Translucency vs. Transparency Blog Post

April 27, 2008 – 4:51 pm

When long-time Windows chief Jim Allchin passed the Windows-development torch to Microsoft veteran Steven Sinofsky in late 2006, many things changed. One of the biggest was Microsoft’s policy on “transparency.”

Following a couple of service pack code and information leaks in July 2007, Sinofsky wrote a post on his internal blog explaining why he believed “translucency,” instead of “transparency,” is the best approach for his team and for customers. Because Sinofsky’s philosophy is so integral to how Microsoft 2.0 is attempting to operate, I decided to share it. This blog post was provided to me by a source, who asked not to be named.

7/9/2007
Transparency and disclosure
 
Transparent. Easily seen through or detected; obvious.
Translucent. easily understandable; lucid.
 
Today was a pretty exciting day for the folks working on servicing Windows Vista as there were a number of breathless stories about SP1 including dates and features. These stories caught us (management) by surprise since not only have we not announced any of the things in these stories, but much of what was reported was not or will not be the case. This is not a good situation to be in and I thought I’d offer some words on how we think of “transparency” relative to disclosure.
 
One topic I have been having an interesting time following has been the blogs and reports that speculate about how Windows will go from being an open or transparent product development team to being one that is “silent” or “locked down”. Much of this commentary seems to center around me personally, which is fine, but talks about how there is a Sinofsky-moratorium on disclosure. I think that means I owe it to the team to provide a view on what I do mean personally (and what I personally mean to do), of course I do so knowing that just by writing this down I run this risk of this leaking and then we’ll have a round of phone calls and PR management to do just with regards to “Sinofsky’s internal memo on disclosure”. But I thought it would be worth a try.
 
The most important thing I believe we owe our shareholders and customers relative to how and what we communicate is that whatever communicate to people be accurate and truthful relative to the work we have going on. This does not mean free from ability to change down the road. It does not mean silence until the very last minute. What it does mean is that we should recognize the potential impact our communications can have on customers, partners, and our industry and we should treat folks with great respect because when we do disclose what we’re working on people pay attention—and they do more than listen as they make plans, spend money, or otherwise want to count on what we have to say. When we have to change our plans, modify what has been said, or retract/restate things we not only look like we don’t have our act together, but we cause real (tangible) pain to customers and partners. One need look no further than the Longhorn/Vista product cycle and the cost to the PC ecosystem of us being out there talking broadly before we really were able to speak with the accuracy our customers and partners assumed. Plans were made. Plans were remade. And then finally people just decided to wait until we really delivered, with some folks not really believing us until the DVD was in their hands, which meant they were no on board with drivers, compatible applications, or the support their customers expected. That example is close at hand, but we can look at examples for Server 2008, ship dates that came and went for any number of products, or even recent examples with Windows Live. This is a challenge that spans all of Microsoft, not just Windows.
 
All of these challenges come about because there is a mismatch between expectations and reality—that mismatch or gap is the heart of customer dissatisfaction. What we can do is be thoughtful about planning and then just as thoughtful about how we communicate those plans. That is what we are doing.
 
Customers and partners want to know about SP1 for Vista. Actually they need to know. We want to tell them. But we want to do so when our plans and execution allow that communication to be relatively definitive. We are not there yet. So telling folks and then changing the plans causes many more challenges than readily apparent. While it might sound good on paper to be “transparent” and to give a wide open date range and a wide open list of release contents, we all know that these conversations with customers don’t end with the “we’ll ship by <x> date and we’ve prioritized <quality>”. Folks do want to know “did you fix this <example> bug?” That is reasonable, but we don’t have all those answers and thus we cannot have a reasonably consistent and reliable communication…yet. We are working towards that. While there is clearly a challenge in the near term in not offering details, this challenge is much less than if we get the wrong information out there and we have to reset and unset expectations. Even among our enterprise customers, for whom this type of information is routine, we have a long history of really scrambling these most valuable customers with “information” that turned out to be “misinformation”. The difference we are trying to highlight is the difference between transparency in what we’re “thinking” and transparency in what we’re “doing”. Everyone wants to know what we’re thinking, but making it clear that those are thoughts versus “doing” is a subtlety lost on a mass audience.
 
