Organizational Design

Organizational design is about the shape of the system people work in. It's the decisions about who's on which team, how teams are formed, where ownership boundaries live, how decisions get made, and how the org adapts when the strategy changes. Most of the problems that look like people problems are actually structural ones: unclear ownership, misaligned scope, roles that don't match the work, boundaries that create friction instead of clarity.

The arc of growth in this competency moves from noticing structural problems to designing organizations that can continuously reshape themselves. As a Team Lead, you're learning to see the system and distinguish structural problems from individual ones. As an Engineering Manager, you're actively designing how your team is organized and scoped. As a Senior Engineering Manager, you're making deliberate decisions about team boundaries, ownership, and hiring across multiple teams. And as a Director, you're building an organization that can form the right teams for whatever comes next. At every stage, the core insight is the same: structure shapes behavior, and getting the structure right makes almost everything else easier.

The IC to Manager Shift

As an IC, you worked within a structure someone else designed. You felt the effects of good and bad organizational design every day, in how clear your ownership was, how decisions got made, where handoffs broke down, but you weren't the one making those structural choices. As a manager, you start owning those choices. The way you define roles, draw boundaries, and organize work directly shapes how your team experiences their jobs. The shift isn't just about authority. It's about recognizing that many of the frustrations you experienced as an IC were structural, and now you have the ability to fix them.

Team Lead

At this stage, you're not designing the org. But you're starting to notice how structure affects your team's work. Who owns what decision, which meetings actually matter, where handoffs break down, why some things fall through the cracks. Most of these problems feel like people problems at first, but they're often structural ones.

The skill here is learning to see the system. When something is confusing or slow, ask whether it's because someone dropped the ball or because the way things are set up makes it hard to succeed. That distinction matters more than you think.

What This Looks Like

You clarify roles and responsibilities within the team so people know who owns what. When you notice confusion or friction, you ask whether it's caused by unclear ownership rather than individual failure. You define how decisions get made on the team instead of letting it happen implicitly. When something falls through the cracks, you examine whether it's an ownership gap before assuming someone dropped the ball.

The most common mistake at this stage is treating every problem as a people problem. Someone missed a deadline, so they're not performing well. A handoff was dropped, so someone wasn't paying attention. But often the real issue is that no one was clear on who owned the handoff in the first place, or the deadline was unclear, or the decision-making process was ambiguous. Learning to see these structural causes is the foundation of organizational design thinking.

You're succeeding when everyone on the team knows what they own and where the boundaries are. When something falls through the cracks, you can tell whether it's a structural gap or a performance issue. Decision-making on the team is clear enough that people don't need to check with you on everything. You've identified at least one problem that looked personal but was actually structural, and named it.

The Shift

The fundamental shift at this stage is moving from "I manage the people on my team" to "I'm responsible for whether the way this team is set up actually works." It's not enough to coach individuals and remove blockers. You also need to pay attention to the system they're operating in. Is the structure helping them succeed, or creating invisible obstacles?

This requires a different kind of attention. Instead of just noticing that something went wrong, you start asking why the structure allowed it to go wrong. Instead of just fixing the immediate problem, you ask whether the same kind of problem will keep happening because of how things are organized.

How to Grow

Ask yourself: Where does work get stuck or confused, and is it because of people or because of how things are organized? Does everyone on my team know what they own and what they don't? Are there decisions that take too long because no one knows who gets to make the call?

Build habits around structural awareness. When something falls through the cracks, ask whether it's an ownership gap before assuming someone dropped the ball. Write down who owns what on your team, even informally, and revisit it when the work changes. When a new responsibility lands on the team, explicitly assign it instead of letting it float. Pay attention to which meetings and handoffs cause the most friction and ask why.

You'll know you're ready for the next stage when the team operates with clear ownership and people rarely step on each other's toes. When you can distinguish between a person struggling and a role that's poorly defined. When your manager hears from you about structural issues before they become crises. You can't redesign the org at this stage, but you can make sure your corner of it is clear, well-defined, and set up for people to succeed.

At this stage, organizational design is about learning to see the system, distinguishing structural problems from people problems and making your corner of the org work well.

Engineering Manager

At this stage, you're actively shaping how your team is organized to do its best work. That means owning roles, responsibilities, and the boundaries of what your team does and doesn't do. You're also starting to think about composition: do you have the right mix of skills and experience for the work ahead, and where are the gaps?

