I’ve been thinking about my colleague Maurice Dubey’s blog on the ‘poisoned chalice’ that was Microsoft Access in the early 1990s. As Maurice points out, Access was a great tool, but its effectiveness was hampered by cowboys and novices picking up the tech and running it carelessly into short-term and short-sighted fixes that the rest of us spent many years cleaning up.

Robotic process automation (RPA) is about investing upfront in the people and the learning so that they can nurture the platform and keep it adapting successfully. After reading Maurice’s blog, I thought it would be useful to look back on some of the thoughts I’ve shared on our RPA trading and conversation hub the RPA Marketplace, and revisit what makes a good RPA developer – particularly with Blue Prism.

The setup:

Blue Prism’s advances in connected technologies and integrations with various AI and other such platforms has made it a favourite in the enterprise and large organisations. As a ‘code-free’ development tool, you can develop processes in a flowchart-like interface by dragging application actions and business decisions onto a page and linking them up. That’s the marketing hype. Easy, right? If it’s so easy, does that mean anyone can use it?

The question I get asked all the time is ‘who can be a Blue Prism developer?’ The more relevant and revealing question, however, is ‘what makes a great Blue Prism developer?’

Tech salespeople, non-technical BAs, hardcore programmers – I’ve seen people from plenty of different backgrounds attempt Blue Prism development to varying levels of success. I believe the result is dependent on the person, their history, their attitude, and the quality of the systems and procedures you put around them.

The background:

It’s true: given a week of training, anyone can technically develop in Blue Prism. The fundamental concepts are simple, and the flowchart-like system is easy to understand. If you want to read data from a spreadsheet and enter it into a Windows application and press a few buttons, then yes, pretty much anyone can do that.

Business processes aren’t that simple though. They’ll have complex variations with many factors that can affect the implementation, including:

  • Many ‘happy’ path variations and exceptions (‘happy’ meaning the typical path or output for any given process)
  • The business not understanding or in agreement on what the current manual process is
  • SMEs reluctant to change
  • The process touching a lot of applications and systems
  • Applications that often fail or don’t behave consistently
  • Internal business politics 
  • Permissions and security to negotiate
  • Ever-changing requirements and requests for changes from the business
  • Internal robotic team / organisational politics
  • Interaction from IT teams used to typical software development
  • Lack of end-to-end testing data or test/development systems

It’s not software development; it’s training a digital workforce

Welcome to the life of a Blue Prism developer. It’s not traditional IT or software development; it’s training robotic users. It takes real skill and experience to prepare a human workforce and likewise, it requires a similar level of expertise to train and equip the emerging digital one.

Developers need to step out of the development box – you know the one where you feed in bananas and code spits out – and into the complexities of life working directly in business units.

It can be hard, challenging, and complex, but when you get it right, the rewards of a well-trained digital workforce are significant to an organisation of any size.

Getting it right ultimately comes down to choosing the right set of people and surrounding them with the structure and operating model they need to succeed (more on the other part of this equation in future Q4 blogs)


So who makes the best developers?  

Experienced senior developers with a proven track record typically make the best Blue Prism developers. It’s as simple as that. While Blue Prism is code-free, all the standard development constructs still apply:

  • Thinking logically and can troubleshoot quickly
  • Knowing how to architect solutions
  • Having proper testing procedures and practices
  • Taking ownership and being proud of solutions
  • Building and maintaining relationships
  • Spotting issues before they happen
  • Knowing what is essential and what isn’t, i.e. focusing on the right problems
  • Understanding the importance of code control and code reuse
  • Understanding that in order to speed up, you have to slow down and do the analysis correctly
  • Looking at the long term view, especially long term support and scale
  • Be willing to learn continually.

The reality

That’s what experienced developers do. But the reality is you will never have a full team like this. Even the best delivery vendors houses struggle to find and keep these people. I recommend focusing on recruiting a core set of seniors then filling the rest of your team with bright juniors and novices. Surround them all with the right systems and processes to allow the juniors to learn and upskill and your capability to scale and not be burdened with technical debt and bad technical decisions.

These systems and processes include:

  • Strong governance and pipeline management practices
  • Giving your seniors time to code review and mentor
  • Start small and slow, gather momentum rather than forcing it
  • Have strong unit testing strategies
  • Have a clear and well-followed delivery methodology
  • Focus on quality, standards and object reuse
  • Remember documentation

So who makes the best junior/novice developer? 

Well, this is where it starts to open up. These are the key attributes I believe make an excellent junior to mid-level developer:

  • They are logical thinkers and like to understand how things work
  • They are technically-savvy, curious and have had exposure to many different technologies and applications
  • They take ownership and responsibility in what they do
  • They are willing to speak up in group situations
  • They like dealing with people
  • They know what it’s like working within business units and can establish and maintain relationships
  • They have a high attention to detail
  • They are open to advice and willing to learn

Like most things, behind-the-scenes of RPA, there isn’t a simple answer to who makes the best developer. We work and live in the complex business environment with a burgeoning technology and comparatively low levels of industry knowledge. Complexity is currently the hallmark of RPA.

Q4 specialises in helping organisations through this complexity, so drop me a line if you want to know more on this subject. For instance, a good place to start is understanding the best approach and tools to audition experienced or novice RPA developers. (Yes, think audition, not interview)