Overview

Your org chart still looks like it did five years ago. Three engineers per feature. Six engineers per service. A principal architect who reviews everything. A security team that approves deployments.

That structure made sense when building software meant "write code, review it carefully, deploy carefully, hope it works."

When your engineers have access to AI that can handle most of the coding, most of the reviewing, and most of the analyzing, that structure becomes a bottleneck.

Here's what's happening at companies doing 10x: they've changed their team structure entirely.

What Was Wrong with the Old Structure

Traditional engineering teams are organized by specialization: backend engineers, frontend engineers, DevOps engineers, security engineers. This made sense when each specialty was deep and complex. You needed true experts.

But there's a cost: dependencies. A feature needs backend work, frontend work, and DevOps work. The feature can't move until all three specialties are available. Work gets queued. Context switches happen. Velocity suffers.

Another problem: knowledge silos. Only the DevOps person understands the infrastructure. Only the backend experts understand the architecture. When those people leave or get reassigned, knowledge walks out the door.

And scaling is slow. Want to ship twice as much? Hire twice as many engineers. But hiring is hard. Training is slow. Onboarding takes months.

Consider this real scenario: A mid-cap fintech company with 120 engineers across 8 teams (backend, frontend, mobile, infrastructure, security, data, QA, devrel) wanted to launch a new feature. Timeline estimate: 4 months. Why so long? The feature touched all 8 teams. Each team had a 2-week queue. Dependencies stalled 6 weeks of the project in planning and coordination.

The alternative structure shipped the same feature in 6 weeks with 8 people. Same quality. Zero defects in production. Same people later shipped a second feature in 4 weeks because they kept the team intact.

AI changes all of this.

The New Structure: Cross-Functional Squads with AI Support

Small Outcome-Focused Teams

Instead of organizing by technology (backend team, frontend team), organize by outcome. A squad owns a complete feature or service end-to-end. Five to seven people max.

The squad has all the skills needed: someone who understands the system architecture, someone who can write frontend code, someone who understands DevOps and infrastructure, someone who can lead. And critically: all of them can do any of the work because they have AI assistance.

Why does this work? Because an average engineer with good AI assistance can do 80% of what a specialist could do. And because the squad's shared ownership of the outcome means decisions are made locally, faster, with full context.

AI as the Eighth Member

Every squad has access to Claude or its preferred AI. The AI is available to every engineer on the squad for:

• Code generation and pairing
  - Architecture discussions (the AI has read systems papers, reference implementations, patterns)
  - Security review (the AI knows vulnerability patterns)
  - DevOps troubleshooting (the AI has seen 10,000 similar problems)
  - Documentation (the AI writes it faster than humans)

The AI doesn't make decisions. It makes every engineer on the team smarter.

Reduced Dependencies, Increased Autonomy

Instead of waiting for the infrastructure team, your squad has someone who can handle infrastructure (with AI help). Instead of waiting for security review, your squad has someone who can review security (with AI help).

Decisions that used to require a principal architect's time are now made by the squad with AI input. Not lower quality, the squad is smarter because the AI has read every relevant paper and pattern. Just faster.

Multiple Smaller Teams > One Large Team

Two squads of five people beat one team of ten. Why? Because five people can make decisions and move. Ten people have too many opinions and too much politics. Dependencies multiply. Coordination overhead kills velocity.

With AI-assisted generalists, you can have more smaller teams with fewer dependencies between them. Each team ships independently. Velocity compounds.

Why Smaller Teams Move Faster: Research by Will Larson (Stripe) shows that adding people to a team past 8 members increases coordination overhead by 28% per additional person. A 6-person squad with clear ownership outpaces a 12-person committee every single time. The math is brutal but predictable.

How Team Members' Roles Change

The Generalist Engineer

Previously, "generalist" meant "not good at anything specific." Now, it means "good at multiple things because I have AI assistance."

This engineer can:

• Write backend code (with AI pairing)
  - Understand infrastructure (with AI helping explain complex systems)
  - Fix frontend bugs (with AI showing examples)
  - Troubleshoot production issues (with AI analyzing logs and patterns)

They're not experts at everything. They're competent at everything, because they know how to use AI to level up their capability in any domain.

The Tech Lead as Multiplier

The squad still needs technical leadership. But the leadership role changes. Instead of "solve the hard problems yourself," it becomes "make sure the squad solves problems well."

The tech lead:

• Defines the architecture (with AI input)
  - Reviews designs (with AI having already reviewed for technical soundness)
  - Mentors the team (teaching them how to work effectively with AI)
  - Watches for technical debt accumulation
  - Makes the calls when there are tradeoffs

