Before You Adopt AI, Reorganize Your Teams Around Value Streams

Before you bring AI into your company, there is one move that pays off more than any tool or model you might pick: reorganize your technical teams around value streams. I’ve watched too many enterprises buy the tools, deploy the models, train the people — and delivery still drags, while the team comes out more exhausted than before. The root cause is almost never weak AI. It’s that the teams are sliced along technical layers — frontend, backend, algorithms, ops, security. A single end-to-end feature has to cross four or five teams, and every handoff bleeds. The requirement loses a little. The context loses a little. The sense of ownership loses a little. Get the team boundaries right, and AI has something to amplify. Get them wrong, and AI just accelerates the debt piled on a broken structure.

This article lays out an organizational design method you can actually use — Team Topologies (Skelton & Pais, 2019). Three ideas sit at its core: slice teams along value streams, watch the cognitive load on every team, and run internal platforms as products. I’ll unpack it through a real manufacturing scenario.

A manufacturing CIO (anonymized from a real project) told me this: rolling out an AI-powered quality-inspection feature wasn’t technically hard. Cameras detect defects, the model is off-the-shelf. The hard part was delivery. The frontend team built the UI, the MES team reworked the work-order flow, the algorithm team deployed the model, the ops team ran the servers, and the security team had to review it on top of everything. One feature, 5 teams, 4 formal handoffs, 3 months of drag. Nobody was slacking. Every handoff just dropped something on the floor.

1. Conway’s Law Only Tells Half the Story

Conway’s Law says: a system’s architecture mirrors the communication structure of the team that builds it. Split your teams into frontend and backend, and you’ll get a frontend-backend split system. However the team communicates is how the system grows. Empirical evidence has borne this out again and again.

But Conway only told us this happens. He didn’t tell us how to design teams so that a good architecture grows on its own. Skelton and Pais closed that gap with Team Topologies (2019): four basic team types, three interaction modes, and one principle threaded through all of it — watch cognitive load.

2. The Four Team Types: Options for a Reorg, Not Terms to Memorize

I’ll walk through these four types as options you can reach for during a reorg. You don’t need to memorize definitions.

Stream-aligned teams — the workhorse of your organization, and the overwhelming majority of them. (The book says “most,” with no fixed ratio.) A “stream” is a continuous flow of value. A stream-aligned team owns a stretch of that flow end to end — understanding the requirement, building it, shipping it, running it. One test tells you whether a team qualifies: can it get value into a user’s hands without depending on another team? Back to that CIO: if his smart-inspection feature had belonged to a single “inspection stream team” — with people who know frontend, MES integration, algorithm deployment, and ops all in one team — the feature ships with zero handoffs. That’s the shape it should have.

The most common problem in large enterprises is that the system runs end to end while the teams are sliced into horizontal technical layers. Every end-to-end delivery has to thread through the reporting boundaries of multiple teams. The pattern holds across industries, even if the names change. In finance, a credit-risk feature has to cross four groups — the app team, the core-system team, the risk-model team, and the data team. E-commerce and telecom compress the same pain into different words: a promotion feature crosses catalog, transaction, marketing, and warehouse; a plan change crosses channel, billing, CRM, and network. Whenever horizontally sliced teams try to serve a value stream that runs vertically, handoffs multiply. That’s the disease.

Platform teams — paving the road for stream-aligned teams. A platform team supplies infrastructure, CI/CD, and shared services so stream-aligned teams can self-serve the capability instead of filing a ticket and waiting. One test: is your internal platform run as a product — with users, a roadmap, an SLA — or has it slid into being an internal outsourcing shop that lives on tickets? Most large enterprise IT shops are stuck in the second one. They build a platform nobody uses, the business teams route around it and build their own thing, and the platform team decays into an outsourcer. Netflix’s Spinnaker (continuous delivery) and Spotify’s Backstage (developer portal) are the textbook examples of a platform run as a product. People mix these two up constantly: Spinnaker is Netflix’s, Backstage is Spotify’s. Don’t get it wrong in front of your board.

Enabling teams — help stream-aligned teams level up, with the explicit goal of working themselves out of a job. An enabling team doesn’t deliver the business directly. It raises the capability of stream-aligned teams: a coach bringing in a new technology, a guide for a DevOps transition, a consultant on security and compliance. The relationship to the stream-aligned team is mentor and student, not buyer and supplier. For large enterprises, this is the role an external transformation consultant should play — transfer capability, don’t manufacture a long-term dependency.

