When something goes wrong in a making endeavor, the first thing you do is look at what's visibly failing. Output isn't shipping. Users aren't happy. The team keeps making the same mistakes. Whatever the pain is, you go to the pain and try to fix it there.
This instinct is almost always wrong.
Not because the pain isn't real. It is. But the making network is strongly connected. Every system influences every other system through chains of activity. Problems don't stay where they start. They propagate. By the time a failure becomes visible, it's usually showing up far from where it originated. And intervening at the symptom doesn't just fail to help. It often makes things actively worse.
Six signatures
Each of the six activities serves a specific structural function. When one breaks or goes missing, it produces a characteristic failure. Learning to read these signatures is the first step toward finding the real break.
Missing Validation (nothing testing whether what exists serves the actual need): You get products that meet every specification and still fail. The thing works. Nobody wants it. Everything was built correctly. The wrong thing was built.
Missing Verification (nothing examining what output reveals about process): You get the same mistakes repeating across projects. Teams execute, ship, and learn nothing. The same errors recur because nobody reads the output as evidence about capability.
Missing Scoping (nothing bounding ambition to capacity): You get chronic overcommitment. Promises that felt genuine when made but can't be kept. Targets that outpace what can be delivered, every time, as if by compulsion.
Missing Provisioning (nothing building capacity toward what's required): You get stagnation. Ambitious goals paired with a team that never develops the capabilities to reach them. The aspiration grows. The machinery stays the same.
Missing Specification (nothing translating intent into concrete form): You get vagueness. Everyone has a sense of what's needed but nobody can say what the thing should actually be. Work proceeding against criteria that were never articulated.
Missing Delivery (nothing turning capacity into tangible output): You get plans that never materialize. Clear specifications. Capable people. Nothing ships. The gap between concept and artifact widens quietly while everyone stays busy with everything except producing the thing.
You've seen these. You've been inside a few. The question is what you do once you recognize the shape.
The intervention trap
The natural response is to go directly at the visible problem. Output isn't shipping? Push harder on production. Users aren't satisfied? Ship more features. Same mistakes recurring? Invest in testing. Requirements vague? Hire a requirements analyst.
Sometimes this works. If the problem really is local, if a specific activity is failing because of an execution issue right there, then fixing it there helps.
But if the problem is structural, if it originated somewhere else in the network and cascaded to where you're seeing it, then local intervention produces one of two patterns. Either temporary improvement followed by recurrence: you patched the symptom, the cause is still generating it. Or displacement: the problem shifts to a different visible failure while the root cause persists. Both produce the whack-a-mole dynamic every organization knows: fix one thing, another breaks, fix that, the first one comes back.
The network guarantees this when you treat a cascade effect as a primary break. Strengthening one path doesn't help when the break is upstream on a different path entirely.
Following the break upstream
A PhD student reads constantly. Attends every seminar. Takes notes by the stack. Hasn't produced a chapter draft in two years. When writing happens, most of it gets deleted.
The visible symptom is a Delivery problem. Nothing is being produced. The obvious intervention: write more. Set deadlines. Push.
But look more carefully. The reading never stops. Capability investment is continuous and intense. And when output does appear, it gets destroyed against some standard. This student isn't failing to produce from laziness. The student is failing to produce because the need was never bounded. "The dissertation should be brilliant and comprehensive" is an unbounded target. No preparation feels sufficient when the aspiration has no ceiling. No output survives measurement against an impossible standard.
The primary break is in Scoping: using what you have to constrain what you're pursuing. That question never got asked. So preparation never terminates and production stays blocked. Pushing the student to write more addresses the symptom while the cause keeps running. The real intervention is upstream: bound the need to something achievable given current capacity. Once that happens, preparation can converge and production can begin.
Or take a software company that ships features rapidly. Capable engineers, clear specifications, on-time delivery. Everything is working. Except user churn keeps climbing. The company responds by shipping more features, faster.
Every activity in the production chain is functional. The gap isn't in how things get built. It's in whether anyone is asking if the right things are being built. User churn is evidence that the need was misarticulated. But that evidence isn't being used to test or update the team's understanding of need. It's being used to justify more production.
The missing activity is Validation: using what exists to test whether the need is right. The faster they ship, the faster they build the wrong thing. The attention pattern of the team doesn't foreground that activity. So the signal goes unread, the wrong diagnosis gets applied, and effort intensifies in the direction that's already failing.
The founder's blind spot
One more, because this one illustrates a different mechanism. A founder with a clear vision hires engineers to build it. They build exactly what's specified. The product fails in the market. The founder concludes the team wasn't good enough, fires them, hires a new team, tries again with the same vision.
The structural break is identical: Validation is missing. Evidence from what exists should be testing the vision itself. But the cause isn't structural inattention. It's psychological. The founder's identity has fused with the need. Questioning the vision feels like questioning the founder. The activity is blocked not by absence of information but by refusal to let the information land.
This matters because you can't always fix structural problems with structural interventions alone. Sometimes the break is psychological. Sometimes political. Sometimes cultural. The network tells you where to look. What you find there determines what kind of fix is needed.
The diagnostic
Start where the symptom is. Identify which two systems have a gap between them. Users don't want your product? That's a gap between Need and Solution. Your team keeps repeating mistakes? That's a gap between Solution and Resources.
Then check the activities that directly bridge those two systems. Are they running? Are they functional? If so, the direct bridge is working and the break is somewhere else.
If the direct activities seem functional but the gap persists, move upstream. Follow the network. Weak Delivery often traces to broken Scoping two steps away. Weak Verification traces to vague Specification. Capability stagnation traces to never questioning whether the need driving investment is accurate.
One more test before you intervene: is the problem internal or environmental? If the environment is changing faster than your activities can close the gap between need and outcome, no amount of process improvement will help. The distinguishing question: "If everything external stabilized tomorrow, would this team succeed?" If yes, the problem isn't the team. It's the rate of external change. That requires a different response: faster cycles, reduced coupling to volatile inputs, or patience to wait for stability. Working harder doesn't flip the equation when the environment is moving faster than you can converge.
What changes
Stop chasing symptoms. When something breaks, resist the instinct to intervene where the pain is most visible. Trace the network. Ask which activity, if it were functioning, would have prevented this failure. That's usually a different activity than the one that's visibly broken. Strengthening that upstream activity will do more than any amount of effort at the point of pain.
You don't need to see the whole network at once. You just need one discipline: when you see a failure, ask "is the break really here, or is this where something else's break shows up?" That single question changes the trajectory of most interventions.