“Management is not a promotion, it’s a career change” - Lindsay Holmwood
You know those moments when advice hits you years after someone gave it? That quote from my first engineering manager has been living rent-free in my head during my first year of management. And boy, was Lindsay right - this isn’t just climbing another rung on the ladder, it’s more like jumping onto an entirely different ladder… while the first one’s still moving.
Let me paint you a picture: Imagine you’ve spent years mastering chess, getting really good at calculating moves and orchestrating brilliant plays. Then one day, someone hands you a whistle and says, “Great! Now go coach soccer.” Sure, some of that strategic thinking transfers over, but suddenly you’re dealing with twenty-two moving pieces who all have their own ideas about where they should be running. That’s what becoming an engineering manager feels like.
The Great Identity Shift
The first and perhaps most jarring realisation is that your measure of success undergoes a complete metamorphosis. Remember that dopamine hit when you squashed a particularly nasty bug or got a clean build after days of refactoring? Those mostly disappear. Instead, your “work” becomes your team’s success - a much more nebulous and long-term proposition.
I spent my first few months as a manager feeling like I was somehow cheating the system. Here I was, spending entire days in one-on-ones, writing project proposals, and responding to messages, all while my Git contribution graph flatlined. The hardest part wasn’t the new responsibilities - it was the nagging feeling that I wasn’t doing “real work.” It’s a mental adjustment that takes time: learning to see value in the invisible work of management.
Let me tell you about this one week that really drove it home. By Friday, I had exactly zero lines of code to show for myself. But what did happen? I helped an engineer break through a wall they’d been banging their head against, prevented a design decision that would’ve spawned enough technical debt to need its own credit score, and watched another engineer nail their first presentation in front of a group of stakeholders. None of that shows up in a pull request, but hot damn if it wasn’t some of the most important work I’d ever done.
This transition requires redefining your relationship with productivity. Your impact becomes increasingly indirect - you’re no longer the one writing the code or designing the systems, but you’re creating the environment where great code gets written and elegant systems get designed. Success might look like a team that’s running smoothly, delivering consistently, and growing both individually and collectively. It’s less tangible than a green CI pipeline, but potentially far more impactful.
The Hidden Currency of Tech: People Skills
Here’s something they don’t tell you in computer science: while hard technical skills might get you through the door, it’s the soft people skills that ultimately determine your ceiling - especially in management. The tech industry has traditionally emphasised technical prowess, often at the expense of people skills. But when you step into management, this equation flips entirely.
Suddenly, you’re being paid to be empathetic. Let that sink in for a moment. Your primary value isn’t in writing elegant code or architecting systems - it’s in understanding people, their motivations, their fears, and their aspirations. And let me tell you, a Kubernetes cluster on its worst day has nothing on the complexity of a team hitting a project deadline while Mercury is in retrograde.
This shift requires developing an entirely new toolkit. You need to learn how to read between the lines in conversations, how to provide feedback that motivates rather than deflates, and how to handle conflicts before they become crises. You’ll find yourself dealing with imposter syndrome (both your team’s and your own), career development questions that don’t have clear answers, and interpersonal dynamics that no amount of technical expertise can solve.
However, I’ve found that the same analytical skills that made me a good engineer can be applied to people problems - just in a different way. Instead of debugging code, you’re debugging communication patterns. Instead of optimising systems, you’re optimising team dynamics. The key is to approach these challenges with the same rigour and systematic thinking you’d apply to technical problems, while recognising that human systems are far less predictable and require much more patience and flexibility.
The Bob Hawke Approach to Leadership
One of my favourite frameworks for thinking about engineering leadership comes from an unlikely source: former Australian Prime Minister Bob Hawke. His leadership style wasn’t about being the smartest person in every room - it was about surrounding himself with brilliant people and having the wisdom to trust their judgment. Revolutionary, right?
A good friend of mine calls this style of leadership the “Bob Hawke Approach,” and it goes something like this: hire people smarter than you (or people who’ll probably surpass you given half a chance), make sure they have everything they need to produce their best work, then get the hell out of their way and let them be great. This isn’t just feel-good management speak - it’s a practical strategy that consistently delivers results
This philosophy has profound implications for how you operate as a manager. It means actively seeking out people who might intimidate you with their technical skills. It means creating an environment where your team feels empowered to challenge your ideas and propose better solutions. It means being comfortable with the fact that your team members might know more than you about certain technical areas - and celebrating that fact rather than feeling threatened by it.
Here’s the beautiful part: when you stop trying to be the technical hero and start being the person who enables technical heroes, something magical happens. Your team starts solving problems you wouldn’t have even thought of. They come up with solutions that make your old “brilliant” ideas look like something coded on a Commodore 64.
I’ve also seen this approach pay dividends in unexpected ways. When you hire people smarter than you and give them the autonomy to excel, they not only deliver better results - they also raise the bar for the entire team. They become force multipliers, mentoring their peers and driving technical excellence through example. Your role becomes less about directing traffic and more about removing roadblocks and creating opportunities for your team to shine.
The Empathy Advantage
Perhaps the most valuable asset I’ve brought from my individual contributor days isn’t any technical knowledge - it’s the ability to truly empathise with my team. Having walked a mile (or several thousand) in those shoes gives you a unique perspective. You understand the frustrations, the challenges, and the small victories that make up an engineer’s day.
This isn’t just about understanding the technical challenges - it’s about remembering what it feels like to be on the receiving end of those “urgent” requests that come in at 4:55 PM on a Friday. It’s about knowing the unique flavour of dread that comes with being assigned to refactor a codebase whose last contributor left the company during the Obama administration. When someone says they need focused coding time, you remember your own experiences with context-switching hell.
This empathy becomes your secret weapon. It helps you make better decisions about timelines, resource allocation, and technical debt. But more importantly, it helps you build the kind of trust that makes teams excel. Your engineers know you’ve walked in their shoes, and that makes all the difference in how they receive your guidance and feedback.
The Leadership-Management Distinction
One crucial lesson from this year has been understanding that management and leadership, while related, are not synonymous. Management is about processes, resources, and outcomes. Leadership is about vision, inspiration, and growth. The best managers do both, but they’re distinct skills that require conscious development.
Management skills are more concrete and process-oriented: running effective meetings, setting clear expectations, providing constructive feedback, and ensuring projects stay on track. These are the mechanical skills of keeping a team running smoothly. They’re essential, but they’re not enough on their own.
Leadership, on the other hand, is about the intangibles: creating a compelling vision that motivates your team, building a culture of psychological safety and continuous learning, and helping each team member see their own potential for growth. It’s about making decisions that might be unpopular in the short term but serve the team’s long-term interests.
I’ve learned that great engineering management requires a careful balance of both. You need the management skills to ensure the trains run on time, but you need leadership skills to ensure they’re heading in the right direction. Some days you’re a project manager, some days you’re a coach, and some days you’re a visionary - the art is in knowing which hat to wear at which moment.
The Support System Paradox
Here’s an interesting twist: as you become responsible for supporting others, your own need for support often increases. Having mentors and other managers to talk to becomes not just helpful, but requiredl. The challenges you face are often too nuanced for friends outside the industry to fully grasp, and too sensitive to discuss with your direct reports.
This need for support isn’t a sign of weakness - it’s a recognition of the complexity of the role. The decisions you face as a manager often don’t have clear right answers. Should you promote a strong performer even if it might destabilise team dynamics? How do you balance giving a struggling team member time to improve with maintaining team productivity?
This is where having your own support network becomes crucial. Other engineering managers become your rubber ducks - except instead of explaining why your code isn’t working, you’re explaining why your days suddenly feel like a reality TV show. These relationships are your safety net when you need to ask questions like, “Is it normal to feel like I’m making this up as I go along?” (Spoiler alert: yes, it is.)
Looking Forward
When I first stepped into management, I thought I’d finally get to implement all those grand technical visions I had as an engineer. What I didn’t expect was to find joy in watching other people implement even better versions of those visions.
After a year in this role, I can tell you that while my Git commits might be down, my impact has never been higher. Those technical skills I spent years honing haven’t gone to waste - they’ve just become part of a larger toolset. They help me understand what’s possible, what’s practical, and what’s going to cause problems down the line.
The journey from individual contributor to engineering manager isn’t just a career change - it’s a complete perspective shift. You learn to measure success differently, to find fulfilment in the growth of others, and to see leadership as its own technical challenge. And while I’m still learning every day, I’m convinced that the best engineering managers are the ones who can bridge the gap between technical excellence and human understanding.
And hey, if nothing else, I’m definitely spending less time arguing about tabs versus spaces. Though now I get to mediate those arguments instead - I’ll let you decide if that’s an upgrade.