It’s always easier to say sorry than to ask for permission

The video from NASA referenced in a post from yesterday illustrates many of the difficulties in attempting to be innovative within any largish type of organisation.

I was talking with a colleague today about this and other associated problems and his question is “But what are the solutions, the alternatives?”. As a cynical bastard who has a long history of forever pointing out the flaws in various organisational practices (there really is no challenge in doing this), a common response from those nasty folk in power has been – “But what are the solutions?”.

These folk really started getting annoyed, just like those in the video, when I started actually outlining solutions. So annoyed that you knew you would never actually be able to do anything.

So, what’s the solution?

The solution

Talk about coincidence, the 37Signals blog has just had a post published that outlines the solution I’ve used in the past. They call it “going rouge”. My explanation was “it’s always easier to say sorry than to ask for permission”. i.e. do it and apologise later, don’t ask.

There are some problems with this approach, including:

• You can become a “pariah”.
  The negative connotations that arise form this approach can be seen in the words used to describe it. For example, “rogue” in the 37Signals post or “shadow systems” when it comes to IT systems.
• You don’t get the resources or access you may need.
  In some cases you actually need resources or access to materials/information in order to do something innovative/effective. If you’re a “rogue” you won’t get that access. iStandford would never have happened without some folk within Stanford helping out the “rogues”.
• Folk may never ever get it.
  If you’re approach is so different, folk may never understand it. Even if you show some early results, in the long run the established perspectives will rule. Especially because of the next point.
• The quality might not be up to it.
  A lot of what I did with “rogue” e-learning systems wasn’t seen as innovative because it didn’t look pretty (because I’m not an interface/graphic designer). People couldn’t see beyond the surface to see the idea. The lack of quality limited the ability to demonstrate results. The quality was limited because I had to go rogue and couldn’t get access to resources – like a good interface/graphic designer.