Kind of an ambitious title, eh? I was asked to talk about this subject recently and started to mull some things over in my head. I mean, lets start with the basics – what is “shadow IT” and why should you care. As an IT Professional who works in the IT Space – you should definitely care. It represents an individual / project / team who has gotten fed up with the current process for procuring “IT Services” and has gone around the blocking team and set something up themselves. this could lead to a couple of assumptions:
- “The IT department” is going to be left holding the bag when something goes wrong
- “The IT department” has become so mired in the day to day muck that they can’t properly advise on how to “efficiently” do something that will have long term impact to the company
- “The IT department” is viewed as a stoic and non agile department that is not perceived as being innovative and providing value to the business
In case you don’t see the trend here, these are negative assumptions. There may be others, but when the term “shadow IT” comes up, it has generally already gone down the wrong path. This is something everyone in “IT” needs to help prevent – in a more proactive and agile way.
When I was starting out in IT a long time ago – the IT Manager I worked for enjoyed his position on the leadership team as an advisor and a partner. He did a good job of evaluating the requests and collaborating with the various groups and departments on projects that were important to the business. As Projects got more and more complex, additional full time resources and additional skillsets were not able to be secured or got left behind, which lead to a traditional problem of resource constraints. At some point he realized that there was a disconnect with what the business wanted to do and the actual “costs” associated with it. Long story short – the IT Department evolved into a cost center that was pushed out of relevancy with the rest of the business and the old school equivalent of Shadow IT crept in.
How can you keep it from happening OR how can you “recover” from it already appearing in your work environment. To some (on the other side) they see it as a good thing, so long as the project goes well and security / architecture was properly thought out. It’s when crap goes wrong that the chips fall and debts are repaid.
Going back to my story of working in that IT department with my Manager and looking back with 20/20 hindsight, some things could have been done to help overall. If budget was not a factor <sarcasm> we all have unlimited budget, right? </sarcasm> we could have implemented the following:
- Invest more time to update skills of staff with regards to new technologies they already work in AS WELL AS new emerging technologies that the business could leverage.
- Invest in additional headcount to distribute the existing workload and allow for more self development time.
- Commit to Moving the 80% effort for maintaining and fixing existing systems down in order to invest more than 20% effort at exploring new options and technologies.
- Partnering with new projects as they develop and understand what sort of resources and technologies they need BEFORE they are asked for. I stress the word PARTNERSHIP here.
- Ensuring current processes are streamlined and not in place to keep the status quo.
- Rekindle the relevancy of the IT group so that it is viewed as a value added partner to the organization and one that understands how it’s projects affect the business.
The main problem here is that all these points are mostly systemic and require some serious reform and commitment from all those folks in charge. What can an individual IT pro do? We are one part of the problem and also one part of the solution to change this perception. Admit it – as IT Folks, we love to solve problems and work on systems so that they provide services to the community of end users. It’s solving these challenges that keep us going and interested in the job. When we are no longer challenged, we get bored and look for new ones.
Here is what I have done to keep me happy and mostly SANE working in IT and help influence change within organizations I work in.
- Commit to a lifelong learning approach to IT. I take time in the job and after work to learn about new things – ALL THE TIME. You have to, or you get left behind.
- Don’t just focus on your core areas of existing expertise. Explore additional areas that are of interest and that you think will be usefull going forward.
- Share your learnings with others. Give brownbag lunches to your colleagues. discuss new technologies over beer. Attend conferences and “report back” with good trip reports that include your opinions and insights. Having to explain and teach people what you have learned helps solidify your knowledge and sets you up as a go to person for new technologies.
- Volunteer for projects that are outside of your comfort zone. your strengths from your existing toolbox will come in handy or at least your approach and alternate viewpoint will bring new light into the project.
- Provide constructive criticism on how things can be done better. In other words – look to find ways to solve issues and share them in such a way that it’s not assigning blame and its providing a solution instead of just complaining about something that is broken.
Do these things by themselves make your IT department more agile? Would it prevent a Shadow IT department from forming or fix up one that already has? I don’t think it is a silver bullet. As I mentioned before – it’s a bigger issue than one person to fix, but a bunch of people with a similar mindset AND a supportive management chain that is willing to try to be more responsive and agile will go a LONG WAY to fixing the issues and changing perceptions.
This whole being more agile and having more “dev ops” approach to projects and IT really comes down to some basics that are NOT rooted in various online services, 3rd party tools or solutions sold by different vendors. It’s about the PEOPLE you have in place, their ability to WORK TOGETHER towards a goal and their ability to keep COMMUNICATING without bias. I’m not going to go into a long discussion around DevOps here – my friends Volker Will and David Tesar have been doing a GREAT job talking about DevOps on their blog (http://blogs.technet.com/b/devops/) with more of a People/Process focus. They from an OPS background (which is rather refreshing in the DevOps world) with DEV experiences. Go check them out.
This was very much a commentary piece. I don’t profess to have all the answers – I can only talk from my experiences. We all have war stories about how things have gone wrong in various IT organizations we worked in. Hopefully we also have good stories of when things are going RIGHT as well. Do you have any ideas or stories to share? Comment below!