The trap is going to one extreme. Some managers over-formalize everything with rigid processes and defined roles for every edge case. Others leave everything loose and call it agility, but what they actually have is confusion. The skill is knowing what needs structure and what needs room to breathe.

What This Looks Like

You define clear roles and responsibilities that match the team's actual work, not a generic template. You identify gaps in team composition and have a plan for addressing them, whether through hiring, skill development, or shifting responsibilities. You structure how decisions get made so the team can move without bottlenecks. When the work changes, you adjust the team's internal organization instead of sticking with what was set up originally.

The hardest part is finding the right level of formality. Too much structure and people feel boxed in, every edge case requires a process update, and the team can't adapt quickly. Too little structure and ownership is vague, decisions stall because nobody knows who has authority, and the same arguments happen over and over. The right answer depends on the team, the work, and the moment. It changes over time, and adjusting it is part of the job.

You're succeeding when the team's roles, scope, and decision-making structures match the work they're actually doing. When you can articulate where the team has gaps and what you're doing about them. When the team has the right amount of structure: enough to be clear, not so much that it's rigid. When the work changes, you adjust the team's organization instead of forcing the old structure to fit.

The Shift

The shift at this stage moves from "I'm responsible for whether the way this team is set up actually works" to "I actively design how this team is organized, composed, and scoped for the work ahead." You're no longer just noticing structural problems. You're making deliberate choices about how to organize the team.

This includes thinking about composition in a way you probably haven't before. It's not just about hiring to fill headcount. It's about asking what skills, experience levels, and perspectives the team needs for the work ahead, and then closing the gaps intentionally. Every hire, every role change, every scope adjustment is a design decision.

How to Grow

Ask yourself: Does the way this team is organized match the work we're actually doing, or are we working around our own structure? Where are the gaps in this team's composition, and am I addressing them or hoping they'll resolve themselves? Is the team's scope clear to the people outside it, or are we getting pulled into work that shouldn't be ours?

Build habits around intentional design. Review roles and responsibilities when the team's work shifts significantly, not just when someone leaves. When hiring, start from what the team needs, not from the last job description you used. When scope creep happens, name it and renegotiate instead of quietly absorbing it. Periodically ask whether the team's internal structure still makes sense for the current priorities.

You're ready for the next stage when the team's organization feels intentional and people understand why it's set up the way it is. When you've hired or restructured to fill a real gap, not just added headcount. When other teams and leaders understand your team's scope and don't constantly push work over the boundary. The best managers at this stage don't just fill seats. They think about what the team needs to succeed and organize around that.

At this stage, organizational design is about intentional shaping, designing roles, scope, and composition around the work your team actually needs to do.

Senior Engineering Manager

At this stage, you're designing structure across multiple teams. That means making real decisions about team boundaries, ownership models, reporting lines, and hiring strategy at the org level. When you split a team, merge two teams, or staff a new initiative, those are organizational design decisions with consequences that last.

Hiring becomes a serious lever here. You're not just filling roles on one team. You're thinking about composition across your org: where the skill gaps are, what the right senior-to-junior ratio looks like, and how to staff new work without gutting existing teams. You're also deciding when the current structure needs to change, which is one of the hardest calls at this stage.

What This Looks Like

You make deliberate team structure decisions, splits, merges, new teams, based on strategy rather than convenience or history. You hire with org-level composition in mind, thinking about how each hire fits into the broader picture. You define clear ownership boundaries between teams so work doesn't fall through the cracks or get duplicated. You recognize when a team structure that used to work is now creating friction, and you change it.

The most common failure is inertia. Teams stay structured the way they are because restructuring feels disruptive, even when the current structure clearly isn't serving the strategy anymore. The other common failure is staffing by reflex: pulling from the same strong team every time a new initiative needs people, burning out your best group while others coast. Both of these are structural problems disguised as tactical ones.

You're succeeding when teams are structured to match the current strategy, not just the way things were set up originally. When ownership boundaries between teams are clear and rarely disputed. When hiring decisions are made with the whole org in mind, not just the team with the open headcount. When you restructure, the rationale is clear and the transition is well-managed.

The Shift

