Overview
Growth needs real work
A stretch assignment is consequential work that requires a capability the engineer cannot yet demonstrate reliably. It should stretch one important dimension while providing enough authority, support, and safety for learning; it is not extra work piled onto a full job.
GitLab's career guidance describes development as structure plus individual initiative plus opportunity. Advice and training can prepare an engineer, but broader capability becomes credible through relevant situations and results.
The six-part opportunity brief
A safe assignment begins with a one-page brief that names the work and the learning system around it. This Growth OS synthesis keeps managers from delegating risk without context and keeps engineers from accepting vague hero missions.
| Part | Required answer |
|---|---|
| Outcome | What useful state should change, and for whom? |
| Stretch | Which single capability is less reliable today? |
| Authority | Which decisions, forums, information, and people are accessible? |
| Support | Who coaches, reviews, sponsors, or removes structural blockers? |
| Boundary | What scope, capacity, risk limit, and stop condition apply? |
| Evidence | Which outcomes, behaviors, and observations will be inspected? |
If “authority” or “boundary” is blank, the assignment is not ready. Accountability without authority creates a trap; ambition without a boundary invites unsafe failure or burnout.
Stretch one dimension at a time
An assignment becomes difficult through several dimensions: scope, ambiguity, stakes, technical novelty, relationship complexity, and time pressure. Increase one or two deliberately rather than maximizing all of them.
| Dimension | Current-safe example | Stretch example | Dangerous overload |
|---|---|---|---|
| Scope | One team | Three collaborating teams | Entire company with no sponsor |
| Ambiguity | Solution known | Problem clear, solution open | Neither problem nor success defined |
| Stakes | Reversible internal tool | Customer-facing pilot | Irreversible critical migration |
| Novelty | Known domain | One unfamiliar subsystem | New domain, stack, and organization |
| Relationships | Trusted peers | Two teams with different incentives | Hostile conflict plus unclear mandate |
| Time | Normal planning window | A meaningful deadline | Crisis deadline with no learning room |
Manager lens: reduce unrelated load before adding stretch and check whether less-visible engineers receive comparable access to consequential work.
Engineer lens: name which dimension is the intended stretch and negotiate the others downward. Declining an overloaded shape is risk management, not lack of ambition.
Build an opportunity portfolio
One perfect “Staff project” rarely exists. An opportunity portfolio is a sequence of real assignments that tests different capabilities and provides repeated evidence without forcing one project to carry an entire career transition.
Possible portfolio entries include:
- Resolve a consequential decision across two teams.
- Establish an adopted standard with an exception mechanism.
- Lead a time-bounded response to a hard ambiguous problem.
- Connect technical options to a business investment decision.
- Develop another Senior engineer to own a domain decision.
- Sunset a low-value initiative and redirect effort.
Sequence matters. A smaller cross-team decision can reveal support needs before the engineer receives a year-long transformation.
Add guardrails and checkpoints
Guardrails make failure survivable and informative. A checkpoint asks whether the assignment remains a fair test—not merely whether the schedule is green.
| Guardrail | Example |
|---|---|
| Scope boundary | Pilot with two services before broader adoption |
| Capacity boundary | Remove one existing ownership area for the quarter |
| Risk boundary | No irreversible data migration during the experiment |
| Decision review | Principal peer reviews the first decision frame |
| Escalation trigger | Manager enters if two directors cannot resolve incentives |
| Stop condition | Pause if reliability or team health crosses an agreed threshold |
At each checkpoint ask: Is the outcome still important? Is the intended capability actually being tested? Does the engineer have authority and sustainable capacity? What support or scope must change?
Worked example: from rescue to ownership system
A realistic example shows the difference between “harder work” and developmental work. Mei is the Senior engineer everyone calls during data-pipeline incidents; the intended stretch is creating cross-team ownership.
Unsafe assignment: “Fix data reliability across the company while staying on your current roadmap.”
Safe assignment: “Over 90 days, lead two producer teams and the platform team to define data-contract ownership and pilot it on the two highest-cost pipelines. Mei owns the recommendation and pilot; directors own staffing. Her manager removes weekly feature triage, sponsors the director forum, and joins if incentive conflicts remain after one documented attempt. Stop the pilot if incident severity increases.”
Evidence includes whether owners can respond without Mei, whether repeated incidents fall, how dissent was handled, and what mechanism survives the pilot.
When the assignment goes wrong
Poor outcomes need diagnosis before judgment. Separate engineer behavior, manager support, opportunity design, and changed context.
| Signal | Investigate | Response |
|---|---|---|
| Engineer is doing everything | Delegation behavior and owner capability | Coach delegation; name real owners |
| Stakeholders ignore the work | Mandate, incentives, and sponsor credibility | Manager repairs authority or changes scope |
| Work consumes nights | Capacity removal and risk boundary | Stop, reduce load, and redesign immediately |
| Project no longer matters | Business context | End the assignment without inventing performance failure |
| Engineer avoids the stretched behavior | Skill, confidence, and support | Give specific feedback and a smaller practice loop |
| Results are good but no learning is visible | Stretch may have been too small | Record strength and choose a different capability next |
Do not preserve a broken assignment to “test resilience.” Resilience is not silent endurance of preventable system failure.
Key takeaways
Stretch assignments build capability when real stakes are paired with deliberate containment and support. The manager and engineer jointly maintain the quality of the test.
- Tie every assignment to a real outcome and one intended capability stretch.
- Match accountability with visible authority, information, forums, and access.
- Remove capacity; do not disguise extra workload as development.
- Bound scope and risk, name escalation paths, and define stop conditions.
- Build a portfolio of increasing tests instead of waiting for one mythical next-level project.
- Evaluate opportunity quality separately from engineer capability and project outcome.
Practice: write and red-team an opportunity brief
This exercise converts a candidate assignment into a fair test. The engineer drafts it, the manager completes the organizational obligations, and a neutral peer tries to break it.
- [ ] Outcome has a beneficiary and matters now.
- [ ] Exactly one primary capability is being stretched.
- [ ] Authority is visible to affected stakeholders.
- [ ] Existing capacity is explicitly removed.
- [ ] Coach, reviewer, sponsor, and escalation owner are named where needed.
- [ ] Scope, risk, and stop conditions are explicit.
- [ ] Evidence includes outcomes, behavior, and corroboration.
- [ ] A changed or cancelled project will not be mislabeled as personal failure.
Red-team prompt: “What is the most likely way a capable engineer could fail because our assignment design is unfair?” Repair that condition before launch.
Sources
These practitioner sources ground opportunity, impact, and sponsorship principles; the six-part brief and safety model are course syntheses.