Career Goals and Progression Questions

Direct answer

At the next level the shift is from executing well defined work to owning the definition of the work itself, making calls that currently need someone else's approval, and being accountable for outcomes beyond your own output. The honest test of a good answer is naming a specific decision type you don't yet own, not describing a vaguely bigger job. What would actually change is which decisions route to you first instead of to your manager, and which outcomes you're accountable for even when you didn't personally do the work.

Structured elaboration

Name the current boundary. State plainly what you own today: you execute assigned work reliably and flag risks, but calls above a certain size still route through your manager or a review.

Name the specific decisions that would move. Pick concrete decision types, not scope words. Sign-off on a class of technical or design trade-offs, direct negotiation of priorities with adjacent teams instead of relaying through a manager, representing your area in reviews without a chaperone.

Choose a credible vehicle. A few common paths show you've thought about mechanism, not just outcome: becoming the domain lead for a defined slice, the person others route decisions to for that area; taking a Tech Lead step, coordinating technical direction before any title changes; or demonstrating staff level individual contributor (IC) leadership without a manager title, driving cross team outcomes through judgment rather than headcount.

Build the evidence trail. Decision rights expand when you have a record of good decisions under less oversight. Volunteer for ambiguous problems, document your reasoning so it's auditable, catch your own mistakes before someone else has to.

Expect the time mix to shift. As scope moves toward you, your week shifts from mostly delivery toward more judgment calls, review, and framing problems for others, often the first visible sign the scope changed before any title does.

Worked example

"In my current role I own execution well, but any decision affecting another team's roadmap still gets escalated to my manager. Two teams kept colliding on the same shared dependency, and each time it went to my manager to referee. Instead of saying someone should own this, I proposed taking the domain lead role for that shared area for one planning cycle, gathering both teams' constraints and proposing the trade off myself, escalating only if we couldn't agree. My manager agreed to a trial. I ran two of those conversations, documented the reasoning each time, and by the end of the cycle both teams were routing that kind of conflict to me directly. That's the evidence I'd bring into a scope conversation, not that I want more responsibility, but a specific decision I already made well, repeatedly, without oversight."

Trade-offs & pitfalls

• Describing scope growth as more of the same work reads as ambition without a plan.
• Picking a vehicle that doesn't match your organization, pushing for a formal Tech Lead title in a flat org that doesn't use that ladder, wastes the conversation on semantics.
• Conflating volume with scope. Taking on more tickets is not the same as gaining authority over a new kind of decision, and a reviewer notices the difference immediately.
• Overclaiming scope you can't back with a track record invites the exact pushback (show me you've done this already) that a demonstrated vehicle avoids.

Direct answer

Don't argue the premise. Reframe scope as breadth of impact rather than headcount of teams touched, surface concrete evidence that your depth already produced value beyond your immediate team, and pair it with a dated, checkable plan for closing whatever gap is real.

Structured elaboration

• Separate whether the pushback is right from whether it's complete. Even genuinely deep, narrow work usually throws off reusable artifacts, informal mentoring, or unsolicited cross-team requests, find and name those rather than assuming the panel has the full picture.
• Categories of scope evidence beyond team headcount: tools or practices other teams adopted from your work, standards that outlived the original project, unsolicited requests for your input from outside your team, an improvement whose benefit reached other teams indirectly, and direct peer or stakeholder statements about your influence.
• The milder version of this same move, quantifying your influence on company-level KPIs (key performance indicators), not just team-level ones, is worth building into a promotion case proactively, even without a panel pushing back, rather than only pulling it out defensively when challenged.
• Acknowledge any genuine gap honestly, then attach a plan scoped to the next one or two review cycles with specific, checkable milestones, not a vague intention to "do more cross-team work."
• Tone matters as much as content. Agreeing with the legitimate part of the feedback lands better than arguing the premise; panels respond to "here's what already extended beyond my team, and here's exactly how I close the rest," not to defensiveness.

Worked example

