Out of the shadows
Photo credit: David Werbrouck via Unsplash
Shadow IT is a failure of trust, and it is a failure we must fix.
The origin of the term ‘shadow IT’ is unclear, but you don’t need to know where it came from to understand what it means.
If you work in an IT department, it instantly evokes feelings of dread and horror: of insecure, unmanaged, poorly designed and unstable systems that business teams have come to depend on, and that you’re going to have to figure out how to manage and integrate.
And if you work outside the IT department, hearing your solution described as ‘shadow IT’ inspires a sinking feeling, as you realise that the solution that you have painstakingly learnt to build, that your colleagues love, and your boss has praised you for, is going to disappear into the impenetrable bureaucracy of security reviews and change management processes.
Shadow IT comes into existence for two reasons. Firstly, and most obviously, people with needs and problems have access to powerful tools: it should not be a surprise to discover that they use them to build solutions. Second, and less obviously, teams inside and outside the IT department don’t trust each other. The IT team does not trust non-technical people to build robust solutions, and insists that everything that looks like a system goes through their rigorous planning, design and release processes. The business team does not trust technical people to manage costs and resources effectively, and insists on extensive and onerous processes for portfolio and programme management which make it hard to respond to evolving needs. As a result, if you want to build things properly, you have to wait, and if you want to build things quickly, you have to step into the shadows.
(This is, of course, something of a caricature. Some organisations use Agile practices and product management disciplines, delivering continuous improvement through multi-disciplinary teams. But there are plenty of organisations stuck in the model described above.)
This situation may be about to get worse. As well as the growth of low-code and no-code platforms, it is now easy to obtain AI coding assistants which appear to generate working code in response to a few English sentences. And tools to build agents are becoming part of our desktops, productivity suites and processing platforms. We could quickly find ourselves in a situation where IT teams are fending off a barrage of multiplying agents and vibe-coded systems, or business teams are fighting to get access to tools which they know will help them. Or, more likely, both at once.
I think that our response should be, yet again, to rethink the relationship between ‘IT’ teams and ‘business’ teams, and our understanding of who builds systems and who uses systems. This will not be the first time: in the history of computing, fundamental advances have shifted the boundary between technologists and non-technologists. Compilers made it possible for people to write code without being mathematicians. Screens and keyboards made it possible for people to interact with computers without being programmers. GUIs and office productivity tools made it possible for users to capture ideas and create knowledge, rather than being trapped in the rigid fields of green screens. The Internet made is possible for people to access assets and information all over the world. Laptops and mobiles made it possible for people to take their technology out of the office into the world. Now AI is making it possible for people to build solutions faster than ever.
Each of these steps has required a shift in trust. Sometimes this shift means education for business users: the shift from green screens to GUIs didn’t happen without training. Sometimes it has meant business users accepting controls from their technology teams: mobiles and laptops can survive securely in the world due to security protections. And sometimes we have got it wrong: if you are old enough, you may remember the days when Internet access required someone to fill in a form asking special permission, or the days when an email account was a privilege.
The adoption of AI will require a shift in trust in both directions. Technology people will need to accept that putting powerful tools in the hands of the people who are closest to their business needs will often be the best way of meeting those needs. Business people will need to accept that those powerful tools come with guidance and guardrails that they will need to understand and embrace in order to build safely. Both will have to accept that the boundaries of their respective professions just got fuzzier.
Shadow IT has always been a side-effect of a failure of trust. To date, that side-effect has been survivable; a new wave of tools and innovation means that it threatens to become overwhelming. Fortunately, we have the means to eliminate shadow IT, not by stamping out business innovation, and not by accepting uncontrolled proliferation, but by working together to develop practices based on trust.
