Career Goals and Progression Questions

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

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.

Direct answer

Pick a project you chose deliberately because it filled a specific, named gap in your experience or visibility, not just one that landed on your desk, and be concrete about the one thing that measurably changed in your trajectory afterward, a capability, a relationship, or a type of work you're now trusted with.

Structured elaboration

• Name the specific gap the project targeted. A skill, a type of stakeholder exposure, a kind of ownership, not "it seemed interesting."
• Distinguish accelerant projects from ordinary assigned work. You sought it out or volunteered specifically because of the gap; that intentionality is the actual signal being tested.
• Point to something durable in the "what changed" half. A new kind of work you're now trusted with, a relationship that opened later opportunities, or a capability you now use routinely, versus just "it went well."
• Keep it forward-looking. The project itself is evidence; the answer is really about what it changed about how you're used or seen now.

Worked example

Partway into a role, I noticed a gap in my own experience: I'd never owned something end to end in front of a skeptical stakeholder audience, only ever as part of a larger team. When a short, high-visibility project came up that nobody else wanted because of the tight timeline, I volunteered specifically because it forced that gap. I ran it end to end, made the calls, and presented the outcome directly to the stakeholders who'd been skeptical going in. What actually changed afterward wasn't the project's result, it was that I started getting pulled into that kind of stakeholder-facing, ambiguous work as a matter of course, work I'd never have been offered before proving I could carry it alone.

Trade-offs & pitfalls

• Choosing a project purely because it's visible, without it targeting a real gap, produces a story about luck rather than intentional growth.
• Framing the outcome as "and it went well" rather than naming what changed afterward misses the actual question, the interviewer wants the trajectory change, not the project recap.
• Volunteering for something without being honest about the real risk, a tight timeline, being out of your depth, undersells the growth; own the discomfort as part of the story.

Direct answer

A promotion packet is a structured evidence file built over months, not written the week before the review. It has an impact summary, a scope and ownership section, a section that explicitly counts non-technical contributions, and a visibility trail showing others already recognized the work before the packet existed. The packet documents evidence, the persuasive conversation that uses it is a separate skill and belongs in the room, not on the page.

Structured elaboration

The non-technical ledger is the section most packets under-build. Mentoring and documentation are real promotion evidence and should be quantified in terms you can actually verify, not vague credit.

The visibility trail has two strong levers. Turning a side project into a visible internal product, something that started as personal initiative and is now relied on by others, and building an external technical brand, a talk, an open source contribution, or public writing, that puts your name on the work before the packet does.

Building visibility so the packet isn't a surprise means never letting it be the first time your manager, or their manager, hears about the work in it. Share progress in venues that already exist, be deliberate about which pieces of work you narrate publicly, and invest consistently in one or two visibility levers rather than spreading thin.

Worked example

"Over the year before my review cycle I kept a running log of contributions as they happened, not reconstructed at the end. When I built a small internal tool to solve a recurring problem on my team, I didn't stop at solving my own problem, I documented it, offered it to an adjacent team, and it ended up adopted as the default approach for that class of problem, a side project that became a small internal product. Separately I wrote up a design decision as an internal post, which a colleague on another team referenced months later solving a similar problem, so I had a quoted instance of influence beyond my own team. When I assembled the packet, the non-technical ledger included the two people I'd onboarded that year with specific notes from them on what helped, plus a piece of documentation that became the team's reference for a process I'd designed. None of this was manufactured for the packet, it was work I'd done anyway, tracked as I went."

Trade-offs & pitfalls

• Building the whole packet in the final month reads as reverse-engineered and gives peers no time to corroborate it.
• Treating mentoring and documentation as filler instead of first-class evidence under-sells real work that reviewers weight more than most candidates expect.
• Over-investing in external visibility at the expense of internal scope evidence. External brand supports the case, it doesn't replace it.
• Keep the packet as evidence and artifacts, save the persuasive framing and objection handling for the conversation itself, or the packet reads as a sales pitch instead of a record.

Direct answer

A workable leveling framework names a small set of competency dimensions, defines observable evidence for each level within each dimension rather than a single blended score, and is calibrated across managers with a shared evidence bar, not left to individual judgment. Where a discipline splits into technical and people-leadership paths, the framework should offer parallel individual contributor (IC) and management tracks rather than forcing everyone toward a single ladder.

Structured elaboration

Choose the dimensions. Distinct competencies that don't collapse into one another, scope and ownership, domain judgment, execution and delivery reliability, collaboration and influence, and further up the ladder, mentorship or people development. Five to seven is a common ceiling so a rater can hold them all in mind for one candidate.

Define evidence per level per dimension, not an adjective. A vague label like strong technical judgment isn't gradable. A concrete description of what a rater should be able to point to is:

Offer a dual-track structure. At the point where a discipline splits, describe both the individual contributor track and the management track explicitly, with a shared foundation up to that split and different evidence after it. The IC track keeps rewarding deep domain ownership, the management track shifts the evidence toward people outcomes, without treating either as a lesser or forced default.

Calibrate across managers. A rubric applied differently by different managers isn't a shared standard. Build in a norm-setting session before each cycle where managers score anonymized example write-ups and discuss disagreement, and keep a documented set of example evidence per level that managers can compare their own candidates against.

Keep the promotion bar distinct from the good-performance bar. Conflating the two is a common source of drift, where strong performers get promoted for consistency rather than demonstrated readiness for the next level.

Worked example

"When I sketched a rubric for my own discipline I started with five dimensions, scope and ownership, domain judgment, delivery reliability, collaboration and influence, and from a certain level up, mentorship. For each I wrote concrete evidence per level, distinguishing consistently delivers assigned work with occasional guidance from identifies and scopes new work independently, and others rely on that scoping. I built in the dual-track split at the point where the discipline typically forks, the individual contributor track kept the domain-judgment dimension weighted heavily, the management track replaced the mentorship dimension with a people-outcomes dimension covering retention, growth, and team health. To calibrate, I proposed a norm-setting session before each cycle where a handful of managers scored the same two anonymized write-ups independently and discussed any gap before applying the rubric to their own teams, so the same evidence wouldn't land a promotion on one team and a not yet on another."

Trade-offs & pitfalls

• Too many dimensions makes the rubric unusable in practice, raters default back to gut feel.
• Too few collapses distinct competencies together and hides real gaps, blending technical judgment and delivery reliability can let someone who's reliable but making poor trade-off calls slide through.
• Skipping calibration is the most costly gap. Without it, the same rubric produces different outcomes on different teams, which is precisely the fairness problem it's meant to solve.
• Forcing a single ladder onto a discipline that naturally splits pushes people toward management for the promotion rather than the fit, a bad outcome for both the person and the team they might end up managing.