Thinksum

Performance Reviews in Start-ups

(the following refers specifically to performance reviews for software and QA engineers)

Here's a question:  are performance reviews antithetical to a start-up environment?

I don't think so.  As long as the group is big enough to have a manager or leader, then I think performance reviews can be useful.  I do think, however, that performance reviews are more dangerous at a start-up.  The big difference between a big company and a small company is that at bigco individuals don't matter as much (sorry to my friends who work in bigcos but it's true).   But at smallco and start-ups, individuals make all the difference.  Performance reviews done badly can set people off, alienate them from each other or the company, and fracture rather than help to fuse the team.  In a start-up that's not just bad, it's disastrous.

The thing to be clear about in a start-up, if you are going to do performance reviews, is why.  There's only one good reason I know of to do them in a small company -- as a way to mentor people on how they can work better individually and as a team.

And the worst mistake I know of (actually I believe this is a mistake for software teams in bigcos too) is to attach performance reviews directly to compensation.  You can't mentor someone when they're thinking "I'm getting screwed on compensation because this bozo gave me a 5 when I should have gotten a 9."  And nothing is more likely to fracture that fragile relationship between the individual, the team and the company.

Which raises another question:  how can you keep performance reviews and compensation rewards separate, especially when for many companies they're done at the same time of year?  I have two rules of thumb I use to keep them separate:

1. Decide on compensation changes before working on performance reviews;
2. Never adjust compensation changes after doing performance reviews.

It's sort of a Karate Kid thing:  rule #2 is "see rule #1."

Does that sound crazy?  I've found it works.  Compensation changes are based on what's fair for each individual as a result of team success (and company success) and the person's relative position in the team.  Performance reviews are based on the key messages you want to communicate to individuals about what matters, what doesn't, where they're doing well and where and how they can improve.

Here's an example:  I had an engineer who was working for me who was underpaid relative to his position in the team.  He wasn't underperforming, although he wasn't overperforming either.  In terms of performance if we did a stack-ranking (in a high-performing small team) he was in the lower 25%, but in terms of percentage raise he ended up at the top.

His performance review was fair (and received as fair) because it correctly reflected areas he needed work.

His raise was fair (and received positively by him) because it just brought him in line with where he should be relative to his position in the team.  And I didn't have to worry about other team members finding out about his percentage raise, because I knew it was fair and I could defend it (and they received fair raises too).

In this process, he learned that performance reviews and compensation are two separate things, and that helps him (I believe) receive the performance messages more clearly and openly, now and in the future.

The key word here is trust.  Trust is established by treating people fairly, and not creating over-complicated or unnatural performance rating systems that attempt to justify compensation decisions.  If performance reviews are really honest mentoring efforts, then they can be an asset in any size team.

Hiring Outside Managers in a Startup

TNT is experiencing some growth, and in engineering this is creating the need for more management.  In any company, when you need more management, you either shift some folks from individual tasks to partial or full management, or you bring in someone new from the outside.  In a startup like TNT, this decision is particularly crucial.

In a startup, where in most cases you are strapped for people, every individual has crucial responsibilities.  If you shift someone to management, then you are reducing the time and energy they have for individual tasks.  While team members may want to gain management experience, the trade-off may not be acceptable for the overall product and company (unlike a bigger company where the results of individual changes can more easily be absorbed).  Also, appointing someone a manager over someone else who was previously a peer is always a bit risky, but can be really prickly in a small team in a small company (it usually means a raise, for instance, and in a startup the salaries and raises are necessarily limited).

But if you bring in someone from the outside, then you risk upsetting team chemistry and frustrating key team members who wanted to manage themselves.  Again, in a startup, team chemistry is particularly crucial.

When natural leaders have emerged within an existing team, they may be able to assume part of the management responsibilities without upsetting team chemistry or productivity.  We've done this successfully at TNT and I've seen this done quite successfully elsewhere in the past.  The natural leaders are not necessarily the most experienced people on the staff, but they're the ones with the best combination of experience and drive, and who in various situations have demonstrated leadership skills and who have come to be seen by the team itself as leaders.

But when no natural leaders emerge in areas that need more management, my experience is that it's better to look outside than to try to groom someone inside into the manager role (I'm saying this specifically for startups -- in a more mature company I would offer different advice).

Needless to say, this is a crucial hire and must be made extremely carefully.  The key, I believe, is that the team respect the individual.  In an engineering team, this means that the manager must be at least as intelligent as the team members, and must clearly have more experience in the specific area that would qualify them as a manager.  During interviews, if this is not clearly the case, and if questions remain about the candidate, then it's better to keep looking.  With individual contributors even in a startup you can take some risk, but with a manager (even the manager of a small team) you need to be sure.

Proof that someone is working really hard

I know my friends at Clearspring are working really hard trying to change the world with semantic portals, but here's the proof.  Hilarious (maybe a little frightening too).