More People, More Complexity

There is a particular moment that’s recognizable once you've seen it enough times.  A problem stops being a problem and becomes a project.

It usually starts with good intentions because something isn't moving the way it should. The person at the top notices, decides it needs more attention, and begins adding people. A specialist here, a coordinator there, someone from an adjacent team who might have relevant context. The logic is sound on its face – this problem matters, so let's resource it properly.

What happens next is predictable, though it rarely feels that way in the moment.

The scope expands to accommodate the new participants. A problem that had a defined boundary now must account for additional perspectives, additional workstreams, and additional questions that weren't part of the original situation. Meetings are scheduled to bring everyone up to speed.  Those meetings generate follow-up items. The follow-up items require coordination. Somewhere in the expanding circle, the original problem is still waiting but is now surrounded by everything that was added to solve it.

I've watched this happen more times than I can count. The moment the calendar invite goes out with names that weren't there before, something shifts. The people already close to the problem who understood its boundaries and who had a reasonable path to resolution are now navigating a larger room, with more complications. In many cases, the person who assembled that larger room has moved on to the next thing, confident that resources have been deployed.

The coordination burden never distributes evenly. It lands on the people who are most connected to the original problem, the most responsive, and the most capable of holding the threads together.  In some cases, it lands the person least connected to the problem, but who has the greatest bandwidth, which adds additional layers of difficulty.  No one volunteered for the expanded coordination, but this level of expanded structure must have something to keep it from collapsing.

This is what well-intentioned escalation produces. Not more capacity, but more complexity. The problem doesn't get smaller because more people are looking at it. It is harder to resolve because closing it now requires alignment across a group that didn't exist a week ago.

There's a version of this that's entirely appropriate. Some problems genuinely need more people. Gaps in expertise, capacity constraints, decisions that cross functional lines - these are real considerations, and adding the right people at the right moment is good structural thinking. That's not what this is about.

This is about the other version. The one where the problem was manageable, the path was visible, and the addition of people wasn't a response to a genuine gap. It was a response to the discomfort of a problem that hadn't been resolved on its own timeline, and the need to act on the instinct to do something, to show engagement, to apply resources as a proxy for resolution.

The people closest to the problem usually know the difference. They felt the original scope and saw the path, yet they watched it get complicated in a meeting they didn't call for reasons that had more to do with the appearance of action than the mechanics of resolution.

The original problem is still there.  It just got harder to reach.

What the Room Decided Not to Say

The meeting had every reason to go well.

The right people were in the room. Multiple parties, each with a stake in the outcome. A customer present, waiting for clarity on a situation that had already taken longer than it should have. The problem was known and the explanations existed. What was needed was someone to say the situation plainly, set a realistic expectation, and let the customer leave with something they could actually use.

That's not what happened.

What happened instead was a kind of collective hesitation. It was careful, almost choreographed, though no one had planned it that way. The legal representatives weighed their words and the company's representative stayed quiet. Each person in the room made an individual calculation about whether the answer was theirs to give, and each arrived at the same conclusion. Not me. Not now. Not in this room.

The customer asked questions, which were answered at the edges. There was enough engagement to fill the silence but not enough substance to constitute an actual answer. At some point the customer began filling the gaps themselves, out loud, assembling something that resembled a conclusion from the pieces they'd been given. Nobody corrected them. The meeting moved forward the way stuck meetings do, with activity that resembles progress until it ends and nothing has actually been resolved.

There is a particular kind of discomfort that comes from watching this happen. Not participating in the hesitation, but close enough to feel its weight. Close enough to know what answer the customer needed, and to watch the moment for it arrive and pass without anyone reaching for it.

The cultural dynamics in the room were real. There were different norms around directness, around hierarchy, and around who holds the authority to deliver difficult information across company lines. Those aren't imaginary forces. They shape how people behave in rooms like this one, and they explain some of what happened. They don't explain all of it.

The company in that room had a stated value. Transparency. It appears in the language the company uses about itself, in the commitments made to clients, in the identity the company claims. And in the moment when transparency would have meant something - when a customer was sitting across the table waiting for someone to just tell them the truth - the value didn't show up.

That's not a cultural failure. That's an ownership failure. The two can coexist, but they aren't the same thing.

Ownership drift rarely looks like negligence. It looks like a room full of reasonable people, each making a defensible individual decision, that collectively produces an outcome nobody would have chosen. Nobody decided to leave the customer without a real answer. It happened because in the absence of someone willing to own the uncomfortable truth.

The customer left with an answer. It was the one they'd built themselves from incomplete information, assembled in the gaps where a real answer should have been. Nobody corrected them. And that uncorrected answer is now the foundation for whatever comes next.

