Performance Reviews for Engineers at a 20-Person Startup: Lightweight, Honest, and Actually Useful

Most founder-led companies skip performance reviews entirely. The reasoning: "We're small, we talk to people constantly, we know who's good."

That's how you end up with a senior engineer who thinks they're crushing it and actually isn't, a junior engineer who's been stuck for six months without realizing it, and a payroll decision in Q4 where someone gets paid 30% less than they deserve because nobody ever said it out loud.

I've run performance reviews at three-person startups and 300-person companies. The mechanics change. The principle doesn't: a great performance review is a conversation that surfaces truth and unlocks growth.

When you're small, you can't hire an HR person to run this. So you design something that actually works for operator teams.

The Stakes: Why Tiny Companies Need Reviews

You might think: "Our team is tight, everyone knows everyone, why do we need to formalize this?"

Here's what actually happens without structure:

Feedback becomes personal instead of behavioral. Instead of "your code reviews could be more constructive," you hear "you're hard to work with." The engineer gets defensive. Nothing changes.
Compensation drifts. You hired Sarah as a junior engineer 18 months ago. She's now the most productive person on the team, but nobody's adjusted her compensation. She'll leave. You'll be shocked.
Growth feedback only flows one direction. Juniors rarely tell their manager where they're stuck. Engineers don't know what good looks like at your company. By the time you realize someone's not growing, they've already mentally checked out.
Firing becomes harder. When you finally decide someone isn't working out, they're blindsided. "But nobody said anything!" Yes, they did, in casual comments, but never formally. Now you have a legal exposure and a team morale hit.
Your culture gets weaker every hire. New engineers don't know what excellence looks like because nobody's defined it.

Performance reviews aren't bureaucracy. They're how you tell people the truth in a structured way.

The Framework: A Three-Pillar Review System

I run performance reviews built around three elements: calibration, structure, and honesty.

Calibration: Define What Good Looks Like

Before you review anyone, you need to know what you're measuring.

At a 20-person company, I typically define four levels:

Level 1 (Learning): Ramping up. High potential but limited independent ownership. Needs clear direction and feedback. Early career or new to your domain.

Level 2 (Solid Contributor): Independently drives their area. Executes well. Consistent quality. May need support on ambiguous problems. This is a healthy state for someone in their first 2-3 years at your company.

Level 3 (Senior/Multiplier): Owns major systems end-to-end. Raises the bar for their team. Mentors others. Operates with less direction. Can take ambiguous problems and turn them into clear solutions.

Level 4 (Lead/Architect): Sets technical direction. Influences company strategy. Owns multiple senior-level engineers' growth. Rare at a 20-person company; usually you have one.

Don't overthink this. These aren't formal levels with promotion committees. They're clarity on how you think about people. Use whatever language makes sense to you.

Then define what each looks like in your context:

Code Quality: What does "solid code" mean? Do you value test coverage? Documentation? Speed of shipping? Be specific.
Execution: Can they break down a vague problem and ship a solution? How much guardrails do they need?
Communication: Do they write clear PRs? Participate in design reviews? Help unblock others?
Collaboration: Can they work well without being managed? Do they make the team better?
Growth Orientation: Are they learning? Teaching? Taking on harder problems?

Write this down. Share it. New engineers should know on day one what excellence looks like at your company.

Structure: The Actual Review Process

Here's how I run a performance review for a small team:

1. Self-review (engineer completes, 30 min)

What are you most proud of from this period?
What's been harder than you expected?
Where do you want to grow?
What support would help you do better work?

This isn't a resume. It's reflection. It surfaces what the engineer actually cares about and where they see gaps.

2. Manager prep (you gather data, 30-45 min)

