Five Definitions of 'It Works'

"It works" is the most overloaded phrase in software.

Say it in a status meeting and five people will nod, agree, and walk away with five different mental models of what just happened. Nobody is lying. They are all answering the question honestly. They are just answering a different question than the one you think you asked.

Executives measure predictability

When an executive says it works, they mean they can now commit to the next milestone without quietly worrying about a rewrite. The roadmap holds. Investors hear a coherent story instead of a list of caveats.

This is not a superficial concern. Predictability is the currency executives spend to make every other commitment — hiring plans, fundraising narratives, customer promises. A system that "works" but whose timeline nobody trusts doesn't actually give them what they need.

Product measures adoption

Product says it works because the right metric moved, support tickets on that flow went quiet, and users are completing the task without asking how. Their definition is entirely about what happens outside the codebase.

A feature can be architecturally elegant and fail this test completely — nobody uses it, or they use it in a way that generates confused support tickets. From product's chair, that is not "it works with rough edges." That is it doesn't work, full stop.

Engineering measures changeability

Engineering says it works because the abstractions are clean, the failure modes are isolated, and the next developer won't need a 45-minute onboarding session just to touch it.

This is the definition most engineers default to, and it's the one most invisible to everyone else. Nobody outside the team notices whether the failure modes are isolated — until eighteen months later, when a small change takes three weeks because nothing was isolated after all. Engineering's "it works" is a bet placed on the future, payable much later.

Risk management measures defensibility

Risk says it works because if an auditor asked, there would be a defensible answer. The attack surface is understood. The decisions — including the ones that trade off security for speed — are written down somewhere, with a reason attached.

This definition rarely shows up in a demo. It shows up in an incident review, or a compliance audit, or a customer's security questionnaire, at which point it's either there or it very much isn't.

Operations measures quiet systems

Ops says it works because nothing paged at 3am. There is a runbook. When something breaks — and something always eventually breaks — it breaks predictably, in a way that has a known response.

Ops is the definition most correlated with the other four and least likely to get credit for it. A system that never pages looks, from the outside, exactly like a system that was never at risk of paging. Those are not the same system.

None of them are wrong

The tension isn't that one of these definitions is correct and the others are noise. They're all correct, measured against what each function actually needs from the system. The tension is that optimizing hard for any one of them tends to create debt in at least one of the others.

Ship fast enough to hit the executive's predictability bar, and engineering's changeability definition quietly erodes — the abstractions get skipped because there wasn't time. Lock down the attack surface hard enough to satisfy risk, and product's adoption numbers can suffer if the friction lands on users. Build the isolated, well-tested, changeable version engineering wants, and it might ship a quarter later than the roadmap promised.

None of these trade-offs is a mistake. They're the actual content of the job.

---

Shipping fast is easy. Shipping something all five of them can live with — that's the work that doesn't show up in the demo, and it's the only version of "it works" that actually holds.