Innovation Isn’t Just a Buzzword

It’s rather unfortunate that everything has to be an innovation these days. Even worse, is that for a business to be effective, it seems they must drive disruptive innovations. Innovations are simply inventions that have been successful in the market, those inventions might actually business model changes that have been successful in penetrating the market. I personally find that looking at innovation as a framework to analyze business pressure to be extremely interesting. I did this today in an interview and it felt really good as I was able to create context around changes impacting the health insurance industry.

Several years ago I wrote about the 4 types of innovation, Incremental, Modular, Architectural, and Radical. This is a bit different than the framework that Christenson argues, since he only looks at 2 types, Incremental and Disruptive. I believe that disruptive encapsulates both Architectural and Radical. Architectural changes are business model innovations while making a very similar product but one that significantly undercuts existing businesses or creates a new market. While Radical innovations creates a new market but also attacks existing customers, through a new business model and a completely different type of product. Think of a fan competing against an air conditioner window unit, while central air is an architectural change for the window unit.

da9cf-typesofinnovation

I believe that this framework is just as useful for businesses to analyze their environment as Porter’s 5 Forces┬ábecause it forces businesses to confront the disruptive innovations that they might have overlooked otherwise. Without using this framework it is likely that businesses would ignore the new entrants force as they don’t feel that those businesses will ever compete with them. However, based on historic evidence those entrants that have a different business models or a different metrics for their performance eventually supplant incumbents. I believe that this type of analysis should be conducted annually or bianually as many industries and markets have continually increasing uncertainty and faster rates of change than historically.

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.

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.