Knowledge is power – and power is a limited resource.  At least, that’s what some folks believe as they obsessively guard information from others.

That’s a load of tripe.  It creates a work environment so fundamentally backwards: employees direct their efforts toward breaking into the cliques, cabals, and secret societies just to get their jobs done – leaving no time for more important things (like customers.)

There are plenty of examples of this inside of Microsoft.  Rather than give a bad example of information hoarding, let me instead give a powerful example of transparency – the folks behind the Windows Live Mail team.

I had a friend (also a Windows Live Mail customer) mail me yesterday in desperation.  He’d been struggling with an issue in his mail account, and contact with official support channels proved fruitless.  They told him it was a known bug, and would be fixed in the future.  He asked me if I could provide any additional information.

Traditionally, this would result in me contacting a blogger from the product, or sending a mail to their internal discussion alias (if they have one.)  That’s good, but you’re still taxing the resources of the product team.  Self-serve is better.

My first stop was the internal site that lets us search bugs.  Most products publish their bug databases to this site, although many refrain.  So, first tally for transparency – publishing your bugs.  I found a few related to the issue – one with the comment, “this has been turned into a feature, and will be tracked for <milestone x>.”  It included a (broken :)) link to the internal Windows Live Mail SharePoint feature tracking site.

Normally, this would be pretty much the end of the road.  I could contact the last person that made comments in the bug and ask them the question.  That’s good, but you’re still taxing the resources of the product team.  Self-serve is better.

Instead, I was able to go to the feature tracking site and look at what they listed for <milestone x>.  Second tally for transparency: publishing your work items.  I found the work item, and was able to open its full details.  They included the development and PM contacts, and also allowed me to verify that this was the same issue I was looking for.  However, I had no idea when <milestone x> would be live.

Next, I looked at their published master calendar on the same Sharepoint site.  Third tally for transparency: publishing your schedule.  It lists all of the milestone dates, code complete dates, integration dates, release to operations, release to web (live site,) and more.  I simply searched for <milestone x>, and found its release date (which happens to be soon).

So, my final email to the contacts listed in the feature details?

Hi <PM> and <Dev>;

I’ve got a friend who is … eagerly looking forward to this feature – “<Feature>".  From <feature tracking site>, it looks like the feature is scheduled to ship with <milestone x>. 

From <ship calendar site>, it looks like <milestone x> code goes live on <date>.  Did the feature make it into <milestone x>?

The answer was “yes.” I was able to do nearly all of the groundwork required to become an ambassador for an entirely different team.  Rather than jealously guard the information, the team created value from thin air.  Kudos to the Windows Live Mail team for being so progressive.