A clerk from the grid connection department solved the problem that two IT projects had failed to address. Using a platform that enables applications without traditional programming, she built an overview that tracks all applications across three systems. Processing times dropped, two neighboring teams adopted the tool, and no one wanted to work without it anymore. Two years later, the colleague changed employers. After the next system update, the application failed, and it became clear: no access, no documentation, no one responsible. And during troubleshooting, something else came to light that weighed heavier than the outage: the application had processed customer data via an account that no one in the company knew about. The tool had solved a real problem and, in doing so, unnoticed, created a bigger one.
Departmental self-development cannot be banned, only driven into invisibility. Therefore, the choice is not yes or no, but visible or invisible.
At an energy provider where I led such an inventory during a consulting mandate, the first systematic search unearthed over eighty applications that departments had built on their own initiative and of which IT knew nothing. Spreadsheets with complex macros, small databases, automated evaluations, tools on rental platforms. Some of them were harmless. Another part processed customer data, fed reports to management, or controlled processes that other departments relied on. The remarkable thing was not the number. It was the fact that every single one of these applications solved a real problem for which there had been no other solution.
This is precisely the key to dealing with the phenomenon. Three levers turn wild growth into a managed capability.
Shadow IT—applications and tools created and operated outside of official IT—is not a new phenomenon and not a sign of malicious employees. It is the most visible proof that the needs of the departments are growing faster than the capacity of IT. Where a legitimate request meets a long waiting list, the solution emerges past the official path, quietly and with the means available. Bans do not change this. They only shift development deeper into invisibility, where neither data protection nor operational security is ever checked.
Two developments are currently exacerbating the situation significantly. Platforms for development without programming knowledge, established under the terms Low-Code and No-Code, are lowering the barrier for developing business users—internationally referred to as Citizen Developers—from years to weeks. And AI-supported tools are lowering it again, from weeks to hours, because a precise description is now sufficient to generate a functioning application. The capacity released through automation in the departments meets tools with which it can be immediately transformed into their own solutions. This wave is rolling, whether managed or not.
| Characteristic | Invisible self-development | Managed self-development |
|---|---|---|
| Overview | No one knows the inventory | Applications are recorded |
| Responsibility | Ends with the person who created it | Designated, with a deputy |
| Data protection and security | Unchecked | Checked according to risk |
| Departmental speed | high | Remains high |
The last line is the most important, as it dispels the common objection that management costs the speed for which self-development arises in the first place. Properly designed, management takes nothing away from the pace of self-development. It only takes away its invisibility.
The first step is not the rule, but the inventory, and it only succeeds under one condition: no sanctions. Those who respond to the reporting of existing self-developments with accusations will only learn about a fraction of the inventory and drive the rest deeper into hiding. The inventory is an offer: what is reported may continue to run until it is checked and will be supported during the transition to secure operation.
Only this overview makes manageable what has long existed. It shows which applications support critical processes, which data lies outside protected systems, and where a technical legacy is growing that no one has on their radar because it appears in no official inventory. Furthermore, unmanaged self-development lacks everything that secures the operation of an application over time: regulated updates, traceable version statuses, a deputy for outages. It is thus nothing other than technical debt created off the books, and like any debt, it eventually falls due—usually at the most inconvenient moment.
The second mistake after banning is the one-size-fits-all rule that subjects every spreadsheet with a macro to the same requirements as an application processing customer data. Such a rule is unsustainable in practice and is therefore ignored across the board, causing management to lose its credibility before it even takes effect. What is effective is scaling by risk: a tool for one’s own workstation needs little more than registration. An application used by a team needs a designated responsible person, a deputy, and minimum documentation. An application that processes customer data or controls processes that others rely on belongs under the full standards of IT—in regulated industries, without exception.
This scaling follows the same principle that characterizes good governance in agile organizations: guardrails instead of individual approvals, clear boundaries of what is permitted instead of checking every step. The difference lies in the subject matter: there it is about decision-making paths and forms of work, here it is about tools and data. And scaling protects against the reflex that is particularly pronounced in regulated firms: the blanket safeguarding that stifles every movement because no one distinguishes between a harmless aid and a real risk.
Banning fails, as does letting things run wild. The third way is a division of labor: IT provides the environment, the departments develop within it. An approved platform with regulated access, connected data sources, and central user management takes the most dangerous part of shadow IT out of the game from the start—namely unregistered accounts, unsecured storage, and isolated solutions without access protection. Within this environment, departments are allowed to be fast; outside of it, it is not considered self-development, but a violation.
A CIO whom I supported in this reorganization combined the inventory with an exchange: every reported application was transferred to the approved platform or orderly shut down within a year, and every department designated a person who was qualified as a contact for self-development. Two years later, more applications were being created than ever before, but every single one had a responsible person, a deputy, and a verified way of handling data. The speed had remained. All that had disappeared was the risk that no one knew the magnitude of before. Such a model requires management to have its own basic understanding of technology, because those who cannot categorize the tools can neither define the risk classes nor judge whether the guardrails are fit for purpose.
First: How many applications developed by departments on their own initiative exist in your company? If you do not know this number, it still exists—just outside of your control.
Second: Which of these applications would bring a critical process to a standstill if the person who developed it left the company at short notice? And which process customer data in environments that have never been subjected to an audit?
Third: When will the first inventory without sanctions start in your company? Set the date for the coming quarter and simultaneously define three risk classes before an audit or a failure takes over this task—though then under conditions that you no longer determine.
Departmental self-development is here to stay, and AI is accelerating it further. A ban does not create security, but invisibility, and invisibility is the most expensive form of risk because it eludes all management. The task of leadership is therefore not to complain about or forbid the wild growth, but to transform it into a capability: visible, scaled by risk, and on an environment that makes dangerous shortcuts unnecessary.
The energy with which your departments help themselves is not a threat. It is unused capital that only needs an order to be effective.
Technical Literacy for Executives – Risk classes and guardrails can only be defined by those who can categorize the tools themselves.
Insourcing through AI – The same technology that turns departments into developers also brings outsourced work back in-house.
All Insights can be found in the overview.
Proven tools and models for self-application are available under Solutions.
If you want to take these thoughts further for your company, a no-obligation initial conversation is worthwhile.
