Choose a stretch assignment with support, not just more risk
Check the scope, authority, time, and review behind a development opportunity. Distinguish a useful stretch from unsupported responsibility.
A useful stretch assignment adds a specific unfamiliar responsibility within a supported boundary. Before accepting, agree on the result, decision authority, time, reviewer, and escalation path. More work without those conditions is not automatically development.
Leading one small cross-team change with an experienced reviewer lets you practise coordination. Being made responsible for every dependency without access or help gives you risk, not a sensible learning plan.
A stretch assignment should help you practise a capability you do not yet handle reliably on your own. It should not simply transfer an inconvenient problem to the person most eager to prove themselves. The difference is visible in the assignment’s boundaries and support.
Identify the one responsibility that is new
Ask what you are meant to learn. It might be identifying dependencies, leading a review, clarifying a requirement, or coordinating a small release. “Take more ownership” is not specific enough to guide either the assignment or the later evaluation.
Compare the new responsibility with work you already do. If the assignment changes the technical domain, the number of teams, the delivery pressure, and the decision authority at once, it may be hard to tell which difficulty you are learning to handle.
Barry O’Reilly’s Unlearn prompted the idea of testing changed behaviour in a bounded way. His public book introduction discusses changing previously effective approaches. Our assignment agreement below is a proposed workplace tool, not a claim that taking larger risks produces faster advancement.
Try the decision
A developer is offered ownership of a service they have never operated.
A stretch task becomes unsupported operational risk.
Next step: Clarify authority, time, review and escalation before accepting.
This is an illustrative decision with stated assumptions. It cannot establish your employer’s policy or predict an individual career outcome.
Inspect the support before accepting
Check five practical conditions: the result, your authority, available time, review support, and the escalation path. Each should be specific enough that you can recognise whether it exists.
The result defines what is included and excluded. Authority defines what you can decide and what another person must approve. Time defines which current work moves. Review identifies a person with relevant knowledge and actual availability. Escalation explains what to do when a dependency, risk, or missing decision exceeds the agreed boundary.
These are not administrative details around the learning. They determine whether the learning opportunity is workable. A named mentor with no time is not available review. Responsibility for a decision you are forbidden to make is not autonomy.
The stages of end-to-end ownership can help identify hidden responsibilities. The estimation guide helps distinguish an uncertain task from a confident but unsupported deadline.
Turn the opportunity into a bounded agreement
In an illustrative example, an engineer wants experience coordinating across teams. They are offered responsibility for upgrading a shared test library in two services. The technical changes are familiar; coordinating different owners is the deliberate stretch.
The agreement names the two services, the intended compatibility checks, the owners who must approve the changes, and a senior engineer who will review the coordination plan. The engineer can organise the work and recommend sequencing, but cannot override either service owner’s release decision.
The manager removes another planned task to create capacity. The team agrees an early checkpoint after the dependency review, not only a final judgement after delivery. If another consumer appears or the upgrade exposes a wider issue, the scope is reconsidered rather than silently expanded.
A concise acceptance might be: “I can lead the coordination for these two services, with this review support and this work moved. I will bring unexpected consumers or incompatible requirements back to the owners before extending the plan.” This demonstrates responsible initiative without pretending the engineer controls everything.
Recognise unsupported responsibility
Be cautious when the assignment is called a growth opportunity but nobody can explain its boundaries, provide necessary access, or name a reviewer. Be equally cautious when the work keeps expanding while the promised development conversation keeps moving.
Ask whether the assignment is temporary learning, a permanent change of role, or cover for an unfilled position. These arrangements have different implications. Discuss expectations and recognition through the appropriate process rather than assuming extra responsibility will automatically lead to a title or compensation change.
A stretch should not require bypassing safety checks or making commitments beyond your authority. It also should not depend on hidden overtime. Use a clear trade-off conversation when the assignment conflicts with existing work.
You can ask to reduce the scope or decline an unsupported assignment. That does not establish that you lack ambition. The relevant question is whether the conditions let you learn and deliver responsibly.
Review both the result and the learning
At the checkpoint, inspect the work and the conditions. Did you identify the right owners? Did you surface a dependency in time? Did the reviewer provide the promised help? Which decisions can you now handle with less support?
A delivered change is not the only possible learning result, and a delayed change does not automatically mean the learner failed. Separate your actions from missing access, changed requirements, and other conditions. Equally, do not use those conditions to avoid examining a decision you could have handled better.
End with the next suitable boundary. Perhaps you can coordinate another change of similar size independently, or you need another supported attempt at identifying dependencies. Use a development one-to-one to make that next step explicit. A useful stretch produces clearer capability, not merely a longer list of responsibilities.