The Org Structures That Emerge from AI Maturity — And the Context That Should Shape Them

Aristotle bust, Public domain, via Wikimedia Commons

Previously, I mapped out five stages of AI maturity from counterproductive early adoption to a refined operating model and I explored how UX Research has already experienced, and learned from, the role blurring other teams are now going through with AI adoption.

Now, I finally get to start tackling the anxiety-provoking question that arises in Stage 2 of AI maturity: what does the resulting org structure actually become?

Before diving in, I have a bone to pick with how org design is typically discussed. Most articles conflate two distinct concepts: reporting structures and how individuals with different specialties actually work together. Delivering these two ideas as a single framework muddies the waters. They go somewhat hand-in-hand, but the number of variations they create without meaningful difference in how the team actually does the work makes it counterproductive to present them together. This article focuses on how team members do the work together, specifically to avoid those confusing conversations about matrix reporting.

Org Design Cannot Live in a Vacuum

Org structure design cannot be created in a silo of ideals. There is unfortunately not a one-size-fits-all model and even the structures I propose later in the article will need to be modified for your specific context.

Org design must account for the value different specialties bring to the organization and the context of the organization itself. When you reach Stages 2 and 3 of AI maturity, roles blur and org structures need to evolve — but how they evolve should depend on where your organization is, not just on what’s theoretically optimal. (And as I noted in my first article, I don’t believe this is always about workforce reduction. McKinsey’s research on AI augmenting roles rather than eliminating them is worth keeping in mind throughout this piece.)

Before we get to the actual structures, let’s talk about what I mean by organizational context.

Financial Position and Business Phase

The first consideration is the financial position and overall trajectory of the organization. Michael Watkins’ The First 90 Days outlines the STARS model, which serves as a useful starting place for thinking about your organization’s context. He frames it as “match strategy to situation.” I’ve adapted it here with specific considerations for how each context should inform org design decisions around AI enablement.

Start-up. You’re assembling capabilities to get a new business off the ground. You can shape the organization from the outset. Smaller teams mean less cognitive load from relationship management. Jens-Fabian Goetzmann illustrates this nicely by showing how the number of one-to-one relationships grows exponentially with each new team member. Start-ups can also experiment with AI more rapidly: less red tape, already-blurred lines between roles due to team size.

Turnaround. You’re taking on a unit in deep trouble and working to get it back on track. Unfortunately, you likely need the ROI of a reduced workforce, but you don’t have much bandwidth to get your org structure wrong. That said, you don’t want to immediately chase headcount reduction through AI enablement for the reasons I outlined in my first article. A more conservative approach to org structure avoids adding another variable that could compound failure.

Accelerating Growth. The organization has hit its stride, and the hard work of scaling has begun. AI enablement will be particularly difficult here because you’re designing the plane while building it. If you’ve successfully reached Stage 2 or 3 of AI maturity in this context, that’s impressive. Because you’re likely not trying to reduce headcount, you have more room to explore org designs that highlight the specializations of individual skills. You may lean more toward what AI augments rather than what it automates away.

Realignment. Your challenge is to revitalize a unit or product that has been drifting into danger. Similar to Turnaround, a conservative approach may be wise, but at least you have some runway. You may be able to pilot a new way of working with one squad or team before rolling out to the full organization.

Sustaining Success. You’re preserving the vitality of a successful organization and taking it to the next level. This demands understanding at a deep level what has made the business successful. It would be a shame to chase quick ROI for shareholders by setting up an org structure that cuts exactly the capabilities that built the organization’s success.

Culture

The next piece of context is your organization’s culture. Peter Senge’s The Fifth Discipline addresses this in depth, particularly around the failures that come from fear-based cultures rather than learning-oriented ones:

“CEOs tend to emphasize developing the organizational culture. ‘In the traditional authoritarian organization, the dogma was managing, organizing, and controlling.’ … ‘In the learning organization, the new “dogma” will be vision, values, and mental models.’”

