What are org design questions, and how do you answer them?

In this article

1. Before you start
2. Why interviewers ask this
3. Org design from first principles
4. Worked example
5. Trade-offs and edge cases
6. How to answer it in an interview
7. Common mistakes
8. Follow-up questions
9. Sources

Before you start

This page is one step of the leadership interview questions learning path.

Why interviewers ask this

A weak org design answer sounds like a reshuffle: names moved between boxes with no reason. Interviewers use these questions to see whether you can explain why a structure fits the work, what it costs and how you carried people through the change.

Candidates report variants of these questions in engineering manager (EM) loops at large tech companies, and the same ideas appear in the loops covered in director of engineering interview questions. The wording changes: "how do you decide how to organize a team around work to maximize impact?", "tell me about a time you reorged an organization", "explain the structure of your current org".

A strong answer shows a method (work first, then boundaries, then load), one real trade-off and something you changed after learning more. A Staff-level answer ties the structure to the software it produces.

Org design from first principles

Org design

Org design is the practice of deciding team boundaries, who owns which work and how teams interact, so that work reaches customers with few hand-offs and each team's load stays manageable. It is about the shape of the groups, not about who sits in them.

Conway's law

Conway's law is the observation, published by Melvin Conway in 1968, that organizations which design systems produce designs that copy their own communication structures. The way people are split into groups therefore shows up in the way the system is split into parts.

Span of control

Span of control is the number of direct reports a single manager has. It counts only people who report to that manager in the organization chart, not dotted-line or project relationships, so a director with four managers has a span of four.

Stream-aligned team

A stream-aligned team is a team aligned to a flow of work, usually a segment of the business domain, that owns that work from idea to running in production. In the words of the Team Topologies 2025 post, it is aligned to a value stream that delivers direct customer value, with the autonomy to execute without constant handoffs.

In plain words

Think of a restaurant kitchen. One cook does starters. Another does mains. A third does desserts. A table that orders a full meal waits on three cooks. Now let each cook serve whole tables. The waiting goes away. But the cooks repeat each other's prep work. The analogy breaks in one place. Software lasts for years. A boundary you draw today still shapes the code long after the people have moved.

In one precise sentence, org design chooses team boundaries so that the work customers see can move with few hand-offs, and then checks that no team or manager is overloaded.

