after we build · part ten · resistance and maturity
What resistance looks like
Resistance to the chain is not irrational. It is the team's honest response to being asked to do more work. The resistance has predictable forms, and each one has a real concern underneath that deserves a real answer.
"We don't have time for discovery."
The real concern: the delivery schedule is tight.
The answer: discovery that is skipped does not reduce cost, it transfers it to rework at 3-5× the price. Run one cycle with discovery and one without. Compare the rework.
"The brief is too much process."
The real concern: the team has been burned by process that added overhead without adding value.
The answer: the brief is not process. It is the document that tells you whether the thing you're building is the right thing. If it feels like overhead, it's probably too long. Shorten it.
"We already know the problem."
The real concern: the team has domain expertise and feels observation is redundant.
The answer: the Kelev example. A team that knew veterinary software built the wrong booking system because they never watched a receptionist work. Expertise is not observation. Both are needed.
"Predictions are guessing."
The real concern: being held accountable for a wrong guess feels punitive.
The answer: a wrong prediction is the most valuable outcome. It tells you exactly where the model needs updating. A prediction not checked is the only one with no value.
What maturity looks like
A mature team — three to five cycles into the practice — does not experience the chain as a process. They experience it as the way they think about work.
- The PO naturally asks "who have we watched?" before writing a brief.
- The developer naturally asks "which scenario does this test?" when writing a test.
- The designer naturally names states for what the person experiences.
- The retrospective naturally traces to levels, not people.
The chain becomes invisible. Not absent — invisible. The practices are habitual. The artifacts are automatic. The conversations are shorter because the shared vocabulary is already there.
The client notices not the process but the result: the software fits more precisely, the surprises are fewer, the conversations about what to build next are grounded in evidence rather than opinion.
That is the goal. Not five volumes of visible process. Five volumes of invisible discipline — where the understanding travels faithfully because the team has made it habitual to protect it.
Enough to know the chain is alive.
At least one cycle has been run with prediction + check. At least one practice from the sequencing list has been added. At least one model update has been written. The team can name what is mature, what is still draft, and what is gap.