Variable pay for product and engineering teams: simple structures that hold up

A product company decides to add a bonus for engineers. The founder drafts a formula on a Sunday night, linking pay to features shipped. By March the team has shipped many small features and no big ones. Two senior engineers ask why code quality no longer counts.

Variable pay can help, but badly built plans change behaviour in ways you did not plan. This post gives a few simple structures and a method to choose among them, for a founder or finance head.

Before any formula, write one sentence on what the plan is for. Is it to share company success, to reward a team goal, or to retain key people? The purpose decides the structure. A plan that tries to do all three usually does none.

The wider pay design sits within your compensation and rewards strategy. Variable pay is one part of it, next to fixed pay, benefits and any equity.

• Company pool: a share of an agreed company result is set aside and divided by level or by fixed pay. It is easy to run and links everyone to the whole.
• Team goal bonus: a squad earns a payout when it meets a shared target, such as a launch date held or an uptime level agreed with customers.
• Project completion award: a one time payment on delivery of a defined project, decided before work starts.
• Spot recognition: small awards for exceptional help, given by managers with clear rules.

Most small firms do well with a company pool, plus a modest team goal for squads whose work can be measured fairly. Individual sales style commissions suit sales roles far better than engineering.

Lines of code, tickets closed and features shipped are easy to count and easy to game. Engineers who help colleagues, review code or fix hidden problems earn less under such plans. The result is a team that stops collaborating. Prefer team measures and add a manager's judgement for individual contribution.

1. 1

   Write the purpose

   One sentence, shared with the leadership team. Test it by asking whether a developer could repeat it.

2. 2

   Choose the measures

   Pick two or three company or team measures that finance can report from existing data. Define each one in a line, including where the number comes from.

3. 3

   Set the size of the pool

   This is the founder's decision. Base it on what the company can afford in a weaker year, not only a strong one.

4. 4

   Decide eligibility and split

   State who takes part, how new joiners and leavers are treated, and how the pool is divided.

5. 5

   Write it down

   A one page plan, a payout calendar and a named person who answers questions.

6. 6

   Run a trial cycle

   Calculate payouts on paper for last year before you announce the plan. Check that results feel fair.

Purpose of the plan.
Who takes part and from when.
Measures and where each number is read.
How the pool is sized and by whom.
How the pool is divided.
Treatment of joiners, leavers and long leave.
Payout calendar.
Who can change or stop the plan and how staff are told.
Who answers questions.

People accept a lower payout if the rule is clear. They resent a surprise even when it is generous. Share the plan in a meeting, hand out the page, and answer questions. Tell the team that the plan can change with notice, and explain how.

Be careful with promises. Words like usual or expected can later be read as a commitment. Ask your own adviser to check the plan wording and any letters that mention it.

A bonus does not make up for low fixed pay. Engineers compare offers on fixed pay first. If variable pay is large and uncertain, candidates discount it. Review fixed pay by level using the guidance for SaaS and product companies and keep the variable part moderate.

Take a product firm with three squads. The founder chooses one company measure, which is renewals held from the previous year, and one team measure per squad. Platform holds uptime agreed with customers. Mobile holds crash rate at an agreed level. Growth holds a launch date. Finance confirms each number can be read from existing reports. The pool is sized by the founder after a cautious look at the weakest recent quarter. It is split by level, with a small adjustment for months worked. Nobody is paid on lines of code or tickets.

At the end of the cycle, the leadership team reviews each measure and writes two lines on what the number did not capture. These notes feed the next round of the plan.

• After the first full cycle, with the team's feedback.
• When the company changes its business model or main product.
• When a measure turns out easy to game.
• When hiring becomes hard because candidates doubt the plan.

Pair the plan with the hiring method in scorecards and skills tests for developers so offers describe fixed and variable parts consistently. Late night work is better handled by its own rule, as covered in fair rules for on-call and release night work, rather than through the bonus.