The Innovation machine – This is a “how to” guide for Innovation management

As many of my blog readers know I’m an innovation reading junky. I’ve read many of the books on how to manage, from a individual’s perspective, creating an innovation or even at a high level how to run an innovation project. However, this if the first book that looks at things in a very systematic manner utilizing a lot of case studies. The Innovation Machine by Rolf-Christian Wentz is a fantastic introduction into a series of case studies of the most innovative companies in the world.

Books like the Innovator’s Dilemma are a lot more prescriptive in what a business should do or how a given business has been disrupted. Typically they focus on the smaller entrants that enter a market and beat the incumbents. The Innovation Machine on the other hand looks at the incumbents and analyzes what the organization did culturally to enable innovation. I believe books like Innovator’s Method and the Lean Startup address a different need: how to take an innovative idea to market. This book touches on those things, but looks at how the whole organization can enable those Lean startups within the organization and use it’s size to maximize the results.

The Innovation Machine also touches on the portfolio management aspect as well as some of the best ways to fund projects, staff projects (2 is best, a small room is next, anything else is doomed to fail), and finally how to integrate the project teams back into the larger business as a whole. No book that I’ve read has really discussed how to do this. All these topics are covered with clear case studies of some of the most innovative companies. He includes discussions of Google, Toyota, GE, P&G, SC Johnson, BMW, Microsoft, Whirlpool, and a litany of others. The stories are referenced as he details the concepts that were leveraged by the companies in his case study.

I believe that this book is a must read for a CEO or a leader that values innovation. Especially since he calls out the massive differences between managing Incremental Innovation and Disruptive Innovation – he gives very clear practical examples and methods for managing them separately. I believe these are powerful and will help me identify projects I work on more easily as disruptive or incremental.

I’m surrounded by @ssh*les!

Everywhere I look I see bad managers these days. Which is surprising considering that there are articles being published every day with headlines like “People don’t quit companies they quit bad managers” or “Bad Managers are the no 1 reason why people leave their job.” This is a problem specific to one company or one industry, but rather it’s across industries and sectors. I’ve worked in Semiconductor manufacturing, semiconductor design, and now health insurance all of them have had their share of bad managers. It’s not even just home grown managers that make poor decisions, it’s managers that are specifically hired to come in to effect change that don’t have the right skills to do the job that needs to be done.

It is whenever managers are put into a position where they do not have the information they need or the right skills to do the job that they become assholes. This is especially problematic in complex environments and this complexity isn’t linear from person to person, which is to say that a given person might find one level of complexity manageable, while another person may be unable to handle it. So for one manager that could be managing the line at a fast food restaurant, while another it might be managing a project that has 5 internal stakeholders and 5 government regulatory agencies as stakeholders.

In large organizations complexity is only going to increase. In this way complexity is like entropy, it only increases. We implement new policies and likely never eliminate historic policies. This is especially true with government regulations. We rarely sunset those provisions. The only way to manage this complexity is to plan. Like all plans, they are pretty much worthless after you build the plan, but going through the process is invaluable.

For instance, my preferred strategic planning approach is to pull in three types of data, Voice of the Customer, Voice of the Business, and Voice of the Team. Voice of the customer is what your customers are telling you about your existing services and offerings. They can tell you how much you’ve screwed up and where you’ve screwed up. They might not be able to help you identify the next iPhone, but they can tell you not to build the next Blackberry device. Voice of the business is typically the loudest voice at any organization. This is what the C-Suite is telling everyone to do, this is the competitive landscape and the regulatory environment that you operate within. Together these voices are powerful and loud. Finally, the voice of the team is almost always ignored, mostly because the team won’t speak up. This needs to be a true analysis of the capability of the team using Capability Analysis of Business Architects or doing a SWOT. Using these three voices to have a frank conversation, you can build a three to five year road map. Then you can build out your strategy to enable your team to meet your customer needs as well as your business requirements.

Managers become less of an asshole whenever they have clear management processes in place. Clear reasons why they are doing what they are doing. Employees aren’t the only ones that need processes. Managers and leaders need them too. They prevent churn and waste if they stick to them.

What should a manager manage?

