Why Your Citizen Developer Efforts Are Stalling

The concept of the ‘citizen developer’ has been around for the better part of the last decade, but it is only in the last few years that it has really come to the fore in the minds of business leaders.

That is due largely to the confluence of several trends.

• One is the broad embrace of digital transformation. The skills and ideas to transform need to come from somewhere. In the current climate of skills shortages, it makes sense to look and foster these capabilities from within in the first instance.

• Another trend is the rise of low-code platforms, which promise “to enable people who aren’t programmers to develop the software they need” in order to work more efficiently.

• A third trend is the increasing onus on employees to be continuous learners. The World Economic Forum estimated pre-pandemic that employees would need “101 days of retraining and upskilling” between 2018 and 2022 just to stay relevant and employable. Given the rapid changes since 2020, that requirement would have risen substantially.

All of which has led to the idea that workers of the future will be incredibly well-rounded digitally, bolstering their existing business acumen and domain knowledge with newfound technical nous that drives continuous improvement into business-as-usual practices.

This is a popular though ultimately flawed definition of what makes a citizen developer. Notably it is a definition that has a couple of misconceptions which, if left unchecked, will counteract the entire exercise.

I want to spend some time outlining these misconceptions, as being able to recognize them will leave business leaders and their organizations well-placed to create sustainable citizen developer efforts.

1. Citizen Development Should Not Be an Extra Imposition on Employees

Too many citizen-development-gone-wrong strategies ask employees to do more, on top of what they already do for the organization.

This is the reason we see pushback: people are already at capacity. They barely have time for business-as-usual tasks, let alone special projects. Asking them to find time to develop additional skills that are ultimately peripheral to their day-to-day lives is asking for trouble.

Organizations with citizen developer ambitions must first appreciate employees’ day jobs. If they want to prioritize innovation, it should be a formal carveout. Google popularized this model with the 20% Project, where up to one-fifth of an employee’s time can be invested in side projects. Similar models are used by Atlassian and Apple.

Now, obviously, not every organization has this luxury, but good results can be achieved in as little as a sanctioned hour or two. I run short, non-technical workshops that show ways to innovate with software that does not require coding skills to use. The idea is to seed the art of the possible. I want people to go back to their business areas inspired to start a conversation and positively influence their operations.

Citizen development in my mind is about raising awareness of what digital business tools can do and how they can improve, and even transform, business-as-usual. A conversation can then be had on how to resource the build.

Related Article: Can Citizen Developers Fix Information Management?

2. It’s Not Only About Employees Building Things

Too many citizen developer models focus on employees building their own digital tools.

This assumes too much: it assumes that people in the business want to learn coding skills to pursue productivity improvements. It assumes that the products and tools created with a crash-course in coding will meet organizational standards and not require additional rework. And it assumes that the business has time to take all of this extra work on.

We’ve established that if an organization wants citizen developers to innovate, it needs to give them time to do it. That applies even more so if citizen developers are also expected to build their own tools. Organizations should provide suitable low-code platforms that make the assembly and maintenance of these new digital tools easy, and that embed governance and compliance guardrails that ensure whatever citizen developers produce is valuable. Misconfigurations can be costly, and are easy to do, especially when people are offered only a minimum of technical training.

I always come back to the model adopted by a big pharmaceutical company. They set up a questionnaire to understand the business-as-usual pain experienced by employees and stood up a two-speed model to address it. If a pain point was deemed simple enough, an employee could opt to build a solution from a template, and IT would review it and do the final push to production. If the pain point was more complex, IT ran the build and asked the employee to review the tool prior to deployment.

This model worked for several reasons. First, it made their citizen developer effort more about sourcing ideas and engaging citizens without creating unnecessary extra work for them. Second, it struck a good balance in who did the actual development work. Citizens that wanted to be more hands-on could do so, but it wasn’t solely their responsibility. It also created a close and productive collaboration with IT, helping everyone in the organization to “win together.”

Organizations everywhere are racing to digitally transform, which is driving increased demand for software solutions that are both easy-to-use and powerful. The best decision your organization can make — if it wants to win the race to digital — is to involve your people in the process and equip them with tools that quickly transform work.

Related Article: What it Takes to Build a Citizen Developer Program