One Organization, Two Systems

Step back from the meeting room for a moment. Before we follow that conversation any further, before we watch Lars and Priya defend their diagnoses and Maya ask for a first step, let's talk about what Velox actually is. Not what it sells. Not how many engineers it has. What it is as an organization. Because the reason that meeting is going in circles isn't a personality conflict or a communication failure. It's that everyone in the room is looking at one part of a system that has two parts. And in a system like that, you cannot fix your way out by pulling on one thread.

The useful distinction

Every software product organization has two subsystems. They're not separate organizations and they don't live in separate buildings. They exist simultaneously, inside the same company, and they shape each other continuously.

The first is the technical subsystem: the codebase, the deployment infrastructure, the toolchain, the processes that define how software moves from idea to production. At Velox, this is the Rails monolith that grew with the company, the CI pipeline that was built for five engineers and hasn't been revisited since the team tripled, the deployment process that three teams are now sharing in ways it wasn't designed for.

The second is the social subsystem: the teams, the roles, the communication pathways, the structures through which people make decisions and coordinate. At Velox, this is the five team leads reporting to Priya, the ownership model that was clear when everyone sat together and has become ambiguous since the org grew, the escalation patterns that bring decisions to Maya's desk that she didn't intend to own.

The useful distinction here is not that these are different departments or different concerns. It's that they each have their own logic, their own inertia, and their own failure modes, and that each one shapes the other in ways that are often invisible until something breaks.

Each subsystem has its own logic and its own failure mode. The gap between them is where the Velox release spent three weeks in staging.

What Lars is looking at, and what he isn't

Lars sees the technical subsystem clearly. The Velox monolith is genuinely overloaded. Teams that should be able to deploy independently are coupled through shared database tables, shared process logic, and a deployment pipeline that serializes what should be concurrent. When Lars says the architecture needs to change, he is not wrong. The technical subsystem is a real constraint on the speed the company needs.

What Lars is not looking at is the social subsystem. His proposed intervention - refactor the monolith, decouple the services, let teams operate independently - will improve the technical structure. But the ownership ambiguity that Priya describes daily, the decision escalations that land on Maya's desk, the coordination patterns that produce invisible blocking - none of these are downstream of the monolith. They exist in the social subsystem, and they will persist in a cleaner architecture unless the social system changes too.

There's a version of Velox that has clean microservices and the same coordination failures, because the boundaries between services don't match the boundaries between teams, and no one has resolved whose service is whose. Lars's intervention is real. Its scope is one subsystem.

What Priya is looking at, and what she isn't

Priya sees the social subsystem clearly. Ownership has become ambiguous as the company grew, there was never a formal conversation about which team owns which part of the product, because when everyone shared a codebase and a room, it didn't matter. Now it matters enormously, and the answer doesn't exist. Priya is right that this needs to change.

What Priya is not looking at is the technical subsystem. The ownership conversation she wants to have will founder on the technical coupling that Lars is describing. Even if Priya's team clearly agrees that Team A owns the billing flow, the billing flow shares database tables with four other parts of the monolith that other teams touch. Clear ownership, applied to a tightly coupled technical system, doesn't produce independence - it produces friction at every coupling point. Priya's intervention is real. Its scope is also one subsystem.

This is why the meeting that Maya called is going in circles. Lars and Priya are both looking at real problems. Their proposed interventions are both legitimate. And they never quite intersect, because each one solves for one side of a two-sided system, and neither proposed change makes the other unnecessary.

Every intervention has a scope

This doesn't mean you have to fix everything at once. That's not a practical instruction for running an organization, and it's not what we're building toward in this course.

What it means is that every intervention has a scope, and the scope has consequences.

Break the monolith: that's a real improvement, with a real gap on the social side. Clarify ownership: that's a real improvement, with a real gap on the technical side. Both changes will make things better in the dimension they address. Both will surface the other side of the problem in a new form, probably within six months of implementation.

This is the actual friction of organizational change in software companies. It's not that the proposed interventions are wrong. It's that organizations are two-sided systems and we tend to address them one side at a time, because one side at a time is faster, more measurable, and considerably easier to get organizational approval for. A monolith refactor has a project, a scope, and a definition of done. "Redesign the social coordination structure simultaneously" has none of those things, and that's not incidental. It's the reason it gets deferred.

Most organizations discover this gap not in planning, but in the retrospective after the next incident. After the monolith is cleaner but the release delays have moved somewhere else. After ownership is clarified but the coupling makes the clarity theoretical.

The meeting in that Velox conference room will generate some version of this experience. Lars will push something technical forward. Priya will push something structural forward. Both will work. And in six months, Velox will have a new form of the same problem.

Unless someone asks the question that nobody has asked yet. What is this organization, as a system? Not what it builds. What it is.