What If We Are Wrong?

min read

"Courage is the complement of fear. A man who is fearless cannot be courageous. (He is also a fool.)"Lazarus Long

This is a time for big change on our campuses. Realignment and repurposing of IT will comprise a significant part of that change. While the need may be clear, our new destination will remain obscure to many on campus. IT leaders will probably be among the first to see the shape of things to come. They will want to chart out this brave new world and proclaim it as destiny. For others, however, plotting out the future is not the immediate goal. Their natural first thoughts are for self-protection from change that could potentially be unsettling, even deleterious. Some of these folks are likely to push back at recommendations offered by the CIO and other campus IT leaders. How will this dynamic ultimately play out?

CIOs will care both about making decisions they deem are the best for their campuses and about maintaining their personal credibility as those decisions are made and implemented. Implementing change necessitates boldness in purpose from leaders, yet in our current environment change comes with substantial residual uncertainty. The brave new world as a concept may be easy to sketch; the brave new world as a reality requires an awful lot of detail that can't be filled in ahead of time. Nobody knows enough to do that. Bold leaders can look reckless after the fact and consequently have their credibility challenged. Understanding that, the CIO might be prone to caution early on when implementing change. But cautious leaders will find that change doesn't happen at all or that it happens but with them in the passenger seat rather than at the wheel — and not for the better for their own campuses. That is the dilemma I plan to work through in this column by reconsidering the recommendations from earlier columns, taking them on in reverse chronological order.

Let us start with the most recent column, Sunsetting IT Services. The tension that underlies the dynamic in this case is quite clear: Retained IT staff are burning out due first and foremost to overwork, since their numbers are dwindling but demand has remained unabated and might even have grown as others on campus start seeing IT as a solution to their own budget issues. A second cause for the burnout feeds on the first: If nothing is done about the problem, IT staff will conclude that management is insensitive to their needs or that leadership in this area is absent. In either case, those conclusions feed the burnout. So management needs to do something real, both to alleviate the problem and to signal staff that indeed their welfare is a prime management concern. Sunsetting IT services is perfectly rational for this reason.

Nevertheless, some users of services targeted for sunset won't see it that way. Instead, they'll argue that this move simply shifts the burden onto them. Assuming they are right about that, they'll ask — quite forcefully, you can be sure — why they should be the ones to bear the brunt of cuts in service? So the push-back is readily understandable in this case. That push-back is likely to generate a lot of heat but very little light. In the pressure of the moment one can imagine a promise being made to restore the service even if it is better for the campus to stick with the plan to sunset it. Such renegotiation can have disastrous effects, creating the possibility of similar scenarios with other services targeted for sunset, and thus ultimately not addressing the key issue at hand.

A well-designed process to select services for sunsetting must acknowledge the possibility of this dynamic and incorporate that in the selection process. Thus services that are good candidates for sunsetting must be such that either the users on their own can find reasonable alternatives in a not-too-long time, or the services must be broadly consumed so that the pain when they are terminated is shared across campus. For the former, the CIO then has reasonable grounds to stay the course and let the irate users complain — but hopefully soon thereafter go about the business of addressing their own needs. For the latter, perhaps the CIO can leverage other users who are dealing with the loss of service in a low-key way. Note that in either case the prior decision can be wrong — the potential hardship proves worse than anticipated. There is no safety play here. What this approach reduces and perhaps totally eliminates is the inability to follow through when the decision was right. That's what the CIO and other IT leaders should try to ensure.

Let's turn to the next case, Dis-Integrating the LMS. The underlying goal here is to encourage an ongoing culture of experimentation with teaching, as a way to improve the quality of instruction and to make more valuable the role IT plays in support of instruction. Faculty's embrace of the approach is, of necessity, voluntary, so there is no reason to anticipate push-back from them. At worst they will simply ignore admonitions to take up a dis-integrated approach. In this case the staff supporting the LMS are likely to push back, and they may have good reason for doing so. They will fear losing relevancy in their work, and if they are correct in that prognosis, they will also fear losing their jobs.

For a dis-integrating the LMS approach to work, support staff must actively facilitate it by offering encouragement, providing suggestions of things to try in teaching, and offering ancillary services that make it easier for faculty to embrace the approach and not spend undue time on IT administration of their courses. Such facilitation would represent a substantial change in the role of support staff. Campus IT leaders should actively promote this, investing resources in staff development and reducing prior obligations to make the change possible.

Again, IT leaders could be wrong. They could overestimate the extent of faculty adoption even when IT staff vigorously facilitate the dis-integration approach. They could also overestimate the ability of IT staff to change roles, even after the requisite staff development and job changes. Perhaps some staff cannot adapt. Because IT leaders could be wrong, they might be cautious in making the necessary supporting changes. That caution could very well doom the faculty adoption, however. The operative expression is, "manage for success." Making the supporting changes does exactly that.

Finally, let's briefly look at the first column in this series, in which the scenario described the goal of moving the Tragic Tory users from a long-standing IT service targeted for termination to a brand-new service. This case bears similarities to the service sunset case, except that here the users don't fend for themselves in identifying the alternatives. A new wrinkle specific to this case is managing the period of overlap where both services are in operation, as well as determining how many resources should be put into migration. The transition matters for the ultimate success of the new service. IT leaders need to understand that and resource the transition accordingly.

Likewise, consider the case of a broadly consumed service with many locked-in tragic tories who are extremely reluctant to switch to a new offering. Then the motive for switching must be quite clear to the CIO and other IT leaders. Either the new service is of vastly better quality, so the strong expectation would be that the tragic tories will quickly come around to the point of view that it was a good move, or the new service must produce a substantial and obvious saving, so the shared burden argument can be applied. If the proposed new service is lukewarm on both these fronts, IT leaders risk the possibility that the entire process will unravel.

I'll conclude with the following observation: We might have to combat our own instincts to guard against being found wrong if we are to give the best chance to implementing change with IT. A useful guide for thinking this through is to ask, How might our own actions impede success when success otherwise would occur? Invariably we will find such impedance is the consequence of seeking self-protection. The times demand that IT leaders sacrifice some of their personal self-protection to better position IT services on campus. It is not being wrong that we need to guard against, though that is what we fear. Failure even when we were right is the greatest sin.