The Observation
There is a version of every system — a business, a portfolio, a body, a life — that is quietly better than the one currently running. Reaching it does not require adding anything. It requires removing something.
Nothing here is doing double duty.
A few years ago I sat down to map out everything my business depended on simply to function. Every tool, every subscription, every small procedure I had introduced one at a time, each for a perfectly reasonable reason at the moment I introduced it. The list took an entire afternoon to finish, and longer still to admit what it meant. Nothing on it was, by itself, a mistake. Together, they had become a weight I had been carrying without noticing I was carrying it.
I spent the following months removing things rather than adding them. I closed accounts I had opened "just in case." I collapsed three overlapping tools into one. I cancelled a service I had kept for two years out of momentum rather than need. What remained worked better than what I had started with — not because it did more, but because there was less of it to break, less of it to explain to someone else, and less of it occupying a corner of my attention every single day.
That was the moment I began paying attention to a distinction that, once seen, is difficult to unsee.
Simple Is Not the Same as Easy
We use these two words as if they were interchangeable, but they describe different things entirely. Easy means familiar — close at hand, requiring no adjustment to how we already think or act. Simple describes something more specific: how many parts of a system are tangled together, independent of how comfortable that system feels on first contact.
A tangled system is one where changing a single part risks breaking several others, because the parts were never cleanly separated to begin with. Choosing the easy option — a convenient new tool, a quick workaround, one more approval step "just for now" — almost always trades away simplicity for comfort. It feels like progress in the moment it is added. The cost only becomes visible later, when every future change has to account for everything it might quietly disturb.
Every one of these was a reasonable decision on its own.
This is the trap. Ease is immediate. Simplicity is deferred. Left unexamined, nearly every decision drifts toward whichever option feels easier today, and the tangle grows one reasonable choice at a time — never through a single dramatic mistake, but through a long accumulation of small, sensible-seeming ones.
The Tax Nobody Sees on the Invoice
Complexity behaves like a tax. Nobody writes a check for it, and no line item on any budget calls it out by name. It is paid instead through three quieter channels, and I have watched all three drain a business from the inside without a single obvious crisis ever announcing them.
The first is the cost of building anything new, which climbs as components multiply and none of them were designed to work cleanly together. Manufacturers who let a product's parts list grow unchecked routinely see material costs rise by ten to fifteen percent with no corresponding gain in what the customer actually experiences. The second is the cost of simply operating day to day — more moving parts require more coordination, more inventory sitting idle, more meetings whose only real purpose is keeping the pieces aligned with one another. The third, and usually the most expensive, is the cost of repair, paid when the person trying to fix something can no longer hold the whole system in their head well enough to know what they are looking at. Firms that ruthlessly simplify their product lines instead — fewer variants, cleaner components, tighter tolerances — have shown they can cut that first cost by fifteen to twenty percent and cut repeat service calls by close to a third, simply by making the thing easier to understand.
None of this arrives as a single bill. It accumulates through a long sequence of decisions that each seemed sensible in isolation — one more subscription, one more approval layer, one more feature nobody quite asked for but nobody wanted to be the one to cut. The invoice only arrives once the system has become too intricate for any one person to hold in their head, and by then nobody can say which decision, exactly, was the one that tipped it.
The charge is real. It's just never itemized.
A Concrete Case: One Aircraft, One Discipline
The clearest illustration I know of this comes from an airline that made an unusually boring decision and stayed with it for decades: fly a single aircraft type across the entire fleet, long after every competitor had diversified into two, three, or four.
The decision looks unambitious on paper. In practice, it means every mechanic in the company can reach full specialization on one airframe rather than partial competence across several. It means the spare-parts inventory stays small enough to actually manage, rather than sprawling across dozens of part numbers for engines and cabins that will never share a bolt. It means crews can rotate freely without running into licensing walls that would otherwise lock a pilot to one aircraft family. And critically, it means the airline had to say no to the tempting, complexity-adding move of building out premium, multi-class cabins — which would have required larger galleys, fewer seats, and a fundamentally different, slower boarding and turnaround process. That single refusal protected a business model built on dense seating and turnarounds measured in twenty-five minutes rather than sixty. The airline in question has carried billions in liquidity through downturns that grounded less disciplined competitors, and its customer satisfaction scores have sat well above the industry average for years — not because the aircraft is remarkable, but because the company never let its own operations become more complicated than the one plane it chose to fly.
A messaging platform, in a very different decade and a very different industry, made a version of the same choice. It reached hundreds of millions of active users with an engineering team small enough to fit in a single large conference room, by refusing to chase the fashionable, feature-heavy infrastructure everyone else was adopting and instead building on a small, disciplined runtime originally designed decades earlier for telephone switches. Each user was given an extremely lightweight process consuming a few kilobytes of memory rather than the megabyte a conventional approach would have required, which meant a single physical server could hold millions of simultaneous connections. The servers themselves were designed to hold nothing — messages were delivered and immediately forgotten, rather than accumulated into ever-growing databases that would need to be maintained forever. In both cases, the discipline was never about doing less work. It was about refusing to let the system tangle in the first place.
One aircraft. One set of parts. One less thing that can go wrong.
Complex Systems Must Grow From Simple Ones
There is a useful, almost biological observation about how any working system comes into existence: a complex system that actually functions is almost always found to have evolved from a simpler system that already worked on its own. A complex system designed from scratch, in one attempt, tends not to work — and worse, it usually cannot be patched into working afterward. The only reliable path is to begin again from something simple and let it earn its complexity gradually, through contact with the real conditions it will actually face.
This is not an argument against sophistication. It is an argument against skipping the step where a simple, working core absorbs real friction — real errors, real edge cases, real fluctuations in demand — before anything further is layered on top of it. Structures built the other way around, fully specified before they ever meet reality, tend to collapse at the very first unplanned event, because they were never tested against anything except the blueprint that produced them.
I think about this every time I am tempted to build the finished version of something before the simple version has proven it deserves to exist.
The Quiet Advantage of Staying Unseen
There is a behavioral dimension to this as well. People who maintain their financial position for long stretches of time tend to be far less visible than popular imagination suggests. Visible wealth invites its own complexity — things to manage, insure, protect, explain. What is not on display rarely needs defending, and capital that does not need defending is free to simply keep compounding quietly in the background, without a second set of costs attached to being seen.
The same logic runs well below the level of money. A calendar with fewer standing commitments, a home with fewer possessions, a body with fewer unresolved habits — each carries less that must be actively managed just to remain where it already is. None of it requires abstinence or austerity. It requires only refusing to add a second layer of complexity on top of something that was already working.
Vedlen Observation
Complexity is easy to acquire and expensive to carry.
Simplicity is difficult to build and, once built, carries itself.
The difference between the two is rarely visible on the day either one is chosen.
The Asset Test
Does this addition remove a future decision, or quietly create three new ones?
What I Am Currently Doing
I have started applying a simple rule before adopting anything new into how I work: it has to replace something, not merely sit alongside it. If a new tool or habit cannot clearly retire an existing one, I treat that as a signal rather than an oversight, and I let it wait. I am also working my way back through the small procedures I introduced years ago for reasons I can no longer fully reconstruct, asking, one at a time, whether they still earn their place. Most of them, so far, do not — and cancelling them has cost me nothing except the small discomfort of admitting I did not need them in the first place.
Most of what's left the drawer, I didn't miss.
Compound Selection — The One-In, One-Out Rule
The practice worth adopting from this issue is a single constraint, applied consistently: nothing new enters your systems, your home, or your schedule without something else leaving it first. Not as a rigid ritual, but as a genuine filter. Before adding a tool, a commitment, a possession, or a procedure, name specifically what it will retire. If nothing comes to mind, that absence is the answer.
This does not slow growth. It prevents the particular kind of growth that only adds mass without adding strength — the kind every one of the systems in this issue eventually had to refuse in order to keep working.
Closing Thought
The instinct, almost always, is to solve a problem by adding something to it.
The harder and better instinct is to ask what could be removed instead.
See you next Tuesday.