A version of this post exists that says craft doesn't matter and engineers should stop caring about it. That version is wrong and I'm not writing it.
The actual claim is narrower and more annoying: excellence is an input, organisations allocate against outcomes, and work presented in terms of its inputs has no exchange rate with anything else on the list. It doesn't lose the argument. It never enters the argument.
The units problem
Picture a prioritisation meeting. Five things are competing for the same quarter. Four are described in revenue, customers, or a deadline someone else set. The fifth is described in milliseconds, or coverage percentage, or how much cleaner a module would be. Where I stop at the implementation of technical excellence without business impact falls flat, XenGrowth's growth engineering practice carries on into running it.
The fifth doesn't lose on merit. It loses because there is no way to compare it. A decision-maker choosing between four numbers and one adjective isn't rejecting quality — they're rejecting an item they have no method for evaluating, in favour of four they do.
Engineers read that refusal as a statement about the company's values. It is almost always a statement about units.
And the misreading is expensive, because it produces a story — the business doesn't care about quality — that is both demoralising and false, and that stops anyone trying the thing that would work.
Quality genuinely does have consequences
It's worth establishing this properly, because otherwise the argument collapses into telling engineers to be more commercial.
DORA's 2025 data shows AI adoption raising delivery throughput while delivery stability continues to fall. That is a quality cost arriving whether or not anyone budgeted for it — teams shipping more and a larger share of it wrong. DORA's own framing is that AI amplifies what a team already is, which makes baseline engineering quality the determining variable rather than a preference. For the the operations side of this angle, see The XenGrowth resource library.
Veracode found 45% of generated code across 100+ models introducing an OWASP Top 10 vulnerability, with larger models no better. Stripe's survey puts roughly 42% of the developer week on technical debt and bad code. All three are quality problems with commercial consequences, and none of them announces itself as a line item.
So the case exists. It just has to be made in a currency that can be compared, and nobody is going to make it for you — the finance function cannot see it, because engineering salaries sit below the gross margin line and maintenance burden never appears as a cost of serving customers.
The translation, item by item
What you care about | The channel it reaches | How to say it |
|---|---|---|
Latency | Activation and conversion | "The drop-off at step three tracks this; here's the funnel" |
Reliability | Retention — churn is a divisor in LTV | "Cohorts that hit this defect churn at N% higher at six months" |
Test coverage | Change-failure rate, then retention | "Our change-failure rate is X; DORA's stability finding is playing out here" |
Refactoring | Capacity, with a named destination | "Work here takes twice as long; here are twelve tickets" |
Security hardening | Risk, expressed as expected value | "This category failed 45% of the time in Veracode's benchmark" |
Infrastructure efficiency | Gross margin | "1.8 points of gross margin, permanently, for six engineer-weeks" |
Architectural elegance | Often nothing | Be honest — see below |
The last row is the important one and the reason this post isn't just advice on rhetoric.
The failure mode in the other direction
Some quality work has no channel. It doesn't reach margin, churn, activation or capacity by any route anyone can name. It is nicer, and that's the whole of it.
That work is a professional preference, and the ability to tell it apart from the other kind is the actual skill this post is about. An engineer who translates everything into business language, including the things that genuinely have no consequence, has not become commercially literate — they have learned a rhetorical trick, and it stops working the second time someone checks. XenGrowth on AI agents and marketing automation covers the AI agents and marketing automation side of this.
There's a test I find reliable. Ask what specifically gets worse if this is never done. If the honest answer is "nothing measurable, but I'd rather it were different", that's fine — say that. Small preferences get accommodated in the ordinary course of work, and asking for one directly is far more likely to succeed than dressing it as a business case that a sceptical reader will dismantle.
The asymmetry that makes this feel unfair
Part of what makes this galling is that the comparison is not conducted on level ground, and it is worth naming rather than pretending otherwise.
A feature proposal gets to describe a benefit that has not happened yet, in confident terms, with no obligation to measure whether it arrived. A quality proposal is asked to prove a counterfactual — that something bad would have occurred — which is epistemically much harder and frequently impossible. So the two are held to different standards, and the harder standard falls on the work whose benefit is the absence of a problem.
You cannot fix that asymmetry from where you sit, but you can stop being disadvantaged by it in one specific way: by attaching your quality work to a problem that has already happened rather than one that might. An incident that occurred, a deal that was lost, a migration that overran, a support queue that grew — these are observed facts, and a proposal anchored to one of them is arguing from evidence rather than from prophecy. Teams that keep a written record of what went wrong and why have a permanent supply of this ammunition; teams that resolve incidents and move on have to reconstruct it under pressure every time.
This is also the strongest reason to write real postmortems even when nothing dramatic happened. Their value is not the corrective action list, which usually gets half-implemented. It is that six months later you can point at a documented cost and say that the thing you are proposing addresses it — which converts a prediction into a repair, and repairs get funded.
Why this isn't selling out
The objection I'd expect is that this asks engineers to justify their expertise to people who don't have it, which is both undignified and inefficient.
Two responses. The first is that every function does this. Sales justifies headcount in pipeline. Marketing justifies spend in attributed revenue. Finance justifies its own existence in controls and cost of capital. Engineering is the only function that routinely expects to be funded on the strength of its own professional judgement, and it is not obvious why that expectation should hold. XenGrowth on AI search, GEO and discovery covers the AI search, GEO and discovery side of this.
The second is more practical. Translation isn't a tax on the work — it changes what work you choose. An engineer who habitually asks which channel something reaches will notice, some fraction of the time, that a thing they wanted to do reaches none of them, and that a thing they were ignoring reaches one directly. That reallocation is worth more over a career than winning any individual argument, and it is the actual return on learning this.
What to do with this
Before proposing quality work, name the channel and say it out loud. Margin, churn, activation, capacity. If you can't name one, you have learned something before spending a meeting on it
Bring the number even if it is rough. "Roughly twice as long, here are the tickets" is enormously stronger than "this area is difficult", and it took ten minutes to produce
State the cost of the work in the same detail as the benefit. Engineer-weeks, what else those weeks would have done, and a payback period. A benefit with no cost attached reads as advocacy
Bring what you're recommending against. A list of quality work you think isn't worth doing is the single cheapest way to make the rest of the list credible
Say when a preference is a preference. It costs nothing, it is usually granted, and it protects the credibility of every case you make that isn't one
Measure afterwards, including when you were wrong. Almost nobody does this, and it is why so few organisations know whether their last twenty investments worked
The story engineers tell | What is usually happening |
|---|---|
"They don't value quality" | The proposal had no unit they could compare |
"They only care about features" | Features arrive with numbers attached; quality work usually doesn't |
"Management is short-termist" | Sometimes true — and unfalsifiable from where you're standing |
"Nobody listens to engineers" | Engineers who translate get listened to at a noticeably higher rate |
"We'll pay for this later" | Correct, and no one can act on it until you say how much |
The bottom row is the whole post in miniature. "We'll pay for this later" is almost always true and almost never actionable, because later has no size and no date. Give it both and it stops being a warning and becomes a decision somebody can make.
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
If technical excellence without business impact falls flat is part of a growth programme rather than a standalone build, XenGrowth is the companion reading.
Craft still matters. It is just that nobody outside engineering can see it directly, and the translation is your job because you are the only person in the building who can do it.
