The term 'citizen developer' is getting a lot of attention – and rightly so – but there’s a lot of hype and a lot of overlap with other popular ideas. Gartner defines a citizen developer as 'a user who creates new business applications for consumption by others using development and runtime environments sanctioned by corporate IT'.
I work at a company to whom citizen development matters a lot, and I’d like to pass along a few observations on the subject.
It’s not the same thing as low-code/no-code development
The biggest adopters of low-code/no-code development tools are developers and IT pros, not users. It turns out that developers like to save time, reduce busy work, and make fewer mistakes just like the rest of us, and when an easier environment can do the job, they use it.
Low-code/no-code development means exactly that: development without coding. You might do very formal projects with very formal deployment models, etc. You might still need to think like a developer (compare 'loop, test for a condition, exit loop' with 'wait until something happens') at every step of the way. And sometimes that’s an asset.
Citizen development-grade low-code/no-code tools usually try to reduce the need to think like, and operate like, a developer. Citizen development needs low-code/no-code tools, but there’s more to it than that.
If you think 'citizen developers' don’t really exist, you’re looking in the wrong places
If you go looking for marketing managers, accountants, salespeople, operations managers, etc., who have temporarily dropped everything they’re doing to start writing software, that indeed doesn’t happen much.
But when financial analysts create elaborate Excel macros? When a salesperson uses Zapier to sync Salesforce.com customers/leads with their Office 365 contacts? When a data analyst creates an automatic data import job and builds custom dashboards? When HR creates a process to take collaboratively-edited employment contracts and route them to recruits using DocuSign? That’s citizen development, or at least the beginning of it.
You can even see some citizen development tools embedded in the apps people already use.
Development, to some extent, is becoming another business skill
Answering the phone, typing memos, sending mail, preparing budgets? They all used to be specialised skills done by specialised people. They gradually became a normal part of virtually every job.
This is happening with development skills. For example, almost everyone knows how to use Excel, at least on a limited basis. Certainly some people are much better at it than others, and you can find people who are good with Excel on almost any team. That said, their job isn’t to 'do Excel' – it’s to 'use Excel' to do their real job.
That’s expanding. If it’s your job to work with data, or your job to share content, it’s increasingly going to fall to you to work out how to get it, share it, and move it to where you need it. That’s development.
A lot of citizen development looks like integration, and it should
Some of the most vexing user-level problems involve having to re-key or manually copy information from place to place, or not having access to the right content at the right time.
Many apps now want to be integrated. We’ve arrived at a few standards for identifying users, making requests, and returning data, and it’s in the interests of most modern apps to be easy to integrate.
The most common pattern of citizen development is connecting together multiple apps, much like snapping together a set of LEGO® bricks.
Microsoft Flow, Zapier, and IFTTT let you connect a given web app to another given service and decide what to pass along the way. Some ready-to-use services, the popular travel & expense Concur coming to mind, have this 'plug it in' capability built in. My company, Nintex, takes this app-to-app communication model and combines it with rich process logic.
The word 'citizen' means more than just 'user'
Citizen development is not 'random ad-hoc power user projects'. The word 'citizen' implies participation and civic responsibility. When applied to development, that means working with IT-managed resources, not bypassing them.
This is where some tools like IFTTT fall short, actually. They don’t provide an organisation-wide view of who’s using what, and how. In fact, a number of low-code/no-code tool fail to provide the management/monitoring/oversight that’s needed to provide distributed work; they weren’t meant to be used in citizen development scenarios, so they assume everyone using them understands deployment, reuse, and plenty of other development principles on their own.
Citizen development is a mindset
Although low-code/no-code tools are a de facto prerequisite for citizen development, the way they’re used matters. First off, citizen development is iterative. It’s rare that all requirements are understood in advance, and attempts to draw them out prematurely lead to inaccuracy. The most effective way to do citizen development is to create a quick initial solution, try it, note what’s wrong/missing, and improve it, and repeat.
Secondly, citizen development is messy -- if IT isn’t involved in a coaching/sharing/curating role. Citizen developers are less likely to undergo rigorous testing, to do versioning of assets, to factor them into components, etc. IT needs to select tools that allow them to keep track of activity, to provide a library of reusable assets, to share best practices, and so on. Formal development is a profession, with a variety of disciplines, and citizen developers are not likely to adopt them. IT has to maintain a balance of allowing citizen developers plenty of room to get things done but not so much room that they hurt themselves or their organisations.
Thirdly, with IT involvement, citizen development is collaborative. The model of snapping together components works best when IT can point citizen developers to good components. IT can recommend ways to solve frequently-encountered problems. Consultants can be brought in to create work-for-hire solutions, but with the understanding that citizens may well be modifying/extending them after the fact.
Citizen development is your best-case outcome. Users have myriad needs that IT’s formal solution queue will never be able to adequately prioritise. Departments and their users will bypass IT to get what they want, using their own budgets to buy, build, or commission solutions. Moreover, when faced with the option of requirements being lost in translation with coders or the option of doing it themselves, an increasing number of users will choose the latter. To turn rogue users into responsible citizens requires a combination of the right tools and the right attitude. It’s worth it.
Mike Fitzmaurice, VP of Workflow Technology, Nintex