1

Technical Leadership

Sets technical direction for a domain or system. Architectural decisions that affect multiple teams or long-term velocity.

Exceeds

Shapes technical direction at the team or org level. Architectural decisions are adopted without revision. Other engineers seek their technical opinion before committing to an approach.

Meets

Drives technical decisions for their area. Advocates for the right approach in design reviews. Aware of cross-system tradeoffs.

Below

Defers to others on technical direction more than expected at senior level. Decisions are reactive rather than proactive.

Example review phrases

  • "Proposed and drove the migration off the legacy monolith queue—a decision that is now the standard approach across 6 services."
  • "Other senior engineers consistently reference their design docs as the benchmark for quality in the org."
  • "At the senior level, expected to set direction—instead still waits for architectural guidance from staff engineers."
2

Scope Expansion

Ability to take on problems broader than their assigned team. Cross-org visibility and influence.

Exceeds

Regularly takes on problems that cross team boundaries. Recognized as a go-to expert outside their immediate team.

Meets

Handles cross-team dependencies competently. Contributes to broader technical discussions.

Below

Scope stays within their team and assigned tickets. Does not proactively identify broader problems to own.

Example review phrases

  • "Noticed a shared infrastructure bottleneck that 3 teams were working around independently—stepped in, fixed it, and unblocked all three."
  • "Scope has stayed within assigned work for the full review period; the senior track expects more proactive ownership."
3

Mentorship

Development of junior and mid-level engineers through structured feedback, pairing, and code review quality.

Exceeds

Actively grows junior engineers toward independence. Code reviews are teaching tools, not gatekeeping. Direct reports point to them as the reason they leveled up.

Meets

Available to junior engineers. Code reviews are substantive. Helps when asked.

Below

Junior engineers avoid asking for help. Code reviews are transactional. Limited visible investment in others' growth.

Example review phrases

  • "Two mid-level engineers attribute their recent promotion readiness directly to this person's investment in their development."
  • "Code reviews are detailed enough that every author learns something, not just gets unblocked."
  • "Junior engineers default to asking peers instead of them—a signal that mentorship relationships haven't formed."
4

Delivery at Scale

Ability to drive large, ambiguous projects from definition through delivery without constant management.

Exceeds

Handles large, multi-quarter projects without requiring active management. Turns ambiguous requirements into clear technical plans.

Meets

Executes well-scoped multi-month projects. Surfaces scope issues early. Delivers with acceptable quality.

Below

Struggles when requirements are ambiguous. Large projects need more check-ins than expected at this level.

Example review phrases

  • "Took a vague product requirement and produced a phased technical plan that the team executed with zero rework."
  • "Delivered the Q3 platform project 2 weeks early despite 3 significant scope changes mid-quarter."
🔮

Where do these examples come from in real reviews?

Most managers write performance reviews from memory—limited to what they personally observed. Confirm surfaces behavioral evidence from across the organization: who relied on this person, what they drove, how their impact extended beyond their direct manager's line of sight. Reviews written with Confirm's data are more accurate, more defensible, and faster to write.

See Confirm in action →