12 May 2026

When a CTO should refuse a roadmap request

A practical filter for technical leaders under pressure to accept every commercial promise without capacity to deliver.

Boards and sales leaders often present “small” feature asks as revenue insurance. The technical risk appears later: context switching, half-finished refactors, and a release train that never recovers.

A filter that travels well

Ask three questions before accepting:

  1. What existing commitment moves or dies if we take this?
  2. Which reliability or support burden arrives with the feature?
  3. Who owns the post-release learning loop?

If the requester cannot answer the first question, the request is not ready for engineering. Saying no is not obstruction; it is protecting the delivery promises already in flight.

Phrase the refusal as a trade

Replace “we can’t” with a written option set: delay by a quarter, reduce scope to a spike, or fund extra capacity. Document the chosen path. In advisory sessions we see fewer midnight escalations when the trade is visible to commercial stakeholders.

What this is not

This is not permission to dismiss customer pain. It is a habit of making capacity explicit so programming consulting conversations stay honest.


← All field notes