When a promotion committee told me my influence looked narrow after a long stretch deep on one product, I didn't argue the premise. I went back through the year and pulled out everything that had actually left that product's boundaries: a utility I'd built for my own use that two other teams had since adopted, a set of monitoring practices another team copied after seeing them in a review, and specific unsolicited messages from peers on other teams asking me to weigh in on their design decisions. I hadn't been tracking any of that as "scope," only as good engineering. I paired that evidence with a concrete plan for the next two review cycles, naming the two teams I'd deliberately extend work toward and a milestone I could point to at each checkpoint. The panel's read shifted from "narrow" to "narrow so far, but closing on a plan."

Trade-offs & pitfalls

• Getting defensive or arguing the panel is simply wrong is the most common failure mode, even when you privately disagree.
• Overclaiming influence with specifics you can't stand behind under questioning is worse than admitting the gap plainly; panels probe.
• A plan with no dates or checkpoints reads as a promise, not a plan; always attach a review-cycle timeline.
• Confusing volume of your own output with scope; breadth means other teams' work changed because of yours, not how much of your own work you personally did.

Direct answer

Before committing to a lateral pivot, prove the fit cheaply and prove the readiness credibly. Validate genuine interest and aptitude through a low-commitment experiment, a rotation, a shadow assignment, a small real project in the new discipline, before asking for the move, and build a small portfolio of evidence in the destination discipline's own terms, not your current discipline's terms.

Structured elaboration

Separate validating fit from proving readiness, they use different evidence. Fit is whether you actually enjoy and are suited to the day-to-day of the new discipline, learned through direct, low-stakes exposure. Readiness is whether you can perform credibly at an entry level in the new area, proven through a real deliverable.

Validate fit cheaply first. Shadow someone already doing the destination role for a defined period, take on a small real piece of that work alongside your current job, or an informal rotation if your organization supports one. The goal is finding out, before committing a year of your career, whether the actual daily texture of the work matches what you imagine it to be.

Prove readiness in the destination discipline's terms. A common mistake is presenting your current discipline's evidence and expecting it to translate automatically. It rarely does. A few illustrative pairs and what the evidence tends to look like:

• Moving from an engineering role toward product: a small product decision you drove, with the reasoning about user or business trade-offs made explicit, not just a technically strong build.
• Moving from an individual contributor (IC) technical role toward research: a well-scoped investigation with a clear question, method, and honestly reported result, not just a strong implementation.
• Moving from an analyst role toward engineering: something you built that runs reliably and that others depend on, not just an analysis that was correct once.

Build the relationships the destination discipline actually relies on before you need them for the move, so the people who'd eventually evaluate you already have direct exposure to your work in it.

Worked example

"I was drawn to an adjacent discipline but was honestly unsure whether I'd like the daily reality of it or just the idea of it. Rather than asking for the move outright, I asked to shadow someone in that role for a short period and separately took on one small, real piece of that kind of work alongside my existing responsibilities, with my manager's agreement that it was a bounded experiment, not a scope change. The shadowing told me quickly which parts matched what I expected and which didn't. The small real piece of work gave me something concrete, a deliverable that someone already doing that role could evaluate on its own terms, not on the terms of my original discipline. When I later raised the possibility of a fuller move, I brought that piece of work and named it plainly as evidence, rather than asking to be trusted based on enthusiasm alone."

Trade-offs & pitfalls

• Committing to a full pivot based on the idea of the new discipline rather than direct exposure to its actual day-to-day risks discovering the mismatch only after the move.
• Presenting evidence built for your current discipline and expecting a destination-discipline evaluator to translate it themselves. That's your job to do, not theirs.
• Treating the validation experiment as a favor you're owed rather than something you actively design and propose with a clear scope and end date, so it doesn't become an open-ended distraction.
• Be honest with yourself about a negative result. If the shadowing or small project reveals weaker fit than expected, that's a successful use of a cheap experiment, not a failure to be pushed past.

Direct answer

A strong answer proposes two or three initiatives that are genuinely cross-team, not just a bigger version of your current work, and names, for each, the specific thing it would prove about your scope: usually that you can align people who don't report to you, or that something you build outlives your own use of it. The initiatives can take different shapes, a shared platform or tooling effort, a bounded stretch project outside your current lane, or leaning further into an existing cross-functional partnership, but each one needs a clear owner-question attached, not just a description of the work.

