Read on TwitterLast 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& #39;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 
https://abs.twimg.com/emoji/v2/... draggable="false" alt="đ" title="Eyes" aria-label="Emoji: Eyes">
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.
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!
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.
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.
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...
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.
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.
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?
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& #39; performance whenever thereâs a contextual mismatch.
