The Cost of Starting Over

Posted by Anders Toxboe on July 21, 2026 · 5 mins read

---

Most organizations don’t struggle because they have too much work. They struggle because they repeatedly lose momentum. Every few weeks they pause, regroup and synchronize before moving forward again. Product explains what it has learned. Engineering tries to understand what it will build next. Leadership revisits priorities. New questions emerge, old assumptions are challenged and by the end of the meeting everyone finally feels aligned. We accept this rhythm as a normal part of knowledge work, but it’s worth asking a simple question: why does the organization keep needing to rebuild the same shared understanding before it can continue?

One of the central ideas in Eliyahu Goldratt’s The Goal is that the objective of a factory isn’t to maximize the output of every machine. It’s to keep work flowing through the entire system. To explain why that matters, imagine a factory producing bicycles. One machine builds wheels, another builds frames and another assembles the finished product. If the wheel machine keeps producing thousands of wheels while the assembly line isn’t ready for them, those wheels simply accumulate in a warehouse. Manufacturing has a name for this: inventory. Inventory isn’t inherently bad because it’s made of wheels. It’s problematic because it’s work that has already been completed but has stopped moving through the system.

Knowledge organizations don’t have warehouses full of wheels, but they experience something surprisingly similar. Instead of accumulating physical inventory, they accumulate interruptions to understanding. Work pauses while teams wait for planning, governance meetings, approvals or refinement sessions. During that time, the shared understanding that once existed begins to fade. By the time everyone gathers again, they aren’t simply deciding what to do next. They’re rebuilding the context that allows meaningful decisions to happen in the first place. Unlike a warehouse full of parts, you can’t point at this inventory on a balance sheet, but the effect is remarkably similar. Flow has stopped.

Once you start looking at planning through this lens, many familiar practices begin to feel different. Think about how many planning sessions begin. Engineers ask why the customer problem matters. Product explains what it learned during discovery. Designers walk through a proposed solution. Technical constraints emerge. New alternatives are suggested. Only after all of that does the conversation shift toward implementation. None of these discussions are wasteful. In fact, they’re often the most valuable part of the meeting. The interesting question isn’t whether those conversations should happen. It’s why they all need to happen at exactly the same time.

If planning is where engineers first understand the problem, then planning is performing two very different jobs simultaneously. It is creating shared understanding while also coordinating execution. Those activities place very different demands on people’s attention. Building understanding benefits from time, repetition and gradual exposure to ideas. Coordinating execution benefits from clarity and decisions. When both happen in the same meeting, planning becomes heavier than it needs to be because the team is trying to create the foundation and build on it at the same time.

This became much clearer to me after hearing an engineer say they wished they knew more about what they were likely to work on next. They weren’t asking for earlier tickets, detailed specifications or implementation plans. They simply wanted enough context for their subconscious to start working on the problem. Good engineering rarely begins when someone opens an IDE. It begins much earlier, when a technical constraint suddenly connects with something heard in a customer interview, or when a design sketch reminds someone of a solution to a completely different problem. That kind of thinking can’t be scheduled into a two-hour planning meeting. It needs time to develop.

Shared understanding behaves differently from documentation because it isn’t something that can simply be stored until it’s needed. Documents wait patiently. Understanding doesn’t. It grows through continuous interaction between people. A customer conversation changes how someone interprets a technical discussion. A technical discovery reshapes the product problem. A design exploration influences what questions are asked during the next customer interview. Every conversation reinforces the previous ones. When those conversations continue, understanding compounds. When they stop for weeks at a time, the organization doesn’t merely pause progress. It gradually loses the shared context that allows work to flow smoothly.

This is why I’ve stopped thinking about planning as the place where teams build shared understanding. I now think of planning as the place where you discover whether enough shared understanding already exists. If planning spends most of its time rebuilding context, then the organization hasn’t maintained understanding between cycles. It has allowed it to cool down and is now investing significant effort heating it back up again. That repeated restart is the real cost, not because planning is inherently inefficient, but because rebuilding almost always costs more than maintaining.