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 recover the reasoning that produced the answer later, 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 at the moments when unfamiliar problems arrive, not from being told. 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. Escalation latency compounds with the number of unfamiliar problems they encounter.

And when the role gets reassigned (through departure, project rotation, leave), the reasoning behind 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 slower, 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 leaving the load-bearing decisions invisible: why this source first, what disqualified the previous lead, when to switch from reading to prototyping. The keystrokes are observable. The reasoning structure 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. Either way, the test is whether they can rerun it later on their own.

Artifacts that carry reasoning share a shape: they record what was tried before the working approach and what disqualified it. 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, not just the result.

What a runbook entry like that looks like in practice: a service returns intermittent 503s. The backend's own metrics were the first check, since a 503 usually means the proxy found no healthy upstream for a new request. The backend reported 100% success in the failing windows: the requests never reached it.

The 503s lined up with config reloads of the proxy in front of the service. Each reload briefly emptied the upstream pool, so new requests had no healthy backend to route to until it repopulated. That gap in the reload is the load-bearing detail, not the specific config that changed. 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, not its code.

The artifact has to let a teammate rerun the reasoning from cold, not from memory of the conversation that produced it.

In the real-time case, the signal that distinguishes co-reasoning from narrated learning is who's deciding the next question. The exchange to listen for: "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. Two moves belong after mitigation: pausing the response to let the team drive the next question, or choosing the pedagogical move over the faster fix. The teaching happens afterward, in the postmortem and the runbook update, where the cost of the slower path is paid in calendar time and not in customer impact.

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.