One of the more interesting pieces of feedback I got on my org design piece was a question about org structure. In most MBA programs, org design is taught through the lens of organisational structure, not through the lens of design. And so the natural question that emerges is: “Why not talk about org structure instead? Why talk about the skill of org design as an iterative search for form-context fit?”
This turns out to be a really good question. Org structure is a remarkably fertile topic to dig into — and one that serves as a rich source of commentary for many a business pundit. Over the years, Apple’s unusual org structure has often been cited for its ability to innovate (see this lovely HBR piece titled How Apple is Organised for Innovation by Joel Podolny and Morten Hansen for a primer), and the back-and-forth on functional vs unit organisations is a recurring debate that has lasted for decades. If you’re unfamiliar with this debate, I encourage you to read Steven Sinofsky’s and Ben Thompson’s arguments on this very topic, back in 2016, or to refer to Chapter 8 of Andy Grove’s High Output Management — where he says, in effect, ‘every organisation eventually settles on some hybrid organisational structure’.
Of course, a company’s org structure is consequential. Most people are probably familiar with Conway’s Law, which states that “any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure”. Conway’s Law is responsible for the tech industry quip “ahh, they shipped the org chart”, which is muttered anytime one encounters software that is perplexing and complicated and badly put together.
This is probably not surprising! Org structure is the most legible part of the org design skillset — which is, in turn, why so many people seem to enjoy talking about it. As Sinofsky puts it in his piece:
Company organization structure defines both how and what a company builds. It is also one of the few decisions that a CEO can clearly make. Because organization (org) structures appear to be easily distilled down to simple graphs, it is frequently the case that when a company is doing well a given org structure serves as a model for others to follow; and when things are not going well there’s a chorus to change to some obvious alternative. Reality is far more complex, unfortunately.
And indeed reality is ‘far more complex, unfortunately’ — the first half of Sinofsky’s essay on org structure may be read as a short history of Microsoft’s iteration in search for good form-context fit.
The Interplay between Structure, Incentives and Culture
I’ve never enjoyed comparative discussions about org charts, and I’ve pushed back on discussions about org structure alone whenever someone brings it up in conversation. For a number of years now, I’ve argued with friends and colleagues that org structure is insufficient to capture the actual practice of org design.
Why is this the case? I’ve mentioned this in passing in The Skill of Org Design, where I said that one of the four sub-skills required to do effective iteration is a good understanding of the ‘three modes of organisational control’. When you’re shaping an org in practice, the work you’re doing usually decomposes to manipulating three levers: structure, incentives, and culture (or, as Andy Grove puts it ‘contractual obligations, economic incentives, and culture’). A good org designer knows that they must pay attention to the interplay between all three elements.
If you think about it for a bit, it should be pretty clear that all three elements influence each other. For instance:
- Structure and Culture: Companies that are organised into individual business units tend to have slightly different cultures at the unit level, compared to a purely functional organisation. On the other hand, strong company culture can sometimes make up for a lack of explicit structure (e.g. less oversight by HR or compliance is necessary if there is a strong culture of company ownership, even if no such ownership actually exists.)
- Structure and Incentives: Organisation structure tends to be tied to promotion criteria in ways that cannot be easily separated. For instance, functional organisations tend to have promotion systems that reward single-discipline expertise. Whereas splitting your company into multiple business units usually creates a layer of ‘glue’ managers, and therefore an incentive to level into more glue-type roles. All of these are obvious consequences that fall out of org structure, and you can find various arguments around the tradeoffs elsewhere. But incentive systems can also influence company structure — there’s an old joke that Google ships a gajillion messaging apps because messaging apps are what gets engineers promoted. And so God knows how many new teams are spun up thanks to subtle promo-related reasons?
- Incentives and Culture: There’s a management nut that goes “culture is who you hire, fire and promote.” I think it’s fairly obvious that incentives shape culture, since it follows that incentives influence individual behaviour. Less obvious is the idea that culture can also influence incentive design. Here’s an example: Koch Industries indoctrinates its employees with a philosophy called ‘Market Based Management’. An MBM-based culture makes it easier for Koch to wield certain incentive mechanisms — for instance, it evaluates its business units based on ROIC instead of a P&L budget, and rewards employees for business activities that a) generate valuable information relative to cost, and b) generate long-term ROIC. The incentives reinforce what the philosophy teaches: employees are told that they should think like owners, and should focus on creating value for the company; the incentive systems back the philosophy by rewarding them when they do so. (How Koch designs these mechanisms is — unfortunately — opaque to me; both Kochland and Charles Koch’s two MBM books are silent on the exact details of these systems, beyond mentioning that employee performance is rewarded with shadow equity — a derivative contract based on company performance — and one-time merit bonuses. This is, by the way, an open invitation: if you have direct experience with Koch Industry’s internal incentive systems, feel free to email me — I’m extremely curious about how it all works and I’d love to talk to you).
I bring up the interplay between structure, incentives and culture because I think highlighting this interplay serves one other purpose: it enlarges the discourse around org design. If you focus on org structure alone, every solution to an org design problem is necessarily a restructuring. This is unrealistic. And, from experience, there are whole classes of problems that may be patched by a change to an incentive system or via a tweak to org culture instead.
Sinofsky himself says something to this effect:
In practice, there are few hard and fast facts that govern the sociology of organizations. I would go as far as to say that anything can be made to work for any structure. In fact, since there is no optimal or perfect organizational structure (if there was, then this post would be unnecessary) then the most important thing is to know the weaknesses of your structure and to compensate for them (emphasis mine). The biggest mistake in organizing is a belief that a new organization would be free of problems, simply because you haven’t yet discovered or experienced them.
I agree with this. In fact, I think org design novices fixate on the trappings of structure since it the most legible component of the skill. But the reality of org design is more in line with Sinofsky’s description: you change your structure to find some initial context fit, and then you patch the problems with your chosen structure from all three tools in the org design toolbox.
It strikes me that this can be turned into an exercise: go read Sinofsky’s essay — or really any other sufficiently detailed narrative about org design (e.g. Chapter 3 in Working Backwards, or Chapter 11 in Kochland) and see if you can pick up on all the three levers that are manipulated during the iteration process. I find this particular paragraph in Sinofsky’s narrative of the Windows reorg very revealing:
… almost every org change I ever saw that didn’t work started off not with a problem statement but with a goal of putting a certain person in charge or a boss-centric perspective of grouping some things together or separating some things. This becomes clear when you read the re-org mail and finish not quite sure what just happened, which also explains why most people ignore re-org mails or simply jump to an org chart (Pro Tip: do not include an org chart in re-org mails and see if you can explain things without the chart–yes that’s a test). Therefore, the easy golden rule is to clearly identify the problems that lead to the change and start there. You then owe it to the team to immediately follow this with an understanding of what just got more difficult (in reality or perception) and how that will get resolved or managed. For example, I spent a lot of energy articulating career path and opportunity because many viewed functional orgs as lacking relative to unit orgs (emphasis mine).
I found this useful as a taste of the interplay between incentives and structure that Windows leadership had to address in order to get the org change to take.
In fact, reading Sinofsky’s piece highlights several other aspects of his org design skill that I don’t yet have. I’ve noticed, for instance:
- That the Windows reorg had to happen in one big shift (with follow-up patches) instead of a more gradual, iterative approach. This made sense given the events around which Sinofsky was doing the change: Windows had a shipping deadline to enforce, and a once-and-done reorg was probably the best move given the size and historical dysfunction of the organisation.
- Sinofsky had to spend ‘three months of 100s of meetings and learning to really understand what might need to change and why’ — which probably gives you an idea of the context discovery one has to do when doing org design in the large.
- And finally, I find it notable that Sinofsky (and the legendary Mike Maples Sr. before him) could predict the tradeoffs of various org setups even before they were implemented (or before the organisational behaviour emerged), thanks to their experiences in the deep trenches of Microsoft and IBM, respectively.
These properties are likely higher-level features of the org design skillset; Sinofsky and Maples Sr are much higher on the skill tree than I am.
Wrapping Up
In the end, I prefer the frame of ‘org design as a search for form-context fit’ because I think it is a more useful way of thinking about org design.
If you focus only on org structure, then the emphasis shifts to copying the org charts of companies that are currently successful. This can seem rather theoretical (can a junior employee execute a reorg?) and potentially irrelevant to a novice in a smaller company or a tiny team.
But if you say ‘oh, org design is simply a search of form-context fit, and you achieve that by toying with the interplay between structure, incentives, and culture’ then what happens is you end up with something vastly more approachable. This frame invites you to make small changes to your team, or to observe changes by others as they percolate throughout the broader organisation.
Org design can often seem like some mysterious skill. But it really isn’t. What it is is that it is a skill of iteration. Like many other skills, getting good at org design is simply a matter of learning by watching, by trying things out, and then by reflecting on what happens as a result of your changes. It is not some magical ability to pick perfect structures, accessible only to CEOs or VPs. It is something rather ordinary. Important, perhaps, but mundane.
Originally published , last updated .
This article is part of the Operations topic cluster, which belongs to the Business Expertise Triad. Read more from this topic here→
