The Org Chart Is a System Schema

Executive Summary

The most consequential piece of software design most executives ever do is the org chart, and almost none of them experience it as software design.

An operating model gets settled in a room the systems people were not in, drawn as boxes with lines between them, and then handed over as context for the real work of configuration. It is not context. It is a specification. And the parts of it nobody actually decided do not announce themselves. They surface later, as defects.

The Symptom: Burnout as a Routing Error

Consider what a load balancer does when two of three nodes are unhealthy. It does not run the service at a third of capacity and shed the rest politely. It routes everything to the node that responds — and that node, now carrying three times its design load, fails in a way that looks like its own weakness rather than the system’s.

Human systems route the same way, with one cruel difference: servers do not feel obliged. People absorb overflow because refusing it means visibly letting the business down, so the routing is invisible until someone resigns.

The Gartner numbers suggest this is close to the normal condition. In a February 2023 survey, only 9% of HR functions were both highly efficient and highly aligned to business needs. Meanwhile, 71% reported that burnout was more challenging than before the pandemic, and 55% said they were receiving more requests across a wider variety of topics. [Source: Gartner, February 2023 survey of 217 HR leaders]

The survey does not establish that the first two numbers cause the third. But rising demand meeting an unfinished structure has to land somewhere, and the burnout figure is at least consistent with where. Burnout in a well-designed function is rarely a signal about the person. It is a signal about where the load is going.

The Root Cause: Partial Implementation

A well-documented case of this failure is the adoption of the “Ulrich model” in HR—splitting the function into business partners, centers of excellence (CoE), and shared services.

The design assumes all three legs are actually able to do their part. What organizations get instead is uneven maturity: a capable partner layer sitting on top of a shared services function that cannot yet take the operational work, and a CoE not yet producing the standards the partners are supposed to deploy.

The work does not pause while the immature legs mature. It goes to whoever can do it. Practitioner accounts of this are consistent: partners absorb transactional load because shared services cannot yet carry it, improvise policy that was never written, and fit strategic work into whatever remains. Some call it the business partner as postman.

It is worth knowing what was actually adopted. Ulrich’s 1997 book proposed four roles as deliverables, not departments; the three-legged structure came later, from consultancies operationalizing those roles, and he has consistently said he did not create it. [Source: Ulrich, Human Resource Champions, 1997] When organizations buy the boxes without building the outcomes, they lose the control plane (enterprise governance) and the runtime (front-line execution). Unowned work does not queue. It finds the nearest component that will accept it.

The Translation: Reading the Operating Model as a Schema

Every operating model is a specification that somebody will eventually have to implement in software. The org chart is the informal version. The system is where the informality becomes expensive.

1. Decision Rights are the Authorization Model

Governance frameworks read as slideware to anyone with an engineering background. They should not. When a model specifies who sets enterprise policy, who adapts it locally, and who executes, it is specifying roles, permission scopes, and approval chains. It is an authorization model in prose.

A team that cannot state its decision rights cannot configure any system. What it produces instead is the default configuration, which becomes the de facto governance—decided by whoever filled in the form, ratified by nobody.

2. The Service Catalog is the Interface Contract

Strip the domain vocabulary from a shared services function and what remains is service management: a catalog of services, tiered resolution, response commitments, and escalation rules.

A catalog states what each leg owes the others and what a request is entitled to expect. Without it, boundaries are negotiated case by case. There is no contract to point at when declining work, which is precisely why the strong leg absorbs everything.

3. The Employee Lifecycle is a State Machine

Attendance, onboarding, promotion, and exit are often treated as documents in folders. Model them instead as transitions over an entity, each with an actor, a timestamp, an approval, and a resulting state.

When you do this, the audit trail becomes the transition log. Procedure documents become versioned configuration. Offboarding becomes a terminal transition with mandatory predecessors rather than a checklist.

The Executive Playbook

If your strong leg is quietly paying the bill for the other two, here is how to stop funding the routing failure and start fixing the system:

1. Write the service catalog before buying the software. Immature systems are the visible symptom, so software becomes the first purchase. Stop. The catalog and the decision rights are prerequisites to procurement. List every service the function delivers, name the leg that should own it, and mark where it is actually being delivered today. That single document exposes the routing and sizes the gap.

2. Sequence the legs deliberately. A structure announced on a Monday is not a structure that exists. Do not announce three legs and let the strong one silently cover for the others. Name what each leg owes, be honest about which ones cannot yet deliver, and explicitly hold that work centrally or externally in the interim—with an end date.

3. Measure where time actually goes. If you want to know if your strong leg is absorbing the others, measure its time split between strategic and transactional work. Check the answer against ticket data. The gap between the role as designed and the role as lived is the whole diagnosis.

4. Recognize technology as a core competency, not enabling infrastructure. Across four consecutive rounds of Ulrich’s HR Competency Study, the technology competency escalated rather than receded. [Source: HR Competency Study rounds 4–8, RBL Group] The system is the business function’s product, with IT as the platform provider. Reverse that, and IT ends up making service-design decisions by default, through configuration choices nobody experienced as decisions.

The underlying idea of separating strategic partnership from specialist design and transactional execution is sound. But an org chart is just a schema—a promise about what the system will be asked to do. If you draw the boxes without maturing what sits inside them, you have not implemented an operating model. You have written a specification and handed the bill to the strongest leg.