Product Management for Software Engineers (part three)
The second most common question I get asked after “How do product and engineering work together?” is “How do we balance building features versus working on our tech stack?”. I’ve seen many permutations of this going wrong. If you don’t build features that bring value to your users and employer then you don’t tend to survive long as a team. If you accrue technical debt in the name of delivering features (or hitting deadlines) then eventually you are unable to deliver new features because you’re swimming through treacle. Then you don’t survive long as a team. Obviously, neither extreme is desirable and you have to find a sweet spot somewhere in the middle.
The bad news is this is different for every team and varies depending on the point in time you’re at. It also offers something of a false choice between product and engineering which pits the two disciplines against each other in ways which can become unhealthy. The purpose of this article is to give you another way of thinking about this balancing act which enables you to get the best out of each other and also become more capable as a team.
The premise is simple — what if your team was a product? What would be the key characteristics of the team? Ideally you’d look at something similar to the metrics so eloquently defined in Accelerate. I’m going to take three of the metrics:
- Time to push a change through to production (lead time). How quickly can you deliver a new feature or change to be visible to your users. This represents the limit of the velocity your team can deliver at.
- Time to fix a problem in production (MTTR — mean time to resolve). When things go wrong — how quickly do you detect it and how quickly can you resolve it? MTTR tells you how good your monitoring is and also how quickly you can run something through your build and deploy pipeline.
- Percentage of breaking changes. How reliable is your build and deploy pipeline? How good are your tests? How much faith do you have in any change you make to your product?
I’ve left number of deploys a day because, while this is interesting, it is heavily dependent on what you’re working on and a combination of lead time and MTTR tell you how quickly you can push something to production. It’s also something that can be gamed. You should aspire to be able to deploy on demand.
Ultimately, whether a team is effective is whether it solves real problems at a pace which is comparable to (though ideally better) than your competitors. If you’re not consciously investing in this capability then you’re going to be offering people the false choice of features vs tech and missing out on the things which will allow you to compete.
How do you get to this magical place? It’s not as hard as you think. The bad news is there is no button you hit and suddenly you’re doing everything right. I remember I had one team that had just inherited a codebase that was quite tangled with a number of other products. It took us 5 weeks to make a change to a button. This was terrifying at the time but it led to the conversation which allowed us to move towards the team we wanted to be. It started with two questions:
- What are the things that are slowing us down? You should revisit this often (maybe even weekly) to understand the things which make it difficult to make progress. No software engineering team ever said “it’s too easy to get things done here”. It might be that you need approval or feedback from another team (hint: don’t wait until the day before you want to launch to engage with them). It might be your build and tests take a day to run (this also happened to me). Understand where your friction is and either accept it or plan to remove it.
- How quickly should we have been able to push out a trivial change? If you’re struggling then the best way to learn how to go faster is via doing simple things. Because, let’s face it, you won’t be able to take on complex work anyway. Get good at the simple things — they afford you the ability to run through more iterations in a shorter space of time. Every iteration is an opportunity to learn how to go faster.
Wind forward 12 months and that team was unrecognisable. Engagement was up, more features were being shipped, more value was being delivered. If you’re prepared to invest in this accept it’s something to commit to for the long haul because it’s a culture change not a band aid. But the culture change leads to everyone getting what they want — the product manager gets features, users get a rapidly improving stable product and engineers get to take pride in building things well.
I had another team that was running at close to 90% toil. Yet they were never given the space to step back and fix it. This meant unhappy product managers and unhappy engineers and unhappy business. They took 6 months to clear out their toil. In the process they fixed lots of things in the product anyway and learned how to put the foundations in place to deliver features more quickly. When they started picking up features again people were astonished at how much they could get done.
Those are just a couple of examples. If you aspire to be part of a great team either as a product manager or an engineer then you have to think of the capability of the team to get things done. Treat your team as a product you’re developing because — if you’re not investing in going faster then you’ll end up going slower.
No comments:
Post a Comment