The New Leadership Skill: Systems Thinking
Why the way you think about your team has to change before your agents go live
My team is building a zerotouch automation process. The idea is straightforward. A set of agents handling routine operational work without human intervention, freeing the team for higher complexity problems that actually require judgment.
When we sat down to design it, the first instinct was to build one agent. One system that ingests the work, processes it, and outputs the result. Clean. Simple. Easy to explain.
I’ve seen that instinct before. It shows up every time a team designs something new. Put it all in one place. One system, one owner, one throat to choke when something goes wrong. It feels like simplicity. It isn’t.
I pushed back. Not because of the technology. Because of what I know happens when one person does every job.
The monolith problem isn’t new
In infrastructure, we stopped building monoliths years ago. Not because distributed systems are easier to build. They’re not. We stopped because a monolith that fails takes everything down with it. One point of failure. No natural boundaries for isolating problems. No way to scale the parts that need scaling without scaling the whole thing.
We learned that lesson the hard way, more than once, before it became standard practice.
My team was about to relearn it with agents.
A single agent handling everything looks manageable until it isn’t. When it fails, and it will fail, everything stops. When it drifts, and it will drift, there’s no checkpoint where the drift becomes visible before it compounds. When it makes a bad decision, there’s no handoff point where a human or another agent can catch it before the downstream effects land.
That’s not a technology problem. That’s a system design problem. And it’s a leadership problem before it’s either of those things.
Decision rights at scale
The second concern was about oversight. One agent with broad decision rights and no natural boundaries is a system that can travel a long way in the wrong direction before anyone notices.
This is the part that leadership frameworks don’t address. When you delegate to a human, you have a conversation. You check in. You read the signals that tell you something is drifting. The human pushes back, asks questions, flags confusion. There’s a natural feedback loop built into the relationship.
An agent doesn’t do any of that. It executes. Continuously. At whatever speed the work arrives. If the decision rights are too broad and the oversight checkpoints are too few, you don’t find out something went wrong until the output lands and the damage is already done.
Breaking the zerotouch process into smaller agents with defined roles solves both problems at once. Each agent has a bounded scope. A specific set of decisions it is authorized to make and a clear handoff point where its work passes to the next agent or surfaces to a human. When something breaks, it breaks in one place. When something drifts, the handoff is where you see it.
That’s not just better architecture. That’s a manageable system. And manageable systems are the only kind worth building.
What systems thinking actually looks like
I didn’t walk into that design conversation with a framework in mind. I walked in with 18 years of knowing what breaks and why.
The instinct to distribute responsibility, build in redundancy, and create natural observation points isn’t something I learned from a leadership book. It’s something I learned from watching monolithic systems fail at the worst possible moments. From being the person on call when everything went down because one component took everything with it.
That experience is systems thinking. It’s just been applied to infrastructure for most of my career. What’s changing now is that the same mental model applies to the teams and workflows I’m responsible for leading.
Leaders who came up through technical disciplines have an advantage here that most of us haven’t named yet. We already think in failure modes. We already ask what happens when this breaks. We already know that a system with no natural boundaries is a system with no natural recovery path.
The leaders who will struggle are the ones who learned to manage humans through relationships and presence, and haven’t yet made the translation to systems that don’t have either. Not because they’re less capable. Because nobody told them the mental model needed to change.
The question I’m sitting with
Think about the last time you designed a workflow that included an AI agent or automation. Did you think about what happens when it fails? Did you define the boundaries of its decision rights before it went live? Did you build in observation points where drift becomes visible before it compounds?
If the answer is no, you didn’t design a system. You built a monolith. And somewhere downstream, it’s waiting to take everything with it.