When I open a role, I expect some part of its current technical context to be obsolete before the person has finished onboarding. The service boundary may move. The evaluation stack may change. A workflow that is manual today may become the center of the product.
I therefore write the role from the next year of decisions. What outcomes must the team own? Which judgment currently depends on one person? Where can the team build a component but still fail to operate the result?
A useful hiring profile survives a change in the diagram.
Separate capacity from capability
A team can be short on hands or short on a kind of judgment. The remedies differ.
A capacity gap appears when the work is understood and the team cannot complete enough of it. A capability gap appears when the team cannot yet make or operate an important class of decision. Adding another generalist may help the first and leave the second untouched.
I write the gap as an outcome:
- we need an engineer who can turn model behavior into a reproducible evaluation;
- we need an owner who can trace a request through tools and external effects;
- we need someone who can design and operate a migration with state on both paths;
- we need a technical lead who can make cross-team failure ownership explicit.
These statements describe work the company needs. A list of technologies describes one possible route to it.
Mark what is stable
Some parts of the role should remain true even if the architecture changes. The user outcome, the operating responsibility, and the decision authority are usually more stable than the framework or service boundary.
| Stable | Likely to change |
|---|---|
| Outcome the engineer owns | Current implementation path |
| Failure classes they must diagnose | Observability vendor or data store |
| Decisions they may make | Service and team boundaries |
| Evidence expected before release | Evaluation tools and deployment process |
The job description should lead with the stable column. The changing column belongs in context so candidates can judge whether their current experience transfers.
Recruit for a missing point of view
Team composition matters more than isolated candidate strength. I ask what challenge the current team is least likely to raise.
A group strong in model experimentation may need someone who begins with workflow state and recovery. A platform-heavy team may need an engineer who stays close to the customer’s task. A fast-moving product team may need someone who can define a release bar and hold it during schedule pressure.
This does not mean hiring for disagreement as a personality trait. The useful addition is a person who can expose a missing constraint and still help the team reach a decision.
Test whether judgment transfers
The interview should use a problem whose surface differs from the candidate’s résumé while preserving the role’s underlying decision. Give the candidate a voice workflow whose scheduling call timed out after the request left the system. Ask what state must be recorded, which evidence would establish the external effect, and when a retry becomes unsafe. An engineer from payments may recognize idempotency. Someone from distributed storage may begin with state repair. The useful signal is how they transfer that knowledge and where they stop.
I want evidence that the candidate can:
- identify which prior experience applies and which does not;
- ask for the missing evidence before choosing a design;
- learn enough of an unfamiliar system to make one bounded decision;
- state where a specialist is still required.
This protects the hiring decision from a moving architecture. The company is hiring an ability to reason and operate, supported by technical depth, instead of buying familiarity with one diagram.
Define the first owned result
Before opening the role, I write the result the new engineer should own within the first months. “Learn the platform” is an activity. “By day 90, make one supported customer workflow observable from request through confirmed effect, then transfer its operating runbook to the team” is a result.
The result might be an evaluation that changes a release decision, a reliable path through one customer workflow, or a migration plan tested against production evidence. It should include access to the people and systems required to succeed. Hiring someone into a cross-team outcome without granting cross-team access creates a false assessment of the person.
The onboarding plan then becomes a test of the hiring thesis. If the engineer cannot reach the intended result, I examine the role design, authority, and available evidence before concluding that the candidate signal was wrong.
The hire is successful when the company can make a decision it previously could not make well and the team can operate what follows. That is the standard I want the role, interview, and first ninety days to test.