Behind the hype does citizen development really work

Most transformation programmes talk about automation at the enterprise level. Fewer ask the harder question: who actually builds it? And what happens when the people closest to the problems are left out of the solution?

That gap is what citizen development is designed to close. Instead of routing every automation request through IT, it puts the tools in the hands of frontline employees. They spot the friction, design the fix, and own the outcome.

The concept sounds straightforward. Does it actually work at scale, outside a pilot, in the day-to-day reality of a large services organisation?

We ran the experiment ourselves. Across two of our key business units, we took citizen development off the whiteboard and tested it in practice. The results are documented in our case study The Firstsource Automation League: Democratising automation at Firstsource with citizen development. Three things stood out.

1. Mindset change is the actual work

Citizen development is not a coding initiative. Framing it as one is why programmes stall.

The real resistance is psychological. People get comfortable with their workarounds. Handing part of your job to a bot feels threatening when that job is tied to your livelihood. Leaders who skip the culture work and jump straight to tooling consistently underperform.

What moves the needle is giving people a safe environment to experiment. Not mandating adoption. Not measuring bot counts. Letting curiosity do the work, then reinforcing what sticks. The Automation League was built on that principle: show people what technology makes possible, and let them discover what they are capable of with it.

2. Small automation compounds fast

Organisations tend to chase the big transformation moment. The enterprise-wide deployment. The headline efficiency figure. Citizen development works differently. It accumulates.

Behavioural scientist B.J. Fogg describes sustainable change as the product of small, repeated habits. That holds in automation too. A bot that saves a team leader ninety minutes a week looks modest in isolation. Multiply it across a business unit, across a year, and the compound effect is material. Each small win builds appetite for the next one.

Training and mentoring around that compounding logic, not just tool proficiency, is what makes citizen development stick.

3. Bottom-up scales better than top-down

IT-led automation programmes depend on IT bandwidth. Citizen development distributes the dependency. Bots that frontline employees build get used because they solve real problems the builders live with every day. They spread organically through informal networks because they actually work.

A small number of early adopters become evangelists. Their results become proof. Others follow not because they were told to, but because they saw what was possible. That self-reinforcing dynamic is far more durable than top-down rollouts and scales into territory that centralised programmes typically cannot reach.

Governance is non-negotiable

One constraint matters before any of this works: compliance and InfoSec must be involved from day one. Citizen developers on the frontline cannot be expected to know every regulatory and data protection requirement relevant to the solutions they are building. Shadow IT is a real risk when governance is an afterthought.

Getting that scaffolding right early is what separates citizen development programmes that sustain from those that collapse after the pilot.

We have applied the lessons from our own programme to the Automation League framework for clients.