What I Learned at Microsoft

Last month, I left Microsoft after four wonderful years on the Office team. It was my first job after college (big decision) and I got lucky. Not everyone does.

Some of my learnings and experiences

Access to mentors, interviews with multiple companies (famous college) and understanding what work environment you're committing a third of your life (8/24 hours) to is a privilege. I am writing this to level the playing field however I can. DMs are open if you have questions

Access to People:

The institutional wisdom and history inside big companies is massive. Xbox head, TypeScript’s creator, Office’s chief strategist against GSuite, leaders from Wunderlist, Accompli, Sunrise, GitHub - I met them all during my time at Microsoft.

Getting a meeting might take time, but you could almost guarantee a 30 min learning session from anyone in the company including the CEO. E.g. MS’s CXO taught me about the recurring traits she saw in people who grew the fastest: A hunger to learn and consistency of follow-up.

Stable and Unstable Management:

At an internal Diversity & Inclusion event, we asked folks what would convince them to stay at the company longer? ‘Stable Management’ was the most common answer.

During my first year, the Office org went through multiple reorgs.

Each reorg brought about changes in priorities & direction, which paused existing efforts. New work would begin based on the new management’s priorities. I saw the morale go down in partner teams as months of work would get thrown away for a new direction. Repeatedly.

My team kept chugging along because we were heavily dependent on iOS and macOS updates. These were generally revealed once a year at WWDC. Being unable to see the internal workings of Cupertino was a blessing because we could keep executing on at least one certain set of goals.

Our bosses buffered the team against other changes until they were confident and only then adjusted course. That was leadership - recognising choppy conditions, guarding your team from the storm and making progress in the journey despite changing goals. And enjoying it!

What does the rest of the company do?

In university, it’s hard to understand what management did or why a company hired so many non-engineers. In classes, you would get a spec, write the code and get rewarded with a grade. Simple.

In the real world™, you decide what to build, for whom, why, and when. How to market it internally and externally, how to sell, ship, support and iterate on it. All these verbs can be matrixed across disciplines and org structures depending on the company and industry.

There is no pass/fail every few months. What gets affected is your job and compensation on a longer timeline. Managing the iOS Office product, I got to practice all these verbs across different projects and I attribute most of my learning to this breadth.

Process & Execution
Coordination is easy when two programmers are working on a multi-week project. At Microsoft-scale, how do Windows’ annual releases and Office’s monthly updates and weekly beta builds rollout? How do you ensure tens of thousands of people stay in lockstep?

How do you course-correct from feedback and competition? Process. The fine art of just-enough-process for tiny A/B experiments, to quarterly product planning and massive launches. Execs have processes too - just a different abstraction level, scope and experience requirements.

One Manager:

Your manager has an outsize impact on your experience. They might influence what projects you get, your compensation and whom you work with. At a big company, there is no guarantee you’ll have the same manager or team throughout your time there.

I was lucky to have the same manager throughout and we got along too! This enabled him to tell an evolving story of my work at performance reviews which helped in faster promotions. If you don’t get along with your management, you can also switch internally, because...

Companies within Companies:

When I worked with the Azure, Surface & Windows orgs, they felt like different companies. The culture, product & people can differ dramatically across orgs. This diversity of available experiences tends to keep people at big companies for decades.

Space and Time:

At Microsoft-scale, every team is remote to some degree. Your team can be in different timezones, different floors, buildings, or different companies. I moved to Vancouver in 2018, while 90% of my colleagues were in Redmond. Adjusting my...

(and my team’s) working style to be asynchronous and decoupling decision making was important to move fast. However, It’s also necessary to periodically plan together and share learnings, so that the team doesn’t lose the natural agility that arises from being co-located.

Accessibility:

Most college computer science curricula don’t even touch on making accessible software. Mine didn’t. Surprise, surprise, my first project was to lead the team’s accessibility efforts. That necessity drove me to learn as much as I could about...

different kinds of disabilities, universal design and contextual mismatch ( @katholmes’ book is amazing for this).
I learnt if companies which create tools or platforms don’t make them accessible, they’re hurting their own business and excluding people from society. How?

Public institutions are legally required to buy accessible solutions. If a job requires specific software to be used but it’s inaccessible, individuals get excluded, regardless of talent. Inaccessible tools can hurt every users' performance whenever there’s a contextual mismatch.