The Quarterly 90-Day Growth Contract

A growth contract is a written agreement about one capability, one real opportunity, the support each person owes, and the evidence they will inspect. “Contract” means mutual clarity rather than a legal promise, and 90 days is a bounded learning window—not a promotion deadline.

Quarterly planning prevents career development from becoming an annual retrospective. It is long enough to observe patterns across meaningful work and short enough to revise a poor hypothesis before it becomes a year-long assignment.

A usable contract fits on one page and names both engineer and manager obligations. The following structure is a Growth OS synthesis grounded in the opportunity-centered career guidance from GitLab and the impact language in the cited progression frameworks.

An outcome describes a meaningful changed state, while an activity describes motion. Growth requires action, but activity alone cannot show whether technical leadership helped.

Predefining evidence reduces hindsight bias, the tendency to reinterpret expectations after seeing results. Combine outcome evidence, behavior evidence, and corroboration instead of relying on visibility or a single metric.

For a cross-team reliability assignment:

• Outcome: recovery time and repeated incident rate.
• Behavior: decision framing, dissent handling, delegation, and ownership transfer.
• Corroboration: service owners can explain the decision and act independently.
• Context: roadmap changes or staffing losses that altered the original plan.

Evidence can disconfirm the plan. A good review may conclude that the problem was not worth solving, the assignment lacked authority, or another capability matters more.

Development fails when the engineer receives a stretch goal but no access, authority, or cover. Put manager actions in the contract so opportunity is treated as part of the system rather than a reward for already-visible people.

Manager obligations may include:

• Explain why the outcome matters and which constraints are real.
• Introduce stakeholders and state the engineer's mandate.
• Remove conflicting work so the assignment fits sustainable capacity.
• Observe at least one relevant meeting or artifact each month.
• Give prompt feedback grounded in behavior and effect.
• Sponsor the engineer for appropriate visibility and decisions.
• Escalate structural blockers the engineer cannot resolve.

Engineer obligations may include:

• Keep the outcome, risks, decisions, and evidence legible.
• Seek dissent and relevant stakeholder constraints early.
• Ask for support before hidden failure becomes a rescue.
• Delegate meaningful ownership and credit contributors.
• Reflect on behavior, not only project completion.
• Say when the assignment no longer tests the agreed capability.

The contract lives inside normal work and the fixed growth cadence. The standard 1:1 remains exactly 30 minutes with 10/10/10; its final segment checks one live question rather than reviewing the entire contract line by line.

A complete example shows how ambition and safety coexist. Jordan, a Senior engineer, wants to test Staff-scope direction across three developer teams.

A growth contract is a learning device, so changed conditions require revision rather than retroactive blame. Separate project outcome, observed capability, and quality of the original opportunity.

This one-page template is the working artifact for the quarter. Keep language observable and revise it when assumptions change.

# 90-Day Growth Contract

Engineer:
Manager:
Start / day 30 / day 60 / day 90:

## Growth hypothesis
I want to test [capability] because [evidence-based diagnosis].

## Real outcome and opportunity
For [beneficiary], change [baseline] toward [desired state] by [mechanism],
while protecting [constraint]. The bounded assignment is [scope].

## Evidence
- Outcome:
- Observed behavior:
- Corroboration:
- Context to record:

## Mutual obligations
- Engineer will:
- Manager will:
- Other support:

## Authority and boundaries
- Decisions / access:
- Capacity removed:
- Risk limit / stop condition:

## Review decision
Continue / deepen / redirect / stop, because:

The contract turns growth intent into mutual, testable work while protecting uncertainty. It complements local career processes rather than replacing them.

• Use one capability and one consequential opportunity per 90-day cycle.
• Define outcomes, behavior evidence, corroboration, and context before work begins.
• Write manager access, authority, sponsorship, and capacity obligations beside engineer actions.
• Review at days 30, 60, and 90 while using the weekly final 1:1 segment for small adjustments.
• Distinguish project failure, capability evidence, and opportunity quality.
• Never promise promotion in exchange for completing a growth contract.

This exercise turns the diagnosis into a fair experiment. Draft independently, reconcile together, then ask a neutral senior peer to test the logic.

• [ ] Outcome matters to actual customers, business, or engineering.
• [ ] Capability is an observable behavior, not a title adjective.
• [ ] Opportunity is real and bounded.
• [ ] Evidence includes result, behavior, corroboration, and context.
• [ ] Engineer has explicit authority and sustainable capacity.
• [ ] Manager actions have owners and dates.
• [ ] Stop conditions contain risk.
• [ ] Contract does not imply a guaranteed promotion.

Pressure-test question: “If the outcome changed for reasons outside the engineer's control, could we still make a fair statement about capability and opportunity quality?”

These sources ground the opportunity and impact principles; the seven-field contract, review rhythm, and examples are course syntheses.

• GitLab Engineering Career Development
• Monzo Engineering Progression Framework v4.1
• Dropbox Engineering Career Framework
• CircleCI engineering competency matrix