How to Simplify Your Scaling Model as AI Makes Teams Faster

Product team size is always an optimization/trade-off. On one hand we know that the smaller the team the easier it is to collaborate within the team and to get to a high-performing state.

On the other hand, a small team that’s always blocked is useless. We want the team to be empowered. To be able to close the loop. To deliver value, sense and respond, with minimal/no dependencies outside the team. We often refer to this as being cross-functional - the team having access to all of the functions/disciplines needed to identify, define, deliver, test, and realize value.

Unlike AI-native startups, most product teams I see out there in the trenches are up to 10 people, but they’re not cross-functional enough, therefore they often depend on other teams to deliver something valuable.

The reality is, in some of the cases, the organization found a shortcut in the system to product team transformation - they just called their systems products and voila - they have product teams. But these teams fail the “empowered” test.

We used to ask whether a team can deliver a feature in order to gauge whether it’s an effective empowered team. But then the shortcut gang found a way around it. They defined Features as a bunch of work that the team can do, not as something valuable and marketable. There goes the value of a “Feature Team” as a concept…

Dive deeper into organizing teams around outcomes.

If teams can’t fully deliver value on their own, we need some mechanism to coordinate and manage the collaboration across teams to deliver value.

And that’s the purpose of scaling frameworks.

SAFe, LeSS, Nexus, even the Spotify Model that isn’t a framework. They all, at their core, try to answer the question: “What’s the minimal amount of management/coordination scaffolding we can get away with to ensure predictable, effective delivery of value across a set of teams?”

Each of these frameworks makes a different assumption on the state of the organization. LeSS and Nexus for example assume product teams that are much closer to the ideal “Feature Team” so they can get away with less coordination/scaling overhead.

SAFe also prefers an organization with teams that are organized around value, but their main market is organizations that struggle to make this transition. Which means SAFe needs to include more elements to manage the coordination overhead.

AI accelerates the software development lifecycle. Engineers that use coding agents effectively can be much more productive. They tackle stories that used to take several days in a few hours.

But beyond increasing the story output, the real effect depends on engineer and team versatility and codebase scale and health.

If your organization requires 4 portfolios, 8 value chains, and 16 pods to align before a single customer epic can ship, 10x-ing code generation just produces more unintegrated PRs and longer dependency queues. You do not get faster time to market and amplified throughput. You just get a new version of activity theater.

Tiny teams work well when:

• Engineers can span wide across the codebase - They aren’t afraid to go anywhere, they are allowed and encouraged to go anywhere, and they are capable of providing judgement and perspective to AI agents working anywhere in the codebase that’s needed to deliver value.
• Coding agents can see and work across the codebase. They have access to all the code repositories, test environments, knowledge about the context the product is living in.
• Humans and their agents can own the entire “value stream” from intent/problem to value realization - it’s not just about building and integrating software. It’s about stewarding it through adoption, retention and value creation.

Going back to the typical enterprise / scaleup - this isn’t their reality. The typical organization didn’t make enough headway into a real agile product operating model so their teams and architecture don’t provide the conditions for tiny team success.

In these environments, you might be able to reduce team size, but until you deal with the same limitations the pre-AI “product” teams had, you would still need the same level of coordination across these teams.

Do you still need scaling patterns? In this case, you probably need quite a bit of your current scaling apparatus, unfortunately. As long as your teams need to collaborate to deliver value, you need some mechanism to coordinate and manage priorities, execution, delivery across these teams.

If, for example, a true feature still needs the involvement of multiple teams, you still need some mechanism for planning and coordinating the work breakdown of that feature. And you might even still need to manage user stories believe it or not.

What your scaling apparatus looks like at this point really depends on what you need. Which is good advice I give to all my clients and students. Descale when you can, Scale when you must.

So what needs to happen for us to be able to descale? or at least to enable a lighter scaling apparatus?

The same that was true before AI. We need to work on team independence and decoupling.

Luckily, AI is really helpful for some of these moves.

The typical barriers to collective code ownership / versatility are lack of safety nets, technical debt, and code complexity, creating “here be dragons” areas which engineers are afraid to get anywhere close to.

In parallel, code owners are afraid to let anyone touch the code that they are responsible for.

Coding agents can be leveraged to refactor, reduce technical debt, and create safety through test automation and code review workflows, that clean some of these “here be dragons” caves.

Coding agents, with their ability to get up to speed on new code faster than any human, can pair up with humans and help them work in foreign areas of the code more productively.

A different approach is to create consumable platforms so that much more of the functionality teams need for their features can rely on self-service APIs and doesn’t require new development in the platform.

Many organizations I work with have a clear vision for the decoupled architecture that will set them free from dependencies, but never had the capacity to invest properly in their architectural runway.

Even during a “cloud transformation”, the pressure is often so high that “lift and shift” is more common than proper rearchitecture to micro-services.