What code did they write that was exemplary? What was rough?
How did they handle a hard deadline or ambiguous problem?
What did teammates say when you asked "how's it working with them?"
Are they growing into harder work or stalling?
Compensation question: would you rehire them at their current salary? (If no, that's honest feedback.)

Don't just rely on memory. Look at PRs. Check Slack history. Ask other people on the team.

3. The review conversation (45-60 min)

Start with the self-review. Listen. Then deliver your assessment:

What's going well: Specific examples. "Your API design for the messaging system was really clean. It made it easy for the frontend team to integrate." Not "you're great at architecture."
Where there's opportunity: Frame it as growth, not failure. "I'd like to see you take more initiative on breaking down ambiguous specs. You always wait for me to clarify, and I think you'd surprise yourself with how many you could solve independently."
What support they need: Be concrete. "I'm going to pair with you on the next ambiguous task" or "I'm going to have Sarah spend 2 hours with you on our deployment process."
Compensation: If it's a raise, say it. "You've moved into solid contributor territory, and your market rate has shifted. We're bringing you to [X]." If there's no raise, explain why. "We're staying even, but I want to revisit this in Q2 once the project is done."

End with forward-looking clarity: "In six months, I want to see you owning the API work end-to-end without my review cycle. Here's what that means..."

4. Follow-up (ongoing)

A review that sits in a document is useless. You follow up:

Reference it in 1:1s
Check in on the growth areas
Celebrate wins
If someone's not hitting the mark, have the hard conversation sooner rather than later

Honesty: When Reviews Demand Truth

This is where most small teams fail. You're nice. You like your people. So you write reviews that are vague and positive, and six months later you're shocked that someone's not working out.

Here's what I tell founder-led teams: a great review is kind and honest. They're not mutually exclusive.

If someone isn't cutting it, you say it. "You've been here eight months. I see potential, but right now the code quality isn't meeting what I need from a backend engineer. Here's what needs to change: better test coverage, and we need to see more initiative on problem-solving. I'm going to support you with [mentor/training/whatever], but I need to see improvement by July. If we're not there, we'll have to make a change."

That's not mean. That's clarity.

If someone's crushing it but not growing, you say that too. "You're reliable and consistent, which the company needs. But I'm not seeing you take on harder problems. I think you have more in you. How do you feel about it? What would help?"

Concrete Example: How a Review Prevented a Departure

I was working with a Series A company. Their backend lead, Marcus, had been there for a year. The founders saw him as solid but not exceptional. He wrote competent code, showed up, wasn't flashy.

In a formal review process (which they'd never done), it surfaced that Marcus felt invisible. He didn't know what "good" looked like at the company. He'd taught himself three new systems without being asked, but nobody had noticed. He was thinking about leaving.

In the review, his manager explicitly said: "You've taken on way more responsibility than the role definition suggests. You've mentored two junior engineers in ways I wasn't even seeing. Your instinct on our API design turned out to be right. I've been under-appreciating the work. We're moving you into a senior role, raising your comp, and I'm going to make sure you're visible in how the team works."

Marcus stayed. His trajectory changed. The company kept a person who could have become a great hire for a competitor.

That's what a good review does.

The Counterpoint: When Reviews Become Theater

I've seen teams build elaborate review systems: 360-degree feedback, calibration meetings, rubrics that are 40 pages long. At a 20-person company, this is cargo-cult management. You're doing the form without the function.

The risk is that reviews become a checkbox. You go through the motions, say nice things, and nothing actually changes. Or worse, you create a culture where people are afraid of feedback because the formal system feels like an evaluation rather than a conversation.

Here's what prevents that:

Keep it simple. A self-review, a manager assessment, a 1:1 conversation. Done.
Make it a real conversation, not a presentation.
Actually follow up. It has to change how you lead the person.
Use it to inform decisions (comp, projects, growth) not just to document opinions.

Where I Come In

I help teams design lightweight performance systems that actually drive behavior change and retention. Whether you're 10 people and have never done a formal review, or you're scaling from 20 to 50 and your old process is breaking, let's build something that works for your company. I'll work with you to define your levels, design your cadence, and run your first round of reviews if you want a template and calibration.

Action Checklist

Define three to four performance levels and what each looks like at your company.
Identify the five behaviors most critical to your engineering culture (e.g., shipping velocity, code quality, mentorship, collaboration).
Create a simple review template (self-review prompt, manager sections, conversation notes).
Schedule reviews for everyone on the team. Do them all within a two-week window to maintain consistency.
Prep data for each person: PRs, feedback from teammates, specific examples of what they've accomplished.
In the conversation, lead with what's going well, then growth opportunities, then comp/career.
Schedule a follow-up in three months to check progress on growth areas.