This post is a part of our Change Management blog series. Head over to our Change Management section to learn more about big-picture tech strategy in the workplace.
Prior to joining the Newmind team, Hans Erickson served as the SVP and CIO of the Detroit Regional Chamber, and he gave one of our favorite talks at Build It Together Kalamazoo 2014, which glanced the subject of “Shadow IT”. If you didn’t make it to the event (we held it back in June and can’t wait for next year), you can read the highlights of his session, but one aspect of his talk stood out to us: a relatively modern IT notion, mysteriously named Shadow IT. We decided to reach out to Hans, and he gave us some time to discuss his thoughts on the subject 1 on 1.
Starting plainly, could you define Shadow IT for us, in your own terms?
The term has been around the IT world for several years—I think it may have been termed by the analyst community, through conversations they may have been having with IT players. Basically, it describes the practice of business units purchasing tech services or products without going through IT.
The consumerization of IT and predominance of mobile devices have accelerated this phenomenon, he says, and since the expression “shadow IT” has been in regular use, certain figures in the corporate IT world have renamed it “business-led IT.”
I think “business-led IT” correctly puts a positive spin on the practice, because this is a pretty fundamental shift in the IT environment that’s here to stay, and it’s just going to continue to grow.
The impact of cloud-based computing, software as a service, social media, and many other factors regarding modern technology have made it easier than ever for internal business units (marketing, human resources, and so on) to implement technology on their own, when they can’t get the support they request from centralized IT.
He goes on to note that more and more, non-IT budgets will reflect a growing percentage of IT spending. “Internal units will find the path of least resistance, which is often going directly to the department head, rather than going through to the organization’s IT department.”
Can you describe some scenarios in which Shadow IT could be interpreted in a positive way, and how to effectively approach it?
Rather than give you examples to illustrate this, I like to look at how technology has matured through an analogy for human behavior: as a “child,” a business environment was provided for by IT in a very controlled fashion. Just as a parent does with a small or growing child, while technology matures in our culture and workplace, IT finds itself in the position of a parent whose child has matured and is ready to leave home—the relationship has to change, or there’s going to be bad for everybody.
Each business unit knows its own business needs better than IT does. IT, on the other hand, understands how data integration, authentication, security development and lifecycles work. So the “business-led” IT model suggests that IT transitions into the role of “supporter,” rather than “doer.” In this new relationship, guidance and help where requested are more effective than total project control.
Marketing can own the website, with IT providing back-end database integration and 3rd party integration assistance.
Accounting can own the general ledger of budgeting applications, with IT helping on authentication, distribution, and data storage guidance.
With this approach, the entire organization can move more quickly and nimbly, with IT providing assistance to each business unit wherever it makes the most sense.
Under what circumstances, would you say, should Shadow IT be addressed explicitly as a problem?
I found that question very interesting because, to me in most cases, where I would define shadow IT as a problem is where IT is actively resisting. That’s kind of the status quo, and it comes back to the idea of rebellion and “raising the child.”
When the adolescent unit becomes more resistive to your authoritative control, that’s when IT should maybe be considering letting go a little bit, because suddenly IT isn’t really supporting crucial portions of the project anymore, and the entire organization suffers as the result. I think there needs to be limits on what each business unit is allowed to do, and what should still be referred to the IT department for assistance.
With an IT department open to cooperating with the needs of each business unit, he says, a better team spirit is cultivated, and IT’s values, such as infrastructure and security, become more recognized and respected.
Getting on board with this philosophy can be difficult. You become used to the way that you’ve provided services to the different aspects of your business, when one day, you discover a conversation has been happening over new functionality that a business unit needs, and things are underway before you even enter the equation.
So you may feel a little bit defensive right out of the gate, and may feel the need to re-establish the ground rules, after not being called upon for IT needs. Instead of that though, you need to just stop, set your personal pride aside, and try to determine the contraints that got the business unit into this situation, and let them help you determine the best solution for their needs.
That usually entails helping them with details of the project that they might not have thought through because they’re not use to working the IT side of things. This provides value to them through the expertise that you bring to the table, while respecting and utilizing the needs of that unit. The more you realize that the relationship has to change fundamentally to go forward, the easier it gets for each succeeding conversation.
