Performance Management and Talent Development

At a fictional payments company with a hundred and twenty engineers, the annual review overlooked important evidence. The engineer who had kept the nightly settlement batch running for three years received the middle rating because the template counted features shipped and she had shipped few. The engineer who shipped the most features received the top rating, although two releases had been reverted. Those facts do not establish either person’s correct rating; they show what the review needed to investigate. Four months later the settlement engineer left. Nobody else could run the batch. This article examines how to assess individual work within team results, define competencies and career levels, calibrate ratings, structure hiring, and connect development with succession. The public sources describe several organizations’ practices. The payments company and its decisions are illustrative.

The rating is individual and the work is not

The US Office of Personnel Management (OPM) distinguishes the person receiving a formal rating from the work being assessed. Its performance-management cycle allows group performance to affect an individual’s summary rating while assigning the rating of record to the individual. For software teams, that calls for an account of responsibilities, outcomes, and observed contributions. Responsibility and accountability distinguishes responsibility for doing work from accountability for its outcome. Neither assignment can be inferred from a feature count alone.

Use more than one kind of evidence. OPM’s assessment playbook covers job knowledge, skill application, behavior, and outcomes; GitLab’s handbook likewise includes both results and behaviors. The settlement engineer’s reliable operation of a critical system mattered. So did the absence of usable documentation and another trained operator. Before treating those gaps as her performance failure, the reviewer needed to establish what sharing was expected, what time and support were available, and what she had done. For the feature engineer, the reverts called for investigation into causes and recovery. In this case, incident records also showed that he had skipped agreed pre-release tests. That observed behavior could be assessed against an established expectation; the reverts alone could not settle his rating.

Shared delivery measures need a clear role in this assessment. Deployment frequency and lead time describe a delivery system, and mechanically dividing them among people does not identify each person’s contribution. Such attribution can encourage competition over the measure. Measuring friction rather than people explains the limits of activity counts and individual rankings. Team outcomes can still provide context when assessing agreed responsibilities, decision authority, constraints, and specific contributions. A summary rating may combine that evidence; it should remain traceable to it rather than substitute for it.

What is assessed	Question it answers	Evidence that fits	Evidence that does not
Results	Did the outcomes this person was accountable for happen?	Expectations set at the start of the period and whether they were met	Counts of activity (commits, tickets, features) presented as outcomes
Behaviors	How did they work, against the stated competencies and values?	Observed conduct with examples: reviews given, incidents handled, knowledge shared	Impressions without examples; personality
Team contribution	How did this person contribute to the team’s work?	Observed unblocking, mentoring, reviews, and gap coverage, considered alongside relevant team outcomes	The team’s DORA or delivery numbers mechanically assigned to one member

OPM recommends self-assessment and input from colleagues, clients, and other collaborators. These provide additional perspectives on work the manager may not see, including operation, recovery, and knowledge sharing. They need examples and follow-up questions; collecting them does not guarantee that a gap will surface. The playbook also connects recognition with demonstrated results, behaviors, and goals, including recognition between formal reviews. Expectations and feedback develops that ongoing conversation.

Competencies and levels: writing down what a level means

A review needs expectations that people can understand before they are assessed. The payments company had titles but no shared account of what each title required. A career framework can provide that account through role-level expectations and competency descriptions. Teams still need to translate the framework into appropriate goals and responsibilities for their work.

The UK Government Digital and Data Profession Capability Framework illustrates how the parts fit together. It describes role levels and the skills required at each, with skills expressed through four ascending proficiency levels. Its software developer role runs from apprentice to principal and offers technical and management paths from senior level upward. The framework supports development discussions, workforce planning, job descriptions, and candidate assessment. A company adapting it needs to check its own roles and scope rather than equate a title with one of the government’s levels.

Dropbox’s framework separates the scope and reach of a level from the behaviors used to deliver results. It also warns that the framework is not a promotion checklist. Applied to the settlement case, this distinction would help the reviewer discuss operating impact and knowledge transfer separately. It would not automatically label the engineer senior in one dimension and junior in another. That judgment would require relevant criteria, evidence over the assessment period, and consideration of the opportunities and support she received. A development plan would then specify actions, support, and how improvement would be observed.

A framework can become a checklist whose completed bullets are mistaken for a guaranteed promotion. It can also drift away from the work people actually do. Review its fit when roles, scope, or expectations change, and record the outcome. The UK framework’s dated change history is one example of maintaining that fit. A review may also find that existing expectations remain suitable; a recent edit date alone says little about quality.

Promotion: evidence of the next level, not hope for it

Dropbox’s promotion principles recognize sustained performance at the next level, including results and the behaviors needed to achieve them. Its policy does not treat completed checklist items or hoped-for future capacity as sufficient. A company adopting this approach should state the evidence period, relevant expectations, and decision process so that people understand how readiness is assessed and who approves promotion.

