I recently had a discussion on Slack about variable pay (bonuses) for tech roles. I've always found it counterproductive — I briefly mentioned it in a previous post about measuring engineering team performance:

$ echo

>

I should mention that I'm generally not in favor of variable pay for engineering roles. At least not before staff engineering level and above, but that's not the point of this post so I won't elaborate.

Let's elaborate now.

TL;DR

Variable pay for tech roles isn't common practice, and it's generally perceived negatively by engineers — rightfully so, in my opinion. It becomes an obstacle during hiring.

Unless the variable is added on top of market rate.

In practice, it also creates ongoing tension between managers and employees when there are no objective and relevant criteria for awarding bonuses.

Perks like additional PTO based on tenure, conference budget, learning stipends, etc. are far more effective at building a lasting relationship.

The difficulty of finding relevant criteria also makes variable pay counterproductive — either because it misaligns individuals in what is naturally a collaborative activity, or because it incentivizes gaming the metrics meant for continuous improvement.

Using equity (stock options, RSUs) or profit-sharing mechanisms is, in my view, a much better way to align individuals with company success.

Variable pay is a hard sell during hiring

Let's start with the basics: why do companies offer variable pay?

For the company, it's mainly about motivating employees to go the extra mile in order to earn a higher salary.

For the employee, there's significant risk involved. Variable pay isn't guaranteed. It's typically excluded from income calculations when applying for a mortgage or renting an apartment. Banks look at your base salary, not your OTE.

And that's my first argument against variable pay.

In today's context — where variable pay is uncommon for tech roles, the market is tight, and salaries are high — you lose a lot of attractiveness if the variable component just compensates for a lower base.

A dev will systematically choose $180k fixed over $150k fixed + $30k variable(all other factors being equal). Why would they do otherwise?

Now, you might argue that variable pay can allow someone to significantly exceed market rate.

And yes, if the variable is added on top of market salary, it can become attractive.

For example: $180k fixed + $30k variable.

But let's be honest — this is rare. Most companies align with the market and then carve out a portion to make it variable.

Bottom line: it generally doesn't add to your attractiveness and makes the offer stage of hiring risky.

It's a constant source of tension with the manager

If it's harder to recruit with variable pay, it's also a source of tension between managers and employees since you need to regularly set and update objectives.

For sales roles, it's considered straightforward — variable pay is proportional to sales volume.

In tech roles, it gets complicated. The job is inherently team-based and creative. You can't easily measure individual success, and devs don't (thankfully) get paid per line of code.

At a previous company, I was often told that "bonuses were almost always given" and that "if you didn't get it, you should consider leaving because either the company was doing badly or it was a hidden message." Basically, withholding the variable was used as a roundabout way to push people out.

Personally, I much prefer clear messages. If something's wrong, I shouldn't have to guess — we discuss it and decide together. Using variable pay this way is cowardly management.

If you want to set up a system to encourage people to stay, there are many more effective options:

• Work environment (good equipment, quality office in a good location, or remote work)
• Mission and meaning of the work
• Continuous learning budget (conferences, traditional training, online courses, etc.)
• Equity that vests over time (you acquire portions progressively)
• Benefits that accrue with tenure (additional PTO, for example)

(non-exhaustive list)

Variable pay is counterproductive

But let's get back to how variable pay is calculated. To have variable pay, you need to tie it to an objective.

First scenario: individual objectives tied to a specific project.

This often leads to absurd situations. Projects get abandoned because they're no longer relevant, scope changes, the person is no longer working on it, etc.

And when I talk about counterproductive situations: in the past, as an individual contributor, I had the choice between continuing on a project (relatively small and less useful than expected) to get my bonus at the expense of the team, or abandoning it to focus on more relevant topics at the expense of my bonus.

In short, you create a conflict between (very) short-term and long-term interests.

(Have you never seen a situation where, after discussion, everyone agrees that a project is actually problematic for the company, but a few people whose bonus depends on it keep defending it?)

