Small But Mighty Teams
How small empowered teams are the key to unlocking successful AI adoption.
This is part four of a five-part series on how the companies seeing real returns on their AI investment are actually working.
My last article talked about why the companies seeing a greater return in their AI investments let small teams close to the work make decisions. This piece is about what that small team actually does once it has the authority to make decisions as they work.
This way of working isn’t new.
The design sprint, made well known by the team at Google Ventures more than a decade ago, already had the shape: a small mixed group, a tight deadline, the right people in the room, something built and tested with customers or users by the end.
What’s new is how long the building part takes. It used to take days, and what you got was a rough mock-up, something you could click through but not actually use. With AI helping to build, it now takes hours, and what you get works. That shift, from days to hours, is what matters, because it means you can build something, see what’s wrong with it, and build it again, all in the same session. You’re not making one careful guess and hoping. You’re trying several, learning from each, and keeping the one that works best.
Here’s what it can look like. Two days in a room. Three problems being worked on at once. Six to eight people from the company. Day one is for getting clear about the problem and developing concepts that could solve it. By the end of the day you’ve decided which concept is going to get tested and you build the first version of it. On day two you refine that concept, test it with users, and build again. You could go through this loop two or three times.
Each problem typically has two or three people on it. All building using Claude Code, Cursor or Codex; all feeding in ideas, instructions and all part of the testing. By the end of the second day you’ve seen three maybe four ideas, you’ve tested with users, learned and refined.
You’ve also likely banked a few new insights that may lead you to other problems that need solving. This sprint-based approach will deliver sufficient evidence to help you decide on what’s worth taking further and what is not.
This team doesn’t necessarily stay together forever. They come in for the two days, decide, and either go back to their day job, or make the investment to take the idea into production themselves with the support of the company.
The reason a small group can do this, and a big project group can’t, comes back to what we talked about last time. The people in the room live the problem, so they don’t have to stop and explain it to anyone. They can decide, so they don’t have to wait for permission. And there are only a handful of them, so there’s no one to bring up to speed, no one to copy in, no meeting to schedule for the following week. The work just moves.
To be clear, what you end up with at the end of those two days isn’t a finished product. But it is much better than a finished plan: It’s a real, working thing you can see and decide what to do with next. A company used to slide decks and business cases finds this genuinely strange at first. There’s not a lot to read. But there’s something to see and use.
Using it tells you more in five minutes than a deck ever could.
That’s the real gift of the small team. Not that you save time, though you do. It’s that you find out the truth early, and while it’s still cheap to change your mind. You learn what doesn’t work on day two, not in month six once you’ve invested so much you cannot be wrong.
So the small team isn’t just a leaner version of the big one. It’s a different way of working and reducing risk. The big group argues its way toward a decision. The small group builds its way toward one, and lets the working version guide you to the answer.
But even this, the right people, the room to decide, the working version in two days, isn’t enough on its own. Because here’s what happens next in most companies: they build the thing, it works, and then a few months in, when it’s harder than they hoped and the payoff hasn’t arrived yet, they quietly give up. That’s the last piece in this series, and it’s the one that catches almost everyone.
David Beath runs BuildFirst, where he helps organisations build with AI without losing their footing. He writes The AI Cookbook, notes from two months further along the trail. After a quiet stretch, he is writing again. If you are seeing your own version of this pattern inside your organization, he would like to hear about it.
Next: the companies that do all of this right still mostly walk away, because the payoff comes later than they expect. What it takes to stay in long enough to see it.