Every time you add something to a system, you’re making two bets — and most people only evaluate one of them.

The first bet is obvious: is this thing good? Is this a strong hire? A promising company? A useful tool? A reliable vendor? We have entire disciplines built around answering that question. Interview loops. Diligence memos. Vendor scorecards. Trials and pilots and reference checks.

The second bet is the one that actually matters: does the system get better for having it?

Those are not the same question. And the gap between them is where most of the value — and most of the damage — lives.

The Real Test

Here’s the frame I keep coming back to: when you onboard a new vendor, vibecode a new tool, invest in a new company, or hire a new employee, that thing should contribute more to the system it’s being added to than its value in isolation.

Not equal to. More than.

The goal is 1 + 1 > 2.

That sounds like an aspiration. It’s actually a filter. Once you start asking “what does the rest of the system gain from this?” instead of “is this good?”, a lot of decisions that looked close stop being close.

What It Looks Like When It Works

The clearest version of this is hiring. There are people you bring on who do great work — and there are people you bring on who make everyone around them do great work. The second kind is rare and wildly underpriced, because their output doesn’t show up in their own column. It shows up in everyone else’s.

The same dynamic holds in a portfolio. You can invest in a company that will do well. Or you can invest in a company that makes the other twenty companies you’ve backed shine a little brighter, because now they can all leverage a capability that didn’t exist in the network before. One of those investments returns a multiple. The other one raises the floor on everything you already own.

And in tooling: the best thing you build is rarely the thing that solves the biggest problem. It’s the thing that quietly makes six other tools more useful than they were yesterday.

In every case, the value isn’t in the node. It’s in the edges.

The Version Nobody Talks About

But here’s the part that gets left out of the optimistic version of this idea: the inequality runs both ways.

Sometimes you hire that extra person and velocity drops. Not because they’re bad — often they’re perfectly good — but because the coordination cost they introduce exceeds the throughput they add. More context to sync. More meetings to hold. More surface area to keep aligned. The system now spends energy maintaining itself that it used to spend moving forward.

That’s 1 + 1 < 2. And it’s the worst outcome available, because it’s expensive, it’s slow to detect, and everyone involved is doing their job well.

The tool version of this is the same story. Every tool you add that doesn’t talk to anything else isn’t neutral. It’s a tax. Something to maintain, something to remember, something to context-switch into. Ten disconnected tools are worse than four connected ones, every time.

Interoperability Is the Whole Game

Which brings me to what I think is the actual mechanism underneath all of this: interoperability.

The reason a tool makes your system better is that it composes. It reads something another tool wrote. It writes something a third tool can consume. Its output is somebody’s input. The value compounds because the pieces fit.

A tool that can’t be composed with anything is a dead end, no matter how well it does its one job.

And I suspect this translates directly to people. The person who makes everyone better is, functionally, interoperable. Their knowledge is legible to others. Their work has clean interfaces. They can plug into someone else’s problem and add capability without requiring the whole system to reorganize around them.

The person who drags the system down is often the opposite — brilliant, but a closed system. Everything has to route through them. Nothing composes.

The Question to Ask

So the next time you’re about to add something — a hire, a check, a vendor, a tool you spent an afternoon building — don’t just ask whether it’s good.

Ask what it connects to.

Ask what gets better because it exists.

Ask whether the system is stronger with it, or just larger.

Because a system that only ever gets larger is a system that’s slowly getting worse. The sum of the parts should be greater than the whole. When it isn’t, you didn’t add anything. You just added weight.

---

I wrote 174 words of raw notes and Claude turned them into this. Not one sentence of the body above was edited by me or by it — the only changes after the first draft were the title, and two word counts in this footer that were wrong. That’s the whole point: an unedited version is the only one worth comparing against. The handwritten version is here — same idea in 174 words instead of 791, and I’d argue it says the same thing.