Lean Enterprise Innovation

Lean Enterprise Innovation

(FYI, we’re using affiliate links to Amazon in this post!)

Technology innovation is vital. It can enable business success – and it can also drive business innovation.

If a business falls behind the technology curve, it opens itself up to the risk of under-serving its customers, and eventually being out-maneuvered and defeated in the marketplace. This happens over and over to businesses, where a competitor’s technological innovation pushes them right out of existence – see Blockbuster (Netflix), and Border’s (Amazon, B&N). Amazon has also innovated while JC Penney has stagnated – department stores could have taken the world by storm via the internet – but their online presences weren’t good, certainly not as good as their competitors, and therefore neither were their sales figures.

On the other hand, if your business keeps up with current IT tools, processes, platforms, and techniques, you can speed up your business execution and provide a higher quality of service to your customers. You can also execute higher-efficiency development processes, which has the additional benefit of speeding up everything that your IT people do. If you think back, there have probably been times in your business’s history where innovation in your systems gave you the chance to leap forward – to serve your customers above expectations, and to out-compete your competitors.

And, as technologists, newer technology is just more fun, and running new technology can be a competitive advantage in the IT hiring market.

It’s hard to argue with the need to innovate – the hard part is innovating successfully over time.

Lean Enterprise

Lean concepts are not new.

Ever since the manufacturing revolution of the 1980s, companies have tried to apply scientific principles to their work processes, and minimize the cost of resources spent doing work that will later be thrown away, or that won’t be needed until much later.

Changing a large organization is hard.

Large organizations have typically been successful over a long period of time, and arrogance, complacency, or some mixture of the two can slowly kill a formerly successful organization – like a ship that doesn’t turn around because it assumes it will never hit that iceberg. Large enterprises also have existing culture and a lot of momentum in the direction they’re already going – and culture and organizational momentum are the hardest things to change.

Culture and organizational momentum are the hardest things to change.

Jez Humble, Joanne Molesky, and Barry O’Reilly wrote Lean Enterprise to apply these existing Lean principles in order to explain how large organizations should continually learn and transform themselves.

Their thesis: by starting small and basing innovation success or failure on measurables, an organization can learn and continually grow and innovate.

Lean Innovation

Their main points are:

  • Design your innovation processes like science. Define an objective, do an experiment, and evaluate the results.
  • Spend the minimum amount of time/money/resources to take the next step. Baby step into innovation.
  • Remove barriers to innovation, such as centralized detailed decision making and “change prevention” as a corporate value.

We really like the idea of doing small-scale research implementations, with no promise of long-term support, and no promise of a guaranteed enterprise rollout.

This is effective for a few reasons:

  • people don’t panic at being forced to support technology they’ve never used
  • the enterprise doesn’t invest a lot of money in something that ends up being awful when meshed with existing technology and processes
  • if an enterprise rollout does happen, it’s with cultural support and assurance, and also with some feedback on how to make it better

Technology is extremely variable and unpredictable. We shouldn’t treat it like a one-shot cannon, where we either hit spectacularly or miss spectacularly, we should treat it like a machine gun firing tracer bullets – try a lot of experiments with a lot of feedback, and be willing and able to adapt as you go.

This also has the added benefit of lining up very well with Agile methodologies, which seek to deliver business value in pieces over time, always learning and re-prioritizing.

Only for IT?

The wisdom contained in The Lean Enterprise applies to any organizational process or platform. People can even live their lives outside of an organization by trying things out, questioning their assumptions, doing science, and remaining flexible.

Direction Setting vs Decision Making

The authors describe successful organizations (such as the US Army in World War II) that operated in high-risk, dangerous environments, coordinated massive efforts, but also successfully allowed flexibility in operations and decision making. These organizations had people on the ground making decisions that people back at central HQ couldn’t have even imagined.

A major principle that the authors believe in and advocate for is, “the people closest to a problem understand it best.”

Their suggestion is that top-level leadership should define top-level priorities and objectives and clear measurables. They should communicate these to the next level of leadership, and then delegate execution authority to that level. That level should define their priorities for their subset of the objectives, define measurables, communicate, and delegate, etc.

So, in an enterprise expanding into a new region, it could look like this:

  1. The board and the executive team decide major objectives, timelines, and measurables and then delegate execution to a regional director.
  2. The regional director decides that the execution on her end includes building key relationships, creating policies, and negotiating regulations. She delegates these to the people on her team.
  3. …so on and so forth until it gets all the way to where boots are on the ground – writing the specifications, building products, and talking to customers.

It would be silly to suggest that the CEO should write all of the legalese and specifications, participate in all of the sales calls, and negotiate with every regulator.

In this plan, some teams will need more direction and some will need less. A great way to approach this is, again, adaptability, and also “reasonable defaults” – tell people where to start and then allow for, and even encourage, deviation as it makes sense.

Bottom line: centralized direction-setting is critical, but it should be clear and appropriately general so as to allow for de-centralized decision making and implementation. This requires strong communication and trust at all layers of the organization.

Bottom Lines

Okay, that was a lot, so…in summary, these are the recommendations for successful enterprise innovation:

Communicate expectations, direction, and objectives clearly and at the right level.

Do more lean experimenting, with an acknowledgement that 90% of it might get thrown away, because it just won’t work because reasons. Include in your experimentation sharing what’s been learned even if it was a disaster – especially if it’s a disaster.

Do not do big-bang technology rollouts. Tech and process innovations and improvements like JIRA, TDD, Slack,  OpenShift, GitHub, Continuous Delivery, and ${your_fave_new_thing} should have defined benefit criteria and specific success metrics, and they should be rolled out slowly. Spend the minimum amount of resources in each phase to feel confident that you know if it was a success or not, because you might throw it all away. Basically, do canary releases for innovation.

Allow teams to self-determine their processes and tools. Support common standards (e.g. Agile/JIRA/Java/Spring/Prometheus/Grafana), and let teams figure out their own implementation. Want to try Scrum? Sure! Want to try out that new Spring library? If it passes security scan, go for it! Want to add more automated testing? Please do! 

Governance clearly. Yes, you do have to get your release approved, and yes, you should pay attention to those SonarQube results. No, you can’t keep your source code outside of the main git repo. No, you definitely can’t write a web app in FORTRAN. No.

When teams find success with a new thing, share it! Organizational learning is important, and a lot of that comes from teams innovating and teaching each other. Give presentations, formal or informal. Post to your internal mailing list or share it on your corporate chat/Slack-like thing. Tell your friends at lunch! Write a blog!


Innovation isn’t easy, but it’s vital in order to get or maintain a competitive advantage. Changing organizational culture is very difficult – but innovation shouldn’t actually be changing everything all at once. With support, adaptability, and the right amount of freedom to implement, any organization can innovate and learn in ways that make sense for them.

Comments are closed.