So our goal as an organization is to be much more thoughtful and considerate with what we disclose. Premature disclosure might make us feel like we were helping. Heck it might even make some customers and partners feel good, and some partners might even understand of the challenges we face in managing our projects. But on the whole it did not make Microsoft a good citizen of the ecosystem and it certainly did not make us good enterprise partners. Being thoughtful and considerate means we will be just as open and just as transparent about roadmaps and plans as we ever were (meaning the contents we disclose) but we are going to work to eliminate the premature disclosure that has low reliability and high error rates—we will have the right materials for enterprise customers, brief industry analysts, and work with partners all with valuable and timely information. Notice that these audiences are our customers and partners and that a non-goal is allowing the news cycle or needs of the press to drive disclosure timing and contents.

 
Just as we plan the software we will plan to disclose our work. It means that we will develop the messages (so expectations are correctly set), the supporting information (so all the details are there), and the overall communication plan (so we don’t leave anyone out). Product Management owns and drives this. In many ways this is their product deliverable. Just like we don’t want people running to demo a feature hot off a build machine, we don’t want to rush to disclose until we have these plans in place. Our PMG team is dedicated 100% of the time to communicating in a planful way this information to the Microsoft field, customers, partners, and the press. They are not perfect, but like all of us their strive to do their best, learn, and improve each turn of the crank. This is a key point which is that we are trying to be new and improved with respect to disclosure, and one thing we need to do is go out and make sure we set expectations on what new and improved means and how we will be working.
 
But our PMG team cannot do their job effectively if they end up in reactive mode. Stories like the ones about SP1 (or similar leaks about Live Services) make getting the word out pretty impossible. It puts us on the defensive. It confuses customers. It makes it so the message we want to get out there—the features we delivered, the quality of the work, the scenarios we enable, etc.—just doesn’t make it through the cacophony of chatter about the rumors, partial information, and other guesses. Of course we can’t be proactive about how we wish to be new and improved if we are always responding to these situations.
 
We also have ongoing disclosure with customers and partners of all types as we get their feedback and input about how we should evolve Windows. These discussions are about what we’re “thinking” and when done in a manner in which expectations are clear are super valuable and critical. We do this in a deliberate and constructive manner. These are dialogs. They are not press releases. We work with customers. We provide tools to the field that talk about what we do know about the next releases of our products. We train the field to deliver those messages. Is there enough detail relative to expectations? Never. That is a natural outcome of making sure what we do say meets our over-arching goal of being truthful and accurate in what we say.
 
Some folks think that it is a good idea to tip off the press or give a customer (even under “NDA”) early details of what they are certain we will be communicating in the future. Please don’t. This doesn’t help. It only feeds the frenzy and diverts attention from doing a good job. This is especially true when we burn “news cycles” responding. The ripple effect of the SP1 stories is immense—our PR team, OEM teams, enterprise sales, IHV relations, and on and on all spent the past 24 hours (yes these folks all are on call) scrambling to address the rumors. Ultimately, this means we spend less time planning how we will talk about and disclose the work we are doing. And ultimately it just causes problems for everyone. Even if one person, somewhere and for some reason, felt like it was the right thing to do by disclosing what they believed to be the case.
 
All I’m asking folks to do is think before they disclose—in person, in blogs, over the phone. Our product management team owns disclosure and owns communicating with the world the work we are doing. They take this work seriously. They have a very strong desire to tell people about what we do—it is their job. They want to do this well and that takes discipline from everyone involved. Please help.
 
I know many folks think that this type of corporate “clamp down” on disclosure is “old school” and that in the age of corporate transparency we should be open all the time. Corporations are not really transparent. Corporations are translucent. All organizations have things that are visible and things that are not. Saying we want to be transparent overstates what we should or can do practically—we will share our plans in a thoughtful and constructive manner.
 
The upside of being deliberate is that we hope to exceed expectations with what we do. That is not to say that if we are silent people will expect nothing so anything we deliver is great. Rather since we will be talking all along about what we do (in a planned manner) when we show off the software it comes to intrigue and excite people because it does what we said it would, but it does so in an elegant and thoughtful manner, and that it really does what we said it would do, and it does so spectacularly well. We are different than some companies in our industry because our success is dependent and intertwined with that of thousands of other companies. We take that extraordinarily seriously and thus our communication is designed to take that into account by sharing actionable, accurate, truthful, and complete information in a timely manner—timely means that there is time to act and if acted upon the results are what we collectively hope to achieve.
 
–Steve