This company was so serious about dealing with this threat (they described it as “existential to their survival”) that they had mobilized the entire corporation to come up with new solutions. This wasn’t a small undertaking, because the threats were coming from multiple areas in multiple dimensions; How do they embrace new technologies? How do they convert existing manufacturing plants (and their workforce) for a completely new set of technologies? How do they bring on new supply chains? How do they become present on new social media and communications channels? How do they connect with a new generation of customers who had no brand loyalty? How to they use the new distribution channels competitors have adopted? How do they make these transitions without alienating and losing their existing customers, distribution channels and partners? And how do they motivate their most important asset – their people – to operate with speed, urgency, and passion?
The company believed they had a handful of years to solve these problems before their decline would become irreversible. This meeting was a biannual gathering of all the leadership involved in the corporate-wide initiatives to out-innovate their new disruptors. They called it the “Tsunami Initiative” to emphasize they were fighting the tidal wave of creative destruction engulfing their industry.
To succeed they realized this isn’t simply coming up with one new product. It meant pivoting an entire company – and its culture. The scale of solutions needed dwarf anything a single startup would be working on.
The company had hired a leading management consulting firm that helped them select 15 critical areas of change the Tsunami Initiative was tasked to work on. My hosts, John and Avika, at the offsite were the co-leads overseeing the 15 topic areas. The consulting firm suggested that they organize these 15 topic areas as a matrix organization, and the ballroom was filled with several hundred people from across their company – action groups and subgroups with people from across the company: engineering, manufacturing, market analysis and collection, distribution channels, and sales. Some of the teams even included some of their close partners. Over a thousand more were working on the projects in offices scattered across the globe.
John and Avika had invited me to look at their innovation process and offer some suggestions.
Are these the real problems?
This was one of the best organized innovation initiatives I have seen. All 15 topic had team leads presenting poster sessions, there were presenters from the field sales and partners emphasizing the urgency and specificity of the problems, and there were breakout sessions where the topic area teams brainstormed with each other. After the end of the day people gathered around the firepit for informal conversations. It was a testament to John and Avika’s leadership that even off duty people were passionately debating how to solve these problems. It was an amazing display of organizational esprit de corps.
While the subject of each of the 15 topic areas had been suggested by the consulting firm, it was in conjunction with the company’s corporate strategy group, and the people who generated these topic area requirements were part of the offsite. Not only were the requirements people in attendance but so was a transition team to facilitate the delivery of the products from these topic teams into production and sales.
However, I noticed that several of the requirements from corporate strategy seemed to be priorities given to them from others (e.g. here are the problems the CFO or CEO or board thinks we ought to work on) or likely here are the topics the consulting firm thought they should focus on) and/or were from subject matter experts (e.g. I’m the expert in this field. No need to talk to anyone else; here’s what we need). It appeared the corporate strategy group was delivering problems as fixed requirements, e.g. deliver these specific features and functions the solution ought to provide.
Here was a major effort involving lots of people but missing the chance to get the root cause of the problems.
I told John and Avika that I understood some requirements were known and immutable. However, when all of the requirements are handed to the action teams this way the assumption is that the problems have been validated, and the teams do not need to do any further exploration of the problem space themselves.
Those tight bounds on requirements constrain the ability of the topic area action teams to:
I noticed that with all of the requirements fixed upfront, instead of having a freedom to innovate, the topic area action teams had become extensions of existing product development groups. They were getting trapped into existing mindsets and were likely producing far less than they were capable of. This is a common mistake corporate innovation teams tend to make.
I reminded them that when team members get out of their buildings and comfort zones, and directly talk to, observe, and interact with the customers, stakeholders and beneficiaries, it allows them to be agile, and the solutions they deliver will be needed, timely, relevant and take less time and resources to develop. It’s the difference between admiring a problem and solving one.
As I mentioned this, I realized having all fixed requirements is a symptom of something else more interesting – how the topic leads and team members were organized. From where I sat, it seemed there was a lack of a common framework and process.
Give the Topic Areas a Common Framework
I asked John and Avika if they had considered offering the topic action team leaders and their team members a simple conceptual framework (one picture) and common language. I suggested this would allow the teams to know when and how to “ideate” and incorporate innovative ideas that accelerate better outcomes. The framework would use the initial corporate strategy requirements as a starting point rather than a fixed destination. See the diagram.
I drew them a simple chart and explained that most problems start in the bottom right box.
If a solution is found and solves the problem, the team heads up to the box on the top left.
But I explained that very often the solution is unknown. In that case think about having the teams do a “technical terrain walk.” This is the process of describing the problem to multiple sources (vendors, internal developers, other internal programs) debriefing on the sum of what was found. A terrain walk often discovers that the problem is actually a symptom of another problem or that the sources see it as a different version of the problem. Or that an existing solution already exists or can be modified to fit.
But often, no existing solution exists. In this case, teams could head to the box on the top right and build Minimal Viable Products – the smallest feature set to test with customers and partners. This MVP testing often results in new learnings from the customers, beneficiaries, and stakeholders – for example, they may tell the topic developer that the first 20% of the deliverable is “good enough” or the problem has changed, or the timing has changed, or it needs to be compatible with something else, etc. Finally, when a solution is wanted by customers/beneficiaries/stakeholders and is technically feasible, then the teams move to the box on the top left.
The result of this would be teams rapidly iterating to deliver solutions wanted and needed by customers within the limited time the company had left.
Those companies that make it do so with an integrated effort of inspired and visionary leadership, motivated people, innovative products, and relentless execution and passion.
Watching and listening to hundreds of people fighting the tsunami in a legendary company was humbling.
I hope they make it.