The gun you didn't need

Most organizations get hurt not by what they can’t do, but by what they can do and forgot they could.

Here’s what I mean. Today I was building an outreach pipeline — the kind of thing that generates personalized emails for prospects, queues them up for review, and stages them as drafts in your email client. The whole point is drafts. You review them, you decide when to send them. The human stays in the loop.

Except the email client we were using has a JMAP API, and that API has two capabilities: Email/set, which creates drafts, and EmailSubmission/set, which actually sends them. And at some point — weeks ago, when the code was being written — someone added the send path. Just in case. For convenience. “What if we want to send immediately later?”

You can guess what happened.

The code had a parameter called send_at. If you set it to a future date, it created a draft. If you set it to None, it sent immediately. And there was a line that said: if the send date is today, set send_at to None. Because today means now, right?

So when the schedule command ran for today’s batch, the emails weren’t staged as drafts. They were delivered. To a real person. Who texted back asking why she’d received four cold emails in sixty seconds.

Here’s what’s interesting about this. The capability wasn’t malicious. It wasn’t even sloppy. It was thoughtful. Someone anticipated a future need and built for it. That’s what good engineers do.

Except good engineers also know something that organizations routinely forget: every capability you build is a capability that can fire. And the ones you build “just in case” are the most dangerous, because nobody’s watching them. They’re not in the runbook. They’re not in the test suite. They exist in that shadowy space between “we can do this” and “we meant to do this.”

This happens everywhere, not just in code. Companies build pricing tiers they never use. Teams create approval workflows for scenarios that never occur. Procurement sets up vendor categories for products they don’t buy. And all of that dormant capability creates surface area — places where something can go wrong that nobody’s looking at, because the capability was never supposed to be active.

The fix wasn’t adding a safety check. It wasn’t putting a confirmation dialog in front of the send button. It was deleting the send capability entirely.

I want to sit with that for a second, because it goes against every instinct organizations have. The instinct is to add guards. Add a flag. Add a permission. Add a review step. More process on top of more capability. But the capability is still there, loaded and waiting for someone to misconfigure the guard.

The actual safe thing — the boring, unsexy, career-unadvancing thing — is to remove the capability you don’t need. Not disable it. Not gate it. Delete it. Make it so the system literally cannot do the thing you don’t want it to do.

We ended up going further. The pipeline had three manual steps: review the emails, approve them, then schedule them as drafts. Three commands. Why? Because at some point, someone imagined a workflow where you’d want to approve without scheduling, or schedule without approving, or review without doing either. Flexibility. Options. Just in case.

In practice, nobody ever approved without scheduling. Nobody ever reviewed without eventually approving. Three steps existed because three steps were possible, not because three steps were necessary. We collapsed them into one: approve. It reviews, approves, and creates the drafts in a single action.

Fewer steps means fewer places for things to go wrong. But more importantly, fewer steps means fewer dormant capabilities sitting in the system, waiting for someone to discover they can be used in ways nobody intended.

There’s a pattern here that I think about a lot in my consulting work. Organizations love to accumulate capability. New tools, new workflows, new integrations, new permissions. It feels productive. It feels like progress. Every new capability is a press release, a demo, a quarterly win.

But nobody gets promoted for removing a capability. Nobody writes a case study about the feature they deleted. The incentive structure rewards accumulation and punishes subtraction. So the loaded weapons pile up.

The test suite we had was a perfect example of this bias. The original tests verified that the send functionality worked correctly. They tested that EmailSubmission/set was called with the right parameters. They confirmed the dangerous thing operated smoothly. What they should have tested — what we test now — is that the send capability doesn’t exist at all. The test literally asserts: there is no method on this object that can send an email.

Testing for absence. That’s a weird concept. But it might be the most important kind of test there is.

So here’s the question I keep coming back to. How many loaded weapons are lying around your organization right now? Not the ones you know about — the policies, the permissions, the escalation paths that are documented and monitored. I mean the ones nobody remembers building. The integration that was set up for a pilot that ended three years ago. The API key with write access that was created for a one-time migration. The workflow that can approve expenses up to fifty thousand dollars that was meant for a team that no longer exists.

You can audit for these things. You can inventory them. But the real discipline isn’t finding them after the fact. It’s not building them in the first place.

The capability you don’t need is the one that fires.