The Citizen Developer

Key to Citizen Developer Success: Set Everyone’s Expectations Properly

• By Howard M. Cohen
• November 21, 2022

Nobody knows your processes better than your operations people, the ones who actually do the job. The amount of time it takes to complete a functional spec proves this perhaps better than anything. If only your operations people could create applications themselves. Hmmm….

The stumbling block here, of course, is the need for someone specially trained and with the natural skills required to handle the complexity of coding. But there’s a concerted lack of such people, as evidenced by the global skills gap in IT: four million job openings unfilled.

But what if you shifted, or at least clearly defined, your expectations?

Getting IT Into the Red Zone

Low-code and no-code software development platforms are meant to enable people with little or no coding experience who are armed with robust knowledge of the processes being supported and the functionality required to build the needed applications themselves. The difference between low-code and no-code provides the next needed insight:

• “No” means no programmer necessary
• “Low” means low need for programmer assistance

Given these characteristics its likely that no-code tools should be used to create simple actions or automations that don’t access any corporate data resources. This includes workflow routines to support better collaboration between departments and automating simple tasks, such as sending various reminders or conveying authorizations.

When a citizen developer presents a project created using low-code tools, it should be anticipated that the application will require examination and adjustment by someone with coding experience who is also familiar with the governance required when accessing corporate data assets.

If this expectation is shared and anticipated by everyone in the organization, the citizen developer can move the ball down the field close to or into the red zone (that's inside the 20-yard line, for those who don't follow football). From there, the developer will be able take that ball all the way to the end zone and deliver a fully-formed, fully-compliant application.

Who Knows What Evil Lurks in the Hearts of Departmental Managers?

One of the side benefits of adopting low-code/no-code is that it can help eliminate Shadow IT. Identify your renegades and offer them training on a low-code platform. Commit to pairing them with developers who can assure quality and conformity, while also smoothing any rough edges in the application. This is great for the departmental managers; it helps them feel well supported. It’s also great for the developers, because their workload has been cut by whatever the citizen developers' departmental managers can provide.

The better you train those departmental managers, the more development workload they can defray.

A Dose of Reality in the Expectation Setting

There is a certain temptation to grab the nearest low-code platform, hand it to your best user, and tell them to redesign the entire enterprise ERP. It’s not impossible, just not realistic.

Although development of low-code/no-code solutions actually began in the 1970s, it's only recently that the true value of this practice has been recognized and begun moving into the mainstream. Gartner predicts that 80% of applications will be created using low-code/no-code tools by 2024!

This suggests that many of the low-code and no-code platforms are in early versions awaiting further development. Similarly, users are in the earliest stages of using these tools and require more experience and training before they can achieve success with more complex challenges.

When setting expectations for stakeholders and users, you begin at an advantage in that you are probably reducing the workload on staff programmers. Never underestimate the time a new user working with a new platform will need to produce a viable result. Be honest about timeframes. As you proceed, those timeframes will become shorter and shorter.

Remind stakeholders and users that the citizen developer starting on the project has deep knowledge of the processes and procedures involved, which should significantly improve the alignment between their needs and the design of the new application.

Also, citizen developers would be well served to enlist their colleagues in the process. Giving them more of a hands-on experience with low-code/no-code tools would give them a chance to develop a greater appreciation for the work, effort, and time required to realize a quality application.

When interfacing with stakeholders, users, and their own management, citizen developers should break down their time estimates in stages. Perhaps start with a "problem identification" stage involving the entire affected department. This could be followed by detailed documentation of the processes and procedures involved. Then the low-code platform could be used to generate the majority of the application. Finally, the developer could review the resulting application and make any adjustments required. Setting a projected time for each of these stages is more precise than simply quoting a start-to-finish time estimate.

Different Rules for Different Tools

The development of applications using low-code/no-code platforms exists in a kind of continuum. Some of the processes amount to simple additions to existing software to provide a function left out, or to create an unusual one; others are complete and comprehensive process systems.

As the number of citizen developers increases three- to four-fold over the next few years, organizations must define every step along this continuum, decide what it looks like, and assign specific rules and procedures for each one. Ideally, any employee identifying a simple problem should be enabled and empowered to create a simple routine to solve it. Addressing larger and more complex challenges will require training and certification, and the enthusiasm for working with a developer to complete the project.

Welcome to Phase One in the journey of the citizen developer!