Managers should not be managers of people, they must manage processes. Managers should be leaders of people not managers of people. Managing people by watching them closely is not typically a very effective method to ensure that work is completed. Micromanagement breeds mistrust between employee and manager. Through managing the quality of the processes the manager is able to increase the likelihood of success of their people.

All work is a process. Even if there doesn’t appear to be a process if the work is to be fully completed there are a series of steps that must be completed. It doesn’t have to be a good process, a repeatable process, or particularly effective but if the work is completed it followed a process. Furthermore, if more multiple people do the same type of work without a clearly defined process it’s likely that there will inconsistent results to their work. A manager owns the overall output of all the work of their employees. If the work is consistently subpar or employees have a difficult time picking up the way to do the work that is expected of them, this is the responsibility of the manager to address. It doesn’t matter how amazing the employees are, they could have been consistently excelling in a previous, if the processes are terrible those employees will not succeed.

Not every type of work can effectively be managed through traditional software. For example, software and technology development in both these are “knowledge” activities that unlikely would benefit from a highly structured process. In these cases there are two things that help manage the process. First creating a regular process of checking in, managing what work the developers should be doing, and working to eliminate roadblocks – in software this is Agile software development. Second you create a standard process to feed in consistent data into the truly creative process and consistent outputs so that the consumers of the work are able to use the output of the creative process effectively in their work.

To manage the processes managers need to equip their employees and themselves with tools to do root cause analysis, conduct structured problem solving, and rigorous process improvement. Managers need to take ownership of the end to end process, the data their employees use to complete their work, and the quality of the results. It is important that this becomes the norm as it will switch blame from people, who generally want to do the right thing, to the process and how work is completed.

This is not to say that whenever people deviate from the agreed upon process that the manager shouldn’t address that or if people still fail to meet expectations while working in the process that they can’t be fired. However, leading employees to identify broken processes, supporting them in fixing them, and providing tools to do so becomes the role of the manager rather than micromanaging their employees.

Strategy and Business Management

As I mentioned in my Business and Silver Bullets article, there are a lot of different approaches to managing your business, or at least a portion of your business. None of these approaches are easy to implement and it seems that there’s a bit of a revolving door around what leadership approach is the best for a given business. Furthermore, it’s troubling to me that organizations are looking at initiatives like Lean and Six Sigma as only operational improvement opportunities. As I’m reading through how Business Architecture works, it’s obvious to me that many of the organizational deployments of LSS have failed in reaching their full potential. I saw it at Samsung, AMD, and I’m skeptical of the full reach I’m going to have at Regence. It’s not a failure of the individuals deploying it or of a given leader, it’s a failure of the full organization to accept that changes need to happen. Organizations need to integrate approaches like LSS into their core strategic planning process. Otherwise those methodologies will only impact a limited area and won’t appear to have a holistic approach to making changes to an organization.

From my experiences Lean and Six Sigma methodologies can indicate the need for organizational re-alignment. These require real change with serious effort to implement those changes. In many cases those are outside the scope of the project facilitator, the leader of the process improvement center of excellence, and likely the owner of the processes. It’s got to come from an executive sponsor. They have to be able to provide the organizational courage to make real changes to an organization. Through these tools it’s possible to identify redundancies and areas where organizations require massive change.

Why don’t organization implement these changes? Too many priorities is likely one problem. Another is that these changes are hard and unless they are well versed in Lean or organizational structures, they won’t understand why the changes are fundamental to continued success of an organization. They may not understand the changes because they weren’t involved in the redesign process intimately enough. Finally, it might also be that these changes are bottoms up recommendations and not top down.

I believe this is why Business Architecture eventually was a created as a discipline. I believe in organizations that are truly Lean that these types of roles are not needed. Simply because the bottoms up approach allows the leaders to focus on different things especially since a true Lean organization is always customer centric. In organizations that there is a great deal of legacy behavior and entrenched management fiefdoms, it might be a requirement to go through an organization like Business Architecture to give the true sense of ownership to the leaders. It makes the bottoms up recommendations that come from the BA team seem like it’s a top down approach that is sanctioned by all of leadership. It let’s people see that clearer tie between the different organizations in a way that a lot of Lean work doesn’t. It’s designed to be holistic not something grown into the whole over time.

