Leadership in Loops

“X” is abuzz this week with talk of AI skills, and just as loudly, with loops. I’ll leave the skills debate for another day. What’s had my attention is the loop, or more specifically, the AI Loop.

A quick, generic definition: an AI Loop is a system that takes an action, observes what happened, adjusts, and acts again, without a person approving every individual step. The oversight happens at the level of the system, not the level of the task. That’s what makes it scale. That’s what makes it fast. That’s what makes it, in a strange way, trustworthy. It’s built to correct itself instead of waiting to be told it’s wrong.

Picture a racetrack. It’s a loop for a reason. A driver doesn’t get told how to take each corner one at a time. They run the lap, feel what worked and what didn’t, and adjust on the next one. Nobody’s radioing instructions mid-turn. That’s the loop working.

The more I read about AI Loops this week, the more it remined me of my own department. Consider this: a micromanager is basically a driver who has to radio the pits after every corner and wait for permission before the next one. A loop is the opposite. It’s a driver who gets to run the lap and adjust on their own read. That’s what leadership looks like when you actually trust the system you built. That’s the parallel that kept pulling at me all week.

Three years ago I took over a team that was underperforming. On paper, that sounds like a talent problem. It wasn’t. I inherited capable people who’d been managed into a defensive stance. The prior structure ran on checkpoints or outright task removal while simultaneously making every decision route back up before it moved forward, every project sliced into silos narrow enough that no one held the whole picture. The team was fully capable. They were just never given a loop to run. They were given a queue to wait in.

Here’s what that actually looks like day to day: a person sees a better way to handle a task, sits on it, because raising it means a meeting, and the meeting means a decision that isn’t theirs to make. Multiply that by every person, every week, and you get an organization that looks busy and produces slowly. The silos made it worse. Nobody could see how their piece connected to the outcome, so nobody optimized for the outcome. They optimized for not getting flagged.

I didn’t restructure the team. I restructured the loop. Gave people the context behind the goal, not just the task. Gave them the authority to act on what they saw, not just what they were assigned. And this is the part that mattered most: I let them see what their decisions actually produced, instead of filtering every outcome back through me first. That last piece is the whole mechanism. A loop only works if the person acting can see what happened and adjust. Cut that feedback path and you don’t have a team, you have a chain of approvals with people attached.

The results weren’t subtle. People started finding opportunities nobody had assigned them, because for the first time, spotting an opportunity and acting on it were the same job. Output changed. But so did something harder to measure: people started thinking like owners instead of executors. I had one rule: treat your job like your own small business. That shift doesn’t happen in a system built on checkpoints. It only happens in a system built on loops.

Here’s the objection I’d expect, and it’s a fair one: doesn’t “let them run the loop” just mean no oversight? No, it means oversight moves. A leader in a loop-based system isn’t reviewing every decision. They’re building and maintaining the loop itself: setting the goal clearly enough that people can self-correct against it, making sure the feedback signal people receive is accurate, and stepping back in only when the loop itself is broken, not when a single output looks different than they’d have done it. That’s a harder job than approving tickets. It’s also the only version of leadership that scales past the number of decisions you can personally review.

Which is the real question underneath all of this. Every organization racing to build AI systems that act, observe, and improve on their own should look at their own management structure first. Are we building that same loop into our people with context, authority, visibility into outcomes, room to adjust? Or are we still routing everything through ourselves and calling it leadership?

The team I inherited didn’t need new skills. They needed a system that let them use the ones they already had. Most underperforming teams do.

AI is about to hand every organization a faster engine. Speed without leadership structure isn’t an advantage. Think back to that racetrack. A Sunday driver dropped into a Formula One car doesn’t suddenly know how to read a lap. More speed just means the same bad habits happen faster, right up until the wall. A trained driver uses every loop around the track as information: brake a little later here, carry more speed through that corner, adjust the line on the next pass. That’s what separates them. Not the car. The loop.

Don’t hand your people a faster car until they know how to run the loop that comes with it.