For years big tech has been evangelising the concept of the ‘citizen developer’, with the idea that as low-code and no-code tools become more powerful, non-technical team members across companies will be empowered to create tools that help to digitally transform businesses.

The vision is a compelling one. Imagine staff across all levels having the capability to create tools that solve real business problems quickly, and cheaply. No longer would we launch tools that aren’t fit for purpose, because the people building them would be domain experts in their respective fields and know exactly what’s required. Costly developers and tech teams would be required less and less, driving down costs and ultimately benefitting the bottom line.

But to be frank, this hasn’t happened and is unlikely to happen for several reasons. In fact, ‘citizen developers’ can hinder effective transformation by inadvertently creating more technical and operational debt.

Tech teams do more than just write code

Or at least the good ones do! Whilst low-code and no-code tools (as the name implies) promise to greatly reduce the amount of code that needs to be written, this is only part of the picture.

Tech teams do more than just churn out lines of code. They deep-dive into problems, understand the surrounding processes, identify root causes, develop solutions, and make sure that these solutions fit well with the other systems and processes in use at the company. In essence, they consider and understand the wider context and alignment with the overarching technology strategy.

Citizen developers typically don’t do this, and why should they? Afterall, it’s neither their job nor their area of expertise.

Processes always overlap

The ‘citizen developer’ philosophy, in my humble opinion, assumes that everyone within a company works independently, using their own systems and data, away from the rest of the business. But how many companies do you know where everything is so compartmentalised? It’s not unheard of, in fact I can think of a few examples, but it’s certainly not the norm! Processes, people, systems, and data nearly always overlap in some way.

When someone in the company builds a new tool, it will likely have knock-on effects for several other people within the team, or across the wider company. At best, these efforts will simply introduce another ‘cog in the machine’. At worst, they will create additional copies of data (‘data silos’) and cause adverse effects and confusion downstream.

‘Citizen developers’ enforce key person dependency

When a ‘citizen developer’ builds something using a low-code or no-code tool, they typically don’t document it, or explain to others how it works. In fact, when I work with companies that have tried this route, we typically uncover lots of mini systems that most people never knew existed.

Why is this a problem? Well for starters, it creates additional operational complexity and debt. Such complexity is hidden and only comes to light after some form of transformation initiative has started. One day the transformation project becomes far more complex (and costly) as these systems come to light.

Transformation aside, should the ‘citizen developer’ ever move on, or retire, then untangling what they have done and how they work becomes a tall order. Their inbound replacement (and you) won’t have an easy transition time!

Complexity doesn’t scale

This has been my mantra for 2023 and I can’t stress it enough!

All the scenarios above result in additional complexity, and complexity layered on top of complexity. But the big problem is that complexity simply doesn’t scale, or it doesn’t scale well! Companies that effectively scale have well defined processes and systems with clear boundaries and flows. Sure, some of their operations may be complicated, but they are not complex. In essence, they are repeatable, and thus scalable.

But as companies, we nearly always want to scale. Perhaps we want to sell more products, to a larger customer base, through an expanded partner network? Or perhaps our operations are creaking, and we need to streamline them so we can scale? Scale always plays a role in some form.

Complexity hinders this, it gets in the way, it costs money and leads to frustration. Managed poorly, a ‘citizen developer’ ethos will simply create more complexity as lots of little systems are implemented in an ad-hoc manner, with no alignment or communication across the company.

Do low-code and no-code tools have a place?

Yes, I think they do. But not in the way that’s been pushed down on us from big tech companies. The quality of the solutions produced by these tools is increasing every day, to the point where they can be on-par with big expensive bespoke systems.

So, should our tech teams start using these instead of writing tonnes of code? The argument is a compelling one, as tech teams can still do ‘their thing’ but only a lot quicker. What’s more, as requirements change, they can pivot easier and at less cost. Only code where it’s absolutely necessary.

Or perhaps there’s a scenario where non-technical people do use these tools, but they use them to prototype and communicate their requirements? If a picture paints a thousand words, how many words does a working prototype paint? That’s a sure-fire way to communicate requirements to tech teams and the wider business, without getting lost in a long drawn-out, and paperwork heavy discovery phase?

I like low-code and no-code tools. I use them myself, and I’ve helped many clients implement them. But my advice is to think about how you plan to use them, and don’t blindly buy into the philosophy of the ‘citizen developer’ as it’s really not that simple.