On July 11, 2013, every Microsoft employee got an email from the chief executive, Steve Ballmer, under the subject line “One Microsoft.” It announced “a far-reaching realignment of the company.”
Microsoft was then organized into business groups. Ballmer wanted it to rally behind “a single strategy as one company,” not “a collection of divisional strategies,” and to see its product line “holistically, not as a set of islands.”
Then he redrew the chart. “This means we will organize the company by function.” Marketing, finance, HR, legal and the other functions would each be pulled together, and engineering would be split into four areas: OS, Apps, Cloud and Devices. All the operating-system work, for consoles, mobile devices, PCs and back-end systems, would sit in one engineering group.
Read to the end, though, and the memo draws more than one chart.
Three shapes in one memo
Dynamics would stay separate, “as it continues to need special focus,” its head running it “as is,” with three dotted lines: his product leaders to the head of applications and services, his marketing leader to the head of marketing, his sales leader to the COO group. And “each major initiative of the company (product or high-value scenario) will have a team that spans groups.”
So the memo that made Microsoft a functional company also kept a division and laid a grid of cross-group teams over both: functions, a division and a matrix in one document.
Group people by skill or by product. Either way, some work falls across the seam.
Stations and stalls
A big restaurant kitchen is organized by station: sauces, grill, pastry, and every plate passes through several of them. A food court is organized by stall, each cooking its whole menu.
A functional organization is the kitchen. Engineers sit with engineers, standards stay consistent, and building the same thing twice gets less likely. But every product has to cross every department, and the one place they all meet is near the top. A divisional organization is the food court: each product or market gets its own set of functions and one head to answer for results. A former Amazon manager called its two-pizza teams, each run on one business metric agreed with the senior executives, “the ultimate divisional organization.” The cost is duplication, and the islands Ballmer wanted gone.
An early version came out of DuPont. In 1921, by the company’s own account, its Executive Committee decentralized management, and product departments such as Explosives, Paint and Dyestuffs set up their own applied research. A Harvard Business School case calls the result “the ‘M’ or multidivisional form.”
A matrix tries for both. A person sits in a product team and also answers to a functional head. “Matrix organizations result when two or more activities must be accomplished without hindering the other,” the organization designer Jay Galbraith wrote. Stanley Davis and Paul Lawrence opened their 1978 Harvard Business Review article on its “significant pathologies” with a warning: “No organization design or method of management is perfect.” When Spotify’s coaches described their squads and chapters in 2012, they asked themselves “isn’t this just a matrix org?” and answered: “Yes. Well, sort of.”
None of these is the right answer in general. They are trade-offs, and which one fits depends on what the organization most needs to do well.
Your designer, their product
Imagine you lead six designers at a software company with four product teams. The product managers are tired of queuing for design, so you’re asked to put your designers inside their teams.
Each product may well move faster. Six months later you might find four different date pickers, and your most junior designer with nobody to show her work to.
The middle path is to embed the designers but keep them reporting to you for craft. Now each designer has two people who can set her priorities. Unless you agree ahead of time who wins when a product deadline collides with the design standard, she will be the one deciding, alone, every week.
A tester kept away from the code
AI agents raise the same question. In a paper first posted in December 2023, Dong Huang of the University of Hong Kong and colleagues described AgentCoder, which splits code generation among a programmer agent, a test designer agent and a test executor that runs the tests and sends failures back. The test designer writes its tests without seeing the whole code, so that, in the authors’ words, they are not “biased and affected by the code.”
They compared it with one agent writing the code and then the tests in a single conversation. On the HumanEval benchmark, 61.0% of that agent’s tests were correct against each problem’s reference solution, against 87.8% from the separate test designer. The authors suggested two possible reasons: doing both jobs may distract the agent, and tests written after the code can inherit its flaws. Their test designer also had its own specially designed prompts, so separation was not the only difference.
Like a QA department, the split buys independence, and it has the usual seam: the test designer knows only the requirement, so a vague requirement gets vague tests. When an agent has written your code and its tests, give a fresh session only the requirement and ask for tests. Run both sets. A disagreement is a lead to check against the requirement, not a verdict; models vary from run to run, so try it more than once.
Slipping back
Ballmer’s memo did not claim the new chart was finished. “We have resolved many details of this org, but we still will have more work to do,” he wrote, and completing it would take until the end of the year. He added: “In my own staff meetings, we are modeling these new characteristics yet also find ourselves occasionally slipping back.”
Six weeks later, on August 23, Microsoft announced that Ballmer would retire within 12 months. “We have embarked on a new strategy with a new organization,” he said. “We need a CEO who will be here longer term for this new direction.”