Empowering Engineering Teams Through Balanced Leadership

While leading software teams at a rapidly growing technology company, I discovered a paradox: our most talented engineers had become our most significant bottleneck. It wasn't their fault—we had created this situation by following a traditional playbook that, despite its apparent logic, was quietly undermining our success.

Recognising the Hidden Cost of Role Accumulation

Like many technology organisations, we built our engineering structure around Tech Leads. In reality, this wasn't a proper position - it was just a set of extra responsibilities we added to our senior engineers. We asked them to maintain their coding duties while leading technical decisions and acting as the primary contact for product and business stakeholders. At the time, this seemed logical. After all, should our best technical minds guide the way?

I remember one project that initially validated this approach. We faced a critical decision about migrating from a monolithic architecture to microservices. Wearing his Tech Lead hat, one of our senior engineers masterfully guided the technical discussions. He weighed complex factors like service boundaries and data consistency, steering us away from pitfalls. It felt like proof that our model worked.

But as our organisation grew, I started noticing concerning patterns. During a particularly challenging project, I watched one of our most talented senior engineers struggle to balance it all. He was trying to write code, mentor junior engineers, make architectural decisions, and manage stakeholder communications - all at once. The strain was visible. Team members began hesitating to make even minor technical decisions without consulting him. The team delivery was highly impacted when the Tech Lead went on vacation. What had started as an efficient way to leverage our best talent was now holding everyone back.

The Pivot to Dedicated Leadership

The solution wasn't immediately obvious, but I knew we needed fundamental change. Instead of tweaking the existing model, we needed to rethink our approach to engineering leadership entirely. This led us to introduce Engineering Managers (EMs)—not as an additional role but as a dedicated position focused on team leadership and growth.

What fascinated me was how our practical experience led us to a model that aligned remarkably well with the principles outlined in Matthew Skelton and Manuel Pais's "Team Topologies." Without initially realising it, we were reshaping our organisation into what they describe as stream-aligned and platform teams. This theoretical validation of our hands-on experience helped us articulate the 'why' behind our structural changes.

This was about more than just creating a new management layer. It was about deliberately ending the practice of role accumulation that was burning out our senior engineers. We wanted to let technical leaders focus on technical excellence while having dedicated managers support team growth and development. Our stream-aligned teams would own distinct product areas, while platform teams would provide the crucial infrastructure and tooling that reduced complexity for everyone else.

The transformation proved more challenging than I anticipated. Change is always tricky, especially when it challenges long-held beliefs about how things should work. I had to navigate resistance from multiple directions, each requiring a different approach.

Navigating the Winds of Change

Looking back, I was naive to think that introducing Engineering Managers would be a straightforward transition. The challenges came from every direction, and each required careful navigation. My experience working in both models - first with Tech Leads and then with Engineering Managers - proved invaluable in these conversations. Instead of theoretical arguments, I could share real examples of how each model operated in practice.

The first pushback came from senior leadership. I still remember the sceptical looks when I proposed removing the Tech Lead role entirely. "Won't this dilute our technical excellence?" they asked. Having lived through the limitations of the Tech Lead model, I could explain how role accumulation was holding us back. It wasn't about reducing technical leadership but enabling it to thrive by removing the burden of management tasks.

The conversations with product managers were particularly enlightening. Over time, they had become de facto facilitators for engineering teams, running ceremonies and managing processes. When I first suggested changing this dynamic, their resistance was noticeable. They saw it as losing control. The breakthrough came when we analysed how they spent their time. One product manager realised she was spending more time coordinating engineering tasks than doing actual product discovery. This helped shift the conversation from what they might lose to what they could gain - the freedom to focus on their core product responsibilities.

The Heart of Resistance

But the most delicate conversations were with our senior engineers. I'll never forget one particularly heated discussion in which a respected senior engineer said, "We don't need someone managing us; we need someone writing code." His words captured many's fear that this change would diminish their influence and autonomy.

These weren't just professional concerns; they were personal. These engineers had built their careers and reputations on being technical leaders. The idea of having a "manager" felt like a step backwards. I realised we needed to show them a future where they could have even more impact but without the burden of juggling multiple roles.

This led us to create a clear technical leadership track parallel to the management track. We wanted to send a strong message that we weren't devaluing technical leadership but giving it room to flourish. We involved these sceptical senior engineers in defining the Engineering Manager role, ensuring it would complement rather than compete with technical leadership.

Making the Investment

Another hurdle was the financial conversation. "How can we justify adding another senior-level salary when this person won't be writing code?" It was a fair question. On paper, adding Engineering Managers looked like pure overhead. But I had seen the hidden costs of our existing model: the delayed decisions, the frustrated engineers, and the increasing turnover.

