Ambiguity is the real source of dev chaos
- YT :: https://www.youtube.com/watch?v=Nq3D8cnULHo
- Original title :: Deciphering Dev Chaos: A CTO's Ambiguity Playbook
Teams that look chaotic are rarely missing process or senior talent - they are absorbing unresolved business decisions that leadership never made. The fix is a small set of explicit artifacts that force those decisions into the open instead of letting engineering silently inherit them.
Ambiguity, not uncertainty, is the problem
Uncertainty is normal in product work - you learn by shipping. What actually causes chaos is negligent ambiguity: unclear customers, problems, trade-offs, ownership, and decision rights. When leadership doesn't resolve these, they don't vanish - they flow downstream and land on engineering disguised as an implementation detail. "Add this field," "make it flexible," "we need to move fast," "the user asked for it" are all business questions laundered into tickets.
Why estimates and architecture take the blame
Estimation in ambiguous work is really scope discovery, not forecasting - a 2-day UI change becomes a 2-week data-model change once a hidden decision (e.g. no source of truth) surfaces. Architecture absorbs the same problem as flags, adapters, and special cases pile up because a request's true long-term shape was never modeled. Incidents make the bill explicit: they expose whichever ownership and escalation questions the organization never answered while things were calm.
Creative ambiguity vs negligent ambiguity
Not all ambiguity is bad - creative ambiguity ("here's the problem space, here's what we want to learn") gives smart people room to explore and is how fast teams find the right answer by building. Negligent ambiguity ("build something, we'll decide what we meant after you ship it") is different, and the CTO's job is separating the two.
A simple ambiguity control system
- A decision ledger: what's the question, who owns it, when is it due, what's the current default - naming the default exposes the risk of inaction, which is itself a decision.
- A problem contract per request: who's affected, what's unacceptable right now, what signal proves the work helped.
- Recorded trade-offs (speed vs quality, flexibility vs standardization) so stakeholders can't silently optimize for different goals and let engineering "code the compromise."
- Explicit decision rights (RACI or simpler) - contributors can be many, accountability cannot; a decision with five implied owners has zero owners.
- Discovery spikes with exit criteria - unbounded discovery is procrastination, no discovery is gambling, bounded discovery is learning.
- Assumption reviews after the fact - did the user problem hold, did the signal appear - so the organization learns instead of repeating the same confusion under a new project name.
The takeaway
The point isn't slowing teams down, it's refusing to let motion substitute for progress. Developers can handle uncertainty but can't sustainably absorb unmanaged ambiguity from every other function. When a team looks chaotic, the diagnostic question isn't which tool would fix it - it's which decision everyone is avoiding.