We need to talk about teams

I write with Wim Sweldens, who ran the wireless division at Bell Labs, on why building effective teams is the next frontier in AI readiness.

Image credit: Wikimedia Commons

A post about the nature of organizational strategy and change management is the perfect opportunity to share four roles that aiEDU is hiring at the moment. Each of them will be an opportunity to lean into the absolute bleeding edge of AI capabilities while leveraging knowledge and expertise to advance our mission to prepare all students for the age of AI. Here they are:

• Chief of Staff & Director of Special Projects

• Product Manager (x2)

• Senior Marketing & Communications Lead

+++

Written with Wim Sweldens, co-founder of the live-video company Kiswe and an applied mathematician by training. He invented the wavelet lifting scheme that underpins the JPEG 2000 image standard, ran the wireless division at Bell Labs as a president under Nokia’s Alcatel-Lucent, and now writes about “AIQ,” his metric for how well a person can actually use AI. I borrowed Wim’s AIQ idea in an earlier post about aiEDU starting to adopt AI ourselves. We’ve kept talking since, and a conversation that started with how you learn to ride a bike ended up pointing at something deeper about how teams change in the AI age. What follows is the two of us working it out together—mostly in my voice, with one stretch that belongs entirely to Wim.

+++

A few months ago I wrote about why and how aiEDU kicked off our AI transformation strategy last year.

We ran hackathons and stood up a cohort of “AI Vibers,” people from across the org learning to build with AI, even though not one of us is an engineer. aiEDU is a nonprofit whose day job is preparing students for an AI world, not writing software. Everyone at aiEDU has a GitHub account, they’ve deployed software with a backend (Supabase) and a frontend (Vercel). Most of us are using VS Code. I’ve been using Conductor. A few folks prefer working directly in Terminal.

A team with no software developers built internal automations across the tools we live in, a website that lets districts assess themselves against our readiness framework, the workshop platform we now run our own sessions on. Things that would have cost us tens of thousands of dollars and months of lead time two years ago, made in an afternoon.

I’m proud of where we are. I’d wager that aiEDU is among just a handful of nonprofits in the country that are as far along in the journey.

But the further we get, the more I’m coming to terms with this problem being fundamentally different than a technology implementation. Now that we’ve more or less closed the gap on ability to use AI to build stuff, we’re faced with the question of “what’s next?” Generating an ever-larger set of rough prototypes and cool ideas has rapidly deminishing returns.

The next frontier is figuring out how to cultivate a team (and, really, teams) that can use AI.

Wim was a very early thinker about how to describe the challenge we are tackling. He dubbed it: AIQ — that is, a human’s ability to understand and productively use the jagged edge of AI capability.

AIQ essentially combines AI literacy and readiness. Understanding AI, and having the skills to leverage that understanding within and across organizations of humans. AIQ also manifests at the team level.

So we're back to critical thinking, communication, collaboration — durable skills.

Thus, we find ourselves back to critical thinking, communication, collaboration—durable skills. It's reassuring that someone who's actually lived through a technology revolution is landing in the same place.

aiEDU Studios published my interview with Wim that inspired this post today, and it’s a great complement for those more audio-visually inclined.

Echoes of our most recent technology revolution

If you’ve spent time around software teams, this will sound familiar, because the software world ran this exact experiment twenty years ago.

In the 2000s, companies fell in love with a family of product development methods called Agile. These methods promised speed: adopt the processes, stand-ups, and sprints and you’d ship faster. Plenty of companies got on board—but got almost none of the speed.

What they were missing didn’t have a name yet. It turned out you couldn’t just change how individuals worked. You had to change how the work moved between them, especially between the people writing software and the people responsible for keeping it running. That rethink eventually got its own name, DevOps, and the organizations that figured it out pulled away from the ones that didn’t.

DevOps is a shared machinery: common infrastructure, automated handoffs. It was a single place where the state of everything lived, so that coordination no longer depended on whether two people happened to talk that day.

AI adoption is on the edge of its own Agile moment. The tools are at times unbelievably powerful, and they’re widely available. Most organizations are getting individuals fluent and waiting for the team-level payoff to show up on its own. That didn’t happen automatically the last time around, and it probably won’t this time.

Now that we’ve seen success developing AIQ, or AI readiness, at the individual level at aiEDU, we’re focused on figuring out what it looks and feels like at the team and org level.

The part you can’t write down

So what’s the equivalent of DevOps for a team working with AI? Wim and I have been kicking that around on our podcast, and the piece we kept getting stuck on is more basic than infrastructure. It’s a certain kind of knowledge—one that you can’t actually relinquish to anyone.

Wim has a thought experiment for this: Sit down and write out everything you know. You’ll be busy for a very long time. Days or probably weeks later, when you finish and hand in the reams of documentation, you’ll find that very little of what you wrote down isn’t already part of an AI model’s dataset. That’s basically how language models work—they are built by training on the things humans can write down.

So what’s left? What do you have that the machine doesn’t? By definition, it’s everything you know how to do but can’t write down.

