Team Building
The Performance Review Problem in Dual-Track Organizations
The standard argument for a unified review process across engineering and product goes like this: everyone in the organization should be evaluated on the same core competencies — impact, collaboration, growth — and the specifics of the job should be captured in the role expectations, not in the review framework. This sounds reasonable and it’s mostly wrong.
The problem is that “impact” means fundamentally different things for an engineer and a product manager, and the review process that tries to evaluate both using the same concept without acknowledging the difference ends up doing something more pernicious: it evaluates both against whichever version of impact is more visible to the reviewer. In a product-led culture, engineers get evaluated on whether their work moved customer-facing metrics. In an engineering-led culture, product managers get evaluated on whether they can speak credibly to the technical tradeoffs they’re creating. Both of those are category errors masquerading as fair evaluation.
The time horizon problem
The deeper issue is time horizon. A product manager’s impact tends to be visible on a quarterly scale — a feature shipped, a metric moved, a customer problem solved. An engineer’s most important work often has a longer horizon: an architectural decision that makes the next eighteen months of product work faster or slower, a platform investment that doesn’t show up in any customer metric but that enables a class of products that didn’t previously exist. Evaluating an engineer’s annual performance in a system calibrated for quarterly product outcomes systematically undervalues the people doing the most strategically important technical work.
The engineering leader who spent most of the year building an internal platform that product teams are just starting to use will look unproductive in a review cycle that measures impact in shipped features. The engineer who fixed three critical infrastructure problems that you can’t point to a customer metric for will look like a B-player in a review calibrated around visible outcomes. These calibration failures drive exactly the wrong people out of organizations — the ones whose work is most important over a multi-year horizon and least visible in a quarterly snapshot.
What actually works
The most functional review systems in dual-track organizations I’ve seen separate the evaluation of “what was accomplished” from the evaluation of “how strategic the work was.” The first question gets answered against role-specific criteria and recent outcomes. The second question gets answered against a shared framework for strategic contribution — one that explicitly values work whose payoff is delayed, work that enables others, and work whose absence would have been costly even though its presence is invisible.
That second category is where staff and principal engineers live, and it’s where senior product managers who are investing in the team’s capability rather than their own output metrics live. Building that language into the review framework explicitly requires the organization to develop shared judgment about what strategic contribution looks like in practice — which is uncomfortable, because it requires leaders to defend their assessments with arguments rather than just pointing at metrics.
The other change worth making is calibration across the product-engineering seam. Most organizations calibrate reviews separately within engineering and within product, then do a final pass to normalize ratings. That order of operations reinforces the separate cultures. A calibration session that explicitly compares an engineering and a product contribution — “this engineer’s infrastructure work and this PM’s strategy work are both rated ‘exceeds expectations’ — let’s make sure we’re applying the same standard to both” — forces the organization to develop shared vocabulary for what excellent work looks like regardless of discipline.
That shared vocabulary is the CPTO’s job to develop. It doesn’t exist by default. It has to be constructed deliberately, named explicitly, and defended specifically when it conflicts with the simpler metric-driven evaluation that the review system naturally pulls toward.
Tags:
Keep reading
The things nobody writes on LinkedIn
Monthly signal from leaders navigating the product-engineering merge — real decisions, real tradeoffs, no thought leadership filler.
No spam. Unsubscribe anytime.