Team Ownership as Feudal Tenure

The contemporary software organization’s concept of “team ownership” is best understood not through the lens of rational-legal bureaucracy — which is how it presents itself — but through Weber’s analysis of the feudal lord’s household and the delegation of authority through benefice and fief. The structural parallels are not metaphorical. They are exact, and they explain phenomena that the official discourse of engineering management cannot account for.

Weber observed that the lord’s household is the origin of all administration. Before there is a state, before there are offices in the modern sense, there is a household in which the lord delegates specific functions to members of his retinue. The cupbearer manages drink. The steward manages provisions. The marshal manages horses. These are not roles defined by organizational design; they are personal delegations from the lord to trusted dependents, and the critical feature is that the delegated authority tends, over time, to become the property of the holder rather than a revocable grant from above.

This is, precisely, what happens when a VP of Engineering creates a team and assigns it ownership of a service. The delegation is presented in rational-legal terms — a charter document, an entry in the service catalogue, a Slack channel named #team-payments-platform. But the actual social relation is patrimonial. The team does not own the service the way a contractor owns a deliverable. It owns the service the way a vassal holds a fief: by grant from above, maintained through continued performance of obligations (on-call rotations, quarterly roadmap commitments, attendance at architecture review), and defended against rival claimants with a ferocity that has nothing to do with organizational efficiency and everything to do with the fief being the basis of the team’s continued existence and status.

Weber identified the central tension of feudal administration as the conflict between the lord’s need to maintain authority and the vassal’s tendency to treat delegated power as hereditary right. The lord grants a fief so that the vassal will administer it on his behalf. The vassal, having received the fief, proceeds to administer it on his own behalf, and the lord discovers that reclaiming the delegation requires a confrontation he would rather avoid. This is why service ownership is so difficult to reassign. The engineering director who proposes moving the payments service from Team A to Team B is not making an organizational design decision. He is attempting to dispossess a vassal, and he will encounter exactly the resistance that any feudal lord encounters when attempting the same: appeals to historical right, claims of specialized knowledge that cannot be transferred, dark warnings about what will happen to the fief if its current holder is removed. The vassal does not say “this is my fief and I refuse to surrender it.” The vassal says “we have deep context on this system and a transition would introduce unacceptable risk,” which is the same sentence in rational-legal costume.

The microservices movement, read through Weber, is the parcellation of sovereignty. The lord, finding his domain too large to administer directly, breaks it into fiefs and distributes them. Each vassal receives a bounded territory — a service with defined API boundaries — and is granted autonomy within it. The lord retains nominal suzerainty (the architecture review board, the ADR process, the platform team’s “golden path”), but actual governance is local. Each team establishes its own customs: its own deployment practices, its own on-call rotation, its own observability stack, its own configuration format. These local customs are not defiance of the center. They are the natural consequence of delegated authority operating over time without direct supervision, which is what Weber meant by the feudalization of administration.

The platform team occupies the position of the royal household attempting to reassert central control over an already-feudalized landscape. Its instruments — the internal developer platform, the standardized toolchain, the service mesh — are the feudal equivalent of the itinerant court: an apparatus that travels to each fief and attempts to impose uniform standards. The vassals comply to the minimum extent required to maintain the lord’s favor and then continue as before. This is why platform adoption is “mandatory” in the ADR and spotty in practice. The lord has decreed. The vassals have nodded. The fiefs remain unchanged. The platform team, like the Carolingian missi dominici, sends emissaries to audit compliance and writes reports that the lord reads with diminishing attention.

The serf, in this arrangement, is the junior engineer who inherits a service they did not build, do not fully understand, and cannot leave without leaving the team. Their relationship to the code is not ownership but adscription — they are bound to the land. They tend it. They are on call for it. They did not choose it. The service was there when they arrived, and the accumulated customs of the fief (the undocumented configuration precedence, the deployment script that must be run twice, the Datadog monitor that alerts on Thursdays for reasons no living person remembers) are transmitted to them not as rational procedures but as feudal custom: “this is how it has always been done.” The serf’s labor maintains the fief. The fief’s existence justifies the vassal’s position. The vassal’s position secures the lord’s claim to effective governance. Everyone is invested in the arrangement except the person doing the actual work, who is invested in it too, because the alternative is to leave the fief and arrive at another one with different customs and the same structure.

Weber’s deepest insight about feudalism was that it is not a failure of rational administration but a stable alternative to it — one that persists precisely because it distributes just enough autonomy to prevent rebellion while concentrating just enough authority to prevent dissolution. Team ownership in the contemporary software organization has the same quality. It is not a transitional phase on the way to something more rational. It is the equilibrium. The lord will continue to grant fiefs. The vassals will continue to treat them as hereditary. The serfs will continue to tend the land. The platform team will continue to issue decrees. And the system will continue to function, not because it is well-designed, but because — as the Manifesto would have it — it has always functioned this way, no one can fully explain why, and this is, in any case, the more Austrian condition.