Career Goals and Progression Questions

Direct answer

Name the specific skill gap precisely, not get better at X but the concrete capability you lack, build a month-by-month plan that pairs learning with a real, low-stakes application of the skill, and define upfront what evidence would prove to both you and your manager that the gap is actually closed, not just that time was spent on it.

Structured elaboration

Name the gap precisely. A vague gap, need more leadership, can't be closed on a timeline because you can't tell when it's done. A precise gap, I haven't yet led a project with more than one dependent team, can be. The gap itself varies by person and stage, it might be depth in a specific technology, a practice area such as MLOps, the operational practice of running machine learning systems in production, or cloud architecture, or a non-technical capability such as leadership, communication, or cross-team influence. Whatever it is, name it precisely rather than generically.

Choose the plan format that fits the gap and your organization's norms. A formal individual development plan (IDP) or personal development plan (PDP) tracked with your manager, a self-directed learning roadmap, or a mentorship-and-development plan built around a specific mentoring relationship. The format matters less than whether it has real milestones and a real check-in mechanism attached.

Build month-by-month milestones that pair input with application. A month or two of concentrated learning, a course, structured reading, shadowing someone strong in the area, followed immediately by applying it on a real, if small, piece of work, not learning followed by an indefinite wait for the right opportunity.

Define the closing evidence upfront, before you start. A completed project that required the skill, feedback from someone who observed you using it, or your own comfortable performance in a situation that used to make you anxious. Where you're earlier in your career or the gap is foundational, a lighter version of this plan can lean more on recommended resources, a specific book, course, or structured reading list, as the input side, since real-world application opportunities may need to be built up to.

Build in the feedback loop. A recurring, lightweight check-in with your manager or mentor, not just a single review at the end of the plan.

Worked example

"I identified a specific gap, I'd never led a piece of work that required negotiating priorities directly with another team, only within my own. I built a three-month plan. Month one, shadow a colleague who did this well in a couple of real meetings, and read a short set of material on negotiation and stakeholder alignment. Month two, take on one small piece of work myself that required exactly this, with my manager aware it was a deliberate stretch, and check in with my shadowed colleague afterward for candid feedback. Month three, take on a second instance of the same kind of work, this time without shadowing beforehand, to test whether the skill had actually transferred rather than only working with a safety net. I'd agreed with my manager beforehand what would count as evidence the gap was closed, specifically that I could handle one of these negotiations independently, with an outcome both teams considered fair, and that a peer who observed it would say so unprompted."

Trade-offs & pitfalls

• A plan that's all learning and no application doesn't close a skill gap on its own, it only prepares you for the real practice that does.
• Defining the gap too vaguely to know when it's closed leaves the plan running indefinitely with no clear finish line.
• Skipping the check-in loop means only finding out at the end whether the plan actually worked, rather than adjusting along the way.
• Be realistic about pacing. A genuinely new capability, especially one involving judgment rather than a mechanical skill, usually needs more than one real attempt before it's trustworthy.

Direct answer

Start from a specific, named skill gap rather than "wanting a mentor" generally, then find someone with direct experience closing that exact gap and structure the relationship around a concrete cadence and deliverable, not just occasional check-ins.

Structured elaboration

• Start with the gap, not the relationship. Name the specific capability you're missing, not "I want a mentor," but "I need someone who's actually navigated this exact problem."
• Identify the right person by evidence they've solved that specific problem, not just seniority or title.
• Structure it deliberately: a defined cadence that's regular but time-boxed, a specific artifact or goal to work toward together rather than open-ended conversation, and a natural end point or reassessment.
• The reverse angle applies here too. The same intentionality applies when you're the one acting as mentor to someone else, tying it back to your own trajectory: teaching a specific skill to someone else is often the fastest way to convert your own implicit knowledge into something you can articulate and lean on for your next level. Seeking and giving mentorship around a specific gap draw on the same underlying skill.
• Close the loop. Define what "done" looks like so the relationship doesn't drift into indefinite informal chats with no forward motion.

