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

  Strategize Your Career
  by
  Fran Soto

• Euro tech jobs from

  The European Engineer
  by
  Nicola Amadio

• Why you should avoid heroism in engineering from

  Engineering Leadership
  by
  Gregor Ojstersek

• Machine learning interviews from

  The ML Engineer Insights
  by
  Kartik Singhal

---

👋 💬 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.