Your Operating Model Cannot Support Automation and AI
According to a survey conducted by Deloitte with 523 executives across many different industries, fifty-eight percent reported that they have started their automation and AI journey. Robotic Process Automation, Machine Learning, Chat-bots, and countless other technologies are driving adoption of automation and are helping companies transform processes across their enterprise to become more efficient and to drive true Digital Transformation. While this sounds like we are building next generation companies and workforce's, most companies will barely be able to get these efforts off the ground due to one big glaring issue: The way most companies operate will not support automation.
I’m going to be using some terms that you may not be fully familiar or versed with. I’ve provided handy links to help you get up to speed
Your organizations design is problem #1
It used to be common practice for companies to build large bulky applications with single code bases. An update to one part of your application (can) require the entire team to agree and sign off on the update or fix with thorough integration and UAT testing. This moved many companies to adopt SDLC to provide a structured process to going through this type of development, testing, and sign off for providing “functionality”. The side effect of developing bulky applications using SDLC, in combination with this classic “waterfall” methodology, changes the way organizations are designed and how they operate for all process. This ends up having a detrimental effect to organization’s ability to quickly release features and develop with newer technologies even when they claim they are using “Agile” principles. If your organization has IT governance that makes it difficult for developers to release to production, your applications releases will become larger and more complicated. If your organization follows an agile methodology with continuous delivery, releases become more simple and easier to test. This follows the principal known as Conway’s Law.
Conway’s law, or similarly the mirroring hypothesis, states that organizations will create software that mirror their organizational structure. So if your organization built a bulky IT Governance process that includes dreaded Change Advisory Boards and mountains of approvals to release simple features, your software will also be bulky, slow to adapt and change, and have a code base that is likely larger and more complicated. The primary thing driving bulky releases and software is that the overhead of deploying is so great, developers want to squeeze as much as they can into a release. Leaders in these organizations often have grown up using SDLC, ITIL, or ISO standards and think that this is how organizations should be effectively managed. I believe this to be categorically false. Technology advances too quickly to have a single governance process for all technology. More importantly, any structured methodology or process should be uniquely tailored to your organization. Older organizations either have a hard time adapting new technologies or don’t adapt at all because they require these new technologies to fit into their organizational mold. Looking at newer companies who have developed adaptable and streamlined operating models can help shed some light on why the traditional governance models no longer can work in the future.
The Rise of The Independent Team
Spotify takes a non-traditional approach to product engineering and organizational design. The foundation of their design is built upon what they call Squads. A squad is autonomous, self-organizing and self-managing team of no more than 12 people. Multiple Squads are grouped together into Tribes. Tribes and Squads are built on a foundation of autonomy and trust. Tribes are trusted to make the right decisions which means they must take accountability and ownership of everything they do to ensure it’s a success. Some of the benefits are as follows:
· Enhanced velocity
· Processes are reduced to a minimum
· Addresses short term challenges
· Minimized dependencies
· Lack of a firm structure makes problem solving easier
The key things to call out here are the reduced process and lack of firm structure. Traditional organization design often takes complete decision-making power away. If your team is responsible for an application or feature, you must pass all the IT stage gates in order to deploy. In the Spotify model, your tribe can deploy 100 times a day without ever letting another tribe know what was happening. This federated model allows every single team to be completely effective without the organization itself causing delays in the name of process and governance. The power of small, independent teams is necessary to remain competitive and to effectively employ newer technologies.
Building an operating model for independent teams
The Spotify model works for Spotify, but it doesn’t mean it would work for your company. As I stated previously, any structured methodology needs to be uniquely tailored to your organization. Creating team structures that have the capability to provide quick value to the organization is what’s required for this to work. Independent teams give a new capability the full decision-making power and autonomy to make the right decisions. They aren’t letting someone else who doesn’t understand the technology or strategy dictate how deployments happen or how things are prioritized. At the end of the day, automation benefits the customer and you want a direct path from your automation team to the customer.
In the example to the left (this is representative so don’t take it too seriously), if we are working at a healthcare company and we want to automate how quickly medical records can be turned around to patients, the traditional approach would be through laborious IT governance depicted in the blue. Every single box takes on its own responsibility, and stage gate, because each part of the organization does not trust another. This lack of trust leads to very expensive timelines for projects. The difference in timeline for a simple RPA project between the two could be a difference of 4–8 weeks or more depending on the organization. But why is this?
In the traditional organization design, there are strong disconnects between an automation team and the rest of the organization. The rest of the organization will require unnecessary testing, validating, process, and meetings so they can understand the entire solution. I rarely see any value or risk aversion from anything an organization does in the traditional approach. In fact, all it does is implement risk to the project and adds cost. My perspective only applies to onshore teams, however. As I have previously written, offshore and automation should never co-exist.
A brief example using Robotic Process Automation
As we learned, Squads are built around velocity. An independent automation team should be too. So, if you are building an RPA team, the first thing to understand is how development is different from writing code. We are automating over existing applications. We write self-contained “scripts” that take action for a specific process. It’s completely siloed from the underlying applications and with RPA you only need a non-production and production environment. Adding a third environment increases the complexity of deployments and adds zero value in testing. The other key thing to understand is UI automation only works when the underlying applications’ QA and Prod environments are identical. At the very core these may seem like small differences, but they are huge when you have a dedicated operating model that lets you use the technology as intended. Removing all the “middle management” layers of the operating model lets the team make the best decisions and prove value. The executive steering committee provides oversight and accountability. So how do you go about creating your own independent automation team with its own operating model?
Key themes to a successful automation team and operating model
The most important thing about designing an independent automation team’s operating model; you need an executive steering committee with at least one C-Level executive. Traditionally, automation is often championed by either the CIO or CFO (or both). One of these executives provides a very powerful role, mediation between other lower executives. Automation is new, scary, and challenges the norms of every organization. Everyone will not always agree. Success hinges on having a strong and engaged executive with authority to make final decisions. The next item to address is where in the organization does this team belong?
Key Takeaway: Create a steering committee with a C Level Executive
Automation teams can and should belong anywhere, except IT. Automation belongs in the business. Remember what I said about the IT operating model and governance being the bane of automation's existence? Putting this function in IT will do nothing but get sucked up into it. Keep automation on the business side and create a cost center dedicated to the Automation program. You want the team fully funded to be able to go out and find automation opportunities that are going to provide the business the most value. The minute you start getting into charge backs and other sorts of funding nightmares you will suddenly find that you’re a year into your automation effort and have saved next to nothing. You don’t want to give anyone any reason to not want to do automation.
Key Takeaway: Create your independent enterprise wide team anywhere in the business with its own cost center and funding to accelerate the automation effort
The last key point to make about automation. It doesn’t matter if you are creating automation's with Machine Learning, Chat-bots, or Robotic Process Automation. These are experiments, not your traditional application build efforts. We start with a hypothesis of what our outcome should be, and we work towards that outcome in an extremely iterative and agile way. People can argue all day that you can document all requirements, build, test, deploy, and be done (Waterfall). These people have very little experience deploying automation at scale or understand how to create automation's with true velocity. Work towards your hypothesis of what is supposed to be the outcome and figure it out along the way. This is the iterative and agile approach automation should take, always. Deploy early, often, and with purpose. But how do we prioritize which automation's we go after?
Prioritizing automation opportunities is probably the most problematic part of automation today. Every business wants to derive value from automation when they are “trying” it out. So, what do they do? They select the most complicated use case with the most payback. This is where companies are failing the most. Gall’s Law states that complex systems that actually work were always evolved from a simple system that works. Invariably, a complex system designed from scratch never works and cannot be made to work. This is something very powerful to understand as part of your automation journey. If you are just starting a capability, you have no “complex” system in place in terms of your team. Your teams operating model isn’t defined and the organization itself doesn’t understand automation. This means you must start simple with use cases that are easy and well defined. You do this until you have a solid operating cadence for your team and then you move onto more advanced use cases. The second aspect of complicated use cases is properly phasing them out. We want to break a complicated use case into smaller, digestible, chunks where we can begin deriving value within a short period after development starts. With each phase more value is derived until the solution is now comprised of that complex system.
Key Takeaway: Use your hypothesis of the automation outcome to drive an extremely iterative and agile development methodology. Always start with simple use cases with new teams, even if you are using experienced consultants. Always break out complicated use cases into more digestible components to piece together many simple systems into one complex system that works.
Conclusion and final thoughts
There are a lot of things that you can derive from this article. The first is that automation is truly an enterprise wide effort to drive value for the business and the customer. In order to reach this goal, you must create an independent automation team with its own executive steering committee and operating model so value can be realized faster, cheaper, and with purpose. In order to make this team effective, you want a dedicated cost center with its own funding. In order to be successful, new teams should always start with simple use cases before moving to more complex use cases. And when more complex use cases are started, they should always be broken out into more simple automation's since complex systems are never one unit, they are comprised of many smaller units and iterations. Regardless of your industry vertical, this will work for any company. If you think it won’t work, I’d be thrilled to show you how it will, so let’s start a meaningful dialog.
