This is the 2nd in a 4-part series of how I feel Engineering managers should function. This one talks about value delivery, and how it should be your next priority after focusing on your people.
Your #2 responsibility is delivering value to business.
At most companies (even smaller startups), it’s at the engineering manager level that engineers first start to think about the business[1]. How does my company make money? What is it that customers value? Why is my team building these features? It’s also often the first taste that engineers have of uncertainty & tradeoffs: conversations are littered with: “Can we try this out?”, “I’m not sure it’s going to work.”, “This is what our customers say, but…” and the classic: “Folks, let’s think of what our priorities are.”
As an engineer manager, how do you deal with this uncertainty, this new… mess that is suddenly your life? I have 3 tips:
- Do not confuse delivering features with delivering value. When I say this to a lot of product managers, I get an almost visceral reaction: “What do you mean? It’s the features that our customers pay for, it’s what drives our business.” And of course, that is true. Delivering features is probably what is going to get your company featured in Techcrunch, put you on top of Product Hunt, and even bring in revenue.
Delivering value is delivering what your customers want. Build something people want. Sometimes, it’s more features, but at times, it’s making sure that your app loads much quicker, your site is less buggier, and your interactions make more sense for the jobs he wants to do[2].
So how does this affect you as a newly minted engineering manager? Just like your product manager counterparts, you should know when to push the breaks on features, and think about things like technical debt and simplifying user experience. - Make sure your team has slack. Not Slack, slack: the quality most ignored in ill-functioning “agile” teams. I would suggest a 20% slack when you start off, and a gradual reduction depending on the amount of uncertainty your team faces. If your team is tightly-wound, pushing themselves to complete sprint after sprint, then they will never be productive and happy, and your company will never get those serendipitous moments from smart engineers that can make or break them.
This is probably the hardest thing to communicate to a non-technical manager, especially if they have no prior experience with agile management. “What do you mean you are only planning to 80% capacity?” What are they going to do the rest of the time? Make sure you have a technical debt backlog for when engineers are out of sprint work. One thing I always do is to let engineers make their own TBFs (to-be-filed tickets) every sprint, and if they have slack, they can work on an idea that they came up with to improve the product. - Push for at least a 20% planning budget for technical debt. And 30% or more if your product is in bad shape. Only delivering features when your developers are struggling every day with a horrible codebase is probably a bad idea. Make sure that you have an honest and forthright conversation with business: I know you have these wonderful ideas, but we need to put down some speed breakers so we can go fast later. Don’t go for a big rewrite: a 30% budget is enough, make sure you iterate to where you want to go.
That’s it! Practice these few tips, and you are already well ahead of 90% of new engineering managers. Next week, I’ll write about coding in the trenches, and how to earn the respect of your team.
[1] As an aside, I think this is really flawed. Every engineer should learn about the business from Day 1, and really know and grok what they are delivering, and who they are building products for.
[2] If you have a company in the SaaS space, there is an excellent framework from Rahul Vohra that you should adopt.
Leave a Reply