They're doing higher-leverage work than they used to, because the operational burden (writing code, finding bugs, security review) has been distributed to the squad with AI help.

The Principal Architect as System Designer

You still need principal architects. But they're not doing the same job. They're no longer reviewing every pull request or signing off on every architecture decision.

Instead, they're:

• Designing system-wide patterns and principles
  - Evaluating major technology decisions
  - Mentoring tech leads
  - Thinking years ahead about architecture evolution
  - Making high-stakes tradeoff decisions

They have more leverage because they're not bogged down in implementation details. The squad and AI handle those.

Specialists (Still Exist, But Different)

You still need domain experts in security, infrastructure, and architecture. But they're no longer gatekeepers. They're teachers.

Instead of "security team approves all deployments," it's "security expert teaches the squad how to think about security, then the squad deploys with confidence." The expert reviews design decisions, not every line of code.

When This Goes Wrong: The Autonomy Trap

One common failure mode: teams get autonomous but lose alignment. A squad makes excellent local decisions that conflict with another squad's work. Architecture diverges. Integration points become nightmares.

How to prevent it: Establish 3-5 non-negotiable principles upfront. (Example: "All state changes go through an event stream." "Customer data gets encrypted at rest." "No direct database writes from the application layer.") Let squads implement the details, but enforce the principles through automated checks and quarterly architecture reviews.

Second failure mode: the AI becomes a crutch. Engineers stop thinking. They generate code without understanding it. Security vulnerabilities appear because "the AI said it was fine."

Prevention: Require one engineer per squad to actually understand the architecture decisions. Make that person responsible for reviewing AI outputs. Have them present system design quarterly to the principal architect. Keep humans in the loop for anything security, scaling, or architectural.

Scaling This Model

Start with One Squad

Pick your most capable tech lead. Form a squad of 5-7 people with diverse skills. Give them a clear outcome to own. Have them experiment with this structure for one quarter.

Measure: Are they shipping faster? Is quality better? Are they happier? Do they feel more autonomous?

Document What Works

After the first squad, document the patterns:

• How do they make decisions without a central architecture team?
  - How do they ensure code quality without a centralized code review process?
  - How do they handle security without a security gate?
  - What processes do they have? What rituals?

Replicate and Adapt

Form more squads using the documented model. Each squad will adapt it to their needs. That's fine. The pattern is there, but autonomy is the point.

Watch for Coordination Needs

Multiple squads will occasionally need to coordinate. Have a lightweight sync (weekly, 30 minutes) where squads share what they're shipping and flag dependencies. If dependencies are high, restructure squads to reduce them.

Case Study: SaaS Platform Restructure

A 200-person SaaS company with declining velocity restructured from 14 technology teams to 7 outcome-focused squads. Timeline mattered: they didn't restructure all at once. They created one pilot squad (6 people, owned account management features end-to-end). That squad shipped their next milestone 40% faster than the old structure predicted.

Three months later, they formed three more squads. Then three more. Within a year, all 200 engineers were in outcome-focused squads. Average time to ship a feature dropped from 12 weeks to 5.5 weeks. They didn't hire. They restructured.

The key metric they tracked: cycle time (idea to production). This dropped consistently quarter over quarter. They also tracked deployment frequency. Old structure: 6 deployments per week (organization-wide). New structure: 40+ deployments per week (multiple squads deploying independently).

What they had to fix: First month, there was architectural chaos. Some squads were making decisions in parallel that conflicted. They created an architecture decision log that all squads updated. By month 3, conflicts disappeared. Autonomy increased but alignment stayed high.

The trade-off: This structure requires more deliberate coordination. The old structure had central control (slow but consistent). The new structure has distributed autonomy (fast but requires discipline to align).

The Scaling Problem Teams Miss: You can't add people linearly and expect output to increase linearly. At some point, coordination overhead kills velocity. The best organizations understand this and structure to minimize dependencies, not just add more people. More importantly: most teams are structured wrong. They optimize for input (people, hours) when they should optimize for output (shipped features, cycle time).

What to Do Monday Morning

• Map your current team structure (who does what?)
  - Identify one outcome (feature or service) that touches multiple teams/specialties
  - Propose forming a small cross-functional squad to own that outcome
  - Give that squad permission to make decisions locally (with input from experts, but not blocked by them)
  - Measure: velocity, quality, team satisfaction after 3 months

FAQ

Q: Won't specialists become irrelevant?

A: No, they become more valuable. Instead of spending time on routine reviews and approvals, they spend time on deep problems and mentorship. That's more interesting work, and frankly, more important. One principal architect we spoke with actually preferred the new model: "I spend my time on problems that matter, should we move to a microservices architecture? How do we scale the database? instead of being a bottleneck approving pull requests."

