View profile

Level Up - Issue #114


Level Up

October 17 · Issue #114 · View online

Level Up delivers a curated newsletter for leaders in tech. A project by Ideal for busy people such as Tech Leads, Engineering Managers, VPs of Engineering, CTOs and more.

Which problems are you solving?
Earlier this week I was helping a leader navigate a conflict they were in. They wanted to take one technical approach but found a peer pushing for an alternative approach. They were stuck and couldn’t agree on how to move forward. This happens all the time in technology teams. Your conflict might be picking which tools to use, how to use said tools or even more broadly which problem-solving approach to take.
One of the great things I enjoy about coaching technical leaders is providing a neutral view. I have to ask questions to gain further context, and in that process, people have the opportunity to re-evaluate their assumptions and ideas. As I explored the current situation I was trying to understand why each person was pushing for different solutions. We explored questions like:
  • How does your/their solution improve the situation? In what ways does it improve the situation?
  • What problem are you trying to solve? What problem do you think they are trying to solve?
  • What are you trying to optimise for and what trade-offs are you accepting with your solution? What about their perspective?
  • Are you sharing the same assumptions about these trade-offs?
In the process of exploring these questions, I had the suspicion that one big reason they weren’t getting closer to agreeing was that each person was focused on a different problem, or at least, trying to optimise for different outcomes. This situation is often called cross-talk or talking past each other.
It’s easy to end up talking past each other if you don’t take the time to share information, confirm assumptions and take time to listen to each other. What can help is building a shared external model. That external model could be as simple as building a shared document concretely detailing the specific problem, the pain points a solution needs to address *before* trying to focus on a winning solution.
Your challenge for this week is to pay more attention to any conflicts or disagreements. Listen carefully to see if people are focused on solutions and trying to “convince” the other how their solution is better. Ask questions to draw out assumptions and to see if they’re focused on solving the same (or different) problem.
Enjoy this week’s newsletter and be sure to pass it on to a friend or colleague.
Want to level up your technical leadership skills? Sign up for the online workshop, “Shortcut to Tech Leadership” or take a self-paced course at the

Problems may look the same without taking the time to delve deeper
Problems may look the same without taking the time to delve deeper
Sponsored Content
Scaling Engineering Processes w/ Twitter VP of Eng
Maria Gutierrez’s time as an engineering leader taught her to scale sustainable engineering processes. As VP of Engineering at Twitter, she joined the Dev Interrupted Podcast to share how.
How New Managers Fail Individual Contributors
Staff Software Engineer Responsibilities - Align With Authority
How to safely think in systems.
Join this interactive online course to level up your technical leadership skills
Join this interactive online course to level up your technical leadership skills
How We Design Our APIs at Slack - Slack Engineering
Models That Match Reality
Repository Visualization with GitHub Next
Learn more about systems thinking with this self-guided course
Learn more about systems thinking with this self-guided course
Organisation & Processes
You must not measure individual software engineer performance
SRE Doesn’t Scale
4 Product Development Fallacies
Tweets of the Week
Hear hear 👇👏
Jez Humble
It’s come to my attention that many people think continuous delivery/deployment is about taking whatever crap you have in version control & shipping it into prod as fast as possible so you can test in prod


CD is about making it SAFE to ship your code into prod quickly by:
Great thread to read if you’re unfamiliar with queuing theory
Ben Golub
Here's a basic queuing theory fact that may have behavioral/psychological implications.

If customers take on avg 10 minutes to serve and arrive randomly at a rate of 5.8 per hour, then with one bank teller working, expected wait is 5 hours. With two tellers, 3 minutes.

Thanks for making it this far! 🤗
If you enjoyed this newsletter, please send me feedback and share it with others!
Want to level up your technical leadership skills? Watch out for future dates for the Shortcut to Tech Leadership online workshop, or check out self-paced courses at the Tech Lead Academy.
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.
Powered by Revue
Patrick Kua, Postfach 58 04 40, 10314, Berlin, Germany