Your Velox

Kai drives home after the meeting.

Six months ago, he brought Team Topologies to Velox. He read the book, ran the workshop, mapped the streams, stood up the beginnings of a platform team. The first steps are in place. Stream-aligned teams. A nascent platform team. People have the vocabulary now.

And yet: nothing is noticeably faster.

He doesn't say this out loud. He thinks it on the drive home. He opens his notebook at a red light and writes something, then puts it away.

You've had this thought. Maybe not about Team Topologies specifically, maybe about the last reorg, the last OKR cycle, the last time someone brought in an Agile coach and ran a two-day training. Something changed. The change was real. And six months later, the problems were still there, wearing different names.

The question Kai doesn't ask out loud yet is: why?

The problem with naming too specifically

There's a pattern in how organizations respond to growth pain that almost guarantees the problem will return.

Someone on the leadership team observes a symptom. The symptom gets named, specifically, concretely, at the level where it's most visible. "Team A and Team B aren't communicating well." This feels like progress: the problem has a name, and names imply solutions. So solutions arrive. A new Slack channel. A weekly sync. A responsibility matrix.

The symptom disappears. The system stays unchanged.

Six months later, the problem surfaces again. Different team names. Slightly different symptom surface. Same underlying dynamic.

The issue isn't that point solutions don't work, they often do, temporarily. The issue is that naming a problem too specifically produces solutions that operate at the wrong level of the system. "Team A and Team B don't communicate well" locates the problem in the relationship between two teams. It implies the fix is relational, better meetings, clearer expectations, maybe a team-building exercise. But the actual cause might be that Team A's ownership domain and Team B's overlap in a way that makes coordination expensive regardless of how much the individuals like each other.

Fix the relationship. The structural condition that makes the relationship hard persists. The relationship gets hard again.

This is what Donella Meadows called intervening at the wrong leverage point: pushing on a part of the system that's easy to change but has low impact on how the system actually behaves. Parameters, the specific values, the individual relationships, the surface-level symptoms, are the most accessible part of any system and the least powerful place to push.

This is what Kai is circling in that notebook on the drive home. The framework gave Velox a vocabulary. It changed how people talk about team types. It created new names for things that already existed. What it couldn't change, what no framework can change by itself: the underlying structural conditions that made coordination expensive in the first place. If the ownership domains still overlap ambiguously, if the technical coupling still exists, if the decision authority is still mismatched, the framework vocabulary sits on top of those conditions without resolving them.

The framework didn't fail. The naming did. The intervention was applied at the level of "how teams are labeled" rather than at the level of "what conditions make coordination hard."

Finding the right altitude

The ability to name your own organizational problem at the right level of abstraction, not too specific, not too vague, is the prerequisite for any structural change. Most org problems stay unsolved not because solutions are missing, but because no shared problem definition exists.

"Right level of abstraction" sounds like a procedural thing, but it's actually a judgment call that takes practice. Here's a rough guide.

Too specific: The problem is named at the level of a symptom, a team, or an interaction. "Team A and Team B don't communicate well." "The mobile API handoff is broken." "Lars and Priya disagree about priorities." These are real observations, but they locate the problem in a specific relationship or event. They imply specific relationship-level solutions, and they don't transfer, if Team A and Team C have the same issue next month, you're naming a new problem.

Too abstract: The problem is named at the level of culture or values. "We have a communication problem." "People aren't taking ownership." "We're not aligned." These are real patterns, but they're too diffuse to act on. Everything is connected to everything. The intervention surface is undefined.

At the right altitude: The problem is named at the level of a system condition, specific enough to point at a structural or social element, general enough to explain a class of symptoms. "Our ownership boundaries don't match our communication needs" explains why Team A and Team B have issues, why the mobile API handoff is unclear, why decisions escalate. It's precise enough to design an intervention around, and general enough that the intervention will address more than one symptom.

The test: if you name the problem correctly, a first-time observer should be able to predict at least two different symptoms that would follow from it. If you need to name the problem differently for each symptom, you're still at the symptom level.

What the Velox perspectives each miss

Go back to the four views in that meeting room, now with this lens in place.

Lars names the problem as an architecture problem. At the right level, that's closer than it looks: "our architecture creates coupling that limits team independence" is a system-level name. But Lars' proposed intervention, break the monolith, addresses one condition while leaving the others intact. He's named a structural force correctly, but incompletely.

Priya names the problem as an ownership problem. "Nobody knows who owns what" is close: "our ownership map doesn't match the decision-making load" is the system-level version. But Priya sees only the social weight this creates for her and her team leads. She's missing the structural origin.

Kai has the broadest view in that room, but he's applying a framework to something the framework was designed to name rather than to change. He's naming at the vocabulary level, which sits between the symptom level and the system level, but doesn't quite reach it.

Maya is the only one asking the system question, "whose problem is this, actually?", and not getting an answer. That question is the right one. The course is, in some ways, an extended attempt to answer it.

The notebook stays on the passenger seat as Kai pulls into his driveway.

He's been at Velox for six months. He brought the frameworks. He ran the workshops. He knows the vocabulary. And sitting in that meeting today, listening to Maya ask whose problem this is, he had a thought he hasn't said out loud yet.

Are we sure we know what kind of organization we actually are?

That question is where we go next.

Exercise