Visibility : Proof of Concept or Request
My posts of late have been on the DIY meme, which is possible now that we have enabling social tools. These grassroots tools empower you to achieve part of your vision, and hopefully your visibility will lead to others helping you finalise it.
I’m hoping that my current project I’m tinkering on will be an example of this concept. I’m not building it using social tools, but I will spread the word using social tools.
I figure you get more participation with some good design thinking. That’s why my vision is for a browserless desktop app that streams latest content from our CoPs and allows you post to the CoP eg. something like Tweetdeck.
Now I’m not a techie person, I have limited skills…but my limited skills will get me further than trying to get something approved and developed. This idea would not be seen as important, but hopefully it will be once people are hooked on a Proof of Concept version.
I have made a HTA file on my desktop that opens a little pop-up box. It lists all the blogs, forums and wikis that I regularly use, and even has links to the post entry form for each object.
This is so much better than opening a browser and using my Favourites, and better than a desktop folder with lots of shortcuts. My little app is nicely presented as a list with some fancy javascript accordion features, and a window that rolls-up. BTW - I don’t understand how it works, I just found stuff on the net and chunked it together and tested and tweaked it till it worked.
I can share this file so others can use it. Even better I have the contents of the file in an iFrame the refers to a HTML page on our server. This way I can write new versions and not have to re-issue people new files.
Anyway, so far so good.
But what I really want is to be able to publish content to the CoP from inside the app (which I can already do if the links open within the app, but this is not ideal). I also want to see streamed content. And it would be good if my app could be turned into a generic form so people can easily make their own apps without needing to know any programming.
At the least I hope to see a cosmetic change…since I have taken away the border and the title bar you cannot drag the HTA window, so I’m hoping someone knows how to make my HTA file a window you can drag.
Anyway, my Proof of Concept will be posted in our communities.
Hopefully someone will see it, and get good use out of it, another may know programming and re-mix it to work better, another person may want to rebuild it using MS Silverlight or Adobe Air…who knows.
If it really caught on and people did not want to be without it, it might get some resources thrown at it…all thanks to Proof of Concept and the visibility of Grassroot social tools.
This example is about using social tools to get your invention visible, but further to this the invention itself may be built using the social tools…this is now all possible!!
Glass half-full
To achieve your vision you may not have everything and everyone at your disposal. But that’s OK, just use what you have at your disposal. The important part is having the grassroot tools to enable you to make your thoughts visible.
In a past post I mentioned that our Communities of Practice were originally for people in different teams or even the same teams that had like interests. eg. people from 5 different teams and offices may be experts in "Flash programming", so they set up a group space to benefit from each other.
But since these tools are so flexible we had CoPs being used for unexpected use cases, like initiative task forces, support sites, office website, task rooms, etc…
Our CoPs surfaced all these needs people have that are beyond CoPs. It teased out needs like our official support database needs to be less rigid as some teams are using a CoP instead, business unit spaces need to have social tools as BU’s are using CoPs instead of the official space, etc…
So in a certain light our CoPs have become a "Proof of Concept" for surfacing other unmet needs.
Rather than a team complaining and requesting about a better support database or better business unit spaces, they just used what they had at their disposal to achieve their needs…we are great self-organisers. This is the true essence of grassroot tools.
Due to our CoP tools, and our organic process of creating them we are able to indirectly use them as Proof of Concepts. Perhaps now the official support database may look into a crowdsourcing feature, perhaps business unit areas will have a homepage rather than just a bunch of folders…or perhaps they are happy to stay with what the CoP offers them.
People could of talked about these needs forever, and management may even agree with this need…but things go on the backburner…you have to wait for requests to go through the right channels..approvals…charters…money.
The answer is use whatever tool you have, and rather than talk the talk, walk the walk with a Proof of Concept.
There’s a difference in hearing and discussing something compared to actually using a prototype and getting that "feeling" from using it…it has a more profound effect as it’s experiential.
Summary
You have the idea, and talking gets you nowhere, so you use some grassroot tools (thank-you web 2.0) as a Proof of Concept, and this visibility gets you noticed. People you don’t know see it, and think it’s a good idea, someone else with a similar use case may apply it to a different context, a viral effect may ensue where lots of different groups are using it and improving it, someone else high up in the chain may come across it and may say why isn’t this made official.
You get the idea…visibility is king, and grassroot tools help you get there.
Not only do these social tools help you get there because they bypass the hierarchy, and it’s information flows and approvals (basically your Proof of Concept can go viral and touch lots of people…you no longer need authority as you have influence by reputation…you are networked.) But the actual tools getting you connected, can be the same tools that your Proof of Concept are based on.
In my last post I mentioned some teams have noticed our wiki tool and are self-organising a way to do onboarding. Not high-level onboarding, but at the level of what new comers need to know about working in that business unit. They are not going to wait for an official way, or approval to do it their requested way…instead they are using the tools at hand and going with it. Maybe the idea is to get in trouble, but when you get in trouble they might decide that they like your prototype and give you resources to do it properly.
Get visible, get in trouble (well, be cheeky), get a proof of concept, get social tools.
This goes hand in hand with a culture of autonomy, experimentation and acceptance of failure as the road to better productivity and performance…and innovation.













