When we have learned to work in a project-based way, planning can easily become something a few people do for others. A leader or expert, perhaps together with a few others, thinks through the work, creates the plan and prepares it for others to execute.
This can feel like an efficient use of people’s time. Why involve people before their expertise is needed, or have them spend time in discussions where they may have little to contribute?
And sometimes this is exactly the right thing to do.
If we are not operating in complexity, the problem may be understood well enough, cause and effect sufficiently predictable and existing expertise enough to determine a good solution. A technical specialist may be perfectly capable of planning a technical change, just as someone with deep testing expertise may be the right person to design a particular test approach. Not every decision benefits from involving the whole team.
The trap appears when we use the same planning logic while operating in complexity.
Complexity may come from the problem itself, technology, customer behaviour, organizational dependencies, competing needs or a changing environment. In these situations, we cannot know everything we need to make good decisions upfront. Some knowledge is distributed across different people and perspectives. Some simply do not exist yet. It emerges as we interact, experiment and learn.
When people start thinking together, someone may know something about the customer that changes how others see the problem. A developer may see a simpler possibility. Someone spots an organizational dependency. A question exposes an assumption nobody realized they were making. And very often someone says: “Wait – I didn’t know that.”
This is not a failure of preparation. It is learning happening. We are not simply sharing what we already know. We are creating new understanding together.
In complexity, this makes it difficult to separate planning neatly from execution. Execution itself creates knowledge. The more detailed decisions we make upfront, the more decisions we make before that knowledge exists.
One place this becomes very visible is the backlog. Work for a long time into the future is planned ahead and sometimes even planned into sprint buckets; Sprint 1, Sprint 2, Sprint 3 and several sprints beyond. It looks very different from a traditional project plan, but the underlying logic can be surprisingly similar: a few people have decided in advance what many people will do later.
Thinking ahead is not the problem. The problem is deciding too much before the learning that could change those decisions has happened.
The Planning Efficiency Trap: Moving from project planning to sprint planning can leave the old planning logic intact — in the name of efficiency.
The answer is not to have the whole team plan everything further ahead. That would simply spend more people’s time making decisions when knowledge is at its lowest. Instead, bring the relevant perspectives together when the thinking matters, as close to execution as reasonably possible. What we learn today should be allowed to influence what we decide tomorrow.
So the useful question is not whether planning should be done alone or together. Ask instead: Can we make this decision from what we already know, or do we need to learn our way towards it?
There is a longer-term consequence too. When a few people repeatedly do the thinking and others execute their plans, the team gets fewer opportunities to understand the product, challenge assumptions and develop its own ability to navigate complexity. Planning together where learning matters is therefore not only about making better decisions now. It gradually builds the team’s ability to make better decisions without someone else having to make those decisions for them.
That is the Planning Efficiency Trap. In complexity, we may try to make planning more efficient by involving fewer people and making more decisions upfront, precisely when we have the least knowledge to make them.
More traps
The Negotiation Trap in Prioritization is one of several traps in the series Traps when moving from projects to product teams.
See the bigger picture
The Planning efficiency trap is one example of what can happen when we change the way we work without fully changing the underlying logic.
Our Project vs Product Organization in a Nutshell poster explores this shift from several perspectives — including strategy, execution, governance, teams, funding, culture and organization.
