When common sense prevails: why descoping might be the smartest move.
Thinking formed in practice, published as part of the Bearing & Course Points of View library.
When NASA needed a pen that could write in zero gravity, they reportedly spent millions engineering one. The Soviets used a pencil. The facts of that story are disputed, but the point it makes is not. Sometimes the smartest solution is the simplest one. Delivery culture rarely rewards that insight.
Most projects start with a clear purpose. As they move, that clarity tends to fade. Scope expands. Complexity accumulates. Features get added because someone thought they might be needed, not because there is evidence they will be used. Before long, teams are solving problems that were never properly validated, often for users they have not actually spoken to.
Part of this is psychology. Complexity gets equated with rigour. More features suggest more value. When uncertain, most organisations default to doing more. It feels like action. Saying no, or slowing down, can feel like risk. There is also a quieter pressure: the assumption that if something is not fully automated or digitally transformed, it is not good enough. But complete transformation is not always the right answer. Automation for its own sake creates problems as readily as it solves them.
The most effective leaders I have worked with can hold that tension. They know when to simplify, when to focus and when to leave something out of scope entirely. Not because it is unimportant, but because it is not the priority right now.
Before building, scoping or investing, the right questions to ask are simple ones that rarely get asked. Who exactly are we solving for? Is there actually a problem, or an assumption of one? How many people experience it and how significantly? Is the return on cost, experience or outcome genuinely there? These questions sound obvious. They are frequently skipped.
Every project comes with surprises. Found complexity is guaranteed: edge cases, legacy constraints, hidden dependencies, policy or regulatory requirements nobody flagged. Edge cases matter too: they reveal where systems fail the people who most need them to work. But edge cases cannot be allowed to shape the entire delivery. The skill is knowing when and how to address them without derailing the value for the majority.
Descoping is a leadership skill. It keeps work focused, avoids waste and stops teams from building elaborate solutions for problems that have not yet been validated. Sometimes the best move is to do less. Sometimes it is to wait. Sometimes it is to do nothing at all.
When common sense prevails, delivery sharpens. You build what is needed. You maintain less. You waste less. You earn trust because the people you are delivering for can see the connection between effort and outcome.
Complexity is not a sign of rigour. Sometimes it is a sign that nobody stopped to ask a simple question.