The shift at this stage moves from "I actively design how this team is organized" to "I design how multiple teams are structured, staffed, and bounded to serve the org's strategy." The decisions you make now affect dozens of people. Where you draw team boundaries determines who works together daily. How you staff new work determines which teams feel stretched and which feel stable.

This requires balancing competing concerns. You want teams small enough to be cohesive but large enough to deliver. You want clear boundaries but not rigid silos. You want to staff new initiatives without destabilizing existing ones. There's no formula for these tradeoffs. They require judgment, and they require revisiting as the strategy evolves.

How to Grow

Ask yourself: Are my teams structured for the work we need to do next, or the work we were doing six months ago? Where are ownership boundaries between teams unclear, and what's that costing us? Am I hiring to shape the org I need, or just backfilling the org I have?

Build habits around structural health. Review team structure against strategic priorities at least quarterly. When a team is struggling, ask whether it's a leadership problem or a structural one before assuming either. Before opening a new role, articulate how it changes the team's composition, not just its headcount. After any restructure, check in on how the transition landed and what you'd do differently.

You're ready for the next stage when your org adapts its team structure as strategy evolves instead of clinging to what worked before. When ownership between teams is clear enough that cross-team work doesn't require constant negotiation. When people across your org can explain why the teams are structured the way they are. The teams you create, the boundaries you draw, and the people you hire shape how dozens of engineers experience their jobs every day.

At this stage, organizational design is about building the right containers for work, making deliberate structural choices that serve the org's strategy and the people within it.

Director

At this stage, you own the shape of the engineering organization. Team topology, reporting lines, ownership models, decision rights, hiring strategy across the whole org. The question isn't whether any single team is well-structured. It's whether the organization can form the right teams for whatever the business needs next.

The real challenge is building an org that can adapt. Organizations naturally calcify around the structures that worked before. Your job is making sure the org can restructure when strategy shifts, staff new initiatives without gutting existing ones, and do all of this without months of thrashing every time.

What This Looks Like

You design team topology to match business strategy and adjust it as strategy evolves. You create the organizational capacity to form new teams, wind down old ones, and move people without chaos. You own the hiring strategy across the org, ensuring the right talent in the right places at the right time. You build systems for making structural decisions that are grounded in evidence, not politics or inertia.

The risks at this stage are both over-engineering and under-engineering. Some directors treat reorgs as the answer to every problem, reshuffling teams so frequently that no one has time to gel before the next change. Others let structural debt accumulate for years: unclear ownership, outdated team boundaries, roles that no longer match the work. Both are failures of organizational design, just in opposite directions. The skill is knowing when the structure needs to change, when it needs time to settle, and how to execute the change well when it's needed.

You're succeeding when the org adapts its structure as priorities shift without months of planning and thrashing. When new teams spin up effectively because the org has a playbook for forming, staffing, and onboarding them. When ownership is clear across the entire org and rarely a source of cross-team friction. When structural decisions are made based on strategy and data, not politics or who has the loudest voice.

The Shift

The shift at this stage moves from "I design how multiple teams are structured" to "I build an organization that can continuously form the right teams for whatever comes next." You're no longer making individual structural decisions. You're building the organizational capability to make those decisions well, repeatedly, as the business evolves.

This is the difference between being a good architect and building a system that can be easily re-architected. The org will need to change shape over time. Markets shift, strategy pivots, teams grow or shrink. If every structural change requires your personal involvement and months of planning, the org can't keep up. If the org has the norms, playbooks, and muscle memory to restructure effectively, it can adapt to almost anything.

How to Grow

Ask yourself: Can this org stand up a new team effectively, or does it take months of thrashing? Is the current org structure serving our strategy, or are we working around it? Where is structural debt accumulating, and what's the cost of not addressing it?

Build habits around organizational health. Review org topology against strategic priorities at least twice a year. After any restructure, check in on how the transition landed, not just whether it shipped. Maintain a clear picture of where talent is concentrated and where gaps are emerging across the org. When structural problems surface, fix the root cause instead of patching around it.

Your growth at this stage continues through building an organization that can organize itself. The structures you design, the ownership you clarify, and the adaptability you create determine whether the org can keep up with what the business needs next. If the org only works in its current configuration, it doesn't work. The best directors build organizations that are durable and flexible at the same time.

At this stage, organizational design is about building an organization that can reshape itself, one that adapts to strategy, not the other way around.