I recorded a short video this week about something I would like you to think about over the next few weeks, particularly if you are an executive or lead a team in a medium or large organization. I think now is the time to build at least one frontier team that experiments with AI.
The last issue was about handing AI a bigger job than you are used to giving it. This one moves up a level, from the individual to the team.
Here is how Amazon writes the Ownership principle:
Leaders are owners. They think long term and don't sacrifice long-term value for short-term results. They act on behalf of the entire company, beyond just their own team.
Giving a team an outcome to fully own, and letting it decide how to reach it, is that principle applied to an AI experiment.
One team, not a program
I am talking about one team. It could be a product team, or a team building a new operation, something where you can measure whether making it AI-first made any difference. That team gets more freedom than the others: freedom to experiment and to fail, plus room to try out different tools and ways of working. It also gets very specific outcomes that it is measured on and works towards. And it is built differently, with AI agents as an integral part of the team.
The outcomes you get out of the team are of course important, but the team is also going to teach you how you should be building and thinking about the rest of your organization. It will let you inspire other teams to follow suit, and it will show you what is not working, so that when you come to scale this you will know what worked and what did not. Building one team and scaling to many are different jobs, and the scaling piece can wait until you have tried the first one for a while.
There is a reason to do this with a selected team rather than leaving it to whoever is already keen. Greg Shove, who runs Section, grades current enterprise AI adoption at about a C-, but says that for 10 to 15% of any organization adoption gets an A+. A team is about the smallest unit where the gain has somewhere to go, and it is where I suggest you start your climb up from individual-only AI adoption.
Keep it small and unblocked
Keep it small. By small I mean three or four people. Make sure it holds enough different skills to get from an idea to something real without waiting on anyone else. It should never queue behind another team to get anything done.
Give it an outcome to own
Give it an outcome to fully own. Not a project to deliver. The way to achieve that outcome is up to them and their AI team members.
A project fixes the shape of the answer in advance. An outcome leaves that shape to the team, including the question of which parts of the work an agent should be doing at all.
Say the permission to fail out loud
You should be very blunt about their permission to fail, and you will probably need to repeat this message more than once. Implied permission is not enough in this case.
What makes it a frontier team
So what makes it a frontier team rather than a team with better tools? Someone has to be thinking about what the agents will actually be doing. The question is how the work itself is set up so that agents can take a real part of it, rather than which tools to buy. That is an organizational and operational design challenge. It will not happen on its own, so it is part of your job and part of the team's own responsibility to make that mindset change.
I have written before about what centaur teams look like in practice, and about agent teams as a source of business value. A frontier team is one way to find out which parts of that hold inside your own organization.
The measurement trap
You should not just set the team up with the necessary freedom. You have to define strong expected outcomes for it.
The easy-way-out temptation is to measure the team on activity: tools they have tried, hours they saved, speed of adoption, number of workflows automated, number of AI tokens consumed. Those numbers are easy to collect and easy to produce without very much impact. A team may be running fast in the wrong direction, and will only teach you how to scale the wrong things.
What I suggest you look for instead is an outcome the business already cares about. Something the team owns and can move, and that someone outside the team would recognize as worth having. If the outcome only makes sense inside the AI experiment, it is probably the wrong outcome.
Agree on it in advance, in writing. Otherwise the story may be rewritten afterwards. After a certain time you can talk about the results, figure out what did not work and why, and what did help the team progress towards the desired outcome.
Where the effort actually goes
I spent the past few weeks building a personal knowledge base for myself, which I wrote up separately in building a digital brain that knows me. Very little of that effort went into tools. Most of it went into writing down how things actually work: who does what, and what I mean by the terms I use.
I would expect roughly the same balance in a team working heavily with AI agents, and I suggest you plan for it.
It connects to a larger question I have written about separately, moving from an AI overlay to an AI-native company.
To explore more the concept of frontier teams and how to let them run and pull your organization upwards, this talk with Allie K. Miller is worth your time:
Your action step
Name one team this month. Write down, on a single page, three things: the outcome it owns, the freedoms it has that other teams do not, and the date you will sit down to review what happened.
Then take the page to the team and read the second part out loud, the freedoms. Ask them what they would need to believe it. Whatever they say is missing is the actual state of your permission to fail.
Do you already have a team like this? What did you actually give it permission to do, and what is it measured on? If you have tried something along these lines and it stalled, I would like to know what stopped it.
If you are working out where a frontier team should sit in your organization, what outcome it should own, and how to review it without quietly turning it back into a project, that is the kind of question I take on in AI strategy advisory engagements and in sessions as an AI keynote speaker and workshop facilitator.