Twice in a row#

Recently, in two separate meetings at a large tech company, I watched the same scene play out.

Someone presented an approach that was suboptimal — not just technically, but for the customer and the company too. Not catastrophically wrong — just not right. Better alternatives existed — technically sounder, ones that would actually bring value to the product and/or its users. Both times, they were dismissed with nearly the same words: “That would require convincing people. It would add friction”.

As if the difficulty of the conversation was a valid engineering argument.

The real optimization function#

Large companies talk a lot about optimizing for the customer. But spend enough time inside one and you start noticing what people actually optimize for: internal ease.

The question isn’t “what’s the best solution?” anymore. It’s “what can I ship without friction?” The decision-making framework has quietly shifted from correctness to convenience. And the worst part is, everyone probably knows it — or knew it once, before they stopped caring.

The customer nobody mentions#

Here’s what struck me most about both conversations: at no point did anyone mention the company, let alone the customer.

Not once. The entire discussion revolved around internal dynamics. When your primary constraint becomes “what’s politically feasible” rather than “what’s right for the product”, you’ve stopped serving customers and started serving your own career.

Death by a thousand easy choices#

No single instance of this is catastrophic. A product can survive one suboptimal API design, one unnecessary abstraction layer, one poor architecture choice. Each one, taken alone, is perfectly defensible — if it’s really for the greater good of the company or the customer.

But they rarely are. And they compound. Large organizations reward consensus over correctness — and while doing the right thing is long and difficult, doing it wrong takes no time and no effort in the short term. Over months and years, the product quietly decays. Not from one bad decision, but from a thousand easy ones.

As I’ve written before, the friction excuse is how that politics manifests at the individual decision level. It’s the mechanism by which organizational dysfunction gets encoded into your codebase, one pull request at a time.

The quiet resignation#

The most troubling part isn’t that people make this trade-off once in a while. It’s that they don’t even see it as a trade-off.

Engineers who genuinely care about their craft don’t stop caring because the org is messy. They push back. They fight for the better solution. And when the culture makes that impossible, they leave. They don’t shrug — they refuse.

Can you imagine a surgeon compromising on an operation because the hospital’s approval process is too slow? A pilot compromising on safety? A pharmacist compromising on a dosage? In no other profession is “it’s too hard to sell internally” an acceptable reason to do worse work.

So who are you serving?#

The next time you’re about to compromise to avoid friction, ask yourself genuinely: is there a solution that would benefit the customer more? The company more? The codebase more? If your organization has reached a point where internal comfort consistently overrides doing the right thing, then the friction isn’t in the proposal.

It’s in the culture.