Many organizations have tried — and failed — to successfully implement citizen development initiatives. The theory behind the model is alluring: Leverage low-code/no-code (LCNC) tools to enable business users to build their own applications. Who knows what users need better than the users themselves? It’s a pitch that many advocates have been making.

But the unfortunate reality is that businesses rarely find citizen development to be the right model for their organizations. There can be a lot of finger pointing for organizations when citizen developer projects fail. As for why, I see it play out any one (or more) of four ways:

A lack of expertise

Perhaps foremost is the fact that business users lack the skills and technical expertise of professional developers. It’s the old adage that a hammer doesn’t make a carpenter.

First, there’s logical expertise. Citizen developers don’t always think to do things like normalize data. They might not know about encapsulating reusable functionality into functions and rules, and instead repeat a lot of procedural work.

Discipline expertise, in the sense of subject matter awareness, is also a concern. For example, knowing which data sets are necessary is just as important as knowing how to query them. In workflow scenarios, understanding the implications of parallel activity and whether two or more things are truly independent of each other, or whether there’s some expectation of sequence that’s never been written down, is far from trivial.

Finally, there is method expertise. This is more about methodologies and project management than tools or algorithms. It includes things like iterative development cycles, putting applications through development-testing-production stages, and delivery rings for testing new features on a subset of users before rolling them out to successively larger groups. This is usually the kind of thing citizen developers safely avoid — unless their creations become popular.

A lack of vision

This isn’t a lack of vision of what users want, as citizen developers almost always know their users (because it’s themselves). Instead, this is a lack of vision into what the application will need to become next; how it can be maintained and evolved. Too many applications become crises the moment they acquire two or more users. Too many citizen developers find themselves saying, “It was a great solution — until I shared it.”

If you’re developing a solution for yourself, it’ll reflect the benefits you wanted and will incur costs/tradeoffs you deem acceptable. It reflects your priorities. The problem is that someone else’s priorities are almost always guaranteed to be different. And the moment you agree to help them, you become responsible for them. Some sacrifices that are fine for you aren’t fine for them. They demand changes, and they want them right away. And just like that, you’ve become a miniature version of the IT department.

A lack of fit

This refers to a sense of knowing which tools and techniques to use to solve different kinds of problems. Without this awareness, citizen developers often attempt to use the same tool to fit every possible problem. In most cases, while the tool allows you to avoid coding like a developer, it doesn’t eliminate the need to think like one.

Tool builders often work around this issue by using wizards. Wizards walk aspiring citizen developers through a series of questions and choices, then generate a ready-to-use (or at least ready-to-adjust) application for them. But wizards work because they impose countless constraints on available choices and on which kinds of problem they’re prepared to address.

If constraints aren’t acceptable, you’ll need to think like a developer. This challenge cuts both ways: Professional developers, despite their best efforts to interview, discuss and negotiate requirements with users, still struggle with understanding the business task at hand and the desired outcomes of the applications they’re asked to build.

A lack of consistency

As citizen development is adopted, from an organizational perspective this isn’t about one application. It’s about two, five, 20, 50, or even hundreds of applications — and where each one is completely unique.

Lack of consistency drives users crazy. It also increases training costs, slows down adoption, and makes every new application a one-off job with no ability to borrow from previous work. That drives management crazy. At the end of the day, it makes it much harder — if not impossible — for anyone who’s not the author to maintain the application.

How IT can rethink citizen development

Taking all this into account leads to two observations: First, difficulty with citizen development doesn’t directly equate to failure of LCNC tools. It’s the approach, not the tools, that can lead to problems. In truth, LCNC tool are used far more often by professionals than they are by amateurs. Second, just because the pendulum might have swung too far in one direction doesn’t mean it has to swing all the way back in the other.

Citizen development is not easy, it’s not a panacea, and it’s certainly not magic. In fact, without the right organizational culture, it may not work at all. That said, the idea of citizen development has value, and the motivation behind it is real. A hybrid model of citizen-assisted development borrows from the best ideas behind citizen and professional development and melds them into something likely to succeed far more often. Citizen-assisted development assigns the right responsibility to the right people and keeps them working together the entire time.

Stakeholders and users are assigned the task of creating something (perhaps using an LCNC tool) that illustrates what they want. Professional developers are assigned the responsibility for making those prototype examples into things that really work, considering exceptions that must be handled, integration that cannot be taken for granted, data access security, etc. Instead of citizen development giving birth to applications that get orphaned close after, it’s a shift to creating sustainable teams that are made up of innovators and curators working together.

How does IT woo would-be citizen developers? By pivoting to soft power and ceding hard power, offering things of value, things that are hard to do when citizen developers attempt to go it alone. Things like:

• Lower-cost licenses. IT can purchase these at scale.
• Painstakingly researched and selected tools. IT has the time, expertise, and hopefully the will to do this, and its expertise can make sure that applications aren’t just easy to drag and drop but are also secure and governable.
• Education and training to bring the cost of acquiring knowledge down and significantly speed up the process.
• A curated library of resources, components, data sets, and other things that don’t have to be reinvented every time. Security matters here, but it ought to focus on right-to-know as opposed to need-to-know.
• Expertise with integration. Arguably, it’s hard for anyone other than IT to do this. Individual citizen developers in different departments are ill-equipped, and in some cases unwilling, to share data and APIs with each other.
• Deployment and update management.
• Backup/restore and other continuity-of service practices.
• Advocating design standards. This is true for user interface consistency, as well as techniques and resources.
• IT’s overall responsibility for applications — so citizens may remain responsible for business while the applications created for them are not getting orphaned.

None of this is easy — but, ultimately, it’s lower risk and higher payoff.

Mike Fitzmaurice is WEBCON‘s Chief Evangelist and VP, North America and has more than 25 years of product, consulting, evangelism, engineering, and IT management expertise in workflow/business process automation, citizen development, and low-code/no-code solution platforms and strategies. His decade at Microsoft included birthing technical product management and developer evangelism for SharePoint products and technologies.