It’s a Problem of Transparency

For being here only a bit more than three years I’ve had the opportunity to wear several different hats at work.  Though officially always in the QA org I’ve had a good number of opportunities to do development (aside from developing QA tools), product design, and most recently work that involved encouraging our team to interact more with customers.  I love all my jobs, but the latter has been most intriguing of late because of the challenges it presents.  Officially titled I’m now the “Community Manager” for the Visual Studio organization in addition to my day job “Software Development in Testing Lead”.  I only get one paycheck, but do need a new business card… one that is long enough to carry on the pretense. J

 

My job, as the Community Manager, is to be involved in the planning and management of how this large team participates in the developer community.  Getting only slightly more specific it means “Influence the community experience to be the best compared to our competitors including making it valuable, sustainable and fun!” in addition to “Guide transparency to make us more open as a company and a division blurring the lines between community and internal processes.”  IMO the transparency part could be the trickiest, yet more rewarding one.

 

It’s been impossible for anyone to draw a meaningful line where transparency crosses from good to bad.  As an extreme example bad could be someone blogging our confidential release dates, product roadmaps, un-released source code, etc.  I’ve recently spent a lot of time contemplating my blog and the blogs of several other Microsoft employees to see, since there is no concrete guidance, where the self imposed line is.  I learned that everyone has what, in effect, reflects very different views of where this line is.  The blogs I saw ranged from what amount to complete unreleased product specs posted for feedback and snippets of product source all the way to the mundane topics that probably should have been included in documentation for products that have been out for years.  Indeed, advice has been given tantamount to “Use common sense”.  Unfortunately these senses are not always common.  There isn’t a line and if there was, it’s already been crossed and will continue to be trampled upon.

 

This is a simple fact we are just going to adjust to as a company if we want to reap the benefits of giving Microsoft a real face (or thousands of faces) behind the products we make.  I’ve seen countless examples of customers who are thrilled with transparency we have started to show.  The side effect of encouraging employees to be open and honest while at the same time asking them to do the best they can to help and have quality conversations with customers on a regular basis is that “proprietary” information and intellectual property will be exposed.  Sometimes this could be for the best.  Let’s pretend that there is a code sample numerous customers have been asking for that could help improve computer usage for people with vision impairments, but at the same time exposing the code in this sample would risk giving away information about a process you may have wished to file a patent on.  What would you do?  There are several of different answers and outcomes that would result when the choice lands in the hands of any one amongst thousands of employees.

 

There is a lot more I could post on with regard to this topic, but I thought it was a good introduction to some of the things I’ll be posting here in the future.  Since I still have my job as an SDET, I’ll continue to make my testing related posts, but I’ll also be posting about some of the exciting ideas on how Visual Studio/Microsoft can be more transparent and more effectively work with and help customers umm… “realize their potential”. 

 

It’s cheesy, true, but at the same time so tempting to use about everything.  For example: “Today I’m going to help the VS Task List realize it’s potential” or “I must help my dog realize his full potential and teach him more tricks”.