The question gets asked in multiplier form — is an engineer worth 10x another one — and in that form it isn't answerable, because the people answering it are consulting their impression of their own work. METR's trial is the corrective: sixteen experts on their own codebases misjudged their own speed by roughly 39 percentage points.
Asked differently it becomes tractable. There are four channels through which engineering work reaches revenue. Each has a formula. And the interesting finding is that most engineers can only reach two of them, which is a fact about their role rather than their ability. If engineering management needs to survive contact with a marketing team, XenGrowth has the operational side.
Channel one: gross margin
The most accessible and the most under-used. Infrastructure, third-party services, egress and support sit in cost of goods sold, above the gross profit line — and they're determined almost entirely by engineering decisions.
A recurring saving here reaches profit whole, because there's nothing to subtract from it. At a 20% net margin, a saved dollar contributes what five earned dollars contribute. Take a mid-stage company at $10m revenue with $1.2m of annual infrastructure: an engineer who finds $180,000 of recurring saving has moved gross margin by 1.8 points, permanently, which at a 10% net margin does what $1.8m of new revenue would do. For the the operations side of this angle, see The XenGrowth resource library.
The number is large and the work is usually a few weeks. What makes this channel unusual is that it needs nobody's cooperation — sales cannot reduce your egress bill, finance cannot change a retention policy.
Channel two: retention
The largest by magnitude, and the arithmetic is the reason.
LTV is gross-margin-weighted revenue divided by churn rate. Churn is a divisor, so improvements to it don't add — they multiply. Halve churn and you double LTV. There is no acquisition improvement with that property: a 10% CAC reduction improves the ratio by 10%, while a 10% churn reduction improves LTV by about 11% and keeps compounding through every subsequent period.
This is where reliability and performance work stop being professional preferences and acquire a number. Not because uptime is virtuous, but because churn sits in a denominator.
The caveat is that the link is lagged and hard to attribute. A customer who leaves in March because of an outage in November will tell you they left over pricing. Net revenue retention — Benchmarkit puts it around 106% on average, above 120% for top performers — is the metric that captures it, and it moves slowly enough that a single quarter's work rarely shows up cleanly.
Channel three: activation and conversion
Reached through onboarding friction, time to first value, and speed at the points where people decide whether to continue.
Commercially it lands on CAC payback, where the spread in Benchmarkit's cohort is the striking part: a 16-month median, 6 months or less at the top quartile, up to 48 at the bottom. A company at 40 months is not slightly worse than one at 12 — it has to survive more than three years per customer just to break even on acquiring them, which constrains everything else it can do. If AI agents and marketing automation is the part you are stuck on, XenGrowth on AI agents and marketing automation is the better reference.
Self-serve activation is the main lever separating those groups, and it is squarely engineering work. The catch is that this channel usually requires someone else's agreement, because changing onboarding means changing what the product is, and that is a product decision rather than a technical one.
One practical note on measuring this channel. Because attribution is slow, the mistake is to look for the effect in the quarter you did the work. Pick the cohort instead: customers who joined after the change, tracked against those who joined before, on retention at six and twelve months. That is a slower answer and a real one, and it is the difference between a claim about reliability and evidence for it. Most teams never run it, which is why reliability work is perpetually argued for on principle rather than on numbers.
Channel four: capacity
The weakest, and the one engineers claim most often. Freed engineering hours are not value in themselves — the salary is paid either way. The value is whatever those hours produce instead.
Stripe's survey puts roughly 42% of the developer week on technical debt and bad code, so the pool is genuinely large. But an unnamed destination is not a business case, and claiming both the time saved and the work it enables is the standard double-count. If you can't say what the reclaimed hours will do, you have moved the same salary around.
Channel | Formula | Magnitude | Can you reach it? |
|---|---|---|---|
Gross margin | Recurring saving ÷ revenue = margin points | Moderate, and reliable | Yes — needs nobody's permission |
Retention | LTV = margin × ARPA ÷ churn | Largest, because churn is a divisor | Partly — the work is yours, the attribution isn't |
Activation | Effect on CAC payback and conversion | Large at the top of the funnel | Usually needs product agreement |
Capacity | Hours freed × value of what replaces them | Zero unless the destination is named | Yes, but it's the weakest claim |
The channel nobody counts: what you stopped
There is a fifth channel that resists formulas entirely, and on a long enough horizon it may be the largest of the lot: the things that did not get built because somebody asked whether they should be.
A feature declined costs nothing to build, nothing to maintain, generates no support load, consumes no review attention, and places no constraint on future design. Against a baseline where roughly 42% of the developer week already goes to maintaining what exists, every feature not shipped is a permanent reduction in that bill. The engineer who talks a company out of a quarter of work has produced more value than most of what they will ship that year.
The reason it never appears in anyone's performance review is that the counterfactual is invisible. There is no artifact, no demo, and no way to prove that the thing you prevented would have gone badly. This is the same attribution problem that makes cost savings go unclaimed, and it has the same partial fix: write it down when it happens. A short note saying what was proposed, what you asked, and what the team decided instead turns an invisible contribution into a documented one, and costs five minutes.
It is worth being honest that this channel is also the easiest to abuse. An engineer who declines everything is not exercising judgment, they are avoiding work, and the difference is legible to everyone around them within about two months. The version that carries weight is specific and occasional: most requests get built, and the one that gets questioned is questioned with a reason.
Why access matters more than ability
Here's the part that reframes the question. Two engineers of identical skill, in the same company, can have wildly different revenue influence — because one works on a system that touches a channel and the other doesn't. For the AI search, GEO and discovery angle, see XenGrowth on AI search, GEO and discovery.
An engineer on an internal tooling team has access to capacity and almost nothing else. An engineer on billing infrastructure touches margin and retention directly. An engineer on the signup flow has the shortest path to activation of anyone in the building. None of that is about how good they are.
Which makes this a question about what you work on, not how well you work — and that's a more useful frame, because it's actionable. If you want more revenue influence, the highest-return move is usually to change which system you're near, not to get better at the one you're on.
Billing, provisioning and anything metered: direct line to margin, and usually understaffed because it's unglamorous
Onboarding and the first-run experience: shortest path to activation and CAC payback, and the work is nearly always visible to leadership
Reliability on the paths customers actually depend on: the retention channel, with the caveat that attribution is slow
Internal tooling: capacity only, unless you can name what the capacity delivers — which you often can, and almost nobody does
Greenfield features: no channel at all until they ship and someone measures whether they changed behaviour
If you want to... | Do this | Because |
|---|---|---|
Show impact this quarter | Cost per customer analysis, then the top decile | Fastest channel, needs no permission, ends in a number |
Make the largest possible difference | Find the churn cause nobody has traced | Churn is a divisor; nothing else compounds like it |
Get noticed by people outside engineering | Anything touching activation | It's the one channel commercial teams already watch daily |
Justify a platform investment | Name the destination for the freed capacity | Otherwise it reads as a preference for pleasanter work |
So the answer to the question is: considerably more than most engineers realise, through channels most of them have never enumerated, limited mostly by which systems they happen to sit next to.
That last constraint is the one worth acting on, and it is the only one in this post you can change on a Tuesday.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
Working on engineering management inside a commercial team? XenGrowth's revenue operations work publishes operator guides on the revenue side of this work.
Pick one channel and one number this quarter. Enumerating all four is interesting; moving one of them is what the question was actually about.
