Four People, One Problem

We're going to read the same meeting again.

Not because you missed something. Because the same forty minutes look completely different when you slow them down and pay attention to what each person is actually saying, and what they're not seeing.

Lars: "If we break the monolith, teams can ship independently."

Priya: "The problem is that nobody knows who owns what."

Kai writes in his notebook: Interaction modes are unclear.

Maya says nothing for a long moment. Then: "But whose problem is this, actually?"

Nobody answers. The meeting ends. The plan is to meet again next week.

Here's the thing: all four of them are right. And that's exactly why nothing is getting fixed.

What the same problem looks like from four different positions

Lars isn't wrong about the monolith. Technical coupling is a real constraint: when one team's change can break another team's deployment, teams can't move independently regardless of how motivated they are. The architecture produces the coordination problem.

Priya isn't wrong about ownership. When accountability is unclear, decisions escalate. They land on her desk, and on Maya's, and in meetings that exist only to resolve things that should have been resolvable at the team level. The social structure produces the decision-making problem.

Kai isn't wrong either. Team interaction patterns, how teams hand things off, how they request dependencies, how they communicate across boundaries, determine how well a multi-team organization can actually function. His observation belongs in that notebook, not on the floor.

And Maya isn't wrong about speed. All of this, the coupling, the unclear ownership, the coordination overhead, shows up in the business as slower releases, more slippage, and an organization that's working harder for slower results.

Four correct observations. Four different levels of the same system.

The useful question isn't "which of them is most right?" The useful question is: what does a problem look like when it has to be named from all four positions simultaneously?

What structural and social actually mean

The distinction that makes four partial views coherent is one that we'll carry through the entire course.

Growth pains in software organizations are always both structural, how work is divided and connected, and social, how people coordinate, trust, and decide. Addressing only one side leaves the other intact.

These two words can feel abstract. They don't have to be.

Structural forces are constraints that live in how the work is organized, independent of the people doing it. The monolith Lars wants to break is a structural force: it creates technical coupling that limits team independence regardless of whether people like each other, communicate well, or want to cooperate. The unclear ownership Priya is managing is also structural: when nobody has explicitly defined who is responsible for what, the gap exists in the organization's design, not in anyone's attitude. If you replaced every person at Velox tomorrow with equally capable people who had never met each other, they would encounter exactly the same structural forces.

Social forces are constraints that live in how people actually coordinate, the informal patterns of trust, decision authority, and communication that run underneath the formal structure. When engineers at Velox wait for decisions they feel they should be able to make themselves, that's a social force: something in the relationship between teams and leadership is producing caution and escalation that the org chart alone doesn't explain. When a meeting room can't resolve a clear question because nobody wants to be the one to decide, that's a social force. These patterns are real, they're consequential, and they don't disappear when you redraw the boxes.

The reason this distinction matters is not taxonomic. It's practical. Structural fixes, redrawing team boundaries, clarifying ownership, breaking a monolith, can leave the social system intact. Velox can split into four well-defined teams with explicit ownership domains and still find, six months later, that those teams don't communicate with each other, escalate things they should resolve, and mistrust each other's work. The structural change didn't touch the social patterns. The social patterns will reconstitute the structural problem.

The reverse is equally true. Social fixes, new communication norms, leadership training, psychological safety workshops, can leave the structural system intact. If the architecture still creates coupling, if ownership boundaries are still ambiguous, if decision authority is still misaligned, the structural constraints will create social friction whether or not people like each other.

Both systems need to be considered together, not sequentially.

This is the intuition behind what Emery and Trist, studying organizations since the 1950s, observed about why technical improvements so often produce unexpected social degradation, and vice versa. The two systems are not independent. They shape each other. Optimizing one while ignoring the other doesn't produce a partial improvement. It produces a new problem.

Why "whose problem is it?" has four correct answers

Maya's question, "But whose problem is this, actually?", was meant to get clarity. It produced silence because the correct answer is: all of ours, and we're each looking at a different piece.

In systems like Velox, there is no single root cause. There are multiple valid, incomplete views of the same system. Lars is right about the monolith. Priya is right about ownership. Kai is right about interaction patterns. Maya is right about velocity. Each of them is looking at a real element of a system that has structural AND social dimensions, and the elements interact.

The failure mode here isn't that any of them is wrong. The failure mode is that an organization tries to pick the single most important explanation and fixes only that. The monolith gets broken. The teams are now technically decoupled, but ownership is still unclear, so they build conflicting things anyway. Or ownership gets clarified, but the architecture still couples teams at the infrastructure level, so the clarity doesn't translate into independence.

The skill this course builds isn't "find the one true root cause." It's something harder: learn to hold multiple valid explanations simultaneously, understand how they interact, and know which lens to use when you're making a specific intervention.

There isn't a decision rule that makes this easy. The useful question isn't "structural or social?" It's: what does this symptom tell us about both systems, and what would have to change in each to address it?

That's what we're building toward.

Further Reading

Exercise