For a long time, I didn’t think I had much to contribute to the conversation about engineering management.
I wasn’t the engineer who had been programming since childhood. I didn’t study computer science. I started university in engineering, eventually moved into business, and found my way into software through a path that was much less deliberate than it probably looks in hindsight.
And when I became an engineering manager, I certainly didn’t feel like an expert.
If anything, I was a meddling engineer who had been given people to manage.
I cared deeply about the work. Sometimes too deeply. I wanted to help solve the problem, improve the implementation, jump into the discussion, and make sure things were moving in the right direction.
Learning when not to do those things turned out to be a large part of learning how to manage.
Over time, I became more comfortable with the idea that my job wasn’t to be the person with the answer. It was to create an environment where the people around me could find better answers than I ever could on my own.
I learned how difficult that actually is.
Managing engineers means dealing with ambiguity, competing priorities, performance problems, career conversations, organizational changes, disagreement, missed expectations and all the other messy things that don’t fit neatly into an engineering management framework.
I’ve made mistakes in nearly all of those areas.
So when I would see people writing about leadership, management and engineering culture, my instinct was usually that someone else was more qualified.
Someone with a bigger title.
Someone who had managed more people.
Someone who had worked at a more recognizable company.
Someone who had a framework with a clever acronym.
Lately, though, I’ve had reason to reflect on my career.
I’m looking for my next engineering leadership role, and that process naturally forces you to look backwards. You start thinking about the teams you’ve managed, the decisions you’ve made and the kind of manager you’ve actually become.
And while doing that, I noticed a pattern I’m proud of.
Across the teams I’ve led, I’ve had zero voluntary attrition.
Not one engineer has chosen to leave one of my teams.
There are plenty of caveats attached to that statement. I don’t believe zero attrition should be a management goal. People should leave teams. Careers should move forward. Sometimes the best opportunity for someone will exist somewhere else, and a good manager should be willing to help them pursue it.
And I certainly can’t take full credit for someone choosing to stay.
But the pattern still means something to me.
Because when I think about the parts of management I’ve cared about most, retention was never really one of them.
Culture was.
I’ve always wanted to build teams where people feel safe.
Where they can disagree with me.
Where they can say they don’t understand something.
Where they can make a mistake without wondering whether it will define how they’re perceived.
Where expectations are clear and feedback isn’t saved for a performance review.
Where people are trusted to do their jobs.
Where good work is noticed.
Where people know their manager cares about them as people, not just as units of engineering capacity.
I haven’t always gotten those things right.
But I’ve tried very hard to create them everywhere I’ve led.
And perhaps that’s the thing I have something useful to say about.
There is no shortage of writing about engineering management. There are books about organizational design, delivery, metrics, career ladders, technical strategy and almost every other part of the job.
I’m interested in something a little closer to the ground.
What does it actually feel like to work on your team?
What happens when someone makes a mistake?
What happens when someone disagrees with you?
Does an engineer know whether they’re doing well?
Can someone tell you they’re struggling?
What behaviours do you reward?
What behaviours do you quietly tolerate?
Do people feel trusted?
Do they feel appreciated?
Do they feel safe?
Those things might sound softer than architecture diagrams or delivery metrics, but I don’t think they’re separate from engineering performance.
They’re often what determines it.
A team that trusts one another can disagree faster. A team that feels safe can surface problems earlier. Engineers with clear expectations can make decisions without constantly seeking permission. People who feel appreciated are much more likely to invest themselves in the people and work around them.
Good culture isn’t something you build instead of delivering software.
It’s part of how you deliver good software consistently.
That’s what I want to explore here.
I’ll write about things that have worked for me, things that haven’t, mistakes I’ve made, conversations I’ve struggled with, and ideas about what healthy engineering leadership can look like.
I’ll use stories from my career, but I’m not interested in turning former coworkers or companies into case studies. Details will sometimes be deliberately vague. This isn’t a place to settle scores or tell someone else’s story.
I want this to be a safe place to think seriously about management.
I’m still figuring plenty of it out myself.
But after years of wondering whether I had anything worth adding to the conversation, I’ve decided that’s probably enough reason to start one.
