Automation often looks simple from the outside.
Step one: find a repetitive task. Automate it. Save time. Improve efficiency.
But anyone who has led a major automation effort knows it rarely works quite that neatly.
I saw this firsthand while working with robotic process automation (RPA) in accounts payable. On the surface, invoice processing seemed like an ideal candidate for automation. It involved repetitive work, defined rules, and opportunities to improve speed and efficiency. But once we started looking at the entire process, it became clear that we weren’t simply automating tasks. We were changing a system.
Invoices came from vendors. Information moved through different processes and teams. Rules determined what could be approved and what required attention. People handled exceptions. Procurement, operations, accounts payable, and vendors all interacted with different parts of the process.
Changing one piece could affect several others.
That experience reinforced an important leadership lesson for me: when you change part of a system, you need to understand what happens to the rest of it.
That is where systems thinking becomes valuable.
What Is Systems Thinking?
Systems thinking means looking beyond an individual problem or task and considering how the different parts around it are connected. Instead of asking only, How can we make this task faster?, a systems-thinking leader might also ask: What happens before this task? What happens afterward? Who else depends on it? If we change it, what else might change? Those questions can reveal problems and opportunities that aren’t obvious when we look at one task in isolation. Our automation work taught me several practical lessons about doing this well.
1. Check What’s Connected
When something isn’t working after a technology implementation, it’s easy to assume the technology is the problem. But sometimes the problem isn’t the technology at all. Imagine invoices begin lagging after an automation launch. The immediate reaction might be to look for a bug in the bot. But what if vendors weren’t included in the change and don’t understand how the new process works? The technology may be functioning exactly as designed while the larger process is failing. Before fixing what appears to be broken, step back and ask who and what is connected to it. Sometimes the missing piece isn’t technical. It’s people.
2. Look for Repeat Loops
Automation can make a task faster without making the overall process better. Suppose an automated process moves invoices more quickly, but the same problems continue bouncing back to vendors or operations teams for correction. We’ve improved the speed of one step, but we haven’t necessarily solved the problem. We may have simply moved it somewhere else. That’s an important distinction. Faster doesn’t always mean smoother. When the same issue keeps returning, look for the pattern rather than treating every occurrence as an isolated problem.
3. Slow Down Your Judgments
When something goes wrong, we naturally want to identify the cause. Sometimes we do that too quickly. A processing delay might look like a technology failure when the real issue is overly restrictive rules, inconsistent information coming into the system, or a threshold nobody considered during implementation. Before assigning blame, trace the problem through the process. Good systems thinking requires judgment discipline: understand what happened before deciding why it happened.
4. Watch for Delayed Impact
Not every problem appears on day one. An automated approval process might work beautifully when it launches. Two weeks later, stakeholders may discover that the rules are too rigid for situations the project team didn’t anticipate. That doesn’t necessarily mean the original solution was poor. It means real-world use revealed something the design process didn’t. Leaders need to think about both now and later. Ask what might happen after people have used the new process for a while. Where could exceptions occur? What happens when circumstances change? A successful launch is important, but so is what happens after the launch.
5. Look Upstream and Downstream
One of the easiest mistakes in process improvement is optimizing one team’s work while unintentionally creating more work for someone else. A bot may eliminate a repetitive accounts-payable task, for example, while causing vendors to contact procurement more frequently because they no longer understand what is happening with their invoices. From one department’s perspective, the process improved. From the organization’s perspective, maybe it didn’t. When changing a process, look upstream and downstream. Ask who provides the inputs, who receives the outputs, and what effect the change could have on them. Local improvement isn’t always system improvement.
6. Look for the Bigger Pattern
One failed implementation can be an isolated problem. Repeated failures deserve a different question. If every automation initiative seems to encounter similar resistance or delays, the problem may not be the individual technologies. It may be how change is introduced across the organization. Perhaps teams aren’t being involved early enough. Perhaps communication happens too late. Perhaps implementation moves faster than adoption. When something keeps happening, zoom out. Patterns often tell us more than individual events.
7. Lead the Change, Don’t Just Announce It
A technically flawless rollout doesn’t guarantee people will use it successfully. People need to understand what is changing, why it is changing, and how it affects their work. That requires more than sending instructions. It requires leadership. Before launching a change, ask whether the people affected by it understand the purpose and see the value. Listen to their concerns. Give them an opportunity to ask questions. Implementation is something we do to a system. Adoption happens through people.
8. Listen to the People Closest to the Work
Leaders and project teams don’t always have the best view of what is happening. Sometimes the person who sees the problem first is the person doing the work every day. An accounts-payable analyst, for example, may notice exceptions or patterns that a project team never considered. A vendor may see a communication problem that isn’t visible inside the organization. Those perspectives aren’t obstacles to implementation. They’re information. Ask: Who is closest to the signal? Then listen.
9. Balance Action With Reflection
Go-live isn’t the end of an improvement effort. It is the beginning of learning how the change performs in the real world. After implementation, make time to ask: What worked? What didn’t? What surprised us? What should we do differently next time? Without that reflection, organizations can repeat the same problems from one project to the next. Reflection isn’t inactivity. It is part of improvement.
Systems Thinking Is Really About Seeing More
Systems thinking can sound like a complicated management concept, but its practical application is surprisingly simple. Look beyond the task in front of you. Look at what feeds into it and what comes out of it. Look at the people affected by it. Look for patterns. Watch what happens over time. Listen to the people closest to the work. And after making a change, stop long enough to learn from what happened. Automation gave me a practical way to see these lessons, but they apply far beyond automation. Whether you’re introducing new technology, redesigning a process, leading organizational change, or simply trying to solve a recurring problem, sometimes the most important thing a leader can do is stop looking at the individual piece and start looking at the system around it.
Coach’s Corner Reflection: Think about a change or recurring problem you’re dealing with right now. Are you trying to fix one part of it—or have you stepped back far enough to see what it’s connected to?