This leads to a different method for developing strategy than what a lot of Lean practitioners utilize. Business Architecture focuses on the current capabilities and works to align the strategy from there. Lean starts with the 5 year vision and goals and figures out how to align existing projects and improvement efforts to enact those goal, through providing a metric for the person doing the work on the ground.

I think that these business management approaches are both valid, I’m really biased towards Lean, but I do believe that in many organizations Business Architecture is likely required. It leaves the control a bit more in the leadership rather than the Lean approach. I believe they both can impact strategy in an effective manner, but it’s likely that BA will be more tightly coupled from the start than many Lean initiatives.

Businesses and Silver Bullets

I’ve been teaching Lean Process Improvement or Six Sigma for about 6 years now. I’m getting into learning Agile in a pretty deep way through reading a ton of books, seeing it in action, and working with Agile teams. I’m currently learning Business Architecture/Enterprise Architecture as well. All of these methodologies are similar but different in some dramatic ways. Lean itself isn’t a project management solution, it has some features of it, but the goal is to take action put something in place and measure the results. Inherently, you’re supposed to be done as soon as possible. Six Sigma has some pretty strong Project management capabilities built into it, but it’s not to be used to install software or some other type of function, it’s design to solve a complex problem, prevent it from happening again and moving on. Agile is totally about managing projects while with as little overhead as possible, while maximizing visibility. This is done through frequent light weight touches and less frequent demos. Finally business architecture is about defining the structure of the business then identifying root causes. I’m the least impressed with Business Architecture at this point because it seems to have the objective of keeping the people at the top in charge while minimizing the amount of empowerment throughout the organization. That’s just my first brush with it though and I could be wrong. The other methodologies are all about empowering the team and the people doing the work so they can be as effective as possible. With Lean and Six Sigma the goal is to eliminate your own job if you’re an instructor or internal consultant, it doesn’t seem the be the case with Business Architecture.

Regardless, all of these methodologies indicate that our businesses are extremely sick. It’s becoming pretty clear to me that the vast majority of current state business practices are flawed and leading to under performing businesses. Lean Six Sigma, makes it clear that there are out dated and poor performing processes. Agile makes it clear that traditional software development doesn’t work and is much too expensive. Business Architecture indicates that no one knows what people are doing, why they are doing it, or where other parts of the organization are doing the same type of work.

In many cases some of the problems looking to be solved by Business Architecture are eliminated in a true Lean organization, but not always. I believe that is why Lean Startup methodology is becoming so popular in both new and old businesses. It’s a novel way to force change in an existing company, while in a Startup it helps keep the company healthy much longer. Furthermore, it forces the company to build effective organization structures early and continually test them.

With the majority of businesses being unhealthy due to out dated processes or aging systems, it’s no wonder why organizations are always looking for a silver bullet. They need a quick fix because nothing is working correctly. The goal to continually drive more and more profits prevents leaders from taking a hard look at what they are doing. Forcing investment in doing the right thing the first time or to do the right thing for the organization even if it takes more time and potentially money.

With my current process improvement classes and engagements I’m seeing a continually struggle between the way you should do Lean, focus on changing what you can, and the reality that most of the work is being done through systems. Even if I wanted to improve processes around the system there’s a limit to what I can do, because I cannot effect change on the underlying system. Changing those systems either IT or organizational can be impossible to do without a strong organizational will and clear strategy. Without either of those, any improvement or agile effort is doomed to fail.

Methodology, managers, and projects

When working on a project there are a few different ways to manage those projects. One is the traditional waterfall approach, which is your top down project where you have to use Gantt charts to figure out how long you think it’s going to take up front, where you’re given a set date that can’t change without a lot of effort to do a certain amount of poorly defined requirements, and a set amount of money to do the project. This approach has been how Windows and many video games have been produced in the past. It’s not really extremely effective and really no one really likes working a project conducted using Waterfall methodologies. There are risks, projects get cancelled and the project management can seem to be capricious and opaque. This leads to lack of trust and belief that management has the best interest in mind for both the project and the employees on the project.