Sustained performance is a claim about work over time. A large project spanning several phases can supply that evidence through repeated decisions, collaboration, delivery, and operation; several smaller projects do not automatically supply it. Dropbox’s account of impact also places greater accountability for business results on more senior roles. In the payments case, the reviewer would examine the feature engineer’s decisions and release practices across the period, including the skipped tests, rather than decide from project count or two reverts. Regular career discussions help people understand the evidence and remaining gaps. Dropbox, Google’s manager research, and the UK line management standards all emphasize such discussions. An unexpected promotion result is a reason to investigate how expectations and decisions were communicated. It does not prove that no conversations occurred: readiness assessments, new evidence, calibration, and final approvals can still change the outcome.

Calibration: aligning raters, not ranking people

Calibration gives managers a way to compare how they apply assessment criteria. GitLab distinguishes this from stack ranking and prioritizes gaps, outliers, and cases needing further alignment. Promotion candidates and changed ratings are useful starting points, with discretion to expand the discussion. Missing evidence, different work opportunities, or a disputed assessment can justify examining an unchanged middle rating too. GitLab also limits what participants share: performance-relevant evidence belongs in the discussion, while health details and confidential formal-remediation information do not.

GitLab’s expected rating distribution is a prompt for investigation, not a quota requiring managers to move people until counts fit. A forced quota can instead assign a category that the evidence does not support. For example, a rule requiring at least one failing rating in every eight-person team would do so if all eight met the performance standard. That result depends on the stated quota, group size, and category meaning; it does not follow from every distribution policy. GitLab also cautions that its Developing category is not automatically underperformance. People adjusting to a role may fall there, while its Too New to Rate category separately covers eligible recent hires.

Agreement between managers does not establish accuracy. If they all undervalue operational work, their ratings can share the same bias. The framework should recognize relevant operating and knowledge-sharing responsibilities, and calibration should allow participants to question the criteria and evidence. Cross-functional input, examples of overlooked work, and a route to challenge an assessment help make that scrutiny possible. The settlement engineer’s unchanged middle rating should remain open to examination.

Hiring: structure replaces the gut

Hiring also needs evidence against defined requirements. Google’s structured-interviewing guide describes how an early impression can lead interviewers to seek confirming evidence. Its structured interview approach combines relevant prepared questions, detailed response records, common scoring criteria, and interviewer training and calibration. These practices make decisions easier to compare and review; they do not eliminate judgment.

Google’s guide summarizes research supporting stronger prediction of job performance and smaller differences between demographic groups with structured interviewing. Its own internal studies also reported better prediction than unstructured interviews, an average saving of 40 minutes per interview from prepared materials, and a 35% higher candidate-satisfaction result among rejected candidates who experienced structured interviews. These are Google’s reported results, not effect sizes promised to another employer. Candidate experience deserves attention alongside assessment quality, including for people who receive no offer.

Before interviewing, define what success in the particular role requires. Google organizes useful attributes around role-related knowledge, problem solving, and leadership, with expectations adapted to the role. A career framework supplies common expectations, but the hiring team must translate them into job-specific requirements and evidence. An employer without a framework can still do that work through job analysis and written criteria before interviews begin. The payments company had done neither when it hired the settlement engineer through a conversation with the previous batch owner.

Developing the people you have

OPM treats development as building the capacity to perform through training, work assignments, and other improvements. A course, supervised practice, a stretch assignment, mentoring, and coaching provide different kinds of support and can complement one another. GitLab’s growth-plan suggestions include assignments as well as mentoring, coaching, and exposure to other functions. The UK framework makes capability development part of the principal developer role. For settlement work, guided experience with reconciliation and recovery would be useful because the learner needs to practice operational decisions as well as understand the rules.

GitLab separates demonstrated performance from the ability and desire to take on broader or more complex work. That makes the employee’s interests part of the conversation. Steering an engineer into management against their wishes can damage fit and retention, but a plan also has to address current-role needs, organizational priorities, available opportunities, and support. Agree what the person will work toward, who will provide help, and how progress will be checked. A request for a particular assignment is an input to that agreement, not an automatic entitlement to the opportunity.

Development also needs time and people. In the settlement case, management had assigned no colleague to learn the work. That was an organizational gap to address alongside any sharing responsibilities agreed with the incumbent. A community of practice could offer peers, shared material, and discussion, provided participants had capacity. Participation or a repository of notes would not by itself establish that another engineer could operate the batch or held authority to do so.

Succession and the single point of failure

OPM describes workforce and succession planning as identifying staffing and skill needs and building continuity. GitLab’s handbook illustrates several readiness categories: emergency cover, ready now, and readiness over longer development periods. Its emergency category concerns temporary cover of roughly six months; its ready-now description uses 90% of the role’s competence and experience. Those are GitLab’s categories, not universal operational acceptance thresholds. Define the tasks, constraints, authority, and evidence needed for coverage in the local role. Where no internal successor can cover, record an alternative such as qualified outside help or a workable division of responsibility, and validate that it can actually be used.