They Checked Their Own Work First

Something felt off before anyone could name it.

Visible tasks were being completed. Items were being signed off in the portal and notifications were going out. From the outside, the work looked like it was flowing normally. The vendor had lost a key staff member, had a plan to cover the gap, and had made a quiet decision. This was temporary, manageable, not worth raising with the client.

It wasn't temporary. Nor was it manageable alone.

When client team members went to check on critical updates, things weren't there. Fundamental elements, the kind that validate everything built around them, were missing. The team members did what anyone would do: they checked their own work first. Everything on their side was complete. Submitted correctly, documented, done. They hadn't missed anything.

But something was wrong, and they couldn't identify what. They began second-guessing themselves anyway, not because the evidence pointed to them, but because there was no other explanation visible from where they sat. They spent time re-checking work that didn't need to be re-checked. When colleagues asked why complete work had only produced partial results, they had no answer. They were left explaining an outcome they hadn't caused and couldn't account for.

Leadership got involved. Not by choice, and not quickly. There was a period of investigation first. Technology was examined, process gaps were considered, and the possibility that something had been miscommunicated internally was explored. Each thread led back to the same place. The client's side of the work was complete. The gap was somewhere else. Finding it took time that wasn't available for anything else, the kind of diagnostic work that pulls senior attention away from higher-value activity and into a problem that shouldn't have required that level of involvement to surface.

Eventually it required a direct call. Client leadership to vendor leadership. Not a routine check-in, but a specific conversation to ask, plainly, whether something was wrong.

That's when the full picture emerged. A staffing loss. A knowledge gap that was larger than anticipated. A plan to cover it that had worked for a while, until it didn't. A moderate problem became triage faster than anyone could manage it alone.

The vendor wasn't operating in bad faith. They had genuinely believed they could contain it. The decision to stay quiet was made in a moment of reasonable optimism, a belief that the disruption was temporary and manageable, that disclosure would create concern where none was necessary. But reasonable optimism isn't the same as a sound structural decision. The choice to manage it quietly removed the client's ability to prepare, adjust, or help. That's not a moral failure. It's a structural one. The disruption was theirs but the consequences didn't stay that way.

Internal disruptions don't always stay internal. The damage control that feels protective in the moment, keeping things quiet, pushing visible work forward, maintaining the appearance of continuity, can quietly remove the one thing that would have allowed the other side to help. When specialized knowledge walks out with the person who held it, and no one knows quite how to recreate it, the work continues but the foundation doesn't. That gap doesn't announce itself. It shows up later, in someone else's escalation, on someone else's timeline, carried by people who had nothing to do with the original disruption and no way to understand why their complete work kept producing incomplete results.

By then, a conversation that could have happened at the beginning costs significantly more than it would have.

Introduction to The Structural View

There’s a point in many organizations where the same problem begins to show up again. It doesn’t always look identical. Sometimes it appears as a familiar issue that was thought to be resolved, or it is a new situation that feels just different enough to justify revisiting a previous decision. The details change, but the pattern is recognizable.

A decision is made and the team aligns.  The path forward is clear.  But, gradually, the same tension begins to surface again.  Leadership is brought in, again, and additional practical solutions are put in place.  More communication, more resources and time allocation.

Sometimes those changes help, at least temporarily. When the same issue returns, often in a slightly different form, the response tends to follow the same pattern. More meetings, more strategizing why things aren’t working, more changes to the process or to the participants.

From the inside, this often feels like something was missed, or perspectives didn’t fully line up.  Leadership assumes that someone didn’t follow the process, or something broke down along the way.  While those explanations aren’t always wrong, they are often incomplete. In many cases, what’s happening is not a series of isolated issues. It’s the system itself producing the same outcome under slightly different conditions.

“We keep trying to fix it, and that’s part of the problem.”

Decisions that depend on interpretation rather than clear direction tend to be revisited.  Ownership that exists in principle but not in structure begins to shift, and metrics that create clarity without context can develop confidence without resolution.  The visible problem changes. The underlying conditions do not. The organization continues to respond to what it sees, while the same pattern quietly forms again beneath the surface.

This underlying layer is where many recurring problems actually live. They are not in any single decision, or team, or process.  They are in the organizational structure that governs how those decisions move, how ownership is held, and how systems respond under pressure.

This is the problem that tends to go unexamined, even as organizations continue to work to fix what they can see using traditionally accepted methods.  More revisions, more processes, more hiring.

The Structural View operates within this space.  It does not aim to provide immediate answers or replace what is already working.  It looks more closely at the patterns that continue to persist even after they’ve been addressed.

In many cases, the question isn’t just what needs to be fixed.  It’s why the same things keep happening in the first place.