Why you have Shadow IT, and how to fix it

Most companies use software tools which haven’t been blessed by in-house engineers nor operations. There is what we call "shadow IT". We posit this is due to how organisations approach software management, and that No-Code tools are a solution to this issue.

As a technology leader, why should you care about No-Code?

No-Code development platforms are not a new idea, nor a recent one. Some of the most well-known companies in the space have been around for over a decade. Despite this, ask an engineer, and you are likely to be met with scepticism. As a consequence, companies tend to solve their software needs by either buying off-the-shelf or building in-house.

That scepticism may be based on a limited view of the overall needs of the company, caused by bias derived from the technical skills of engineers. But we can’t fully dismiss it, as in the end this is a problem with a technical component. 

What do we mean by No-Code

We should first define better what we mean when we talk about No-Code platforms. Then we can discuss the above in more detail.

No-Code development platforms are a natural evolution of what was called in the past low-code, or CAD. These tools are used to build software applications through graphical user interfaces and configuration, instead of using traditional computer programming.

Examples of successful companies in the space are Airtable (founded 2012), IFTTT (founded 2010), Zapier (founded 2012), or Shopify (founded 2006).

A large part of the customer base of these tools are lifestyle businesses, as Shopify themselves promote. No-Code platforms are advertised as an opportunity to build a product without the need of an expensive engineering team. Initiatives like Indie Hackers, a community for founders and entrepreneurs, and Build in Public, a related movement, make heavy use of No-Code tooling. In fact, they recommend it as the preferred way to start a new project.

But, perhaps surprisingly, when you ask an engineering team, they usually raise arguments against the use of these tools inside a company. They say that it is more limited than coding the solution, reducing what's possible. That it causes lock-in with the vendor, and migration may not be possible at all. That it is not cheap (with some exceptions) which means it is not that much cheaper than a custom build. And the lock-in means the platform can have a big impact on profit margins as the company grows.

Some believe this is a cynical play by developers, based on the fear of losing their job. But the truth is that those arguments are not entirely wrong. The real risk for developers of using No-Code is not great. If one considers that using a No-Code platform is akin to outsourcing their skills, we can see that. Offshoring has not removed the need for engineers.

So, what gives?

Cost centre and profit centre

Let’s start with a small detour outside the realm of software and engineering, into a couple of business concepts. Some people with technical backgrounds are not familiar with these terms, and it is worth explaining them as a refresher. This will be a simplified definition, so excuse any inaccuracies introduced for brevity.

A Cost centre is a department that supports the business. It doesn’t generate revenue directly (thus, the “cost” part), but its efforts support the departments that generate revenue, and the company couldn't function without them. When you think about a cost centre, think about HR, about legal, about accounting, … you get the idea.

A Profit centre is one of those departments that bring revenue to the company. Given that the purpose of business is profit, they are the core of the company. They are often treated as a distinct entity within the company so that their profitability can be measured, as they have costs themselves. Examples of profit centres include areas like bike repair in a bike store, or professional services complementing a SaaS offering.      

Knowing that, how to classify software in a company? Are applications profit or cost centres?

Software inside a company

As Marc Andreessen put it, “Software is eating the world”. Everybody uses software at their work. If you are reading this article, it is likely your professional role is at least close to software engineering in your company. Your company deals with external tools like Slack, as well as the software you are responsible for producing.

Companies that don’t build software in-house also need software. Slack, Zoom, Miro, and many others are used by companies in all sectors, but they often also require custom software for their operations. Just replace “software you are responsible for producing” by “software a consultancy builds to our specifications”.

We can see that both types of companies use off-the-shelf software. Slack, Office suites, Zoom, and others are standard tools used by everyone. But they exist in a different category to the software a company produces in house (or outsources to be built). And, for many companies, the only software they have some relation to is the one belonging to the first category, the standardised one.

This is why we raised the subject about cost centres and profit centres. For any given company, some software is used to support the day-to-day business, which means it can be classified as a cost centre. And, for some companies, a piece of software is a profit centre which they make money directly from, by either selling it, or because without it, their core business doesn't exist (think Uber).

A company wants to minimise the costs associated to a cost centre. When that cost is a piece of software, they don’t build it, they buy it, as otherwise they would need to pay an expensive team of developers to get the same functionality. The functionality is usually standardised enough, that they aren't concerned with customisation. Before, that was called off-the-shelf software. Now it’s called SaaS. 

By the way, this also affects things that we considered, traditionally, Capital Expenditure. Like servers. We moved from managing servers and racks to the Cloud, for the same reason: trying to reduce costs. Even thought in some cases the savings are relative.

Finally, we have the software that is core to a company, the software that is built-to-order, per the specifications of the business, to bring in revenue. There are two options: either it is built in-house, or there is a contract with a consultancy to build it as per requirement. In both cases, it is an expensive piece of software, albeit for different reasons. But still pivotal to the company success, and part of a profit centre.

The Gap

This duality leaves us with a Gap. No, not that kind of Gap. On one hand, we have commodity software, where one doesn't care about customisation. Let's say, Zoom. On the other hand, we have our own built-to-specification software, be it internal or a SaaS, which helps us generate revenue.

This opens up a middle ground, software that needs to behave in a way particular to your company. It can be due to regulation, internal processes, or market requirements. But this software is not essential enough to receive the budget for a fully custom-built solution.

Covering the gap is the No-Code case, and that’s why it’s succeeding.  

The mistrust of engineers towards No-Code is explained by this same gap. Their skills and experience make them understand that this tooling is important for the business. They are just removed enough of the bigger picture, and the cash-flows of the organisation, to not recognise that their solution wouldn’t be reasonable given the additional economic constraints.

You already use No-Code

No-Code companies have survived long for a reason. They have discovered a niche that exists in all organisations: the not-so-custom software that is important to keep the company working, but not relevant enough to be built in full.

You can recognise it in the form of complex Excel spreadsheets with weird formulas shared between co-workers, to manage their own workflows. The “hidden software” in use by employees of most organisations. Which, as this promo piece of a low-code tool shows, can have unexpected consequences. In a sense, Excel is the grandfather No-Code-tool.

Should your company adopt No-Code tools?

Yes are probably already using them, in a non-compliant and more risky way. The rise of No-Code platforms aimed at building internal tools, like Retool or AppSmith, gives you the perfect excuse to start testing the waters.

You will reduce risks by having official and supported solutions for your processes. If you consider the time currently spent by your employees on maintaining and using ad-hoc hacks, the total cost of No-Code may not be higher.

If you aren't convinced that these tools can fit the needs of your sector, read the use cases published by AirTable (or other vendors). You may be surprised at how much you can achieve with these tools, and how well they can mould to your requirements.

Conclusion

No-Code is covering a crucial niche in companies. If you are not using it, you are missing out. It allows you to iterate faster on solutions that are worth some expenditure, but that don't justify the full cost associated with a custom solution. It reduces risks. Additionally, they empower your non-technical users, making them more productive.

Likewise, you can port some of your custom solutions to No-Code platforms, reducing their TCO and freeing precious engineering resources.

We would be remiss if we didn't point out that some of you, may have been nodding along the full article, as you consider all this to be obvious. If that is the case, we have to congratulate you, as you are lucky to work in an enlightened environment. Unfortunately, many organisations have yet to get this point. Adoption of technology and related trends has a long, fat, tail.

Next steps

In a future post, we will go deeper on topics we have alluded to in this article. There are different stages to the software a company uses, from custom to commodity. What are the real reasons for this, and how you can use that knowledge to better structure your efforts. Stay tuned!