Book Review: The Other Side of Innovation

August 22, 2013

Book Review: The Other Side of Innovation

I am part of a team that sends out an internal newsletter each month. It is called POV Dispatch because it shares a point of view about ideas that are important to Autodesk and our customers. Innovation is frequently one of the topics. For our September issue I am reviewing The Other Side of Innovation by Vijay Govindarajan and Chris Trimble. I thought I would share it with It's Alive in the Lab readers, since it provides a glimpse into two processes at Autodesk. Here is what I submitted.

Using a 5-page summary that I read during our getAbstract pilot, the key take aways from the book include:

Once companies achieve success, they tend to act like "Performance Engines." They strive to make day-to-day operations repeatable, predictable, disciplined and efficient.
Unfortunately, "innovation and ongoing operations are inevitably in conflict."
Beyond small or routine projects, every "Innovation Project" requires a "Dedicated Team." Companies should build the team as if they are building a new company from the ground up.
The Dedicated Team must partner with "Shared Staff," which remains part of the Performance Engine.
The Shared Staff should support the innovation initiative while sustaining quality ongoing operations.
The delicate partnership between the Dedicated Team and the Shared Staff requires direct oversight from senior executives.
Senior executives should view each innovation initiative as an experiment driven by a hypothesis.
Senior executives should assess progress by rigorously testing each assumption.
The leader of the innovation initiative must focus on learning quickly and inexpensively.
Senior executives often hold innovation leaders accountable for delivering the initiative's projected results. Instead, they should evaluate leaders on whether they have executed a disciplined experiment.

The book makes a distinction between a Performance Engine, and an Innovation Engine (although the authors did not call it that).

Performance Engine

The driving factor behind a Performance Engine is what business strategists call "operational excellence." It centers on consistency of process that yields repeatability and efficiency. There is a high degree of predictability for a Performance Engine since each new iteration is just another instance of what has succeeded in the past.
Innovation Engine

The driving factor behind an Innovation Engine is experimentation and learning." It centers on creating a hypothesis based on an aspiring idea and testing the hypothesis — often with new and completely different processes. There is a low degree of predictability for an Innovation Engine since each new iteration is intentionally different from what has succeeded in the past.

As defined, the two engines are inherently incompatible because they compete for resources that could lead to disharmony within a Division. That's why dedicated teams for innovation projects supported by shared staff that tend to shipping products/services while also supporting innovation are key. At Autodesk there is room for both engines:

Performance Engine

The development, release, marketing, and sales processes for our applications (e.g., AutoCAD, Inventor, Revit, 3ds Max) are well established processes. They can be considered Performance Engines. With millions of users, the stakes for these products are high. As a consequence, each overall release is more important than any one feature or defect correction. As such, there are characterized by team decision making and rigorous change review.
Innovation Engine

Not every process has to be patterned in the Performance Engine model. For example, the Autodesk Labs process can be considered complementary. Labs is often a precursor to a formal Beta process. Technologies on Labs are early in their development. They are not released products. The number of users tend to be in the thousands instead of the millions. These not-fully-baked technologies are given more latitude by the customers who try them out as well as Autodesk senior executives. Labs technology previews are about feedback.

Recently the technology preview of the Maximo Integration for Autodesk Revit retired from Autodesk Labs. With 595 downloads, some might consider this technology a failure since a technology preview like Inventor LT has 56,500 downloads. It is quite the contrary. Senior Industry Strategy Manager for Owners & Operators, Brook Potter, noted the benefits from the technology preview:
- With almost 600 downloads, this technology preview had notable scale, given the significant and enterprise nature of the Maximo business (e.g., one Maximo account represents hundreds or thousands of seats and end users).
- We captured important industry insights and technical requirements from this preview such as the importance of building owners articulating what data they need to manage and operate their facilities, and how to ask for this information — early on from their AEC services teams.
- We learned that integrations, like these, create new collaboration opportunities within the owner organization, where facilities teams are now working more closely with capital project groups.
- Most importantly, the preview continued to validate the interest of building owners in extracting even more value from the BIM process and workflow to better serve them in building operations, which is the longest and most cost intensive phase of the building lifecycle.
This is a perfect example of why each innovation project, in our case the technology preview, needs its own hypothesis. Labs technology previews are indeed disciplined experiments with designated start and end dates along with formal feedback mechanisms that are analyzed for sentiment and tallied.

