Application Leadership for the Future: Build, Trust, Repeat
Responding to a Changing Environment
I will not bore you with one more list of the way the world of the CIO is changing. We all know how it goes. Our organizations are competing in a digital world that is moving blazingly fast. To be successful, we need technology that is flexible, scalable and reliable. That is what IT is expected to deliver, and if we can’t do it fast, our colleagues will move forward without us.
If I had a dollar for every time a vendor says, “You can deploy our solution without involving IT”, I would be sitting on a beach right now instead of writing this article. In the end we are playing catch up, and trying to stay less than a step behind the business which often takes all we have got.
Many new organizational models and leadership philosophies have popped up to help CIOs navigate through this new and different landscape. Agile and its offspring DevOps, as well as Gartner’s BiModal IT are just two examples that come to mind.
At the foundation of these concepts is a trade-off between trust and control. We as CIOs are supposed to have all kinds of control over infrastructure, applications, security, among others. If we were just willing to give up some of that control, to trust and empower our people, we will shed bureaucracy, streamline processes and start moving faster.
We need to get out of the way and let our IT people work directly with their customers
As I was reflecting on how to best implement one or more agile processes and how to find the right balance of trust and control for our university, it struck me that there was a major flaw in my thinking. I was confusing my (limited) control over our IT infrastructure and few core IT services with control over how technology is deployed to our community. This is the kind of control IT may have had before the arrival of app stores, web services in the cloud, and other technologies in the last five years, but it is definitely not the case anymore. To think we can balance trust and control is an illusion, as we really don’t have much control any more.
Higher education is in the early stages of a major disruption, and our community is no longer willing or able to wait for IT’s traditional approach of gathering requirements, analysis and design, implementation and test, and then deployment. We have to deliver education faster, cheaper, and in a customized manner to meet the students’ needs. Moreover, it has to be delivered at any place, in time, and we have to do it now. If we don’t, somebody else will. As a public university, we also have to justify how we spend taxpayer’s money and show what value is delivered in return.
If we are not there with our stakeholders, actively contributing to solving their problems within their timeframes, they will go around us. And if we try to stop them, they will go under our radar and just not tell us what they are doing until it is too late. In the best case, IT becomes irrelevant. In the worst case, we could end up with a catastrophic data loss from which it would be very difficult to recover.
Baby Steps toward a Trust Based IT Organization
Given this rather dystopian view of how bad things could go, our management team decided to change the conversation. Rather than trying to cling on to control that we really didn’t have, we decided to look for ways to speed up the building process for trusted teams. And a better start would be with ourselves in IT? Our first step as a management team was to take time out for day-long retreats, two to three times a year and spend at least half of that day on trust building exercises.
As a CIO, I quickly realized that I am a stakeholder in this process of building a trusting team. I am not a neutral third party, so I cannot lead the process. We have therefore decided to work with an outside leadership consultant.
The next step we are working on, is encouraging our managers to look for trust building opportunities in their areas. So far we have come up with two areas; deployment of our Service Now IT Service Management System, and evaluation and implementation of an Enterprise Service Bus for our campus. For both efforts we are creating small, autonomous teams of four to six people who have wide authority to make tactical decisions on design, implementation, and configuration. We are starting with internal IT processes but are planning to quickly expand to areas like onboarding of students, faculty and staff where we work closely with campus stakeholders.
To make sure relevant stakeholders are aware of upcoming changes, we require a couple of checkpoints: New or enhanced functions must be documented as agile user stories or service requests in our ticketing system. All changes must also go through a formal change process before they are moved to production.
To move at the speed our community requires, we need to get out of the way and let our IT people work directly with their customers. On the other hand, it is our job to make sure our efforts are successful.
This is where building applications becomes like washing your hair. But rather than lather, rinse and repeat. Our job is to build the right team, build a team environment of trust, and then repeat. This includes finding the right people, training them, helping them learn to trust each other, and then teach them how to do the same thing for their next team.
So far, this has shown promising results for us. We were able to develop and deploy a new IT change management process in two months and are now starting to work with campus stakeholders to enhance and automate the way we expose key data elements from the many systems we maintain. If we get really good at this, maybe one day my campus colleagues will complain that IT is moving too fast for them. That will probably never happen, but a CIO can always dream.