A chief architect who never touches the system can lose contact with its real constraints. One who takes every difficult implementation can become the constraint.
Technical ability is already assumed. The question is allocation: where will my direct work change the outcome, and what ownership will the team have after I stop?
Code to answer a decision
I am most likely to implement when the team is blocked on an uncertain technical claim that controls the architecture.
Examples include whether a model can meet a latency target under representative load, whether an external effect can be observed reliably, whether two sources can be reconciled without losing state, or whether a proposed boundary survives the main failure modes.
The code in these cases is an instrument. Its purpose is to produce evidence. I define the question before opening the editor:
- Which decision will this implementation inform?
- What result would reject the current plan?
- Which parts need production quality for the result to be credible?
- Who will own the artifact if it survives the experiment?
This keeps a spike from quietly becoming a production dependency with no maintainer.
Code where the interface needs proof
Some architectural arguments remain vague until one path works end to end. A reference implementation can force decisions about state, errors, authority, and observability that a diagram postpones.
I choose a thin vertical slice through the important boundary. For a tool-using agent, that might include one user request, one authorized action, one observable external effect, and one recovery path. The slice should be small enough to finish and complete enough to expose the contract.
The result belongs to the team. I document which choices are examples, which are requirements, and which remain open. A reference path should reduce disagreement. It should not turn my implementation preferences into hidden policy.
Step back when the problem is execution
Once the governing uncertainty is resolved, continued implementation by the architect can reduce throughput.
I step back when:
- the interfaces and operating outcome are clear;
- another engineer has enough context to make local decisions;
- the remaining work benefits from sustained ownership;
- my review can remove risk without taking the task;
- the team would delay decisions while waiting for my code.
The handoff should transfer authority. The engineer needs the intended result, the constraints, the evidence behind the current design, and the conditions under which they may change it. A task list without decision rights creates an implementer who still depends on the architect.
Avoid becoming the hidden escalation path
A chief architect can accumulate unofficial ownership by repeatedly rescuing difficult changes. The repository shows many contributors, yet the team knows that one person must approve the dangerous parts or repair the hardest failures.
This arrangement feels fast during the rescue. It becomes expensive when every consequential change waits for the same person.
I look for signals that my coding is creating dependency:
| Signal | Response |
|---|---|
| Reviews wait for implementation details only I know | Write the contract and review rubric. |
| Incidents route to me before the owning team | Transfer diagnosis tools and operating authority. |
| Engineers avoid changing my code | Pair on a real change and remove unnecessary cleverness. |
| I keep taking the central path | Assign an owner before the next design decision. |
| The reference implementation becomes permanent | Fund the production rewrite or adopt it deliberately. |
Use several modes of direct work
Writing a feature alone is one mode. Other forms of direct work can transfer context more effectively.
I can pair with the engineer who will own the result. I can write a failing test that defines the disputed behavior. I can instrument the system to expose the constraint. I can build a disposable comparison. I can review a critical path with the implementation open and make one targeted change.
Each mode has a different transfer cost. Pairing shares context during the work. A test leaves an executable contract. Instrumentation improves future decisions. A private prototype may produce evidence quickly but requires a deliberate handoff if retained.
I choose the mode that resolves the uncertainty and leaves the least avoidable dependency.
Define the exit before starting
Before writing code, I state when my direct involvement ends. The exit may be a measured result, a working vertical slice, an interface accepted by the owning team, or an incident returned to normal operation.
I also identify the next owner. If no one can own the artifact, that is a staffing or scope problem. My temporary implementation does not solve it.
Lines of code are a poor measure of architectural contribution. The useful measure is what changed: an assumption was tested, an interface became concrete, a failure became observable, or another engineer gained enough context to own the next decision.
I should stay close enough to test where the architecture is false. The next decision should still be able to proceed without me.