You have 0 further articles remaining this month. Join LeadDev.com for free to read unlimited articles.
Every engineer who transitions into management gets asked this age-old question at interviews, performance reviews, and career planning meetings. Most new managers I know have answered, ‘I want to help other engineers grow.’ This is brilliant. It tells me that they have the right motivation to become a multiplier. Beyond enabling others, there are various, more nuanced flavors to engineering management. Every manager feels more inclined to play certain roles compared to the others, though a strong manager can apply a range of styles and skills from their leadership toolbox to handle organizational challenges. They can lean into a few flavors at a time to most effectively handle the problem at hand.
Let's illustrate the eight flavors of engineering management through an example scenario. You are deployed to a recently formed team. The product managers are concerned that multiple projects didn't meet the estimates, yet again. The sales team has completely lost faith in your team to deliver on your commitments and put a lot of pressure on your manager to rectify the low performance. What does debugging the struggling team look like in the eight flavors of engineering management?
Let's look into the data to see why the projects are delayed. I have a hunch that it is about our low velocity. I have set up the four key metrics from the book Accelerate: lead time, deployment frequency, mean time to restore (MTTR), and change fail percentage. It looks like our team's deployment frequency is low, and the lead time (defined as ‘the time it takes to go from code committed to code successfully running in production’) is exceptionally high compared to the industry average. Looking at our CI/CD dashboard, the long test-running times could have contributed. Let's staff this project ASAP in Q2.
From the team's last retrospective, we identified that each project needs a specific owner in order to have clear accountability in the team for our running projects, from ideation to deployment. While we're at it, let's document the way we run projects and compile a playbook to get alignment within the team and eventually have other teams adopt it.
Let's go back to the whiteboard. What was the problem statement for this project? What value were we attempting to yield from it? We want to validate our assumptions in the shortest cycle possible. Let's work with Product to scope it down significantly, chop it up into multiple iterative milestones, and establish clear metrics and ways to prove our hypotheses.
We need to tackle these tech debts before we can deliver fast. Let me work with several experienced engineers on the team to scope this out. We could move the purchase flow code into its own service out of the monolith. With a 4-engineering-week upfront investment, we could reduce at least ~70% of engineering time whenever we have to touch this critical purchase flow that the sales team relies on so much.
I need to make sure other departments are aligned with the changes our team has planned. To have the project playbook idea and the purchase flow refactoring project go through, I need to make sure the Head of Product backs us up before our leadership meeting by Tuesday. Let me have a chat with them.
After we get the green light, I'll set up a meeting with the Head of Sales, updating them about our improvement plans, so that they can gradually restore their trust in us. And of course, I will report up to my manager about the game plan, so they know I have gotten the team performance taken care of.