GitLab distinguishes a person whose absence would cause a serious operational or knowledge gap from someone designated Key Talent for performance and growth potential. The categories can overlap, but one does not establish the other. Assess the dependency regardless of the person’s rating. Knowledge transfer may reduce it; so may role sharing, tested automation, a service alternative, or safe retirement of the work. Each option needs an owner, capacity, completion evidence, and a plan for remaining risk. The settlement review had insufficient evidence for a sound performance judgment and had not examined continuity at all.

	Is a single point of failure	Is not
High performer with growth potential	Develop and retain; also fund and verify a plan to reduce the dependency	Develop and retain against agreed needs and interests
Solid performer	Recognize the contribution and address the dependency with an appropriate mitigation	Recognize the contribution and support relevant development

GitLab warns against making a person’s organizational value depend solely on Key Talent designation. Reliable work by the wider workforce also deserves recognition and development. OPM likewise describes recognition for contributions made individually and in groups. Review what a reward system makes visible: if it recognizes feature launches while overlooking operation, mentoring, or recovery, people may have less reason to invest in that work.

The payments company, one cycle later

For the next cycle, the head of engineering commissioned a career framework and agreed role-specific expectations for production operation and knowledge transfer. Managers assigned time and learners where transfer was needed. The review template gathered results, behaviors, and team contributions, with self-assessment and collaborator input. Feature counts no longer determined a rating. Calibration prioritized outliers, promotion candidates, and changed ratings, while allowing expansion for missing evidence, different opportunities, or disputed judgments. Participants reviewed performance evidence within the privacy limits.

For the settlement batch, the company arranged qualified contractor cover and assigned a second engineer to learn alongside the contractor. Six months was the planning target, not proof of readiness. Before ending contractor cover, the service owner would verify that the engineer could independently run agreed normal cases, reconcile outputs, recognize exceptions, and execute or escalate recovery under the runbook. The rules, access permissions, decision authority, and support route also had to be in place. If the criteria were not met, the company would extend or replace cover and revise the plan. The engineer had requested relevant experience; the manager agreed this assignment after checking business needs, workload, and coaching capacity. It served both development and continuity.

For two open roles, hiring managers used the framework and job analysis to define requirements before choosing questions. They prepared scoring examples, practiced independent scoring, and compared the evidence behind disagreements. The initial calibration session was a starting point; later interviews would reveal where criteria or training needed improvement. As a local decision rule, the hiring manager required written reasons for decisions that departed from the rubric scores.

The company assessed people against evidence rather than requiring a failing rating in every team. Batch incident data informed the investigation, but incident counts alone did not determine anyone’s performance rating. The second engineer’s assignment could be a valued growth opportunity while serving a risk-control purpose; participation and progress could also be recognized. Once readiness was verified, the authorized owner would grant the agreed responsibilities and record the scope, constraints, and review conditions as a delegation level. The document would record valid authority and make subsequent changes reviewable.

What a reviewer should ask

A performance and talent process can be reviewed against a short list, each item tracing to something above.

• Does each assessment explain results, behaviors, and team contributions with evidence that supports any summary rating?
• Where shared metrics inform an individual assessment, are responsibilities, authority, constraints, and observed contributions explicit, without mechanically dividing the team’s number?
• Are role and competency expectations written down, and when was their fit with current work last reviewed?
• Under the chosen promotion policy, what evidence supports the required level over time, and who makes the final decision?
• Can calibration examine missing evidence or disputed middle ratings as well as outliers, without forcing a distribution?
• Are job-specific requirements defined before interviews and connected to questions, response records, scoring criteria, and interviewer calibration? Are departures from the scoring evidence explained?
• For each critical system or role, what demonstrates that the proposed cover is ready? If nobody qualifies, what alternative is funded and what happens until it works?
• Does each critical dependency have an owner, mitigation, due date, and verification plan? Where learning is part of the mitigation, is capacity reserved and development agreed?
• Do development plans reflect the person’s interests as well as role needs, organizational priorities, opportunities, and available support?

The payments company could not defend its ratings from feature counts, and it had no tested cover for settlement operations. Better criteria and conversations helped identify what was missing. Funded learning, explicit authority, and demonstrated operating readiness were needed to close the continuity gap. Keeping those distinctions visible lets managers assess people fairly while addressing risks that belong to the organization.

References

• US Office of Personnel Management, Performance Management Cycle
• Performance Management and Accountability Playbook: Assessing and Rewarding
• What is Workforce and Succession Planning?
• GitLab Handbook, Talent Assessment
• Dropbox Engineering Career Framework
• UK Government Digital and Data Profession Capability Framework
• UK Government — Software developer
• Google re:Work, A guide to structured interviewing for better hiring practices
• Google re:Work, Following the data: The research behind great managers
• UK Civil Service, The Line Management Standards: Core stage
• Dropbox — What is Impact?
• Dropbox — Promotion Principles