Why Most Performance Pay Programs Fail — and What We Check Before You Launch Yours.

Ask most contractors why their bonus program fizzled out and you'll get some version of the same answer: "The crews didn't care" or "It cost more than it saved" or "We just kind of stopped." Dig one layer deeper and a different story shows up almost every time. The program wasn't undone by apathy or cost. It was undone by a number nobody checked before launch — a budget that was never honest, a target set off a gut feeling instead of the org's own history, a goal that half the crews were mathematically unable to reach.

That's the pattern we see over and over when we sit down with an operator whose last attempt at performance pay didn't stick. The instinct was right. The execution skipped a step: nobody looked hard enough at what the operation's own data actually said before turning the incentive on.

The real reason performance pay programs fail

Set aside company size, trade, and region for a second, and the failure pattern looks almost identical everywhere. An owner builds a bonus program around what they believe the numbers say — because that's the only version of the numbers they've had time to look at. Budgets get set from memory, from what a job "should" take, or from an estimate built for pricing rather than for measuring crew performance. The program launches. A few weeks in, one of three things happens:

• Almost nobody earns anything. The target was set closer to the best day any crew has ever had than to what a good, motivated crew can actually do consistently — so the bonus reads as a bait-and-switch.
• Everybody earns something, immediately, for doing nothing differently. The budget was already loose, so the "incentive" just pays out the gap that existed before the program ever launched — real dollars, zero behavior change.
• The results are inconsistent in ways nobody can explain. One route prints bonuses every month; a nearly identical route next door never does — and it turns out the two were never measuring the same thing to begin with.

None of these are people problems. They're baseline problems. And a baseline problem is invisible until you go looking for it, because on paper, the program still looks reasonable — a target, a bonus, a payout schedule. What's missing is the step before that: an honest read of what your operation's own history says is achievable.

The six things we check before you launch

This is the part of the work we don't talk about publicly very often, because it isn't glamorous — it's an operations audit, not a pitch. But it's the actual reason the programs we help set up hold up past month three. Before we help you turn on a single incentive, we walk your operation through six questions, in this order, using your own job history rather than assumptions:

1. Is your baseline honest? What does twelve months of your real labor data say, compared to what you believe it says — company-wide, then by branch or division? The gap between those two numbers is usually the first surprise.
2. Are your budgets any good? Budget versus actual, job by job, scored by crew and by route — separating "budgets that are wrong" from "crews that are behind." These are very different problems with very different fixes.
3. Where does the time actually go? Billable versus non-billable, drive time, production hours — the hours hiding inside a schedule that make a target unreachable, or trivially easy, depending on what nobody accounted for.
4. Are you staffed the way the job needs? People per budgeted crew-day, compared against similar jobs. Overstaffing and understaffing both distort what "on budget" even means.
5. What would this program actually pay? We model the incentive against your last several months as if it had already been running — per crew, per employee — before a single dollar is committed.
6. What does a real improvement target look like? Not a number pulled from the top of your head — a target set a defensible distance ahead of what your own recent performance shows, with the confidence that a meaningful share of your crews can actually reach it.

Each of those six questions gets its own post in this series, with a real (anonymized) walkthrough of what the analysis surfaces. This post is the map. The next five are the terrain.

What this looks like on a real operation

Here's a composite, drawn from patterns we've seen repeatedly and stripped of anything identifying: a landscaping company came to us wanting to reward crews for finishing jobs under budget. Reasonable goal. When we pulled twelve months of their actual job data, the picture looked nothing like what the owner expected.

Their budgets assumed a labor cost around 30% of revenue. Their real twelve-month number was closer to 40 — a gap wide enough that handing crews a 30% target wouldn't have been a stretch goal, it would have been a program almost nobody could win. At the same time, a handful of their best-performing routes were already running 5–10% under budget every month, with zero incentive attached — meaning a poorly-calibrated program would have paid those crews for behavior that had nothing to do with the new bonus at all.

That's the entire thesis of this series. The tools to fix a broken incentive program are less about clever program design and more about looking honestly at the numbers before you build anything on top of them.

Where this stands today

This analysis isn't a slide deck we walk you through once and hand you a PDF. It's built into how our team works with you inside the platform, using your synced job data rather than a spreadsheet reconstruction of it — and we're actively rolling out more of it in automated form inside the product every week, so more of this becomes something you can pull up yourself rather than something we run for you. If you're evaluating performance pay right now, this is the work that happens with our team before you ever turn an incentive on.

What's ahead in this series

Over the next five posts, we'll go through each of the six checks in detail — what we look for, what typically goes wrong, and what a good answer looks like using real (anonymized) examples from operations we've worked with.

We'll link each post here as it publishes.

Frequently asked questions