I worked alongside a data engineer who was, by every formal measure, the best performer on the team. He was also quietly destroying the platform.

Not maliciously. He was optimising for the thing being measured. His work shipped fast because he skipped the edge case analysis. He closed tickets at first resolution without ever checking whether the underlying pattern would recur. He didn’t review anyone else’s PRs (not his KPIs, so why would he?).

One of his teammates was the person actually holding the platform together. Quieter, slower to release, never at the top of any metric. She questioned everything, dug into the data, and worked with stakeholders to write elaborate testing scenarios. She was the one who caught a new source system sending nulls where the schema expected integers, and had been doing so for three weeks. She paired with the juniors. She wrote the runbook nobody had written.

Her performance review that year was average. His was excellent.

If you’ve worked in data engineering for any length of time, you’ve seen a version of this. If you’ve moved into leadership, you may have been the one signing off on it.

That’s the incentive pay problem. Not that it doesn’t motivate people. It motivates them to do the wrong things.

The Measurement Trap


There’s a name for this: Goodhart’s Law. When a measure becomes a target, it ceases to be a good measure. The moment you attach money to a metric, you’ve changed what people optimise for, and nearly every metric you can pull from the tooling is the wrong target.

Pipelines deployed rewards volume and punishes care. An engineer who ships fifteen small, well-tested, well-documented pipelines is worth more than one who ships thirty fragile ones. No spreadsheet you build will ever agree.

Tickets closed incentivises decomposition. Want a higher count? Chop big problems into small ones and resolve at the surface. The underlying pattern that keeps generating tickets isn’t your problem. That’s a different ticket, a different quarter, someone else’s metric.

Incident count punishes the team for things outside their control. An upstream system starts sending malformed payloads at 2am and your bonus goes down. (The vendor who caused it hits their SLA and gets paid in full, naturally.)

I’ve watched other leads volunteer for these measures because they’re easy to extract from Jira and GitHub. Easy to extract is not the same as meaningful. In my experience it’s usually the opposite.

The Invisible Work Problem


The deeper issue is that the most valuable work a data engineer does often leaves no trace.

The schema that doesn’t need refactoring in six months because someone thought carefully about how it would evolve. The data contract that caught a breaking change. Good engineering actively suppresses the numbers that look like productivity, because fewer incidents means fewer tickets, and fewer tickets means a lower “work completed” count.

Then there’s the social work. The engineer who reviews PRs with care, who explains why and not just what, who flags when a colleague’s approach will cause trouble downstream, is compressing the learning curve for the whole team. They prevent incidents that never appear in any log, because they never happened.

I wrote about this from a different angle in The Invisible PR You’re Building Right Now — the reputation built through small interactions that compound over years. Incentive pay is the structural version of the same idea. Most schemes don’t just miss this work, they penalise it, because a careful PR review is time not spent on your own ticket count.

The Lopsided Ledger


Even a perfect set of metrics — which you can’t build, but suppose — runs into some uncomfortable arithmetic. A strong review doesn’t make a good engineer better; at most it confirms what they already believed. A review that misses what someone actually did makes them recalibrate, and next quarter they do the work that gets measured instead of the work that matters. The downside dwarfs the upside. And since most people believe they’re above average and most systems grade on a curve, disappointment is the default output. You’re spending management time and team morale on a mechanism that runs at a loss.

So What Actually Works


I’m not arguing that data engineers don’t care about money. They do, and they should.

Dan Pink covered this territory in Drive, and his central finding is facinating: if-then rewards work well for mechanical tasks and reliably degrade performance on cognitive ones. Data engineering is nothing but cognitive work. His answer, and mine after years of watching teams, is to pay people well enough that money stops being the conversation — then use the levers that actually move things.

Autonomy. Engineers who are told what outcome is needed, and trusted to work out how, consistently produce better work than those handed a specification. The person who understands the problem deeply enough to design the solution will always see things the specification missed. Give people the problem, not the method.

Mastery. The most engaged engineers on my teams are the ones getting meaningfully better at something. Not completing training modules — deepening their craft. Conference time, learning budgets that actually get spent, a problem slightly beyond their current reach with a safety net underneath.

Purpose. Data engineers rarely see the downstream consequence of what they build. Closing that loop matters enormously. When an engineer learns that the student outcome data they built powers the retention intervention that changed whether someone finished their degree, no quarterly bonus comes close.

And recognition, the specific and timely kind. Not plaques, not a Teams message with too many emojis. The manager who says quietly in a 1:1: “The way you caught that schema drift before it hit the mart prevented an incident nobody will ever know about, and I noticed.” That costs nothing, and it does more for morale than any incentive scheme I’ve witnessed.

The Pipeline That Doesn’t Break


The best data engineering work is characterised by what doesn’t happen.

The data that arrives without error. The migration that completes cleanly. The breaking change caught in review. The junior who is now autonomous on a system they couldn’t have touched six months ago.

None of this is countable. None of it generates a closed ticket or increments a deployment counter. Which means it will always be invisible to any incentive scheme complex enough to automate and simple enough to implement.

There is an honest cost on the other side. Drop the metrics and you lose the comfort of a ranking you can defend in a calibration meeting. Judging invisible work means knowing your team’s work well enough to see it, and that’s harder than reading a dashboard.

Pay people fairly. Pay them enough that salary isn’t what they’re thinking about while debugging a nightly job at 7am. Then build the conditions where the work itself is worth doing.

The engineers who hold your platform together aren’t doing it for the bonus. And the moment you start paying them as if they were, you’ll start losing the ones who weren’t.