Citizen Development and the use of low-code or no-code platforms are all the rage right now. Cloud software vendors just love to sell you on your entry-level bookkeeper creating an application that saves the Accounting team loads of time and shortens your month-end close in half. Who doesn’t want that? I know I do! Well, sorry to break it to you, it’s not all rainbows and sunshine and can have a downright devastating impact on your organization. 

What the heck is Citizen Development? 

Citizen developers are simply non-IT employees who see opportunities for using technology to make their work easier and more efficient. They use cloud-based no-code or low-code platforms to create programs using graphical user interfaces clicking and dragging a mouse instead of traditional code. 

Marketers will use catchy phrases like “clicks over code” and “configuration instead of development” to illustrate just how easy it is. 

Does it really work? 

Yeah, it does. In many cases, the approach can allow creative and entrepreneurial types in an organization to build applications and automations that can be very beneficial and allow for a more cohesive and streamlined business process. 

There are many platforms out there that have these capabilities. Some of the leaders are Salesforce.com, Hubspot, Betty Blocks, OutSystems, Mendix, etc. Heck, even basic project management platforms such as ClickUp have joined the movement, albeit in a little more restrictive manner. 

It’s clear to see why these capabilities are so popular and marketable. Everybody wants to do more with the resources they have, especially in the current environment where the demand for traditional technical resources is through the roof. Most small businesses simply cannot afford to keep enough technologists on staff, and thus technical backlogs grow and business stakeholders are left searching for ways to innovate. 

Benefits of Citizen Development 

• Accelerates digital innovation and transformation 
• Reduces current IT backlog and shortens time to value 
• Reduces the need to hire additional hard-to-hire and expensive technical staff 
• Increases the entrepreneurial spirit within an organization by allowing end-users to solve issues they observe in their workflows 

Sounds great, what’s the catch? 

Where do I start? No, really, even with how innovative and great some of these tools are, they can stop an organization dead in its tracks. 

There are so many cliches I can throw out on this part of the discussion, but the two that come to mind are “Just because you can, doesn’t mean you should” and “Knowing enough to be dangerous”.  

I won’t argue that it’s not a good thing to enable end-users in a way that gives them some autonomy in their work and environment, however, there has to be oversight and governance. 

I cannot count the number of times in the Salesforce.com ecosystem that I’ve run across applications or automations that have been created by someone in the business (non-IT or traditional developer/architect) that has slowed their org to a grinding halt.  

It usually starts off as something trivial, but then somebody else comes along and adds something trivial on top of that. And so on, and so on, you get it… 

Eventually, this small piece of automation that was by itself harmless, has become a “common-law feature”, meaning it started as an insignificant item, but has been engrained into the core flow of the overall system. 

At some point, it breaks. It usually happens at the most unexpected and opportunistic time, without warning. 

Everybody scrambles to figure out what the issue is, but nobody knows, because it’s not clear what is causing the issue and IT has no clue because they had no part in building it.  

So, after significant downtime, a developer ends up debugging the system and pinpoints the issue back to something Jane put in production several years ago. There’s no history of what the solution was supposed to do, how it was tested, and what significance it has in the overall system.  

Meanwhile, all that “time saved” years ago has caused an outage today, when the stakes are higher and the impact is multiplied. 

Scared yet? 

You may think the story above is hyperbole, but it is more common than you think. The good news is that Citizen Development isn’t all bad and there are things you can do to make it successful. 

Having success with Citizen Development all starts with having some form of governance and change management. 

Governance is an overloaded term and comes in many forms. However, with Citizen Development, all I’m referring to is having somebody that IS formally trained in software development or architecture, or even a small committee, be involved at some point in the process. 

This can be as simple as formalizing a “change control” process where all changes that are to be made to a production environment get reviewed by either a single admin/developer, a committee, or some other group that is responsible for reviewing candidate changes and ensuring that they are architecturally sound to go into the production environment. 

Obviously, if you are going to go through that trouble, you may as well capture and document who made the change, what was created/changed, what it was intended to accomplish, and when it was put into production.  

Simply getting somebody in the boat with you and documenting the change can go a long way to adding the necessary guardrails to prevent improperly architected from entering production and also leaves an audit trail to understand the intent and details in the future. 

Conclusion 

Let’s face it, the typical Citizen Developer is analogous to an amateur stepping in to do a professional’s job. Just because you are smart and resourceful, does not mean that you understand enough about good software architecture, practices, and procedures to successfully build systems. You may be able to peck around the edges and make some small improvements here and there, but it’s best to leave the heavy lifts to the pros. In either case, you need to make sure to establish a minimum practice of documenting and have somebody with experience review your changes to ensure you are not planting a ticking time bomb. 

Go forth and build, but do so with a safety net!