I learned a lot while at Microsoft (I was there over 20 years – I better have!) There were a lot or REALLY smart and passionate people (which equated to a LOT of swearing 😊), but people were fair and apart from the initial brogrammer culture (which eventually improved), it was a great place to work.

When I got promoted to a Senior Engineer, I was invited to attend a two-day course on what it means to be a senior engineer. It was taught by Eric Brechner.

My main take-aways were:

• A senior engineer is an engineer first (i.e. you are expected to be a really good engineer), but if you are only a great engineer, you are not a senior engineer. A senior engineer is not just graded on what they accomplish, but on what they help those around them accomplish – you are expected to have contributions far beyond what you accomplish yourself (I wasn’t always an exceptional senior engineer.)

• No problem is too big or too small for a senior engineer. He used David Culter as an example – he created Windows NT, but then organized and managed a build lab (because Windows NT needed a build lab and nobody else was available to do it). Some developers only want to work on what will look good on their resume, and these people aren’t always the most successful engineers.

• Always be transparent. I was already pretty good with this, but my job as an engineer was to provide data and educated opinions and not to always say what other people wanted to hear (this doesn’t mean that you can be rude – in fact he emphasized the importance of always showing basic respect).

• Fully own any problem you are given. I was always pretty good at this, but some problems are more interesting than others and we are sometimes tempted to half-ass the boring stuff. This was really drilled into my head later when I worked with Steve Pronovost – he is a really good boss and mentor and it’s no surprise that he’s now a Distinguished Engineer (a position higher than VP).

Some other things that I picked up over time are (in no particular order):

• Be open to work on anything. Early in my career I would sometimes feel a sense of superiority over people working on less-interesting problems. As I gained experience in more areas, I found that I enjoyed working on pretty much ANY project/problem as long as it met these three criteria:
  • It had to be relatively hard to solve.
  • It had to be important (not necessarily glamorous).
  • Management had to recognize it as important (I added this third criteria much later and at great personal cost – it’s never fun to keep banging your head against the wall.)

• Focus on being a good engineer, being helpful, and solving problems rather than playing the political game. Microsoft performance reviews can be a brutal process and they stack rank every employee. You can be amazing, but if everybody else is even better, you get a bad review. A lot of people realized that if they couldn’t be the best, the next best thing was to make everybody else worse. When asked questions, they’d give a technically accurate answer, but would often leave out some important details in hopes that everybody around them would flounder. I never used this strategy, and usually people who did were promoted less.

• No big things are accomplished on your own. When working on overlays, independent flip, etc. I had to convince other teams to trust me and sometimes for them to do a lot of work. When things work out and management is handing out kudos, don’t deny these other groups their props. It builds a lot of good will, and trying to take all of the credit (even if you deserve most of it) will destroy that good will. At the end of the day, you need other people to be successful.

• Misogyny was still a bigger issue at Microsoft than I previously understood. There were a lot more female engineers and the culture was far less toxic, but working with Lucia really opened my eyes. She is among the smartest people I’ve known, but in meetings sometimes people would assume she was an administrative assistant and ask why she was attending. Other times people would automatically look at me to answer a question as if she were incapable. The playing field was not nearly as level as I previously believed, and it made me sad as my daughter was took a job as a Microsoft engineer shortly after I left.

Finally, I learned that while intelligence is important, it’s not the only factor in success. Lucia used to rank people like this:

NOTE: “Low” is a relative term. As the truly stupid and unpassionate people didn’t last long at Microsoft, “low” probably aligns with “average” when compared to the outside world.

She never hinted where she placed me in this grid, but I don’t think of myself as particularly brilliant (especially when compared to many of the people that I’ve worked with), so I’d place myself bordering quadrants 1 and 2. Lucia is in the top left corner.

Everybody knows intuitively to hire people in box 1 and to avoid people in box 4, but then I started asking myself:

• How well do our interviews test for how passionate the candidate is? The answer is usually “not at all”.
• Which is better, an employee in the middle of box 2 or the middle of box 3? My spicy take is that I’ve found that passionate people will usually come up with a good answer (given enough time and people to consult), whereas a less passionate employee may not even care that much about the right answer. I’d rank people in box 2 over people in box 3 (although many would disagree with me.)

I think back to the earlier days of Microsoft where everybody believed that every project would be successful because we had the smartest people (and how badly that worked out most of the time). I also remember some really smart people who accomplished very little. Passion, persistence, and experience are often more important than people give credit.