The view from every level
I’ve spent fifteen-plus years in tech, and I’ve been every person in the room: the helpdesk tech supporting hundreds of tools he didn’t choose, the systems engineer vetting the tools before purchase, the account manager explaining them to skeptical business owners, the solutions engineer owning delivery from discovery to close, the co-founder building the product, the director deciding what gets signed. Across healthcare labs, a state institution, MSPs, community health, and fintech.
Most people inside a company see one slice of how it works — their role, their team, their layer. That’s not a criticism; it’s structural. But it means most diagnoses of “what’s wrong here” are made from inside a single layer, and they’re usually wrong in the same way: they mistake where a problem surfaces for where it lives.
The five layers
Organizations, like products, must be intentionally designed. The Foundation Layer is how I map that design — five layers, bottom to top:
The order matters. Operations, Infrastructure, and Clarity are the foundation — where the real work lives. Delivery and Signal are output — where everyone looks. Customers only ever touch L5. Executives mostly watch L4 and L5. And so the company’s entire attention naturally pools at the top of a structure whose failures start at the bottom.
Why the obvious fix keeps failing
When something breaks at L5 — churn ticks up, support drowns, a launch lands badly — the instinct is to fix it where it hurts. More tools, more headcount, more process bolted onto the place that’s complaining. It feels like a response, it’s usually expensive, and it tends not to hold, because the place a problem shows up is rarely the place it comes from.
Support drowning in tickets is rarely a support problem. Usually it’s L2 — documentation that doesn’t exist, systems people have quietly built workarounds for — or L3, where decisions never make it to the people doing the work. Buy support a better ticketing tool and you’ve made the same confusion move faster.
What fixing at the foundation looks like
At an MSP where I was the first dedicated projects hire, onboarding ran on tribal knowledge and every engagement worked its process out from scratch. Nobody was complaining about undefined handoffs between sales and delivery. They were complaining that onboarding was slow. The fix wasn’t onboarding software, it was L1 and L3 work: standard scopes, a mapped handoff path, a set cadence for talking to stakeholders. Onboarding got about a quarter faster and stayed that way after I left, which is the part I care about — a fix that needs you standing next to it isn’t a fix.
At a payments platform, integration pain always turned up during delivery: a vendor API behaving nothing like its documentation, found halfway through the build. On paper that reads as an L4 problem, integrations running late. It was really L2. So we put a gate in front of the dev team — every vendor API gets exercised for auth, edge cases, failure modes and whether the docs are telling the truth, before anyone commits to it. Same engineers, same vendors. The surprises just arrive early now, when they’re still cheap.
The part people don’t like
If any of this is right, the question worth asking isn’t “how do we fix what customers are experiencing?” It’s “which layer is actually producing this?” And answering that honestly usually takes someone who has done the job at the layer in question, not just watched it from above. That’s the only reason I put any weight on having worked all of them — I’ve seen the same patterns repeat in five industries, from the bottom and the top.
Most problems surface at L5. Most fixes start at L1. Companies that get this stop buying tools to manage their symptoms and start fixing the thing generating them.
If this maps to something you’re seeing in your own company, that’s the work I do. You can also see the framework applied to real systems in UAT-Ops.