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.
My Mistakes and Advice Leading 3 Engineering Teams
Now let’s move on to leading 3 teams.
This is the shift from Team Lead to Engineering Manager. In some companies, an Engineering Manager still leads only one team, but in my view, the role really begins when you manage at least 2 or more teams.
That means Team Leads now report to you, and you’re responsible for a broader area within the engineering organization.
This transition happened very quickly for me, only about six months after becoming a Team Lead. I had just started to feel comfortable in that role when I suddenly found myself overseeing three teams.
Here are 3 mistakes I made when I first moved from Team Lead to Engineering Manager:
I didn’t make decisions fast enough
My first mistake was procrastinating on decisions.
I tried too hard to make perfect decisions because I didn’t want to get anything wrong. But the longer I waited, the worse things became. I also assumed that some issues would simply resolve themselves with time, but they never do.
It’s almost always better to make a timely decision and then adjust if it doesn’t work, rather than delay and let problems grow. This was a big lesson for me.
I tried to protect my teams too much
My second mistake was trying to protect my teams too much.
I remember situations where stakeholders, my manager, and the leadership team were facing business challenges or questioning our direction. Instead of involving my teams, I tried to shield them from these issues and kept most of the context to myself.
The problem is that such lack of transparency prevents people from seeing the real situation, and without understanding what’s happening in the business, the challenges we’re facing, or why priorities are shifting, the team can’t adapt or help solve the problems.
The better approach is to be open and share relevant business context and challenges. When the team understands the reality, they can respond more effectively and contribute to better solutions.
My communication wasn’t on point
My third mistake was ineffective communication.
When I first became an Engineering Manager, I was very passionate and eager to improve things across the entire organization. I still hadn’t fully learned that I couldn’t fix everything outside my control.
I tried pushing for change in many areas → across engineering, other departments, and the wider business. I even sent emails to leaders outside my scope and occasionally went above my own manager.
The lesson here is that it’s fine to offer suggestions and share ideas, but you shouldn’t expect them to be implemented immediately, or at all. Ownership still belongs to the people responsible for that area.
This also strained my relationship with my manager because I bypassed them at times.
So, communication becomes even more important when you’re leading multiple teams. Provide input respectfully, through the right channels, and be comfortable when decisions don’t go your way.
Now, let me share my advice for anyone becoming an Engineering Manager and leading multiple teams:
Start delegating effectively
You’ll now have team leads reporting to you, which means you’re no longer working directly with people doing hands-on work. Your role shifts from being a “player-coach” to being a full-time coach.
Your main focus should be on effective delegation. You need to become good at prioritizing your workload and what should be delegated. To do that well, you need to have Team Leads reporting to you that you can trust, rely on, and know will get things done with their teams.
One of the most important parts of this role is developing those leaders: coaching them, helping them grow, and empowering them to guide their own teams confidently.
You need to become a great coach and mentor, and select the right people for Team Leads
As an Engineering Manager, your most important responsibility is developing other leaders. Choosing the right people to become Team Leads is one of your earliest and most impactful decisions.
Once they’re in place, your primary role is to coach and mentor them so they can guide their teams effectively.
Your success now depends on how well they lead, not on what you personally deliver. That means spending time helping them grow: giving feedback, helping them think through problems, supporting their decisions, and empowering them to take ownership.
Your goal is to build confident leaders who can operate independently and create healthy, collaborative teams. Coaching is no longer part of the job → it is the job.
You need to focus on streamlining the process and good cross-team collaboration
You also want to help your organization run like a well-oiled machine. Part of this is spotting risks early, such as bottlenecks or “hero engineers” who hold too much knowledge about a specific part of the system.
As a coach, you should guide your Team Leads to spread knowledge, reduce dependency on single individuals, and plan for what happens if someone leaves or becomes unavailable.
At this level, you must think more strategically. Effective delegation becomes essential. Encourage your teams to take on real business challenges and help them prioritize the most important work.
You’ll also spend much more time on cross-department and cross-organizational communication than you did as a team lead.
A big part of your coaching responsibility is helping your Team Leads understand the broader business context and communicate it clearly to their teams.
My Mistakes and Advice Leading 5+ Engineering Teams
Now let’s talk about leading five or more teams.
At this stage, you’re likely a Director, VP, or Head of Engineering. I was a Head of Engineering, managing 35+ direct and indirect reports.
Here are 3 mistakes I made when I became Head of Engineering:
Not focusing on building really good relationships with the executive team
My first mistake at this level was not investing enough in strong relationships with the executive team.
I had decent relationships, which helped me later become Interim CTO when the existing CTO left. But if I could go back, I would have focused even more on deepening those relationships.
At this level, Head of Engineering, VP, CTO → the leadership team is your first team. Your engineering teams are your second. Building strong trust with the leadership team is critical because:
It’s easier to push initiatives forward
You gain allies across departments
You’re more aligned with business priorities
Cross-department work becomes much better
When your relationships are strong, it becomes far easier to deliver results across the company.
Focusing on 1 issue at a time
My second mistake was trying to fix everything at once.
At that time, there were issues everywhere: architecture problems, technical debt, misalignment across departments, and more. I tried to be involved in all of it, improving everything simultaneously.
But that approach doesn’t work. You can’t solve all the problems at the same time. You need to choose your top priorities → #1, #2, #3, and focus on those, and make real progress before moving on.
Once you’ve improved an area, you must also ensure it doesn’t slip back to its old state. So the key is prioritizing, tackling issues one by one, and maintaining the improvements as you move forward.
If there are any issues inside the leadership team, that spirals down to all the teams
My third mistake was underestimating how leadership issues spread through the entire organization.
We went through many changes in the leadership team, my manager (the CTO) left, I became interim CTO, and other departments had turnover as well. During these shifts, there were moments of misalignment, unclear communication, and mismatched expectations among leaders.
When that happens at the top, it always trickles downward. Teams become confused, priorities shift, communication breaks down, and overall productivity suffers.
Conway’s Law becomes very real here: the structure and health of your codebase often mirror the organization’s communication patterns. If leadership isn’t aligned, teams won’t be either.
As a senior leader, it’s your responsibility to help maintain alignment and strong relationships across departments.
Everyone must work toward the same goal → helping the business succeed, not just optimizing their own department in isolation. Collaboration at the top determines how well the entire organization functions.
Now, here’s my advice for anyone moving from engineering manager to director, VP, or head of engineering.
Make sure to focus on implementing some level of metrics
My first recommendation is to introduce at least a basic set of metrics. At this level, metrics make it much easier to manage expectations because they give you objective data.
They also help you understand what’s happening across the organization without being involved in every team’s day-to-day work.
You’re now relying heavily on your leaders to run different areas of the engineering org, so you need some high-level signals to know how things are going.
Start small → choose 1 or 2 meaningful metrics that make sense for your org. You can add more over time as needed.
Metrics create clarity, help you communicate more effectively with executives, and allow you to spot issues early.
Focus on really understanding the business, the industry, and the overall org challenges.
The second thing is to focus on understanding the business, industry, and organizational challenges. At this level, you become the bridge between the business and engineering. Your job is to ensure engineering work aligns with business goals.
The better you understand the business context → market, customers, priorities, risks, and constraints, the better you can guide your teams to focus on what truly matters.
This is critical. If you have, let’s say, 40 engineers across seven teams and they’re all working on the wrong things, the impact is massive. Strong business understanding ensures your organization’s effort is pointed in the right direction.
Building really good relationships is the key to success
The third point, and one I can’t stress enough → is the importance of strong relationships.
The higher you go, the more critical this becomes. If your relationships with the rest of the leadership team are weak, the entire organization will feel it.
Remember:
Your first team is the leadership team.
Your second team is the engineering organization.
If alignment and trust are missing at the top, it will inevitably show up inside engineering as well. Good relationships create clarity, collaboration, and momentum. Poor relationships slow everything down.
The Biggest Lesson
Growing from an individual contributor into a senior leader is a journey filled with new challenges at every stage.
Each step, leading one team, managing multiple teams, or guiding entire departments → requires you to evolve how you think, communicate, and lead.
Your job becomes less about doing the work yourself and more about empowering others to do their best work.
As you progress:
Let go of perfection and make timely decisions.
Delegate intentionally and trust your people.
Focus on coaching and developing leaders.
Invest deeply in relationships, especially with the executive team.
Understand the business so engineering efforts support real goals.
Use metrics to stay aligned and manage expectations.
Protect alignment at the top, because it shapes the entire organization.
You will make mistakes, everyone does. What matters is learning from them, adjusting, and continuing to improve.
Last words
Let’s end this article with the following:
The more you grow as a leader, success isn’t about what you build, but what your people can build. Your people are your greatest leverage.
You got this!
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
+100! All great points that apply to other career paths beyond the engineer-to-CTO path!
Fantastic as usual! Thanks for sharing.