Speaking recently to a large RPA consulting company director, one of the main fears of any manager in our sector came up: talent retention.
He recognized his difficulties in attracting good technologists to RPA projects, “and when I get the right team at the right efficiency level, the most talented decide to leave. I manage to keep them for an average of nine months”.
A quick reflection could make us think the reason is the exponential growth of the RPA market in the last years, which has generated imbalances between candidates supply and demand, causing higher turnover rates. But this is not the only reason.
From a deeper analysis we get in a very different conclusion: a vast majority of RPA tools are not able to offer any challenge, or simply certain intellectual incentive, to high level technical profiles. These qualified technicians, or those who aim to become ones someday, are not attracted by using a recorder or painting a box – known as Low-Code approaches – nor are interested in learning technologies or proprietary development environments only applicable in certain type of projects. They end up detesting not having control, not having visibility on what is behind those boxes, which is at least a code written in a certain language, but a hidden code not generated by them, which they will never access and from which they won’t learn anything.
Once identified the problem, how to solve it?
Again, a simplistic approach makes us find a quick answer: let’s get business people to develop the robots, profiles without technical aspirations who won’t feel frustrated for not having an experienced programmer career. The reverse situation then occurs: great functional talent profiles feel they are expending their time as programmers, and they did not study a business administration career or even paid a really expensive MBA to devote themselves to software building, a goal far away from their real professional ambition of becoming analysts, consultants or managers.
That’s how the paradox generates: talented analysts do not want to “program” robots and talented programmers flee from “configuring” robots.
How solve this mess? We may be tempted to use a usual solution in another IT contexts such as outsourcing: assigning resources of little experience, whether technological or not, to robots’ configuration/programming. Let’s even use interns, a group that doesn’t complain and has little chance for leaving the company. After all, do not most RPA manufacturers claim that any user can make his own robots?
But how this resources policy will impact on final automation solutions quality, sooner or later?
In Juan Manuel Reina’s words, Jidoka CTO, business partner and good friend, “robots are not smart”. People who design and program robots are smart. There’s where we should look for intelligence. And talent.
Fortunately, neither our clients nor our partners participate on this disjunctive. At Jidoka we have been defending for years there is no reason to forget our sector best practice’s in RPA field (software technology by definition).
These best practices show us there are two critical roles, and therefore two different and complementary resources who should collaborate in the software robot construction:
- One functional analyst for designing visually the workflow in the Jidoka console.
- One programmer for building the robot using the Jidoka SDK.
A common collaboration environment, where both profiles can fully focus on their interests, finding the necessary field to develop their skills and, even more, their professional career.
Jidoka programmers use the entire Java standard ecosystem for robots construction – so it is potentially a nine-million programmers global community – based on such well-known tools as Maven or Nexus, or what is more important, using an IDE with which they are already familiar: they won’t need to learn a new development environment, they can use Eclipse or Netbeans (or any other editor). With the additional advantage of having access to thousands of the Java community existing libraries.
Finally, they get relevant experience as specialized programmers, both because of acquiring the RPA vision and for the Java 8 full power use (for example lambdas), qualifying their curriculum vitae in a decisive way.
On the other hand, our analysts find in the Jidoka platform a powerful visual tool that allows them to design business processes workflow in a simple and intuitive way.
Is not only the tool: the Jidoka platform follows a “top-down” philosophy for building robots, starting with processes flow design and descending to tasks execution, thus simplifying enormously the analysts function and granting them an essential role in this first part of the process. Both this philosophy as the tool simplicity, plus the collaboration formula – which avoids the need of “touching” the code – keep their motivation high, by allowing them to focus on their knowledge area and acquiring RPA experience, one of the most disruptive new digital economy technological trends. Again, an attractive curriculum vitae specialization.
Conclusion: a cohesive and motivated team we hope will advance with us throughout their professional career.