Complicated-subsystem teams — for the hard problems that need deep specialization. When a subsystem demands genuine depth — a risk engine, a recommendation algorithm, cryptography, video codecs — you carve it out as its own expert team instead of blowing out the cognitive load of a stream-aligned team. These should be rare. An organization that sprouts a lot of complicated-subsystem teams is usually turning what should be platform capability into a set of silos.

Naming team types isn’t enough. You also have to define how they interact. Team Topologies gives three interaction modes. Collaboration — two teams working deeply together, suited to uncertain new territory, but energy-intensive and only for short bursts. X-as-a-Service — one team offers a capability as a product that another team consumes on its own; this is the most efficient mode and should be the default. Facilitating — used only by enabling teams. The core question of organizational design is how to push as many interactions as possible toward X-as-a-Service. If your teams are still leaning on “collaboration” long-term, platformization hasn’t happened. Take the CIO’s situation: the inspection stream team and the platform team should interact as X-as-a-Service. The platform exposes a self-service CI/CD entry point, and the inspection team uses it without checking in. If every deployment still requires a “collaboration” meeting with the platform team, platformization is missing — and the problem isn’t attitude. It’s that the platform was never run as a product.

3. Why “Adding People” and “Adding Process” Both Fail: Cognitive Load

This is Team Topologies’ most underappreciated contribution. It puts cognitive load at the center of organizational design.

A team of 5 to 8 people has a finite cognitive load. Ask one team to maintain a dozen unrelated systems, interface with six or seven upstreams, and juggle three new frameworks at once — it overloads. Quality drops. Delivery slows. People burn out.

This is why that CIO was puzzled when he told me: “I added three people, why are we still slow?” The root is that this group was already carrying too many unrelated things. The headcount was fine. Adding people just puts more bodies spinning in the same chaos. Adding process is worse — process eats another layer of cognitive load, and the people who could actually ship end up spending more time on forms, meetings, and approvals.

The easiest fat for a large enterprise to trim is the load it puts on itself — cross-team friction, constant context-switching, approval chains. Cutting it takes no new technology. It takes less thrashing.

A concrete case. The head of a bank’s core-system team had 7 people interfacing with four upstreams — risk, customer service, regulatory reporting, marketing — while maintaining three unrelated modules. Just handling the cross-team sign-offs, alignment meetings, and context-switching ate nearly half the team’s energy every day. Hand this team the best AI tool on the market and it won’t stick. They have no spare cognitive bandwidth to learn anything new or change how they work. To save them, you reduce the load first: carve out the unrelated modules and let the team own a single value stream.

Amazon’s Two-Pizza Team rule is about communication cost — once headcount grows, the number of communication channels among members (n(n-1)/2) explodes and decisions slow. Team Topologies goes a layer deeper: past about 8 people, cognitive load also slips out of control. What organizational design is really doing is splitting teams by cognitive load, so each team’s burden lands inside a tolerable range — not drawing reporting lines by function.

A one-line health check for large enterprises: are your “busiest people” each carrying more than 5 unrelated things at once? If the answer is yes, no amount of headcount or process will save you. You have to re-split.

4. How to Act: The Inverse Conway Maneuver

This is the most actionable move in the book. Don’t draw the architecture first and then reorganize the teams to match. Change the team structure first, and let the architecture grow into the shape you want.

The traditional approach has an architect draw a target architecture (“we’re going microservices!”) and then demand the teams reorganize to fit. This almost always fails. The existing team structure keeps pulling the architecture back into its own shape. Conway’s Law, doing what it does.

The Inverse Conway Maneuver flips the order. Reorganize the teams along value streams first — carve out stream-aligned teams, stand up a platform team — so that team boundaries become the future service boundaries. Then the architecture drifts toward a sensible service split on its own, because teams will naturally communicate through APIs instead of reaching into a shared database.

