If there is an overarching assumption that nontechnical people have about technology, I am convinced it is that technology solves problems. I am also convinced this is not only a fallacy but a dangerous assumption that often backfires, causing problems rather than fixing them.
I have consulted with more than a few organizations and businesses that have virtual closets full of unused or underused hardware and software. Although I do not want to blame salespeople, many make spurious claims about the abilities of their products. Worse, some do not take the time to learn what customers need. This is not just the fault of the salesperson. Many times, the clients do not know either. Often, the client has not taken the time to learn what they need or even how they do what they do.
Here is a real-world example. In the early 2000s, I determined that no existing software fit the needs of an organization where I was CTO. Nothing commercially available fit the practices and processes we used and modifying existing packages increased the complexity beyond what the staff — mostly nontechnical academics — were able to understand. The important words here are “fit the practices and processes we used.” I only knew that because we took the time to write down how we did what we did, and these practices were consistent and replicable. My goal was to match software with the existing processes, and, unfortunately, it did not exist.
So, we created it. We created an application that mirrored existing processes. When those processes changed, so did the application. To be sure, it was an investment that included full-time coding staff. But, at least at the time, this was a necessary investment that paid in institutional efficiency and workflow.
Within a few years, I started getting requests to sell the software to other organizations. My response was, consistently, there is nothing to sell you unless you are going to duplicate what we do and how we do it. Most found this hard (if not impossible) to understand. Their assumption (there is that word again) was that the software would/could fix their problems. Yet, when I probed a bit, they were unable to identify their exact problems, let alone how they might implement this technology. With one of these organizations, I interviewed their staff and discovered they had little consistent practice they could track and no institutional process to monitor or evaluate.
Increasingly, I see technology professionals focusing on the science of technology. We need to spend more time on the art of strategic technology planning, which includes soft skills like user experience, knowledge sharing and how people really do what they do. Let us flip our mindset from one in which technology leads processes to one in which technology enhances existing processes. This will require re-educating users to do the same because many (dare I say most) expect technology solutions to cure all their ills. Often, that is because they do not have a clear idea of what their processes are and hope technology will clarify them. Most times, it will not and can even make things worse.
It is harder to match a technical solution to existing processes than buying the latest whiz-bang solution. But our job as technology professionals is to listen, ask probing questions and use our experience and expertise to make good recommendations. This is itself a process that separates tech leadership from tech management or integration. Be a leader, be strategic and be a problem-solver!