In every organization, there's tension between those who decide what to build and those who actually build it.
On the one extreme, there's the purely top-down plan. The alliance of business people, stakeholders, managers, and idea people say "jump", and the developers ask, "How high?". These demands are broken up into individual tasks that are assigned to the engineers.
The problem with top-down plans is that they are, by definition, out of touch with reality. Roadmaps get crammed full of features, but there is no guarantee that the team is actually working on what they should be working on. Top-down plans often live in a stakeholder slide deck but are considered a cynical joke on the work floor.
On the other side of the spectrum, there's the bottom-up plan. Developers decide what to build, and a plan gets distilled from this wild array of ideas.
Bottom-up plans have the annoying habit of getting nothing done. The teams keep adding tickets, and recency bias kicks in. All of a sudden, three months passed, and we still didn't start working on that crucial feature! These plans are out of touch with the market, investing time in the things nobody is asking for.
As usual, organizations are mainly distributed near the center of that spectrum. It's common for Business/Product to put features on the plan while developers are free to add tasks and technical tickets. Their plans are usually both top-down and bottom-up to a degree. They strike an implicit balance.
But this shaky equilibrium makes companies susceptible to the weaknesses of both styles. It can easily become a worst-of-both-worlds situation.
If developers can freely add tickets to the backlog, how do we ensure we stick to the roadmap?
If Product can push the priority of certain features, how do we guarantee technical debt gets cleaned up?
The best thing we can do is to make this balance explicit. When can we work on developer-created tickets? How can Product set priorities? If we spell out the rules, we can avoid a lot of frustration.
There are multiple ways this can be done.
We could reserve a percentage of the team's capacity for bottom-up tickets. 25% of all tickets on the board could be technical, for example. We could also organize a developer-driven sprint every few months. For these sprints, the engineering team would set the goal, not the PO. I'm sure you can come up with other ways to make this balance explicit.
If you're a regular reader of this newsletter, you know I like iterative buffer planning. This allows us to plan features top-down in focus blocks while using recovery blocks to carve out time for bottom-up planning. It's a straightforward way of making that balance explicit.
If your roadmap tells you the team should be starting on their Q3 work, but the backlog tells you they still need to finish some Q1 stuff, your plan is out of balance.
If your features are on track, but your product quality is falling apart at the seams, something is tipping the scales.
Implicit agreements are the enemy of good plans.
Spell them out.