I'm coming, I'm coming…

Innovation trumps rules and procedures.

What does that mean to you?

I saw this statement scrawled in chalk on an inspiration board at FastCo’s 2016 Innovation Festival and it’s resonated with me ever since.

How often do you hear in meetings at your organization that you are “lean/fast/agile”, or “it’s okay to fail”, or “move fast and break things”, or any other number of memes or buzz phrases that are supposed to inspire and make you feel like you’re actually allowed to experiment in helping get your organization to the next level?

Probably too often. Especially when you attempt to “move fast and break… something”  and you’re met with… “Well that wasn’t in the brief”, or “you really need to run that by *insert person/committee here*”, or “that’s not on brand”, or any other number of soul crushing, innovation stifling phrases that are supposed to bring us back into the overly operationalized infrastructure that so many large-scale organizations were built on.

Now coming from someone who spent a third of his career in marketing, a third in design and development, and a third in operations – I’m a paradox. I understand the need for process and procedures to protect the ever-precious resources known as producers, designers, developers and dollars. However – the marketer in me wants to get things out fast so I can analyze the success or failure of something. And the designer/developer (big paradox) in me wants to make really cool shit.

I’ve been fortunate enough to have worked for some organizations that make this a reality – kind of. While there were always some guard rails in place, we were able to put really scrappy stuff together and test our ideas. Whether it was sketching something on paper and sharing it with our colleagues or coding a medium fidelity something in a sandbox to see what’s possible – we were given a safe place to do so.

If you find yourself in a situation where the organization is doing the “we’re fast and agile” double talk here are some tips that I’ve found worked for me in my overly inspired state of wanting to experiment.

Talk to your boss first

Yes – this defeats the entire purpose of experimentation, failing forward, buzz, buzz, buzz – BUT, you need a coach and cheerleader. And who better than the person that is there to support you the most (sorry honey). Share your idea and plan with them. An example of this conversation could be something like:

You: “Hi boss, I had a great idea that I wanted to share with some folks on the team. I was going to crack open MS Paint and throw some boxes on the screen and see what folks think.”

Boss: “Awesome, I can’t wait to see it!”

That’s it.

Fellow leaders out there – you owe it to your associates development to support them on this – and while they may be heading on a crazy train, just make sure they stay on the tracks.

Make it

Okay, your boss has your back. Check.

Now get cracking on your experiment. Depending on the fidelity of what you’re trying to accomplish there are different approaches you can take. If it’s something that is truly a gut check, maybe it is just a sketch (and when I say sketch I literally mean pen and paper). If it’s a functional thing and you have the capabilities, code it up. The whole point is to keep it simple – remember that term MVP (minimum viable product)? This is your version of the minimum viable product.

Share it

Get feedback. That’s the whole point right. Whether it’s feedback from internal partners or external (tread cautiously with that one – and do make sure you get the right permissions before taking something outside your doors).

It’s important to note though, and you’ll want to use this language when you share it with those who may be offended that you jumped into their swim lane – THIS IS NOT INTENDED TO BE PRESUMED AS FINAL CREATIVE OR FUNCTIONAL DIRECTION: THIS IS A TEST, IT IS ONLY A TEST. BECAUSE WE ARE FAST/AGILE/LEAN, MOVING FAST AND BREAKING THINGS AND FAILING FORWARD.

You can just copy and paste that and pop it into your emails. You’re welcome.

Learn

Okay you got feedback. Were you able to prove out your hypothesis? Was it disproved? Are you going to pivot or persevere? If it’s a success, take it to the next level and put it in process (because you know you’re not going to escape that). If it’s a failure, maybe you make this your 10% project and improve it.

You’ve heard this a hundred times from just as many different leaders but good ideas DO come from everywhere and everyone. Good ideas also get lost in the shuffle of over engineered process and rules. It’s important for us to get our peers, colleagues and leaders on board with the concept of experimentation and doing that outside of the normal process.

If it makes people comfortable – make up a low-fi process that that gives the banner of latitude to the experimentation, with a nod to the operational processes – just a nod. One or two guardrails or checkpoints. And it has to be a nod simply because rules and process are the killers of innovation. Innovation MUST trump them if you’re really to succeed.

To wrap up, (and this may now sound like double talk from me) I would recommend this approach only for smaller scale things, maybe an internal process improvement or an “internal eyes only” improvement to one of your products. Anything that goes to a portion of your customer base would want to follow similar steps, but amplified – i.e., engaging your product and development teams to create a MVP to prove or disprove your hypothesis.

Otherwise – the force of bureaucracy will come tumbling upon you. You have been warned.

Now go. Come up with an idea. Fail. Learn. But most importantly… keep repeating.

 

Leave a Reply

%d bloggers like this: