My Mistakes and Advice Leading Engineering Teams
Through many mistakes and some wins, I progressed from leading 1 team to 5+ teams in my full-time career. Here are my learnings!
This week’s newsletter is sponsored by Cerbos.
Your authorization infrastructure is costing you millions, and undermining Zero Trust.
Most engineering teams are still managing authorization with hardcoded permissions scattered across services, creating massive hidden costs in rework and slowing innovation to a crawl.
This approach is why Broken Access Control is the #1 vulnerability in the OWASP Top 10, with 94% of applications tested exhibiting some form of access control weakness.
Cerbos is an authorization solution for the software enterprises are building. It is designed for Zero Trust environments and AI-powered systems.
It enforces fine-grained, contextual access control across applications, gateways, APIs, workloads, and AI agents, without the hardcoded mess.
What organizations achieve with Cerbos:
Cut authorization bugs and incidents by 75%
Accelerate authorization changes by 90%
Deploy policies from setup to production in hours, not weeks
Maintain full audit trails for SOC2, ISO 27001, FedRAMP, HIPAA, GDPR compliance
Cerbos provides externalized authorization that scales with your business, whether you’re at 100 users or 1 million.
Your authorization logic stays out of your codebase, your engineers stay focused on innovation, and security teams have the controls they need.
Thanks to Cerbos for sponsoring this newsletter, let’s get back to this week’s thought!
Intro
There’s a big difference between leading 1 vs 3 vs 5+ engineering teams. The shift feels like going from player to coach, then to strategist.
Letting go of control and elevating your team becomes increasingly important the more teams you lead.
Leading 1 team: You are involved with the details and the context of the team, and you can spend some time doing hands-on work together with the team.
Leading 3 teams: Your role as a coach is becoming a lot more prominent. One of the key things you need to do here is to put the right people in place to lead each of the 3 teams.
Leading 5+ teams: You are starting to structure the org in a way that can support a bigger scale. You need to prepare and hire your first EM and add additional when needed.
I went through all of these phases growing from Team Lead → EM → Head of Engineering → VP → CTO.
In today’s article, I am sharing my mistakes and also my advice if you start leading 1, 3, or 5+ engineering teams.
Visual/Audio Version of the Article
You can watch/listen to the video below, or you can keep reading for the complete overview and insights of today’s topic!
How I Progressed in My Career Leading Teams
Let me first share a bit about my career and how I progressed in leading teams.
I started as a Software Engineer, and then after a couple of years, I grew to become a Senior Software Engineer.
Later, I became a Team Lead leading 1 engineering team. After six months, I grew to become an Engineering Manager → that’s when I started leading 3 engineering teams.
After a little bit more than a year in the EM role, I became Head of Engineering → that’s where I led 5+ teams. I believe it was around 7 at the most when I also became an interim CTO. It was a combined 35 direct and indirect reports.
And then I’ve gotten an opportunity as a VP of Engineering at a different company, where I led a cross-functional team, and after 6 months, I got promoted to CTO.
You can read my full career progression here:
Today, I am sharing my experience on what I would do differently if I could roll back time!
My Mistakes and Advice Leading 1 Engineering Team
Let’s start with leading 1 team.
Let’s imagine you’ve moved from a Senior Software Engineer role into a Team Lead position. You’re now responsible for a cross-functional team that includes Software Engineers (both frontend and backend), a QA, and a PM.
This was also the structure of the first team I managed as a new Team Lead.
Here are the top 3 mistakes I made when I first became a Team Lead:
I didn’t manage my time correctly
I tried to do everything myself. Coming from a Senior Software Engineer role, I was still focused on being the top individual contributor → finishing the most tasks and getting the most done, while also trying to manage the team, doing stakeholder management, and communication with all the other teams. Plus, of course, facilitate all the meetings.
It quickly became too much. It brought me close to burning out. That was a clear sign that I needed to manage my time better.
Once I did, things improved. I reduced my individual contributions, delegated more, and started to trust my team more.
I focused too much on things that I couldn’t control
Another mistake I made was focusing too much on things outside of my control. As a new Team Lead, I saw many issues across other teams, departments, and the wider organization that I wanted to fix, even though they weren’t my responsibility.
I eventually realized I couldn’t change everything myself. What I could do was to provide helpful suggestions and build strong relationships with the people who owned other areas of the organization.
I wanted to be included in all the fine details
The third mistake I made was wanting to be involved in every detail. As I mentioned earlier, I tried to take on the most tasks, and often the hardest ones, which only added to the pressure.
This became a problem because I became a bottleneck. Over time, you have to trust your team to handle tasks, otherwise, you’ll burn out.
It became better when I started to delegate the ownership of less critical work to my team and stayed focused on what truly mattered for the team, the organization, and the overall business.
To read my full story from growing from an IC to a Team Lead, you can check out the article:
Now, here’s my advice for anyone transitioning from an individual contributor to leading a team:
Focus on the areas where you’re not as strong.
Most new team leads are already comfortable with technical work. They’ve grown from Engineers to Senior Engineers and built strong knowledge of certain frameworks and programming languages and engineering fundamentals.
From my experience, first-time managers lack skills like time management, running effective meetings, managing expectations, and good communication.
These are very different from building features or writing code.
My suggestion is to intentionally work to improve in these areas. One way to focus on that is to put your individual contribution second or to not do it for some time at all.
If you keep trying to be the strongest engineer on the team, you won’t have the time or focus to develop these new leadership skills. So, prioritize the areas where you’re weaker and work to improve in them.
And remember: you will make mistakes. Everyone does when transitioning from engineer to first-time team lead (manager). Learn from them, adjust, and keep moving forward.