I started managing an engineering team this month. 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.
Ask me in six months how it’s going.