Skip to content
Page 5 of 5

Teams in the AI Era

The Bottleneck Shifted. Have the Teams?

In The New Frontier, you learned that the bottleneck on software teams has moved from writing code to knowing what users need, building the right things, and verifying outcomes.

That shift has a direct implication for team structure. When the bottleneck was engineering capacity, it made sense to staff heavily in engineering roles. But bottlenecks move, and they will keep moving.

The goal is flow: software gets developed, verified, and delivered without people sitting idle waiting on another role to finish. If the bottleneck shifts to verification, user understanding, or defining outcomes, the team needs to rebalance. The specific answer will differ for every organization. What matters is constantly evaluating where work piles up and whether your team's structure addresses the actual constraint, not the one you had last year.

Everyone Can Build. Not Everyone Can Judge What AI Produces.

You experienced it today: you described what you wanted in plain English, and AI built working software. This is happening everywhere. People in non-technical roles are building tools, prototyping ideas, and shipping software without writing code. Anyone can be a full-stack builder now.

But you can build anything; you can only evaluate what you deeply understand. Building is the easy part. Knowing whether what was built is actually right requires discipline-specific expertise:

  • Understanding your users. A UX Researcher knows how to discover what causes friction, what drives behavior, and how to turn those insights into experiences that change what people do. That judgment comes from years of practice, not from a tool.

  • Knowing what to measure. A Product Manager knows how the software contributes to the mission, what experiments to run, and when to say no to a feature that sounds good but does not serve the goal.

  • Judging whether the code is sound. On complex or high-stakes projects, someone needs to assess whether the architecture will hold and whether the technical choices will create problems down the road.

These are all forms of taste and judgment: the ability to evaluate whether what was produced is actually good enough for the people who depend on it.

There is a deeper layer. AI models do not know how your organization actually works: who the stakeholders are, what the unwritten processes look like, what compliance requirements apply, or what your users struggle with that nobody has documented. That understanding lives in relationships, conversations, and accumulated experience. Getting it right is an anthropology problem, not a technology problem. Today, there is no AI solution for that.

Think of it like...

In the early 1900s, a single doctor did everything: set bones, delivered babies, prescribed medicine, performed surgery. As medical knowledge grew, specialization became essential. Today, the American Board of Medical Specialties certifies physicians across more than 40 specialties and nearly 90 subspecialties.

Complex diagnosis? You go to a specialist. Not because the generalist is incompetent, but because the specialist has depth the situation demands.

Software is heading in a similar direction. Everyone can build now, the way a first-aid-trained person can treat a scrape. But complex, high-stakes software still requires deep expertise: research, design, product strategy, systems architecture, security.

This connects to the autonomy slider from the previous page. When the stakes push the slider toward more human involvement, you want that human to have the expertise to evaluate what AI is producing. The higher the risk, the more specialized judgment matters.

What This Means for Your Organization

Not every application carries the same stakes. For personal tools, internal utilities, and rapid prototyping, the techniques you learned today are enough. You can build, test, iterate, and ship with minimal overhead.

Mission-critical software is a different category. When the software runs in a classified environment or supports live operations, you need people who can verify what AI produces: whether the architecture will hold, whether the security model is sound, whether the technical choices will create problems six months from now. AI does not replace that judgment. It makes it more leveraged, because an engineer who can direct AI-produced code moves faster without sacrificing rigor.

The right team shape will depend on mission, domain, and risk tolerance. But there are things we do know:

  • Specialization still matters. AI amplifies existing organizational strengths. If the expertise is there, AI makes it more effective. If it is not, AI cannot substitute for it.

  • Bottlenecks have moved. Evaluate your flow. The constraint is no longer writing code. It may be understanding users, defining outcomes, or reviewing work. Examine where work piles up, where people wait, and whether your current roles and ratios reflect the actual constraint.

  • Frame around outcomes, not outputs. Outputs are cheap now. When structuring teams or contracts, define success around the outcomes you need: behaviors that change, mission impact, problems that get solved.

  • Cross-training goes both directions. Product Managers and Designers who learn enough engineering to prototype and evaluate AI output become more effective in their own disciplines. Engineers who learn about users and product strategy can own outcomes end-to-end. AI lowers the barrier to crossing those boundaries.

Discussion: What Does This Mean for Your Teams?

Team Discussion | ~3 minutes total | Discuss at your table.

Think about how teams are structured in your organization. If anyone can contribute to building software, what changes? What stays the same? Where does specialization matter most in your domain?

If you are involved in contracts or acquisition: do the labor categories and role definitions in your current contracts reflect how AI-assisted delivery actually works?

Key Insight

Everyone can build now, and for prototypes and lower-stakes tools, that is enough. For mission-critical software, the stakes demand the same engineering depth they always have. AI makes experts more leveraged, not less necessary: the higher the stakes, the more specialized judgment you need in the loop.