In the Babel story, the builders didn’t fail for lack of bricks. There were plenty of hands to raise a tower to the sky — but one day their speech scattered, they could no longer make themselves understood, and the work stopped. The hard part of any large undertaking is never the work itself. It’s how you bind a lot of people to a single direction.
An org chart is one answer to that problem. It looks like a picture of power — who sits above whom — but that’s not what it is. Once there are enough people, you can’t renegotiate from scratch every time who owns what, who passes information to whom, and who settles a clash. An org structure settles all of that in advance — a device for lowering coordination cost. So designing an organization is really a decision about where, and by whom, that cost gets paid.
This piece sorts those answers into types, looks at what the major companies actually chose, traces how each choice’s weak spots have been patched over the years, and follows the picture all the way to how AI is redrawing it.
The first axis: what do you group people by?
The most basic question that splits organizations is “what do you put people on the same team by?” The answer divides roughly in two.
- Functional: grouped by the kind of work. Engineering, design, marketing, data. People of the same craft sit together.
- Purpose / mission-based: grouped by the goal to be reached. A payments-experience team, a new-user team, a lending team — a single mixed-discipline team owns one goal from end to end. Amazon’s two-pizza teams and the Silos at Toss (the Korean fintech) belong here.
Put another way: a functional org is like a hospital divided into internal medicine, surgery, and radiology — specialists by department. A mission org is like pulling an internist, a surgeon, and a nurse into one team under a single goal: “keep this one patient alive.” The first goes deep on expertise; the second has crystal-clear ownership of one problem.
The diagram makes the difference plain. Because a functional org gathers each craft into a vertical column, a single piece of work has to travel across — from the planning column to the engineering column to the design column. A mission org packs every craft into one mission box, so the work begins and ends inside that one box.
The trade-offs
Run the same task through both structures and you get exactly mirror-image strengths and weaknesses.
| Functional | Mission-based | |
|---|---|---|
| Grouped by | Craft, expertise (how) | Goal, mission (what for) |
| Expertise | Deep (same craft together) | Easily scattered |
| Decision speed | Slow (cross-team handoffs) | Fast (settled within one team) |
| Accountability | Fuzzy (“that’s another team’s…”) | Clear (this team, end to end) |
| Resource efficiency | High (shared, no duplication) | Low (each craft duplicated per team) |
| Consistency | High (standards held by one team) | Easily fractured (every team its own way) |
| Best fit | Stability, efficiency, standardized work | Fast experiments, product-led growth |
The functional org’s deepest trap is the silo paradox. (Here “silo” means the bad kind of wall, not the good Silos at Toss.) Walls rise between teams, handoffs multiply — “I tossed the ball over, so my part’s done” — and the work slows as it moves from department to department. When a product fails, it’s easy to pass the blame: “the plan was weak / engineering ran late.” No one owns it through to the end.
The mission org lives the opposite life. One team holds the work to the finish, so it’s fast and accountability is sharp — but a designer sitting alone on a team has fewer colleagues to learn from, and every team reinvents the same wheel. With each team keeping its own engineers and designers, you also need more people. You buy speed and ownership by giving up expertise, consistency, and efficiency.
So this isn’t a question of which is better. It’s a trade. Boiled down to one line: do you buy efficiency and expertise, or speed and accountability?
What the companies actually chose
The abstract classification sharpens when you hold it up against real companies. Organizations shift over time and the inside often looks nothing like the outside, so read the list below as well-known public examples rather than ground truth.
| Company | Dominant shape | Notes |
|---|---|---|
| Apple | Functional (the textbook case) | Below the CEO sit heads of hardware, software, and design — not an “iPhone GM.” P&L isn’t split by product; it’s read for the company as a whole. |
| Amazon | Mission-based | Two-pizza teams + the single-threaded leader (STL). One person owns one mission to the end. Autonomy and speed, maximized. |
| Spotify | Mission-based (the squad model) | Squads (missions) crossed with chapters and guilds (the craft axis). Tellingly, Spotify itself said “we don’t actually run this way” — yet the name spread as if it were an industry standard. |
| Tesla / SpaceX | Leans functional | Rather than splitting P&L by division, they prize direct engineering reporting lines and tight product integration. |
| Microsoft | Divisional → unified | A structure where divisions once competed too fiercely was pulled back toward functional-and-mission integration under Nadella. |
| Toss | Mission-based (Silos) | A Silo binds a PO, designers, and engineers to own a mission end to end. |
One rule shows through here. The more a product is a single integrated experience, the more functional structure helps; the more it splits into independent lines, the more mission structure does. A product like the iPhone, where every part has to mesh as one body, is better off integrating crafts to polish the seams smooth — while Amazon, with countless services running on their own, is better off attaching a small team to each and letting them run independently. The shape of the product pulls the shape of the organization toward it.
Pure forms don’t last: a history of patches
In the real world, no company runs either type in its pure form. Whichever you pick, the weakness is plain — so the recent history of org thinking is really the history of bolting on devices to cover that weakness.
The matrix. The most classic compromise. The vertical axis is the mission org (squads, Silos), owning the day-to-day mission; the horizontal axis is the functional community (chapters, guilds), gathering each craft to tend expertise, standards, and careers. You get speed and ownership from the mission axis, and you revive functional expertise along the horizontal one. The price is the matrix’s signature confusion: “two bosses.” You’re forever walking the line between your mission lead and your chapter lead.
Team Topologies. Arrived in 2019 and is now a lingua franca for engineering orgs. It sorts teams into four kinds.
- Stream-aligned: the workhorse team owning one value stream (a product or feature). The evolved form of the mission org.
- Platform: provides the internal tools and infrastructure that let the above teams move fast — delivered as a product.
- Enabling: coaches other teams on a given expertise for a limited stretch.
- Complicated-subsystem: takes on only a hard, specialized domain — a payments engine, machine learning.
There are two core insights. One is cognitive load: there’s a limit to the complexity a single team can carry, so you draw boundaries that keep it from crossing that line. The other is Conway’s Law: organization structure hardens into system structure, so you design the teams first to match the architecture you want.
Platform engineering. The platform team above broke off and became its own trend. Shared foundations — deployment, observability, data — are productized as an internal platform, so product teams spend no time on infrastructure and keep their focus on the mission. It’s a head-on answer to the mission org’s “every team reinvents the wheel” weakness.
Tie the arc into one line: the big wave of the past decade or so ran from functional toward mission (autonomous squads), and now it’s refining into a second-generation mission org that patches the duplication and standards-drift of the first with Team Topologies and platform teams. The default today isn’t a pure form — it’s the combination of stream-aligned teams (mission) sitting alongside platform teams (functional efficiency).
AI changes the shape of the org
Everything so far is the story of organizations made only of people. But as AI agents enter, that picture starts to shake again. Here’s the heart of it first: before AI lightens the workload, it melts the glue that held person to person.
We said earlier that organizations exist to lower coordination cost. A large share of that coordinating labor — lining up schedules, gathering progress, tidying reports, monitoring performance, ferrying information up and down — was exactly the middle manager’s job. When agents take that over, the reason for that layer to exist starts to fade. One paper (Farach, AI as Coordination-Compressing Capital, 2026) called AI exactly that — “capital that compresses coordination.” Before AI replaces labor, it drops the price of the glue that binds an organization together.
This change shows up in the shape of the org.
From pyramid to diamond
The traditional organization is a pyramid. New hires and juniors crowd the base, gathering data and doing the first-pass processing; it narrows as you rise. But as agents absorb the simple, repetitive work at the bottom, the shape changes.
Agents take over the work juniors used to do, so hiring shrinks and the base narrows. The middle layer that looked doomed isn’t erased — instead it’s redeployed into training, supervising, and operating the agents, and it actually thickens. A wide-based pyramid turns into a diamond: narrow top and bottom, thick waist. Gartner expects that by 2026, 20% of organizations will flatten their structure with AI and cut more than half of today’s middle-management roles. GitLab declared an “agent-era” restructuring that strips up to three management layers from some orgs and splits R&D into roughly 60 small autonomous teams — nearly doubling their number — while Meta applied an extreme, flat ratio of 50 engineers per manager in its newly formed applied-AI organization.
There’s a trap here. As junior and middle roles thin out, so does the channel future leaders grow through. No one comes up through the trenches anymore. For the sake of today’s efficiency, you empty the leadership pipeline ten years out. That’s the homework companies that chose the diamond will have to solve in the next decade.
From org chart to work chart
The deeper change is that the unit of the organization shifts. Microsoft predicts that the org chart — a picture of people’s reporting lines — will give way to a work chart that binds people and agents together around the work itself. Not who sits below whom, but which person and which agent do this work together — that becomes the basic cell of the organization.
A new role emerges from that. The agent manager: someone who automates their own work and then becomes the owner and operator of that automated flow. What they hold is institutional knowledge the company can’t easily replace. Harvard Business Review goes a step further — “treat AI agents like teammates.” Onboard them, define their roles and permissions, manage their performance. A worldview in which an agent occupies a cell on the org chart.
The faster it goes, the thinner the net
But flattening has a flip side. The vanishing of the middle review layer also means the net that caught errors gets thinner. When there are many approval steps, things move slowly — but a bad decision often got filtered out along the way. Strip those steps and speed picks up, while one person’s, or one agent’s, bad call goes straight out the door. In a domain like finance, where a single mistake can be fatal, the speed you gain makes it more important, not less, to decide where to plant the human’s final verification and audit back in.
And this comes back, in the end, to the problem of delegation. The more you hand an agent, the more your throughput rises — but the understanding that holds the work up doesn’t transfer with it. When an organization thins into a diamond, what empties out isn’t only the labor but the seat where someone understood the work and answered for it. That’s exactly why the agent-manager role matters. Only if the person running the automation understands the flow can they be the last knot in a net gone thin.
Wrapping up
An org structure is, in the end, a question of how you resolve one trade. Buy efficiency and expertise (functional), or speed and accountability (mission)? Because neither pure form lasts, matrix, platform teams, and Team Topologies have patched each other’s weak spots — and now AI has drawn a fresh axis over the top. As coordination cost collapses, the pyramid becomes a diamond, and the unit of the organization shifts from reporting lines to bundles of work shared by people and agents.
The lesson of Babel was that it fell not for lack of hands but because the speech scattered. The history of org structure is one long answer to how you put that speech back together — and AI has now stepped up to take over much of the carrying. One question is left. After you hand the carrying to machines, who stands in the seat that decides what to build and answers for it to the end?
— tomte