A CEO says "can we ship this by March?" The CTO says yes. In March, it isn't shipped. Neither of them lied.
The CEO heard: will customers be able to use this in March? The CTO answered: will the engineering work be finished in March? Between those two sentences sits QA, store review, a migration, a support team that needs training, and a legal sign-off nobody owns. Everyone was honest. The date was still wrong.
I've been on both sides of this table — I ran a startup before I led engineering teams — and it is, more than any technical problem, the thing that quietly destroys roadmaps.
The four phrases that cause the most damage
- "Almost done." To an engineer: the hard part is solved. To an executive: the work is nearly finished. The remaining 10% of the hard part is routinely 50% of the calendar.
- "Just a small change." Small in the interface is not small in the system. Changing a currency field is one afternoon or one quarter, and nothing about the request reveals which.
- "It's technical debt." Heard as: the engineers want to tidy up. Actually means: a decision made under time pressure is now charging interest, and the payment is coming due whether or not it's scheduled.
- "We need to refactor." Almost always a symptom, not a request. Ask what it will make possible. If the answer isn't a business outcome, it's a preference. If it is, it's a roadmap item you've been mispricing.
Why it persists
Because both people are being rational. The CTO gives a technical estimate because that's the part they control and can defend. The CEO asks for a date because a date is what the board, the customer and the campaign all need.
Neither is wrong. But nobody in the room owns the space between the two — and that space is where every deadline dies.
Four fixes that actually work
Ask for the date something is in front of a user
Not "when is it done." When can a real customer do the thing? This single reframing surfaces every hidden dependency — review, migration, training, legal — because they all sit between code-complete and customer-usable.
Make the CTO state what they're assuming
Every estimate rests on assumptions: that an API behaves, that a third party responds, that nobody gets pulled onto something urgent. Written down, they become risks you can manage. Unwritten, they become excuses in April.
Translate technical work into a business sentence
Not "we need to migrate the database." Instead: "if we don't migrate by Q3, onboarding a customer over 10,000 seats will take three weeks instead of one day." Now the CEO can prioritise it against everything else, which is their actual job.
Separate the three questions you're really asking
- Can we build this? — almost always yes.
- What would we stop doing to build it? — the question people skip, and the only one that reveals real cost.
- What happens if we're wrong about the date? — determines whether you need a fixed window or a flexible one.
The tell that you have this problem
Estimates that are always roughly right at the task level and always wrong at the release level. That pattern means your engineers are estimating well and something between engineering and the customer is uncounted.
It is almost never a case of people working too slowly. It's a case of two people describing different finish lines and assuming they're the same one.
If you don't have someone doing the translating
Some companies have this person naturally — a technical founder who's carried a P&L, a VP who came up through engineering and stayed close to the business. Most don't, and hire around the gap without naming it.
That's usually where I come in. Not to write code that a good team could write, but to sit in the space between the two answers and make sure they're about the same finish line. The decision about whether to hire for that permanently is its own question.