The rockstar who wouldn't write a doc

A CTO described his strongest engineer to me as a rockstar. The engineer's output ran about 2x the rest of the team. His architectural decisions were sound. He'd built the 3 most critical systems in the product. The CTO loved him.

None of those systems had a runbook. None had API documentation. The architecture decisions lived in his head. New hires were told to go ask him. He'd become the team's documentation in human form, and the team had gone structurally dependent on his availability in a way that wouldn't survive his next vacation, never mind his eventual departure. It's the runbook that only exists in one person's head, with a person's name on it.

The rockstar framing is one of the most expensive labels a company can adopt, because it rewards the behaviors that keep the team from scaling. The engineer who ships more by skipping documentation is producing a quarter of velocity and a year of debt. The debt is invisible because the person who created it is also the only one who can navigate it. The cost becomes legible the moment somebody else has to.

The unilateral bet underneath the behavior is that the company will always need the engineer. That bet is occasionally correct and almost always damaging. It turns a high-performing contributor into a single point of failure with leverage. The leverage is real: the company can't fire them, can't let them leave easily, can't move them off the critical systems, and the engineer often doesn't consciously realize they built it.

So the answer isn't a documentation policy. Policies fail because they don't change the underlying incentive. What changes it is redefining what rockstar means. A senior engineer isn't the one who ships the most code. A senior engineer is the one who produces the most leverage for the team: code other engineers can extend, decisions they can find, systems they can operate without escalation. A shared place the knowledge lives beats a person you have to interrupt.

Performance reviews have to carry this. If documentation isn't in the rubric, it doesn't exist in the engineer's calculation of what to do with the week. If onboarding velocity for the engineers they mentored isn't measured, the senior engineer has no reason to make it good. The criteria you grade against are the criteria that get optimized. Almost every documentation problem is, underneath, a performance-review problem.

The conversation with the rockstar is direct. The systems you built are critical. The team can't operate them without you. That's a feature for you and a vulnerability for us. Next quarter's review measures how much of that vulnerability you've removed. Some engineers hear it and respond. Some refuse, and the refusal is the data. After the refusal, the cost of keeping them runs higher than the cost of replacing them.

Rockstars don't scale. Engineers who produce leverage do. The bill for the difference comes due the week the rockstar is on a plane and a customer is down.