How to stand up a Bimodal IT strategy to serve the core business and develop innovative solutions at the same time.
One of the biggest impediments to innovation lies in the tension between operating the core business and pursuing new initiatives. Nowhere is this tension realized more fully than in IT departments.
IT as a rule is organized and incentivized to keep things running smoothly. They naturally develop cultures of risk aversion over time, primarily out of self-preservation.
They are responsible for implementing (and more importantly maintaining) any technology infrastructure the organization deems to be of strategic importance. They are often under pressure to deliver faster than they’d like, and the expectation is that everything works without a hitch.
As a result, risk management becomes the dominating consideration. And for good reason - if a core process goes down or has bugs, it can mean millions of dollars in lost revenue or additional costs. Failure is simply not an option.The obvious problem is that an IT culture perfectly suited to maintaining the core business is woefully unprepared to deal with the ambiguity and perceived risk of new innovation initiatives. Telling a group of people to spend 80% of their time maintaining the core with excellence (meaning no mistakes), and 20% of their time experimenting on new stuff is often a recipe for failure.
And yet the imperative to innovate remains. And technology is usually a critical piece of the puzzle.The ideal scenario is a distinct set of people - organized, managed and incentivized in ways that maximize the likelihood of success.
The Bimodal IT architecture is a pattern commonly used in successful transformation initiatives. And it works.
According to a 2017 study by Gartner, roughly 4 in 10 CIOs reported implementing some form of Bimodal architecture. And of those, 71% reported Bimodal architectures improve the success rate of their innovation initiatives.
In a Bimodal architecture, there are effectively two IT teams working concurrently - what we call the Execution Team and the Innovation Team.The Execution Team is tasked with maintaining and improving the core business. Great ones do engage in regular incremental innovation initiatives, working to continually improve “the way we do things here.”
The Innovation Team is tasked with exploration. This could be identifying entirely new business models, new ways of serving customers, or thinking about radical new ways of doing the work of the core business.
The consistent thread is an emphasis on experimentation. They understand many of their initiatives will fail. The goal is to test numerous ideas, killing the bad ones quickly. Release cycles are short, and prototypes and beta tests are the norm.
Both threads are critically important. It’s not about simply standing up an Innovation Team while the Execution Team engages in the status quo. The end goal is to reimagine both. What matters is recognizing the need for each, and setting each up for success.
Trying to combine both into the roles of the same people creates a tension that is difficult to overcome. Likewise, simply standing up an Innovation Team like some splinter cell of rebels or cool kids creates unnecessary political drama and fails to appreciate the need to reimagine the core as well.
While Bimodal makes intuitive sense, it can be difficult to stand up and implement. What follows are some suggestions that we’ve observed tend to increase the likelihood of success.
A wholesale change effort is usually doomed. When trying to enact change of any kind, it’s typically best to start small. The implementation of a Bimodal architecture is no exception.
One effective approach is to stand up a Bimodal process for a single project. For a specific initiative, carve out a small group of people to represent your seed group for your Innovation Team. They work independently from your Execution Team, although they can come from your Execution Team.
The project should be small and self-contained. And the goal is not the success of the project itself, although you certainly want it to succeed.
The primary goal is to help this new team begin to form their own culture and identity. To recondition them to understand that their objective is to move fast, break things, and fail quickly on the way to finding out what works. Emphasis in this project should be on standing up some initial processes, equipping them with some tools, and focusing on learning.
In most organizations, having a strong leader (typically the CIO) providing sufficient air cover to the early team is critical to its success.
In many organizations the general assumption is that IT owns all of the initiatives related to technology, assuming all risks but with little upside in the event of success.
In a Bimodal process, the technology leaders inside the innovation team become partners with the LOB owners. The LOB devotes its own full time resources to the initiative alongside IT. Ideally these resources are co-located for the duration of the project.
The project or product manager is ideally from the LOB - this can help ensure the team is clear where the ultimate ownership for the project lies.You’ll often find within any LOB there is talent that is looking for a new challenge. They might be considering the startup world, and might be frustrated with the pace of change.
These initiatives can be a fantastic way to retain this talent, giving them the rush of excitement inherent in pursuing new initiatives with the security and ground cover of the existing operation.
One big pitfall in standing up these groups is the risk of cultures increasingly clashing. There can be a huge temptation for the Innovation Team to think that they can be the “creative” people, under no obligation to adhere to any form of process or rigor.
Likewise, particularly if the Innovation team pulls the more risk-tolerant team members from the core, there can be a temptation for the Execution team to become even complacent, assuming that any innovative thinking is the other team’s job.It’s imperative that you watch for and snuff out this type of thinking. In a well functioning organization, these two groups will build on and learn from each other.
This again is aided considerably by the help of a strong leader who makes sure that both teams are recognized, and rewarded simultaneously, not simply the fledgling Innovation team. Language is also critically important. Using language that portrays both teams positively (Execution and Innovation vs. terms like “legacy”, for example) can avoid any unintentional devaluing of the core team members.
Make it clear one of the goals of the Innovation team is to identify practices and techniques that can be leveraged inside the core organization. While their team might be concerned with more disruptive initiatives, the reality is there are always dozens of opportunities to make incremental improvements inside the core.
The Execution team in many organizations can benefit tremendously from incremental innovation initiatives - moving from application silos to platforms and reusable code, the development of APIs or microservices, etc.
Uncovering, prioritizing and implementing these ideas take many of the same skill sets. Your end goal is a company that is innovative, not simply a department.One way to do this is to have the Innovation team be a rotation program. People come into the program to learn the company’s approach to innovation. They get to practice them on real projects that matter. And then they return to the core business, often more energized and comfortable with change.You can also make an effort over time to transition the Execution team to more “agile-ish” development practices. This gets both teams operating with similar terminology, development cadences and practices over time which can increase the perception that they’re in this together.
A Bimodal architecture can resolve the stalemate between your execution and innovation initiatives. But getting started can sometimes be tough.
Many Manifold clients use an engagement with our team as an opportunity to stand up this Bimodal infrastructure. While pursuing a new product development or digital transformation initiative, Manifold team members simultaneously work on the product itself and teach the client’s internal team the tools and methodologies they need to ultimately to it themselves.
An easy way to start is with a Design Sprint, which results in a ton of momentum around an idea in as little as a week, and in the process introduces many design thinking methods to your team.If such an initiative would make sense inside your organization we’d love to talk.