Stuff I’ve learned at Microsoft

Coming up on five years (and many teams) at Microsoft, there are a few things I’ve picked up along the way that I definitely didn’t know about when I left college. Call them core values, things I’ve learned, lessons learned, things I scream at my friends to do more of, whatever – they’ve served me well.

Some of these are Microsoft-specific but most will apply to any team/corporate environment. Some of these are tricky – they can get you fired (or worse) if you don’t know what you’re doing.

Ask for forgiveness, not for permission

Any sufficiently large institution has something to lose. Credibility, money, power, you name it. Ergo, any request for something new and risky is met with caution. Be it a new proposal or a new project, it is safer to say ‘No’. Corporate systems are optimized for saying no. Maintain the status quo. No risk of failure and a spectacular blowout.

This is exactly why you are better off going ahead and doing something without asking first. If you don’t ask, no one can tell you to not do it. Have an interesting idea for a side project? Go code it up. If you ask someone first, you’ll probably get told “Go consult with team X,Y and VP Z” and face an endless spiral. Want to write a blog post on something you care about? Go do it.

Obviously, you need to know what you’re doing. Don’t do something obviously stupid. Making a post about unannounced feature X? Bad idea. Checking in code without telling anyone? Very bad idea. Sending an angry flame mail to the wrong VP? Depends (but typically not a bad idea). Like with any risk, there are downsides.

This won’t work all the time. You will fail, sometimes spectacularly. That is OK (see next heading for why). In fact, if you don’t make a complete ass of yourself from time to time, you’re probably doing something wrong.

Corollary: If other people are going to be impacted by you failing, you need to tell them first.

(Most) Screw ups are OK

So you did fail and made a fool of yourself. Maybe got screamed at by an executive. Your demo failed spectacularly in front of thousands of people. Your code change brought down the website.

Turns out that this is OK. Though it may not feel like it at the time, in fact, it is to be expected. If you’re not failing, you’re not trying hard enough. I get very annoyed when someone gets worked up over the small stuff. What are the odds that this will matter five years from now? Typically very low.

The biggest danger with getting worked up over the small screw-ups? Making people cautious. If your employees are afraid to break things, they’re going to stick to what they know. No one benefits from this – they don’t grow and you don’t get the best out of them.

It is hard to be all ‘zen’ over a public failure. Just try talking to me when one of my talks has gone badly – I’m usually looking for the hole in the ground to disappear into. But over time, you learn to separate the things you don’t need to care about and the things you really do.

Corollary #1: If you’re working in an environment/team where everyone is afraid to make the smallest mistake and tiptoes around – leave! The same holds if your manager brings up your smallest of transgressions in your performance review.

Corollary #2: When you do screw up, admit it up front. Send a mail out saying “I screwed up here”. Take the blame and move on, rather than trying to hide it.

Look for the line at your door

I stole this from J. When you work in a team, respect and trust from your teammates is key. One easy way to measure this is to look for the people seeking you out. If people are not constantly seeking you out – either be it problems, ideas or things they need from you, there’s something wrong.

The reverse side of this is that you need to be engaged all the time. Whether you’re a developer or not, you need to be on all the checkin mailing lists, all the team mailing lists. You need to be trying out the latest daily builds. You need to be engaged.

If you’re not plugged in or if you turn away the people seeking you out, don’t expect to be involved when people make key decisions.

Code is king

If you’re in a semi-technical job, you absolutely need to look at the code. You don’t have to be able to write it or debug it but you need basic code literacy. Sync the source tree and get it building. If you can’t figure out how, ask around (and get to know the dev team in the process). Look at the daily checkins. During good times, checkins will keep flowing in. During lean times, checkins will be few and far between and not ‘meaty’.

I’ve seen an insane amount of conversations and meetings which could have been avoided by 30 seconds of looking at source code. There is absolutely no substitute to knowing how the product works (architecture diagrams don’t cut it). If you know how to use a debugger, set a few breakpoints and learn how the different pieces fit together.

If nothing else, your developers will take you a lot more seriously.

Lone wolf syndrome

Whenever I hear the term ‘team player’, I think of ’this’ post.’Team player’ is a term often hijacked to mean obedience, predictability and in general, being a square peg in a square hole. In other words, everything you’re not if you’re a hacker.

It is tempting to lock yourself and code up something and show it off as a fait accompli. Ignore the status meetings, emails and the rigmarole of the usual grind.

Don’t do this. Rather, don’t do this all the time.

Hacking is a creative process. There will definitely be weekends spent with code. However, if this is your default mode of working, you are causing a ton of heartache for your team. If they don’t know how far away from ‘done’ you are, they can’t figure out how much they need to worry or what kind of contingency plans they need to have in place.

Take a moment everyday to walk around your offices. Drop in and find out what people are up to. Talk about what you’re doing. If nothing else, it gives them a comfort feeling that you’re doing something and not browsing Hacker News endlessly. Over time (and this takes a reasonable period of time), you’ll gain enough trust that people know that they can depend on you to deliver on time.

Try out stuff

