The short version, if you’re a new engineering manager wondering where to start: get to know the people, learn why things are the way they are, and read the code, in roughly that order. Then set the context and get out of the team’s way.
I started managing an engineering team this month, a few weeks after writing about what changes going from software engineer to engineering manager. The thing nobody warns you about is how urgent everything feels: new team, new company, and a to-do list that existed long before I did. I can’t do it all at once, so I’ve settled on three things to get right before anything else.
Getting to know the team#
I’m booking 1:1s with everyone, and I’m trying to keep them about the person rather than the sprint. What do they want out of their career? What’s been frustrating them? What would they change tomorrow if they could? My job in these is mostly to shut up and listen. Trust isn’t built in week one, but it can definitely be lost in week one.
People also work in very different ways. Some want detailed direction, others do their best work when you stay out of it, and treating one like the other goes badly for everyone. Camille Fournier’s “The Manager’s Path” is good on this. Empathy and actually listening turn out to be most of the job.
Learning why things are the way they are#
Every process and every odd bit of architecture is a record of some old decision. Before I change anything, I want to know what’s been tried, what failed, and what the company genuinely cares about.
Every company also has unwritten rules about how decisions really get made. The faster I work those out, the more I can actually get done for the team. Andrew Grove makes this point in “High Output Management”: you can’t align your team’s work with the bigger picture until you understand the picture yourself.
Reading the code#
I don’t need to be the strongest coder on the team anymore, but I do need to understand the architecture, the pain points, and where the technical debt is buried. So I’m reading code, poking at the deployment pipeline, and asking people what they’d fix if they had a free week. The answers to that last question are usually the most honest roadmap you’ll get.
It also signals something to the team: that I care about the work itself, not just the process wrapped around it.
Then get out of the way#
Once that foundation is there, the plan is simple: set context, share the goals, and let the team make the technical calls. My job isn’t to approve every PR. It’s to make sure people have what they need and are pointed in the right direction. “The Phoenix Project” by Gene Kim makes the same argument: teams that own their decisions move faster and build better software than teams waiting on sign-off from above.
Books for new engineering managers#
The three books I’ve mentioned, in one place:
| Book | Why it helps a new engineering manager |
|---|---|
| The Manager’s Path, Camille Fournier | Written for engineers moving into management, one level at a time from mentor and tech lead up to CTO. Early on, the parts about 1:1s and managing a team are the most useful. |
| High Output Management, Andrew Grove | Older, and written from running Intel, but the core idea holds: a manager’s output is the output of their team, so spend your time where it moves that. |
| The Phoenix Project, Gene Kim, Kevin Behr and George Spafford | A novel about an IT manager rescuing a failing project. Easier going than a textbook, and good on how work piles up and gets stuck between teams. |
Two others come up whenever people ask what a new engineering manager should read: Will Larson’s An Elegant Puzzle, on the systems side of the job (sizing teams, planning, organisation design), and Lara Hogan’s Resilient Management, a short, practical book on getting to know your team, setting clear expectations and communicating well.
Ask me in six months how it’s going.