That Extra Focus on Solution is Hurting Your Leadership
How being solution-oriented almost cost me my TL-ship
👋 Hi, this is Akash with this week’s newsletter. I write about leadership and growth in software engineering. We are now close to 2000 subscribers! Thank you for your readership ❤️.
This week, I’m sharing one common mistake that might block your growth beyond Tech Lead. Hope you enjoy this edition!
When I first became a TL ~5 years ago, I liked solving problems for others. I thought that was my job.
Do you work with a Tech Lead who’s
Constantly telling you what to do and how to do it?
Always jump into technical details when you ask a simple question.
Giving you instructions to follow and focusing on what they want out of the project?
I used to be that guy. If someone reached out to me for a simple discussion, I’d dig deep and create a recipe for them to follow and solve their problems. I was pleased with my involvement. I was a solution-oriented, hands-on leader. But, I didn’t realize I was blocking growth for individuals working with me.
I was telling people exactly how to do things. When I got feedback, it was surprising but made complete sense. I made three simple changes to improve my leadership.
Today, I will share my mistakes and lessons learned so you can avoid making them yourself.
⭐ Main Takeaways
Mistakes I made as a solution-oriented Tech Lead
How you can avoid making these mistakes by following three simple changes
🎙️ Announcement
I highly recommend checking out this book. It’s filled with my experience protecting billions of users on the internet and my learnings from working on some of the best security teams, including Google and Apple. If you’re a software engineer interested in building secure products or a security enthusiast, this can be your complete companion. It’s now available for pre-order on Amazon!
🗣️ How I Led Before
Imagine you’re my peer, and you come to me with,
“Hey Akash, my package wouldn’t build. Have you seen this error X before?”
My thoughts immediately,
I don’t want to delay the project
I know exactly where this is coming from
Let me teach them how to debug in a coworking session
To avoid delay, I solved the problem for them.
It helped us move past the issue. But my handholding robbed them of the chance to learn.
I continued making this mistake until a peer shared harsh feedback, “If you don’t let people figure out on their own, you’re blocking their growth”.
This feedback hurt a little at the time because it questioned my ability to do my job. But this single piece of nudge brought the most impactful change.
Enough with the context. Let’s explore what I did and how you can avoid this mistake.
👂 3 ways I avoid dictating now
When we start thinking only about solutions, we tend to dictate to others. This happened to me fairly recently; the role was reversed this time. I was on the receiving end.
The experience closed the loop for me. So today, I am sharing three simple changes I made.
💬 1) Asking open-ended questions
Teammate: “The filter we designed is hitting the system memory limit with an OOM error.”
❌ TL: “Let’s do A, B, and C.” or “I will take a look and send a PR.”
✅ TL: “What options have you considered?” or “How would you approach this?”
Going to the second approach took some time, but it has the following benefits,
Encourages team members to think critically and come up with solutions
Helps you uncover the root of the problem
Builds trust and creates a safe space for your team to learn and grow
🤐 2) Resisting the urge to jump in
Our natural instinct is to fix problems quickly, especially in time-sensitive subjects. Let’s try a different example. Imagine you’re sitting in a weekly status meeting, and a teammate is giving an update on their work.
Teammate: “I have deployed the services but am slightly concerned about race conditions. I will focus on load testing this week.”
❌ TL: “The way I architected the system, I’m not about race condition. I want you to work on X instead.”
✅ TL: “Interesting, let me know what you find. We have another important thing that can use your help. Consider time-boxing your efforts on the tests.”
This is based on real events. There are multiple problems with the first response here. We will take a look at why the second one is better,
Builds confidence for your team members
Creates space for deeper thinking and innovative solutions
Develops leadership skills and helps them step up to take ownership
📚 3) Offering guidance, not answers
Even when asked a question, your team is looking for validation. Offer frameworks, resources, or alternative perspectives to help them find their own answers. This time, we will take an example of designing a system. Your team is designing a data-intensive application, and you’re reviewing the choice of database section.
❌ TL: “We should use Google Firestore. It supports high read volume, and indexing is great.”
✅ TL: “Let’s try to come up with our requirements and compare different options. You can benefit from reading this white paper: <link>”
The first response takes the power of collaboration from the team. Quick fixes like these are not scalable. Some benefits of guidance include,
Builds long-term competence
Promotes autonomy within the team
Takes advantage of a team’s diverse thinking
🌟 🔍 Parting Thoughts
The problem of dictating what and how is wider than new TLs. I’ve worked with a seasoned TL (10+ years as a TL) who had this problem. Things got better after giving the feedback I received earlier in my career.
On the other hand, it’s important to understand that speed matters a lot in real life. We often feel that if I can solve this problem in 5 minutes, let’s just do that. But those minutes add up, and it doesn’t scale.
Another side effect of this behavior is losing talented engineers. If a TL is not creating opportunities for others to grow, they will quickly lose team confidence. You can avoid making the mistakes I made by,
Asking open-ended questions
Encourages critical thinking
Helps understand the underlying problem
Builds trust and creates a safe space
Resisting the urge to jump in
Builds confidence
Creates space for innovative solutions
Develops leadership skills
Offering guidance, not answers
Creates a sustainable environment
Promotes autonomy
Includes everyone in decision-making
What has been your go-to strategy for fighting this instinct as a leader?
Share them in the comments!
🐦🔥 This Week’s Favorites
Index information for growth from
byEuro tech jobs from
byWhy you should avoid heroism in engineering from
byMachine learning interviews from
by
👋 💬 Get In Touch
Want to chat? Find me on LinkedIn.
If you want me to cover a particular area of leadership, you can reach out directly to akash@chromium.org.
If you enjoyed this content, please 🔁 share it with friends and consider 🔔 subscribing if you haven’t already. Your 💙 response really motivates me to keep going.
Give the fish or give the fishing rod and teach how to fish yourself. It's faster to give the solution, but it won't scale.
Thanks for the mention here, Akash!
I love the feedback that you got from your mentor. It wasn't even that harsh, IMO! 😃
I guess this urge to dictate the technical sides happens because all Tech Leads were engineers at some point, and you have a pretty solid idea of how things should be built.
Of course, this doesn't justify telling other people what to do because you not only hinder their development but might also miss out on some great ideas they would have come up with without direction.
I had several occasions throughout my career where I learned stuff from beginner developers when I didn’t tell them exactly what to do!