Right-sizing product and engineering teams

So, you just raised a big round. After the effects of the champagne wear off, you turn to your first order of business: growing your product development team, so you can make even more great stuff that customers love.

You now have a big question to answer. How much will you grow engineering, and how much will you grow product? For some, this might be when they’re hiring their first PM. For others, their twentieth. Then again, perhaps the money would be better spent on getting that hairy codebase in shape for the next big push.

More broadly, over the whole lifetime of your company, you will have to answer this fundamental question: what balance will you seek between the disciplines of product and engineering?

If you prefer a video, here’s one. Otherwise, read on.

Magic ratios

Most people trying to answer this question invoke the idea that there is a magic ratio between product managers and engineers.

There are three objections to the ratio approach. The first is that it is one-size-fits-all, and so unlikely to be optimal for our setting. The second is that such ratios are regularly calculated from questionable data. The third is that by focusing on engineering and product management, they ignore the equally important roles of research and design.

So here, instead, is a simple and powerful idea for rightsizing your engineering and product teams.

Create ideal state at the same rate it is consumed

Our goal is to create ideal state at the same rate it is consumed. In this framing, our resourcing strategy is all about continually adjusting to keep these two processes in balance.

This is based on the observation that there is no value in discovering solutions that are never delivered, and no value in delivering solutions that haven’t emerged from discovery (since the whole point of discovery is to prove something is worth building).

Say a genie comes to you and says they will instantly change your product to be whatever you want it to be. Your product’s ideal state is whatever you would wish for in that moment. It represents the sum of all the product discovery you’ve done pursuant to your current goals.

Of course we don’t have a genie, but our team does have engineers. And by turning these ideas into reality, our team consumes our stock of ideal state. If we go fast enough, we can even exhaust it.

So if we agree we need to match the pace of discovery and delivery, it remains to be seen how to do that.

If you can’t measure it, you can’t change it

One thing we could try is a quantitive approach to comparing the pace of discovery and delivery. We could count the number of customer problems we identified, prototypes made, tests run, tickets closed and releases deployed. Then we could work back from there to understand how many more people we should allocate to each process.

Unfortunately, on closer examination this doesn’t make sense, since the discovery time of an individual piece of work will often not relate to the time it takes to deliver.

An alternative is to give up on the project of measurement entirely and instead monitor the system for signs that the balance needs correction.

Hyperdiscovery and hyperdelivery

This “productive equilibrium” has two failure modes, “hyperdiscovery” and “hyperdelivery.” At any moment in time every organisation on the planet has at least a mild case of one or the other of these, and it’s usually easy to tell which.

If we are discovering work to do faster than we’re delivering it – that is, living in hyperdiscovery – our team will start feeling like a talking shop. People will start wondering what point there is in having ideas, since we already have so many great ideas we haven’t got round to building yet.

On the other hand, if we are delivering work faster than we are discovering it – hyperdelivery – our team will start running on guesswork. People will start wondering what point there is in thinking critically about things, since we are committing so much time to work that has not been proved to be worth doing. This is often the telltale sign that more product people are needed.

In both failure modes, there are many other factors to consider other than the volume of people within product and engineering. What is often really happening in supposed cases of hyperdiscovery, for example, is that ideas are being validated too flippantly. In another example, hyperdelivery can be caused by the goal posts being moved too often, rendering previous discovery work less useful.

But understanding whether we are currently in hyperdelivery or hyperdiscovery is a good starting point, and a good place from which to make growth decisions.

Last words

Creating ideal state at the same rate that it is consumed maximises the efficiency of product development organisations. Measuring these rates relative to each other is difficult, but it is usually easy to determine whether creation or consumption are leading. A diagnosis of “hyperdelivery” or “hyperdiscovery” is a good jumping off point for discussions about resourcing.

A final cautionary thought is that – as Rolf Dobelli is fond of saying – humans tend to overemphasise the importance of set up vs. continual course correction. Even within individual cross-functional teams, the balance required between different disciplines will change substantially as their products evolve. When you consider the impact of these small shifts to the scale of hundreds of such teams, it becomes clear that correctly resourcing is not a trivial problem. But by focusing on ideal state generation and consumption, it is one that can be readily grappled with.