There is a version of citizen engineering that transforms how organisations deliver value. There is also a version that quietly accumulates risk, duplication, and fragility until something expensive breaks.
Most organisations that adopt it end up with the second version - not because the idea is bad, but because they mistake access for enablement and freedom for strategy.
Here's my honest take on what citizen engineering actually is, why the tension at its heart is real and important, and what separates the organisations that use it well from the ones that don't.
What Citizen Engineering Actually Is
Citizen engineering - often called citizen development - is the practice of enabling non-professional engineers to build software, automations, and data solutions using low-code or no-code platforms. Tools like Microsoft Power Apps, OutSystems, and Zapier give domain experts in operations, finance, HR, and product the ability to create:
- simple applications
- workflow automations
- dashboards and data pipelines
- integrations between tools
At its core, it shifts who can build.
That shift is meaningful. The people closest to operational problems understand nuance, see inefficiency, and know what good looks like. They are often the last people in the queue when it comes to getting engineering support. Citizen engineering lets them act on their insight directly.
This is not a new phenomenon dressed up in new language. What is new is the quality and accessibility of the tooling. Platforms that would have required months of specialist integration work a decade ago can now be wired together in an afternoon by someone who knows what they want to achieve and is given the right guardrails.
Why the Bottleneck Problem Is Real
In most organisations, engineering capacity is genuinely constrained. Teams are carrying technical debt, maintaining live systems, executing on roadmaps, and absorbing the cognitive load of an increasingly complex tooling landscape. The result is a queue - a long one - of small, legitimate needs that never quite make it to the top of the backlog.
A finance analyst who needs to automate a monthly reconciliation process should not have to wait six months for an engineering sprint. An operations team that needs a simple form-to-Slack workflow should not need a Jira ticket reviewed by an architecture board.
Our Flow & Delivery policy is explicit: delivery systems should minimise handoffs and remove unnecessary constraints on teams doing valuable work. Routing every small problem through central engineering violates this principle. It creates artificial bottlenecks that frustrate the people closest to the work and erode their confidence that engineering is a partner rather than a gatekeeper.
Citizen engineering addresses this directly. When small problems are solved at the edge - quickly, by the people who understand them - engineering teams are freed to focus on what only they can do: complex systems design, platform capability, scalability, reliability, and long-term architecture.
This is a meaningful alignment with the Sooner and Value outcomes in BVSSH. Faster feedback loops. Earlier validation of ideas before committing significant engineering investment. Solutions that don't require translation through multiple layers of abstraction before they reach the person who will use them.
The BVSSH Case, Honestly Made
It is tempting to present citizen engineering as a clean win. The BVSSH alignment is genuine, but it needs to be made honestly rather than selectively.
Better. Citizens building their own tools can improve the quality of outcomes - but only where they have sufficient domain knowledge and the platform guardrails to prevent them from inadvertently building the wrong thing well. Without quality standards, citizen-built solutions have a habit of encoding incorrect processes in code that then becomes load-bearing.
Safer. This is where citizen engineering most commonly fails. Ungoverned low-code development creates shadow IT: solutions with no security review, data handling that bypasses compliance controls, and integrations that expose sensitive information to unintended audiences. Our Embed Security into Delivery policy applies here as clearly as it does to professional engineering work. A Power App that writes to a production database without access controls is not safer because a business analyst built it.
Sooner. The strongest case. Domain experts prototype immediately. Iteration cycles that would take weeks in a traditional delivery model take hours. The time from insight to working solution collapses. This is real and measurable.
Happier. Also strong - in both directions. When people can shape their own tools, ownership increases and frustration with slow systems decreases. Innovation emerges organically. Our Engineer Experience as a First-Class Product policy exists precisely because tooling friction has a direct cost to motivation and effectiveness. That principle extends beyond professional engineers.
Sustainable. The most underweighted outcome. Citizen-built solutions carry hidden maintenance costs. When the person who built a critical automation leaves the organisation, what happens? When the underlying platform changes, who owns the migration? Sustainability requires clarity about what has been built, who owns it, and what its lifecycle looks like.
Value. Realised when citizen engineering creates outcomes that matter, not just activity. Value is not measured in the number of Power Apps deployed. It is measured in time saved, errors eliminated, decisions improved, and engineering capacity released.
Where Most Organisations Fail
The failure mode is not adoption. Organisations that make low-code tools available find that people use them - enthusiastically and immediately.
The failure mode is governance arriving too late, after the solutions have already proliferated.
Six months in, the symptoms emerge:
- Duplication. Three teams have independently built near-identical automations with minor variations, none of which are aware of each other.
- Fragility. Silent failures. Automations that break without alerting anyone. Workflows that pass bad data downstream for weeks before anyone notices.
- Security exposure. Solutions that handle personally identifiable information, financial data, or customer records without audit trails, access controls, or data residency compliance.
- Orphaned ownership. The person who built the solution has moved roles. No one else understands it. It cannot be modified without risk.
- No measurement. No one knows what value is being created. There is no visibility into what exists, let alone whether it is working.
This is the shadow IT problem that IT departments have fought for decades - now with a more accessible toolkit and a more sympathetic framing.
The solution is not to restrict access. Restricting access before trust is established will kill the model before it creates value. The solution is to build the governance infrastructure in advance, not in response.
What Good Looks Like
The organisations that use citizen engineering well treat it as a capability, not a feature. They build the conditions for it to succeed before they open the door.
A platform layer with real guardrails. Approved tools. Pre-built, reusable components. Governed integration patterns that have been through security review. Templates that make the right path the obvious path. This connects directly to our standard on [Internal Developer Platforms Provide Reusable, Well-Supported Capabilities] - the principle holds whether the consumer is a professional engineer or a business analyst.
Clear boundaries. Citizens should know what they are empowered to build and what must stay with engineering. This is not a bureaucratic gate; it is clarity that enables confidence. "You can build automations that operate within the approved data tier" is a statement that enables action. "Everything needs a ticket" is not.
Observability is non-negotiable. Every citizen-built solution that runs in a production context must be observable. Logging, alerting, failure detection. Our [Failures are Rapidly Detected, Understood, and Recoverable] standard does not contain an exemption for low-code solutions. A broken automation that fails silently is not better than a broken automation that alerts. It is worse.
Enablement, not abandonment. The most common mistake after a governance failure is to interpret it as evidence that citizen engineering doesn't work. It is more often evidence that the citizen was set up to fail. Training, coaching, communities of practice, and patterns reduce the error rate dramatically. People want to build things that work. Give them the knowledge to do so.
A lifecycle and an owner. Every solution that moves beyond a personal prototype should have a named owner and a defined lifecycle: active, maintained, deprecated, or migrated to a professional engineering product. Solutions that demonstrate sufficient value and scale should graduate into the engineering backlog as properly engineered products. That graduation path should be explicit.
Measurement. Track what is built, by whom, with what impact. Identify duplication early. Quantify the value created. Use that data to refine the model. Our [Quantify and Communicate Automation Return on Investment] standard applies directly here.
The Strategic Framing
Citizen engineering is not about replacing professional engineers.
It is about shifting the operating model from:
- centralised control → distributed capability
- engineering as bottleneck → engineering as platform
- delivery teams → product ecosystems
Done well, professional engineers stop being a queue and start being a platform. They define the guardrails, own the infrastructure, and curate the patterns that make it possible for others to build safely. This is a higher-leverage use of scarce engineering talent than building basic forms and one-off workflows.
This framing is consistent with our Automate Everything Possible policy - but interpreted correctly. The goal is not automation for its own sake. The goal is removing low-value manual work from every layer of the organisation, including from engineering. Routing solvable problems to the people who understand them is exactly that.
The [Golden Paths Enable Teams to Deliver Without Unnecessary Cognitive Load] standard provides the architectural frame: a golden path is a set of opinionated, well-supported defaults that make the right way the easy way. Citizen engineering needs its own golden paths - approved platforms, certified connectors, security-cleared data sources, template automations - so that the default choice for a citizen builder is also the safe and maintainable one.
The Honest Conclusion
The value of citizen engineering is real. The risk is also real. The organisations that realise the value are the ones that take the risk seriously before it materialises.
If you are considering a citizen engineering programme, build the platform before you open the doors. Define the boundaries. Instrument the solutions. Create the community. Establish the lifecycle.
If you have already opened the doors without these foundations, you have work to do - and the right sequence is to establish governance around what exists before expanding what is permitted.
Done well, citizen engineering is a force multiplier for your operating model: it distributes capability, accelerates delivery, and frees your best engineers to work on the hardest problems.
Done badly, it is uncontrolled entropy - technically invisible, strategically ungoverned, and eventually expensive.
The choice is structural. Make it deliberately.
