Beyond Squads: The Emerging Engineering Model for the Age of AI

The asymmetry problem

#

For two weeks in 2025, three senior engineers at a mid-market SaaS company executed a rewrite of the payment reconciliation service using Claude Code. What should have taken six weeks took ten days. They shipped cleaner code than anyone expected. They felt genuinely fast.

Then they merged.

The code sat in code review for five days while the team lead processed the diff. QA needed three days to design integration tests; the security review took another two. Two of the three engineers had already rotated back to their regular squad work, so institutional memory evaporated the moment the first production issue hit. When the reconciliation service broke at 2 a.m. three weeks later, none of the original three were on call — the incident response team had to reverse-engineer the decisions nobody had written down.

This is not a story about bad engineering. This is a story about what happens when individual velocity (10 days) collides with system throughput (20+ days because the rest of the pipeline is tuned for human-paced work). The engineers were not burning out from writing too much code. They were burning out from the friction of pushing AI-augmented output through infrastructure designed for the pre-AI era.

Google’s 2024 DORA report quantified the paradox: engineers using AI tools had higher individual productivity and better time-in-flow, but their teams shipped slower — a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability ¹. A 2025 randomized controlled trial by METR found that experienced developers using AI were 19% slower on real-world tasks while believing they were 20% faster — a roughly 40-point perception gap ². This is not because AI makes people worse. It is because the system around AI is not built for the speed it enables.

The question, then, is not “are squads dead?” Squads were engineered for a set of constraints that no longer fully apply. The question is: what happens to team design when you decouple individual velocity from team shape?

The squad was built for a different problem

#

Before the answer, the history.

The “squad” — a persistent, cross-functional team that ships a part of the product — is documented in textbooks, implemented in Spotify whitepapers, and crystallized in Team Topologies because it was a sensible answer to real constraints.

Fred Brooks’s 1975 The Mythical Man-Month showed that communication paths scale as n(n−1)/2 ³. Robin Dunbar’s work on primate group size suggested cognitive limits for high-trust collaboration in the 5–15 range ⁴. Tuckman’s forming-storming-norming-performing sequence showed that teams need time to jell ⁵. Spotify’s 2012 squad model and Team Topologies’s formalization in 2019 took these constraints seriously and built containers around them — persistent teams, limited size, clear accountability ⁶⁷.

The model worked. For the problem it was designed to solve.

That problem was: how do you ship features at a human pace (10 engineers writing 50 lines per day each) when you have hundreds of engineers and communication overhead? Answer: organize them into persistent squads, add ceremony to align the squads, accept that big redesigns take months because the squad has to coordinate across the org.

But two things have changed. First, the industry’s favorite example of the model has its own honest retrospective. Jeremiah Lee, a former Spotify engineer, wrote in 2020 that the squad model was “only ever aspirational and never fully implemented,” a point the model’s co-author Anders Ivarsson quietly conceded ⁸. The squads-to-tribes-to-chapters layer they designed added complexity without solving the coordination problem. Spotify internally moved away from “squad” terminology around 2017, toward clearer mission-driven language ⁹.

Second, AI has measurably changed the rate of code production. GitHub’s Copilot study showed 55.8% speed gains on individual tasks ¹⁰. Stack Overflow’s 2024 survey found 82% of AI users apply it to code writing, and adoption went from 70% to 76% year-over-year ¹¹. Claude Code reached 18% adoption in eight months after launch ¹². The velocity is real and replicated.

This velocity creates a problem the squad model was never built to handle: the coordination tax has become the binding constraint. When an engineer can produce a week’s code in an afternoon, the slow parts of the pipeline — product planning cycles, specialized QA handoffs, security reviews, knowledge transfer, on-call context — become visible. They were always expensive. AI just made them expensive relative to the work itself.

The honest version of this story is not “squads are bad.” It is “squads were designed for a constraint that has shifted, and the industry is beginning to notice.”

