Desired State Org Design

Modeling the org as a desired-state system

Tobias Lutke has described applying to org design the same architectural pattern that governs React and Kubernetes: define what the system should look like, measure what it actually looks like, and compute the minimum set of operations to reconcile the two. He calls Shopify's implementation of this "Shopify OS."¹ Rather than treating the org chart as a document produced by negotiation, the model treats it as a live, queryable specification the company is always moving toward.

The mechanics are literal software. Lutke says Shopify OS was built on GitHub as a working project: Python code and configuration files specifying which titles exist, which levels exist, and how many people should report to a manager, with compensation and market data imported and converted to machine-readable form. A SAT solver takes the constraints as inputs and computes an org structure. The first version, by his account, was "utterly incorrect," but the exercise surfaced the real state of the company: roughly 8,000 employees carrying 5,500 different titles, with "senior staff" outranking "director" in some groups and the reverse in others.¹ Making the org software-addressable made every incoherent local decision visible.

HR as reconciler, politics made legible

Under this framing HR's function is not to run programs but to be the reconciler: to measure the gap between the computed desired state and the actual org and take the minimum steps to close it. Lutke presents the concrete benefit as depoliticizing resource allocation. In the informal model, a head of sales asks for fifty new hires, agreement happens somewhere, and engineering headcount quietly shrinks to compensate without anyone explicitly deciding to deprioritize engineering. In the desired-state model the request enters the system, which computes the tradeoff and states it plainly: to add those roles within a headcount constraint, other teams must shrink or the budget must grow. Lutke's contention is that the formal version makes hidden tradeoffs legible rather than leaving them buried in the budget process.

Two products of the same exercise follow. Shopify built a mastery track for every discipline, with comparable levels on both the individual-contributor and management paths, so that an IC who is, in Lutke's words, "insanely good" can out-earn a vice president. He notes the practical effect that great engineers who had become managers largely to earn more could return to the work they were best at, observing that "the best place to recruit more great engineers was my own management team."¹ The framework also produced an agency-based compensation system, prompted by a roughly 80 percent stock decline from its 2021 peak that had left employees holding underwater options, in which employees reallocate total comp across cash, RSUs, Shop cash, and locked stock quarterly, which he describes as designing away the underwater-options problem rather than remediating it after the fact.

A hand-crafted counterpart

Brad Jacobs reaches a similar destination by a different method. Where Lutke encodes constraints and runs a solver, Jacobs audits acquired companies by eye and hand-designs the org "from scratch to match" where the business actually makes money. His recurring finding rhymes with the Shopify OS discovery of title drift: in acquired companies, he says, "the org chart is messed up, 100 times out of a hundred," citing managers of one to three people and businesses running nine layers where he runs roughly five. Both treat org structure as something that drifts into incoherence by default and must be actively reconciled to a desired state, one through a solver over measurable constraints and one through an operator's judgment about the profit engine.

The approach connects to adjacent org-design ideas. It is the tooling that lets a team-of-teams structure hold together at scale without drifting, and it is a direct attack on the coordination cost named in Coase's theory of the firm. Lutke is explicit about its limits: a solver cannot encode which engineer is far more productive or which manager holds a team together, the hardest part is deciding what the desired state should be, and real org changes carry human latency that no config file captures.¹