To address these concerns a group of people created the Agile project management methodology. The goal was to value working software over documentation. Which means that each bit of software is broken down into the minimum viable feature, or the smallest piece of working software that could be packaged and used by a customer. The goal is to manage the project through adjusting how many of these features are going to be finished by the go live date. Effectively you build small bits of work instead of finishing one giant massive piece of software.

This approach is effective for other types of technology that have a modular architecture. There’s some minimum viable product, where you need a minimum set of features for the product to actually work. For example a cell phone needs to have a combination of features to function properly. Things like bendable screens would not be in the minimum viable product, but an excellent touch screen would be. These minimum viable features can be modulated based on the Kano model – which is useful for determining if a specific feature is basic, a pleaser, or a delighter. If the feature falls into basic, you must include that feature if you’d like it to be a success. However, those minimum features don’t guarantee a successful product, you’ll need to include pleasers as well as delighters. Those are the pieces of scope that you will be able to eliminate to make sure you actually launch the product on time.

Issues with these projects come whenever there is a mixture of methodologies. When management believes projects must be managed through waterfall through a central project results office while the development team believes the project is being managed through the agile methodology. This creates serious issues whenever there is miscommunication, lack of information, or lack of understanding the real status of the agile team’s approach. This is exacerbated by the required openness in the agile approach (where you are supposed to continually learn from your mistakes and have a conversation about all the problems you’ve had – to fix them) while in waterfall it is better for people to hide and place blame elsewhere whenever things are not going well. Not because people are bad, but the incentives are in place to behave this way. With a single option of go/no go, it’s better to minimize the known risks as if things are misunderstood as going poorly it will drive management to take action. While in an Agile team, discussing the true status of the project is vital through self policing and partnering with other agile teams to address the problem. The greater the likelihood of success of the projects.

This conflict and a switch from governance in the agile methodology can and will destroy the trust the various agile teams have developed. An organization needs to fully commit to a single project management methodology or it will struggle to complete any project within scope and budget and will demoralize the leaders of projects being worked in agile, as waterfall would likely be the methodology that management selects. Leaders of Agile projects should leave organizations that undercut the agile teams, as it will not stop and will have dramatic impacts on their careers in the long run.

Words, what are they good for?

At work, I’ve recently been given the task of redesigning all my training documentation and plans for Lean process improvement to something else. Apparently, despite successes, some of my leadership team doesn’t believe in Lean. However, they fully expect improvements such as reduced turn around times, quality improvements, and reduced non-value add activities to just happen. That it’s simply expected to occur without any top down pressure or support. Without clear direction or proper tools to measure improvement or even productivity, how can anyone expect to drive improvement in their organization?

Lean is a tool to do that, but since some leaders don’t believe that’s the proper way to drive improvement, we’re having to monkey with the idea of what it means to be an efficient organization. Therefore, I’m going to be rebranding everything to Process Innovation because Innovation. This does an interesting thing, it forces us to change the language we use for continuous improvement. We can’t use words like Gemba (the place where work is done), Kaizen (continuous change), Jidoka (automation with a human touch), Poka-Yoke (idiot proofing). or Muda/Muri/Mura (waste, overburden, unevenness). Using these words isn’t just to try to force people to learn some Japanese. It forces people to slow down and think differently.

Regardless of your thoughts on Malcolm Gladwell, he raises some really valid points about language in his book Blink, where he discusses the example of Korea Air and the usage of English as a language in the flightdeck because it changes the way the first officer and captain think about each other. Lean emulates this idea by forcing English speakers to use Japanese words. It forces people to stop and think about what they are doing. Yes, it’s a foreign word, but the meaning drives a change in behavior simply because it forces the people listening to slow down and think. According to Daniel Kahnman, system 2, deep and introspective thinking, is lazy and lets system 1, Blink thinking, do most of the work. A change of language and specific words triggers system 2 to actually pay attention and not just accept what is said as fact.

Now with Process innovation, I’m going to have to invent my own language and rules to try to force a similar behavior. I’ll have to lean heavily on Lean, Six Sigma, and other improvement methodologies rather than just Lean. However, this might confuse Lean folks.

It’s amazing the impact of a few phrases on changing the way people behave and it’s amazing how they can cause people to react in a negative way. Figuring out how to work around other people’s language hang ups is key for a successful work life, unfortunately.