There is a performance management problem hiding in plain sight inside every organisation that has moved to product aligned engineering. It does not show up in your quarterly reviews, your talent calibration sessions, or your engagement surveys. It accumulates quietly, year on year, in the gap between what a grade actually means and what a manager is actually capable of knowing. I call it captive gratitude, and once you see it, you cannot unsee it.
1. The Captivity Problem
When you embed technologists inside product teams, you are making a deliberate organisational choice. You want engineers, designers, and QA professionals to feel the pull of the customer problem, to sit alongside product managers and be accountable to outcomes rather than outputs. That logic is sound. The unintended consequence is that your UX designer now reports to a product lead who has exactly one UX designer in their world. Your two Java engineers are the only Java engineers that product lead will ever manage. Your frontend engineer exists, from that leader’s perspective, as a singular and irreplaceable atom.
When appraisal season arrives, that product lead faces a structurally impossible task. They are being asked to rank and rate people they have no comparative basis for evaluating. They know whether their Java engineers shipped on time. They know whether the UX designer was pleasant to work with and whether the designs looked good to them. What they cannot know is whether those same people are in the top quartile, the median, or the bottom third of their profession, because they have never managed anyone else doing the same job.
The result is captive gratitude. Because you depend entirely on this one person to do this one thing, you are unconsciously biased toward protecting them, affirming them, and rating them generously. It is not corruption. It is not favouritism in the traditional sense. It is the entirely rational response of a manager who knows that losing their only frontend engineer would be catastrophic, and whose brain has quietly decided that the safest way to retain them is to tell them they are excellent.
2. Two Kinds of Bias
The problem is not symmetrical, and that asymmetry makes it harder to correct. Product heads and technology leaders bring fundamentally different distortions to the appraisal table, and when you embed technologists inside product teams, you hand the appraisal pen to the product head by default.
Product leaders tend to bias toward speed and relationship. The engineer who shipped fast, who said yes readily, who never created friction in the standup, who made the product manager’s life easier — that person reads as excellent. The engineer who pushed back on timelines, who raised technical debt concerns before agreeing to a feature, who occasionally slowed the team down in pursuit of something more durable — that person reads as difficult, even when they are objectively the stronger technologist.
Technology leaders, by contrast, tend to bias toward quality and operational excellence. They notice the engineer who refactors before adding features, who writes tests that actually catch regressions, who thinks about the person who will be on call at two in the morning six months from now. They can spot the difference between code that works and code that will continue to work, and they weight that difference accordingly.
Neither lens is complete on its own. But when the product bias is the only lens available, you systematically undervalue craft and overvalue agreeableness, and your strongest technologists are the first to notice.
3. Why Pools See Clearly
The traditional alternative to product embedding is the functional pool: all your Java engineers in one chapter or guild or centre of excellence, managed by someone who has spent a career around Java engineers. The critique of this model is well rehearsed. Pooled engineers feel distant from the customer problem, optimise for technical elegance over business outcome, and become a shared services backlog that product teams resent.
But pools have one capability that embedded models destroy almost entirely, which is the ability to compare. When a technology leader manages twelve Java engineers, they can see the distribution clearly. They know who writes the clearest code, who mentors most effectively, who handles ambiguity with the most composure, who grows the fastest under pressure. That comparative baseline is not a luxury. It is the foundational requirement for a performance conversation that is honest, fair, and developmentally useful.
Without it, you are not doing performance management. You are doing performance theatre.
4. The Rotation Prescription
The solution is not to abandon product alignment. The embedded model produces real benefits and reversing it would simply trade one set of problems for another. The solution is to deliberately and systematically restore the comparative lens by moving people across team boundaries in structured, lightweight ways.
The mechanism is rotation. Not reporting line changes, not reorganisations, not secondments that last a year and feel like exile. Short cycle, intentional swaps where your UX designer spends three weeks on another product team’s project, or your senior Java engineer contributes to a communities of practice initiative that puts them in the room with their peers from across the organisation. The rotation does not need to be full time. Two days a week for a quarter, or a single project based assignment, is enough to generate the comparative signal that your appraisal process is currently missing.
When your UX designer works alongside the UX designer from another team, both managers suddenly have something they lacked before: a reference point. When your Java engineer presents at a community of practice and fields questions from their peers, their technical lead sees them in a context that product delivery alone never provides. The comparison is not punitive. It is informative, for the manager, for the individual, and for the organisation’s understanding of where genuine strength actually lives.
5. Making It Practical
The objection will be immediate and predictable. Product managers will say they cannot afford to lose their people even part time. Delivery schedules will be cited. Commitments will be invoked. This objection should be taken seriously and then overruled, because the cost of captive gratitude compounds in ways that are far more expensive than a two day weekly rotation.
The practical implementation requires three things. First, a deliberate rotation calendar owned at the technology leadership level, not left to goodwill between product heads. Second, communities of practice that are genuinely resourced, with time allocated in people’s capacity plans rather than treated as something that happens after hours if people feel like it. Third, appraisal processes that explicitly require input from managers outside the home team, so that a rotation is not just a development gesture but a governance requirement.
The goal is not to create instability or to undermine the coherence of product teams. It is to ensure that when you sit across from someone in their annual review and tell them where they stand, you actually know. Captive gratitude feels kind in the moment. In the long run, it fails the people it is trying to protect, because it denies them the honest signal they need to grow, and it denies your organisation the accurate picture it needs to invest in the right people.
Gratitude that is genuinely earned does not need to be captive. It survives the comparison.