Back to the CIO. I didn’t have him pick a microservices framework. I had him do something much plainer: stand “inspection” up as its own stream team. Pull one person each from the original frontend, MES, algorithm, and ops teams. Six people, owning the inspection feature end to end. Three things happened in three weeks. Week one: they discovered that a step stuck in the MES work-order flow didn’t actually need the algorithm team at all — they fixed it inside the team. Week two: they decided on their own to move model deployment from “queuing for the ops team” to in-team self-service, because the platform team had opened a self-service CI/CD entry for them. Week three: they shipped the first small end-to-end feature, crossing no team boundary. No headcount added, no tool swapped — the horizontal layers had been re-cut into vertical streams. Delivery cycle dropped from 3 months to 3 weeks. An unexpected bonus followed: this team started proposing improvements on its own, because for the first time they could see the whole of their stream and they owned the outcome end to end. When it crossed 5 teams before, nobody had felt responsible for the whole inspection flow.

For decision-makers, this is a counterintuitive but high-leverage conclusion: stop agonizing over the architecture diagram and start cutting into the org chart. Architecture is the outcome. Organization is the lever.

Who’s Using It

Banking (TT’s official focus industry + a strong-regulation reference). teamtopologies.com runs an expert column, “When DORA metrics meet governance in banking.” The DORA research it cites is hard-edged: external approvals correlate negatively with lead time, deployment frequency, and restore time — the more cross-team after-the-fact approvals you have, the slower delivery gets and the slower incidents recover. This is exactly the argument of this article: build compliance into the stream team and shift approval upstream, instead of relying on after-the-fact cross-team sign-offs. Digital banks like ClearBank come up repeatedly in the official ecosystem. Banking is the most instructive scenario for value-stream reorg under heavy regulation.
Zalando (e-commerce, the platform-as-product exemplar). Its internal developer platform serves as self-service capability for stream-aligned teams — a platformization benchmark the TT community cites often.
AutoTrader UK (auto classifieds). A real adoption case TT cites repeatedly — reorg by value stream plus internal-platform productization.
KPMG UK (became a TT official solutions partner in 2024). Brings TT to large enterprise and financial clients — a signal that TT has entered mainstream enterprise consulting.
Netflix / Spotify (spiritual exemplars of “platform as product,” not TT adoption cases). Both ran their platforms as products well before the TT book came out in 2019, validating the principle — but they aren’t adoptions of the TT four-team model.

Reference: teamtopologies.com/examples (official case library) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (banking DORA expert column)

5. When It Doesn’t Work

Team Topologies is not a silver bullet. Four common failures, each one mapping to a real pathology in large enterprises.

Renaming without restructuring. Relabel “frontend team” as “stream-aligned team” while the reporting lines stay tech-layered — Conway’s Law doesn’t care what you call things. This is the most common ending of a cosmetic reform in a large enterprise: new labels, same old structure.

The platform team isn’t run as a product. No roadmap, no user experience. Stream-aligned teams keep routing around it, and the platform decays into a ticket-taking outsourcing shop.

Everyone is “collaborating.” Collaboration is a high-energy interaction, only suited to short bursts in uncertain new territory. Relying on it long-term means platformization hasn’t happened. The surface looks like “great collaboration culture.” The disease is missing platformization.

KPIs weren’t updated. The org chart changed, but you’re still measuring by function — lines of frontend code, bug counts — and team behavior snaps right back to the old shape.

These four point to one judgment: among org structure, incentive structure, and technical architecture, change any one without the other two following, and the transformation fails.

A variant for heavily regulated industries. Finance and telecom will ask: functions like security, compliance, and tech risk are required by regulation to be independent (segregation of duties). They can’t simply be folded into stream teams. This is a hard legal constraint, not organizational inertia — don’t force the split. But you also don’t have to fall back to horizontal approval queues. Two paths. First, embed compliance and security reps inside the stream team: they sit in the team while reporting dotted-line into the compliance function, close to the value stream while preserving independence. Second, run compliance as an enabling team that helps stream teams build regulatory requirements into the flow — compliance checks running inside CI, for instance — shifting approval upstream into the team rather than relying on after-the-fact cross-team sign-offs. Regulatory requirements become the stream team’s built-in quality, not an external review gate. That’s the key to letting heavily regulated industries flow.

6. You Might Be Wondering

“We’ve been sliced by tech layer for ten years — won’t a reorg be gut-wrenching?” It will, but far less than you think. You don’t have to topple the whole company and start over. Pick the value stream that’s stuck the most — usually the one everyone complains about loudest — and stand it up as a single stream-aligned team pilot. Like that CIO: 4 to 8 weeks, one small team, and you’ll see a clear shift in delivery speed. Letting results sell the next round works far better than letting a slide deck sell it.

