|
|
November 21 · Issue #119 · View online
Level Up delivers a curated newsletter for leaders in tech. A project by https://patkua.com. Ideal for busy people such as Tech Leads, Engineering Managers, VPs of Engineering, CTOs and more.
|
|
Moving away from right/wrong solutions In one of my conversations this week, a technical leader was frustrated they couldn’t convince someone of their “right” solution. I find this is a very common situation where a technical person identifies a problem, lands on a solution and is convinced they are right. I know this because I’ve also fallen into this trap too many times in the past. Here are a number of traps to watch out for and what you can do instead:
-
A right solution implies you have all of the information. In reality, other people have perspectives and insights that you don’t have. That new information may change what the “right” solution looks like. Avoid this by involving others, gather perspectives and information before trying to problem solve.
-
A right solution implies there is a clearly wrong solution. All decisions have trade-offs. It’s very rare there is a black and white right and wrong answer. In reality, solutions arrive in more of a spectrum where one option may be better than others in some aspects. Avoid this trap by trying to identify the strengths and weaknesses of options and make the trade-offs explicit.
-
A right solution might only benefit you. Solutions often require change. When there is change, others may feel like they lose something. This might be about others losing certainty, losing status or losing an activity they feel is important to them. Avoid this by considering the consequences of a solution and who might “lose out” in what ways.
Technical folk are often submerged in a world of right and wrong. The test goes green/red. The compiler works/doesn’t work. The CI build passes/fails. Unfortunately, solutions that involve people don’t work this way. Appreciate the shades of grey and watch out for the traps above. Enjoy this week’s newsletter and be sure to pass it on to a friend or colleague.
|
|
Start to look for the shades of grey and move away from considering solutions "right" or "wrong"
|
|
The Ultimate Guide to Hiring Software Developers Finding the right software engineers for your project is not easy. This guide covers everything you need to know about hiring skilled developers—both onsite and remotely.
|
|
|
Range Podcast hosted by Jean Hsu: Different Flavors of Tech Leadership
Reading time: 5mins, Podcast: 25mins
Jean Hsu (@jyhsu) interviewed me for this podcast where we talked about different flavours of tech leadership, systems thinking and more topics I enjoy discussing. Check it out.
|
The Managers Driving the Great Resignation
Reading time: 7mins (Medium paywall) Benn Wann covers a number of manager anti-patterns that he thinks is driving the Great Resignation. Make sure you’re not falling into one of these traps
|
Step away from the office, and join the team!
Reading time: 7mins
Chris Matts (@PapaChrisMatts) shares some wonderful observations and stories about company culture. He also covers the small nudges other leaders made to successfully shift their company’s culture.
|
25% off all courses with the code BLACKFRIDAY21 until Nov 28, 2021
|
|
The strong and weak forces of architecture
Reading time: 8mins This is a great article from Evan Botcher (@evanbottcher) thinking about decision-making at different scales using an example of his current company. He introduces a simple model to contextualise decision-making at each of these scales. 👏
|
Automating cloud governance at scale
Reading time: 7mins I’m a big fan of Infrastructure as Code, DevOps and the increasing pull towards DevSecOps. This recent case study from Oliver Crawford and Oscar Blanco Castan from Skyscanner show how they applied a DevSecOps approach to securing their infrastructure at scale.
|
Scaling productivity on microservices at Lyft (Part 1)
Reading time: 9mins Garrett Heel shares another case study about improvising productivity at Lyft after completing a monolith to microservices migration and the next constraint appearing in their development tooling. Read the first of four articles that sets the scene and follow their blog to read the rest.
|
|
🌟🌟🌟 Reach thousands of engineering leaders around the world. Maybe you want to share a leadership role you’re looking to fill? Interested in becoming a sponsor? Get in touch for details for a sponsorship slot in 2022. 🌟🌟🌟
|
|
|
Get your OKRs out of my GEMs
Reading time: 11mins Like with any tool/process, there are many poor implementations of OKRs. Kathy Keating (@kathkeating) offers a neat approach to address an implicit part of OKRs and therefore often missed - the experiments or ideas. Find out how GEMs may may offer a better alternative to OKRs.
|
Portugal makes it illegal for your boss to text you after work in 'game changer' remote work law
Reading time: 4mins I found this new law by Portugal interesting in response to increased remote working. Although I don’t anticipate the US to follow anytime soon, I wonder if any other European cities will?
|
How product engineering teams avoid dependencies -- the independent executor model
Reading time: 8mins
Jade Rubick (@JadeRubick) publishes another insightful article on how to deal with dependencies between teams and the trade-offs associated with each approach.
|
|
Too many of these teams! 👇 Congrats to Randy for doing the homework and calling it out 👏
|
|
@ @ @ @ @ After about a year of working on an agile team, I decided to look up the manifesto. I was not working on an agile team. It was a "half of scrum done badly plus Jira" team.
|
|
|
|
|
I've seen growing business-speak use of "let's align/ensure alignment with team/person x", and I had an epiphany: You can *align* with someone without *agreeing* with them - Alignment means pointing in the same direction, but the path to get there is up to you.
|
|
|
|
If you enjoyed this newsletter, please send me feedback and share it with others!
|
Did you enjoy this issue?
|
|
|
|
In order to unsubscribe, click here.
If you were forwarded this newsletter and you like it, you can subscribe here.
|
|
Patrick Kua, Postfach 58 04 40, 10314, Berlin, Germany
|