Autodesk is well equipped to perform when necessary and innovate at will. Current plans include bringing more web services into the Autodesk Labs and Beta processes. As we move into the brave new world of cloud/mobile/social via an Innovation Engine approach, we can move those services to a Performance Engine model once they are established. While we do, let both the product/service releases and the innovation continue!

Walking while chewing gum is alive in the lab.

Posted by Scott Sheppard at 04:00 AM in Books, Point of View | Permalink

Tags: #AutodeskLabs, Autodesk Labs

Comments

Using a 5-page summary that I read during our getAbstract pilot, the key take aways from the book include:

Once companies achieve success, they tend to act like "Performance Engines." They strive to make day-to-day operations repeatable, predictable, disciplined and efficient.
Unfortunately, "innovation and ongoing operations are inevitably in conflict."
Beyond small or routine projects, every "Innovation Project" requires a "Dedicated Team." Companies should build the team as if they are building a new company from the ground up.
The Dedicated Team must partner with "Shared Staff," which remains part of the Performance Engine.
The Shared Staff should support the innovation initiative while sustaining quality ongoing operations.
The delicate partnership between the Dedicated Team and the Shared Staff requires direct oversight from senior executives.
Senior executives should view each innovation initiative as an experiment driven by a hypothesis.
Senior executives should assess progress by rigorously testing each assumption.
The leader of the innovation initiative must focus on learning quickly and inexpensively.
Senior executives often hold innovation leaders accountable for delivering the initiative's projected results. Instead, they should evaluate leaders on whether they have executed a disciplined experiment.

The book makes a distinction between a Performance Engine, and an Innovation Engine (although the authors did not call it that).

Performance Engine

The driving factor behind a Performance Engine is what business strategists call "operational excellence." It centers on consistency of process that yields repeatability and efficiency. There is a high degree of predictability for a Performance Engine since each new iteration is just another instance of what has succeeded in the past.
Innovation Engine

The driving factor behind an Innovation Engine is experimentation and learning." It centers on creating a hypothesis based on an aspiring idea and testing the hypothesis — often with new and completely different processes. There is a low degree of predictability for an Innovation Engine since each new iteration is intentionally different from what has succeeded in the past.

Performance Engine

The development, release, marketing, and sales processes for our applications (e.g., AutoCAD, Inventor, Revit, 3ds Max) are well established processes. They can be considered Performance Engines. With millions of users, the stakes for these products are high. As a consequence, each overall release is more important than any one feature or defect correction. As such, there are characterized by team decision making and rigorous change review.
Innovation Engine

Not every process has to be patterned in the Performance Engine model. For example, the Autodesk Labs process can be considered complementary. Labs is often a precursor to a formal Beta process. Technologies on Labs are early in their development. They are not released products. The number of users tend to be in the thousands instead of the millions. These not-fully-baked technologies are given more latitude by the customers who try them out as well as Autodesk senior executives. Labs technology previews are about feedback.

Recently the technology preview of the Maximo Integration for Autodesk Revit retired from Autodesk Labs. With 595 downloads, some might consider this technology a failure since a technology preview like Inventor LT has 56,500 downloads. It is quite the contrary. Senior Industry Strategy Manager for Owners & Operators, Brook Potter, noted the benefits from the technology preview:
- With almost 600 downloads, this technology preview had notable scale, given the significant and enterprise nature of the Maximo business (e.g., one Maximo account represents hundreds or thousands of seats and end users).
- We captured important industry insights and technical requirements from this preview such as the importance of building owners articulating what data they need to manage and operate their facilities, and how to ask for this information — early on from their AEC services teams.
- We learned that integrations, like these, create new collaboration opportunities within the owner organization, where facilities teams are now working more closely with capital project groups.
- Most importantly, the preview continued to validate the interest of building owners in extracting even more value from the BIM process and workflow to better serve them in building operations, which is the longest and most cost intensive phase of the building lifecycle.
This is a perfect example of why each innovation project, in our case the technology preview, needs its own hypothesis. Labs technology previews are indeed disciplined experiments with designated start and end dates along with formal feedback mechanisms that are analyzed for sentiment and tallied.