Something I’ve seen happen to a lot of good people is stagnation. You see signs of this when they start saying “This new thing X is just like Y from 20 years ago so I’m not going to try it”. Our industry is one that fundamentally changes every few years or so. The worst thing you can do is to not keep up and let yourself stagnate.

This doesn’t mean you need to be on every new social networking site out there and have tens of iPhone apps installed. But you should be playing with whatever’s popular. Download the latest hot programming language, web framework, browser plugin, whatever.

‘Not having time’ is not an excuse. Something that has always impressed me with both Bill Gates and Ray Ozzie is how much they play with tech – both from their own company and from others. If they can find the time, you can too.

Apart from just playing with it, watch what others are doing with it. You can learn a lot by just hanging out in the laptops section at Costco or seeing the conversations people have at the AT&T store. Ray Ozzie talks about always taking public transport when in a new city or a foreign country to see how people use things. Understand what normal people are trying to get out of technology.

The teams that die out at Microsoft are the ones who don’t keep up. One warning sign is if everyone in a team has worked on the same thing for over a decade. It is almost always a sign you need some fresh blood to shake up the thinking. Of course, as with any rule, there are always exceptions.

New team? Pick people over products

Whenever I decide to move on to doing something different, I’ll look for the people I want to work with first (that’s exactly how I picked my current team as well). This is very different than when I started out when I used to try and get into the coolest product team I could think of.

You learn very quickly that over the long run, how you get along with the people in your team has a much higher correlation with your happiness. Cool technologies fade, change and become old. However, relationships you form with great team mates stick around with you for a long, long time.

What kind of people should you pick? I have a tendency to pick teams filled with a certain kind of people – irreverent, rebels, troublemakers. Find out what works for you.

Get out of your comfort zone

I’m a big believer that the only way you ever get to grow is to do things outside of your comfort zone. Be it people, places, programming languages or your job – try and do something you haven’t done before.

For example, I was always super uncomfortable in bars and clubs. I would find every excuse to avoid a social outing. I finally decided to that the only way I’d ever get comfortable is to actually go. After a few years of forcing myself to show up, I’m as normal as anyone else.

The same goes for technology. Write code in a new language, try out a new search engine or switch to a new browser. Try doing a different job for a while. At Microsoft, it is quite easy to be a part-time Program Manager or a part-time developer – people love the help you can give them. Take advantage of it.

Ask the uncomfortable questions

All of us have been in meetings/presentations where you’re confused, have a question or just don’t know what the topic of conversation is about. Other times, you see everyone in the room tip-toe around a hot potato topic (the proverbial ‘elephant in the room’).

This stems from a desire to fit in, to not look stupid in front of one’s peers or bosses. Guess what? Most times, they’re in the same boat as you are. One rule of thumb I’ve found reliable is that the smartest person in the room is typically the first to say “I don’t know”.

Uncomfortable topics are tricky. A few topics are taboo for good reason (again, legal issues are a good example). Acknowledge them and move on. Most times, you’ll have a much more productive conversation by stating the obvious question everyone’s skirting around.

Go say ‘Hi!’

Any large organization has a number of interesting people. It is a statistical certainty. People who’ve built interesting things, people who’ve been around for a long time and have built-up wisdom, people who are interesting due to how bizarre they are, the list goes on.

Go and meet every one of them. Find out what they’re working on. Get them to tell you stories of the ‘good ol’ days’. Get them to rant on things they hate now. Learn from them.

No one turns down a lunch/coffee meeting. They might be reluctant about it but most cave in. If that doesn’t work, drop by their office and say ‘Hi’. If you’re working in Microsoft or Google, meet the superstars – meet the Dave Cutlers, the Patrick Dussuds, the Dave Campbells, the Rob Pikes, the Ken Thompsons.

Praise in public, pull down pants in private

It is always OK to criticize someone’s idea in public. It is to be expected. However, something you should never ever do is to criticize the person themselves in public. Have an issue with someone’s attitude or performance? Have the conversation behind closed doors. This is even more important if they’re lower on the corporate ladder than you are. The power relationship makes it hard for them to engage with you.

On the other hand, praise is always something that should be done in public. In fact, people consistently underestimate the value of letting someone know that you appreciate what they’ve done. A little email goes a long way in making everyone happy.

Best things are taken, not given

A lot of people expect the ‘system’ to take care of them. This is especially true if you’ve spent all your life in an academic background where your evaluation had a logic and rationale to it.

In a team/company, that’s often not the case. Want your little feature to ship in the next release? You need to go and evangelize the heck out of it. Want credit for the work you put into your product’s massive perf improvement? Make sure the right people knew exactly what you did.

This surprises a lot of hackers. Shouldn’t the ‘system’ automatically take care of seemingly mundane things like assigning credit or evaluating how good something is? The problem is that the ‘system’ is typically just a bunch of smart, well-meaning, overworked people who typically don’t have all data on everything happening in the team. If you don’t make the effort to make sure they have the right input (and this might be as simple as knocking on their door and saying ‘Check out what I built), don’t be surprised if things don’t go in your favor.

Don’t be an asshole