Wim’s example (that I’ve used quite a lot recently) is teaching a kid to ride a bike. You can’t write an instruction manual for it, have them read it, and watch them ride away. It doesn’t transfer that way. They have to wobble and fall and feel it. The knowledge lives in the doing.

Now take that up a level, which is where Wim, who turns out to be an avidcyclist who struggled to learn to ride as kid, took me. Riding a bike alone is one thing. Riding in a tight group is a different skill entirely. In a team time trial, eight riders take turns at the front cutting the wind while the rest draft inches off the wheel ahead. A well-drilled team rides maybe thirty percent faster than any of them could alone. You can describe how it works in a paragraph. The stronger riders pull longer, the weaker ones pull shorter, everyone rotates through.

But knowing the description and being able to do it are nowhere near the same thing. Eight strong riders who’ve never trained together don’t form a team time trial.

They form a crash.

The only way to get the real thing is to ride together, over and over, until the coordination becomes something the whole group can feel.

That’s the knowledge I think we’re missing at the team level with AI. Everyone at aiEDU can ride the bike now. Next up is learning to ride together in a paceline.

This gap exists in the context of AI models which are improving more rapidly than organizations are able to keep up. The individual skills some are racing to build with AI are the ones that AI keeps getting better at with every release. Agents are stringing those skills together now, running them without a person in the loop at every step. We’re pouring our energy into the level that’s getting less relevant, and mostly ignoring the level that isn’t.

What it feels like up close

I want to show you what this looks like when it actually happens, so I’m going to pass the pen to Wim.

Wim here: Earlier this year, I got the six of us in Kiswe Belgium into a room for a day. We’re all a little obsessed with AI, all building things on our own. I figured we’d show each other what we’d made and trade tips. What actually happened was more useful, and a little embarrassing. We’d each wandered off into our own corner. One of us had gone deep on one coding tool, someone else on another, a third on Claude. We’d built private workflows and private vocabularies. Lined up side by side, they barely fit together.

Then, sometime in the afternoon, it clicked for all of us at once. The realization had two parts. The first was small and practical: we should be using the same tool, so we standardized on one. The second part changed how we work. We’d been treating the code each of us produced as the valuable thing, the way developers have been trained for thirty years to treat code as a kind of craft; a sculpture you slowly chisel away at for months. It isn’t that anymore. Code is becoming disposable. The knowledge of what we’re building and why is, that is, the domain expertise, is more precious than ever, and that knowledge was scattered across more than half a dozen people.

So we built what we started calling a specification layer. Plain-language documents, readable and writable by anyone on the team whether or not they can code, holding the actual thinking: what each thing is for, how the pieces fit, what we’ve decided and why. The code hangs off that. We’ve since taken projects, thrown the code away completely, and rebuilt them from the specification in an afternoon, because the part that mattered was never the code. English became our shared programming language, which means our finance person and our engineers can finally build in the same direction. Two weeks on, people still refer back to the moment it clicked. We are getting together again soon for hopefully another such moment.

We hit a familiar wall

I realize I’ve watched a version of Wim’s story at aiEDU. We’d stumbled into the same need: somewhere shared and durable to keep the thinking, so that what one person worked out didn’t have to be rediscovered by everyone else.

And then, a few weeks after Wim’s workshop, Andrej Karpathy, the researcher who coined the term “vibe coding” in the first place, described almost exactly the same move to a very large audience. His version: stop pouring your effort into generating code and start pouring it into a living, maintained knowledge base that you and the AI both work from. It spread fast, because it named something a lot of people were starting to feel.

The shared layer is team’s home base, structured and maintained so that both people and the agents working alongside them can read from the same source. It frees the team to spend its attention on what can’t be written down, and it gives the agents the same reference everyone else has. The reason Wim’s team could throw away their code and rebuild from the specification in an afternoon is that the agents were reading the specification, not the code. The documents are infrastructure.

This isn’t a perfect solution, and there’s still a lot to figure out. When an AI compresses what it reads into tidy summaries, a small misunderstanding can quietly spread through everything linked to it. Keeping the layer accurate and honest, knowing what belongs in it and what to cut, is a judgment nobody has fully written down. Which is the whole point. Even the tool we build to capture what can be written down needs the part that can’t. AI doesn’t make the hard problem disappear, it moves it up a level.

Ride together first

If learning to use AI is like riding a bike (an anecdote I use a lot), team-level AIQ is learning to ride in a paceline. And there’s only one way to learn it: together.

And it’s best to do so before the race starts.

The teams that pull ahead over the next few years won’t necessarily have the strongest individual riders. They’ll be the ones who put in the wobbly, embarrassing laps early — while the stakes were low — and built the instincts that no document can hold for them.

Those of us in education and training should sit with that. We’re shaping what the next generation learns to do with AI, and almost everything in the field is still aimed at individual literacy. But the tasks we teach as “AI literacy” are the same tasks AI absorbs with every release. Readiness is what endures, and readiness gets built at the level of the team.

Notice what it took for Wim’s team: one room, one day, everyone showing what they’d actually built. No framework, no consultant. If you run a team, you don’t need permission to try this. You need a date on the calendar.

Get your people in a room. Ride together. Crash a few times now, while it’s cheap.