Every team I know treats re-explaining the same way: as evidence that something went wrong. Somebody didn’t listen, didn’t read the doc, didn’t pay attention. Fair enough. But what if re-explaining isn’t a symptom of a broken team? Maybe it’s one of the most important things a team does. We’ve just built our work to treat it like an interruption.
It’s astounding to me how much I’m learning about humans by working with AI.
Last week, I used a team of AI agents to help with a big project. I did everything I’ve learned to do. I built a clear folder structure for the agents to work in, with clearly named files and an index to explain what was there. I set a clear goal, with a meticulous rubric defining what “good” looked like. I built a workflow with built-in checkpoints so I could either do the work myself (the parts I was uniquely good at) or review work the agents had done.
Objectively, I know that my human-AI hybrid workflow saved me time. But the experience was agonizing. I spent a shocking amount of time re-anchoring the AI in context it already had.
It treated all my guidance as equally important. When I specified which criteria were most important, it magnified that distinction until I regretted ever making it.
It took me so literally that it was painful. Or, conversely, it would make ludicrous assumptions that would impact downstream work. In all these cases, it was difficult to see how it reasoned its way to these mistakes.
Why is working with AI so aggravating (and what does it reveal about teams)?
Working with AI is 10x more aggravating than anything I’ve experienced working with humans (even though it’s still pretty neat.)
I think that’s because the revision cycles are so short. When the work happens at lightspeed, and only my reviews and revisions are slow, it can feel like all I’m doing is managing misalignment.
An AI revision cycle takes minutes. A human handoff takes days, sometimes weeks. So working with AI, I watch understanding fall apart and get rebuilt dozens of times in a single afternoon. The same breakdowns I see between people, just sped up. Watching dysfunction happen so rapidly is a wild experience. Years of data on a very old problem, compressed into a couple of weeks.
And after weeks of watching it happen on a loop, a suspicion set in. All that re-anchoring, with the agents and with each other, might be doing more than cleaning up mistakes. It might be the thing that keeps the work from flying apart. We just don’t treat it that way.
Why do we think poor explanations are behind poor execution?
Re-explaining feels wasteful. We wonder whether we could have moved faster if we had explained ourselves differently, or if someone else had listened better. When we have to re-explain a lot, we believe we’re experiencing dysfunction.
And honestly, it’s a reasonable belief. The explanation is the element that kicks off the work, and it’s something we feel we can control. The problem is that explanations come loaded with the expectation that other people will understand, apply, and remember them. When the work comes back wrong, either the explainer or the doer is blamed (or both).
We believe that if we could just find the right words, or create the right “alignment document,” then we could move faster.
“The best ones don’t re-explain less than the bad ones. They just re-explain better, and on purpose.”
But I’ve adjusted my process with AI approximately 20 million times, testing (in extremis) the theory that I can reduce re-explaining with the right set-up. I’ve tested a ridiculous number of workflows, context management approaches, prompt instructions, and rubric formats. I’ve tested work on cheap models and expensive ones.
Setting aside the very simple work (which doesn’t take a lot of explaining anyway), I’ve seen fast advancement in the quality of output with each technique I employ…but only a negligible reduction in the work of re-explaining what I want.
Re-anchoring with my agents never trended toward zero. It wasn’t a phase we got past. And when I stop to think about my human teams, I realize the same is true. (I’ve written before about why motivated teams still drift out of alignment, here.) The best ones don’t re-explain less than the bad ones. They just re-explain better, and on purpose.
Understanding isn’t delivered. It’s rebuilt, on a loop.
In 1991, psycholinguists Herbert Clark and Susan Brennan gave this a name: grounding. Their research showed that understanding doesn’t transfer the moment you say the words. It gets built, together, in a loop, through cycles of feedback and repair.
Joint actions require common ground: mutual knowledge, beliefs, and assumptions. Teams use those to build shared understanding about their work. But the most interesting thing to me about their research is called the principle of least collaborative effort. It’s the idea that people try to minimize the overall collaborative work required to achieve mutual understanding.
We try to explain things all at once so we don’t have to go back and forth with questions and answers. We use shortcuts and acronyms. We expect people (including ourselves) to remember past conversations and keep up with our shorthand. And my favorite, transactive memory: teams don’t remember everything. They remember who knows what. That works beautifully right up until the person holding the knowledge goes on leave or takes another job.
Put this all together and re-explaining stops looking like a failure at all. For the leaders and teams running complicated, ongoing work (shifting requirements, real judgment calls, more people than fit around a dinner table), re-grounding is the one thing that might cut misalignment off at the knees. If we do it on purpose and by design.
And re-grounding is the better word for it. Re-explaining is reactive: something went sideways, so I say it again, and somebody feels blamed. Re-grounding is proactive: you rebuild shared understanding on purpose, before it turns into rework. Same words, sometimes. Completely different intent. It’s the same logic I use when I diagnose stalled execution: the failure is rarely the person who “didn’t listen.” It’s a system that never made rebuilding understanding easy or safe.
The best teams build re-grounding into their process
The best teams answer a re-grounding question in a way that re-grounds everyone who needs it, not just the person who asked. The same week I was elbow-deep in re-anchoring the AI, I sent a coworker a quick question about one of our internal processes. I thought we did it one way. It happened differently. I wanted to know why.
What came back was one of the tidiest little pieces of process improvement I’ve seen. Within a few hours, she replied to me and copied everyone else involved, so we all heard the same answer at the same time. Her email had four parts:
- The question I’d asked (so the others were caught up)
- How our process actually works today (it was different than I thought)
- What happened differently this time and why, and
- Two things we would do going forward to address my concern
That cost her maybe ten minutes. It re-grounded four people at once, in writing, when a simple reply back to me would have solved today’s problem.
“The failure is rarely the person who ‘didn’t listen.’ It’s a system that never made rebuilding understanding easy or safe.”
AI has taught me a lot about re-grounding. And the lessons matter for human teams.
AI turned out to be a strange teacher, because it pretends as much as any human does. It nods along, fills in gaps with confident guesses, and hands back plausible work that isn’t what I asked for. The difference is speed and volume.
“A person pretends slowly and politely, so you can miss it for weeks. AI pretends fast and constantly.”
A person pretends slowly and politely, so you can miss it for weeks. AI pretends fast and constantly, dozens of times in an afternoon, until you have no choice but to watch for it. And the only thing that works reliably is deliberate re-grounding. Here’s what that can look like, for AI and for human teams:
- Make document repositories useful, not just available. I handed the agents a tidy folder and an index, and they still skimmed the files they opened and guessed at which ones were current. It stung, because I do the same thing to my teammates. I drop a document in a channel and treat the sharing as the whole job. But a link isn’t grounding. People need to know what a thing is, whether it’s still true, and what it’s for. Otherwise they guess, same as the agents.
- Define “good” out loud, before the work starts. Then evaluate in-progress work against it. The rubric was my single biggest lever with the agents. Say what good looks like up front, and the first attempt comes back close. Skip it, and you end up re-explaining something you never actually explained. Human handoffs skip it constantly. We assume we agree on what “good” means, then find out we didn’t when the work comes back. Scrum retros and demos function this way. They incorporate designed-in opportunities to realign, re-explain, and re-ground on both what is being produced and how the work is being done…whether or not something is visibly broken.
- Ask for the reasoning, not just the result. The AI mistakes that scared me most were the confident ones I couldn’t trace back to anything. So I started asking the agents to show their thinking. That turns out to be the cheapest re-grounding move on a human team, too. “Walk me through how you got here” catches a shaky assumption while it’s still cheap to fix, instead of three weeks downstream.
- Put the whole ask in one place. When I scatter a request across five prompts (a constraint here, a correction there), the agents stitch together some Frankenstein version of what I meant. When I write the goal, the constraints, and the context in one shot, the first pass is night and day. I still iterate and re-explain, but the output is measurably better from the get-go. People aren’t much different. A lot of re-explaining traces back to an original ask that came out in fragments, so everyone filled the gaps with their own guess. The fix isn’t a longer brief. It’s a complete one, in a single place someone can regularly reference.
- Specify the shape, not every step. This is the one I’m still calibrating. With AI, I can dictate every move and nothing pushes back. With people, that same instinct is micromanagement, and it drains the team you’re counting on. The re-grounding version is lighter: agree on what the work should look like and the few points where you’ll check in, then leave the path to get there open. Name what “done” means and when you’ll sync, and you stay grounded without hovering. I won’t pretend I’ve found the exact ratio, but leaning toward shape-and-sync has cost me far less than leaning toward step-by-step.
None of these are AI tricks. They’re the habits I should have built with people years ago and didn’t, until a machine made the cost of skipping them impossible to ignore. The common thread is this: stop treating re-explaining as a sign that something went wrong, and start treating re-grounding as a task worth scheduling.
If You Only Do One Thing
Next time someone asks a question that exposes a gap between what they thought and what’s true (the “wait, I thought we did this differently?” moment), answer it the way my coworker did. Write back with four things: the question they asked, how the process works today, what happened differently this time and why, and one or two takeaways (e.g., options to close the gap, questions/decisions about whether the process needs to change). Then send it to everyone who needs that same grounding, not just the person who asked.
You’ll be doing something rare: re-grounding on purpose.