One of the biggest trends emerging in Robotic Process Automation (RPA) today is its democratization: RPA is now more accessible and affordable than ever before. A driving force is the evolution of standard tools and low/no code environments that make it possible for non-software developers to create automated workflows. For example, Microsoft’s Power Automate Desktop is available for free to all Office 365 users in Windows 11. This means any Windows 11 user has tools and prebuilt templates at their fingertips that enable them to construct automation workflows for free with little to no coding experience.
With the launch of these widely available tools, a new role has now emerged: the citizen developer. With the emergence of this role has come potential upsides – and some serious challenges that must be weighed carefully before diving headfirst.
Here we dive into the difference between citizen developers and RPA developers, as well as the pros and cons of leveraging citizen developers in your organization.
What is a citizen developer?
The idea of a “citizen developer” is a modern response to the traditional software developer or someone who is trained in software development across any popular set of programming languages. Citizen developers can come from almost any background – they don’t need a software engineering degree or past coding experience.
Gartner formally defines a citizen developer as “an employee who creates application capabilities for consumption by themselves or others, using tools that are not actively forbidden by IT or business units…There is no required designation of proficiency or time allocation for citizen developers, but they must be legal employees of an organization.”
This is the idea of the citizen developer defined in the broadest sense of the word, often used to describe individuals that are building software apps for their team using a low-code/no-code solution. For the purposes of this post, we’re focusing on a narrower sense of the term: citizen developers who are focused on building RPA solutions. In other words, a non-technical business user creates simple automation for personal use or for their department’s use.
Why is the idea of a citizen developer popular?
Many small-to-medium-sized organizations do not have the budget or headcount to staff their RPA program with professional developers. Historically, this has made it challenging for these companies to accelerate the use of automation and scale the program quickly throughout the organization. Citizen developers are in many ways an attempt to satisfy these business needs quickly.
For example, from an IT standpoint, there is a never-ending backlog of requests to improve the infrastructure of a business, particularly as it’s growing. From a business standpoint, business users are always in need of methods for improving efficiency across the suite of software tools they use on a daily basis.
If IT were to manage both of these needs, it would lead to slower results for both parties. Citizen developers have been presented as the solution to this challenge since it enables the affected employees to begin problem-solving within their own departments. With a clearer focus on their pains and processes, than IT may immediately understand, it may lead to a more rapid solution overall.
Citizen developer roles can also have other benefits, like enabling employees without programming experience to upskill and take on new and more meaningful opportunities, which can increase employee satisfaction and retention. Leveraging the perspective of those who know the work most intimately can result in more effective automation. However, that doesn’t necessarily mean they are the best people to map, implement, maintain, and optimize the automation.
So are citizen developers a good idea, or a bad idea?
The potential upside for citizen developers has received a lot of press, with countless articles claiming that citizen developers are the nascent future. They promise that you won’t need to employ a bunch of expensive software developers with traditional expertise to complete your internal automation development. While it’s easy to read some of these exciting claims, there’s more at play than one might first consider.
First, RPA development, while simpler compared to traditional software development, still requires adherence to software development best practices for everything from naming conventions to designing for portability, scalability, and reusability. Without a best practices framework, it is very challenging to develop automation scripts that hold up to your business requirements in the long run. Citizen developers might be able to put together a “working” script, but it is unrealistic to believe that they are going to develop “production-ready” scripts that will run without failure day in and day out. In addition, if a citizen developer leaves your company, it can be difficult to migrate the automation scripts they have written to their successor. This could cause interruptions in your processes, and issues should your company choose to employ a trained RPA Developer in the future.
Citizen developers often have a limited understanding of how the problem they’re trying to solve with automation impacts other company objectives. Their narrow focus on a specific task can be a major disadvantage. The most successful RPA programs are truly programs, not a collection of disjointed projects. Successful RPA programs have appropriate governance and a Center of Excellence (CoE) in place to make sure each piece works towards the overarching goals of the program.
There are other important concerns that come with a lack of training that can negate potential cost-savings from a DIY approach. For example, security must be a top priority when designing automation scripts, something that the average citizen developer will not have the training to execute. In addition, effective development requires strategy and experience to identify the most effective approach to improve the existing process. A cardinal mistake in this space is automating a flawed process, and citizen developers may lack the training, experience, and broader perspective to avoid these situations.
For these reasons, we recommend that automation scripts be developed and managed by an RPA development team, whether in-house or outsourced.
Finding the right balance
Once you’re ready to start automating work at your business with RPA, our recommendation is to first work with a consultant that has expertise in both developing automation scripts and building an automation capability. This saves time and effort as they work with you to map out your business functions by the department and identify readily automatable processes within each department or business function.
This approach will also provide a roadmap around your automation goals, as well as an opportunity to develop an automation center of excellence (CoE) focused on ensuring the development of best practices. Furthermore, it takes the pressure off creating an RPA development team in-house in the early stages. If an in-house development team is your ultimate goal, many consulting companies will help you build your own team and smoothly hand off the maintenance of existing scripts and your automation roadmap.
Finally, if your business team is still excited by the idea of participating in your automation program, a great approach to leveraging both skill sets effectively is to encourage them to crowdsource automation ideas as they encounter pains in their everyday operations. With “citizen edition” RPA platforms, they can also try their hand at automating their task themselves as proof of concept.
If proven to be a viable candidate for your automation program, the process and script would eventually be handed off to your RPA development team to build it with production standards in mind. This way, you get the best of both worlds: your business team can try their hand at citizen development in a manner that both empowers them and your broader automation program, with minimal risk.
Learn More
Check out our Executive Guide to Automation, or schedule a short call today to learn how easy it can be to set up your automation program with the right partner and start seeing powerful results in as early as 6 months.