Second scenario: those who try to rely on quantitative metrics not tied to specific projects.

Sure, what could be more natural than looking for individual measurement tools?

In a company, you want a reliable, fair, objective, and consistent tool to measure performance. What better than quantitative data? The intention is good.

However, I could quote a famous law:

$ echo

>

When a measure becomes a target, it ceases to be a good measure.

Goodhart's Law

As I mentioned in the post about measuring performance, these tools are meant for continuous improvement of a team. As soon as you start using them to calculate bonuses, things go sideways because the whole game becomes about gaming the numbers.

I have plenty of amusing anecdotes about this... And I could spend a long time explaining how you can game individual metrics at the expense of the collective.

In any case, a developer works within a team and a strategy. Their success depends on others.

Introducing an individual bonus misaligns people's objectives. It's demotivating and a constant source of conflict.

Team-based bonuses might seem to solve this, but as soon as you apply them only to the dev team, you shift the problem by misaligning them with the rest of the company (customer support, marketing, sales, etc.).

Note: I'm not saying you shouldn't track individual performance (I mentioned it in the post about tracking tools). But this tracking should be both quantitative and qualitative. And it should be aimed at continuous improvement.

If, as a manager, you conclude that someone isn't meeting their objectives and isn't adapting within a team, you need to act — that's your job. But that's a different question from whether someone should get their bonus or not...

Examples of metrics used for variable pay

Here are some metrics that are sometimes used to set up compensation schemes:

Individual bonus based on Scrum metrics

For me, one of the worst schemes. Scrum metrics are the easiest to game and don't reflect software quality. The likely result is lower ambition on sprints or artificial inflation of complexity to increase story points. Really avoid this.

Team bonus based on Scrum metrics

Less bad than the previous one — this scheme tries to account for the collective aspect. But Scrum isn't designed for this. Most metrics that come out of it aren't user-facing. As mentioned above, perverse effects quickly emerge, along with under-commitment to meet expectations.

Team bonus based on user-facing metrics

You could put user NPS in this category. The intention isn't bad, but the connection to dev work is sometimes hard to make. Is NPS really just a reflection of dev effort? Or also customer support, product-market fit, etc.? Too many externalities come into play, and it becomes a source of conflict between departments.

Team bonus based on Accelerate metrics

I'm more convinced by these metrics than Scrum ones because they specifically aim to measure software quality.

But again, you're measuring "internal" quality, not product-market fit. You can ship fast and have few defects on a product nobody wants. You can have a tech team with great metrics but zero business alignment.

It's "the least bad" option, but you're not really solving much...

Equity: alignment and motivation through collective success

To end on a positive note, if we're talking about compensation and alignment with company interests, I'm much more convinced by equity grants (stock options, ISOs, RSUs for startups and public companies) or profit-sharing mechanisms (for mature companies).

Here you lose individual or even team-level tracking for the dev team. But you align everyone with the company's success. We all succeed together or fail together because it's directly tied to the company's revenue (or valuation).

I'll admit, we're not talking about the same thing.

Profit sharing is a mechanism that can only be implemented in mature companies that are profitable (rarely startups). It's generally predictable and you receive it every year.

Variable pay is quasi-predictable — the risk exists but is limited to the year's income.

Equity, in my experience, is harder to explain to dev populations and it's risky — but the potential upside is incomparable.

A lot of the time, equity won't result in any gain. But if the startup succeeds, the gains can be really significant (here are some examples), far greater than a 10-20% variable component.

Equity has multiple advantages, including the fact that people who eventually leave will remain aligned with the company's success and therefore stay active promoters (and really, that's beneficial!).

You can have attribution schemes that depend on where someone is in the career ladder (with possible re-grants starting at staff engineer level if their impact increases, for example).

That's all from me. But I suspect the discussion will continue in the comments on a topic like this :)