The speed/throughput of coding agents can be leveraged to pursue this architectural runway. This sort of work is classic for coding agents because they can work in a closed loop. The “customer” is an internal system that is easy for the coding agent to understand and simulate (unlike real world customers).

Coding agents can take on “gauntlet” goals where they rearchitect entire systems, assuming they truly have access to the right context and environment.

Rome wasn’t built in a day. And an AI-ambitious organization won’t become AI-Native or even AI-Ready in a day either.

Even with coding agents, you have limited capacity and limited throughput you can dedicate to your AI-readiness runway.

So, surprise surprise, you still need to prioritize.

Instead of throwing away your scaling apparatus, leverage it to find the constraints in the form of dependencies. Here are some ways I like to do that:

• Review your dependencies, whether it’s through your dependencies board or mining the information in your JIRA/ADO. (AI can help…)
• Look at why work is getting blocked. Dependencies are often the reason, whether explicitly or implicitly. (Again, AI can analyze your data)
• Look at flow metrics. Items with the highest cycle/flow time or lowest flow efficiency typically hide some dependency on a scarce and unpredictable resource.

This will help you figure out the constraint - the bottleneck. It’s often the team/system that everyone depends on, that is unpredictable, whose capacity is spent in rework, maintenance, serving demand, where they can barely get time to be proactive, go on the offence.

And to be honest - more often than not, people already know to point to this constraint, without the data…

Once you identify your constraint, it’s time to move 20% of your engineering capacity to that team. Just kidding…

A more practical and economical solution these days is to focus coding agent adoption in this area.

This is where even local acceleration can shift the performance of the whole system.

Coding agents can deal with ongoing demand, refactoring, defect fixing, automation, so it can free some human capacity to think and drive ways to improve capacity further.

Coding agents can help accelerate the development of architectural runway items focused on dependency elimination:

• Platform creation
• Enabling other teams to self serve through knowledge sharing
• Creation of context-aware agents specialized for this system, that can “join” other teams or serve them with much smoother service levels.

Kevin Fox tells a classic system/constraints story called The Blue Light. The essence of the story is that if you realized that a welder is the constraint of your value stream, you want to see the blue light of a weld in action coming out of the welding booth as much of the time as possible. (Of course, there are a few assumptions about utilization / efficiency / effectiveness here…) If there’s no light - the welder isn’t welding.

If we apply it to our world - you want to make sure your specialized teams can be as effective as possible. Every time they waste effort because someone asks an incomplete question, brings in work with missing context, or they get stuck on their own dependencies, it’s a big deal.

So at this point you want to think about - what can you do to keep the “blue light” on?

How can AI help? Even for the cases where you want the specialized knowledge the humans bring into the loop - AI can help facilitate efficient intake. It can help as a co-pilot for these humans.

So what scaling patterns make sense? Those that help manage and optimize the flow through your constraints.

This isn’t that different from the perspective I started this article with - that scaling mechanisms should be the minimum viable coordination overhead to tackle the collaboration across people and teams required because of your current dependencies.

Should you use an Agile Release Train? PI planning? Are you ready to shift from full story-based PI planning to planning around features and outcomes? (along the lines of AI-Native SAFe Outcome Planning, for example)

The question shouldn’t be which scaling framework is cooler or has a stronger ecosystem around it. It should be which has the patterns that are a good fit for where you are right now and has the vision and runway to both nudge you and support you on your way to working the way you want to in the age of AI.

ARTs are great, portfolios are great, solution trains are great, but try to avoid them if at all possible. Why? Because collaboration is much easier the smaller the team you have.

Tiny Teams are a great idea continuing further in this direction.

And if you’re ready for them and for reimagining how you work and full-on descaling - go for it!

If you’re not currently ready, but believe you can be, and need the push from a structural change - that’s another way to think about this (That’s the “burn the ships” approach to change)

Take your last three customer-visible outcomes and count how many teams each one had to cross. Not how many teams touched the code. How many teams had to agree on something, or wait for each other, before it shipped. (AI can help mine your JIRA/ADO for what’s really going on)

If the answer is one or two, then a lot of your apparatus probably is optional. If the answer is five, then agents could make each of those five teams faster but they will likely still depend on each other to deliver anything useful.

Then run a thinking/simulation exercise (AI can help here…) to consider what would happen if you implemented tiny teams along the existing structure/topology. Would you still see dependencies? What would be the bottleneck?

And then you can think about what architectural, agentic, or human interventions might improve flow through this system and reduce the coupling and dependencies.

Consider how AI can help you with any of these improvement runway options. It might make interventions that were deemed unrealistic in the past, much more attractive.

Create an improvement roadmap, and get going on the path to real AI-Readiness.

But don’t just create smaller teams, call them tiny, and assume they will 10x, without taking care of how they’re organized, the architecture they’re working on, and the system around them.

Listen to Tiny Teams, Same Dependencies: Can AI Flatten Your Organization? or watch it on YouTube.