I watched three layoff rounds. The people who stayed weren’t the “best coders”

I have been in the room for three rounds. I have also been in the hallway after, which is a different room. The story we tell in public is that we kept the strongest engineers. The list did not look like a coding contest. It looked like a map of what the company still intended to be, drawn in a hurry, with a few names attached so the remaining machines would boot on Monday.

If you want the IC side — how not to look like a pool — I already wrote who gets cut first and how I stopped looking like that person. This is the other seat: who stayed, and why “best coder” was the wrong leaderboard.

Round one: we kept the path to money

The first round was a startup that had hired ahead of a product that did not close. We cut a beautiful internal platform, two mobile experiments, and a senior who could make any language look easy. We kept a mid-level who knew the billing state machine and a quieter backend who had the only complete picture of the webhook retries. Neither would have won a puzzle-off. Both could answer “what happens if we take this name out” with a customer-shaped sentence.

The senior who left was, by my lights, the better programmer. They also lived on a bet we had already walked away from in a board deck they had not been shown. Skill did not lose. The map did.

I learned to ask, before I argued for a name: are they on the path that still takes money, or on a path we already called optional in a room they were not in. If I could not answer, I was arguing aesthetics.

Round two: we kept coverage, not brilliance

The second round was a later-stage company that needed a number. We had a staff engineer who wrote the kind of code I would still steal. We also had two people who could run each other’s on-call and had already documented it. We kept the coverage pair. We let the staff engineer go because their surface was a future platform and the number did not care about futures that week.

I hated that list. I still think it was the list a scared company writes. I also think “best coder” would have been a lie if we had kept the staff and lost the pair. Monday’s pages would have had one hero and no bench. Heroes look good in a blog post. They look thin at 3 a.m. when the hero is the one you just paid to leave.

Coverage is not mediocrity. Coverage is two people who can ship the same noun. The people who stayed were the ones who had already made themselves less special in the hostage sense and more special in the bench sense.

Round three: we kept the people who could still ship with the lights off

The third round came with a hiring freeze already in place. We did not have backfill. We kept people who could wear two hats without theater: an engineering manager who still merged, a frontend who could own the BFF, a data person who could keep a pipeline up without a team of five. We cut specialists whose specialty had become a slide. We cut a very good coder whose entire output was a rewrite nobody had scheduled for the next two quarters.

The remaining team was not the highest-rated on our old calibration. Calibration had rewarded complexity. The week after the round rewarded people who could close a ticket that touched money without a design review that lasted three days. I am not anti-design. I am anti the fantasy that a cut company is still the company that had time for the rewrite.

One person who stayed wrote average code and excellent incident notes. Another wrote excellent code and disappeared in incidents. We kept the notes. I will defend that to a conference. Incidents are the product when you are smaller. Code quality still matters. It is not the only column, and in a cut it is not the first column.

What “best coder” hid

Best coder often meant fastest at a certain kind of problem, or highest leverage on a system we were about to stop loving, or most impressive in a review that directors never read. It rarely meant “owns the noun that is still on the homepage.” It rarely meant “can teach the next person this week.” It rarely meant “will not make the remaining people afraid to ask.”

I have also seen “best coder” used as a shield for people who were difficult in rooms. Sometimes they stayed because we were scared of the system in their head. That is a different failure: we had allowed a hostage. When they stayed, the team paid in silence. When they left in a later round, we paid in recovery. Neither is a model I want. The stay list should not reward hoarding. It should reward a bench.

What I look at now, if I have to look

If I am ever in that room again, I will write four columns before names: what still makes money, what still pages, what we have already killed, who can cover whom. Then I will put names in. If a name has no column, that is information. If a name is in a killed column, that is a conversation I should have had in public months earlier, not on the list.

I will not use performance scores as the first sort. Scores lag. They reward the last calibration’s fashion. I will use them as a tie-break when two people sit on the same live noun and one of them is harming the bench.

I will not pretend the list is merit. A number is a number. Merit is what you owe the people after, in references and in honesty about why the map looked like that. I have failed that honesty. I am trying not to fail it again by writing this down.

The week after, which is also a tell

Who stayed was only half the story. Who could still decide was the other half. After the first round, the people left on the money path started saying no to work that used to be automatic. That was health. After the second, a remaining hero tried to own every page and burned out in six weeks. We had kept coverage on paper and then let one person eat it. After the third, the manager who still merged became the bottleneck because we had not named a second reviewer. The stay list is a start. The week after is the design review you skipped.

I now treat “who stays” as “who can run the smaller company on Monday without a secret second org chart.” If the answer depends on one person’s nights, we did not keep a team. We kept a fuse.

I also watch who gets the ugly work after. If the remaining “best culture” people dump the night job on the quiet owner who stayed, we have reproduced the pool in miniature. I have had to stop that dump out loud. It is easier to stop when the noun is written down. It is harder when we told ourselves we kept the best and therefore the leftovers are someone else’s problem.

What I tell people who ask if they should get better at code

Yes. Get better at code. Also get a noun, a backup, and a paragraph your manager can say. The people who stayed were not worse at programming than the people who left, on average. They were more attached to a live path and more replaceable in the healthy way. The “best coder” myth is comforting because it suggests a contest you can train for. The room is not a contest. It is a map. Train for the map. Own a piece of it that the company has not already crossed out. Teach someone else the piece. That is not a guarantee. It is the only pattern I have seen three times that was not a coin flip dressed as talent.

If you manage, stop telling the remaining team they are the best. Tell them what the map is now, what is dead, and who covers whom. Pride is a poor runbook. I have used pride. It lasted until the first page. Then people needed the columns I should have written when I wrote the list. I write the columns first now, even if I hope I never use them. Hoping is not a staffing plan. The three rounds taught me that. They did not teach me that the best coder wins. They taught me that the live path wins, and that we should have said so before the hallway filled up.