A few days ago I mentioned that I had been receiving a lot of inquiries about developing an innovation capability, cultural development, and why this matters to avoid systemic failure. My post touched upon feedback as the shortest path to innovation and how people need it to learn.
This is the essence of agility, the ability to move quicker, learn faster, understand what works and doesn’t, and shift direction if needed. In the world that big organizations live in, agility is not business as usual. Rather, life inside a large organizations feels like you are going backwards, not forward.
Inside large organization’s, the common obstacle innovator’s have to overcome to get traction is getting permission to innovate. Of course, in a perfect world innovation shouldn’t require permission, but we don’t live in that perfect world. So, most of the time, permission won’t be granted.
Innovation is killed with the two deadliest words in business: Prove it.
For example, here is an email from a person responding to a recent blog post by Brad Feld about agility:
It reminds me of my current project at my day job. The back end infrastructure that handles all the Internet connectivity and services for a world-wide distributed technology that was built by a team of 150 engineers overseas. The infrastructure is extremely unreliable and since there’s no good auditability of the services, no one can say for sure, but estimates vary from a 5% to 25% failure rate of all jobs through the system. For three years management has been trying to fix the problem, and the fix is always “just around the corner.” It’s broken at every level, from the week-long deployment processes, the 50% failure rate for deploys, and the inability to scale the service.
I’ve been arguing for years to rebuild it from scratch using modern processes (agile), modern architecture (decoupled web services), and modern technology (Rails), and everyone has said, “It’s impossible and it’ll cost too much.”
I finally convinced my manager to give me and one other engineer two months to work on a re-architecture effort in secret, even though our group has nothing to do with the actual web services.
Starting from basic use cases, we architected a new, decoupled system from scratch, and chose one component to implement from scratch. It corresponds roughly to 1/6 of the existing system.
In two months we were able to build a new service that:
- scales to 3x the load with 1/4 the servers
- operates at seven 9s reliability
- deploys in 30 seconds
- was implemented with 2 engineers compared to an estimated 25 for the old system
Suddenly the impossible is not just possible, it’s the best path forward. We have management buy-in, and they want to do the same for the rest of the services.
But no amount of talking would have convinced them after three years of being entrenched in the same old ways of doing things. We just had to go build it to prove our point.
Sound familiar? Could the same situation, dismissing key issues that enable progress, be happening inside your organization? You bet!
Better to ask for forgiveness than ask for permission
It is fairly simple to anticipate, and predict, what “non-innovative” behaviors look like. The situation that is explained in the above email is quite common, both in what it is about (technology) and how it is perceived (costly). Heck, there are lists all over the web of x reasons why you can’t innovate: following the old rules, while not identifying when they’ve reached their expiration date, and dismissing the new is one of them.
The situation above is one that innovative companies deliberately try to avoid by giving people permission to experiment. And, the way employees prove their hypotheses is by coming back with data, both quantitative and qualitative, about their findings. And it is done very fast. As I wrote last week, feedback is the shortest path to innovation.
A company that does this well, and shows what a culture of innovation looks like, is Intuit.
So, want to innovate? Don’t wait for permission. Better yet, it shouldn’t be necessary to ask for permission or forgiveness. Let’s aim for that!
P.s. You can take the situation above and add it to your “what not to do” list of examples of non-innovative behaviors.