The solution already exists — consulting firms have run it for fifty years

#

The most useful place to look for answers is not within software engineering. It is in industries that have been running project-based, time-bound team models at scale for decades.

Consulting firms staff engagements by pulling people from home practices, assembling them around a mission for a defined duration, and rotating them back. McKinsey calls it the “Development Group Leader” (DGL) + “professional development manager” (PDM) model ¹³. BCG uses a “Career Development Advisor” paired with “Principal Career Advocates.” Accenture scaled it to hundreds of thousands of people ¹⁴¹⁵. It is not perfect, but it is battle-tested.

The core insight is deceptively simple: the person who evaluates a specific piece of work must be different from the person who owns a person’s long-term career. When you collapse these two roles, you create incentives that destroy rotation models. Your engagement lead wants you on their project; your career manager wants you developing breadth. In consulting, these are separate roles whose incentives align toward your growth.

The operational specifics:

At project end, the engagement lead (equivalent to a strike-team lead) answers four questions, adapted from Deloitte’s Buckingham-Goodall research ¹⁶:

1. Given what I know, would I always want this person on my team?
2. Would I give this person the highest possible compensation increase?
3. Is this person at risk of low performance?
4. Is this person ready for promotion today?

Critically: these are intent questions, not abstract judgments. The lead is not estimating the person’s “performance rating.” They are reporting what they would do — which is a much more reliable signal ¹⁷.

Between projects, the PDM (professional development manager) aggregates these snapshots across all projects the person has touched into a 6-month or annual view. The PDM owns compensation and promotion decisions. This is where the person’s growth trajectory lives. The PDM is usually a senior member of the person’s home practice or a dedicated career coach.

Compensation is decoupled from any single project outcome. A person might have a difficult engagement, receive honest feedback (“I’d want better clarity from them next time”), and see no hit to their compensation. The annual or semi-annual aggregation is where compensation moves.

Home practices are not parking lots. A person’s home practice is where they specialize, accumulate deep context, and mentor incoming people. It is explicitly a platform for others’ rotations, not a holding pattern between engagements.

This model works at scale. McKinsey runs it across thousands of consultants. Accenture runs it across hundreds of thousands. The reason it works is because it separates concerns: evaluation stays local to the project; career ownership stays with the home practice; feedback is granular and fresh; career decisions are aggregated and long-term.

Software engineering has never had to solve this problem before because most engineers stayed in persistent squads. The moment you move to time-bound work, you need consulting’s answer. And the evidence suggests the industry is moving that direction, whether intentionally or accidentally.

Real examples: How software engineering is adapting

#

The consulting model is the template. Here is how it is showing up in practice.

Amazon’s Single-Threaded Leader

#

Amazon replaced the “two-pizza team” with the “single-threaded leader” (STL) model explicitly because team size was not the constraint — ownership clarity was. From Colin Bryar and Bill Carr’s Working Backwards (2021) ¹⁸: an STL is pulled from their usual position and given complete P&L-style accountability for one outcome. Their only job is that one mission. Everyone who works on the mission reports through them for the duration, even if those people report elsewhere in the org chart in their “normal” state.

When the mission is done — “Prime Video integration complete,” “new AWS service launched,” “infrastructure migrated” — the STL returns to their usual position, often with a promotion and with their team dissolved. The model is explicit: this is temporary. An STL assignment lasts 12–24 months. Amazon treats successful STL execution as the most reliable path to L7/L8 promotion, which creates a clear incentive to volunteer.

The parallel: the STL is the mission lead in the consulting model, not the PDM. What Amazon has not formalized publicly (though Blind and ex-Amazon reports suggest it exists) is the PDM equivalent — the person who aggregates feedback across multiple STL assignments and owns a person’s career trajectory.

Basecamp’s Shape Up

#