AI enablement, particularly how leadership decides to restructure around it, can change an organization’s culture overnight. If your organization already runs on fear, a poorly handled restructuring is a great way to put the nail in the coffin. Organizations driven to show value constantly and repeatedly (as encouraged by at least the United States’ particular flavor of capitalism) are likely to reward quick turnarounds of work that don’t actually generate value for customers, which then fails to return the business value that was expected. It’s the opposite of the swan effect: you see rapid pedaling and assume it will create the beautiful, seamless experience of a swan floating across a lake. Instead, it creates a dumpster fire.

Size

The last piece of context is organizational size. While the STARS model indirectly touches on this, it’s worth calling out separately since you can have significant variation in org sizes within any phase of that model. This article is biased toward larger organizations (1,000+ employees) because structure becomes more critical to define at that scale. The relationship management challenge I mentioned earlier, where the number of connections grows exponentially as you add even one more person, is the reason why.

How Product Development Orgs Are Structured Today

Now that we’ve established the context lens, let’s map the current landscape. This will unfortunately do the thing I hate — conflating reporting and how teams actually work together — but it’s necessary to establish a shared vocabulary.

The major models include centralized resource teams that serve the broader organization (what Nielsen Norman Group calls “Centralized”), and pods where every specialty sits within a team and matrixes back to their discipline (NN/g Matrix or NN/g Decentralized). The pod family includes several well-known variations: the squad model (Spotify’s model), the triad model, feature-based teams, and stream-aligned teams. Departments that live separately and matrix into cross-functional teams are also common, though structurally they’re a reporting variation on the centralized model.

The references below skew toward UX, and intentionally so as UX is often the last discipline added to a product organization and the one with the fewest seats at the table, which means its placement tends to surface org design tensions that other disciplines can afford to ignore:

1. Product School’s guide to product team structure
2. dScout’s “Structure and Scale Your UXR Team” — I particularly like their framing of “agency/centralized” versus “embedded”
3. Nielsen Norman Group’s UX team models

What the New Org Structures Could Look Like

Before introducing the specific structures, it’s worth stepping back. Humans have been organizing themselves for millennia and specific models I propose may invoke different feelings when shared through a lens we are more narratively and historically familiar with.

The Question of Power Is Not New

Ancient Egypt developed hierarchical administrative systems sophisticated enough to coordinate pyramid construction with documented division of labor, attendance tracking, and role accountability. By 350 BCE, Aristotle had formalized a classification of government in his Politics, distinguishing rule by one (monarchy), rule by few (aristocracy), and rule by many (polity).

There are whole degrees dedicated to organizational design, and many additional factors to consider in a corporate environment, but there is not going to be a truly new idea in this space even with the major shifts AI creates. What changes is the context in which we apply these patterns, and at the end of the day, many of these patterns still come back to who holds the power, which, in product organizations, often means who is the final decision maker, a dynamic that can be represented in a RACI-like artifact.

Aristotle’s framework is useful here because my proposed org structures map to different models of power distribution. Each represents a different answer to the question: who decides?

• Jack of All Trades → Monarchy / Tyranny. Power is consolidated in a single person. One individual makes the calls across research, design, and development. When that person is competent and accountable, this can be efficient (Aristotle’s virtuous monarchy). When they’re not, it drifts toward tyranny: unchecked decisions, blind spots in specialties they don’t deeply understand, and no structural mechanism to course-correct.
• Core Team and Centralized Specialties → Aristocracy / Oligarchy. Power sits with a small group likely being formed of product and design, but variations can exist. The core team consults other specializations (likely research, analytics, engineering) to inform decisions. But the degree to which they tap into the specialties is ultimately up to the group in power. This mirrors Aristotle’s aristocracy when the core team genuinely values and acts on counsel, and oligarchy when they treat consultation as a checkbox.
• Double Diamond → Polity / Democracy. The discovery diamond conducts activities that promote constant interaction with users and the market, where a mix of user needs and business needs drives the prioritization of opportunities, and then hands those defined opportunities to the delivery diamond. The data is making the decisions, not a single person or group. It functions almost like a representative system: evidence gathered from the field shapes what gets built, rather than the preferences of whoever holds the most authority. Not that you cannot do data-driven design in the other org types, it’s just that the person or group in power has to champion that belief individually, rather than the structure promoting it inherently. Regardless, this in its best form is what Aristotle called polity. In his original framework, democracy was actually the corrupted counterpart, rule by the many in their own self-interest, despite that not being how we typically define democracy today. But corrupted forms do emerge: bad leaders within even well-designed systems can dismantle the core values and returns the structure was built to deliver.

