Learn the basics of Robotic Process Automation (RPA) recruiting


Throughout last year I was approached 119 times (yes, I counted) by recruiters who said essentially: “I saw your profile and it perfectly matches our client’s/or our RPA need.”

Out of those 119 contacts, the majority were outside of Poland (where I live, and I’m absolutely not willing to leave), temporary contracts and — I found after a few discussions – Blue Prism Developer positions. Although my profile clearly expresses my high desire to continue my focus on RPA strategy and run general automation programs, and even when I added the note, “I’m not interested in becoming a Blue Prism developer,” emails were still coming in. I am, of course, relying heavily on my own experiences here but I expect that many others in RPA have been similarly frustrated with recruiting inquiries. It was just one word in my resumé that made recruiters insanely interested – RPA. One time I decided to call one of the recruiters who pinged me and ask: “You saw my profile end to end, you know my preferences where it comes to career, why did you reach out to propose a Blue Prism developer position to me?”

He responded: “You have RPA in your profile, hence I thought that an RPA developer position would be interesting for you.”

That day I decided to write this blog and maybe have some sort of 1-on-1 (or hopefully, 1-on-many) with the recruiters and overall audience on how I see it from the other side of the fence – as the RPA guy on LinkedIn with 10+ years of experience in this field.

RPA roles: No longer a one-string banjo

Although RPA started as a natural evolution of often one-person positions generating efficiency, optimizing processes and eliminating process waste, after a few years there is no longer a one-string banjo encompassing all aspects of robotics process automation under one person’s address.

It is almost like treating an F&A accounts payable specialist as a perfect candidate for all positions labeled F&A. Can you imagine an entry-level AP customer relationship center person being perceived as a perfect candidate for an F&A Managing Director position? No, this would never fly, and a similar approach is kind of enforced currently by recruitment staff that is not properly informed or not yet experienced, and has only very generic information about RPA.

The range of RPA roles

To help clarify the RPA world as it is today, let me explain some basic roles:

  • The main role of RPA developers is to create robots. Developers work on a company-selected RPA platform (a process in which they do not participate) and develop or code the robot to follow some rules and get the job done. The majority of the software is easy enough to allow someone to become a specialist in a few weeks of extensive training if that person is tech savvy. Training can take up to a few months, but only if the robots require some additional features to be coded in .NET, C# or Java. I would consider those RPA delivery areas “rookie friendly,” as you don’t need amazing skills or experience to become good at them. I see LinkedIn filled with sole-named “RPA specialists” who actually graduated from 10-hour webinars and call themselves experts or even masters of the RPA craft. Truth be told – the majority of those people know one RPA platform and are able to bring value in the robot supply chain only to one aspect of RPA – coding robots. Please don`t get confused. You may wonder, “But isn’t creating a robot the essence of RPA?” Honestly speaking, and paraphrasing this a bit – the engine of the car is important, but it will not drive without the rest of the car. Same goes here.
  • The next position essential to RPA is usually called RPA solution architect. I personally have big respect for those people, as they are not “rookies” by any means. To become good at this job you need to have experience in many areas of RPA as a field of service and the ability to understand the automation process (process assessments, data mining), suggest the proper technology (which will enable positive a ROI), assess development timelines and build a 360-degree Business Requirement Document (BRD) for a job that creates the basic idea of the solution and the logic to drive an outcome that meets the client’s expectation. This position demands a lot of experience — at least six years.
  • The last most commonly appearing role is RPA analyst. This person is responsible for verifying the pre- and post- automation situation to prove that the automation worked and brought the expected results. These people should be able to treat Excel/ClickView as their bread and butter for graphs, analysis and comparisons. Does the analyst position require a “special instinct” or extensive knowledge around RPA? No. It can be a person with two to three years of experience in PMO/KPI areas.

