| Margin. |
Field notes on leadership |
Nº 11 |
|
|
Dispatch · to the desk of one working leader
Keep both versions alive until the review.
| Five minutes every Tuesday |
October 2026 |
|
|
The observation
On Saturday mornings, my friends and I built kites. Brown paper when we could get it, plastic bags when we couldn't, held together with string and glue, with thin tree branches for the arch. Paper was hard to find where I grew up in Africa, so we used whatever we could find.
We built several at a time. Some broke before they took off, because our materials were far from sophisticated. The plastic ones flew with a noticeably different smoothness from the paper ones, and the only way to learn that was to fly both. There was no telling on the ground which kite would hold in the air, so we kept trying versions until one did.
There's a word for what we were doing. James March, the late Stanford organizational theorist, used it in a 1991 paper: exploration, the work of trying things whose return you can't yet see.
That word comes back to me as I watch organizations decide how to try out AI. The tools are new, and there's no telling in advance which use will hold. The default response is one cross-functional working group, given a quarter to bring back the answer. It's a sensible way to spend a scarce budget.
|
|
The pattern
James March split organizational learning into two activities that compete for the same people and the same money. Exploitation is the work of getting better at what you already do, and exploration is what we were doing on Saturdays: experimentation and play. Run alone, March wrote, exploitation leaves a system "trapped in suboptimal stable equilibria," and exploration leaves it with "too many undeveloped new ideas."
The pull between them is uneven. Because exploitation pays this quarter, in the department that funded it, and the returns from exploration are "less certain, more remote in time, and organizationally more distant," each sensible decision tilts toward refinement. Over enough of those decisions, an organization can get so competent at its current way of working that a better one goes untested.
Seen through James March's distinction, the single working group is presented as exploration and built like exploitation: one approach, refined under a deadline, by a team expected to return with the answer.
James March's model shows the alternative. Several independent projects, set against one coordinated effort, produce a lower average and more variation at the top, which is where the best result tends to appear. Coordination, in his phrase, comes with "a smaller chance of primacy."
Herbert Robbins, a mathematician, worked on a compatible problem in 1952: two coins, unknown odds, a dollar for every head. "The whole problem," he wrote, "lies in deciding how to draw the sample." Picking one coin at random and sticking with it could give up as much as 50 cents a toss compared with always tossing the better coin. The single working group is that first rule. His strongest rule kept tossing both, shifted toward the one that was paying, and tested the other less and less often without stopping.
What AI has changed is the price of exploration. A small team with current tools can put a rough working version of a process together quickly, which makes a second attempt affordable. Which leaves a harder question for you as the sponsor: if exploring is within reach of a small team, is one working group still the right number?
|
|
Hold this line
If you can't yet say which version will work, you're still exploring, so fund more than one.
|
|
The move
The moment. Your department is transforming, and AI is part of it. Sooner or later you'll be asked to decide how your team's work should change.
The check: explore or exploit? Ask one question before you decide: can anyone on your team say which version of the new way of working will hold? If not, you're still exploring, and committing to one answer now means exploiting a guess.
1. Explore with your people. Ask two small groups from your team to each sketch how the work could run with AI, separately, and to bring their version back in three weeks. One group might keep the steps as they are and let AI take the repetitive parts, while the other rebuilds the steps around what AI can now do.
2. Exploit the version that works. At the review, choose one and give it what exploitation needs: the budget, your strongest people and a quarter to refine it. Keep one person exploring alternatives a few hours a week, so that when the tools improve again, someone on your team has already tested what comes next.
Say this: "Before we lock this in, I want two versions from you, each taking a different approach to the same work, and we'll compare both in three weeks."
What it costs. Some effort goes into the version you don't choose, and that effort buys you a real comparison at the review. Tell both groups at the start how the choice will be made.
If you're on the team: offer your sponsor a lean second version for the review.
Tell me what happened. Try it the next time your team's work is up for change, and reply with whether you were exploring or exploiting. I read every reply, and I'll share what readers found in a future edition.
|
|
Explore before you exploit. Choose after you have seen them both.
See you Tuesday.
Rui
|
|
|
|
If someone came to mind while you were reading this, send it to them.
Someone forward this to you? Margin. is free, five minutes, every Tuesday.
|
Five minutes every Tuesday Margin. · Nº 11 |
End of dispatch |
|
|