Your Simplest Processes Are Fine. It's the Invisible Ones That'll Sink You

Apple	Spotify

Think about the last time someone forgot to submit their hours.

Time reporting is about as simple as a process gets. You entered your time or you didn't. Your manager approved it or they didn't. It got paid or it didn't. Clear gates, obvious inputs, one owner per step. When something breaks, troubleshooting takes about thirty seconds, because you can walk the chain and find the exact spot where it stopped.

Now think about why a deal stalled somewhere between marketing and delivery.

Marketing ran outbound and touched a list of people. Sales picked some of them up — which ones, and what got sent, and when it handed over to the team doing the actual work — lives in five people's heads and three different tools. When that breaks, nobody can even tell you where. There's no single gate to point at. The failure is spread across departments, and everyone can honestly say they did their part.

Here's the trap: both of these are "processes." They go on the same list. They get the same line in the same status meeting. And most of the time, they get roughly the same amount of attention. That's the mistake — treating a light switch and a power grid like they're the same kind of thing.

The one you can fix, and the one you can't

The reason simple processes feel manageable is that their problems are visible. Slack in a stepwise, go/no-go process sticks out. You can see it, and because you can see it, you'll eventually fix it — often without even meaning to.

Complex processes hide their problems. Multiple inputs colliding at the same step, data owned by different people, work that crosses department lines — the deficiencies are there, but they're invisible until something big goes wrong. And because they're invisible, we don't give them a second look. We spend our energy tuning the process we can already see clearly, and we leave the expensive, tangled one alone because we can't get a handle on it.

That's the whole problem in one sentence. The simple processes broadcast their failures. The complicated ones swallow them. So the debt collects exactly where you're least likely to be looking.

Why it never gets simpler on its own

There's a comforting fantasy that if we could just understand our complexity, we could make it simpler. Sometimes that's true. Most of the time it isn't.

A process is never simpler than it is on day one. After that, it drifts toward complexity the way everything drifts toward entropy — steadily, quietly, without anyone deciding it should. Part of that is just human nature. We like things the way they are, even when the way they are is bad. Change is uncomfortable, so we avoid it, and the workarounds pile up.

The rare exception is when someone flips the apple cart — a system migration, a reorg, a new tool. When you're moving from A to B, people are suddenly willing to change, and you get a real shot at simplifying. Which is exactly when most teams blow it. They try to carry every deficiency of the old system into the new one, "fixing" problems that were never real problems to begin with — just accumulated entropy they mistook for requirements. The clean start turns into a faithful reconstruction of the mess.

How complex is it, really?

You don't need a formal index to get a useful read. You need to ask a few honest questions.

Start with the base the process runs on. A process built on Excel or Google Sheets feels simple, but flexibility is a warning sign, not a comfort. Spreadsheets are wonderful precisely because they'll do anything — which means the actual process isn't defined anywhere. It's stored in the head of whoever built the file. The more flexible the foundation, the more human knowledge is holding it together, and the more it costs you when that person leaves. The same logic runs the other way: the more rigid and rules-based the tool, the more discoverable the process, because the tool itself tells you how the work is supposed to go. And the fewer tools and tabs one task touches, the less there is to go wrong.

Then try to hand it off. If the process survives being transferred to someone else, it's better defined than you thought. If it doesn't, most of it was living in someone's head. In knowledge work this is where things quietly break — a manager rattles off ten tasks, the person doing the work hears three, or invents fifteen, and the accountability dissolves in the gap.

Which points at the last question: is there a clear owner? If one specific person is responsible for a step, you can find the failure and fix it. If anyone can reach in and do it, that usually means no one is actually responsible for it. Clear ownership is one of the surest signs a process is legible instead of invisible.

The checklist question

For a long time the answer to all of this was the SOP — write down the steps, hand out the guide. People who use them tend to like them. People who write them tend to lose their minds. And with information a quick question away from an AI tool, a lot of teams are drifting away from formal SOPs entirely.

But there's a version worth keeping, and The Checklist Manifesto nailed why. Pilots run checklists because getting a plane off the ground is complex and business-critical, and people used to die when a step got skipped. Hospitals use care maps for the same reason — not to tell a surgeon how to make the cut, but to make sure someone washed their hands and confirmed the patient. The checklist isn't the work. It's a guardrail around the work.

That's also why a checklist doubles as a complexity gauge. If a process needs a long one to stay safe, that length is telling you something. The catch is that you can't checklist everything — a checklist for your quarterly business review makes sense; a checklist for reading your email is probably a sign you've over-engineered it. And knowledge work resists checklists in general, because the work lives everywhere at once. Nothing is batchable. That scattered, un-batchable quality might be the single biggest source of personal process debt there is.

You can't manage what you can't see

If invisibility is the real danger, then the fix always comes back to making the work visible — and that's harder than it sounds.

Take reporting. In one turnaround, finance could only report on history: activity a month or two old, compared against a forecast, followed by the announcement that the two didn't match. Meanwhile sales knew exactly how many quotes went out today and what the next ninety days looked like. The fix wasn't a prettier report. It was blending the two views — sales's forward-looking signal joined to accounting's discipline about what already happened — so the work everyone was actually doing finally showed up somewhere.

The lesson holds even if you never touch a dashboard: value has to be both transferable and discoverable. If you can't see the work, you can't manage it. A bear can fart in the woods all it wants; if nobody's around, it may as well not have happened.

The debt you can't see

The uncomfortable truth is that complexity behaves like gravity. It compounds whether you're paying attention or not. Left alone, a process doesn't hold steady — it accumulates debt until it's effectively bankrupt.

Your simplest processes will mostly take care of themselves, because you can see when they break. The real risk is sitting in the complicated ones you've been avoiding precisely because they're hard to see into. Those are where the debt hides, and they're the ones worth the honest effort of asking: how complex is this, really, and is it worth what it's costing me?