Basecamp published “Shape Up” (https://basecamp.com/shapeup), the clearest, most operational writeup of a rotation model in tech. Six-week cycles. A “pitch” describes a problem loosely (no detailed spec). A small team (3–5 people) volunteers for the mission. They have six weeks and a fixed scope. At the end, the team dissolves, and people go back to their “cool-down” phase (roughly two weeks) where they work on small fixes, mentoring, and planning.

The cycle is explicit and repeating. It is not “shape up projects until they feel done.” It is six weeks, period. This clarity is why the model works at scale — Basecamp has been running it for more than a decade.

The parallel: this is the best-documented software example of separating “mission pace” from “home pace.” The cool-down is the PDM equivalent — explicitly not another mission, explicitly space for reflection and mentorship.

GitLab Working Groups

#

GitLab publishes its handbook publicly. Working groups are explicitly time-bounded, cross-functional, and dissolve at a predefined end condition ¹⁹. Every working group has:

• A Directly Responsible Individual (DRI)
• A charter with scope and success criteria
• A defined end date
• A transition plan for when the mission is complete

What makes this interesting: GitLab is fully remote and distributed. Persistence is not a property of the team; it is a property of the mission’s completion. Working groups regularly overlap; people can be on 2–3 simultaneously. The public handbook makes the model transparent and repeatable.

Google SRE Rotation

#

The SRE book describes explicit rotation between SRE teams and product teams, with SREs expected to return to product after 2 years and product engineers embedded in SRE for 6–12 months ²⁰. This is the most documented rotation model within a single company.

What works: the return is planned before the rotation starts. You are not rotating “until we need you back.” You are rotating “until month 18, at which point you take on this project.” The clarity prevents the “permanent temporary” trap.

Microsoft V-teams

#

Microsoft used “virtual teams” (V-teams) for cross-cutting initiatives like Teams, the Microsoft Graph, and Azure-Office convergence. The person reports to their home org manager for career purposes but executes the mission under a V-team lead. A V-team lead provides feedback at the mission’s end; the home org manager owns the career decision.

This is closest to the consulting DGL/PDM split within a single company. Public documentation is thin (most references are blog posts and memoir), but the model has been in production at Microsoft for at least two decades.

The strike-team + guardian model: How to adapt it for software engineering

#

The consulting model and these real examples converge on a shape that is emerging in software engineering. It is not a permanent split into two tiers. It is a rotation between two states.

The two layers

#

Guardians — the permanent base layer — own the integrity of the system over time:

• The platform (infrastructure, shared services, foundational libraries)
• The design system and architectural standards
• The regression suite, security review, and deployment guardrails
• The institutional memory of why decisions were made
• Mentorship of incoming engineers

Guardians are not a “platform team” in the TDD sense, though they often overlap. Guardians are the people who stay. They accumulate context. They say “no” when an output does not meet standards. They own the long-term health of the codebase.

Strike teams — temporary, mission-focused clusters — supply intensity and velocity:

• A small group (3–7 engineers depending on scope) pulled from guardian responsibilities
• Assembled around a time-bounded mission (6 weeks to 6 months, depending on scope)
• Heavily augmented by agentic tools and given permission to move fast
• Explicitly designed to dissolve when the mission is complete
• Output goes through guardian guardrails (CI, contract tests, security review) before merging

The strike team is not a separate career ladder. A strike team member is “on loan” from their guardian base. When the mission ends, they return. The strike team is the interesting assignment, not the interesting role.

How it works in practice

#

Formation. A time-bounded problem arrives: rewrite the auth service, launch the new dashboard, migrate the database. A strike-team lead (DRI) is identified — someone with enough seniority and clarity of vision to hold the mission together. 3–7 engineers volunteer or are asked to “rotate” for the duration. The mission has a clear completion criteria (“shipped and stable” not “feels done”). A cooldown period is scheduled for after the mission (roughly 1–2 weeks).

During the mission. The strike team is co-located (same Slack channel, same daily standup, same planning process) and explicitly absolved of most guardian-layer work. They are not on-call for unrelated systems. They are not expected to review pull requests outside the mission. They are running a short sprint at high intensity, exactly the condition where agentic tools are most valuable.

The output is not merge-ready just because it ships. Every change has to pass through the guardian layer’s guardrails: the CI/CD pipeline, the regression suite, the security review. This is non-negotiable. It ensures strike teams cannot ship fragile code, even under time pressure.

Dissolution. When the mission is complete and the code is stable in production (usually 2–4 weeks after merge), the strike team explicitly dissolves. This is a deliberate action, not something that happens passively. The team has a retrospective. What did we learn? What should stay? What should we document? Then people rotate back.

Return and cooldown. Each strike team member has a planned return assignment before they rotate back — it is not “we’ll figure it out.” Return assignments might be: mentoring a new engineer, platform work on a planned improvement, preparing for the next mission, or going back to a regular squad rotation. The cooldown period (the first 1–2 weeks) is explicitly not another mission; it is space for ramp-down, knowledge transfer, and recalibration.

Knowledge transfer (the forcing function). The team that will be on-call for the strike team’s output is in the room during the last two weeks of the mission. They pair on the code, ask questions, and understand the decisions. This is the only knowledge-transfer practice that consistently works (based on Google SRE and Amazon retrospectives). Video recordings, wiki dumps, and “ask me anything” Slacks go stale within weeks.

Who does this work for?

#

Strike teams are most effective for:

• Time-bounded, mission-critical work (infrastructure rewrites, major feature launches, compliance migrations)
• Problems that require intensity but not indefinite continuity
• Teams of 30+ engineers (below that, coordination overhead isn’t the binding constraint)
• Product models where intense bursts can be tolerated (6-week squads or longer cycles, not continuous iteration)
• Orgs with a strong platform/guardian layer to pass output through

Strike teams are not effective for:

• Continuous iteration (weekly releases of small features)
• Highly specialized work that requires 6+ months to depth
• Organizations smaller than 15–20 engineers
• Organizations without a strong, stable platform layer to guard standards
• Work where the engineer needs months to even understand the problem

When to use this model: A decision framework

#

Here is how a CTO or engineering leader should think about whether to introduce rotation.

Ask these questions:

#

1. Do you have a stability problem? Run this diagnostic: Measure the time from “engineer completes code locally” to “code is in production and stable.” If it is more than 2 weeks for your typical change, you have a coordination tax problem. AI will make this worse before it makes it better. Strike teams only make sense if this is the binding constraint.

2. Do you have a platform layer? A platform layer does not mean “a platform team.” It means: do you have shared infrastructure, design systems, security practices, and regression suites that all code has to flow through? If the answer is “kind of” or “we’re working on it,” do not use rotation yet. Build the platform first. Strike teams need guardrails.

3. Are you losing context to velocity? Are you shipping code that looks correct for 2 weeks and then breaks? Are your on-call engineers confused about “why did they make that choice?” If this is not happening yet, you may not have the problem rotation solves. Wait.

4. How big is the org? Below 15–20 engineers, persistent teams are fine; coordination overhead is small. From 20–50, rotation starts to make sense. Above 50, rotation is probably unavoidable if you want to move fast. (This is not a hard rule, but it is a reasonable heuristic based on the companies documented above.)

5. What is your product model? If you ship features weekly in small batches and iterate continuously, rotation adds overhead. If you ship major features quarterly or work in 6-week cycles, rotation fits naturally. The worse your situation is, the more you should think about Basecamp’s Shape Up model specifically.

If the answer to 1–3 is “yes” and you’re in the size/model range of 4–5, you are ready to pilot strike teams.

#

If the answer to 1–3 is “no,” build your platform first.

#

How to implement: The operational details

#

Assuming you have decided rotation makes sense, here is what actually has to happen.

Phase 1: Build the guardian layer

#

Do this first. Before you run any strike teams, you need:

• A CI/CD pipeline that can catch integration issues
• Automated tests covering the code paths that matter (not 100% coverage, but the critical ones)
• A security review process that actually works (PR template, checklist, someone accountable)
• A regression testing suite (automated or manual, depending on the product)
• An on-call rotation with clear playbooks

If you do not have these, strike teams will ship fast and unstable. The guardians are the insurance policy.

Phase 2: Identify your first mission

#

Choose something real but bounded:

• A migration (infrastructure, database, authentication) — these are natural strikes because they have a clear end state
• A new subsystem (payments, analytics, reporting) — discrete and measurable
• Avoid: “improve code quality,” “modernize the frontend,” “we’ll see where it goes”

Clear scope is the most important variable.

Phase 3: Choose the strike-team lead (DRI)

#

This person is the mission lead. They hold the whole problem in their head. They are not necessarily the most senior engineer (though they often are). They are the person who:

• Can say “no, that is out of scope”
• Can make rapid tradeoff decisions without consensus
• Will be held accountable for “shipped and stable,” not just “shipped”
• Has enough standing that other engineers respect their decisions

Phase 4: Run a formation conversation

#

The DRI, the engineering leader, and the strike-team members sit down and agree:

• What does “done” look like? (Be specific: “shipped and stable for 4 weeks,” not “feels good”)
• How long is the mission? (6 weeks, 3 months, etc.)
• What is in scope? What is explicitly out of scope?
• When do people return to their home bases? (Schedule this now)
• Who will be the on-call partner during the knowledge-transfer phase? (Schedule this now)

Write this down. Share it. Refer to it constantly.

Phase 5: Run the mission

#

• The strike team is co-located (same Slack, same standup, same planning, whatever “co-located” means in your context).
• They are absolved of guardian-layer work (no on-call, no “can you review this,” no interrupts).
• Output goes through the guardian layer’s guardrails before merging.
• Decisions are made by the DRI, not by consensus.

The guardrails are the key. A strike team under time pressure will take shortcuts. The guardrails prevent those shortcuts from becoming permanent debt. A strike team will thank you later.

Phase 6: Dissolution and knowledge transfer (the hardest part)

#

When the mission ships and stabilizes (2–4 weeks in production), do a retrospective. Capture:

• What decisions did we make and why?
• What surprised us?
• What should stay? What should we change?
• Where is the architectural memory — the decisions that will matter in a year?

Write a post-mortem, or a design doc, or a recorded walkthrough. Do not assume video recordings will be watched; assume they will not. The forcing function is: the on-call engineer has to be in the room for the last two weeks. They pair on code, ask questions, and understand the decisions. That is non-negotiable.

Then the strike team dissolves. People go back to their home bases (with cooldown assignments pre-planned). The mission exits.

Phase 7: Return assignments

#

Before anyone rotates back, they have a planned assignment. This can be:

• Platform work (the home base has a backlog of improvements that were deferred while people rotated out)
• Mentoring (a new engineer joining, or an engineer ramping on a critical system)
• Preparation for the next mission (planning, learning a new system, etc.)
• Regular squad work if the rotation was short

The point: there is no “floating pool” of engineers. When you rotate back, you have something to do.

Performance management in a rotation model

#

This is where most orgs get stuck. If engineers rotate through short-term missions, how do you review their performance?

The consulting answer is proven: separate the person who evaluates the work from the person who owns the career.

At mission end

#

The strike-team lead answers the Deloitte snapshot questions:

1. Given what I know, would I always want this person on my team?
2. Would I give this person the highest possible compensation increase?
3. Is this person at risk of low performance?
4. Is this person ready for promotion today?

These are not abstract ratings. They are specific to the mission. The lead is not saying “this person is a 3/5 performer.” They are saying “yes, I would hire them again” or “they struggled with X, I’d want to see them develop it.”

Between missions

#

A home-base manager (DRI of the guardian platform or a designated development manager) aggregates feedback across all missions a person has touched. This happens every 6 months or annually, depending on your cycle.

The manager considers:

• How many missions has this person rotated through? (More than 4–5 per year is often a burnout warning)
• What feedback did they get from strike-team leads?
• What feedback did they get from specialists they worked with?
• What is their trend over time? (Getting stronger? Burning out?)
• Are they ready for the next career move?

This is where compensation decisions happen. A person might have a difficult strike team (“I’d want better clarity from them next time”) and see no hit to compensation. The feedback is specific to that context. The aggregation over time is where career decisions move.

What changes

#

This model requires three breaks from traditional software engineering practice:

First: Decouple individual compensation from project outcome. A strike team might fail to ship, or ship to production and then hit a serious bug. The engineers should not be penalized. The outcome was constrained by scope, dependencies, unknowns — many things outside their control. Evaluate effort, learning, and decision-making, not outcome alone.

Second: Retire output-based metrics. “PR throughput,” “lines of code,” “issues resolved per quarter” — these were always noisy metrics, and AI has made them meaningless. The METR study that found developers 19% slower while feeling 20% faster proves the point: volume metrics measure nothing you care about.

Third: Shift the signal to architectural impact. What does this person’s work enable for the team? Did they reduce future cost? Unlock a blocked decision? Raise the floor of the system? Did they do it with clarity about tradeoffs, or by cutting corners? Promotion decisions should be about this, not output volume.

The honest hard part: Home-base belonging

#

The deepest risk in a rotation model is psychological. If you are on a strike team 8 months a year and back at your “home base” for 4, is your home base real? Or is it a parking lot?

This is why the consulting model works: the home practice is not a parking lot. It is where you specialize, where you mentor, where you accumulate deep context. A senior backend specialist at McKinsey does not go to their home practice to “wait for the next engagement.” They go to develop expertise, mentor associates, and build the practice’s differentiation.

In software, this means your guardian platform (or home practice) has to own something that matters and is worth doing. It is not enough to say “when you are not on strike teams, do platform work.” You have to have real platform work. Security improvements, architectural clarity, design-system maturity, mentorship, incident prevention — all are real and valuable. If your org has never valued these things, rotation will not fix it. You will just have two tiers, with one obviously lower-status.

This is cultural work, not structural work. It is the part that takes the most deliberate thought.

What can break — and how to prevent it

#

Every real example has failure modes. Here are the ones documented across all the cases.

1. “Permanent temporary” teams

#

The failure: A strike team ships the thing. Then it stays. Because the problem was not fully solved, or because there was nobody else to own it, or because the political cost of dissolving is high. Two years later, it is still called a “strike team” but it is a squad with a different name, and the people have all built their identity around it.

Why it matters: If strike teams don’t dissolve, there is no rotation. Engineers stay on the strike team forever, the guardian base atrophies, and you are back to squads with all their original problems.

How to prevent it: Make dissolution the default, not the exception. Build the dissolve decision into the formation process. “This team ends on date X unless the DRI and the engineering leader explicitly re-charter it.” When the time comes, dissolve, even if it is awkward. The first time is hard. The second time is normal.

2. Knowledge loss at transition

#

The failure: The strike team ships, the engineers rotate back to the guardian base, and 6 weeks later a production issue hits. Nobody on call knows why they chose that API design. Nobody knows what the performance implications were. They reverse-engineer the code and ship a fix that undoes a careful tradeoff. Repeat 3 times and the codebase is a mess.

Why it matters: This turns fast shipping into fast shipping + slow accumulation of debt. You do not save time; you just move it to the future.

How to prevent it: On-call engineers in the room for the last two weeks. Pair on the code. Ask questions. Understand the decisions. Do not assume you will watch a video later; you will not. The forcing function is synchronous presence.

3. Identity fracturing

#

The failure: Engineers want to be on strike teams because they are high-status. Guardian-layer work becomes a dumping ground. The org splits into “interesting people” and “platform people.” Talented engineers leave because they do not want to be on the platform team.

Why it matters: Strike teams only work if you have a strong platform to pass output through. If the platform is understaffed and demoralized, it will not enforce standards. Code will be unstable.

How to prevent it: Make guardian-layer work explicitly prestigious. Specialist roles (a deep distributed systems expert, a security architect, a performance specialist) should be visibly on the career ladder. Promotions should go to people who raise the floor of the system, not just people who shipped the coolest feature. Pay has to reflect this. The org has to say “platform work is the most important work” and mean it. If you don’t believe this, don’t use rotation.

4. Burnout on high-demand people

#

The failure: Three engineers are great on strike teams. They have high execution velocity, clear thinking, and strong judgment. So they are loaned out for the next strike team. And the next. Within a year, they have cycled through four missions, they don’t have a “home” anymore, and they are burnt out and looking for jobs.

Why it matters: This is the most reliable way to lose your best people.

How to prevent it: Set a hard cap: no engineer on more than 3–4 strike-team rotations per year. After 3 rotations, the person gets a long home-base assignment (3+ months). Force this at the organizational level; individual managers will always rationalize “just one more.” The consulting firms have data showing this threshold; software engineering does not, but the pattern is consistent.

5. Spec drift and lost product continuity

#

The failure: Strike teams are tactical: ship the dashboard, ship the migration, ship the feature. But if product vision is distributed across multiple strike teams, the product stops being a coherent whole. It becomes a pile of locally-optimized decisions. Feature velocity goes up, product velocity goes down.

Why it matters: You ship faster but you ship in the wrong direction.

How to prevent it: Product continuity has to live somewhere persistent. A product manager, a platform roadmap, a set of explicitly-owned design principles — something that is not ephemeral. This is separate from the guardian layer, but it is the same insight: some things have to stay put.

6. Strike team output rejected by guardians

#

The failure: Strike teams ship fast, and guardians are supposed to validate the output. But guardians disagree with the tradeoffs, or they want bigger refactors, or they say “this doesn’t fit our architecture.” The code sits in review for weeks. Engineers on the strike team get frustrated (“we were supposed to move fast”) and push back. Either the code is forced through (stability problems later) or the code is rebuilt (velocity gained is lost).

Why it matters: This is the governance problem. If it is not solved, the model breaks.

How to prevent it: Guardians make architectural decisions before the strike team launches, not after. Here is the platform you are building on. Here are the standards. Build within these. When the strike team is formed, do a “runway walkthrough” where the DRI and the guardians align on the approach. Not a 20-page spec; 30 minutes of conversation. “Here is what we are building. Do you see any showstoppers?” By the time the code is written, the big decisions are made. Guardians are checking consistency, not re-doing architecture.

The cultural shift: Belonging without permanence

#

The hardest part of this transition is not the engineering. It is the cultural shift: learning that your home can be stable even when your assignment is fluid.

This requires clarity about what “home” means. In the consulting model, home is your practice — the specialty you are deepening, the people you mentor, the values you hold. In Amazon, home is your management chain and your career community. In Basecamp, home is the company and the broader product vision.

The key insight is that stability of reporting line and stability of assignment are different things. Your manager can stay the same even though your assignments rotate. Your community can stay the same even though your projects change. Your career development can be continuous even though your work is episodic.

This sounds obvious in theory. It is hard in practice because most of software engineering has conflated these things. “My team” and “my reporting line” and “my project” have been the same thing, and people’s sense of belonging has been built on that conflation.

When you introduce rotation, you have to actively rebuild belonging around the persistent parts: the practice, the manager, the community, the career trajectory. This takes deliberate cultural work.

Here is what that looks like:

• Home-base rituals: Monthly lunches for your practice, weekly 1:1s with your manager, quarterly career conversations. These continue even when people are on strike teams.
• Clear career narrative: Engineers should be able to see, without ambiguity, how a series of strike-team rotations and home-base work adds up to a career. The promotion story should make sense.
• Specialist tracks: Deep expertise paths (architect, specialist, principal engineer) that do not require leadership or constant rotation. Some people are happiest on the platform; that is fine.
• Mentorship as valued work: When someone rotates to a home base, part of their assignment is mentoring. Onboarding a new engineer, ramping someone on a complex system — this is real work. It shows up in evaluations.
• Transparent communication: “Strike teams are temporary. You will come back. We value platform work. You can build a career here without staying on one team forever.” Say it plainly and repeatedly, especially when onboarding.

Without this cultural work, rotation becomes a caste system. Avoid this trap.

What we do not know yet — honest gaps in the evidence

#

Before closing, it is worth being clear about what is not known. The consulting model is proven, but software engineering is applying it in new contexts with new tooling. There are genuine unknowns.

1. Burnout in rotation at software engineering scale

#

Consulting firms have published data showing that more than 3–4 projects per year correlates with higher attrition. Software engineering has no equivalent study. AI-augmented work might change this calculus (faster rotations possible?) or make it worse (perceived productivity ≠ actual productivity, per METR). We do not know.

2. Compensation for strike-team vs. home-base work

#

McKinsey, BCG, and Accenture have standardized compensation formulas for consultants. Software engineering has not formalized how to value a person who rotates high-impact strike teams vs. a person who deeply specializes in platform work. The honest answer is that most orgs are inventing this, with mixed results.

3. What happens when strike teams fail

#

The public literature is almost entirely about successful rotations. What happens when a strike team’s mission gets cancelled, or ships but is unstable, or is late? How does that affect the engineers’ careers? How does it affect their willingness to rotate again? These are real risks that are almost completely undocumented in software.

4. AI tooling assumptions

#

The argument for strike teams in the AI era depends partly on assumptions about AI tooling (context windows, coordination overhead, code review bottlenecks) that might shift. If context windows get bigger, or new coordination tools emerge, the pressure to rotate might ease. If AI-generated code proves to be more fragile than expected, the pressure might intensify. We are guessing about the next 18 months based on 2025 data.

5. Product models with continuous iteration

#

The documented examples (Basecamp Shape Up, Spotify squads, Amazon STL) all work in contexts where intense bursts are acceptable. Most consumer software ships weekly, sometimes daily. It is unclear whether rotation works well for this model, or whether it introduces unacceptable coordination overhead.

These gaps are not show-stoppers. They are reasons to be humble and to measure carefully as you implement. Do not assume consulting firms’ experience transfers perfectly. Watch what happens in your org.

Closing: The decision is cultural, not structural

#

The squad was not a mistake. It solved the right problem at the right time. What is changing is that the problem has shifted. AI has decoupled individual velocity from team shape. The coordination tax is now the binding constraint, and the industry is beginning to notice.

The solution is not new. Consulting firms have run it for decades. The consulting model — separating evaluation from career ownership, using project snapshots and home-base aggregation, making platform work prestigious — is the mature design.

What is novel is applying it to software engineering, where most people have never had to think about career development across multiple short-term projects. This requires cultural work, not just structural work. It requires clarity about what permanence means when your assignments are temporary.

The engineering part is straightforward. Build a strong platform layer. Run clear, time-bounded missions. Dissolve teams when the mission ends. Force on-call knowledge transfer. Check output against standards before it goes to production.

The cultural part is harder. It requires consciously building belonging around the persistent parts of the organization — the practice, the manager, the community — while letting assignments be fluid. It requires making platform work prestigious. It requires being honest about the rhythm of work (intense bursts and quiet periods) instead of pretending everything is steady-state.

If you can do both, the results are measurable: faster shipping on mission-critical work, stronger platform stability, and fewer fires at 2 a.m. because decisions are documented and on-call engineers understand them.

The question is not “are squads dead?” The question is “do you have a problem that rotation solves?” If the answer is yes, the model is ready. If the answer is no, the squad is still the right answer.

Sources

#