Tuesday, Sep 15, 2009, 1:48 PM in The Spout
The Downside of Transparency
Ever since Chris Anderson built his blogging software and shared it with his colleagues, more and more Microsoft employees has been pushing hard on being as transparent to our customers as we can be. This has been a very much grass roots effort. I remember coming into Microsoft six years ago just when legal was busy giving everyone disclaimers to put on their personal blogs and telling us what we could and could not say. It was always a worry whether the next blog post would get you fired. I got in trouble personally several times, but the brave pioneers before me laid the groundwork for people like me to comment on the internals of Microsoft culture, for Robert Scoble to call Steve Balmer out onto the carpet several times and for Rory Blyth to talk about penises, all on the Microsoft dime. Now blogging is just an accepted way to do things. It's not even questioned anymore; it's expected.
And by and large, this transparency is good for reasons that are obvious these days -- when our customers see how the sausage is made and have a say in the ingredients, they're happier eating it with their breakfasts.
As with all good things, however, these is a downside. For example, the product I've been working on for 4.5 years has gone through many transformations. This has to do with how new software is designed at Microsoft.
The tag line when we're hiring folks is always, "Don't you want to change the world?!" Of course, everyone does and that's good, because people coming in the door want to take big risks and do big things. If you're trying for the next Office or Windows, that's the kind of thinking you need. However, what that means is that we have a lot of folks building 1.0 software. We do this in my division with an organizational structure called an "incubation."
My product was in incubation mode for years and we started with zero assumptions. My first day on the job, I was asked to "think about synchronization." What did that mean? What problem was I trying to solve? Does replication count as synchronization? Does data import? I struggled with this for months before I got my head around the process of noodling with a technology enough to understand what problems there were in the space and how that fit with our general idea of what we might want to build into a product.
We tried a huge amount of stuff, often rebuilding shipping technologies to which we had ready source code access just so we could get a feel for how it worked (I personally built multiple data synchronization engines, a WPF-compatible XAML parser, a data binding engine and a set of universal data viewers during that period, all of which were thrown away, as expected).
As we got further along, we started producing things that needed to be published, even if they weren't a core part of our product anymore (like MEF and some new features in XAML 4.0). Once this started happening, we started to feel like we had a handle on what we were doing to move into "startup" mode, where we formed a team to make productization plans. At this point, we started telling folks what we thought we had, including analysts and "insider" customers, getting their feedback. Based on this feedback, we re-jiggered the product and the story and did it again. And again.
Eventually, we move out of startup mode to become a real product team with dev, test, PM and UA splits (up 'til then everyone does everything or, as we liked to say, "everyone shovels"). Eventually in this mode, you publish some set of bits that are your best guess at the time of what we think we're eventually going to ship. In our case, it was the October 2008 "Oslo" SDK CTP, guaranteed only to take up space on your hard drive. At the time, we'd been telling the "Oslo" story for more than a year and it had evolved a great deal. Since we published that initial CTP, we've published a few more, along with an entire web site filled with articles, videos, specifications, samples, etc.
I mean, we did it big. We were part of the keynote at the 2008 PDC and we had lots of folks on our team that are very visible in the community, including Don Box, Chris Anderson and Doug Purdy. These are the heavy hitters, so when they said something, folks listened.
And we definitely got a lot of community involvement -- way more than we expected, in fact. With that involvement, we got a ton of feedback, which is the benefit to us of releasing early and often. We take that feedback and we make changes to our product -- sometimes big changes. In this particular case, we were building on all kinds of SQL Server-related technologies, so because of pressure to build the absolute best thing we possibly could for our customers, we actually merged the division that owned "Oslo" (and WF, AD, WCF, BizTalk, etc) with the SQL Server division.
Of course, those are the kinds of changes that our customers don't see. What they see is that things are changing and that they're not quite sure what our plans are. That's one big downside:
When you share early information, sometimes it's half-baked, it often changes and is almost always confusing.
As an example, Jeremy Miller recently had this to say about "Oslo" and our communication about it's purpose in life. Believe it or not, this is helpful feedback and it's my team's responsibility to understand what exactly is holding folks up and get it fixed in the way we tell the story and in the product itself.
Another part of my team's responsibility, of course, is communicating what it is the product does so that folks can understand it and give us feedback. That means that the first people that know how confusing a product is are the folks writing the documentation and tutorials, building the videos and producing the samples. And believe me, we act as customers on the team as well, logging bugs and making complaints and bugging the developers and PMs directly, hoping to fix everything before customers even see it. Of course, we can't do that all the time (or even most of the time), so often:
We produce materials that tell the story in the very best way we know how with the current set of bits.
Kraig's recent "Oslo" blog post is an example of this. This is an important part of the process, too, actually. We, as Microsoft employees, can complain to the folks producing the software 'til we're blue in the face, but often real changes aren't made 'til real customers complain. As a consequence of this:
We take the slings and arrows of our customers and thank them for taking the time to shoot us.
This one can really hurt, actually. I'm a professional, but I take it personally when I say something that doesn't resonate with my audience (at a recent conference, I threw away an entire completed slide deck and started over only days before the deadline so I could tell a better story) and the audience takes it personally when I show them something that they don't understand.
In fact, everyone in marketing, DPE, UA and every part of the team that interacts with customers directly or via the software we're producing, including the devs and test engineers, all take it personally. We care deeply about building products that delight and empower our customers, which is why we push so hard on transparency from the bottom -- the sooner we hear your complaints, no matter how confusing we might be, the better able we are to build something you love.
I'll tell you though, if we could build something you'd love without giving you an early look, we might want to do that because:
When a customer is confused or disappointed by an early look at a product, they might not want to look at it again for a really long time, if at all.
Early looks are a double-edged sword. We want the early feedback to make our product better, but if you don't come to look at it again, you'll never know we made it better.
Still, transparency is absolutely worth the downsides. Keeps those cards and letters comin'! : )
If not, isn't it time to rename the "SQL Server Division"?
Tuesday, Sep 15, 2009, 2:49 PM
As far as the latest and greatest about "Oslo," I recommend the DevCenter (http://msdn.com/oslo) for the current public story and the PDC (http://microsoftpdc.com/) for what I think will be much more clear and compelling.
Tuesday, Sep 15, 2009, 3:08 PM
I am afraid I am in danger of falling into this bucket. I am an early experimenter (if not always an early adopter), and when I saw that there were a number of sessions at last year's PDC on a technology I had never heard of, I decided I should at least take a look. Since then I have watched all of the Oslo PDC videos, I have read a dozen or two blog posts about Oslo, I have downloaded the Oslo CTP and played with Quadrant and the sample app, and the only thing I can say with confidence is this: if there is a point to Oslo, I don't see it.
Everyone likes to talk about what Oslo is ("Oslo is three things..."). But no one wants to talk about what Oslo DOES. Every time I ask that question, I get either another rendition of the three things, or an abstract discussion about modeling. Not one single person so far has been able to describe the concrete benefit that I will gain as a developer of LOB apps at a medium-sized financial institution.
I get that its early. I get that Microsoft is still figuring out how they want to position Oslo. I get that the concepts in Oslo may never coalesce into their own product, but may be incorporated into other products instead. Here's what I don't get:
1) If Microsoft is dedicating so much of the time and effort of some its top developers to this, shouldn't there be a reason for that? Aren't they expecting to see some kind of return on that investment?
2) Since Microsoft is in the business of developing software, and software by its definition allows users to do things more easily or do things they couldn't do otherwise, doesn't the return on investment in Oslo have to ultimately be a benefit to Microsoft's users, either directly or indirectly?
3) If Microsoft is expecting a return on their investment, and that investment must come in the form of benefit to users, shouldn't someone at Microsoft be able to articulate that expected benefit to those users?
DevDiv's trend toward transparency has been great, and I wouldn't want to discourage that. I would argue, though, that transparency as not an end unto itself. Rather, it is a means to getting user feedback and evolving a product that will better suit users' needs. If you cannot articulate why users should pay attention, and more importantly why users like me - who WANT to be involved - should spend their valuable time evaluating an unfinished and unstable product so that you can get their feedback, then I would argue that transparency doesn't really serve much of a purpose.
Thursday, Sep 17, 2009, 8:50 AM
I remember having a meeting with the VS Program manager around 2000 on the threat of Open Source to the MS business model. I was listened to, and then ignored. AND that is the problem with Microsoft.
Microsoft is filled with smart people, but they don't actually listen and solve problems these days. I know that in your daily work you are thinking that you are solving problems, but you are not. What you do is listen and process to how Microsoft wants to see the world.
Case in point the double courier tablet. Looks great, but so has every other product for the past 8 years. Then it comes to market and it turns into crap. While many like Windows 7, and I do use it, it is not that great. It's ok.
Case in point netbooks. I just bought my first one, and it was OS-less, though there were install CD's. I decided to be adventurous and installed Ubuntu Netbook Remix. Absolutely incredible! No way that Windows is going on that machine. What Ubuntu did is create a distro for the netbook. It works very well. My question is why is Microsoft not doing that? Why is Microsoft with their operating systems giving me an unusable OS on a smaller device?
Why is Microsoft discouraging internal employees to get iPhones? I know from a local Microsoft rep in Europe he said word word, "oh I would love to have that gadget, but we are supposed to have Windows Mobile."
Fix that problem, and then you will fix Microsoft...
Thursday, Sep 24, 2009, 2:56 AM