Originally published on LinkedIn.

Several years ago, I encountered someone creating a 70 page “report” by importing financial and sales information into a spreadsheet and then manipulating it to create a presentation. He spent two months every quarter to produce it. The spreadsheet he used to create the report contained over 5,000 calculations that he updated by hand. Let me say that again: he was updating over 5,000 calculations, every quarter, by hand, one spreadsheet cell at a time.

Spreadsheets are very powerful and they enable virtually anyone to create algorithms and complex calculations. In that light, perhaps we could think of them as the first iteration of low-code/no-code technologies. 

As low-code/no-code tech become prevalent and more powerful and as machine learning and automated processing continue to advance, we need deliberate strategies for controlling, understanding, and maintaining what we create. 

Another recent example of the power (and potential pitfalls) of low-code capabilities involved a CRM project with a requirement to enable the business to create custom workflows without IT involvement. This was easy to implement. It was just a matter of turning on the feature and granting the right access. In this instance, a senior member of the team decided to play with the platform’s notification capabilities. He thought he was creating a workflow to notify his team about updates to one specific client record, but what he actually created was a notification for all client updates to be sent to the entire company. Unfortunately, he was also in a production environment. You can imagine the chaos this caused. In this case, the problem was fixed quickly and the “damage” was just a bit of lost productivity and a bit of embarrassment. But, it could have been much worse.

These sorts of challenges are not new. Every line of code written by a developer (skilled or not) has the potential to create productivity or security issues. But with low-code and automation technologies embedded within point solutions and with entire platforms designed to enable low-code/no-code capabilities, the barrier to implement and deploy “code” is lower than ever. Don’t get me wrong, this is a good thing. But, the challenge it creates is that anyone can deploy things that they may not fully understand and that may not work as intended.

As I discussed in my What You Don’t Know article, we can mitigate many of the impacts of unknowns; but in the case of business-driven coding, we also need a systematic and intentional understanding of where in our organizations these capabilities are being used and by whom.

Back when I was a coder, we had a running joke whenever someone asked if we could code something out of the ordinary: “Sure, it’s just an IF.” That’s true unless you stack 5,000 untested IF statements on top of each other. Or create an IF that evaluates to all employees and not just the ones on your team. In that case, it’s a disaster waiting to happen.

Being intentional and deliberate in how we deploy these technologies will help to mitigate potential disasters. Specifically, we can:

1. Develop an intentional strategy that embraces no-code/low-code technologies and identifies boundaries for their usage.

2. Remove the need for “shadow IT” by creating a program that allows the business to use no-code technologies in a way that is controlled, deliberate, and visible.

3. Educate the entire organization bottom-to-top (maybe especially the top) about the power, impact, and potential damage that improper usage of these technologies can have. 

Your team has the best intentions. They want to do their jobs faster and more effectively. Make sure they have the right tools and knowledge to do so safely and effectively for your organization.

In case you were wondering about what happened with the two-month report: we were able to reduce it from two months to two hours. My next article will explain how we did that.