Yuval Yeret: Tiny AI-empowered teams. The flattening pitch assumes your teams can deliver an outcome alone. But the reality is most cannot. Agents can make people faster, not necessarily more independent. Today want to talk about how to simplify our scaling model as AI makes teams faster. Welcome to the scaling AI from Activity to Impact podcast.
I’m Yuval So this probably sounds familiar. Your engineers or teams who are adopting an agentic software lifecycle, C work compression. If you look at the typical structure of work, big initiatives that used to be split into features that eventually were broken down into stories that used to take days.
Now with AI assisted and especially agentic development take minutes or at most hours. At this level, it’s not even worth managing the way we’ve managed them before. So i it raises the question, do we even need to manage at this level, right?
And one of the things that engineers complain about is that the current ways of working, whether it is a form of scrum or safe or team level Kanban All of those Feel wasteful and irrelevant. It sometimes feel like these engineers were just looking for an excuse to get rid of get rid of this prosthetic overhead that they’re feeling.
So you look into best practices in organizing an AI native product or engineering organization, and you show similar advice from McKinsey, Deloitte, Gardner, all the usual suspects that essentially boils down to the notion of instead of having the classic teams that you currently have with you know managers and a lot a lot of structure, instead of that.
What they’re saying is you can move to tiny teams. Tiny teams that are assisted by robots. And there’s a certain attractiveness to these teams. If indeed you can take you know what used to take ten to twelve people and do it now with two to three people plus tokens. That’s you know, that’s nice, right?
You now don’t need the coordination mechanisms that you had between teams in the past, right? We used to have teams and in you know a lot of scaling structure that connected the work of these different teams. But if everything can be done by these Notion of tiny teams, and you don’t need any of that structure that’s very attractive.
You don’t need as many of the people that were focused on doing this, and you don’t need a lot of the events, artifacts. We don’t need Jira anymore, we don’t need sprint planning, we don’t need sprint reviews, we just need tiny teams. So essentially it’s a flatter leaner organization with human costs replaced by token spent.
So you’re asking yourself a question. Can I really do this? What is needed for success with these tiny teams? Can we just staff these tiny teams, give them tokens, decide on a spec driven harness and that’s it?
Can it be that simple? W when leaders ask me for my advice on this, I start, I go back to what drove us to come up with the right product team size to begin with. So a quick primer. Product team size is always, has always been an optimization, a 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.
A smaller team with three people, much better if we can pull it off than a team that has 10 to 12 people. Right? On the other hand, a small team that’s always blocked. That constantly needs to go outside of the team in order to deliver their value is useless. And here’s the trade off. If the larger team here paid the price of more collaboration and coordination, but through that price managed to actually close the loop and be empowered and independent and decoupled from other teams, it might have been worth the price.
We often refer to this as the team being cross-functional enough, having access to all of the functions or disciplines that are needed in order to identify, define, deliver, test, and realize value. When you look in the wild, unlike AI native startups, most of the product teams that I see out there in the trenches are up to 10 people, but even at that scale, they’re not cross-functional enough.
So even those teams here depend a lot on other teams in order to deliver value. The reality is In some of the cases, the organization found a shortcut in the system to product team transformation. So if you look at the typical organization, the typical starting point is that the organization started with teams around systems or applications.
So each team has an expertise in a certain system. Or an application a let’s say a b c and d systems a b c and d and each one of those teams has people that know how to do work in this area which is fine. And the whole organization is structured this way. And then somebody came to this organization and told them we need to we want to become product oriented.
We’re gonna implement a product operating model. What does it mean? Well ideally we want teams to be empowered product teams that can deliver value end-to-end. And often delivering value end-to-end requires connecting and cutting across those teams. Often it requires an horizontal team rather than those verticals that we’re talking about here.
But the problem is that this is a tough change for organizations. I’ve worked with multiple organizations over the years through this change. It’s not an easy one. And even in twenty six, we still have organizations that haven’t completed this change. But organizations also don’t like to acknowledge that they’re not gonna do this.
They want to be able to say we’ve implemented the product operating model, and their consultants that they’re being paying, the Top dollar two, those consultants want to be able to show that they’ve done the product transformation as well. So what’s the trick?
The trick, the shortcut is to say, you know what? System A is not just a system, it’s a product. Now instead of calling it system A, we call it product A. And system B is product B. Voila! We now have product teams. But these teams still fail the empowered test. They cannot deliver on their own. 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 fan 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. Let’s 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 these teams to deliver value.
And that’s why scaling frameworks came about. Scaling frameworks are designed to help a set of teams work effectively together, combine forces to deliver an outcome. Whether it’s safe. Scaled agile framework, whether it’s large-scale Scrum, less, whether it’s Nexus. Professional scrum.org. Even the Spotify model.
Is in the framework, they all at their core try to answer the question. What’s the minimal? Minimal amount of management and coordination. That we need in between these teams. The minimal 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.
Lest and access, for example, assume they assume product teams that are much closer to what we really want to see. Much closer to an ideal true feature team. So they can get away with less coordination or scaling over it. Safe also prefers an organization that is organized this way, but they’re acknowledging that some organizations, some teams will need more from each other.
So Safe provides because it needs to, because of the organizations that it supports. It includes more elements to manage the coordination overhead. So that’s back context for why did we even need scaling patterns in agile in product operating models?
So let’s go back to what happens when these product teams start to use AI to build self-code. Well, if we had teams that are still organized around systems essentially, even though they’re called products, IA AI will accelerate this team. Okay?
I it will enable engineers that use coding agents here on these teams to deliver much, much, much faster. They will be much more productive. They will tackle and deliver stories that used to take them several days in a few hours, sometimes even minutes. But beyond increasing the story output, the real effect depends on the engineering team versatility in the code-based scale and health.
It depends on the relationship between these teams. If your organization right now requires four portfolios, eight product groups, value chains, arts, whatever you want to call them, sixteen teams or pods, all to deliver one specific valuable outcome. If all of that is needed. Then the fact that you accelerated the pods Has not diminished in any way.
Any of the coordination overhead or headache that is required to align all of this towards an outcome. 10xing the code generation just produces more unintegrated PRs and longer dependency queues. You do not necessarily get faster time to market an amplified fruit, but you just get a new ver version of the activity theater around all of this.
So let’s try to look at it from a positive let’s take a positive slant. What needs to be true? What are the critical success factors for this to actually work? For tiny teams topology to work. Tiny teams work well when you have engineers. That are what we call at least T shapes. Where they can span wide across the code base.
They have deep expertise in certain areas, but they’re not afraid to go elsewhere. They aren’t afraid to go anywhere in the code. They are allowed and encouraged to go anywhere. And they are capable of providing judgment and perspective to AI agents that work anywhere in the codebase that’s needed to deliver value.
The coding agents themselves can see and work across the codebase. They have access to all the repositories. All the test environments that are needed. All the knowledge, all the context. About where this product is living in architecturally, technically from a business perspective. Humans and their agents can own the entire value stream from intent or problem to value realization.
It’s not just about building and integrating software. Coding is just one small piece of it. It’s not even about the testing of the code or specifying the code. It’s about what’s going on upstream. Figuring out what’s the outcome, what are we trying to do?
Going downstream and validating based on actual usage, actual measurement of leading indicators, is this valuable? And the team being able to run loops. That converge towards an outcome. It’s not enough to just say an outcome. You should be able to actually converge and realize that outcome. So we want teams that are able to start.
Steward outcome through adoption, through retention and value creation. The typical reality is that dependencies die hard. Going back to the typical enterprise, the typical scale up that I see out there, the reality isn’t those tiny teams that can do things and end to end. Their reality is some version of this picture.
They typically 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. And in these environments, you might be able to reduce the 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.
I often talk about this scale when you can, scale when you must. So, 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 still need to collaborate to deliver value, you need some mechanism to coordinate and manage these 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. You might even still need to manage user stories, believe it or not, if one feature requires multiple teams and y you need to collap coordinate the different deliverables of each team into this feature.
What your scaling apparatus looks like at this point really depends on what you need. And that’s a generic advice, right? It’s true even before AI. But it’s even more important in times of huge disruption like the one that’s currently happening. So the question that we need to ask ourselves is what needs to happen?
In order for us to be able to descale or at least enable a lighter scaling apparatus. The same that was true before AI. We need to work on the things that enable team independence and decoupling. Luckily, AI is really helpful for some of these moves. Collective ownership was always a good idea, but the typical barriers.
Are lack of safety nets, technical debt, code complexity, creating Hereby Dragons areas, which engineers are afraid to get anywhere close to. In parallel, code owners are afraid to let anybody touch the code that they are responsible for. Coding agents can be leveraged to refactor, reduce technical debt, and create safety through the test automation, code review workflows that clean some of those Hereby Dragon 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 team’s needs for their features can rely on self-service APIs and doesn’t need require doesn’t require new development in the platform.
Many organizations I work with have a clear vision for what they would like their architecture to be that will set them free for dependencies, they know. We want to create this platform and that platform and this service and they don’t need AI to tell them that. But before AI, they didn’t really have the capacity for this.
So one of the s interesting things that has happened With AI is we now have some capacity. AI is freeing capacity whether it is by taking over some of the maintenance work or by taking some of the new feature development work. AI can free some capacity as well as accelerate the work in creating these self-service platforms.
The speed and throughput of coding agents can therefore be leveraged to pursue this architectural runway. The sort of things that even during the cloud transformation you didn’t have time for and just, did lift and shift instead of real refactoring. This sort of work is classic for coding agents, actually, 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. So if you think about it, when the coding agent develops a platform, one of the questions is not just is it Working the way we specified it, is it delivering the outcomes that we wanted this platform to achieve?
In the case of a real customer facing feature that requires deploying to real humans, which is a slow feedback loop. But in this case, what AI can do is it can actually run the different Other systems and products that would use this platform and see whether the separation of concerns is working. This means it can close a feedback loop.
And it can decide amongst itself, even agentically, what is needed, what are the features that are needed from this platform. Continuing to maintain a platform is actually easier in some ways for AI because of this fact that it can monitor how it’s being used by the different systems. And it can come up with ideas how to improve the platform to minimize the amount of life dependencies that it needs to manage and maximize the amount that is self-service.
Coding agents these days can even take on gauntlet goals where they re-architect entire systems, assuming they truly have access to the right context and environment to do this. So, what does it take to be AI ready if you’re an enterprise product organization with serious legacy?
It’s gonna take more than a day. It’s gonna take a while. It’s not just installing coding agents, it’s not even just teaching people or even implementing a spec driven harness. Rome wasn’t built in a day. An AI ambitious organization is not gonna become AI native or even AI ready in a day, a week, or even a month.
Even with coding agents, you have limited capacity and limited throughput you can dedicate to your AI readiness runway. Whether it’s the AI capacity and even more the human capacity that’s needed to provide the intent, the guidance, and the feedback loop to these AI agents. So surprise, surprise, you still need to prioritize.
So how do we prioritize? Instead of throwing away your scaling apparatus, leverage it to find the constraints in the form of dependencies. Here are some ways that I like to do that. So you can review your dependencies whether it’s through a dependencies board or mining the information in your JIRA, ADO, linear, whatever.
AI, by the way, can help with that. Look at why work is getting blocked. Dependencies are often the reason, whether explicitly or implicitly. Look at flow metrics. Items with the highest cycle or flow time or the lowest flow efficiency. Typically hide some dependency. Okay if you look at something that takes a long time to complete compared to the other things, there’s probably not a lot of work that is happening.
It’s actually delayed waiting for something else to happen. This is something you want to look at. It’s often a usual suspect. A lot of time people actually know what it is if we’re honest about it. It’s often the one team that a lot of the work waits for. It’s a team or a system that everybody depends on.
It’s a team that’s often the least predictable, whose capacity is often spent in rework, maintenance, serving demand, where they can barely get the time to be proactive, to go on the offense. Once you identify your constraint, it’s time to move some of your capacity to that team. Just kidding, that maybe, maybe you’ll do that, but it’s often hard to do that.
A more practical and economical solution these days is to focus coding agent adoption in this area. This is where even local acceleration for this team. Can shift the performance of the whole system. Coding agents, for example, can deal with the ongoing demand, refactoring, defeat fixing, automation in this area.
So it can free some human capacity to get out of this loop and start thinking about how can we change this reality? How can we improve capacity or even get out of the loop? Maybe the solution is to create a platform here. Maybe it is to use this capacity to go join other teams and enable them. There are different ways to do that.
AI just creates some new options that we didn’t have before. As well as accelerate and make things that were unrealistic to do in the past or were tougher trade-offs in the past. Kevin Fox tells a classic systems or constraint story that’s called the blue light. The essence of that story is that if you realize that the welder is the constraint of your valley stream, you want to see the blue light of a weld in action coming out of the welding booth in your factory line as much of the time as possible.
And of course, there are a few assumptions that We can unpack about the utilization, efficiency, and effectiveness here, but if there’s no light, the welder isn’t welding. If we apply to our weld, you want to make sure that your specialized teams The teams that are the scarce resource that people are dependent on, the bottlenecks.
The bottleneck that you find, you want them to be as effective as possible. Every time they waste effort because someone asks an incomplete question, brings in work with missing context, or this team gets stuck on their own dependencies, it’s a big deal. So at this point, you want to think about what we can do so this team.
That is the bottleneck, we constantly see the blue light on here. How can AI help? Even for the cases where you want the specialized knowledge the humans bring into this loop, AI can help them, AI can help facilitate efficient intake, it can be a copilot. It can help as a copilot for these humans. So let’s go back to the scaling apparatus.
What scaling patterns make sense? Those that help us manage and optimize the flow through the constraints in the organization. And this isn’t that different from the perspective I started this article with. That scaling mechanism 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 outcomes? The question shouldn’t be which scaling framework is cooler, newer, 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, which has the vision and runway through how it’s based on principles, to both nudge you as well as 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. That’s been my advice for years now. And it’s true now as well. Why do you want to avoid these patterns?
Because they add overhead. And that overhead might be worth it. If you need it. If you can get away with smaller teams that are really empowered, you don’t necessarily need the scaling overhead. But if you’re not ready, if you’re not making the change to these teams, if you don’t have fungible teams, fungible agents at this point, th then you’re not ready for it.
Tiny teams are a great idea. And if you’re ready for them and for reimagining how you work and full on the scaling, go for it right now. But if you’re not currently ready, but believe you can be and need the push, the scaling f patterns can actually help you, should help you run this run this change. Take for example your last three customer visible outcomes and count how many teams each one had to cross.
Not how many teams touch the code, how many teams had to agree on something or wait for each other before it shipped. AI can help you figure out, okay? 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 one of these teams faster, but they will still likely depend on each other to deliver anything useful.
Then run a thinking or simulation exercise to consider what would happen if we did implement tiny teams that were empowered. Would we still see dependencies between them? Where would be the bottleneck? And then you can think about what architectural, agentic, human interventions might improve the flow through the system and reduce the amount of coupling and dependencies.
You can consider how AI can help you with any of these improvement runway options. Any of the changes that you want to introduce to your reality, AI might be useful not just in these teams, AI might be useful. In accelerating the AI readiness runway. A lot of these interventions that were unrealistic in the past are now much more attractive.
You can create an improvement roadmap and get going on the path to real AI readiness by working on it, by allocating some capacity for it, leveraging AI to run it. That’s all great. But don’t just create smaller teams just by their size. 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.
I’m Yuval Yeret thank you for tuning in to Scaling AI from Activity to Impact.