Why Work Keeps Falling Through the Cracks (and Why It's Not Your People)

Alignment Architecture™ · Episode 04 · Blog

A finished piece of work is sitting still in your company right now.

Nobody rejected it. Everyone did their job. It went nowhere anyway. This episode explains where the cracks actually are, and how to close the most expensive one in about twenty minutes.

Listen on: YouTube · Spotify

Why does work keep falling through the cracks even when everyone does their job?

Here's the pattern. You go looking for the thing that stalled, and you walk it backwards. You ask the person who was supposed to move it, and they say, "I never got the final numbers from Bob." You go to Bob, and Bob says, "I mentioned it on the Monday call. I put it in the drive, like I always do." No matter how far back you trace it, every person you talk to believes they did their piece. Everyone did the right thing, and the work still stopped.

That is the phenomenon you're naming when you say something fell through the cracks. And you can feel the truth in that phrase. The problem isn't sitting inside a person. It's sitting in a gap.

You've already tried to fix this (and here's why it didn't hold)

If you're listening to this show, you've done the work. You have an accountability chart. You have seats defined and owners named. You may have run EOS for years. And things still stall, usually at the same handoffs.

So you tried the obvious things. You decided it was a people problem and hired better, and you watched people be brilliant at the things they own. You added a number to measure, and things got a little sharper, and then stalled again. You spent a quarter building SOPs, and they went into a binder that hasn't been opened since. You bought project management software, and your visibility went up while the movement stayed stuck.

None of it was wrong. But notice what actually improved. You and a few key people simply got faster at rescues. Noticing stalled work and shoving it back into motion quietly became a job in itself. Every time something moves, a person makes it move. That's not a system. That's muscle.

The story of the employee who was quietly filling every crack

I have a client in real estate with a key employee who'd been there more than twenty years. They have the giant binder of procedures. They even have a written procedure for how to order the founder's lunch when he's in the office. On paper, a well-oiled machine.

Then that employee, Pat, decided to move out of state. Immediate panic: what will we do without Pat? We built a remote-work setup that's been good for everyone. We divided up the work on her accountability chart. We hired a strong new person. And we still spent months uncovering all the parts of the job that only ever lived inside Pat's head. She had been monitoring the gaps and filling the cracks for so many years that they didn't look like cracks anymore.

There are places in your business where nothing has fallen through in years. Not because you built a system. Because a person is holding it with their bare hands.

Where are the cracks really? Between the seats.

Every crack is between one seat and another. Work rarely goes still inside someone's role. It goes still in the space where one person's output has to become another person's input, and nobody ever designed how that crossing happens.

"Work doesn't stall in seats. It stalls at the seams."

Your accountability chart is a map of ownership. It answers what has to get done and who owns it. What you need, and what almost no company has, is a map of flow: how the information each person needs arrives at the right time, in the right form, from the right source. Think of the building you're in. Somewhere there's a drawing of the rooms and walls and doors. That's your accountability chart. Somewhere else there's a wiring diagram, the circuits behind the walls. You flip a switch and the light comes on because someone once designed that connection. Most companies have the room drawing and no wiring diagram. You know who owns what. You don't know how anything moves. And nothing moves on its own.

I call that second drawing your execution architecture. It's the layer between knowing who owns what and the work actually getting done, and it's the layer an operating system like EOS never addresses.

The Production Flow Model: find every seam

Every business, whatever it does, has at least four functions the work flows through in order. Marketing finds your clients. Sales converts them. Delivery serves them. Finance gets you paid. Between each one, the work has to cross a border. Marketing hands to sales. Sales hands to delivery. Delivery hands to finance. Those crossings are your seams. That's three, minimum, before you count anything else.

And you have to count more, because the seams don't stop at the big borders. Zoom into any one function and the work is changing hands constantly. On an operations floor, an estimate becomes a work order, the work order goes to scheduling, scheduling goes to materials, production hands to quality, quality hands to shipping, shipping hands to finance for the invoice. Every one of those steps is a seam. A seam is anywhere important information has to change hands, whether it's between two departments or two desks that sit next to each other.

This is why marketing and sales are so often at war. Marketing swears the leads are good. Sales swears the leads are junk. Both sides have data. Both sides are exhausted. It looks exactly like a people problem. Nine times out of ten, nobody ever designed what crosses that seam. What does a lead have to include? What triggers the handoff? What does sales send back so marketing can adjust? Two competent teams, one undesigned seam, and years of blame flowing both directions.

The five handoff questions

Point these five questions at any seam and what was invisible becomes visible:

1. Origin: Where does this information come from?
2. Destination: Where does it need to land?
3. Trigger: What makes it move? Not who is supposed to move it, but what actually fires the handoff.
4. Format: What shape does it travel in?
5. Failure mode: When it doesn't arrive, what breaks downstream, and how long until someone notices?

Everyone can answer origin and destination. The one that exposes the truth is the trigger. Ask most companies what fires a handoff and the honest answer is, "Someone remembers." A mission-critical handoff should never depend on a human memory on a busy Thursday. It deserves a trigger built into a tool your people already touch, so the movement happens whether anyone remembers or not.

The four states of a handoff

1. Designed — An explicit system exists: a trigger, a format, a route, all defined and working. You know you're here when people can be out of the office and the handoff still fires.
2. Informal — It works by habit and goodwill, because the person has been there twenty years and just knows. Informal feels like culture, and it's the state where you're most exposed. You're one resignation away from no system at all.
3. Founder-dependent — You, or a key executive, are the trigger, the route, and the translator. Step away for a while and the handoff simply stops.
4. Missing — Nothing exists. The information doesn't travel, and everyone downstream works without it. Work getting done twice because it never moved once.

Map a whole company this way and the result is always the same kind of surprise. A twenty-person company can have more seams than people. A handful come back designed. Most come back informal. Plenty are founder-dependent. And a few are missing and never got noticed. On paper the company looks structured. In reality, a lot of it is improvisation.

But isn't this what my SOPs are for?

They sound the same. They're not. Execution architecture maps a flow and writes down all five elements, especially the trigger. Your SOP binder describes how everything should work and then sits in a cabinet until a new hire needs training, at which point the training mostly reveals how far reality has drifted from the document.

The point was never that writing things down doesn't work. The point of execution architecture is to write things down. What fails is the belief that writing it down was the fix by itself. An SOP might describe a handoff, but it rarely defines the format and it almost never includes a trigger, so moving the work still depends on someone remembering to consult a binder. You've written something you hope will happen. You haven't built a system that makes sure it does. You draw the map first, seam by seam, in writing. That's the blueprint. Then you do the wiring: you design how the seams get filled and you take the trigger off human memory, so the right behavior becomes the only behavior.

Founder-dependent seams live in two zones

Look at your founder-dependent seams. They exist for one of two reasons. Either no route around you was ever designed, so the information comes to you because there's nowhere else for it to go. That's a structural gap, it lives above the waterline, and everything here will fix it: draw the route, build the trigger, and it's no longer yours to hold.

Or a route exists, or easily could, and the work still comes to you because some part of it coming to you feels like your job. That one isn't structural. That lives below the waterline, and it will stay with you even after you've drawn every map. I have plenty of these in my own business, and I do this for a living. So when I ask you to look honestly at the second reason, I'm asking from right beside you, not from above you.

Both zones have to move together. You build the route, and you do the internal work to let the route go. Do one without the other and it won't stick. Do both, and it holds.

I don't want you to stop caring. That care is what makes you and your company valuable. The question is where the caring lives. Care that lives in your hands means the work moves when you move. Care that lives in the design keeps the work moving whether you're available or not. It's the same care, at a higher altitude.

Your action step — the five handoff questions

Take one piece of work that stalled, find the seam where it went still, and put the two people on either side of it in a room for twenty minutes. Walk these five questions out loud: Origin / Destination / Trigger / Format / Failure Mode.

Frequently asked questions

Why does work fall through the cracks when everyone did their job?

Because the stall usually isn't inside anyone's role. It's at the seam between two roles, where one person's output becomes another's input, and no one ever designed how that handoff fires. Everyone can be doing their job perfectly and the work still stops in the gap between them.

What is execution architecture?

It's the map of how work flows through your company, the wiring diagram under the accountability chart. Where the chart shows who owns what, execution architecture shows how information moves from seat to seat: its origin, destination, trigger, format, and failure mode.

Why isn't my accountability chart enough?

The chart answers what has to get done and who owns it. It doesn't answer the third question that decides whether work actually moves: how does the work flow? Ownership and flow are two different drawings, and most companies only have the first one.

Are SOPs the same as execution architecture?

No. An SOP describes how something should work and lives in a binder. Execution architecture defines the trigger and format that make the handoff fire without anyone remembering to check the binder. The writing down isn't the fix; building the trigger into a daily tool is.

How do I start fixing this?

Take one piece of work that stalled, find the seam where it went still, and put the two people on either side of it in a room for twenty minutes. Walk the five handoff questions out loud. Then take the Waterline Check to see whether your bigger constraint is structural or something only you can change.