Question: How Do You Avoid Adopting a Microsoft Culture?

This morning I had an informal discussion with a candidate who’s thinking about leaving Microsoft and joining a startup. He asked the question “How do you avoid adopting a Microsoft culture?” In hindsight, the basis for his question makes a lot of sense. I left Microsoft to start blist. Our website and many of my introductory emails to prospective candidates includes a statement that says something to the effect that “our engineers are mostly ex-Microsoft and ex-Amazon.” He also recognized that one of our board members is from Microsoft. So it’s understandable that he would think we’d have a Microsoft culture.

In that he has that question, maybe others do too. So here’s my answer, for the benefit of anyone and everyone who reads this post.

blist doesn’t feel anything like Microsoft. I only spent a year there and one of the reasons I was anxious to leave was so that Microsoft didn’t change me too much. We are conscientious about not introducing unnecessary layers of management or bureaucracy. Our first employee, a software engineer, celebrated his first year anniversary with blist recently and commented that it was the best year of his career, in large part because of the pace, energy and lack of meetings and bureaucracy. We have no program managers (yet). We have no SDETs (yet). Those roles won’t be vacant forever, but now is the wrong time for them at blist. Soon we’ll add a couple more engineers, and at that point one single, solitary program manager makes sense. I’m not opposed to program managers or SDETs, but the ratio needs to be something like 6:1:1 not 3:2:2 like at Microsoft.

At Microsoft, teams are built top down. I prefer bottoms up.

Unfortunately, the power of political persuasion is necessary to succeed at Microsoft. At blist we value ideas, not politics. A good idea will get done. A bad idea won’t. If someone suggests a bad idea and we discover that in discussion, there’s no animosity or negativity. If someone suggests a good idea, he or she didn’t win - the idea did. We’re democratic, but it’s not a democracy. By that I mean we discuss big ideas but not the little ones. One of the benefits of having smart people is they usually figure out the right thing to do, including knocking down the the little issues and surfacing the big ones.

We don’t have very many meetings at blist. The only recurring ones are our sprint kickoffs and recaps. Other than that, meetings are usually spontaneous and don’t usually take place in a conference room. We usually just talk through an issue in real time. If you need help with something, wouldn’t you rather have immediate help instead of scheduling it for next Wednesday at 3:00? By the way, we never schedule meetings around people’s schedules. If you’re here when we meet, feel free to join, but if not, that’s OK too. We’ve never had a mandatory meeting. If the topic interests you, attend. If it doesn’t or you can’t add value, don’t attend. The result of this is that meetings tend to be quick and engaging. No one checks email on their iPhone. People don’t bring their laptops. It’s a discussion. Almost always something gets decided and you leave the meeting feeling like something was accomplished.

Our development approach is a blend of what you’d find in a startup and what you’d see at Microsoft. We do week long scrum sprints that are very agile, nimble and quick paced. We apply some self imposed rigor and discipline around our engineering practices. For example, you can’t check code into subversion without a formal code review. Those reviews aren’t cursory. They’re in depth. Good questions are asked. Algorithms are scrutinized. Teamwork emerges. I walk through the front door of our office 3 or 4 times a day and almost always I see a code review taking place, with two engineers sitting side by side, one pointing at the monitor, walking the other through the code. It’s refreshing to see. Physically our environment is communal. Sorry Joel (on Software), we prefer to work in an open area where we can communicate and collaborate freely; we don’t want enclosed offices at this stage in our life cycle.

Finally, two words are entrenched in our culture differentiate us substantially from Microsoft: proximity and diversity. The former - proximity - has to do with how close we want to be to our users. We want that proximity - to hear directly from people using our software about what’s working and what isn’t. The latter - diversity - is about how we define our roles. We like broad diversity in what we work on. Everyone wears a lot of hats. We’re all entrepreneurs. We aren’t constrained by the title on our business cards.

So if any of you have shied away from blist for fear its culture would feel like a mini-Microsoft, fear not.

Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages.
  • Digg
  • Sphinn
  • del.icio.us
  • Facebook
  • Mixx
  • Google
/

One Response to “ Question: How Do You Avoid Adopting a Microsoft Culture? ”

I am sympathetic. I’ve done several deals with Microsoft on the other side and I am always flummoxed by the paralyzing levels of bureaucracy and paranoia. Makes me understand every Vista crash, though.


Something to say?