The team receiving the failure is not always the team causing it

A problem appears in a department. The natural response is to fix the department. Creative is late. Customer Support is overwhelmed. Engineering misses the deadline. Operations is expensive. The restaurant floor keeps making mistakes. The failure is visible there, so attention goes there. Sometimes that is correct. Sometimes the team receiving the failure is simply the first place the organisation can see the cost.

The visible problem

Take the version of this I have seen most often. A delivery team is overworked. Briefs arrive inconsistent. Resourcing is reactive. Iteration runs round after round. Draw a circle around the department and there is plenty inside it worth improving.

So you improve it. Better visibility. Clearer allocation. More deliberate resource planning. Stronger intake. A usable commercial view. The department becomes easier to plan and more predictable. Then something more interesting happens. The remaining problems do not disappear. They become easier to locate.

Instrumentation changes the argument

Before a system is visible, organisations often argue through impressions. This team is slow. That person is difficult. Those people never plan. Creative always overruns. Sales always promises too much. Everybody has examples. The examples are usually real. They are not necessarily the mechanism. Once work, capacity, cost and timing are visible together, the conversation changes.

A late piece of work can be traced. When was it sold? When was the brief complete? When did Creative first see it? How many rounds were scoped? How many were delivered? When did the client expectation change? Who had authority to reopen scope? Where did the extra cost land? The data does not remove judgement. It makes judgement more useful.

Follow the failure upstream

Take a familiar agency shape: a project delivered at a loss. The obvious story is that the delivery team took too long. Follow it backward and the story usually gets longer. Scope was loosely defined at the point of sale. A later request was absorbed rather than renegotiated. The team was brought in after the commitment existed.

The work took more time than the price assumed, and the cost surfaced in the department closest to the delivery. Which team caused it? The question stops being useful, because the mechanism crossed several of them. One shaped the promise, one shaped the expectation, one shaped the information available, one shaped the execution, and the numbers showed up last.

The loss belongs to the system. Responsibility still belongs to people, but to different people at different points, and rarely to the ones standing nearest the failure.

Organisations like local explanations

Structural explanations are inconvenient. A local explanation gives you somewhere to point. The Creative Director needs to manage better. The Account Director needs to be more commercial. The chef needs to train the team. The Operations person needs a better process. A system explanation often asks several people to change at once.

It may challenge a commercial incentive. It may reveal that someone has accountability without the authority to use it. It may show that a person behaving badly is also behaving rationally inside the system they were handed. That does not excuse the behaviour. It changes the intervention.

The front line is where strategy becomes expensive

This pattern appears far beyond agencies. Customer Support receives product decisions. Frontline hospitality receives staffing and maintenance decisions. Engineering receives strategic ambiguity. Operations receives promises made elsewhere. Finance receives the cost of all of it eventually. A customer rarely experiences the org chart.

They experience the accumulated decisions travelling through it. That is why frontline teams often look like the problem. They are standing at the point where the system can no longer defer the consequence. The customer is waiting. The launch date has arrived. The invoice needs to be paid. The kitchen ticket is on the rail. The ambiguity has run out of road.

A broken interface can look like a bad person

In a kitchen I helped run, the cooking happened upstairs and the dining room was downstairs, and the dumbwaiter between them did not work. Food moved by hand. Information moved by hand. The formal interface between the two halves of the service was physically broken before anyone got to the human one.

Recurring problems at that handoff were easy to read as somebody's mistakes. Some of them were. But if the same handoff fails repeatedly, the useful question is not only who made the error, it is why the system keeps presenting the same opportunity to make it. So we changed the interface: shared briefings, clearer handoffs, dishes explained, and running food ourselves when it helped. Nobody became a different person.

The conditions just became easier to succeed inside.

Founder dependency can look like a weak team

The pattern shows up again in founder-led businesses. Founders carry an enormous amount of context. Clients, creative direction, new business, delivery knowledge, decisions. When a team needs them constantly, the easy reading is that the team lacks ownership.

But responsibility cannot spread reliably while information, authority and systems stay centralised. Founders in that position are not rescuing weak people. They are functioning as the operating system, which is a compliment and a constraint at the same time. The intervention is not "make the team step up". It is building enough shared visibility, planning and role clarity that stepping up is available to them.

Capacity grows when more of the organisation can carry responsibility without routing every decision through the same few people.

Look for the mechanism, not the villain

Systems thinking can become irritating when it turns every obvious problem into a diagram. Sometimes the person really did make a poor decision. Sometimes a manager is weak. Sometimes a team lacks skill. Sometimes someone knew the rule and ignored it. The system lens is not an excuse to dissolve personal accountability into arrows.

The point is to locate accountability more accurately. Ask: What happened? What was the person expected to do? Did they know? Could they do it? Did they have the information? Did they have the authority? What incentives shaped the choice? Does the same failure happen with different people? If the problem survives several competent people, the mechanism probably deserves attention.

The smallest useful intervention

Once you find a system problem, there is another temptation. Redesign everything. New structure. New tool. New governance. New meeting. New framework. Sometimes that is warranted. Often the useful intervention is smaller. Make one decision right explicit. Put one piece of work in a shared place. Give one person commercial visibility.

Change one handoff. Stop work entering without a brief. Alter one incentive. The intervention should match the mechanism. If the problem is unclear approval, do not reorganise the department. If the problem is how the work was priced, a productivity workshop will not touch it. If the problem is dependency on a few people, hiring more people into the dependency does not resolve it.

The useful question

When a team looks broken, fix what is genuinely broken inside it. But do not stop there merely because the pain is visible. Compare what people think is happening with what the work, numbers and system say is happening. Trace the failure backward. Find where the promise was made. Where information disappeared. Where authority changed.

Where the incentive moved. Where the cost finally landed. The team receiving the failure may be responsible for part of it. It may also be the organisation's most expensive warning light. Do not fix the warning light until you know what it is warning you about.