The People System

A few years ago I hired a senior engineer into a team that was stagnating. Nobody was lazy - they were just comfortable. Same pace, same patterns, same ways of doing things for too long.

When the new engineer started shipping, things shifted. Velocity went up. Architecture conversations got sharper. Most of the peers took it as a challenge and started catching up. A couple of them didn’t. They saw the bar had moved and they didn’t want to move with it. A few months later, they both left on their own.

I didn’t run a cleanup campaign. I didn’t ask anyone to leave. I hired one person and the rest of the system adjusted.

When those two engineers left, I expected velocity to drop. It didn’t. Work got reassigned. Took a couple of weeks to realign. That was it.

I don’t believe in 10x engineers. I do believe there are engineers who shift what a team thinks is normal. And when that happens, hiring and retention stop being separate problems. They’re the same system, measured from different ends.

Table of contents

Hiring is the inlet, not the system

Everyone obsesses over hiring. Rubrics, scoring sheets, interview guides, calibration sessions. I’ve built all of those. They help. They don’t catch what matters most.

A mobile developer passed my rubric cleanly. Good coding, good hiring manager call, good culture interview. During probation, he turned out to be a jerk. Rude with peers. “I know best” every time someone disagreed.

A machine learning engineer scored 100 out of 100 on the technical interview. During probation: zero interest in the business, socially awkward in a way that would have been fine at a big company. We were not a big company.

Another ML engineer scored right at the passing line. We needed the role filled. In the interview they were warm and asked about the business. During probation, they shipped nothing. Good at explaining, good at teaching. Not at doing.

A QA engineer looked perfect in every stage. During probation, talking to them in person felt like talking to an NPC in a video game. Every ticket, every doc, every message was AI-refined. In person, they didn’t know how to speak.

Every one of them passed the rubric. The rubric isn’t broken. It’s just not the full system.

And sometimes it goes the other way. I once interviewed someone who didn’t finish the system design exercise. Longwinded. Got through maybe half the evolutions I usually run. When we flipped to their questions, the questions were sharp - real interest in the business, the team, the problems. I took the bet. The first team didn’t warm up to them. So I moved them to a different team with a mid-sized initiative to own. It worked. They grew into one of the strongest contributors in the department.

Onboarding is where the system either works or doesn’t

Onboarding docs go stale fast. My fix is simple: every new hire has a task to refresh the onboarding doc they used. The laptop setup guide becomes a living document. New people get a working doc and the next person gets a better one.

That solves the doc rot. It doesn’t solve the real problem - onboarding plans quietly die around day 40. Engineers get pulled into sprint work and stop touching the 30-60-90 plan. They tell themselves they’ll come back to it. They don’t.

So I add checkpoints. Every 30 days, the new hire prepares a presentation. Each 30-day block has a theme: Foundation, then Ownership, then Impact. Presentations run at the team level, sometimes at the department level if the material is useful beyond the team. I’m in the audience every time. The diagrams some new hires draw during this exercise end up being reused for the next wave.

Checkpoints do something small that isn’t small. They make onboarding visible. You can actually see if it’s happening. Without the checkpoint, onboarding becomes a story both people tell themselves.

The other piece is the onboarding buddy. Pick any engineer, say “you’re the buddy”, and it quietly fails. What works is pairing the buddy and the new hire through the same plan, with a written guide of what “buddy” actually means - pair on code, answer first-line questions, keep simple questions out of global channels, escalate the things that need a manager. And rotate buddies. One engineer doing it every time burns them out and robs everyone else of the experience.

When did your last new hire’s plan quietly die - day 20, day 40 or day 60?

Growth: the board between you and your report

For over a decade I’ve kept a small private board with each direct report. Competencies from the career ladder organized to their strength level. Evidence - from both of us - in each competency.

I add feedback. They add evidence. It’s open. We both add to it between 1:1s or in quarterly reviews.

The board is doing something bigger than tracking. It’s making the review conversation un-surprising. And yet I’ve still had reviews where someone got “Meeting expectations” and was surprised. In those moments we don’t argue the rating. We open the board. Walk through the feedback. Walk through the gaps. The emotion drops because the evidence is already there.

I’ve also learned that most engineers don’t understand 80% of their own career ladder. The definitions are written for HR, not for the person being evaluated. I’ve built expanded versions with examples for each competency. Growth plans stop being guessing games after that.

A quick note on Staff Engineers. At one company I interviewed all seven Staff Engineers to understand their actual day-to-day, because I was building a growth plan for a Tech Lead aiming at Staff. Almost all of them were operating as Senior engineers inside their teams. The company’s Staff definition didn’t match what any of them were actually doing. I had to redefine the role from scratch before I could write a growth plan that wasn’t fiction.

If your career ladders describe a fantasy version of your company, your people system is running on bad inputs.

One more note on growth at the top. The best leaders I’ve worked with came up inside the company, not from outside. A hire from outside closes a gap in weeks but imports another company’s assumptions with it. A leader grown inside already carries the team’s trust, the team’s language and the team’s failures. Buying talent is fast. Growing it is durable.

Has anyone on your team ever been surprised by their review rating?

Letting go is part of retention

People talk about retention like it’s only about keeping the good ones. It’s also about who you keep past their fit.

I had an engineer whose work was quick but dirty. “My way only” on every discussion. Weak communication. Peers started quietly rerouting work to avoid them. I collected the feedback, had a few 1:1s, gave it directly. They accepted it, agreed to try new practices. Then they stopped showing up. Offline in Slack. No standups. HR reached them - they didn’t want to come back. They resigned.

Another one. An ambitious engineer pushed hard to become a Tech Lead. I said no - they weren’t operating as one. Local communication, slipped deadlines, hoarding the interesting work, solutions that often needed rework. My manager’s manager overruled me. They got the role. Three months later the team was underperforming. Every concern I’d raised accelerated instead of improving. We put them on a PIP with clear goals. They hit all of them. Two months after the PIP ended, the regression came back. We let them go.

Both stories teach the same thing. Keeping the wrong person costs the team. The people around them can see it. They adjust - reroute, hold back, stop offering their best work. Some of them eventually leave too.

Retention isn’t about everyone staying. It’s about the right people staying and the system being honest about who’s actually contributing.

Who are you keeping because it’s easier than the conversation?

What to do after reading this

Sit down. Define the inputs your people system is running on right now - not how you wish it ran, how it actually runs. Sourcing channels. Interview process. Onboarding plan. Career ladder. Performance review cycle.

Then write three gaps in your own understanding of that system. What you don’t really know about how people join your org, grow in it and leave it.

Then pick three gaps you’ll close in the next five months.

Not because five months is a magic number. Because the people system moves on a delay and five months is roughly how long it takes for a real change to show up in the signal.

Appendix: People System Diagnostic Reference