Depending on the scale of the RPA practice, there are also RPA positions like practice lead, manager, vendor lead, support lead, strategist aka evangelist/manager of change (MOC) and IT support. In many setups I’ve known, those functions are combined under one person. Some of those roles can fit in the organization “horizontally” (as an individual contributor); others need a “vertical” or managerial position.  Let me share few details on each of them:

  • RPA practice lead for me is a visionary who handles the promise (deliverables) and the money (budget). These leads need to be aggressive, but smooth, around commitments they put on the table. Transferring it to more recruitment language – we are talking about a junior director or experienced director-level person with charisma, a really good handle on all RPA areas and at least 10 to15 years of experience.
  • RPA manager is normally a line manager for RPA people to report to. He/she needs to understand RPA well but mainly be able to productively manage people’s time and effort, make the connections between different RPA towers and stay on top of KPIs so they stay green. It can be just an average, open-minded line manager with five-plus years of experience. Nothing more, nothing less.
  • RPA vendor lead is a person who handles relationships with RPA vendors, analyzes the cost of licenses, negotiates the rates and verifies which financial model will be most efficient. This position is usually held by an RPA manager or RPA practice lead.
  • RPA support lead is a person who handles the ticketing system and the engineers who can step in 24/7 and fix the robots if they break. They also handle change requests. This position does not require much of a handle on RPA nor extensive management experience. For me it is a person with two to three years of experience who can work quite fast.
  • There is also an RPA IT support team/people who are normally part of the IT organization (not the business, which usually leads RPA efforts). They are your hardware buddies who organize servers, VDIs, access, cloud, BCP plans, IT scalability, networking, etc. They are normally well-trained engineers who understand RPA well enough to be good at how they support the practice. I would give this position three to five years of experience.
  • That leaves the last one – RPA strategist/evangelist/MOC lead. I left it for last as this is the closest to my current role and I have quite wide-ranging knowledge around how this person operates. To be successful at RPA inside any type of organization, you need to create awareness, build automation culture, broadcast properly the changes that automation brings, have a sixth sense for complex MOC, be able to promote internally and externally what RPA is for the company, know progress and changes in the market and technologies. This person is a single “know-it-all” who is able to act as a day-to-day consultant for the RPA practice lead on how to make the ship move quicker, stay stable and drive to a clear outcome. I see that person as a senior, visionary analyst and an out-of-the-box innovator who needs to be able to understand the big picture and prepare all layers of the organization to understand RPA properly from their tighter perspective. In recruitment language – highly experienced (10 years +) and a true-boned talent to drive engagement and consistency in the strategic operational aspect of RPA.

Rising landscape of RPA roles

With the strong growth of automation and robotization, the landscape of roles and specializations within the generic “RPA branch” will also rise exponentially — and really fast. Imagine that we have barely scratched the surface. The RPA-connected impact of pattern recognition, machine learning, chatbots, natural language processing (NLP), dark data usage, process mining, human-in-the-loop AI, big data for robotics and blockchain will all make this whole ecosystem of roles become much more detail-specific and generate new, highly specialized roles.

The only thing that matters now is for recruiters is to be aware of a company’s overall vision and automation scale, and be properly instructed by the strategy/senior staff on what skills and experience is required for each one of the new specialists they’re searching for.

Exciting times isn’t it?


  1. Deepak Suryavanshi says:

    Thanks..I am a conscientious victim of the same confusion. I get a it of calls from recruiters and they are very much confused with Roles in RPA field. My role is RPA support lead but they always get this confused with Developer.

  2. “There is also an RPA IT support team/people who are normally part of the IT organization (not the business, which usually leads RPA efforts).” – I’m very glad that you make this point and thereby bring up what many perceive as the rivalry between business and IT departments when it comes to automation.

    Throughout 2018, we could notice the development of a “minimalist” trend, where much effort was invested in simplifying the use of software robots, so that business teams themselves can track the automated processes more easily. To this end, RPA vendors have started to provide bots with built-in monitoring tools.

    However, I think it’s most important to recognize this as autonomy of the business from the IT team, and not as independence. The intended meaning is rather that of working together in the attempt to attain shared objectives, or collaboration according to a wise division of labour. I expect aspects such as cyber security or data availability to remain the territory of chief information officers.

  3. Yogesh Chauhan says:

    Can someone apply for RPA Blueprism who has two years of experience in Blueprism only .

Speak Your Mind


This site uses Akismet to reduce spam. Learn how your comment data is processed.