Q: What if a squad makes a bad architecture decision?

A: Then you learn, and you correct it. The cost of a bad decision made fast is lower than the cost of a good decision made slowly after months of review. Most bad decisions are also more fixable than you think. The fintech example above had one squad choose a technology stack that didn't work out. Cost to pivot: 2 weeks and 40 engineering hours. If they'd waited for approval from 5 committees, the project would have been delayed 6 months.

Q: How do we maintain consistency across squads?

A: Through shared principles and guidelines, not through review gates. Document your architecture principles. Have experts review designs (not implementations). Create shared code libraries. Establish conventions. Trust the squads to follow them. Make it concrete: "All services expose a health check endpoint at /health that returns JSON." Not "services should be observable", that's too vague.

Q: What's the maximum number of squads before coordination becomes a problem?

A: Depends on interdependencies. If your services are decoupled, you can have many. If they're tightly coupled, fewer. The goal is to structure services so each squad is as independent as possible. The SaaS example had 7 squads working effectively. At 12+ squads, you'll need a "platform team" that manages shared infrastructure and helps squads avoid redoing work.

Q: How does this affect hiring? (This is the hardest part, by the way.)

A: You're looking for people who are curious and adaptable, not specialists. You're looking for people who can work with AI, not people who need to be the expert. Onboarding looks different too, less "become a specialist" and more "understand the system and learn how to use your tools." This is actually a bigger change than the structure itself. Hiring profiles, interview questions, onboarding programs, all of it has to change. More on this in the hiring lesson.

Q: What if a squad has conflicts or isn't shipping?

A: This points to a deeper problem (bad team composition, unclear outcome, or leadership issues). Don't fix it by adding more process or oversight. Fix it by addressing the root cause. If it's a team fit issue, make a change. If the outcome is vague, clarify it. If the tech lead isn't leading well, coach them or replace them. Bad squads are a signal. Don't ignore it.

Q: Won't distributed autonomy lead to chaos and inconsistent code?

A: It can, if you're not deliberate. That's why shared architecture principles and guidelines matter. But here's the counterintuitive insight: centrally reviewed code isn't necessarily better code. It's slower code. Code that was reviewed by an architect who doesn't understand the context. The real solution: have squads document their architectural decisions, use shared code libraries for common patterns, and have one expert per squad who's responsible for understanding the big picture. Chaos happens when there's zero coordination. Bottlenecks happen when there's too much. Find the middle ground.

Q: How do we prevent the formation of fiefdoms where squads work against each other?

A: Shared metrics. If squad performance is measured on "shipped features" but squads benefit from blocking each other (to reduce competition for resources), you'll get that behavior. Instead, measure organizational outcomes: "How fast can we ship new capabilities? How happy are customers? How healthy is the system?" Squads that sabotage each other hurt the organization's metrics. Make squads explicitly accountable for cross-squad health. One team that did this: they tracked "integration cost" (how many hours of work are needed to integrate between squads). If one squad's design choice made integration expensive, they paid the cost by reducing their own capacity. Perverse incentives align fast when there's transparency.

Q: Can smaller squads handle production incidents?

A: Absolutely. In fact, they handle them better. A 6-person squad owns their service end-to-end, so they know it cold. They can diagnose issues faster than a 20-person operation where no one person understands the full context. The on-call burden is also lower, with fewer people per squad, rotation is shorter. You need to make sure squads have the skills to handle incidents (some infrastructure knowledge, some debugging capability). AI helps here, an on-call engineer can use AI to help diagnose, escalate appropriately, and learn from incidents. But the squad needs to be the first responder, not a specialist team.

Q: What about long-term platform evolution and technical debt?

A: This is where you need a "platform team" (usually 2-3 people, or one person at smaller companies). Their job is to think about long-term evolution of the system, shared infrastructure, and reducing technical debt. They're not a gatekeeper. They're an enabler. They work with squads to pay down debt gradually, evangelize new patterns, and provide shared infrastructure that multiplies squad velocity. At the SaaS company: after three squads, they created a platform team of two people. The platform team didn't slow anyone down. They made everyone faster by providing shared libraries and solving infrastructure problems once instead of each squad solving them independently.

The new org structure isn't bigger teams with AI. It's smaller, autonomous teams where everyone is smarter because of AI. Dependencies drop. Velocity increases. Autonomy improves. People are happier. That's the 10x lever.

On This Page

Watch the Lecture
What Was Wrong with the Old
The New Structure
How Team Members' Roles Change
Scaling This Model
What to Do Monday Morning
FAQ

Chapter Details

Part ofChapter 2