“How does this relate to the AI transformation we’re already running?” Directly. AI won’t fix a mismatched organization. It amplifies what’s already there: high-performing teams with AI get faster; mismatched teams with AI just manufacture debt faster. So organizational diagnosis ranks ahead of tool procurement. This is also why I put “capability assessment” very early in my signature method, the 7-Step AI Transformation Coaching Framework — look at the organization and the people first, then talk tools.

“What if we can’t field all four team types?” Most organizations can’t, and don’t need to. The first two you should have are stream-aligned teams (to guarantee end-to-end delivery) and a platform team (to stop reinventing wheels). Enabling and complicated-subsystem teams come in as needed; many organizations don’t have them at the start, and that’s fine. Don’t manufacture teams just to complete the four types. That’s the tail wagging the dog.

7. Lessons for Decision-Makers

Lesson one: before you adopt AI, draw a team topology map. Before the last AI tool you brought in, did you ever draw your team topology? With teams sliced along tech layers, no matter how strong the AI, you’re only accelerating debt on a broken structure. This single check can block at least half of the wasted IT investment in a large enterprise. Concrete action: list every team and mark which value stream it owns end to end. The ones you can’t mark are sliced by tech layer, and they’re the priority for reorg.

Lesson two: run a cognitive-load health check. Stop asking “do we have enough people.” Ask which teams maintain more than 5 unrelated systems at once, and which people interface with more than 3 upstreams. Surfacing these is far more useful than adding headcount or process. AI can absorb some of the load — writing code, looking things up, first-pass triage — provided you deliberately redistribute the load, rather than dumping one more “AI rollout” task on an already-overloaded team.

Lesson three: run the internal platform as a product, or it will inevitably degenerate into outsourcing. The platform needs users, a roadmap, an SLA, and someone accountable for adoption. In the AI era, this platform also has to absorb the model gateway, the prompt library, and the agent runtime — that’s the foundation the later “adoption framework” piece will build out.

Lesson four: don’t let AI harden the wrong boundaries. This one is specifically for organizations introducing AI agents. When you add AI agents into teams, a wrong team slicing gets amplified: the agent will automate along the existing — wrong — boundaries, locking the broken structure in more firmly. Before introducing AI agents, confirm the team boundaries are right. This is the focus of the 11th piece in the series.

Reverse self-check (answer without sugarcoating): is your team sliced by value stream, or by frontend/backend/ops/security? Is your busiest person carrying more than 3 unrelated things at once? If your internal platform has no users, that’s a red light for failed platformization. If either answer makes you uneasy, then before bringing in AI, reorganize the teams first. It’s the highest-payoff prerequisite move you can make.

What’s Next

This is the 2nd piece in the “AI-Era Software Engineering” series (episode 172 of the “Learn AI Slowly” column). We’ve walked from Conway (organization decides architecture) to Team Topologies (how to design the organization). The next piece (no. 3) takes up a more fundamental question: when AI makes code production nearly free, where does the bottleneck of software engineering move to?

Series note: This series continuously tracks the latest evolution of AI programming tools, organizational structures, and software engineering paradigms — for example, how Conway’s Law is changing in the age of AI agents in 2026, and the maturity of the latest tool ecosystem. Follow the series for continuously updated insight.

About This Series

“AI-Era Software Engineering” is an in-depth research series written for CIOs, CDOs, CTOs, and digital leaders in industries like telecom, finance, manufacturing, and e-commerce — 15 pieces in total. Built on 200+ academic papers and industry reports, it provides decision references annotated with evidence levels.

I’m a former IBM engineer and ICF-certified coach, with hands-on experience delivering AI and digital projects for carriers and large enterprises. What’s written here is the field judgment from walking companies through these traps.

If you finished this and you’re thinking “is my company shaped like this too” — I’ve put together a 20-question Team Topologies self-check, and I also offer a 30-minute 1-on-1 diagnostic call to help you locate which value stream to reorg first. If you’d like either: leave a message at the “AI Decision-Maker Insight” WeChat official account, or email coach@iaiuse.com.

References

Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (The original source for the four team types / three interactions / cognitive load — primary source.)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (Multi-organization adoption retrospective — secondary.) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — exemplars of internal-platform productization.
AutoTrader UK — a TT-officially-cited adoption case (link at teamtopologies.com to be filled in).
Official case library: https://teamtopologies.com/examples