Meditations on Microsoft

So: After six and a half years as a full-time engineer, I left Microsoft.

I left to pursue life and career goals that didn’t fit well under the Microsoft umbrella. I missed and wanted to return to the world of startups and of self-directed effort. Which is to say, I think I left for the right reasons.

There was, however, a contributing factor — a “wrong” reason — that helped push me out the door. In my last year of employment, I harbored a vague suspicion that Microsoft was broken at a deep institutional level. Since leaving, I’ve encountered several “red flags” that help confirm my suspicion. These flags make the shareholder in me more than a twinge nervous.

From Where I Sat

Inside, Microsoft looks like bubbling chaos. There are endless new incubations attempting to breathe life into the next great idea. In theory, this isn’t such a bad organizational scheme. It’s inherently Darwinian: the best teams bubble the best products up to the top; everyone benefits.

The reality, however, is that few of these teams end up building marketplace-successful technology. The key to any Darwinian system is its fitness function. It seems that Microsoft never explicitly designed its own incubation incentives; rather, as the company grew, a set of incentives — the wrong ones — arose without conscious effort.

The Gorilla At Work

In order for Microsoft to pursue a new opportunity, it has to be large. Launching hundreds of $10M businesses or even a handful of $100M businesses is not interesting. To propose an incubation, executives and engineers must think big. They must shoot for the moon.

But it’s here that the institution’s incentives are very broken. Executives and their teams are rewarded for the pitch; they’re rewarded for a compelling mile-high description of their moonshot. Later on, they’re rewarded for providing demos that show they aren’t standing still. Teams are not, however, rewarded for quickly finding customers who need the technology. They’re not rewarded for explaining the pragmatic benefits of their technology; abstractions and generalized reasoning hold sway. Most importantly, teams are not rewarded for picking a small, tractable corner of their vision to pursue concretely and to completion.

As a result of these poorly designed incentives, Microsoft is full of incubations at sail with no port in sight. And it’s easy to see the outcome play out in the broader marketplace.

Who Builds For The Builders?

Speaking with startups in the Seattle area, I’ve noticed a recurring trend: when choosing tools, startups rarely look at the Microsoft platform. It’s not that startup engineers harbor a grudge. Rather, Microsoft simply isn’t on their radar screen. And if Microsoft does appear, it’s often as a blip in the distance — too vague an object to warrant careful attention.

There’s a deeper issue: the majority of startups I’ve spoken with have technical problems for which Microsoft is silent. Seattle startups need tools to help write embedded software, design and deploy distributed algorithms, and scale-out complex CRUD web sites. It turns out that open-source efforts like Hadoop and Squid, along with cloud computing platforms like [AWS](http://aws.amazon.com/ “Did you think I meant “American Welding Society”?”) and specialized hosts like Engine Yard, are the best games in town.

Microsoft loses out in a big way when it misses these key platform pieces. But no bulls-eye is no surprise given how its incentives are structured.

Sing The High Notes, Ignore The Low?

When and if customers finally do see the results of Microsoft’s labors, there is often a lot of head-scratching. At this year’s Professional Developers Conference, Microsoft unveiled two major initiatives: Windows Azure and Microsoft Oslo. Speaking with developers, my sense is that the value behind both of these launches could not have been less clear. This is tragic: there is some great technology lurking under the hood, if only it were easy to look.

Azure is a collection of all sorts of cloud-related ideas, only a few of which are likely to be important in practice. Trimming the fat wasn’t an option for the Azure team and so Microsoft’s potential customers have to wade through a pile of muck to find their diamonds. And there are diamonds to be found: the “web and worker” architecture, coupled with tight tool integration, potentially makes Azure the most appealing of the big three cloud services.

The Oslo initiative is similarly baffling. The Oslo team has thought deeply about how to represent and tool models. But there is scant evidence of pragmatic thinking about how models actually improve developers’ lives. As a result, Oslo allows developers to define models (in the sense of defining structures) but provides no runtime platform to access and manipulate them. Meanwhile, it’s simple to both define and manipulate models in platforms like Rails and Django. Once again, Oslo has some buried gems: parts of “M” are genuine game-changers for those in the business of designing languages and tools for languages. And “IntelliPad” is going to rock when it ships.

Even Gorillas Can Be Ignored

The upshot of all of this, I think, is that in many circumstances it’s simply easiest to ignore Microsoft. Wading through complex and poorly structured documentation takes time that startups are loathe to spend. Wading through poorly conceived and messily encumbered APIs takes longer and costs more.

Before I left Microsoft, there were encouraging signs that employees were aware of these problems. But changing institutional structure is not easy; there is too much at stake for employees under the current incentives.

I love my friends and colleagues from Microsoft. I had the opportunity to work with truly brilliant engineers, architects, communicators, and visionaries. I had the opportunity to work with lots of fun and energetic people. But in the end, I found fault with the institution we found ourselves in. I hope that Microsoft can see its way through these current problems and move onward to future greatness.