15 Nov Technology and democracy
The election is over. Discounting some mutterings on the Internet, it appears to have worked as intended. That’s not an assessment of the outcome, but rather of the process.
Yes, we appear to have some wildly divergent opinions of what’s important and where we should be headed as a country. Yes, there was some, shall we say, unpleasantness and less than optimal integrity during the campaigning. Certainly it will take us many years to fully understand all the impacts of this election. However, we voted in record numbers. We made a collective decision using established guidelines, and most of us are moving on.
Don’t you wish your business could say the same about your major technology decisions? If we can get over 100 million people to participate in a contentious election and then abide by the results, why can’t we get that guy from finance to talk with the analyst and architect in development about how the invoicing system should work?
Some of the problem stems from history, or rather lack of it. Our elections are a fascinating blend of custom and protocol, process and statute, technique and technology, and we’ve had more than 200 years of practice. It’s only in the last 20 years that technology has become a ubiquitous, if not always visible, presence in every significant business activity.
Despite billions and billions of dollars spent and millions and millions of hours of effort, we still have not completely assimilated technology into our businesses. Most businesses don’t have a commonly held picture of the custom and protocol, the process and statute, the technique or even the technologies that are the focus of our decisions.
For many years we’ve tended to focus all our energy on the technology side of the equation. The religious wars of mainframe vs distributed computing, C++ vs Cobol, Java vs .NET and so on absorbed all our attention as if resolving these questions would yield some stable technology nirvana. As technology reached its tentacles deeper into our organizations, there was a backlash and we focused most of our attention on the processes and procedures, the business needs, the requirements and the business cases. But we still ended up with less from our technology than we had anticipated. Kind of like election-year promises, I guess.
That idea of an election-year promise illustrates a key difference between elections and technology decision-making. We know an election-year promise is something less than a certainty. We’re quite adept at listening to the tone, the feel, the energy of a promise and responding to it with our support, expecting the election to be followed by discussion, debate, and experimentation. The reality emerges from that shared work of the community, not from the words of some campaign speechwriter.
With technology, we’re not so capable. Whether it’s some clever Madison avenue phrase, an executive with a flight magazine in his or her hand, or a technologist full of evangelical fervor, we hear the promises as if they were accomplished facts.
What’s a leader to do? The CIO, the VP of manufacturing, the senior technologist, the best customer rep on the help desk – what are we to do?
We’ve tried focusing on the technology. We’ve tried turning our attention to the business, with its plans, priorities, and processes. Neither approach has been satisfactory. Perhaps we should start treating technology as an election-year promise. Not something to be wholly discounted, but not something that provides a clear map to reality either.
In addition to all those requirements and specifications, we should begin to put some energy into dialog and experimentation. Rather than assuming the promise is the answer, we can take it as a starting point for a broader discussion. We can build communities of users, sponsors, technologists, managers, and anybody else who feels the brush of technology rumbling through their work day. Those communities will have discussions, do experiments, and make the necessary compromises.
It is from these communities that the reality of technology in our businesses will emerge. Yes, we have to feed and guide them with requirements and specifications, but we also must engage them wherever they are focused. All the business analysis and all the architectural design in the world won’t drive a single penny to the bottom line if the communities that are our workplaces don’t assimilate and accept the technologies we buy and build.
Byron Glick is a principal at Prairie Star Consulting, LLC of Madison Wis. Prairie Star specializes in managing the organizational impacts of technology. He can be contacted via e-mail at email@example.com or via telephone at 608/345-3958.
The opinions expressed herein or statements made in the above column are solely those of the author, & do not necessarily reflect the views of Wisconsin Technology Network, LLC. (WTN). WTN, LLC accepts no legal liability or responsibility for any claims made or opinions expressed herein.