Reasoning the team can't rerun leaves with the engineer

Teams keep the reasoning they can rerun.

A team that watches conclusions arrive without the reasoning behind them learns to wait for the next conclusion. Months later, the team can run what exists and cannot extend it.

Capability transfers when the team can later recover the reasoning that produced the answer, without prompting from the person who produced it. The model gets built through real-time co-reasoning or encoded artifacts. It transfers only if the team can rerun it later, on their own.

Visible reasoning builds the team's model

A team's instinct for "what to try when nothing is familiar" forms from what they observe in moments when unfamiliar problems arise. When the reasoning isn't visible, the only thing observable is the conclusion, and conclusions don't teach a search procedure. The implicit lesson becomes: someone, somewhere, knows. The team's job is to find that person.

Every unfamiliar problem routes to the same place: the team has no model for what to try when nothing is familiar, so they wait for the model to walk into the room. Each unfamiliar problem adds another wait for that person, and the delay compounds.

And when the role is reassigned (due to departure, project rotation, or leave), the rationale for the existing work has to be rebuilt from scratch. The artifacts may still work: the system runs, the integrations execute, the runbooks pass their last validation. What's missing is the reasoning that would let the team extend any of it. The next requirement that doesn't fit the existing artifact restarts the same dependency loop.

Hidden reasoning has a structural source. The expert frame rewards immediate confidence: someone for the team to defer to at standup, a story the manager can tell. Show your reasoning, and you pay now: you look unfamiliar, the first integration ships more slowly, and the artifacts won't be valued for months. The frame optimizes for the moment of the hire. The team's capability pays the bill over the following year.

Surviving reasoning can be rerun

Watching someone Google in public isn't enough. Narrated searches put the act of searching on display while the decisions that steer it stay invisible: why this source first, what disqualified the previous lead, when to switch from reading to prototyping. The keystrokes are observable while the reasoning structure behind them stays private.

Reasoning the team can rerun is reasoning a teammate could reproduce without prompting. It gets built in real time, when the team drives what gets investigated next, or it gets captured in an artifact.

Artifacts that carry reasoning record what was tried before the working approach, and what disqualified each attempt. A reference integration names the decisions a future engineer will need to remake. Runbooks capture the symptom, what got ruled out and why, the load-bearing detail behind the fix, and the signal for related cases. Commit messages and design documents record the search behind the result.

A service returns intermittent 503s. The backend's own metrics are the first check, since a 503 usually means the proxy found no healthy upstream for a new request. The backend reports 100% success in the failing windows: the requests never reach it.

The 503s line up with config reloads of the proxy in front of the service. Each reload briefly empties the upstream pool, so new requests have no healthy backend to route to until the pool repopulates. That gap in the reload is the load-bearing detail. Which config changed is incidental. If a service fails intermittently while its own metrics look healthy, check whatever sits in front of it in the request path: the proxy or load balancer. The service's own code is rarely the culprit.

The artifact has to let a teammate rerun the reasoning from cold, from the record alone. The conversation that produced it won't be in memory.

In the real-time case, the signal that distinguishes co-reasoning from narrated learning is who's deciding the next question. "What should we try?" / "Try X." is the answer transferring. "I think it might be X because of Y." / "Test that." is the method moving. The keyboard can be wherever; what matters is who chooses the next question.

The test for both paths: can a teammate, without prompting, recover the reasoning behind a decision? If yes, the reasoning transferred. If no, the team inherited an answer.

Mitigation needs coordination before teaching

Incident response has one boundary here: teaching. Both teaching moves wait until mitigation is done: pausing the response to let the team drive the next question, and choosing the pedagogical move over the faster fix. The teaching happens afterward, in the postmortem and the runbook update, where the slower path costs only calendar time.

This principle is for the work that builds the team's baseline: the first integration of a new pattern that everything else will follow, the unfamiliar tool the team is about to adopt for the next decade. These are the moments that set the team's working model of how problems get solved, whether anyone notices or not.

Two questions tell whether the reasoning moved

When the role gets reassigned, does the next unfamiliar problem route to a teammate who knows what to investigate, or back to whoever now sits in the seat? If the work has to be redone, or routed back through the seat, the team learned to wait.

When existing work has to be modified (a new integration, a different context, a changed requirement), does the modifier reproduce the original reasoning, or cargo-cult around it until something breaks? If the artifact survived and the reasoning didn't, the team is running someone else's machine without the manual.

The team has the capability when both questions resolve to "they can." If no one can rerun the reasoning, the team inherited the answer, not the capability.