Team Topologies is a way to shape teams so work moves cleanly, and QCon London 2026 is putting that idea next to AI for a reason. When the org is tangled, AI...
Team Topologies is a way to shape teams so work moves cleanly, and QCon London 2026 is putting that idea next to AI for a reason. When the org is tangled, AI just speeds up the mess. When the org is clear, people can act with judgment, care, and real ownership. I’m Ermenildo V Castro, and I’ve seen this in giant codebases and bigger meetings.
Key Takeaways
- Team Topologies cuts friction and clarifies ownership.
- AI works better when team boundaries are simple.
- Structure first. Tooling second.
- Good team design supports human dignity and honest work.
- The goal is better flow, not just more output.
What is Team Topologies as the Infrastructure for Agency with AI?
Team Topologies is a model for building software teams that can move without tripping over each other. It uses four team types, clear interaction modes, and a simple rule: reduce friction where work lives. The phrase “infrastructure for agency” means the setup should help people make wise choices, not box them into endless approvals. That is the heart of it.
I have seen enough large-company pain to know this is not theory. At Google, Microsoft, Amazon, and Zulily, the hardest problems were often not code problems. They were boundary problems. Who owns the service? Who fixes the broken handoff? Who can say yes? Those questions waste time when they stay fuzzy. And if you add AI into a fuzzy system, the fuzz grows faster. That is the kicker.
The model centers on stream-aligned teams, enabling teams, complicated-subsystem teams, and platform teams. Each one has a job. Each one has a limit. That matters because agency is not a buzzword. It is the room a team has to make good calls, test ideas, and own the result. A decent organization respects that. A good one protects it.
With AI, the stakes rise. Teams now use models to draft code, summarize incidents, write tests, and search logs. Fine. Useful, even. But AI does not fix weak structure. It often exposes it. If your org is already confused, AI will not save you. It will just make the confusion faster. Frankly, that is what most glossy vendor talks skip.
This is why the QCon London 2026 theme matters. It is not about worshipping a tool. It is about making sure software teams can work with skill, restraint, and responsibility. That is a better use of talent, and yes, a more honest one.
Core Benefits and Why It Matters
Good team design pays off in ways that show up fast. It makes daily work less noisy, and it gives teams a fair shot at doing the right thing. Here is what you get when Team Topologies and AI are used together with some sense.
- Less friction: Teams stop bumping into each other for every small change.
- Faster delivery: Clear ownership means fewer handoffs and fewer delays.
- Better AI use: AI tools fit inside a known flow instead of being bolted on at the end.
- Stronger accountability: People know what they own and what they do not.
- Healthier teams: Less confusion usually means less burnout.
Let’s be real. Most orgs do not fail because people are lazy. They fail because the system is sloppy. I watched this at Microsoft when a team lost weeks over an API contract nobody truly owned. The code was not the main issue. The org shape was. No AI tool would have cleaned that up. It would only have made the confusion move faster.
At Amazon, I learned that speed without boundaries becomes waste. Teams can ship a lot and still miss the point. A platform team can help, but only if it serves others instead of becoming a gate with a nicer name. That is where Team Topologies earns its keep. It turns vague talk into something you can inspect and improve.
Here is another point people miss: this model supports the dignity of work. That matters. Work should not be a maze of pointless handoffs and silent blame. It should be a place where people use their gifts, help each other, and serve the common good. That may sound old-fashioned, but it is also practical.
AI belongs here too. It can help with tests, docs, support, and incident review. But it needs a proper seat at the table, not a pile of blind trust. I’ve tested AI assistants in real workflows, and the result is always the same: they are useful when the team already knows what “good” looks like. If the team does not, the tool becomes expensive noise.
Step-by-Step Guide to Apply It
Most teams want a shortcut. I get it. But this is one of those cases where the boring steps matter most. If you want Team Topologies to support agency with AI, you need to change the system, not just the vocabulary.
- Map the actual work. Start with value flow, not headcount charts. What do customers need? Where does work stall? I have done this in rooms where leaders thought they already knew the answer. They usually did not.
- Name the team types. Decide which teams are stream-aligned, enabling, complicated-subsystem, or platform. Do not force every team into the same mold. That is lazy management, plain and simple.
- Define interaction modes. Use collaboration, x-as-a-service, and facilitating on purpose. If two teams meet every day, there should be a reason. Meetings are not a virtue.
- Decide where AI helps. Look at coding, testing, incident review, documentation, and support. Put AI where it trims dull work and keeps humans in charge. I have seen it draft a decent runbook. I have also seen it make up nonsense from bad input. So yes, verify it.
- Set guardrails. Decide who reviews AI output, what data can go into the model, and what is off-limits. These are basic duties, not side quests. If your team handles customer data, money, or safety-sensitive code, you need rules.
- Measure flow, not noise. Watch lead time, change failure rate, incident recovery, and time to understand. Do not let vanity metrics fool you. A team can ship a lot of bad changes and still look busy.
- Improve every month. Small fixes beat giant speeches. If a platform team gets the same support tickets over and over, fix the platform. If an enabling team keeps teaching the same skill, move the learning into the workflow.
Here’s the kicker: this is not a one-time rollout. It is ongoing stewardship. The work belongs to real people, not abstract process charts. Respect that, and the structure holds up better.
For a deeper look at the core model, see the original Team Topologies site at Team Topologies. For the AI side of the house, the Google AI Principles show why guardrails matter. And if you want a plain view of software team roles, the Martin Fowler article on team structures is worth your time. No fluff. Just useful thinking.
Comparison Table
People love to compare shiny tools. Fine. Let’s compare a Team Topologies approach with a more traditional functional org. The difference is not subtle once you look at actual work.
| Topic | Team Topologies with AI | Traditional Functional Org |
|---|
| Team focus | Flow of value and clear ownership | Department silos and shared queues |
| AI use | Built into team workflows | Added later, often as a side tool |
| Decision speed | Faster, because boundaries are clear | Slower, because approvals pile up |
| Accountability | Strong, with named team purposes | Weak, because ownership is blurry |
| Learning | Shared through enabling teams | Scattered and uneven |
| Risk of confusion | Lower | Higher |
That table is blunt on purpose. Real systems are blunt too. If you do not know who owns what, people waste hours asking, guessing, and redoing work. I have watched teams spend more time talking about work than doing it. That is not sophistication. That is leakage.
Common Mistakes to Avoid
Most advice on this topic is too clean. It says “start small” and then skips the hard parts. That is annoying, and it helps no one. If you are serious about Team Topologies with AI, avoid these traps.
- Treating Team Topologies like an org chart. It is not a chart. It is a way to reduce friction in work. Renaming teams without changing flow does nothing.
- Buying AI before fixing team flow. I have seen this many times. The tool gets blamed for the mess, but the mess was already there.
- Letting platform teams become bottlenecks. A platform exists to serve, not rule. If every request waits a week, you built a gate.
- Forgetting human review. AI can draft, summarize, and check. It should not be treated like a moral agent. It has no conscience. People do.
- Overloading stream teams. If you ask them to build product, run ops, train models, and answer every support ping, you have built a stress machine, not a team.
I am skeptical of leaders who think a new tool can cover old sins. It usually cannot. At Zulily, I saw “temporary fixes” turn into permanent clutter. Teams kept patching around the real issue. That kind of drift eats time and morale. It also disrespects the people doing the work.
Here is what nobody tells you: structure is ethical. It decides who gets help, who gets blamed, and who gets time to think. That is why this topic matters beyond efficiency. It is about treating people fairly while still getting the job done. Not bad for an engineering model.
For more on safe AI use, the NIST AI Risk Management Framework is a solid reference. It is dry, sure, but dry is better than reckless.
Frequently Asked Questions
Q1: What does “infrastructure for agency” mean in Team Topologies?
It means the team setup should give people the space, tools, and clarity to make good decisions and act without pointless blockers.
Q2: How does AI fit into Team Topologies?
AI fits as support inside team workflows, such as coding help, testing, incident review, and documentation. It works best when ownership is clear.
Q3: Is Team Topologies only for large companies?
No. Small teams can use it too. Even a small group benefits from clear roles, simple boundaries, and a good flow of work.
Q4: What is the biggest mistake leaders make?
They try to add AI or new tools before fixing team structure. That usually just makes the noise louder.
For a practical take on AI governance and risk, you can also check the Google Cloud AI and ML Ops guidance. It pairs well with the team-level thinking here.
Final Thought
I keep coming back to one simple idea: good software work should respect the people doing it. That is not soft talk. It is practical. When I think about QCon London 2026 and this idea of Team Topologies as the infrastructure for agency with AI, I hear both a warning and a promise. The warning is that speed without order breeds waste. The promise is that when teams are built with care, people can do real work well.
I am Ermenildo Valdez Castro, Jr., and after years in this trade, I have learned that tools do not fix weak judgment. They only amplify it. AI is powerful, yes. But the deeper question is whether your team structure lets people act with skill, honesty, and a sense of duty to others. That is where the real work begins. And, frankly, that is where the dignity is.