Early in my management career, I sat through a calibration meeting where we ranked every engineer on the team from top to bottom. One developer had shipped fewer features than anyone else that quarter. On paper, she looked like the weakest performer. But when I thought about what actually happened during those months, the picture was completely different: she had onboarded two new hires, untangled a gnarly production incident at 2 AM, and her code reviews were so thorough that the whole team's defect rate dropped. None of that showed up in the spreadsheet. That experience broke something in me—the belief that you can capture a person's contribution in a number.
Building and shipping software is something that can be done by one person. But most software is built by teams of software developers, and in a team, work is deeply interconnected. One person's output is shaped by the tooling someone else maintained, the designs someone else clarified, and the review feedback someone else gave.
Measuring an individual's contribution is not simple because there is no single metric that can be used that can't also be abused. Worse, any metric you pick will incentivize people to optimize for the metric rather than for the actual goal—shipping valuable software.
Contextual Task Variability
- How familiar is the engineer with this area of the code?
- Are you working with a new version of a framework or library?
- Are you implementing ahead of finalized APIs or specifications?
- Does the task require refactoring?
- How difficult is writing unit, integration, and end to end tests for this software?
- How experienced with this programming language?
- Are you collaborating with others?
Every one of these variables changes the meaning of any metric you might track. Two engineers completing the same number of tickets in a sprint may have faced wildly different levels of difficulty. When the context varies this much, comparing individuals by output is not just inaccurate—it's misleading.
Team Variability
- Are you pairing with other developers regularly?
- Are tickets assigned or chosen?
- Are some team members required to go to more meetings or communicate more frequently because of their role or tasks?
- Are they bringing value in ways that don't involve coding?
- How friendly and positive is the code review process?
- How much emphasis is on documentation?
- Are people rushed to ship code?
- Is the team too focused on code quality, technology, at the expense of the customer?
These team-level dynamics shape individual performance in ways that no personal metric can account for. A brilliant engineer on a team with hostile code reviews and constant context-switching will look mediocre on paper. The same person, on a team with clear priorities and psychological safety, will thrive. You're not measuring the person—you're measuring the environment.
The Ticket Count Illusion
Consider two developers on the same team during the same quarter:
Developer A closes 30 tickets. They're all well-scoped frontend tasks in a part of the codebase they know inside and out. Impressive throughput.
Developer B closes 8 tickets. But during the same period, they mentored a new hire through their first three pull requests, reviewed 15 PRs from teammates (catching two significant bugs before they shipped), and led the response to a production incident that would have cost the company real money.
If you rank by ticket count, Developer A wins by a landslide. But who contributed more to the team's success? Developer B made everyone around them better and kept the system running. Their impact is invisible to any individual productivity metric, yet it's exactly the kind of work that separates good teams from great ones.
This is the core problem: the most valuable contributions in a team often don't look like individual output.
In my experience these questions and other introspection are way more important factors to dig into when evaluating team effectiveness and productivity.
Most modern work performance processes are highly flawed in my experience, because there's no way to build metrics and rules to see how people are performing.
Productivity cannot be measured at the individual level in software development and most knowledge work.
What to Focus On Instead
If individual metrics are broken, what should you pay attention to? The answer is to zoom out to the team level and zoom in to the person.
Measure the team, not the individual. Track indicators that reflect how the whole system is performing: cycle time (how long it takes from idea to production), deployment frequency, change failure rate, and team satisfaction scores. These are the DORA metrics—they tell you whether your engineering organization is healthy without pointing fingers at individuals.
Replace ratings with growth conversations. Instead of scoring people on a 1–5 scale, have regular one-on-ones focused on what each person wants to learn, where they feel stuck, and what kind of work energizes them. You'll learn far more from a genuine conversation than from any calibration spreadsheet.
Be a catalyst. As I wrote in my engineering management philosophy, the manager's job is to be a catalyst for speeding up the performance of each team member. Remove roadblocks. Provide clarity. Help people do their best work. That's the job—not surveillance, not ranking, not measurement theater.
Marcus Buckingham has spent his career studying how people actually work, first at Gallup and then at ADP's Research Institute. His research, detailed in Nine Lies About Work, demonstrates that when you rate another person, more than half of your rating reflects your own patterns and biases—not their actual performance. This is called the idiosyncratic rater effect, and it makes traditional performance reviews essentially meaningless as objective measurement. If you take one thing from this post, let it be this: stop trying to measure individuals and start investing in the conditions that help your team succeed together.