Adapting a performance review by role is one of the most impactful changes an organization can make to its evaluation process. A review that evaluates a senior software engineer using the same criteria as a junior account manager produces meaningless results. The roles have different scopes, different success metrics, different timelines for impact, and different development paths. Yet many organizations use a single review template across all roles, with generic competencies like “communication,” “leadership,” and “initiative” that mean different things depending on context.
Effective performance reviews adapt to the role being evaluated. The structure — evidence-based evaluation from multiple sources, specific behavioral feedback, reduced bias through systematic input collection — remains consistent. What changes is what “strong performance” looks like for each role, what evidence is most relevant, and what development areas matter most.
This guide covers how to adapt reviews for the most common role distinctions: individual contributors vs. managers, junior vs. senior levels, specific functional areas, and different organizational contexts.
The most fundamental distinction in performance reviews is between individual contributors (ICs) and people managers. These roles require different evaluation criteria because they create value in fundamentally different ways.
ICs create value through their direct work — the code they write, the campaigns they run, the analyses they produce, the customers they support. Their review should focus primarily on the quality, impact, and scope of that direct work.
Core evaluation areas for ICs:
Quality and craft. Is the work product consistently strong? Does it meet or exceed the standards expected for the role and level? For an engineer, this includes code quality, architectural decisions, and testing rigor. For a designer, this includes design quality, user research rigor, and attention to detail. For a salesperson, this includes deal management, relationship building, and forecast accuracy.
Impact and scope. What was the measurable impact of the IC’s work? Did they take on work that was appropriately scoped for their level, or are they consistently working below or above their expected scope? A senior engineer who delivers flawless code on junior-level tasks is underperforming relative to their level, even though the work quality is high.
Collaboration and influence. How effectively does the IC work with others? This doesn’t mean “is friendly” — it means: do they communicate clearly about their work, unblock others when needed, and contribute constructively to team decisions? For senior ICs, this extends to influence: do they shape technical direction, mentor others, and raise the quality of the team’s collective work?
Growth and learning. Is the IC developing new skills, taking on new challenges, or deepening expertise in ways that increase their future value to the organization?
What IC reviews should NOT emphasize: Management behaviors. ICs shouldn’t be evaluated on how well they “lead” unless leadership is explicitly part of their role (e.g., tech lead, team lead). Evaluating ICs on management competencies pushes people toward management careers when the organization may benefit more from deep individual expertise.
Managers create value in two ways: through their own individual contributions (strategy, decisions, execution) and through the performance and development of their team. Both dimensions should be evaluated, with the balance shifting toward team outcomes as the manager becomes more senior.
Core evaluation areas for managers:
Team performance. Are the manager’s direct reports delivering strong results? Is the team meeting its goals? This is the most important signal — a manager whose team consistently delivers is likely managing well, even if their personal style isn’t what the evaluator prefers. Conversely, a manager who is personally impressive but whose team is underperforming has a management problem.
People development. Are the manager’s direct reports growing? Are they receiving regular, specific feedback? Has anyone on the team been promoted or taken on significantly expanded scope? Have performance issues been addressed early and constructively? A manager who doesn’t develop their people is borrowing against the future — short-term results may be fine, but the team won’t sustain performance without growth.
Retention and engagement. Are people leaving the team? Why? Are team members engaged and motivated? These are lagging indicators — by the time someone leaves, the management failure happened months ago — but they’re important signals about management effectiveness over time.
Communication and alignment. Does the manager communicate clearly with their team about priorities, expectations, and organizational context? Do they represent their team’s needs and accomplishments effectively to leadership? Do they translate organizational strategy into actionable direction for their team?
Decision quality. Does the manager make good decisions about priorities, resource allocation, hiring, and process? Are they willing to make difficult decisions (performance management, project cancellation, resource reallocation) when needed?
The most common mistake in manager reviews: Evaluating managers primarily on their individual contributions while treating team outcomes as secondary. A manager who is personally brilliant but whose team is disengaged, underdeveloped, or underperforming is not a strong manager — regardless of their individual output.
Manager reviews benefit from upward feedback — structured input from direct reports about the manager’s effectiveness. This input should be:
Direct report feedback on questions like “Does your manager provide specific, timely feedback on your work?” and “Do you understand what’s expected of you and how your work connects to team goals?” provides actionable signal that the manager’s own manager often can’t observe directly.
The same competency means different things at different levels. Evaluating a junior employee on the same expectations as a senior one is unfair. Evaluating a senior employee on junior-level criteria understates their expected contribution.
Evaluation emphasis: Learning velocity, task execution quality, and responsiveness to feedback.
Junior employees should be assessed primarily on how quickly they’re developing, how reliably they execute assigned work, and how well they incorporate feedback into their approach. Strategic thinking, organizational influence, and independent decision-making are not fair expectations at this level.
Example of appropriate junior review language: > “Alex completed all assigned implementation tasks on time during Q2-Q3, with code review feedback decreasing from an average of 8 comments per PR in Q2 to 3 comments per PR in Q4 — demonstrating rapid improvement in code quality. Alex has started asking more proactive questions during sprint planning, which suggests growing understanding of the broader technical context. Development focus: Alex should begin taking ownership of small features end-to-end (scoping, implementation, testing, documentation) rather than individual tasks assigned by the team lead.”
Evaluation emphasis: Independent execution, collaboration quality, and beginning to expand scope.
Mid-level employees should reliably execute work without close supervision, collaborate effectively across teams, and begin identifying problems and opportunities beyond their assigned scope. They’re expected to produce high-quality work consistently and to contribute to team discussions with informed perspectives.
Example of appropriate mid-level review language: > “Jordan independently managed the full customer onboarding pipeline for the Mid-Market segment, maintaining a 94% on-time completion rate against a 90% target. The onboarding playbook Jordan developed in Q1 has been adopted by the Enterprise team — evidence that Jordan’s process thinking has impact beyond their direct scope. Development focus: moving from reactive problem-solving to proactive identification of process improvements. The onboarding playbook is a positive example of this; the goal is to make this proactive approach a regular practice rather than a one-time initiative.”
Evaluation emphasis: Strategic impact, organizational influence, and force multiplication.
Senior employees should be assessed on the scope and significance of their impact, their ability to make the people around them more effective, and their contribution to organizational direction. The specific form varies by function — a senior engineer influences through technical decisions and mentorship, a senior marketer influences through strategy and market insight — but the common thread is that senior impact extends beyond individual task execution.
Example of appropriate senior review language: > “Priya’s redesign of the data pipeline architecture reduced processing time by 60% and eliminated the recurring Saturday on-call incidents that had affected the team for 18 months. Beyond the technical contribution, Priya’s approach to the project — documenting the decision framework, running a design review with all stakeholders, and mentoring the two engineers who will maintain the system — elevated the team’s overall architectural thinking. Three other engineers have adopted Priya’s decision documentation template for their own projects. Development focus: Priya’s impact is increasingly at the staff engineer level, but her communication with non-technical stakeholders remains engineer-to-engineer in style. Developing the ability to translate technical decisions into business impact language would support Priya’s effectiveness in cross-functional leadership and strengthen her case for staff engineer promotion.”
Key evaluation dimensions: - Code quality and technical decision-making - System reliability and operational impact - Code review quality (both giving and receiving feedback) - Documentation and knowledge sharing - Collaboration with product, design, and other engineering teams - Technical scope relative to level
Common review mistakes for engineers: - Overweighting lines of code or number of PRs (quantity ≠ impact) - Underweighting mentorship and code review contributions - Ignoring operational reliability (an engineer who ships features but creates stability problems is creating net-negative value) - Evaluating all engineers against a single “senior engineer” profile when the team needs both deep specialists and broad generalists
Key evaluation dimensions: - Revenue against quota - Pipeline management and forecast accuracy - Deal quality (size, retention probability, customer fit) - Customer relationship development - Collaboration with CS, product, and marketing - Activity metrics in context (calls, meetings, demos — as inputs, not as primary measures)
Common review mistakes for sales: - Evaluating solely on revenue, ignoring deal quality and long-term customer value - Underweighting collaboration with post-sales teams - Using activity metrics as primary performance indicators rather than outcome context - Not distinguishing between market conditions and individual performance (a rep who hits quota in a down market may be outperforming one who exceeds quota in a boom)
Key evaluation dimensions: - Customer retention and expansion within portfolio - Customer health indicators and proactive intervention - Time to value for new customers - Cross-functional advocacy (bringing customer needs to product and engineering) - Documentation quality and process contribution
Key evaluation dimensions: - Campaign and program performance against defined metrics - Strategic thinking and market insight - Cross-functional collaboration (especially with sales and product) - Content quality and brand consistency - Experimentation and optimization velocity
Key evaluation dimensions: - Product outcomes (user adoption, engagement, revenue impact) - Stakeholder management and cross-functional alignment - Decision quality under uncertainty - Communication clarity (specs, roadmaps, strategy documents) - Team effectiveness (is the engineering team able to execute efficiently based on the product direction provided?)
At small companies, roles are fluid. The performance review should acknowledge this reality rather than imposing enterprise-style structure.
Adapt by: - Evaluating adaptability and willingness to work outside formal role boundaries - Weighting speed of execution and learning over polish - Recognizing that “scope” at a startup means wearing multiple hats, not managing a defined domain - Keeping reviews shorter and more conversational — 30-minute discussions with documented takeaways are more valuable than multi-page evaluations at this scale
This is the stage where informal processes start breaking. The “everyone knows everyone’s work” assumption fails around 50-80 people, and visibility bias becomes a significant problem.
Adapt by: - Implementing structured review processes that don’t depend on the founder/CEO knowing everyone’s contribution - Collecting peer feedback systematically rather than relying on manager observation alone - Defining role-specific evaluation criteria before the review cycle, not during it - Using continuous feedback systems to capture evidence throughout the year as manager observation gaps grow
This is the size range where WorkStory is specifically designed to operate. Teams at 100-200 people have enough complexity to need systematic feedback collection but not enough administrative overhead to justify enterprise platforms with months of setup and training. Feedback captured automatically from Slack and Teams fills the observation gaps that emerge at this scale.
At enterprise scale, the challenge shifts from “how do we collect evidence” to “how do we maintain consistency.”
Adapt by: - Implementing calibration processes across managers and departments - Using standardized competency frameworks with role-specific adaptations - Monitoring review outcomes for systemic bias patterns (by team, location, demographic group) - Investing in manager training paired with structural support (not training alone) - Accepting that some organizational context — department culture, team norms, market conditions — should influence how reviews are interpreted but not how they’re conducted
Nonprofit performance reviews face a unique tension: the work is mission-driven, but operational excellence still matters. “Passionate about the mission” is not a performance competency — it’s a hiring criterion.
Adapt by: - Evaluating impact and outcomes, not just effort and dedication - Using the same evidence-based approach as for-profit organizations - Resisting the tendency to avoid critical feedback because “everyone’s here for the mission” - Acknowledging resource constraints as context for performance, not as an excuse for underperformance
First-time managers deserve specific attention because they’re learning a fundamentally new skill while being evaluated on it. The transition from IC to manager is one of the highest-failure-rate role changes in organizations.
What to evaluate in the first year of management: - Are they having regular 1-on-1s with each direct report? - Are they providing specific, timely feedback (not just annual reviews)? - Are they making decisions about priorities and communicating them clearly? - Are they addressing performance issues rather than avoiding them? - Are they developing their team members’ skills?
What NOT to evaluate in the first year of management: - Strategic organizational impact (they’re still learning the basics) - Polished leadership style (this develops over years, not months) - Team metrics compared to experienced managers (their team is adjusting too)
Example first-time manager review language: > “Rachel transitioned from senior IC to engineering manager in Q1. She has established a consistent weekly 1-on-1 cadence with all five direct reports and has provided specific written feedback on at least two occasions per person during the review period. Two direct reports noted in their feedback that Rachel’s technical context makes her coaching on code quality particularly useful. > > Area for development: Rachel tends to step in and solve technical problems herself rather than coaching her team through the solution. This is a common pattern for new managers transitioning from IC roles. In Q3, she identified this tendency and has been intentionally stepping back — but the pull toward direct contribution remains strong when deadlines are tight. Our focus for next period is establishing the habit of asking ‘who on the team should own this?’ before engaging directly.”
Should ICs and managers be on separate review cycles?
Not necessarily separate cycles, but they should use adapted evaluation criteria. A single review timeline is simpler to administer. The customization happens in the competencies and evidence sources, not in the timing.
How do you handle reviews for employees who changed roles mid-cycle?
Split the evaluation into two periods — pre-transition and post-transition — and evaluate each against the relevant role expectations. The review should acknowledge the transition as context: “For the first four months, Alex was evaluated as a senior IC. For the subsequent eight months, Alex has been evaluated as a first-time manager. Both assessments are included below.”
Should high performers automatically be promoted?
No. Strong performance at the current level demonstrates competence in the current role. Promotion readiness requires evidence that the employee can perform at the next level — which involves different skills, scope, and expectations. The review should clearly distinguish between “performing well at current level” and “ready for next level responsibilities.” The guide on performance review examples includes language for both.
How do you evaluate someone whose role doesn’t fit standard categories?
Start from outcomes, not competencies. What is this person supposed to accomplish? What does success look like in their specific context? Custom roles require custom evaluation criteria — which should be defined at the beginning of the review period, not improvised at the end. If the criteria aren’t clear, that’s a management problem to solve before the review, not during it.
Do performance reviews work differently for remote vs. in-person employees?
The review structure should be identical. The input sources may differ — remote employees generate fewer casual observation touchpoints for their manager, which makes documented peer feedback and continuous feedback capture even more critical. Remote employees should not receive weaker reviews simply because they’re less visible. If they do, the review system has a visibility bias problem.
How often should review criteria be updated for a role?
Annually, at minimum. Role expectations evolve as the organization grows, the market changes, and the individual develops. A review that evaluates a senior engineer in 2026 against criteria written for the role in 2022 may not reflect what the organization currently needs. Criteria updates should happen before the review period starts — employees deserve to know what they’ll be evaluated on before the evaluation period begins.
When feedback is captured automatically from the tools your team uses daily, reviews reflect the full picture — across roles, levels, and working styles. See how WorkStory works →
