top of page

When Efficiency Misses the Point

Early in my career, I was asked to help modernize a business process that had been in place for decades. Before I wrote a single line of code, I was sent to spend time with one of the most experienced people in the organization.


She pulled an extra chair into her cubicle, slid a stack of reports across the desk, and said, "If you're going to change this process, you need to understand why it works the way it does."


For the next several hours, she walked me through the process exactly as she performed it every month. One report led to another. A verification depended on a conversation with someone in another department. Printed reports triggered phone calls. Calendars determined when the next step could begin. What I thought would be a conversation about technology quickly became a lesson in how work actually happened.


Every few minutes she would pause and remind me, "Technology isn't going to solve this."


At the time, I assumed she simply didn't want the new system.


It took me years to realize I had misunderstood what she was trying to tell me.


As we continued talking, another employee stopped by her desk with a question about the same process. She answered it without hesitation. Every dependency, every exception, and every nuance was already in her head. Watching that interaction, I could see why people sought her out. She wasn't valuable because she knew how to navigate an antiquated application. She was valuable because she understood the business well enough to guide other people through it.


I saw someone who had mastered a complicated process.


What I didn't recognize at the time was how much of her contribution extended beyond the process itself. She had become the person others depended on to understand it, teach it, and keep it working.


That perspective only came later.


At the time, I believed we were redesigning a process.


What I didn't appreciate was that we were also changing the role she had spent decades building.


Over the years, I've thought about that conversation more times than I can count. I've watched organizations implement enterprise systems, analytics platforms, cloud technologies, digital transformation programs, and now AI. The technology has changed dramatically. The questions people quietly carry with them have remained remarkably consistent.


  • Where do I fit?

  • What value do I still bring?

  • How does my experience matter now?


Those questions are rarely voiced in project meetings, yet they influence almost every transformation effort I've experienced.


It's easy to interpret hesitation as resistance. Sometimes that's exactly what it is. More often, I've found that people are trying to understand whether the strengths that made them successful yesterday will still matter tomorrow. That isn't simply a technology question. It's a leadership question.


Years after that project, I found myself thinking about that conversation very differently.


My business partner wasn't trying to convince me that technology would never improve the process. She was trying to help me understand why the process had become so complicated in the first place. Some of the extra reports, verification steps, and conversations had been added because the business had already experienced costly problems. Others reduced regulatory risk or prevented errors that no one wanted to repeat.


What appeared inefficient to me as a young developer often reflected years of practical learning. The process wasn't simply a collection of steps. It represented the organization's accumulated experience with problems it had already solved, risks it had already encountered, and mistakes it had worked hard not to repeat.


That experience continues to shape the way I think about transformation today.


When I walk into an organization, I'm certainly interested in where work can be simplified. I'm equally interested in understanding why the work evolved the way it did.


Every process tells a story. Some steps exist because they no longer serve a purpose. Others exist because someone discovered a risk, solved a difficult problem, or protected the business from repeating a mistake. Before deciding what should change, leaders benefit from understanding the difference.


I've found it helpful to begin those conversations with questions rather than solutions.


  • Help me understand why this step exists.

  • What problem was this designed to solve?

  • If we removed it tomorrow, what would we lose besides time?

  • Who understands this process well enough to tell us what isn't written down?


Those conversations accomplish more than gathering requirements. They uncover judgment, experience, and institutional knowledge that rarely appears on a process map. Just as importantly, they demonstrate respect for the people who know the work best. When people know their experience is respected before the redesign begins, they are far more willing to help shape what comes next.


I've seen some of the strongest advocates for change emerge from people who initially appeared to resist it. The turning point wasn't better communication about the technology. It was helping them recognize that the organization still needed what they had spent years developing. Their value had never been the system. It was their judgment, their relationships, and their ability to help others navigate complex situations.


My coaching conversations have reinforced that lesson for me. Leaders rarely ask whether AI will change their organizations. They already know it will. The conversations usually sound more like this.


  • How do I help people embrace change without dismissing everything they've contributed?

  • How do I preserve trust while asking experienced employees to work differently?

  • How do I help people recognize that their greatest value isn't found in the process they've mastered, but in the wisdom they've developed along the way?


Those questions don't produce quick answers, but they consistently lead to better leadership.


Looking back, I don't think the most important lesson from that early project had anything to do with software.


It taught me that every technology initiative changes more than a process.

It changes how people understand their contribution.


Leaders who recognize that reality approach transformation differently. They don't assume that explaining the technology is enough. They take time to understand what people are protecting, what experience the organization cannot afford to lose, and how that experience can help shape the future instead of being left behind.


In my experience, that's where lasting adoption begins. It doesn't begin when people learn to use a new system. It begins when they can see themselves contributing with confidence in the future that system is helping to create.

About the Author


Karen R. Edwards is an executive coach, leadership advisor, and former Fortune 50 technology executive with more than three decades of leadership experience. She is the Founder of KE Speaks, where she publishes thoughtful perspectives on leadership, organizational transformation, and how people, technology, and leadership shape organizational outcomes.



Comments


Commenting on this post isn't available anymore. Contact the site owner for more info.
bottom of page