With development, demand always exceeds supply

A founder friend now runs a tech company approaching about 100 employees. It’s just big enough to have different departments: different business units, marketing, operations, customer service, etc. And like any tech company, there is a scarce amount of product development time.

With so many departments, how to allocate dev time?

The question my founder friend put to me was: how do we allocate development time?

It’s a major issue for any tech company that is big enough to have multiple departments. Companies will typically start to feel this pain at about something like 20 employees. And it magnifies with growth.

Don’t hold arm wrestling matches

The typical approach is to have a meeting every week or two where representatives from each department come together. Each person argues their case.

This becomes a series of arm wrestling matches. Essentially Person A has to out-argue Person B to get their work done.

This is a crappy of way of getting development decisions made.

• The judge (a product manager, a C-level decision maker or a committee) cannot understand the minutiae well enough to weigh up a Small-Change-for-Marketing vs Medium-sized-Feature-for-Operations
• A boatload of effort goes into lobbying each other, rather than solving actual problems for the business. It’s unproductive
• Small-but-impactful work doesn’t get done. Experienced product people know the crazy value that can come from making small changes. But small changes don’t sell as well as dramatic features and changes

How to do it better?

Allocate entire sprints to different departments, not many small chunks of time

At the start of every quarter, the management team should simply allocate sprints to the different departments. Essentially they make a macro investment decision and not get stuck into the minutiae of every feature request.

For example, pretend the big aim this quarter is to boost customer acquisition. With single dev team running 2 week sprints, in a quarter, you have about 6 sprints to play with.

Your big decision: of the 6 sprints, how much goes to each department? For example:

• 3 sprints (1/3rd of the total amount) goes to marketing, since they’re going to be driving customer acquisition
• 2 sprints goes to operations and customer service who likely need some upgraded tools to serve a large inflow of new customers
• 1 goes to paying down tech debt and re-factoring systems that have been on the verge of collapsing

The management team should also set a schedule for the quarter, so each department can see when their sprints are coming up.

By doing this resource allocation decision at a macro-level once a quarter, the management team eliminates the arm wrestling that would otherwise happen over every single bit of dev work.

Let each department decide what to do with their sprints

Another key element of this approach is that each department can decide what to do with their sprints. Some teams will fill them with a host of small fixes and changes (anyone who has a run a back-office ops function will probably understand this). Others will go for major features.

When sprints are being allocated, a department may give an idea of how they would spend their budget. But they shouldn’t be beholden to it. Plans change. Shit happens. Each department lead will know at the time their biggest priorities.

Support each department lead with a solid product manager

Different department leads will have different levels of tech and product savviness. The product managers at the company need to work with department leads to refine their priorities. This has to be done ahead of their sprints.

By the time the department’s sprint is due to start, a product manager should have worked with the department to figure out what they need to have designed and built. This means understanding the department’s area of the business, stress testing priorities, getting rough sizing of effort involved, figuring out if the work can be simplified, understanding the relationships with other parts of the business, etc.

Departments are free to do deals with each other

With this approach, departments will figure out how to do deals with each other. They might swap sprints, because the scheduling better suits each other. They might agree to share sprints, especially if one department needs more design work done, while the other really needs build.

Or sometimes, something goes wrong and a feature doesn’t get finished within the planned sprint. In this case, a department lead might make a deal with the following department to get more time to finish the feature.

This sort of cooperation makes this approach work much more smoothly – and is very straightforward compared to the arm wrestling matches.

Remember the bugs!

Bugs suck and they emerge at inconvenient times. My favoured approach for bugs is to leave space in every sprint to fix them. While big bug weeks can help clear a backlog, realistically, it is difficult to ignore bugs altogether in the meantime.

Every department has to understand that if something major blows up in another part of the business, it has to get fixed even if it’s their sprint. Having some ground rules on what is an urgent, important bug and a clear idea of who is the final judge will save a lot of internal arguments.

How you know you’re doing it right: minimal internal lobbying

If you frequently find yourself in a meeting with lots of people playing a zero-sum game against each other, you can be pretty certain something is broken in your approach to making development decisions. When you have it right, the energy put into zero-sum games will go into solving real customer issues.

---

GS Dun builds new ventures and products, such as CakeAB, the easy-to-use pocket calculator for AB tests. Our name is short for “get sh** done”, so while we can talk the talk, we prefer to keep our meetings short and just get on with it.