April 2, 2019

How to get approval for Shadow Software

Shadow software is software that is being used in your organization that is not part of the standard software that is approved or recommended by the organization’s IT department.

… from your global CTO

Shadow software is software that is being used in your organization that is not part of the standard software that is approved or recommended by the organization’s IT department.

This can be something as innocent as me using Google Sheets instead of the company-wide distributed MS Excel, just because I prefer being able to share my spreadsheets more easily. The risk can become bigger when shadow software becomes so prevalent that it is preferred over core operational tools. This can lead to:

  • the organization losing its ability to properly measure its efforts
  • new features that are introduced are not being adopted
  • losing control over governance structures, such as data protection
  • changes in the core system lead to compromising of dependencies in shadow software

At AIESEC we are very bad at shadow software. As Global CTO I need to find ways to continuously minimize risks of shadow software in our Global Information System (GIS). Our Global Information System is our digital landscape consisting of various web-apps and the API powering them.

Our national offices are in essence each their own independent organization. If one of them feels, the IT solutions provided by our GIS are not fitting to how they run their operations (after all, we have one system for 120+ national offices), they might take matters into their own hands and build their own systems. We estimate that around the same amount as our organizations global IT budget is additionally being spent by our national offices into shadow software.

When I was IT director at the German national office of AIESEC, I was in the same situation. For years, we had already been using Salesforce as shadow software until we were forced to switch to a new solution. At that moment, neither did I want to spend money and effort to find just another shadow software, nor would we be able to fully adopt the Global Information System without customization.

We actually already had a solution in place: Bookmarklets

We had built a database connected to an API with the same core structure as the Global Information System’s API. Our endpoints allowed us to retrieve & save data based on the unique IDs present in the GIS. Complementary, we built small bookmarklets that would implement additional modules into the user interface of the GIS. These bookmarklets were then cobbled together in one powerful container to enhance the GIS with functionalities that were not present before, such as offline caching, bulk actions, etc…

We built listeners to tap into GIS' javascript functions to make sure the interactions our users were doing would feel as natural as possible. The bookmarklets were provided in one package as a Chrome extension so that every new employee of our national office received it as part of their on-boarding. However, our solution was also riddled with the usual issues any shadow software has:

  • packaging it in an extension required an additional step for employee onboarding that was not always easy to enforce
  • our features would frequently break when the GIS changed
  • we were spending money & resources on solutions for one office that could have benefitted the global organization

My ambition was to pitch this to the global CTO to get the approval and integrate our features into the global system to minimize these issues. I planned out my attempt, wrote a lengthy email and a highly technical explanation. About to send it, I decided on a whim to ask my colleague for feedback — someone who was not a subject matter expert. His challenge for me was to find a benefit the global GTO would get from this implementation, reasoning they would not spend resources on initiatives that would only benefit me. That’s when I knew I had to level up, gathering more feedback. I talked to my supervisor and my mentor. What I initially settled on was a simple presentation with a few slides following the structure of the Winning Pitch (by Greg Tremlow).

1. The Problem

What you hate or will fix or will make 300% better.

Never start a pitch by talking about yourself, your team, your product, or your total addressable market. Instead, start by naming the thing that’s getting in the way of your customer’s effectiveness and/or happiness. Do that by painting an emotionally resonant picture of how the world currently sucks for your customer, who or what is to blame, and why.

2. The Urgency

Answer “Why Now?”

Audiences — particularly investors — are skeptical. They’re thinking: “People have lived this way for a long time — are they really going to change now?” You have to explain that if you don’t act now, things quickly get much, much worse.

3. The Solution

Show the promised land before explaining how you’ll get there

Showing the enemy’s defeat before explaining how you’ll make it happen can feel wrong for novice presenters — like blurting out the punchline before you’ve told a joke. But when an audience knows where you’re headed, they’re much more likely to buckle in for the ride.

4. The Show-Stopper

Identify obstacles — then explain how you’ll overcome them

Now that you’ve shared your vision of the future, (a) lay out the obstacles to achieving it and (b) show how your company/product/service will overcome each one. (There had better be some big, nasty obstacles — otherwise who needs what you’re selling?)

5. The Evidence

Present evidence that you’re not just blowing hot air

Audiences are skeptical. So you must give them evidence that the future you’ve laid out is, indeed, attainable. For early-stage companies and products, demos can serve as evidence, though results from early (or beta) customers are more compelling. Least persuasive — but better than nothing — are testimonials from potential customers explaining why they would buy. This is the slide set I used. My tactic was to create a compelling story tapping into a problem I knew they wanted to solve the problem of shadow software themselves. When talking about the show-stoppers, I specifically mentioned what I wanted them to do for me. Essentially, I shifted the narrative around from “them helping meto “me helping them”.

The outcome was that they happily integrated my bookmarklet code snippet into the source code of the GIS, allowing me to both achieve my goal and solve a problem the global CTO had by allowing more national offices to also use our solution.

How to get approval for Shadow Software was originally published in Laurins Page on Medium, where people are continuing the conversation by highlighting and responding to this story.

other posts