Org Structure as a Design Process
Visionary leaders design their teams with intention
It was 2008, I was a new manager of an inherited team, and I knew my craft well enough to rise in seniority. I understood process, I cared about quality, I had strong instincts about good design and when to engage customers in research. What I didn't have was a framework for thinking about the team itself as something that needed to be designed. I made decisions reactively, responded to what the work demanded, and communicated in the language of my discipline rather than the language of the business. The team did good work and I was probably better at coaching them as designers than as professionals. But I had no real vision for what our program was becoming, and I couldn't have articulated its value in terms that would have mattered to a CMO, CFO, or CEO.
More than eighteen years and four organizations later, I find myself in a situation that's the mirror image of that one — not a team I'm learning to lead, but a team I'm learning to redesign. Organizational design, like any design problem, requires you to understand and analyze before you improve. Every team I've joined or built has had its own history, its own culture, its own norms, values, and behaviors. Over time, I became more seasoned at how to approach the team design problem in different company environments, with more structured approaches. Every time, my goal was to support each team member to be more effective individually, and for the team to be impactful organizationally.
The org is the design problem
Most leaders think of design as something their team does to products, to experiences, and to systems. Fewer think of their team itself as something to be designed. But the same principles that produce excellent products apply directly to the problem of building an excellent organization: understand the need, define a vision, build deliberately toward it, measure what matters, and communicate the outcome to the people who need to understand it.
This isn't a principle unique to design. The strongest engineering, product, finance, and sales organizations I've observed share the same underlying architecture. What distinguishes them isn't just talent or resources. It's the intentionality of their leaders.
The framework I've used to build design organizations rests on four pillars:
Strategy is the vision of what the organization needs to become, ambitious enough to be worth working toward.
Culture is the expertise, grit, and mindset of the people who will build it.
Process is the collaborative methodology that produces reliable, high-quality output.
Outcomes are the measurable results that make the team's value legible to the organization.
Each pillar depends on the others. A team with vision and culture but no process produces brilliant work inconsistently. A team with process and outcomes but no vision executes well without growing. A team that has all three but can't communicate what it's doing and why tends to be underfunded, underestimated, and eventually invisible.
Maturity is a progression, not a destination
One of the most useful shifts in how I think about team building is treating organizational maturity as a deliberate progression — a sequence of capabilities built over time, each level creating the conditions for the next.
Early maturity looks like foundations: the right people in clearly defined roles, documented processes, and basic visibility into how the work gets done. Mid-level maturity adds sophistication through a structured program for gathering feedback and measuring impact, shared standards that ensure quality and consistency across the team's output, and early evidence that the work is moving meaningful business metrics. Full maturity looks like an organization that has embedded itself in the company's strategy, earns investment proactively rather than defending it reactively, and extends its influence beyond its immediate function.
The temptation is to skip levels, to reach for influence before you've established the operational foundation that makes influence credible. That almost never works. What works is being honest about where the team actually is, setting a clear direction for where it's going, and making that progression visible to the people who need to fund and support it.
The building blocks of organizational design
A framework without building blocks is just philosophy. Here's what the actual work looks like in practice.
Start with a mission statement that is specific, memorable, and durable. Not a generic aspiration, but a sentence or two that any member of the team could recite and that any executive could understand. The mission I developed for one design organization lasted thirteen years without revision, not because it was clever, but because it was true. It exactly defined what the team was there to do, in language that connected principles and craft to business value. A good mission anchors every hiring decision, every prioritization conversation, and every defense of the team's budget.
Define the roles clearly, not just titles, but the distinct contribution each role makes to the team's output and the organization's goals. Vague job definitions produce vague accountability. When people understand exactly what they own and why it matters, they perform differently.
Build a measurement system that speaks in business terms. Every specialized function — design, research, engineering, finance, legal — produces work that ultimately shows up somewhere in the organization's results. The leader's job is to find those connections and make them explicit. Does your team's work reduce time-to-market? Increase conversion rates? Improve customer retention? Reduce support costs? Quantifying those connections and adding color with qualitative quotes from customers and stakeholders transforms the team from a cost center into a value creator in the minds of the people who make resource decisions.
Establish a communication strategy that reaches out in all directions. Internally, that means regular showcases of the team's work, structured updates in leadership forums like quarterly business reviews, and a clear narrative about progress toward the team's goals. Externally, it means making the team's standards and capabilities visible to the market through conference presentations, published content, podcasts, or a public-facing presence (like meetups and seminars) that signals the organization's commitment to the discipline. The best teams I've observed treat their own visibility as a strategic asset. So did the best teams in other functions (engineering, product, science, marketing, sales) that I've partnered with over the years. When we shared internal showcases and co-presented at conferences, the collective credibility of all teams rose together.
Building from scratch versus inheriting
Building and inheriting are two genuinely different problems.
Building a team from scratch gives you the luxury of design from first principles. You can hire toward a vision, establish culture before bad habits calcify, and build process before the pressure to skip it becomes overwhelming. The risk is that you're designing in the absence of context, meaning you may not know what the organization actually needs until you're fully immersed in it.
Inheriting a team, or arriving into a hybrid situation where some people followed you and others were already in place, is more complex. You're designing around existing culture, existing relationships, existing expectations. The people who were there before you have a history with each other and with the organization that you can't fully see yet. Moving too fast signals disrespect for what existed. Moving too slowly signals that nothing will change.
What both situations have in common is the same underlying discipline: understand before acting, define vision before structure, and communicate the direction before making change. The sequence matters regardless of the starting point.
The leader's job is to build something bigger than themselves
At every organization where I've built or rebuilt a team, the trajectory was the same: from shapeless or immature to high-performing and high-impact. And in each case we had the metrics to prove it: increased revenue, improved conversion rates, stronger market position, higher customer satisfaction and adoption. None of that happened by accident. It happened because there was a vision for what the team needed to become, a designed framework to grow into, and a consistent effort to connect that work to the bigger picture in language the organization could connect to, driving action.
The team I managed almost twenty years ago was capable. What it lacked was a leader who had fully learned to design the organization around that capability — to give it structure, direction, and a voice that could be heard in the rooms where decisions were made. The goal as a leader is not to simply manage a team, but to design it with structure and systems that lead to maturity and impact.