Worked example

There was a specific area I knew I was weak in, and I didn't look for "a mentor" broadly, I looked for one specific person on a different team who'd actually solved that exact problem before. I asked for a defined arrangement: a recurring session for a set number of weeks, working through a real piece of my own work rather than abstract advice, ending with a specific deliverable I could point to. That structure meant neither of us had to guess whether it was working. Later, when I mentored someone else through a similar gap, I used the same shape in reverse, a defined cadence, a real deliverable, an endpoint, and explaining the reasoning behind my own decisions to someone else sharpened it for myself in a way informal conversations never had.

Trade-offs & pitfalls

• Open-ended "let's grab coffee sometime" mentorship rarely closes a specific gap, it produces goodwill but not measurable progress.
• Picking a mentor for their title rather than evidence they've solved your specific problem wastes both people's time.
• No defined endpoint means the relationship either fades awkwardly or persists past its useful life.
• Treating mentoring others as separate from your own growth misses that teaching a gap you've closed is often how you close the next one.

Direct answer

Name two to three concrete goals that span a delivery outcome, a relationship or context goal, and a craft improvement, then state one specific milestone you'd check yourself against at the interim mark, not a general feeling of being "on track." The exact goals should shift with the horizon asked, first six months, first year, or two to three years, and with the seniority of the role.

Structured elaboration

