There is no clean way to design an organization. Every framework you can pick up is right, and they each point you somewhere different.
If you come at it from the people side, you ask about span of control: how many reports per manager, what ratios are healthy, when does someone become a bottleneck. If you come at it from product, you ask about empowered teams and where you draw the boundaries: by customer persona, by user journey, by problem space. If you come at it from engineering, you reach for Team Topologies and ask which teams are stream-aligned, which are platform, which are enabling. And under all of that, the technical architecture is pulling at the shape too, asking to be respected.
Each lens gives you a defensible answer. The answers don’t match. So what do you actually do?
The Frameworks Don’t Agree
I’ve designed organizations a few times now. Each time, I’ve wished there were a framework that just gave me the answer. There isn’t.
The HR-shaped answer wants symmetric teams of seven or eight people each, manager spans you can defend in a leadership conversation, a clean reporting tree. The product-shaped answer wants teams that are close to customer outcomes, with end-to-end ownership of a journey or a problem, however that lands on the org chart. The Team Topologies answer wants you to be honest about which teams build for users and which teams build for other teams, and to keep the boundaries between those types clean. And the architecture answer wants the team boundaries to follow the system boundaries, because the alternative is endless cross-team dependencies and slow change.
Pick any one of those frameworks and run with it, and you’ll do well on that dimension and badly on the others. The HR-clean org has product teams stretched across journeys they don’t own. The product-clean org has wild manager spans and platform teams that look like service desks, while the architecture-clean org has people doing work they didn’t sign up for because that’s where the system boundary fell.
The frameworks are right. They’re also incomplete on their own.
The Setup
The hardest version of this I’ve worked on came when I was asked to fold four separate areas into one. The output had to be a single company-wide technology platform that served every team in the company, on every kind of work they did.
Four different histories, four different sets of priorities, four different ways of thinking about who their customer was. And now, on paper, one organization, with one identity and one direction.
No framework alone made the shape obvious. Span of control didn’t. Team Topologies didn’t. The customer journey lens broke down the moment you realized “the customer” was every other team in the company, doing very different work. The technical architecture had four overlapping stacks that were going to take years to consolidate, and the org couldn’t wait for that.
I had to find a way through.
Start With What You Want
The first thing I learned is that none of the framework work matters until you can articulate, in one or two sentences, what the organization is for.
It doesn’t have to be a slogan, but it does have to be a clear statement of where you’re taking the business and what role this organization plays in getting there. It doesn’t need to be perfect on the first attempt. It needs to exist. Without it, every later trade-off becomes arbitrary, because there’s no anchor against which to weigh it.
For us, that meant getting honest about whether we were a service function for the rest of the company or a force pulling the technology stack toward something better. Those two answers produce very different organizations. One is shaped to absorb requests. The other is shaped to set direction. We had to pick.
A First Cut on Customers, People, and Technology
The vision is necessary but not sufficient. The next thing is a first view on the three things the vision has to live inside: customers, people, and technology.
A first view on customers means knowing, at a useful level of detail, who you’re serving and how they group. In an internal platform context, that means specific teams with specific work, with patterns you can name. Some are doing one thing many times. Some are doing many things rarely. Those two groups don’t want the same platform.
A first view on people means knowing the leaders you have, the strengths they bring, what they’re motivated by, where they’re stretched and where they have headroom. You can’t design an org without this and call the result anything more than a wish list.
A first view on technology means understanding what you’ve inherited and where it’s going. Which systems are converging, which ones are being deprecated, where the boundaries are firming up and where they’re still soft. The org you design has to live on top of the architecture you have, not the one in someone’s whitepaper.
Treat all three as inputs the vision has to be tested against, not as side exercises. The vision drives. Customers, people, and technology constrain. If any of the three is missing from the picture when you start drawing teams, the design that comes out of it is fiction.
None of this happens in one pass. As you dig into the customers, the people, and the technology, you’ll learn things that don’t fit the vision you started with, and when that happens you go back and change it. The vision shapes the buckets you sort customers and work into, and the buckets, once you’ve drawn them, sometimes tell you the vision was wrong. Don’t be precious about any of it. A first cut on customers that survives contact with the second week is rare. Iterating the vision against what you find, and re-cutting the groups when they stop holding, is the only way the design ends up true. It isn’t a sign you got it wrong the first time.
The Paper Exercise
With the vision and the three first cuts in hand, you can do the paper exercise.
The paper exercise is laying every proposed team out and looking at it through every lens at once. Where does it sit on Team Topologies? Is it stream-aligned, platform, enabling, or some uneasy hybrid? Which customer groups does it serve, and is that one or many? What’s the span of control? Does it match a coherent piece of the technical architecture, or is it cutting across boundaries that will fight back?
What you get when you do this honestly is a map of friction. Some teams come out clean. They’re a clear archetype, they serve a clear customer group, they sit on a coherent piece of the stack, and the manager has the right number of reports. Most teams don’t come out clean. Most teams have at least one dimension where they’re awkward, and a few teams are awkward on all of them.
The exercise is valuable even when it gives you a messy picture. Especially then. The mess is the real shape of the trade-offs you’re being asked to make. Without the exercise, those trade-offs stay implicit. Someone makes a call about team boundaries and someone else complains about span of control later, and nobody can connect the two conversations because they happen in different rooms with different vocabulary. The paper exercise puts everything on one piece of paper and forces it into the open.
Pick the Compromise
Once you can see the friction, you have to decide what you’re willing to live with. I’ve never seen this taught anywhere, and I’ve never seen a design survive without it.
Are you fine that one team serves multiple customer groups, because the alternative would split the technology in a way you can’t afford? Are you fine that a span of control is wider than you’d like, because the leader you have can hold it? Are you fine that a team isn’t a clean Team Topologies archetype, because the work itself is genuinely hybrid? Name these out loud. Say which dimension you’re prioritizing for this team, and which dimension you’re knowingly compromising on.
If you can’t say which compromise you’re choosing, you haven’t designed an organization. You’ve drawn a wishlist and convinced yourself it’s a plan. The wishlist will get rebuilt the first time it meets reality, and you’ll have lost the credibility you needed to make the next round of trade-offs.
The compromise has to be stated in a way that’s defensible six months later, when someone asks why a particular team has the shape it does. “We chose this because the technology lives here and we’re willing to take the span-of-control hit” is a defensible answer. “It just worked out that way” is not.
There’s a trap waiting at the level above the individual team. It’s tempting to optimize each team for whatever dimension it’s strongest on, one for customer proximity, one for the architecture, one for the leader you have, and call the whole thing done because every team is locally sensible. An org built that way pulls in a dozen directions. Teams that should share a platform build their own. Work that should flow across two teams gets handed off four times. The same problem gets solved three ways because nobody agreed on which way the organization solves it. You need a thread of consistency running through the teams, a few dimensions you hold the same everywhere even when a particular team would be slightly better off doing its own thing, because the shared benefit of teams working the same way is worth more than the local gain. Pick the compromises team by team, but check that they add up to something coherent across the whole.
Where Reality Hits
Then you have to staff it.
This is where the paper version meets the people you have, and the design starts to bend in ways you didn’t predict on paper.
A strong leader can hold more complexity than the framework suggests. They can run a wider span, manage more interfaces, sit in a hybrid team type and still ship. Another leader, equally good in their own way, can’t. Putting them in the same role on paper produces two different organizations in practice. The paper doesn’t know that. You do.
There’s also the retention question. Some of the people you most need are also the ones with the most options. If a leader has been running a piece of the org for years and is good at it, the design that takes that piece away from them might be the right design on paper and the wrong one in practice, because they leave. You end up accommodating part of what they want, keeping a scope they care about, giving them the path they’ve been promised, not because the paper says so but because losing them costs more than the design imperfection.
This is the part that makes org design feel uncomfortable to people who like clean answers. You’re trading a small amount of structural elegance for execution capacity. That looks like compromise, and it is. It is also how the work gets done.
It helps to separate where you want to be from what you can stand up next month. You can have the right long-term shape on paper, the one you’d defend to anyone, and still be unable to implement it now because the people to run it aren’t in the building yet. That’s a different kind of compromise from the ones above. The design is right and you can’t execute it yet. So you stand up an interim shape that the team in front of you can run, and you’re explicit that it’s interim: this team is bigger than it should be until we hire the second leader, this scope sits here for now because the person who should own it hasn’t joined. The long-term design stays on the wall as the thing you’re moving toward. Confusing the two is how people either freeze, waiting for a structure they can’t yet staff, or ship the interim version and forget it was ever meant to change.
Don’t Do It Alone
The first instinct, when you’re doing this kind of design, is to do it privately. It feels too sensitive to share. People’s roles are about to change. Some people are going to lose scope. You don’t want to start a panic by talking about a draft that might never happen.
I’ve come to think this instinct is wrong, if you’ve built the trust for it.
Involving your direct reports in the design, not in the final call but in the analysis and the trade-offs, gives you a much better answer. They see things about the customers, the people, and the technology that you don’t, and they see them sooner than you would. They also tell you, before you commit to it, which compromise is going to fall apart in execution, and that signal is worth more than the discomfort of having the conversation early.
The risk you’re managing is the gap between what the paper says and what the day looks like for someone reporting into one of these new teams. Your reports close that gap. You can’t close it on your own.
Structure Without Cadence Fails
The other thing the frameworks don’t talk about much is that the org chart is only half of the design.
The other half is how the organization runs once you’ve drawn the boxes. What cadences do teams have? What decisions do they make on their own and which ones come up to you? How do problems get raised? How does information move sideways between teams that depend on each other? If the structure is good and the operating cadence is bad, the structure won’t save you. Teams either drift, because they have too much space and no rhythm, or they stall, because they have too little space and every decision goes through the leader.
I’ve watched org redesigns that got the structure right and then ignored the cadence question, and the new org performed worse than the old one. The boxes weren’t wrong. The problem was that nobody had thought through how decisions moved through the new boxes, and the teams were waiting for permission they used to have, on shapes of problems they used to handle without escalating.
There’s a third thing sitting next to the shape and the rhythm, which is how you tell people about it. The same design lands completely differently depending on whether someone hears the reasoning behind their new team or just finds their name in a new box. How you communicate a reorg, what you say, in what order, to whom first, is its own piece of work, and a good design can be wasted by a bad rollout. That’s a post on its own, so I’ll leave it here.
Org design has two layers: the shape and the rhythm. The shape is what people draw. The rhythm is what makes the shape work. Looking at one without the other is the most common mistake I see, and it is the one I most often have to remind myself not to make.
What I Would Tell Myself the First Time
Folding those four areas into one, the part I got wrong was thinking the drawing was the work. I spent far more time on the paper exercise than on how the new organization would actually run, and the ratio should have been the other way around.
The frameworks were still right, each in its own direction. What I’d been looking for was permission to pick one and stop feeling the pull of the others, and there is no such permission. You choose a compromise, you say out loud which dimension you sacrificed and why, and then you run it in front of the people it affects until it earns the right to exist. It has never once felt clean while it was happening.