Innovation Requires Trust

I’ve worked with some of the most innovative companies in the world and I’ve interacted with some of the least innovative companies in the world.  What I’ve learned is simple: innovation requires trust.

What is innovation?  For some companies it means building a fancy new mobile app, or perhaps migrating out of the datacenter to take better advantage of cloud computing. To others, it means creating a new category in the market or new experiences that their customers will love. Each business is different, but almost every company I talk to believes strongly that they need more of it, yet they are having trouble getting the kinds of innovation they desire from their teams.

Innovation is a kind of change that can be labeled as good only after the fact.  Before it is an innovation, it takes the form of an experiment, and experiments come with risk.   As a company grows, it begins to construct layers of bureaucracy to protect itself from risk. This takes the form of spending limits, review boards, manual approvals, sign-offs, rigid process, exhaustive quality assurance testing, etc.  These all make sense in isolation and they build one layer at a time until the barrier to innovation is to too high to overcome.  The result is often a crippling avoidance of change and risk.

So ask yourself, how easy is it for your employees to take risks?  If the burden is high, I would argue that true innovation is impossible in your organization.  You probably worked hard to hire strong leaders and employees with great ideas and capabilities, but have you given them the freedom to experiment, to potentially fail?  Have you given them the time?  Have you provided Guide-Rails_® for experimentation?

Software engineering provides the greatest potential in any company to drive vast innovation, but in far too many companies, bureaucratic processes stifle the very innovation it is supposed to enable. You are probably not getting the innovation you desire from your software engineering organization if:

• Your innovation projects are prioritized against and sequenced on the same roadmap with business-as-usual projects like the next database upgrade.  Risky projects always get reprioritized and pushed out.

• You have a separate “innovation team” responsible for delivering innovation projects. More often than not, these teams come up with novelty projects that can’t scale or drive meaningful value for the business. Excluding your broader team from the innovation mandate means missing out on their expertise and their understanding of your customers. Meaningful innovation can’t happen in a vacuum.

• You have a <Business, Architecture, Innovation, Insert-Vague-Name-Here> Review Board that meets once a month to review proposals for innovation projects. Only the most motivated of employees will bother because most experiments could have been done in the time it took to write that proposal, let alone get it funded and approved.  They will see it as what it is, pandering to the organization rather than respecting and rewarding the attempt.

• Your processes for rolling out, and rolling back are painful and costly. Most companies spend so much time and effort trying to ensure something works exactly as they expect, that they make rolling it out a tedious and complex task… and rolling it back in the case of a problem, even harder.  This makes change very difficult because the barrier for experimentation is extremely high, and disabling or removing failed experiments becomes its own project.  Investing in the ability to quickly add and remove things is one of the most important investments you can make to drive innovation.

• Your organization punishes failure.  Most experiments will fail, but so will most of your thoroughly planned projects.  Rare is the project that actually delivers on all of its promises.  Experimenters need the freedom to fail and the support to learn lessons to inform the next set of experiments. That’s how science works, and that’s how innovation works.  Trial and error is a necessary part of any learning process.

So, how do you innovate safely?  Simple, you make it easier for your engineers to try things out, measure their success or failure, and adjust.  This takes many forms, but it has a few key points:

• Automated testing – it may seem counterintuitive, but fast, repeatable testing is the key to speed, and speed is the key to experimentation.  We don’t give ourselves that many bites at the apple before giving up and the harder it is to make a change and push it out, the fewer experiments we will run.  So invest in your feature testing infrastructure and avoid manual product testing.  The money you spend on manual testing would be better spent on more engineers with a better process.

• Experimentation frameworks – the ability to wire on features and wire them off again with a few clicks and collect data about their impact is key to having the confidence to move forward.  When all projects go live and can’t be taken back, the barriers will go up quickly to avoid the failures, and your potential successes will never see the light of day.  Make it part of your process to try things out, measure them and weed out the failures quickly.  But learn from every experiment you run.

• Autonomy with guide rails – A motivated engineer with a good idea can get something amazing done within a few days if they have the freedom to do so.  If you have a process to limit the “blast radius” of a failed experiment, and a way to measure the impact of their change (positive or negative), you have a recipe for success.

Your engineers aren’t trying to destroy your company. They want to work on things that matter, and they have ideas and the ability to deliver them.  Trust them…  give them the tools they need and the Guide-Rails_® to do it safely.