• Match scope to horizon. A first-six-months goal set is mostly about ramp-up and one visible first contribution; a first-year set adds one meaningful, largely independent delivery plus established trust with key stakeholders; a two-to-three-year set shifts toward growth in scope, ownership, or a chosen specialization rather than a single deliverable.
• Cover three goal types, not just the technical one: a concrete problem solved or thing shipped, a context and relationship goal (understanding the systems and people whose buy-in you'll need for anything ambitious later), and a craft or process improvement you personally own end to end.
• Attach a leading indicator to each goal, something observable well before the deadline, not just the final outcome. This is what makes a mid-point check-in credible instead of a guess.
• Calibrate ambition to seniority. A candidate for a more senior role should include a scope or influence goal, not only execution goals; someone earlier in their career should show they understand ramp-up comes first.
• The single strongest closing move: state the concrete milestone you'd check yourself against at the interim mark, a specific thing shipped, a decision made, feedback actually received, rather than restating the goals as if listing them again proves progress.

Worked example

When I started a previous role, I set three goals for the year: ship one meaningful improvement to a system that mattered to the team, build real working relationships with the two or three people whose sign-off I'd need for anything ambitious later, and establish one process habit I could point to as mine. At the six-month mark, my checkpoint wasn't "do I feel settled," it was two specific things: had I shipped the first version of that improvement, and could I name the people who'd actually back me if I proposed the next, bigger version of it. Both were true, so instead of starting a new goal from zero, I used the credibility from the first six months to scope a larger version of the same problem for the rest of the year.

Trade-offs & pitfalls

• Vague goals ("learn a lot," "add value") signal you haven't actually thought this through; goals that depend entirely on something outside your control (a launch owned by another team) are the opposite failure.
• Loading up only on technical goals while skipping relationship or context goals tends to stall growth later, once the technical work is good you still need sponsors.
• Skipping the interim checkpoint definition means "on track" becomes something you decide retroactively rather than something you can actually check.
• Answering with only execution goals at a senior level under-signals; answering with only scope-and-influence goals very early on over-signals.

Direct answer

The move is to separate diagnosis from reaction: before assuming the gap is unfair (inconsistent criteria, an indifferent manager) or purely a personal failing, do an honest, evidence-based audit of your own case first, then act on what you actually find rather than on the story you started with. That self-diagnosis is what keeps the response grounded instead of either resigned or entitled.

Structured elaboration

1. Name the trigger honestly, whatever it actually is: no advancement across two review cycles, criteria that seem to shift depending on who's managing you, or just a general sense of plateauing. Treat it as a starting observation, not a verdict.
2. Diagnose before reacting. Audit your own evidence (scope actually carried, outcomes attributable to you, feedback received) against whatever the organization's stated or informal bar is. Separately, note if the bar itself looks inconsistent or unclear across managers, that's useful information, not an excuse to skip the audit.
3. Have the direct conversation. Bring your honest self-assessment to your manager and ask explicitly what's missing, rather than silently accumulating resentment or silently giving up on the goal.
4. Decide on a bounded response. Set a real timeframe to see change, and know your own answer for what you'd do if nothing changes, without turning that into an ultimatum in the room.

Worked example

"At one point I'd gone through two review cycles without the scope change I was expecting, and it would have been easy to decide either that the process was broken or that I just wasn't good enough. Instead I sat down and mapped what I could actually point to: had I taken on next-level work, could I show outcomes that were mine, had anyone besides me confirmed it. Some of it held up, some didn't, there was a specific kind of cross-team decision I'd been avoiding making solo. I brought that honest picture to my manager instead of a complaint, asked directly what was missing from their side, and used what came back to set a concrete plan with a real check-in date rather than just waiting quietly for the next cycle."

Trade-offs & pitfalls

• Skipping the self-diagnosis and going straight to a conversation framed as a grievance is the entitled failure mode interviewers are listening for.
• Quietly disengaging or lowering your own ambition instead of raising the issue is the opposite failure mode, and just as costly.
• Blaming inconsistent criteria across managers without also checking your own evidence dodges the harder, more useful half of the question.
• Setting no real timeframe for reassessment lets "wait and see" drift indefinitely. A grounded answer names when you'd revisit the decision.

Direct answer

Before building any recovery plan, diagnose the actual cause: a genuine readiness gap, ambiguous or inconsistently applied criteria, or a structural block (budget freeze, reorg) entirely outside your control, since the right two-quarter plan looks completely different depending on which one it is.

Structured elaboration

• Diagnose before acting, this is the step several answers skip. Ask directly, your manager and, if appropriate, a skip-level or HR (human resources), which bucket this falls into. The same discipline applies whether the specific situation is being passed over for promotion twice in a row, an HR or budget block despite clear manager support, mixed and inconsistent promotion-review feedback, or your team being disbanded in a reorg with nothing to do with your performance.
• Get the diagnosis in writing where you can (a short recap email after the conversation), so the criteria for next time are explicit and can't quietly drift again.
• Match the two-quarter plan to the diagnosis: a readiness gap calls for naming the one or two specific gaps and a concrete way to close them; ambiguous criteria call for pushing for a written, specific bar and calibrating against a recently promoted peer; a structural block calls for negotiating interim recognition (scope, title, or a compensation alternative) and simply continuing to deliver visibly, since the case itself doesn't need rebuilding.
• Keep a running log of impact regardless of cause, so the next review relies on a record rather than memory.

Worked example

I expected a promotion and didn't get it, and my first move wasn't a recovery plan, it was asking my manager directly what had actually driven the decision. It turned out to be a mix: the committee felt the case was strong on delivery but thin on evidence of cross-team impact, and separately, headcount for that level was frozen that cycle regardless of anyone's case. Knowing both halves changed what I did next. For the readiness half, I picked one initiative deliberately structured to touch two other teams and documented it as I went rather than after the fact. For the frozen-headcount half, I didn't spend energy trying to fix something outside my control, I asked for an interim scope change I could point to later and kept the impact log running so the next review had a record instead of the same ambiguous case.

Trade-offs & pitfalls

• The most common mistake is skipping the diagnosis and jumping straight into a remediation plan; if the real cause was budget, the plan solves the wrong problem and burns two quarters proving something nobody doubted.
• Accepting a vague answer ("just not quite there yet") instead of pushing for specifics sets up the same ambiguous outcome next cycle.
• Asking for interim recognition (title, scope) before you understand the real cause can read as entitled; sequence it after the diagnosis.
• Nursing a private grievance instead of a calibrated, written understanding of the criteria repeats the cycle.