By Raonak Ahmad, Chief Revenue Officer, Predii
How do you structure your teams for innovation?
There’s a classic business case regarding a building in New York where the residents complained that the elevators were too slow. They had to wait several minutes to get in one, and once it was there, it took too long to reach their desired floor. A feasibility study explored several options – could they skip certain floors? Could they increase the speed of the motors? Both options would require large engineering investments, which were deemed out of reach. Tenants were moving out and management was panicking.
Then a new hire spoke up. What if we just put mirrors in the lobbies and the elevator cars? The problem wasn’t elevator speed, it was resident boredom. Let them adjust their hair and tweak their ties and they’ll stop thinking about how long it’s taking. Management installed mirrors and the complaints stopped.
AI initiatives and digital transformations often find themselves in situations like this elevator story.
The primary problem or objective that the project was put together to address might be a completely different obstacle than what takes priority half-way through, and by the end of the project the stakeholders involved might be entirely rethinking the problem statement from the ground up. Real value has proven elusive, and the technology investment isn’t paying off.
This is especially true today, when everyone and everything is becoming (or attempting to become) data-driven, and when AI becomes a strategic priority before tactical implications and implementations are fully understood.
The board asks the strategy team to boil the ocean. A number of projects kick off around a transformation journey, but the day to day, moment to moment work effort scenario didn’t receive full diligence. Like mirrors in elevators, no one actually thought about how the business process should transform, prior to kick-off – thinking instead has been spent on the technology by itself, without thinking about the full process change or the psychological change management necessary to modify human behavior to fully leverage the new tech.
Six months to a year later, the CEO is wondering why their AI investments are under water.
How do you avoid this?
Rethinking AI-powered Teams
There are two key ways to build success into a AI transformation:
Don’t Use AI to Fire People
Operationalize Your Data Scientists
Don’t Use AI to Fire People
Modern global enterprises are comprised of endless hierarchical stacks of personal fiefdoms – everyone carves out their space, and the more people you have reporting to you, the higher your star rises. When confronted with poorly orchestrated AI and automation, personal ambitions, responsibilities and relationships chip away at project buy-in until what looked good on paper fails to live up to its promise.
A classic example is the call center. You might have a call center that is thinking about bringing in a speech bot to intercept the customer on the phone. In fact, the people thinking about this technology have done the analysis to see that 30% of their calls can be handled by the bot.
But then you have call center managers who know that going through with this means letting employees go, as you no longer need as many people. There is massive resistance to change at the operational unit level. It’s not the workers who are scared, it’s the managers and leaders who are afraid they are going to lose their empire.
This is shortsightedness in vision – by both the call center leadership and the transformation committee.
Instead of thinking 30% automation means you can lose 30% of your staff, the entire enterprise should be thinking: how much more service value can we deliver with 30% more free time for my employees?
This kind of thinking is frequently not baked into the strategic vision put together by the transformation stakeholders, and in fact they find it difficult to picture what that 30% more service value would look like – they are too far removed from the day-to-day pain points and limitations of call center employees to have a clear understanding of what more could be done. Every employee has an “If I could only X…” daydream: the challenge is bringing it out into the open. Which brings us to point #2.
Operationalize Your Data Scientists
A data science team or external partner can provide incredible value if they are correctly plugged into the essence of the company. They can provide these “If I could only X…” solutions, but they frequently do not know the problems exist, do not understand enough about the problem to render a proper solution, do not have the internal leverage or access to make something happen, or simply do not comprehend the scope of the value to be created by solving for X.
There are certain small measures that can be taken to address this. One example is a hackathon. You rarely get something immediately useful from a hackathon – wireframes or MVPs created in a day are rarely taken to the real world – but there is value in getting cross functional stakeholders to listen to challenges and think directly. However, we have found that non-technical subject matter experts are intimidated by the idea of hackathons.
What really works is mixing the oil and water in the day to day functions and responsibilities, designing your product teams to include a data scientist as a consultant all the way from ideation to execution – not just the parts where it seems data might be involved. What we have seen work is a three-persona set up.
The first persona is a strategic stakeholder who has a vision that there is value. They don’t exactly know what the value is, yet, but they are sure it’s there. They are also limited in their ability to extract the value themselves. These people are crucial because they are the ones that believe and promote.
Subject Matter Expert:
The second persona are do-ers, employees that are deeply consumed by the intricacies of the problems they face on a day to day basis. They understand these problems, but frequently do not have access to the kind of abstraction necessary to see a game-changing solution.
The third persona are data scientists. Data scientists like having crisp problems to solve. They like having the intricate problems and the abstracted solution crisply defined in terms of inputs and outputs, and frequently they expect this to come from someone else. Frequently the last thing a data scientist wants to do is have to go to someone.
All three personas are necessary. One of the key problems faced when trying to get data and product to mix is that each side speaks in its own language. In repair and maintenance, subject matter experts speak in terms of symptoms, failures, and resolutions. They’ll say that they want to know what are the common problems faced by Chevy Silverados, and a data guru will tell the domain expert that they’ll build a recommendation engine, or classification algorithm for them. The SME says “Ok,” not really understanding what the data science terms mean in terms of output. Soon you have a SME receiving a finished data product that doesn’t really do what they thought it would, or simply isn’t accurate enough.
This is why the strategic stakeholder – persona 1 – is involved. They are there to moderate and build understanding between the two. The strategic stakeholder is there to get the data guru to a point where they can say “I’ll build a system that understands symptoms, failures, and resolutions.”
Data is inevitable. The enterprises that succeed have reprogrammed cross-functional behavior – their data scientists aren’t just who you turn to when you need some numbers run; they are intrinsic contributors to the product from the very beginning. These teams also think of the human element within AI initiatives as key cornerstones to the value being produced – they don’t see 30% task automation as a reason to reduce headcount, they see 30% automation as a way to increase the value each employee can provide.
And perhaps help you attack the right problem from the start.