We built the business case on reducing these hidden costs. Less turnover meant lower recruitment costs, better coordination meant faster delivery, and more transparent decision-making meant less technical debt. But the most compelling argument came from the human side: the cost of burning out our best engineers by asking them to be everything to everyone.

The Transformation Begins

With stakeholder support secured, we began the transition with two pilot teams. We deliberately chose contrasting scenarios: one team worked on a mature product with significant technical debt, and another developed a new service almost from scratch. This would help us test the model's effectiveness in different contexts.

A crucial early decision was to clearly state that the Tech Lead role would cease to exist. This wasn't about rebranding but fundamentally changing how we operated. Senior engineers could now focus on technical leadership without the burden of management responsibilities.

Watching the Change Unfold

The transformation was like watching a garden grow - some changes were immediate, while others took time to flourish. The most immediate impact I noticed was in how teams made decisions. Instead of waiting for a single person's approval, they began having more prosperous, collaborative discussions. Engineering Managers facilitated these conversations, ensuring everyone had a voice while empowering senior engineers to lead technical directions.

This shift in decision-making fostered a more collaborative and inclusive team culture. We saw a noticeable increase in knowledge sharing, with engineers proactively seeking input from colleagues from different experience levels. The EMs played a crucial role in cultivating this environment, encouraging open dialogue, and ensuring everyone felt comfortable contributing their ideas.

One moment stands out clearly in my memory. During a significant production incident, I watched one of our Engineering Managers handle the situation differently: Instead of a Tech Lead jumping in and solving the problem alone, the EM facilitated a team discussion, drawing insights from senior and junior engineers. The solution they reached wasn't just technically sound—it was one the whole team understood and bought into. This wasn't just incident resolution; it was team building in action. Also, the entire team understood the problem and the solution instead of persisting it somewhere in the Tech Lead's head.

The Results

The impact of these changes became evident in ways both measurable and intangible. Team surveys after the pilot showed satisfaction rates with the model hitting over 85%, but the anonymous feedback told the story. One comment mainly stuck with me: "For the first time, I feel like my career growth is being actively supported, not just through technical guidance but through meaningful conversations about my professional development.".

The numbers were compelling - we saw a 40% reduction in voluntary departures in the year following the transition. We can't pin this result on this change; other factors must be considered. But behind these statistics were real human stories. Engineers stayed not just because they were satisfied but because they could see clear paths for growth, whether technical or managerial.

Learning Through Experience

Some of our most valuable lessons came from things we hadn't anticipated. We learned that maintaining strong technical practices during a management transition isn't automatic - it requires conscious effort and clear communication channels between technical and managerial tracks. We discovered the importance of flexibility in adapting the model to different team contexts; what worked perfectly for one team needed tweaking for another.

As our pilot teams demonstrated success, something unexpected happened: other teams started asking to adopt the new structure. This organic pull for change was more potent than any push we could have created. The pilot teams became advocates, sharing their experiences and lessons learned with others contemplating the transition.

A New Way Forward

Looking back on this journey, I'm struck by how fundamental this change was. We didn't just reorganise reporting lines or create new titles - we transformed how our engineering teams operated at their core. The success wasn't just in creating a new management structure but in freeing our technical leaders to excel in their areas of strength while providing dedicated support for team growth and development.

As our industry evolves, this balanced approach to engineering leadership becomes even more crucial. Modern software development requires technical excellence and strong people leadership, and combining these in a single role often means doing better than we could.

The Journey Continues

What started as a structural challenge to solve bottlenecks revealed a more profound truth: the path to technical excellence isn't about asking our best engineers to do more - it's about creating space for them to do what they do best.

Our transformation was more than just improved metrics or better project outcomes. I saw senior engineers diving deep into complex technical challenges without the burden of unofficial management duties. New managers had grown into their roles, fostering environments where their teams could thrive. Most importantly, people were energised by having the freedom to choose and excel in their chosen paths.

Transforming that engineering organisation taught me that building great software teams isn't about finding unicorns who can do everything. It's about creating an environment where technical and people leadership flourish naturally and support each other. Sometimes, the best solutions come not from adding more responsibilities but from genuinely giving people the space to excel.

A Question for You

Have you experienced similar challenges in your engineering organisation? Perhaps you've seen the strain of role accumulation on talented engineers, or you're currently transitioning to more specialised leadership roles. I'd love to hear about your experiences and perspectives on this journey. What approaches have worked (or haven't worked) in your teams? Let's continue this conversation in the comments below.