A friend recently asked me about how I might define performance for web developers. It was an interesting question coming from one startup founder to another. He was concerned with how to present performance-based incentives to his developers when performance itself is so hard to measure for engineering work. I had a few thoughts to offer him and I wanted to share them here. 

What is Performance?

Engineering has a complex and difficult work flow – it happens on a maker’s schedule. Understanding this, it’s extremely difficult to determine a fair objective/set of criteria by which to measure someone. Lines of code are simply not going to cut it. So what does? Shipped stories? Defect counts? As far as I’m aware, none of these have worked.

However, if you kick the measure of performance up one level-of-altitude to overall business performance, another problem comes into play. Engineers don’t always have a direct connection to driving business value. They are charged with delivering whatever is on the product backlog in a way that is elegant, stable, and secure. Ideally, they also deliver it quickly. But whose fault is it when the backlog is less than actionable or badly organized?

So why does performance pay at all? And, when it does, who should reap the benefits?

This is an even harder question, and the answer varies from business to business. The core goal behind offering performance-based incentives is to ensure the business keeps working, and maybe even winning. This makes sense. And it probably makes the most sense to provide these incentives to people who are actually making the business win (i.e. managers and other strategic roles).

The flipside is that everyone, in theory, should be incentivized to make the business win. Let’s imagine a hypothetical scenario in which this is the case:

Step 1: Engineer looks at backlog. He realizes that the first three ideas suck.

Step 2: Engineer pushes back because he want the business to win.

Step 3: Product Manager reconsiders one of the ideas in the backlog.

Even in this scenario there are potential flaws: would the incentives actually motivate the engineer over the hump of inaction? Are incentives enough or does it take a particular archetype to motivate themselves through these extra steps? (I know engineers who will push back on tasks they don’t like, even if they’re paid $1/hr.)

What about equity?

Startups, in theory, have a built-in incentive for all employees (or most, depending on where you are): equity. If the business sells for millions, each person will get their piece.

But is that potential enough to rule out incentive pay? Probably not. In my experience, human beings are remarkably impatient. Most non-founders don’t think on the time horizon required to care about this outcome. Furthermore, even if the engineer does have the long con in mind, the average person needs small incentives to hold them over. (Imagine any video game. You don’t go from level one to sixty in one jump. You need all the levels in between to feel like you’re progressing.)

So what do you do?

I think it depends a lot on the type and scale of the business. In most creative product-focused startups, I would argue against non-stock incentive-based pay that is specific to tech goals such as lines of code, uptime, etc.

However, I DO think that operating businesses (with real revenue) can benefit from goals that everyone can get behind (i.e. a quarterly revenue or profit goal). The case for a shared bonus pool here is reasonable, and I would argue net-positive. I like P2P systems combined with management-driven allocations. So your peers and your managers decide what slice of the total bonus pool you receive.

The key here, however, is that it’s a BONUS. It’s NOT an excuse to pay someone less than they deserve.

N.B. I didn’t use the term “market rate” above. I think that market rate is a faulty concept in startup land. Startups have been systematically over-funded in a way that makes bootstrapped startups totally unfit to compete. So what the market can bear doesn’t matter. What matters is how passionate someone is about the opportunity and what they are willing to work for. Generally, equity levels the playing field here.

One final footnote: Decent bonus schemes act as a nice deferred comp plan for very early stage companies. Let’s say a new engineer wants $10,000 in annual salary, but you can only afford $7,000. You can offer that engineer $7,000 with a $3,000 bonus if the company reaches $X in revenue. This way, if you can afford it, you’ll pay it and the engineer is in a better position to bet on the company.

In short, there is some room in an early stage company for a “company-wide performance” bonus pool. But goals have to be well-defined enough for everyone to know what they are marching towards (i.e. post-product market fit). An attempt to create a bonus system before such a time seems like putting the cart before the horse. Chances are your business won’t even work – so why create complex incentive programs?