Imagine a typical performance review meeting.
A manager checks their calendar and thinks: “Uhh, not another review to deal with.” The team member is annoyed as well because they know from experience that it’s likely going to be 30 minutes wasted on reasons why the company can’t increase their salary.
On a small engineering team, this kind of meeting is worse than useless. You already talk to your engineers every day. You already know who's struggling and who's thriving. Sitting down once a quarter to formalize what you both already know is corporate theater.
So a lot of managers running small teams just skip performance reviews entirely. But that's also a mistake. Because when you skip the structured conversation, here's what happens instead:
- Problems get raised in the middle of someone's lunch
- Feedback gets delivered in passing, when it should be deliberate
- And patterns go untracked, so the same issues keep showing up
Prevention is the best medicine. And performance reviews, run well, are prevention. The answer isn't to bring corporate reviews to a small team. It's to build a different kind of meeting, one that's actually useful at this scale.
What we use instead: the Personal Development Plan
On our team, we don't have typical performance reviews. We have Personal Development Plan meetings, or PDPs.
A PDP is a focused meeting with a single team member, built around solving a specific problem or supporting a specific transition. We use them in two main situations:
- Trial period check-ins: one meeting during onboarding to make sure the new hire is the right fit and that they like working with us
- Maintenance meetings: when a problem shows up and needs to be addressed directly, not at a team meeting and not over Slack
The key difference from a corporate performance review: we don't run PDPs on a quarterly schedule whether they're needed or not. We run them when there's something concrete to work on. Senior engineers might go a long time without one. Someone who's falling behind might have two in a month.
This sounds informal, but it isn't. The meeting has a structure, the manager comes prepared, and the conversation ends with stated consequences and a timeline. That's what makes it different from a hallway chat.
The result is performance reviews that actually do what reviews are supposed to do:
- Solve problems before they harden into patterns
- Encourage your team
- And give you a record of what's been said, so you can track whether things actually improve
A PDP shouldn’t automatically feel like “you’re in trouble.” Sometimes it’s corrective. Sometimes it’s developmental. The point is focused attention: a deliberate conversation about something important enough not to leave to casual chats or Slack messages.
A note before we go further
Knowing PDPs exist isn't the hard part. The hard part is the specifics. When do you call one? What do you say when you sit down? How do you handle an engineer who pushes back, or makes excuses, or agrees vaguely and changes nothing? That's where most managers get stuck, and that's what the rest of this post covers.
Want the full guide?
Head over to Thriving In Engineering.
The premium portion of this article goes deeper into:
- The three types of PDPs and when to call each one
- The 30-minute meeting structure with three opening scripts for different situations
- How to run the consequences conversation without softening it
- The mutual feedback script that changes the texture of every
Want more like this?
I publish deeper frameworks, templates, and exclusive content on Thriving In Engineering.
Free subscribers get weekly insights. Paid members get the full framework library, eBooks, learning tracks, and live Q&As.