Structured elaboration

1. Screen each candidate initiative against a bar: does it require influence without formal authority, getting other teams to adopt or align, not just executing your own team's roadmap? If not, it isn't actually cross-team scope-scaling.
2. Pick a vehicle deliberately. Three common shapes: a shared platform or tooling initiative that multiple teams adopt, a bounded stretch project in an adjacent area, or leaning into an existing cross-functional partnership and deepening it into something you lead. Different vehicles prove different things: tooling proves you can build something others depend on, a stretch project proves range, a partnership proves you can operate at the seams between teams.
3. Name explicitly what each initiative would prove, for example "that people outside my team will adopt something I build without me pushing it," or "that I can represent a decision to a group that doesn't report to me and get buy-in."
4. Sanity-check the scope. Too small and it won't register as scale-worthy, too large and it becomes unrealistic for a six-to-twelve month window. A good initiative is genuinely finishable in that window with a checkable outcome.

Worked example

"In my own case I proposed a shared internal tool that a couple of adjacent teams had each separately half-built versions of. The value wasn't the tool itself, it was proving I could get two teams with slightly different priorities to agree on one version and actually switch to it. Alongside that, I proposed picking up a partnership that already existed informally between my team and a downstream one, and turning it into something with a real cadence and shared goals, meant to prove I could operate at the seam between two teams rather than just inside my own."

Trade-offs & pitfalls

• Proposing something that's really just a bigger project inside your own team, dressed up as cross-team, doesn't prove the thing this question is testing for.
• Failing to name what each initiative proves turns the answer into a project list rather than a scope-growth case.
• Picking an initiative so large it can't plausibly land in six to twelve months undermines credibility more than picking a smaller, real one.
• Proposing initiatives that all use the same vehicle, three tooling projects, say, misses the chance to show range across different kinds of influence.

Direct answer

Structure it as an evidence led case, not a request for a favor. Open by naming the specific ask, promotion, a stretch assignment, or dedicated time and budget, back it with three or four concrete instances of impact and readiness, and pre-empt the most likely objection with a fallback. The conversation should feel like two people already broadly aligned on the goal, working out timeline and specifics, not a persuasion contest.

Structured elaboration

Open with the ask itself. Name what you want as your first sentence, not your last. Ambiguity in the open lets the conversation get steered before you've made your case.

Bring evidence, not adjectives. Two to four concrete instances where you already operated at the level you're asking for, a project led beyond formal scope, a decision others now rely on, a skill built and applied. Evidence should be specific enough that your manager could describe it to their manager without you in the room.

Anticipate the likely objections. There's no open role at that level, the timing is wrong for budget, you need more evidence in one area. A prepared response isn't a rebuttal, it's a next step, what would close the gap and by when.

Bring a fallback. If the primary ask can't be granted in full, have a smaller alternative ready, an interim scope change, a defined stretch project with a review date, or a partial commitment such as title now and a compensation review next quarter. Arriving with only one possible outcome makes it binary and easy to defer.

Close with a mechanism. Propose a specific follow up date and what would need to be true by then for the answer to change.

Worked example

"I asked for time on my manager's calendar and opened directly, saying I wanted to talk about taking the stretch assignment leading the migration project and what that meant for my scope going forward. I brought three examples where I'd already operated at that level informally, a cross team escalation I'd resolved without waiting for my manager, a proposal the team had adopted, and feedback from a peer who said they now came to me first on a certain class of problem. My manager's first response was that the team couldn't spare me from current work. I'd anticipated that and offered a fallback, take the assignment for the first phase only with a defined handoff point, so my current responsibilities weren't left uncovered. We agreed to that scope, with a check in scheduled for the midpoint to decide whether to extend it."

Trade-offs & pitfalls

• Leading with feelings instead of evidence invites the manager to respond to the emotion rather than the case.
• Bringing only one possible outcome, with no fallback, turns the conversation into a yes or no vote you can lose outright.
• Overloading the evidence list dilutes it. Two or three strong, specific instances beat six vague ones.
• Skipping the close is the most common gap. A conversation that ends without an agreed next step tends to quietly disappear from both people's priorities.