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, days or weeks later, without prompting from the person who produced it. That recovery happens through real-time co-reasoning, encoded artifacts, or both.

Visible reasoning builds the team's model

A team's instinct for "what to try when nothing is familiar" doesn't form from being told. It 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. Escalation latency compounds as the number of unfamiliar problems they encounter increases.

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, which 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. Externalizing reasoning carries immediate costs: visible unfamiliarity, slower delivery on the first integration, and time spent on artifacts that 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.

The reasoning the team can rerun is that a teammate could reproduce without prompting. It can live in real time as the team works through unfamiliar territory, driving what gets investigated next. Or it can live in the artifact.

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. First check was the backend's own metrics, since 503s often point upstream. The backend reports 100% success in the failing windows.

The 503s line up with config reloads of the proxy in front of the service; in this proxy path, the reload was closing in-flight requests before drain completed. That gap in the reload-drain sequence is the load-bearing detail, not the specific config that changed. If a service intermittently fails while its own metrics look healthy, check whatever sits between the load balancer and the service.

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 when the team's working model for solving problems is being set, 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 artifact, not the capability.