Convergence

Somewhere on your team, somebody has already solved a problem the rest are still living with: a skill that makes review faster, a pattern that keeps agents on the rails. Convergence is the discipline of turning that solo win into team practice: surfacing it where everyone can see it, packaging it so others can pull it in, and making it cheap enough to try that saying yes costs an afternoon.

When a good change propagates, skills travel across your repos and the tooling starts compounding: tools that build tools. The improvement outlives the person who found it, and the next hire inherits it instead of rediscovering it.

The discipline takes its name from the framework's diverge-then-converge principle. The principle names the posture: let people explore, then fold what works back in before everyone's practice drifts apart. This discipline is that posture at team scale: engineers experimenting on their own is the divergence, and Convergence is how the team closes the loop.

Exploratory

Improvements stay in the head of whoever found them. Nothing is shared or tried widely.

Enables

The person who improves gets the benefit at no coordination cost, and which of their wins others reach for on their own tells you which are worth spreading. That is what propagation later gets pointed at.

Deficiencies

Wins stay siloed, the same lesson gets re-learned, and there is no path from one person's change to team practice.

Cost to maintain

Re-paying for improvements that never propagate.

Expert-led

One person shares their wins informally and others copy them when they notice.

Enables

Some spread. The people close to that person pick up what works.

Deficiencies

A single point of propagation, sharing that is ad hoc, and opt-in that depends on being in the right channel.

Cost to maintain

Their time evangelizing, on top of the work itself.

Documented

A sharing ritual runs, a retro or a demo, and adopting what a teammate built is deliberately made easy.

Enables

Changes reach the team rather than one corner, what is available to try is visible to everyone, and convergence happens by agreement.

Deficiencies

It still relies on the ritual running and people choosing to opt in, so a win lags before the team adopts it.

Cost to maintain

Holding the ritual and curating the shareable artifacts.

Structural

Sharing and propagation are built into the everyday tooling. A proven change reaches every project with easy opt-in by default.

Enables

Convergence without manual copying, trials and opt-in built into the system, and improvements that compound.

Deficiencies

Automated propagation can spread noise as signal, and it needs guardrails on what auto-adopts.

Cost to maintain

Building and tuning the propagation, plus reviewing what it spreads.

Convergence rarely stands alone. Where it overlaps a sibling discipline, an investment on one side quietly depends on the other. The Improvement domain page lays these out in full.

• Convergence and Prioritization

  Prioritization decides which change earns the team's energy; Convergence gets that change out of one head and into everyone's workflow. Pick the right bet and never converge on it and you have a correct decision quietly decaying unused, re-earned by hand each time someone new needs it. Converge hard with nothing ranking what spreads and you propagate whatever got tried last, noise moving as fast as signal.

  Held together, they are the difference between a good idea becoming standard practice and a good idea becoming a story about the one engineer who had it figured out.

• Convergence and Evaluation

  Convergence is a multiplier, and a multiplier only helps if what it multiplies was worth spreading. Evaluation is the check that makes that call: it holds a change against a real standard of good before the team commits to it everywhere.

  Without that check, Convergence works perfectly on the wrong input, rolling out to every repo the change that merely felt faster, and the better your propagation the wider that mistake travels. The point of running them together is a team that standardizes on what was proven, not on what demoed best last week.