Step 1: Know why boundaries matter (Conway's law)

Team boundaries become software boundaries. Conway's 1968 paper says that organizations which design systems "are constrained to produce designs which are copies of the communication structures of these organizations" (Conway, 1968).

The mechanism is delegation. Once work is split among groups, each group's scope narrows, which narrows the design options it can pursue, and the defined scopes create a coordination problem that groups solve by agreeing interfaces. Those interfaces end up as the seams in the code.

Treat this as a lens, not a proven cause. Wikipedia's summary notes that the law describes the connection and does not state that communication structure causes system structure (Wikipedia, secondary). Later empirical papers test the idea, such as Herbsleb and Grinter's "Splitting the Organization and Integrating the Code: Conway's Law Revisited" (International Conference on Software Engineering, 1999). Practitioners use the idea on purpose: they choose the team shape they want the software to have. You now know why a team split is also a design decision.

Step 2: Map the flows of work before you place people

Draw boundaries around flows of work, not around people. List the kinds of change your customers or internal users see, then find where each flow waits on a hand-off to another team.

Give each main flow a stream-aligned team that can ship and run its slice without queuing behind others. The test question is simple: can this team change its part of the product without asking another team for permission?

Only then place people. This is the answer to "how do you organize a team around an area of work versus how do you put a person in the right spot": the work shape is decided first, and individual strengths, growth goals and risk decide who fills each seat. Starting from people produces boxes built around who is available, not around what customers need. You now have the units; the next step gives each one a job.

Step 3: Choose team types and interaction modes

Choose a team type and an interaction mode for each boundary. Team Topologies has four team types and three interaction modes (Team Topologies, key concepts).

An enabling team is a team that helps a stream-aligned team overcome obstacles and detects missing capabilities. Enabling teams help and then move on (Team Topologies, 2025). A platform team is a team that provides an internal product to stream-aligned teams to accelerate their delivery. A complicated-subsystem team is a team that holds work needing deep mathematics or technical expertise.

The three interaction modes are collaboration, facilitation and X-as-a-Service, where one team provides and another consumes something as a service. Collaboration is "high bandwidth, high cost", so use it for a defined period. Every team boundary becomes an interface that someone must maintain, so each extra team adds upkeep.

Text description of the diagram

• Enabling teams help and then move on.
• Platform teams provide an internal product to stream-aligned teams.

Step 4: Check span of control and team load

Check span of control and team load before you commit. Overloaded teams make poor decisions and move slowly, so a structure that looks clean on paper fails if one team owns too much.

For managers, there is no single best span. Gallup states that the ideal span of control isn't universal, and that manager quality changes the effect of a larger span. Gallup reports that 37% of managers oversee fewer than five people and 66% manage fewer than 10, in its article of 2026-01-13. About one in five (22%) have 10 to 24 direct reports and only 13% oversee 25 or more, per the same article.

Use these figures as context, not as a target. A good answer says which span you chose and why it suited the work and the managers.

Step 5: Change in small steps and say why

Change the structure in small steps and keep adjusting. The Team Topologies authors write that organizational design is never "done" and must evolve as business needs, technologies and people change (Team Topologies, key concepts). Their nine principles also favor small, safe changes.

A reorg, short for reorganization, is a deliberate change of team boundaries, reporting lines or ownership. Make each change small enough to explain and to reverse. Afterwards, judge whether it worked by checking the same things that motivated it: how many hand-offs a typical change now needs and how long work waits between teams. If neither improved, adjust the next step rather than defending the change. The cross-team change guide covers the rollout side.

1 · Why boundaries matter2 · Flows of work3 · Team types4 · Load5 · ChangeReplay

Step-by-step description

1. Team boundaries become software boundaries.
2. Draw boundaries around flows of work.
3. Pick a team type and interaction mode.
4. Check span of control and team load.
5. Change in small steps and keep adjusting.

• Team boundaries become software boundaries.
• Draw boundaries around flows of work, not around people.
• Choose a team type and an interaction mode for each boundary.
• Check span of control and team load before you commit.
• Change the structure in small steps and keep adjusting.

Worked example

Take an illustrative team of 12 engineers who own three services. Every pair of people is a possible communication path, and the number of pairs is $\frac{n(n-1)}{2}$, so 12 people have 66 paths.¹ Split them into two stream-aligned teams of 6 and each team has 15 paths inside it, 30 in total. The other 36 pairs now cross a team boundary, and they should run through one agreed interface instead of ad hoc chat.¹ This is arithmetic about possible paths, not a measured claim about speed.

Now the span. Suppose 48 engineers (illustrative) report to managers. At a span of 4 you need 12 managers, at 6 you need 8, at 8 you need 6 and at 12 you need 4.¹ Gallup's median is about five to six reports per manager and 66% of managers have fewer than 10 (Gallup, 2026), so a span of 8 sits inside the common range. The trade is plain: a smaller span costs more manager roles, and a larger span leaves each manager less time per person.

Communication paths grow faster than headcount. A team of 12 has 66 paths and a team of 6 has 15.

Text description of the diagram

• Communication paths grow faster than headcount.
• A team of 12 has 66 paths and a team of 6 has 15.

Trade-offs and edge cases

Org design trades one cost for another, and the textbook answer fails in several places.

Duplication against waiting. Stream-aligned teams remove hand-offs but may repeat work such as tooling. A platform team removes the repetition but adds an internal customer relationship to maintain.

Collaboration is expensive. Close joint work is useful for discovery, but its cost is high, so time-box it and move to X-as-a-Service once the interface is clear. Enabling teams are temporary by design; treating them as permanent consultants turns them into a bottleneck.

The law is a lens, not a theorem. Researchers have tested Conway's hypothesis on real codebases, including the Harvard Business School study by MacCormack, Rusnak and Baldwin, "Exploring the Duality between Product and Organizational Architectures", described by Thoughtworks. A correspondence between structure and software does not by itself show which one drives the other, so say "I use it to choose the team shape I want the software to have" rather than "it proves".

Frameworks are not org charts. Use the team types as a thinking model for flow and dependencies, not as job titles or a box-drawing template. The same conversation about boundaries usually involves peers, so see stakeholder management for EMs.

How to answer it in an interview

The spoken structure: say work first, then the boundary and its software effect, then load, then how you change it and communicate it.

Common mistakes

• "I'd put my best people on the biggest problems and build teams around them." (wrong) That starts from people. (right) "I start from flows of work, then decide who fills each team."
• "Conway's law proves that structure causes architecture." (wrong) The law describes a connection between the two. (right) "I use Conway's law as a lens to choose the structure I want the software to have."
• "We reorganized using the Team Topologies template." (wrong) The four types describe how work flows, not job titles. (right) "I used the team types to reason about flow and dependencies."
• "The ideal span of control is eight." (wrong) Gallup says the ideal is not universal. (right) "I picked a span that matched the work and the manager's experience, and I checked the load."
• "Our enabling team is our permanent expert group." (wrong) Enabling teams help and move on. (right) "The enabling team helped for a set period, then handed the capability over."

Follow-up questions

Tell me about a time you reorged an organization: why that structure, how did you communicate it?

Pick a real change and state the problem first, then the structure, the trade-off and what you left unchanged. Say how you told the people most affected before the wider group, and how you checked the result later. The cross-team change guide helps with the rollout part.

How do you organize a team around an area of work versus putting a person in the right spot?

Decide the work shape first, because a seat built around a person rarely matches what customers need. Then place people by strengths, growth goals and risk, and accept that no placement is perfect.

What kinds of organizational incentives create poor technical decisions?

Incentives shape technical choices because people optimize for what is rewarded. Common patterns, reasoned rather than measured, are launch-focused promotion that rewards new systems over maintenance, team-local metrics that push cost onto shared platforms, headcount-based status that favors splitting teams, and builders who do not carry on-call, so operability is neglected. A manager counters them with shared ownership metrics and by recognizing debt reduction in reviews; see tech debt versus features and how technical an EM must be.

How do you explain the structure of your current org?

Describe it by flows of work, not by names: which teams own which flows, how they interact and where the main hand-offs sit. Close with one boundary you would change and why.

What is the largest org you have managed?

State headcount and layers honestly, then your span and why. For scale context, Gallup reports that only 13% of managers oversee 25 or more employees (Gallup, 2026).

What do you do when a senior leader from another org challenges your structure?

Ask what outcome they are protecting, show the flow of work behind your boundaries and agree what evidence would change your mind. The sibling page on a senior leader from another org who challenges your approach covers it in full.

Sources

1. How Do Committees Invent? (Conway, Datamation, April 1968) — Melvin E. Conway (author's site), 1 Apr 1968
2. Team Topologies: Key Concepts — Team Topologies (Skelton and Pais), 26 Oct 2026
3. Team Topologies: how to structure your teams using nine principles and six core patterns — Team Topologies, 6 Mar 2025
4. Span of Control: What's the Optimal Team Size for Managers? — Gallup (Jim Harter), 13 Jan 2026
5. Conway's law — Wikipedia (secondary summary), 26 Oct 2026
6. Splitting the Organization and Integrating the Code: Conway's Law Revisited (Herbsleb and Grinter, ICSE 1999) — ACM (International Conference on Software Engineering, ICSE '99), 16 May 1999
7. Demystifying Conway's Law — Thoughtworks, 26 Oct 2026