Jack of All Trades

One person does it all — research, design, development — for a certain scope of product or service. In its default state, the Jack of All Trades model relies heavily on high proficiency and maturity, both of the organization and of the individual contributor, or on AI guardrails that minimize the impact of skill gaps. I envision the Jack of All Trades as someone orchestrating a coordinated fleet of AI agents that collectively perform the work once done by a human team. I am afraid this is the territory most companies are or will venture into with the simple goal of showing stakeholder value without considering what actually drives value in their organization.

Well suited for: Start-ups and smaller organizations (under 100 people).

Risk level: High in its default state. This isn’t likely an org structure you should leap to; it’s one you might evolve toward. The workforce reductions it could produce make it risky as a starting point. I’ve outlined two variations below that mitigate this risk.

Two variations seem most plausible:

Jack of All Trades + Specialization Consultants. Likely someone from Product or UX who shifted into a do-it-all role. This approach contains a centralized resource group of specialists (ex. research, design, architecture). These specialists could be internal employees or contracted consultants. This model depends on the individual contributor knowing when and how to engage with these specialties.

Jack of All Trades + Specialization Owners. Same core, but instead of a centralized resource group, different domains have a dedicated expert overseeing that specialty across a set of products or services. Think of a UX owner, an architecture owner — someone who monitors the consistency and quality of their craft despite it being executed by numerous generalists. This reduces single-point-of-failure risk and fosters higher-quality delivery.

Core Team and Centralized Specialties

I envision this as Product and Design as the core team. Product works in a pod, squad, or embedded team model with one or more designers, and this core team focuses heavily on early-stage design work. The pod taps the centralized resources (research, analytics, engineering, or any other specialty the organization may have) at key stage gates to ensure quality: that problems are properly understood (research) and that AI-generated code meets devops criteria like cybersecurity requirements and successfully merges into the larger repo (engineering).

Well suited for: Turnaround and realignment contexts, and large Fortune 500s that can’t move fast or struggle with change transformation.

Risk level: Lower. This delivers workforce reduction ROI with the least amount of structural disruption.

Double Diamond

Here the discovery diamond becomes one part of your org and the development diamond becomes another.

Your Discovery Diamond team includes business analysts, data scientists, AI developers, researchers, and UX designers (those with strong skills in early-stage design) working on blue ocean visions, new business opportunities, and innovation. This team augments the workforce and emphasizes the human value in the process. Humans use AI to explore more concepts and reach insights faster, but you’re enabling the specialties that have these skills with AI tools rather than replacing them.

Your Development Diamond team is where more roles are automated than augmented. The vision, plan, and strategy created by the Discovery team gets built here, with this team responsible for execution, compliance, and integration with the existing product.

Personally, this is my favorite of the models I propose as I see it upholding and augmenting the value only humans can provide while taking advantage of where AI can streamline functions. Additionally, I’m a strong proponent of designing systems that make it hard to fail and this model relies least on the human needing to be exceptionally proficient and capable.

Well suited for: Organizations in accelerating growth — deploying this model could further their lead on the competition. Sustaining success organizations could also benefit if they have the ability to invest in discovery resources they may not already have.

Risk level: Lowest of the three. The ROI emphasis is not on workforce reduction but on reallocation of resources: automating roles in execution while augmenting others that drive value. However, it may require investment if the organization doesn’t already have the talent it wants to augment.

In conclusion, org structure decisions in the age of AI are not purely structural decisions. They’re value decisions. What does your organization believe about human work? What specialties built your success, and what happens when you commoditize them? Your organizational context (your business phase, your culture, your size) should shape the answer.

What does your organization value?

— — —

Note: Written with editorial assistance from Claude (Anthropic).