The most important lesson of all is this – don’t be an asshole. Lots of smart people tend to develop rude, antagonistic behavior patterns. Sometimes, they’re just jerks by nature. Other times, they’ve seen this behavior exhibited by people they work with and admire (something which used to happen a lot in the Microsoft of 10-15 years ago).

Some hackers mix up being rude with being forthright and blunt. Don’t – there’s a world of difference between the two. You can be blunt, call out someone’s BS without being nasty. In fact, some of the people who I admire most have a tendency to rip apart BS without raising their voices or even making the other person feel bad.

Being a jerk not only makes people hate you, it has network effects. It only takes one person exhibiting bad behavior to have it spread.

Be nice.

Corollary: Don’t mistake ‘be nice’ with ‘be politically correct’ or ‘be passive aggressive’. Being passive aggressive and politically correct to a fault is almost equally bad. The key is to critique someone’s work/ideas without critiquing the person themselves.

That however is a hard trick to pick up.

# 12 Dec 2009| Comments

Hardware and software, 2009 edition

Over the years, the software and hardware I use to go about my daily job has changed dramatically. Here’s the state of affairs at the end of 2009, of interest only to me in the future.

Hardware

I’m quite spoiled hardware-wise (one wonders whether it comes from a college life spent wanting a better machine). I have three primary desktop machines, two laptops and one mobile phone.

Operating Systems

Software

# 10 Dec 2009| Comments

Programming Windows Azure up for pre-order

Though there’s a bunch of work left on the book, I’m happy to report that my book ‘Programming Windows Azure’ is now up for pre-order on Amazon. Go forth and pre-order now!

# 05 Nov 2009| Comments

Windows Azure Service Management API

Last week, we shipped a preview of the Windows Azure Service Management API blog post, docs and a little tool which uses the API

Personally, it’s been a rewarding journey to ship this after a lot of hard work from an absolute fantastic team. It’s not often that you get to spearhead the creation of a major new Microsoft API and it feels great to have seen this through from beginning to end. I learnt a lot of lessons along the way – I should get around to blogging about them after PDC.

Do play with the APIs and let me know what you think.

# 28 Sep 2009| Comments

Setting outgoing font in Apple Mail (Snow Leopard) for Outlook

I installed Snow Leopard this morning and quickly set it up to work with my Microsoft work email account. Mail.app in Snow Leopard finally has Exchange support (it uses the public Exchange APIs which I’m surprised Thunderbird/others haven’t implemented support for yet). I quickly ran into a blocker.

Fonts.

I’m very particular on the fonts my emails use and I like to change it from time to time. Mail.app has this annoying property where you can only set the font as it displays on your screen but your recipients will get to see whatever font their email client picks. By default, Outlook 2007 on all my Windows machines picks this big, ugly Times New Roman font which I absolutely detested. However, actually getting Mail.app to set a font on your email proved to be quite hard and even in the end, I have a klutzy hack.

To compose using your font of choice, here’s what you do.

  1. Open Mail.app. Go to Preferences -> Signatures and create a new signature and associate it with your chosen account (my Microsoft Exchange account in my case). The actual content of the signature doesn’t matter as we’ll be replacing it later.

  2. In Finder, go to ~/Library/Mail/Signatures. You should see a file of the form ’<guid>.webarchive’. Make a mental note of this file’s name. If you already have a signature, you’ll see several files here in which case, open up each in Safari until you find the one you created in Step 1. For example, in my case I see F665C5B9-4F7F-48EF-9693-FE1F5BCC3767.webarchive.

  3. Open up your text editor of choice. Type in the following content. You’ll want to replace my name and font with yours of course. Mail editors are finicky about the HTML subset they support and the following, while not exactly CSS best practices, seems to work across all the clients I tried.

     &lt;div&gt;
 &lt;font face=&quot;Arial&quot; style=&quot;font-size:10pt&quot;&gt;
 Your content here
 &lt;br/&gt;
 &lt;br/&gt;
 Sriram
 &lt;/font&gt;
 &lt;/div&gt;

  4. Save the above file to the desktop as test.html or some other name of your choice.

  5. Apple Mail signatures need to be in the Webarchive format. Thankfully – we have a handy dandy converter built in – Safari. Using Safari, open the file you saved in Step 4. Go to File->’Save As…’ and make sure the format is set to ‘Web Archive’. Navigate to ~/Library/Mail/Signatures and replace the file we found in Step 2. Essentially, we want to change the contents of the signature without having to go through the trouble of making Mail.app recognize a new signature.

  6. Restart Mail.app in case it was open until this point. This is necessary since it seems to cache signatures after it has opened them once.

  7. When you compose or reply to a new mail, you should see the contents from step 3. Replace Your content here with, well, whatever content you intended to write.To make sure the content falls under the font style we created, I start typing between that line and my name and remove the placeholder line when I’m done. I generally don’t have my name at the end of my work mails but in this case, it acts as a nice placeholder for me to know when the signature ends.

It’s a bit painful to have to do this everytime and perhaps there is an Automator script which can do it for me. An alternative is to create your own stationery which does the same thing but that didn’t work for me as not only do you have to pick stationery with every new mail, you also can’t use it on replies or forwards.

# 29 Aug 2009| Comments