In this article
Your manager asks you to lead a cross-functional initiative alongside your regular role. The work is important, the people involved are senior, and the problem is messier than anything on your current roadmap. Saying yes could give you the broader scope you have wanted. It could also turn you into the person who keeps a difficult project moving while your own commitments quietly become evenings-and-weekends work.
There is no perfect answer because both risks are real. Declining every ambiguous assignment can leave your work narrower than you intend. Accepting every one can make you dependable in ways that are useful to everyone except your own career.
For an experienced individual contributor, the useful question is not, “Will this be good for my growth?” Almost any unfamiliar work can be described that way. Ask instead: What capability will this assignment let me demonstrate, what authority comes with it, and what existing work will make room for it?
A stretch assignment deserves to be treated as a time-bound career decision, not as a vague favor to the team. Developmental-assignment guidance from the U.S. Office of Personnel Management describes this kind of work as a challenge beyond current skills, often involving new perspectives or leadership demands. That is a useful definition, but it leaves out the conditions that make the challenge worth accepting in a regular workplace: a clear outcome, enough decision-making room, and an ending.
Decide what you are trying to prove next
Experienced ICs often make a subtle mistake with stretch work: they begin with the assignment rather than the direction of their career. A director asks for help with a launch, a migration, a customer escalation, or a planning process, and the invitation itself feels like evidence that it matters.
It may matter. But it may develop a capability you already demonstrate while taking time from the one you need to make visible next.
Before responding, write one sentence that names the next level of work you want others to be able to recognize. Keep it grounded in work behavior rather than a title. For example:
- “I want to show that I can set a technical direction across two dependent teams.”
- “I want evidence that I can turn uncertain customer signals into a product decision.”
- “I want to become known for improving a system that affects reliability beyond my immediate area.”
- “I want to test whether program leadership is work I actually want to do repeatedly.”
That sentence gives you a standard for judging the offer. It also separates growth from accumulation. Helping organize an offsite, mentoring every new hire, or running the weekly status meeting may be useful work. It does not automatically create evidence of broader technical, strategic, or operational judgment.
This distinction can carry an unequal burden. In research on low-promotability tasks, Babcock, Recalde, and Vesterlund examined how requests and acceptance can shape who takes on work valued less in advancement decisions. The practical implication is not that anyone should refuse shared responsibilities as a rule. It is that reliable people should inspect recurring “can you just” requests more carefully, especially when the work has no visible finish line or ownership authority.
If you cannot name what the assignment will help you prove, you are not ready to call it a stretch assignment. You may still choose to help. Just describe it honestly as team service, crisis coverage, or relationship-building—and limit it accordingly.
Sort opportunity from coverage work
The same project can be developmental for one person and coverage work for another. Leading a customer-incident review might be a strong assignment for an engineer who needs to demonstrate systems thinking and influence across functions. It might be a poor fit for an engineer who has already done that work twice and needs protected time to establish architecture ownership.
Assess the assignment on four dimensions: the result it creates, the judgment it requires, the people who can observe that judgment, and the cost to your current commitments.
| Dimension | A stronger career case | A warning sign |
|---|---|---|
| Outcome | A defined decision, launch, operating change, or deliverable exists. | You are asked to “keep things moving” without a clear result. |
| New capability | The work requires a skill or scope you need to demonstrate next. | It repeats coordination, cleanup, or support work you already do well. |
| Authority | You can set an approach, make bounded decisions, or bring tradeoffs to the right decision-maker. | You are accountable for progress but must seek approval for every meaningful move. |
| Visibility | People who assess your scope can see your reasoning and the resulting change. | Your contribution is filtered through someone else’s updates. |
| Capacity | Something is paused, delegated, narrowed, or reassigned. | The assignment is added to a full workload as “just temporary.” |
| End point | A date or condition marks the handoff, review, or completion. | The work becomes a standing responsibility by default. |
You do not need every favorable condition. A short, high-stakes recovery effort may have little predictability but still give you useful evidence. A deeply technical project may have limited executive exposure but substantially expand your judgment. The problem begins when an assignment is weak on several dimensions and is still presented as a growth opportunity.
Be especially careful with work that is broad but powerless. “Coordinate across teams” can sound like leadership, yet it can mean chasing updates from people who have no reason to respond. Scope without authority produces a poor record: you carry the friction, while someone else owns the decisions.
Research on early-career engineers from the Stanford VMware Women’s Leadership Innovation Lab also points to an important limitation: unfamiliar assignments do not distribute opportunity evenly or create the same expected returns for everyone. Although that study focused on early-career engineers, its lesson applies more broadly. Do not assume that a manager’s use of the word “stretch” settles whether the work is well-designed for your development. Ask what the assignment actually allows you to do.
Negotiate the assignment as a bounded exchange
You do not need to turn a developmental conversation into a contract negotiation. You do need enough specificity that both you and your manager can later identify what happened.
Start from interest, then name the tradeoff. A useful response might be: “I’m interested because this would give me a chance to lead the dependency planning across both teams. To do it well, I’d need to reduce my ownership of the weekly reporting cycle and agree on what I can decide directly. Can we define those before I take it on?”
This wording does three things. It identifies the capability you intend to build. It makes capacity a work-planning issue rather than a personal endurance test. And it asks for decision rights before you become responsible for outcomes.
| Clarify | Question to ask | What a useful answer contains |
|---|---|---|
| The result | “What needs to be true by the end of this assignment?” | A concrete outcome and a definition of done. |
| Your role | “Am I leading the work, recommending a path, or supporting the lead?” | A clear account of who decides, who contributes, and who resolves conflict. |
| The audience | “Who should see the work and understand my role in it?” | The manager, sponsor, or review forum that can assess the contribution. |
| The tradeoff | “Which current responsibility should move, narrow, or pause?” | A named change to workload, not a general promise to be flexible. |
| The checkpoint | “When will we review whether the scope is still reasonable?” | A date before the work has become permanent by habit. |
| The exit | “What happens when this project is complete?” | A handoff, return to core work, or explicit discussion of an ongoing role. |
Managers sometimes cannot immediately remove work from your plate. That does not mean you must refuse automatically. It does mean you should make a different choice: accept a narrower version, set a later start date, or agree to support rather than lead. “I can own the decision memo by the end of next month, but I cannot also run the weekly operating meeting” is more useful than accepting both and hoping the workload settles down.
Be cautious about promises that depend on a future promotion cycle: “Take this on now, and we’ll see what happens.” A promotion may be unavailable even after excellent work because budgets, roles, and organizational priorities change. GitLab’s public engineering guidance makes a distinction many companies blur in practice: career coaching helps someone prepare for a future level, while a promotion process evaluates work already demonstrated. Your assignment can create evidence. It cannot substitute for a clear process or guarantee its outcome.
Run a 30-day evidence check
Once the assignment begins, avoid waiting until a performance review to discover that its scope changed. A stretch assignment can drift in two directions: it can shrink into administrative support, or it can expand until it crowds out the work that made you credible in the first place.
Set a short review point, usually after the first meaningful milestone or roughly 30 days. Bring a one-page record: the original outcome, decisions you made, obstacles you escalated, work displaced, and the next decision required. This is not self-promotion theater. It gives your manager something more useful than a general impression that you have been busy.
Progress monitoring is worth making routine. A large meta-analysis published by the American Psychological Association found that monitoring progress was associated with better goal attainment across the experimental studies reviewed. For career assignments, the relevant practice is modest: compare the actual work against the agreement while there is still time to change it.
If the work is on track, ask a forward-looking question: “What would make this contribution legible as evidence of broader scope?” If it has become pure coordination, use the checkpoint to reset: “The project now needs a dedicated program owner. I can continue as the technical decision-maker, but I can’t be both the coordinator and the accountable owner without moving other work.”
- Put the original outcome, end date, and your decision rights in one shared note.
- List one current responsibility that was paused, narrowed, delegated, or explicitly retained.
- Record decisions you made and the tradeoffs behind them, not only completed tasks.
- Schedule the review before the assignment reaches its first major milestone.
- At the review, decide whether to continue, narrow, hand off, or formalize the expanded scope.
Keep the assignment from becoming invisible permanent work
The final stage is easy to skip because the team is relieved the work is done. Do not let relief erase the record.
Close the assignment in writing. A short note to your manager can state the original problem, the result, two or three decisions you owned, the collaborators involved, and what you learned about the next scope you want. If the project continues, identify whether you are handing it off, retaining a defined piece, or discussing a formal change in role.
That last distinction matters. An assignment that was temporary in practice but never receives a handoff can become a hidden second job. You may decide the expanded role is worthwhile. If so, ask for an explicit conversation about role design, priorities, and how the work will be evaluated. Do not rely on the team to infer that a responsibility has become permanent because you have handled it capably.
The decision at the beginning was never simply yes or no. It was whether the opportunity gave you a credible way to demonstrate the kind of work you want next without quietly sacrificing the work you already own. Say yes when you can name the capability, obtain enough authority, make room in your workload, and set an endpoint. If those conditions are absent, ask for a smaller, better-defined version—or let this particular opportunity pass.
About the author Victoire BoucherCareer coach focused on helping women navigate the tech industry. I’ve worked in product and engineering roles before shifting to coaching full-time. Now I write about imposter syndrome, salary negotiation, and how to grow without burning out.
