Functional versus Unit Organizations
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.
A recent post by Matthew Yglesias, Apple may have finally gotten too big for its unusual corporate structure, clearly describes two main types of org structures and also explains how a new structure will address some perceived problems at Apple. Stratechery’s Ben Thompson also wrote about this topic earlier in the year, Apple’s Organizational Crossroads. I wish things were as straight forward as these posts imply. If you’re not sure what it means to organize by function or unit (sometimes called a division) then please read those two posts for background.
Reading these posts and a diagnosis of Apple brought back memories of a Microsoft executive retreat many years ago where some high-brow consultants were arguing for Microsoft to be business unit, rather than function, organized. Oddly at the time we were clearly organized by “product” and hardly by “function” so I was always confused by the advice (as were many people). But the memories of this time and my own history of working through basically every size and shape of organization over the years provided some motivation for this look at what works and does not work in the seemingly binary choice between functional and unit organizations.
This post is in four sections: some personal history, the two Golden Rules of orgs, a collection of pros/cons for each of the two ends of the pendulum known as functional versus unit organization shape, and then the universal truths of org design.
OMG this post is long! Sure it is long, but this is a really tough topic. In human-centric companies, how CEOs and leaders organize is as important as how Henry Ford innovated in factories. In doing something big at scale, the organization influences, and even determines, much of what gets built. As a CEO or big company executive, organization is one of the very few things that is entirely your doing and responsibility. So a lot of words follow.
“Going Functional”
Like any org structure in practice, one almost never sees a pure expression of the ends of the spectrum referred to as functional and divisional. The conglomerate model of running things as seen by Berkshire Hathaway or in industrial companies like GE is close to a pure expression of unit structure and strategy, but pretty rare. Likewise, almost nothing is a pure functional organization except for single-product companies. It could be that Apple is reasonably close to a pure expression of a functional org, though as with an example like GE one should have visibility to more levels of detail and operations to know for sure.
It turns out that the details and shades of grey of this spectrum matter and matter a lot. Generally, the more you dive in the more you realize that most all companies are in the broad middle of org structures. They try to have a best of all worlds approach, because they know that the pure models are fraught with unappealing trade-offs.
For example, almost no companies that claim to be organized by units or divisions allow global sales teams to managed from within business units, which would be a key part of actually controlling your destiny. Likewise, most all companies centralize finance and talent, both of which are often the hallmarks of “running a business” — this is even the case when they report sales/earnings by business. Similarly, most functional orgs rarely have a total lack of general management (i.e. a single manager overseeing a variety of job functions). In fact, most functional orgs have plenty of small, autonomous teams working away on products or go-to-market initiatives.
Purity in org structure makes for great caricatures of orgs, but operationally rarely exist. That is why I used the now infamous diagram at the start of the article — a great caricature but far from the truth I worked in (though I totally understand why people love the image). This reality just offers another reason why it is so common to think of org structures as a pendulum. Once you characterize an org one way, then it is easy, when facing challenges, to want to swing the other way.
The Office team at Microsoft had long been known as the place where much thought went into management structure (owing this to the legendary Mike Maples Sr. who had experienced everything imaginable in organizations at his IBM career prior to joining Microsoft). His thoughtfulness and wisdom influenced the evolution of the organization years beyond his immediate tenure.
In the early days of “apps” (in the 80's it was really called it that), the team was a pure expression of a functional organization just as you would expect a startup of a couple hundred people. There were single leaders for engineering, testing, documentation, marketing, localization, and so on. There were dedicated engineers for apps (like word processing and spreadsheets) but everything else was for the most part single threaded on the next app to finish.
Through Mike’s incredible leadership, the organization then morphed into Business Units (with a long series of catchy names like ABU, EBU, OBU, GBU, DABU — BU for business unit being the operative word, along with Analysis, Entry, Office [sic], Graphics, Data Access, etc. for Excel, Works, Word, PowerPoint, Access, etc.). These teams were “units” in that they owned all the R&D and marketing necessary to run the business. Well almost, some things were difficult to spread out such as the global sales organization.
It is worth noting that upon introducing this, Mike remained hardcore about minimizing the notion of P&Ls across these groups. His (impossible to argue) logic was simply that one could not reasonably account for the costs side of a P&L because (a) most costs were not under the control of a business unit and (b) business units relied on each other for much of their business success. This latter point could be illustrated by a favorite saying of the leader of the Word team who used to say “our best feature for competing with WordPerfect is Excel”.
Mike’s experience at IBM clearly influenced this point of view as he spent many years watching people fight to move expenses to other teams, claim revenue for their own team, or even fight against the price of shared corporate services. This “allocation” dynamic is extreme “finance gymnastics” that grows exponentially complex as the business cross-dependencies grow. Ultimately the meaning of P&Ls derived from allocations becomes the undoing of most rational thought in an organization — hiring, investing, marketing and more all become influenced by mythical numbers that few really understand. The real downside of this is that it removes accounting as a tool to make strategic decisions, which is why accounting was invented in the first place!
The business unit structure worked very (extremely) well until the main business transitioned from single apps competing with separate companies to a category-defining suite with about $1B ARR. Once the suite took hold then the idea of centralizing marketing became very important because it would solve problems such as ads for Word being totally different than ads for Excel or for confusing the sales force about what was important.
Given this challenge the transition was made to “Product Units” which reflected a unit organization for “making” products but a functional organization one level up, split by “makers” and “marketers”. It is worth noting, that there was still no clear ownership of sales, finance, talent, or many other significant parts of a business.
This refinement served us well for a short time until it became clear that the engineering team also needed to solve some of these same synergy issues, but in the product itself. In particular, the marketing message of “Office” needed to be supported by the product. It is never a good thing to be marketing and selling a value proposition that the team is not actually building. This led to taking a more functional approach to the engineering team as well, piling more and more resources into senior leaders for engineering, test, and product management to build massive amount of shared code and infrastructure. Yet, the organization was also somewhat of a hybrid because it was felt that having “product” champions was still important, so there were “unit” leaders for the apps as well. It did not fit neatly in a picture but it worked reasonably well. At some level this is still what Office 365 looks like today still.
After a dozen years and 6 product cycles of Office I moved to Windows. The cultural differences that I had long observed (or participated in) moved to center stage for me. The thousands of people in the Windows organization at the time reflected the style of organization that had dominated “Systems” (what the other half of Microsoft was called) for years which was to have many “units”. These units were far more granular than say Word within Office. This “unit” organization was favored by Windows for many of the reasons outlined below.
Windows had units for each of the subsystems you might name if you were to describe the product — file system, kernel, shell, core networking, graphics, and the even more granular such as CODECs, FAX/Scan, DRM, and so on. Actually, I did an exhaustive project to catalog the number of product units and there were 142 of them across everything Windows and related online services. Each of these units consisted of a general manager (or product unit manager), some number of engineers (called software engineers), testers, and product managers (called program managers). To put a number on it, most of these teams had fewer than 15 engineers and were on average about 30 people.
Of course, none of these units, as we saw in Office, had sales, marketing, finance, talent, etc. But they did operate with all the attributes of a business in terms of deciding what to work on and how to allocate resources within the product unit. There wasn’t any central coordination of these efforts, which made for quite an interesting project management effort.
As was well-documented back around 2006, things had not been going well in developing the next release of Windows and so naturally one might ask if the organization caused the problem, if there was just a leadership/management problem, or the problem was in some process that could be addressed. That is always the issue with an org-centric view of execution problems. Is it the physical structure of the org, the logical representation, the strategy, or the people — and where precisely is there a mismatch? Business and consulting books tend to quickly draw causal arrows and drive to solutions, and often if you’ve already swapped out some people then the next thing to do is a re-org — see these dozen or so Dilbert cartoons.
My view is that so many of the seams experienced in Windows — different API strategies, varying support for languages and runtimes, inconsistencies in enterprise management, multiple models addressing the same problem, and so on — were fairly directly attributable to this org structure. The difficulty in coordinating architecture, experiences, schedules, teams, and more came out of this org structure that, arguably, was optimized for specific innovations.
So, we did a re-org of the Windows team — I knew we would need to make changes but it took about 3 months of 100’s of meetings and learning to really understand what might need to change and why.
The change became known as “going functional”, and not said in praise. It was big and traumatic as it was basically unwinding about 20 years of “unit” organization and displacing a lot of general managers. I think in this post I will spare the gory details of change management. The legwork that led to this change, however, was focused on several challenges that were clearly articulated broadly across the team and at every level:
- Missing clarity of product goals and ownership of those goals
- Reduced quality of engineering work
- Little collaboration across teams
- Inflexible allocation of resources
- Lack of agility in product development
- Inefficiency of core processes
Yep, you can read these and apply them to just about everything that ever went wrong, but this is a summation of what so many on the Windows team were feeling. One must start with a recognition that Windows is effectively a single product, with a single release date, finite set of customers (PC makers), and very broad end-user base, and so on. Given that, the unit organization probably never made much sense. Below we will show why unit orgs can be so seductive in a fast growing and complex product line. At the same time, the challenges outlined are almost a perfect reflection of the product that was shipped around that time.
For most of the people involved “going functional” represented a pretty big change — not just a change in the current org shape or reporting structure but also in their own career journey and expectations. As it happens, most of Microsoft had long been organized by product/business unit and thus the most immediate career goal of most managers was to make the leap from a manager in a job function to being a multi-disciplinary manager (MDM), or product unit manager (PUM).
In times of major changes like this, most people necessarily become quite concerned with their own path and worry less about the company overall. That’s natural, but adds to the challenge.
While I learned many lessons during this transformation one has stuck with me because it speaks volumes about how org shape can influence the overall growth of talent on a team. In thinking about this, if you have a large organization where the best performers are pulled from the ranks of line/discipline management to managing several types of jobs then there’s a definite, yet gradual, erosion in the quality of skills in core disciplines. More than any aspect of the change, the most distinct memories of going through such a transformation were “discovering” that we had 100+ general managers but we lacked leadership across core job functions such as product management, software engineering, and testing. Those that would have been the future leaders of 30, 40, or 60 engineers were drawn to manage much smaller teams of 20–30 people made up of 10–15 engineers (plus test and product).
One might be tempted, as many pointed out, that functional organizations thus fail to grow general managers or business leaders. While there is an obvious truth to that, the reality is that if you believe that you have general managers when you truly have a business then you need far fewer of them, so the ability to identify them amounts to picking 1 out of 500–1000 (for example). That’s very different than needing 40–50 leaders capable of leading teams of 40–50 engineers, testers, or product managers (which numerically was what we ended up needing in Windows).
If you’re really interested in an even deeper level of detail, much of the communication with the team is detailed in the selection of internal blog posts I wrote during this time which are in the book, One Strategy, co-authored with Marco Iansiti of Harvard Business School.
Golden Rules
Business is a social science which leads to lots of crazy advice that arises from doing whatever seems to be working at a given moment for a visible and successful company. For example, in the early days of Google they shunned managers and insisted that a manager could handle 40–50 direct reports (here’s a post I wrote on how crazy I thought that was, What do managers do and how big should my team be?). That didn’t last but a lot of companies thought that was worth considering.
Conversely, if something isn’t going well then it won’t be long before the collective wisdom concludes that you need to go with the other end-point of the pendulum. That is pretty much what happened at that executive offsite when the consultants told us to have more business units. Of course it is also what I did, or what people said I did, when we re-organized Windows.
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. 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 (Rumsfeld’s taxonomy of unknowns comes into play).
That said, these are the two Golden Rules of organization that I’ve come to respect.
Golden Rule of Orgs — Don’t ship the org chart. Much has been written about this going far back so I don’t claim to have invented this (see Stevey’s Google Platforms Rant, or this HN thread). HN captures my view, which is the rule is aspirational in that you always ship the org chart. Therefore, when you create an org chart you are creating your product — the seams in the org get reflected in the product; the depth of feature work gets reflected in resource allocation; the coordination across job functions gets reflected by the leaders you choose, and so on. When Office wanted to build a suite, we organized the team to build a suite. When Windows needed to ship one Windows product on time we removed product units and went functional, and when we wanted to elevate product design and quality we also elevated leaders of testing, product management, and design. When we wanted to build a computer for the first time we created a singularly focused organization with a leader to do just that, and so on.
Golden Rule of Re-Orgs — Know the problem you are solving. If there is one thing that consistently amazes me it is that org changes are made without clearly and deliberately identifying what problems will get solved by the new structure, new leaders, and new resource allocation. In fact, most 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.
Functional versus Unit, Pros and Cons
No organization is purely functional or entirely unit-based, nevertheless in any given company of size (more than one product or more than about 100 engineers) there is almost certainly a dominant shape.
There is no general answer to the question of “functional or unit” absent the context of a specific set of people, at a specific company, working on a specific product plan. There are some well-understood pros and cons to each of these org structures. In fact, it is likely that a given manager “loves” an org shape or knows why a shape will “fail”. Managers are always products of their own experience!
In this list, which will be updated over time (updates will be indicated), I wanted to offer the love/fail aspects of functional and unit org structures.
Why love a functional org?
One product, one org. This is the most obvious basic truth to a functional organization and why most startups remain this for quite some time. But even at the scale of Windows (6,000 full time people) if you’re building one product then you just don’t really need “units”. As we saw in the transition of Office over time, once customers were buying a suite it made sense to build a suite.
Better develops skills for each functional area. Functional orgs optimize for creating depth of skills at functions rather than breadth of generalist skills. This is simply because a majority of senior people in the organization are engineers, testers, or product managers and not general manager. In a functional org, the most senior technologists become the leaders creates a management team of increasing depth and experience in technology — and new hires can aspire to leaders in what they were hired to do and fewer people work for someone who has no idea what they do for a living. My view is that for technology companies this is a hugely important point since the future of a technology company is never the current product, but the ability to lead technology change over many years and that only happens with depth of technology skills.
Creates critical mass for every discipline. Even on very large product organizations, there are some required skills that don’t have a lot of people. In a functional organization, disciplines without a lot of headcount still get brought together and create a center of gravity. This holds for both job disciplines or for specific technology skills within a discipline. Back in 2000 when Office needed to build out online services (that’s what the web was called back then), the first thing we did was recognize we would need operations skills and created a functional leader for those efforts rather than expecting each unit to try to hire and train their own experts.
Easier to be less hierarchical. It is much easier for managers to manage people doing work they “understand” and have done themselves (perhaps not literally) than to manage people doing something they have no personal experience with. It follows that you can have fewer managers and therefore less hierarchy, in a functional organization. One statistic: when I came to Windows and the 142 product units, the team overall was over 35% managers (!). But the time we were done “going functional” we had about 20% managers.
One meeting brings together all perspectives. In any project of scale, the biggest challenge will be to make sure all voices are heard — and in making product those voices mean engineering, product, design, quality, localization, operations, and more. In a functional org, you don’t need to have every general manager either “represent” those voices or worse bring 3 or 4 people to every meeting. Instead, at one table all the job functions for a business can be represented.
Embraces synergy across product(s). A larger organization working on multiple things seeks, by definition, synergy across those things. Even if customers must purchase multiple products there is almost always a requirement to have those products work well together and ship at the same time. In addition, sales and marketing almost always want to tell the story of 1+1>2. A functional organization is geared towards synergy across efforts because it removes the management layer that might interpret strategy or synergy uniquely.
Easier to resource load balance. Things get planned and then change. The way to respond to change is to shift the work around or to move resources to where they are needed most. A functional org is perfect for this because all the discipline resources are under one “roof” and it is much smoother and easier for a discipline leader to see the potential for change and ramifications of making a change. In a project with high variability, a functional org is almost always better.
Where could functional orgs fail?
Difficult to scale to multiple products. The first criticism of a functional org is that it is difficult to create multiple products from within the team. It is important to separate multiple products from multiple go-to-markets (GTM). A suite is made of multiple products but is really a single GTM, so a functional org structure can generally work well. Products with different GTMs, wildly different customers or sales channels, or just different ship dates are extremely difficult to manage as a functional org. More than anything, very different targets among one of more of date, segment, channel, etc. is a red flag for a functional org.
Requires a discipline leader that can scale to lots of people. One of the less obvious challenges of a functional org is that it magnifies your need for strong leaders across disciplines. Where you could once have two people each capable of managing small teams, you now want one leader capable of managing a bigger team — and everyone knows management doesn’t always scale linearly. If you lack senior leaders, before bailing on a functional org you want to make sure you are adequately prepared for the challenges you are taking on by hiding your shortage of talent under unit leaders.
Potentially diffuses accountability. I’m not a big fan of this becoming a challenge but because of the notion that unit orgs are so strong at accountability, it is almost necessary to mention that discipline orgs can have the feeling of less accountability. Ultimately accountability is much more about the entire team than any one leader, but suffice it to say it is easy for engineering to point to product to point to quality to point to marketing when those feel “far away” or there is not an obvious single leader. Many working with Office or Windows orgs over the years were frustrated by the presence of multiple engineering contributors, whereas those leaders were equally frustrated by unit managers that never seemed to know what was going on.
Requires collaboration from the outset. A functional org is by definition about collaboration — across and within disciplines. People often feel that if you don’t share a manager then wires will get crossed and signals mixed, making collaboration impossible. As always, if the organization feels that to get something done right/well requires a manager to force people to do so, then the problems are much larger than can be solved by the org structure. It is the case, however, that unit orgs can force cross-discipline collaboration sooner at a very significant expense of cross-unit collaboration.
Challenging to manage physically separate people. If you have a team that is geographically dispersed to a significant degree, a functional org can be challenging because it pushes each of your functional leaders to become skilled in managing people from a distance. Often as remote sites grow companies face the challenge of “rolling up” those people to leaders at HQ or creating a remote “unit” org. If you have a small number of remote people or they are concentrated in one discipline then a functional org is manageable.
People tend to feel less opportunity because there is “one” leader of a functional area. As people grow and want to expand their scope of responsibility, there can be a feeling of limited opportunity “managing within a discipline” compared to “managing across disciplines”. With a single discipline leader, it can feel like a tenure-track problem to more recent hires on the team. The focus for me regarding this challenge was to optimize the disciplines around depth of skills and breadth of experience within the discipline as measures of career progress.
Why love unit orgs?
Easier to scale to many products. If the company is building many products or just products with different timelines, GTMs, architectures, and so on then a unit structure often makes sense. One area worth considering is how multi-platform product development is handled. Quite often these are viewed as “products” because any one customer rarely uses both and because of the different product development skill sets (and often, the intentional/necessary lack of code sharing). It is worth being cautious of using platform or engineering skill sets as unit org boundaries because of the downstream need for strategic synergy from a customer/market perspective.
Requires one decision, not n to staff. The unit org is a favorite of executives who face many “problems” needing to be solved because it is a single decision — one person gets hired to solve a problem. This is the famous (or infamous) BOL argument (butt on line, very often made in the Systems world in my time at Microsoft). The simplicity of a single hire is rather attractive especially if the hiring manager lacks experience in disciplines beyond their own career path.
Caters to notion of “tiger team” created to focus on specific market challenge. Closely related to BOL is the idea of assembling a small, focused, and even isolated team to attack a problem. By doing so you free a team to go after the market need, solve the problem, or build a product unencumbered by being part of a larger organization with other work. This “tiger team” approach can be attractive, so long as there is an idea for how the potential strategic and GTM issues can be resolved once the team is successful. The unit org is almost always employed in a response to a disruptive technology threat, and yet consistently the inability to scale this new org before getting clobbered by the existing org is also routine.
Clearly defines the work, obvious to rest of company. Unit orgs make the mission clear from the outset (especially with one leader) and are a good tool to communicate that to the rest of the company.
Decision making authority is obvious. A unit org, when set up as intended, is super clear about who is in charge and how to make decisions about the mission. As a reminder, if there is a need for “deciding” then there are likely additional issues to wrestle with in the org, team, and people.
Initially teams are smaller and everyone loves small teams. Unit orgs, especially when created within existing companies, always start off small and focused. It is exciting and many people want to join (very early in my career I tried super hard to join one of the few small unit orgs that was being created for this very reason, but alas I didn’t get the job). It is also the case that people chosen to lead unit org often are exactly the people that create a draw to a new team. In practice, teams rarely remain small over time.
Where could unit orgs fail?
Unit as problem versus business. By far the biggest failure risk of a unit org is that the unit is created to solve a problem rather than create a business. While problems deserve attention, the unit structure implies much more than a technology or GTM problem but a focus on all 4 P’s of bringing something to market. Invariably, a unit that is a problem will struggle to “define itself” and rarely finds a purpose or calling. Yet time and again, most units are formed to solve a problem so caution is advised.
Overlapping strategy/execution always follows. The biggest myth of unit orgs is that they leave the impression that the newly formed unit is going to be the only place a given technology or product area will receive focus within a larger organization. That is, with certainty, never ever the case. As strong as that statement is, it is even more the case if the area is new and hot. I can’t count the number of times at Microsoft new units were created to go after something hot and how difficult it was to keep others from innovating in that area (either by adding to their existing product or GTM or by just doing something new). From email clients, photos, collaboration, mobile, and more this strategic confusion and redundancy always followed the creation of a unit. In fact, the larger the company the more likely the creation of a unit is a signal that everyone should be working on this new area. By definition, units are self-contained so also taxing them to be the collaborator or supplier to other units goes against the mission given to a general manager.
Collaboration doesn’t happen. Unit orgs, no matter how big (eventually everything is a unit) make collaboration very difficult — but that is by design. The general manager of a unit is focused on that unit and solving the business problem they were asked to solve. They are likely working on a very big problem, on a short timeline, without ample resources. Also, additional resources almost always have a priority to solve more of the existing problem rather than collaborative, cross-org problems. Using other code, fitting within positioning frameworks, relying on same branding, and more are all much more difficult with unit orgs.
Resource allocation is difficult. If the executive managing multiple units sees a need to re-allocate resources across units, doing so also requires re-visiting accountability, schedules, and commitments. This is because a unit is…a unit. General managers put up a fight if resources are removed from the unit.
Constantly revisit (or “innovate”) where it doesn’t matter. One of the more interesting potential downsides of a unit within an existing company/culture is that over time units tend to revise or revisit most every company process and approach. I’ve seen units that say to be successful they need to recruit differently, need different beverages, need different performance appraisal, hire a different PR firm, different furniture, and more. The most famous unit innovation I recall was a team acquiring their own domain name and mail setup along with separate card key access. Engineers will almost always use unit creation to revisit tooling and approaches. Where general managers can innovate and where they should spend those cycles are important boundaries to establish with a unit. Sometimes this is exactly why a unit is created but most often this is just burning calories.
Units require more resources. In general units require more resources, not just beyond the general manager layer that gets created. Every unit requires leaders across disciplines and often the first leaders put in line managers (which you need at least 3 to make a team). Resources that are generally scarce often get hired and are under-utilized in units, such as design. One interesting statistic from moving Windows from unit to functional was that the number of administrative assistants was cut in half, even though the overall headcount remained the same initially.
Rarely able to staff disciplines/leaders across many units. Units create an illusion that the number of senior people grows because of the number of general managers and also the number of discipline leaders in each unit. Because of the scale of units, the reality is that unit orgs stunt the growth of leadership at the discipline level. On the one hand, the incentives for the company are for everyone to become a generalist and on the other hand, assuming the same number of resources, fewer are able to manage at larger scale.
Difficult to find general managers. The source of general managers is something to consider. At Microsoft, most GMs came out of program (ne product) management. This made logical sense, but also had challenges in two dimensions. First, these orgs tended to grow new product managers poorly because the GM was often the de facto product leader, and this created a shortage of product leaders down the road (as we discovered in Windows). Second, hiring and managing for a job you never did is super difficult and requires a good deal of mentoring, observation of best practices, and more, but if you create many GMs this problem is amplified across the company.
Practical accountability does not increase. While unit orgs have the general view that they increase accountability, in most companies a true unit org remains elusive. Units rarely have accountability or influence over sales or geographies, and certainly in most companies decisions about pricing or support are not unit-level accountabilities. For this reason, most units and related accountability is rather less than the theory. The recent creation of the Enterprise group at Google is a unique and rare exception to the creation of units within large companies. People who think of Microsoft as having many focused business units and P&Ls would do well to see how sales, marketing, and geographies are managed (and the associated accountabilities).
Scaling units is challenging. Units do not scale particularly well, either in terms of the unit itself (because of the challenges of hiring or growing leaders) or because at some point if you have 1000+ people then you end up with a lot of units and need to have units of units as a management structure.
Universal Truths
Like everything in business, org design is a social science and highly dependent on context — the problems faced, history, people, and more. Since there is never a single right answer it is always worth thinking through as much as possible the implications and second-order effects of a chosen path.
The apparent ends of a spectrum of org design between functional and unit alignment, lead many believe this is a pendulum that swings back and forth over time. A company oscillates between orgs, changing as things in the current state seem unworkable or just because there’s a new leader. Perhaps there is a zeitgeist that prefers one org type over another, simply because of a visible success or failure.
The reality is that there is subtlety and nuance to this problem. CEOs and executives can rarely have direct and immediate impact on large scale challenges, org design is one of the more important tools, since a single choice can have a profound impact.
Regardless of the type of org in play, there exist several critical factors that are near universally true. When designing an org, it is very difficult to work around these realities:
Synthetic P&Ls are, always, evil. Going back to the history of accounting, a P&L is a tool used by executives to inform decisions around resource and capital allocation, pricing, etc. In a large organization, it is very difficult to assign revenue and costs to a specific unit within a company and even more difficult to offer true span of control or accountability to a unit leader. The creation of P&Ls that attempt to represent a portion of a business inevitably lead to an excess of internal focus, accountability shifting, and infighting. It is never a good idea to work with two sets of books, so unless a P&L truly represents control and accountability to a leader then it is far more likely to impede innovation, collaboration, and sharing than it is to facilitate well-informed decision making. I would love to document positives with regard to synthetic P&Ls but I’ve yet to see that work in practice — at worst it accelerates internal focus and at best it leaves one with a false sense of success.
Sales and geography. In a global, enterprise company with several products lines or businesses it is almost impossible to effectively partition, manage, or provide accountability for sales and geography to specific business units. Customers demand a single “face” for a vendor, no matter how large or diverse, and so by definition org design must account for the reality that an extremely important aspect of a business is almost certainly centrally organized, goaled, and managed. The implication of this is that sales quotas and motions, GTM, and even more upstream marketing and branding for many business units will go through a globalization filter and not likely represent the ideal as envisioned by a unit leader. The benefit of this is that a unit immediately achieves global scale with little incremental effort.
Resources not generally fungible. A primary role of an executive is resource allocation. The unfortunate reality of allocating resources is that it is way harder than simply using a pivot table. People, for a variety of reasons, are not entirely fungible. Products have technical constraints (legacy code, tool sets, architectures) that require certain people. Some people don’t want to work on some products or for some people. Some projects require more resources than seem to make sense. There are many reasons. Therefore, org design will always need to factor in reality and ultimately will have some level of compromise from ideals.
Innovation in process v. outcomes. In building an org and creating accountabilities, one must always be aware of the tendency to be innovating in the process of work versus the desired outcome. The larger a company the more org design begins to reflect how versus what, and likewise the newer or smaller an organization the less likely it is that process will be considered. A major part of designing an org is knowing that new orgs tend to start off innovating in process, just by nature of being new, and so setting both boundaries and expectations on this dimension will be critical.
Mixed messages get mixed results. Executives strive for the middle ground — say and structure one way for an outcome and then also overlay some extra outcome that runs counter to what was just said and structured. A classic mixed message would be to create a unit organization and then expect the unit (spontaneously) to strategically align, share some code, integrate with another team, and so on. Ultimately starting off with a mixed message will yield mixed results, but unpredictably so, because how the compromises are made will not be decided up front. You get what you optimize for, and everything else is a bonus.
Functional and unit orgs both work. Because there is no right answer to the perfect org, it is likely that any company of size will employ both functional and unit organizations. Overlaying product lines, GTM, or geography on a single executive will likely result in a mixture or even a hybrid of org design. The desire for uniformity or clarity can be the enemy of the practical.
Golden Rule: Ship schedule is everything. I intentionally saved this for last because it is the only point in here that I don’t believe is a pendulum, a grey spectrum, or contextual. The most important thing to consider in org design is that when it comes to execution, collaboration, and alignment ship schedule is everything. Execution means that having a date and hitting it is the most important thing for a well-functioning team (editorial note: a ship date is a date, like January 15, not a quarter or month, which are 90 or 30 ship dates). Collaboration between products or units can only happen when schedules are aligned, otherwise planning is an exercise in the futility of each team waiting for the other team(s) to be ready to produce or consume the other’s plans. Finally, alignment from a customer perspective of messaging, sales, and overall GTM can only happen when products make it to customers (in pre-release and final form) at the same time. As difficult (or perhaps “impossible”) as schedule alignment appears to be, it is the tool, way more than org structure, that defines the ability of a company to scale to many products that are aligned and related in a positively reinforcing way.
# # # # #
PS: I welcome reports of typos or mistakes via DM.
