6 Structure: The Architecture of Delivery
This chapter is currently in draft form.
Structure provides the rails that work rides from idea to customer value. A structure that allows work to flow freely into production unlocks incredible development velocity, but get it wrong and you create bottlenecks that stifle even the best teams.
Structural changes require significant political capital and cause temporary productivity dips during transitions. When you pay this cost, you want the outcome to be as optimal as it can be. To optimize that outcome, you need clear principles to guide your changes. I will provide those principles here, but realize that my perspective is shaped by years in traditional hierarchical organizations, so I’ll focus on principles that hold true there. If you operate in flat or matrixed structures, adapt these ideas to your context and move with caution.
6.1 Tenets of Organization Design
Effective structure rests on two principles: team purpose and organizational distance.
6.1.1 Clear Goals, Hard Boundaries
In most cases, we can divide teams into two types, delivery teams and platform teams, with each having very specific purposes. Delivery teams own the end-to-end process of shipping customer value. They write code, deploy it, monitor it, and fix it when it breaks. They make product decisions within their domain and are directly accountable for business outcomes. Platform teams, by contrast, are force multipliers. They build tools, platforms, and shared infrastructure to help delivery teams move faster. For example, internal APIs or monitoring systems.
Platform teams exist to enable, not control. Left unmanaged, they drift into gatekeeping. If you see that pattern, that’s on you; you lost trust or never built it. Do not add checkpoints. Fix the boundary and build capability inside delivery, including security, testing, and discipline, so the work can flow. See “When Gates Signal Systemic Failure” later in this chapter for the playbook.
6.1.2 Organizational Distance: Minimize Layers, Maximize Delivery
Organizational distance is the number of reporting layers between people who need to collaborate. The principle is simple: the greater the distance, the harder alignment becomes. Banet identified this dynamic in 1976 as a key variable in organizational design (Banet, 1976), and it remains one of the most reliable predictors of coordination problems.
At distance zero, one person can deliver everything. It is clean and fast, though it rarely scales beyond simple tasks. Add a second person and distance begins to grow. If both report to the same manager, the gap is still small; they share alignment and direction. As soon as they sit under different managers or directors, the gap widens. Each additional layer adds interpretation, delay, and drift.
This reflects a deeper truth about organizations. Your manager defines your alignment and goals; their manager defines theirs. Even with clear direction at the top, each layer translates it into local priorities. By the time two people only converge at the CEO, collaboration has become translation across competing goals.
The remedy is unified delivery. Place responsibility for customer value within a single team. Every handoff between product, engineering, and operations introduces translation errors, delays, and diluted accountability. The ideal delivery team owns everything from customer research to production support. When a system fails at 2 a.m., the team that built it is on call. Tight feedback loops drive quality and speed.
6.2 When Gates Signal Systemic Failure
When you feel compelled to add gates to the delivery process, treat it as a signal of capability gaps at the people and process layers. Gates are responses to past failures, not solutions. The architecture review board often appears after a system fails to scale. Security approvals show up after vulnerabilities reach production. QA gates follow broken features reaching customers.
The issue is not that these failures occurred; in complex systems they will. The issue is responding with new gates instead of building capability inside delivery teams.
Replace approvals with capability. Equip teams with the tools and training to make secure decisions, and embed security expertise where the work happens. If regulation requires independent checks, keep them narrow, automated, and auditable.
Apply the same approach to quality, architecture, and compliance. These concerns are legitimate. The goal is to place the capability to address them as close to delivery teams as possible.
If your CTO reacts to production problems by adding gates (security approvals, release checkpoints, or separate deployment teams), you have a structural problem. These barriers create coordination issues and bottlenecks instead of fixing root causes.
This pattern signals your CTO does not yet know how to design a strong delivery organization. Your job is to decide whether they can learn or whether you need someone else.
Ask your CTO for an organizational plan. Ask for three elements: target design, the tenets behind it, and an implementation schedule. Judge it on whether it speeds decisions and accountability, not on headcount charts. Look for unified delivery and minimal organizational distance. If the plan adds gates instead of embedding capability in delivery teams, send it back with clear criteria.
6.4 The Human Cost of Restructuring
Structure changes over time as your team matures. Early constraints loosen as you gain credibility and organizational understanding. You should absolutely take advantage of that evolution. But restructuring has a frequency limit. In my experience, that rhythm usually looks like 6–12 months between structural shifts. Any faster, and you exhaust people. Any slower, and you drift. This matches what organizational researchers have found: change works best as a rhythmic pulse rather than one-off events (Huy and Mintzberg, 2003), with tempo, duration, and sequencing determining success or failure (Kunisch et al., 2017).
Restructuring takes a human toll. People need time to get resituated, understand new roles, rebuild working relationships. You’ll see a productivity dip during any reorganization. If you’ve made good structural choices using these tenets, productivity should recover to a higher level. But that recovery takes time.
Early in your tenure, political constraints and organizational immaturity will force suboptimal structures. As you build credibility and your teams mature, those constraints ease. Use that opportunity strategically. But remember that each restructuring spends political capital and human energy. Make sure the structural improvement justifies both costs.
Structure is the lever most technical leaders underutilize because it requires political capital and organizational courage. Easier to optimize processes or coach people than fundamentally reorganize how work flows. But structural changes have exponential impact. Fix structure and many people and process problems solve themselves.
The goal isn’t perfect structure; that doesn’t exist. The goal is structure that lets delivery teams own their outcomes with minimal external dependencies. When your teams can ship value without asking permission from platform teams, you’ve achieved structural leverage.