Brain-Numbingly Strategic

Eric Hawley, CIO at Utah State University and a professor in the Jon M. Huntsman School of Business, received SearchCIO's Enterprise IT Leader of the Year Award for 2013.

As I write this, my IT department is struggling with a possible "known defect" in a critical piece of software that directly affects the customer experience. The software manufacturer can't seem to track down the defect, and we have spent months working through ineffective suggestions and denials.

Yet at the same time, this company continues to express its desire to become more strategically involved with us and to extend its product reach. Hmmm, if you can't do well what you are already doing for us, why would we ever want you involved in more?

The answer to that question is brain-numbingly obvious for a CIO. Still, how often do we CIOs find ourselves doing the same thing? How often do we wonder why we aren't getting invited to discussions as we push to be "at the table" and "more strategic."

Let's get back to the basics. Ever had a friend? A real one, the kind of friend you could trust for anything (even though you know he/she isn't perfect and can't do everything)? What words come to mind for such relationships? Empathy. Understanding. Willingness. Confidence. Reliance. Connection. Focus. Trust. These friends listen, confide, commit, believe, allow, warn, entrust, and enable.

But these relationships happen only between people. This is not corporate trust or institutional trust. This is individual trust. It's personal.

Nobody trusts information technology. Information technology is a thing, a construct. It cannot be loved or return love. But in our IT departments in higher education, we have some pretty great people and, therefore, the capacity for creating excellent and trustworthy relationships.

Do you, as a technology leader, have trusted friends? People who feel that they could call you about anything? Can you name names? What about each person on your teams? Those are hard questions.

Thinking back, I recall that my first-ever job at a university (and the only job I have formally applied for since) was custodial work. That's right: scrubbing toilets. I am now CIO at a research university. How did that happen?

Cleaning toilet jokes aside, it happened because of individual relationships built on trust—because of confidence built day by day, project by project. I never asked or demanded the next step up in responsibility, but I handled some basics well enough in my little spheres that when other needs became apparent, someone would invite me to help rather than show me the door. And together, we created great outcomes.

When we are good at what we do and when what we do helps someone get done what they need to do, we are invited back to the table, time and time again.

We are invited to the table not as a servant, but as a guest. Speaking of servants, something unfortunate starts to happen when someone treats another person, or gets treated by another person, as an anonymous cog in a machine, a faceless consortium, a "customer," or yet another student. Interrelations become automated and mechanical. The dreams and desires that motivate get lost. Relationships are forgotten, and policy, process, and procedure reign.

Through our actions, are we building vendor-customer relationships full of demands—or partnerships full of trust? I'm not saying vendor-customer relationships are bad, but as a CIO, I know how it feels to be on the "customer side" of a relationship with a vendor that is always pushing to be "strategic" (which is code-speak for "we will sell you more and bind you further"). Might our "customers" feel the same way sometimes? If we are a true partner, we are not there for the paycheck, the job security, or the organizational turf.

When we collectively do the basics well, when we are trusted in the foundational pieces that are expected for information technology, when we build partnerships, we receive natural opportunities to stretch a little more.

Of course, that's all fine and dandy—motherhood and apple pie and all that. But reality eventually hits. No matter how good you are or how expansive and talented your team, you can't do everything for everyone. (And yet, we try.)

So, focus. Think of the friends and colleagues who are always busy whenever you call or, worse, say they would love to join you or help you but then never show up or, when they do, are often late or unprepared. Eventually you stop calling.

A good friend of mine, Eric Denna, asks this governance question: "Whom do we serve, and what do they want/need/have to do?" If the answer to this question is everyone and everything, we are doing something wrong.

In the central IT organization that I support, I also ask this question: "What are the things that only we can do?" That is, what are the things that, if we don't do them, will turn into bottlenecks and risks for others?

For example, "anyone" can develop a web app, "anyone" can go buy a cloud application, and "anyone" can buy a hard drive or access point. But not everyone can create an expansive, capable, secure, and efficient end-to-end access-layer. Not everyone can consolidate and tackle core institutional data. Not everyone can integrate systems, data, and cross-institutional processes.

What could we enable for "anyone" at the institution if we focus first on the core: on the things that, in our position, only we can do best? Build and maintain a strong and responsive reporting system and web-services API (with an efficient governance process) so that anyone can leverage and gain insight from institutional data? Get a strong authorization and identity management system in place so that we can effectively and quickly provide access to diverse content and systems anywhere across the globe?

Of course, deciding what to do is often more difficult than deciding what not to do. What should we say "no" to?

The idea that our little central IT software shop could somehow build the best and the most affordable and the most timely apps in the world for everything from assisting the finance and HR departments to helping researchers locate and track the festrel-bottomed-fort-warbler is ludicrous! And yet we try. We have a long list of hundreds of software and customization requests. But we never dare say "no," because that's bad customer service. So we say we'll get to it. Then we don't.

The tendency brings to mind one of my favorite quotes from the historian C. Northcote Parkinson: "Delay is the deadliest form of denial."

Maybe our focus should not be on building and supporting any infrastructure or any custom app that anyone can dream of at our wildly diverse institution. Maybe our focus should be on building and supporting a rich platform that our wildly diverse institution could securely leverage in ways unimaginable to us.

Motivation. Where to from here? A story is told about a CEO who, after a long workday, would regularly head out to the train station, park her car, and watch the trains roll out. When asked why she did that so often, she replied: "It's so refreshing to see something move on its own power without my having to get out and push it!"

There is something to be said for a person who doesn't have to be constantly reminded, perhaps even prodded, to jump in and get something done.

Need trust? Drive it. Do something trustworthy and reputation-building, on an individual level, toward a common, nontechnical objective. Challenge your staff, each individual, to do the same.

Need focus? Drive it. Don't wait until your units are spread so thin that quality and reputation drop through the floor.

Want a strategic invitation? Do all of this, then keep your ear to the track. Your train is coming.