Citizen development has been promoted by many—particularly platform vendors and consultants that orbit them—as a near-magic solution to enterprise development challenges. If only that were the case. For the majority of organizations, citizen development, at least as popularly conceived, has generally not worked.
Before discussing why, and what to do about it, let’s define what we’re talking about: a citizen developer is a user whose job is not in development, but who nevertheless creates applications, typically using low-code/no-code (LCNC) tools. The practice is meant to address two primary problems: first, the application backlog facing many organizations. Simply put, there’s greater demand than supply, and development teams often struggle to keep up. In fact, 86% of IT decision-makers say the biggest digital transformation challenge is too few software developers. Second, the stakeholder/developer disconnect problem which, to be clear, is a two-way street: developers often lack an innate understanding of the business challenges facing users, while users often misunderstand what is technically possible.
The well-meaning solution for many organizations is to just put easy-to-use tools in the hands of users so they themselves can build the solutions they need. For many citizen developers, the need tends to be very personal—scratching an itch of sorts—commonly to either automate a tedious and/or error-prone task or to address a broader need that can’t be tackled by IT for an unacceptably long time.
While more applications certainly get built with citizen development, it also diverts significant time away from other productive efforts. Citizen developers aren’t creating applications in their spare time; they’re doing it instead of other work. Moreover, and not to put too fine a point on it, citizens are not developers. They lack the expertise, vision and mindset required to build sustainable, scalable and sometimes even functional solutions. As a result, time also gets diverted from IT: either fixing broken citizen applications or figuring out how to actually scale successful ones.
That said, on occasion, citizen development produces stellar results. When it works, it can transform citizens and developers, IT and organizations. Some citizens get so good at development that it becomes their day job. Developers in turn use LC/NC tools to save time, allowing them to focus more on better understanding specific business challenges (sometimes even becoming dedicated to particular divisions or departments). IT can enthusiastically support citizen development with tools, training and even reusable components. And organizations find that they have less of a “shadow IT” and more of a “satellite IT”—an extension rather than a replacement.
To make citizen development work requires rethinking the approach as one of citizen-assisted development (CAD). Rather than handing off development wholly to power users, the hybrid process is shared between power users and development professionals. And if this sounds like the well-established Joint Application Development (JAD) approach, that’s not accidental. The difference is that citizens can do some of the work themselves, while not being responsible for all of it. Where JAD is analogous to a police sketch artist working with a witness, CAD is closer to a talented person designing a prototype that a professional then figures out how to refine and mass produce.
This distinction is critical, as it can address the challenges—application backlog and stakeholder/developer disconnect—while largely eliminating the challenges associated with non-professional applications. Developers and citizens get a tangible sample to iteratively collaborate on, while both are using a cohesive toolset to speed results. Moreover, it eliminates the need for obsessive spec writing, contract-style thinking and cover-your-*** behavior as things become simple and low-cost to change.
If this sounds attractive, the question is how to get there? It boils down to three steps:
-
- Step one is the tangible prototype. This still means putting LC/NC tools into the hands of citizens; the difference is who they’re developing for. Instead of shooting for production use, power users should create a prototype for collaboration with peers and developers. The goal is not to solve the problem, it’s to show (not tell) the developer what they want.
-
- Step two is explication and elaboration. Integration with other systems? Security? Scalability? Encapsulated, reusable components? Metrics and auditing? These are issues to be addressed by professionals—ideally using the same tools and platform as the citizens. Having the same platform to work from means you’re not trying to convert a sketch to conform to reality, you’re using the same example workflows, forms and data as the citizens. Developers can move more rapidly because they’re essentially starting from a better position.
-
- Step three—and it’s really Step ∞—is continual communication and adaptation. Even after the handoff to IT has taken place, user stakeholders remain involved. But instead of waiting on deliverables, they’re examining and commenting on work in progress. As importantly, the bar to “success” is dramatically lower because iteration is simple. Developers can get something into the hands of users and, again assuming the right tools and platforms are in place, make improvements and changes while systems are in use (in fact, using change-friendly tools is critical, as a high cost of adjustment pushes the relationship back into contractor-client mode). A side benefit is an inevitable immersion that takes place, as developers come to understand not just the “what” but the “why” behind various decisions, while citizens learn the technical considerations and limitations of various choices.
Citizen development isn’t easy, and it’s certainly not a panacea. That said, the motivation behind it is real. The citizen-assisted approach borrows and melds the ideas and advantages behind both citizen and professional development into something likely to succeed far more often.
