At junior level, the evidence that matters is reliability and ramp speed. Goals should demonstrate that you can ship independently and are starting to think beyond your own ticket.

**Good examples:** - Ship at least 2 features end-to-end per sprint for the next 3 months with no critical bugs in production - Review at least 3 PRs per week from teammates, with written comments rather than just approve/decline - Write a technical runbook for one service I own by end of Q2 - Complete onboarding for the authentication system well enough to answer questions from the next new hire - Identify one area of technical debt in my codebase ownership and file a proposal to address it

**What makes these work:** They're measurable, time-bounded, and within the engineer's control. They don't depend on manager approval or committee decisions.

Mid-level goals should start generating evidence of ownership and initiative — the two things the senior bar requires most.

**Good examples:** - Identify one reliability gap in my service area, write the design document, get approval from a senior engineer, and ship the fix before the end of Q3 - Mentor one junior engineer to the point where they can independently own a module — measured by their next performance review showing expanded ownership - Lead the technical design for the next major project in my squad rather than inheriting the design from a senior engineer - Reduce P1 oncall incidents for my service from 8/month to 4/month within two review cycles by improving alerting and runbooks - Present a technical proposal at the team's architecture review — with a written doc that survives scrutiny from senior engineers

**What makes these work:** They require initiative rather than just execution, they involve other people (junior mentee, senior reviewer, team), and they produce artifacts (docs, proposals) that constitute visible evidence.

Senior goals should demonstrate cross-team impact and technical leadership beyond your immediate area. This is the threshold where most engineers struggle because the work that gets you to senior isn't the work that gets you to staff.

**Good examples:** - Identify a cross-team dependency issue between my team and the platform team, propose a solution, and lead the implementation without being asked — completed before Q4 review - Build relationships with at least 2 senior engineers in adjacent teams who can speak to my impact in calibration - Write and publish an internal technical design standard for API versioning that gets adopted by at least 3 teams - Sponsor a junior engineer's promotion from L3 to L4 — including writing the promotion brief and presenting in calibration - Lead the migration of one legacy system to a new architecture, coordinating across two teams, with the migration complete and stable in production

**What makes these work:** They cross team boundaries, they produce artifacts that outlast the engineer's direct involvement, and they create advocates (other engineers who benefited from the work) who can speak to impact.

Staff-level goals focus on org-level technical direction and influence. These are inherently harder to set because staff impact often emerges rather than being assigned.

**Good examples:** - Define the technical strategy for observability across all backend services, get buy-in from engineering leadership, and drive adoption to 80% within 6 months - Identify and resolve a systemic architectural issue (e.g., inconsistent data modeling across microservices) that is creating rework for 4+ teams — without a mandate from engineering leadership - Represent the engineering org's technical perspective in a vendor evaluation with meaningful influence over the final decision - Establish a recurring technical review process that didn't exist before — with consistent participation from engineers across three or more teams - Reduce time-to-production for new features org-wide by 20% through platform improvements, measurable across at least 5 teams

**What makes these work:** They are self-initiated, cross-org in scope, and leave infrastructure or process improvements that continue delivering value after the engineer moves on.

Engineering manager goals are structurally different — they're measured through the outcomes of the team rather than individual technical contributions.

**Good examples:** - Hire two senior engineers and one mid-level engineer by end of Q2, with both offers accepted within 3 weeks of final interviews - Achieve team velocity of 85+ points/sprint by Q3 (up from 60 in Q1) through better estimation, reduced scope creep, and clearer requirements - Develop one engineer to the next level during the next review cycle — evidenced by successful calibration and promotion - Reduce team attrition to zero for the next 12 months through 1:1 investment, growth path clarity, and workload management - Deliver the team's Q3 roadmap within 10% of planned scope, with a written retrospective explaining any variance

**What makes these work:** EM goals are defined by team outcomes, not personal technical output. They require the manager to think about what conditions enable their team to succeed, not just what they personally need to do.

Career aspirations are the longer-horizon version of goals — the direction you're pointing rather than the milestone you're targeting. These matter for annual reviews and PDPs but also for helping you filter opportunities.

**IC track aspirations:** - 'I want to become the technical owner of a product area at the scale of [company's main product] within 3 years' - 'I want to develop deep expertise in distributed systems reliability and be recognized as a go-to resource across the org' - 'I want to lead a technical migration that changes the architecture of a core system and positions the team for the next 5 years of scale'

**EM track aspirations:** - 'I want to build a team where the average engineer grows at least one level during their first 18 months with me as their manager' - 'I want to lead an engineering org of 20+ engineers within 4 years, with a reputation for high retention and strong technical quality' - 'I want to be the engineering leader who defines how this company builds AI-assisted products'

**Alternative path aspirations:** - 'I want to transition into product management where I can apply my technical depth to product strategy within 2 years' - 'I want to build and lead a technical consulting practice that serves companies at [specific stage]'