I once fixed a project without writing a single line of code.
Early in my career, consulting for a large international bank client. They came in with a detailed brief: an hour of requirements, very clear on what they wanted built.
I had enough domain experience to sense something didn’t fit. So I asked questions. Not about how to build it, but about the problem the build was supposed to solve.
Twenty minutes later, the real need surfaced. It was different from the stated ask. The solution was already in the system. Zero new engineering. The client called it the most productive session of the project.
The CTO-CEO relationship breaks the same way.
The CTO flags a critical refactor. Months of work. The CEO hears “slow down.” The CEO needs a feature shipped by Q3. The CTO hears “technical debt doesn’t matter.” Neither is wrong, but neither has stopped to check whether they’re looking at the same problem. The result: parallel conversations that compound into misaligned roadmaps, frustrated teams, and decisions built on incomplete frames.
The most expensive work an engineering team does is the work that answers the wrong question.
It’s not usually a skills gap. And it’s not a communication style issue — the most common assumption when this pattern surfaces. It’s a conversation that moved too fast from “what do you want” to “how do we build it,” skipping the step where you ask “what do we actually need?”
That pause is the work. It doesn’t slow things down. It’s the only thing that stops you from building the wrong thing at full speed.
I’ve seen this pattern across Booking.com and a 120-engineer platform org at TomTom serving 1,500 developers, and in conversations with early-stage founders. The leader who can hold that pause, reframe before the team starts building, changes what gets built.
When did you last stop a planning conversation to check: are we solving the right problem?
The answer tells you more about how your organisation makes decisions than any retrospective will.