Introduction

My name is Jim Frost, and over the next several blog posts, I will be highlighting areas you need to consider when building your automation team for long-term growth and scalability, beginning with the foundational work, moving through the short-to-medium term growing pains, and finally scaling your team across your entire organization.

Over my 40-year career, I’ve been a part and led teams of various sizes and complexity. I’ve led very small teams in a technical start-up firm, as well as large teams that spanned multiple business areas across several continents. While all were different, they shared some of the same needs. Keeping these top-of-mind is critical:

• Good cultural alignment across the team 
• Defined roles and responsibilities for every team member 
• Clear expectations in all things 
• Clear vision of where the team is heading and potential career paths for individuals 
• Clear, open, and honest communication 

In an automation program, people are the most important asset, as mentioned by the Pathfinder Community Team in the article on roles within automation found here. Failing to address the areas above can result in higher employee turnover, lower employee satisfaction, and lower overall ROI.

In my current role, when creating automation programs from scratch, we spend a good amount of time discussing these areas and we continue to re-engage the topics on a regular basis. This is not a one-and-done activity. It is very important that you continue to think about these things while managing and growing your automation program.

So where to start?

You begin by building your program’s foundation.
 
Throughout my career, I’ve seen teams that are very successful, as well as others that tended to be a bit of a mess. The better teams all were built upon a solid foundation and had a clear path to success, while the others tended to be much less organized, had unclear motivations, and experienced frequent finger-pointing and delays.
 
Before you can create your team, you need to make sure you have a clear focus on what the team will need to do and the type of team you will create. Here are a few examples of the questions you need to ask yourself before creating your team blueprint:

• Does your organization have a documented strategy? 
• Does your organization have an innovation and/or experimentation mindset? 
• Do your business units operate mostly independently, or do they share some services, such as research, software development, or project management? 
• Does your organization run projects using an agile mindset? 

Based on how you have structured your organization and business operating model, your team will need to be created differently to augment and support the organization. I’ve seen many different models, and they all have various pieces that make them work for their respective organizations. 

Here are two notable ones: 

Company A: Centralized CoE Model, Citizen and Professional Developers, Open to Innovation
 

This firm was accustomed to the shared services concept, and they were not afraid to experiment. They initially staffed their CoE team with 1 business analyst and 1 professional developer.
 
The business analyst was charged with working with the business unit SMEs for process discovery, and helping guide the SMEs into the Citizen Developer roles through training provided by their platform provider. Additionally, the business analyst was expected to grow into the CoE lead over time.
 
This firm felt that connecting the SMEs directly to the BA was the best setup. They would go over possible projects and refine process documentation as needed. The SME would then take over the initial development of their bots and the BA would finalize the process documentation, design documents, and test plans.
 
The professional developer would oversee the final error and exception handling and work with the team to push it into production status.
 
This approach was also selected to show the entire organization several points. First, it was easy to demonstrate the impact of the program from an SME viewpoint. Second, it showed how the firm was open to allowing citizen development and advancing their employee careers. Lastly, it proved that there was enough governance and control via a professional developer handling the final stage of going live to alleviate any concerns of “the bot going rogue”.

Company B: Outsourced CoE, Internal Program Manager, Relatively Conservative

This firm was slightly more old-school. They knew they wanted to adopt automation but felt more comfortable having external personnel acting as their developers. They wanted confirmed ROI from a time savings perspective and wanted to tightly control the automation ideation, development approval, and acceptance process.
 
They worked with their hired consulting firm in a well-defined manner. Their internal program manager performed process discovery internally, beginning with known pain points and high overhead departments. The program manager would then set up process assessment meetings with the consulting firm and together they would establish an estimated LOE and investment payback period. The program sponsor (a high-level executive) was the single point for all go/no-go decisions. 
This firm had several defined rules/guidelines and objectives they wanted to achieve with their automation program. They did not feel comfortable allowing experimentation as they felt the teams did not have the necessary skills nor the appropriate big picture view to select and deploy the most appropriate automations.
 
The plan was to show the organization how automation could assist in their day-to-day lives and slowly build a portfolio of automations that saved very meaningful time across the most overloaded departments.  Eventually, they did plan to deploy more “quality of life” automations, as well as allow certain teams to upskill and perform higher value work, but certainly wanted to achieve the time savings first and foremost.
 
How these two very different teams moved on through the growing and scaling phases will be discussed in the next blog post. For now, here is a guide to start you on your way to building a solid automation team foundation.

*Downloadable version attached to article below - click to enlarge

I hope you found this post interesting and helpful - reply and share your feedback/experiences.

Keep an eye out for my next post coming soon. I’ll be covering how to approach growing your team, the pains and challenges you may face, and how to mitigate them as best as possible.

Jim Frost, an Automation Anywhere Most Valuable Pathfinder, is currently a Lead Engagement Partner at R-Path Automation.