This post completes a series of 3 blog posts. Now you’re ready to hire the right RPA team, congratulations!
In case you missed the past 2 lectures, this is your chance:
A common feature of most successful RPA projects is the fact that organizations treated the process automation initiative as a joint venture between business and IT departments. Unlike traditional Process automation projects, RPA empowers the business to drive their automations and reduces the dependency on IT.
But while bridging business units that have traditionally different circles of action is exciting for organizations, it does come with some language difficulties that commonly reduce speed of implementations.
In this article we argue that, just like science communication (which can be defined as the “public communication of science-related topics to non-experts.”) is a highly sought-after skill in academia, your RPA team should also have people who master the art of translating technical challenges and obstacles into concrete action points for non-technical stakeholders involved in the project.
Low-code is still technical at times
One of the great achievements of the low code space (where RPA is included) is the fact that “coding” became less technical, stripped out of programming jargon and in many cases converted into a drag and drop activity. Yet, most large RPA projects are still characterized by a high number of support tickets and endless mail chains with requirement clarifications. (Question: who reads e-mails with more than 5 sentences?).
In these moments, having people in charge of the translation of technical obstacles is key since this can avoid long feedback loops and effectively move the implementation forward. While we have seen this role being performed by different RPA stakeholders (e.g. Technical Lead, Environment Manager) having developers capable of performing this role should be something every organization should aim for. So which principles should be taken in account to make your Technical communication as smooth as possible? Here are a few ideas:
- Less Is More: The Minimum Effective Dose (MED) of Information – It is tempting to provide the whole backstage context of the technical obstacle at hand, yet we have found that most times a lot of information does not really translate into obstacles being solved faster, on the contrary. Developers should aim at providing the minimum level of information (the MED) that allows a point to be resolved. Or in the words of Leonardo da Vinci – “simplicity is the ultimate sophistication”.
- The Golden Rule – a key rule of technical communication is to put ourselves in the shoes of the receiving end. Always ask yourself, would I understand all these technical terms before I started working in RPA? If the answer is: “not really” then rephrase.
- Eliminate the Technical Jargon – No more “PDDs”, “UATs” and “Release Management”. Understand that your audience probably has not been exposed to all these software development terms and relying on them makes communication more difficult.
In sum, you should place some effort in assessing the communication effectiveness of your RPA team since your change management workstream will be significantly eased with these capabilities.
One skill to look for!
With more and more organizations building their internal Robotic Process Automation teams, the ability to select candidates that will pro-actively move the project forward despite the many obstacles facing RPA teams becomes an imperative for success. Yet, while most interview processes are designed to confirm the technical background of the candidates they rarely check communication skills of the developers.
This statement is surely going to raise a few eyebrows. After all, isn’t communication checked during the whole interview process? Communication is a big word and you surely need a developer that can interact with the operations. Yet, the specific skill you should be looking for is the ability to convert a technical obstacle into an actionable support ticket.
Whether you are a manager, a developer or part of a support team you have certainly experienced the consequence of bad support tickets. Just think back at those huge mail chains involving different support teams. Chains that generally lack ownership and only move forward after some escalation.
Very often these chains damage the ways of collaboration of your internal teams which are so essential for the success of your RPA implementation. Our view, after many RPA implementations, is that a great deal of these back and forth could be avoided by having a stronger technical communication when raising issues. This is a hard skill to have and to learn but incredibly important to have in your RPA team.
If you agree with use you won’t be leaving empty handed. In the next bonus section, we’ve prepared a set of questions for you to use on your next interview process. These questions aim at testing the ability to explain technical problems in a non-technical way.