My End at Microsoft

It’s been exactly a year now since I left Microsoft (and a week away from my one-year anniversary at Unity). I (abstractly) dumped my feelings on the move a year ago in The Breakup, and posted a few thoughts and reflections in my first few months at Unity (Forty Days In, Why Unity, Musings on Microsoft, Making it Easy to do Good Work and probably others).

Now that I’m a year in, I’m happy to publicly admit that it was a scary move. I don’t regret leaving Microsoft (more on that later), but I’ve always credited a lot of my success at Microsoft to my network. I ran communities, I mentored people across the company, and I used all of my connections (and their connections) to discover new ideas, and to get help quickly when I needed it.

I didn’t know anyone at Unity, and for better or for worse, I had a reputation that I didn’t know if I could live up to. I suffer (like many others) with imposter syndrome, and worried (and still worry) that I can make the kinds of differences that I want to make.

I haven’t been perfect. I’ve made a lot of connections, but even though I know how important a network is, I could have connected with more people. While I’ve made good strides in establishing credibility within and outside of my org, some of the things just happening now are things I think I could have accomplished months ago. I’ve done enough work in my career with organizational change and shifting mindsets that I’m happy with what’s happened, yet I know how far there is to go.

I’ve been blown away time and time again how much all of my co-workers and team members like to help each other, and how much they like to help the customer. In one of the posts above, I accused Microsoft of not giving a shit about the customer – while that may not be completely true, I still believe it to be largely true.

In his Ted Talk, Simon Sinek tells a story of exec retreats he attended at Microsoft and Apple. At Microsoft, 70-80% of every executives presentation was about the competition. At Apple, 100% of the executive presentations were about the customer. While those percentages may have shifted since then, the essence of Microsoft culture is in that first sentence. At Microsoft, product executives obsess over the competition. Internally, groups compete with each other (there were at least three product groups at Microsoft besides the Teams group where I worked who actively campaigned as Microsoft’s competitor to Slack). Within organizations at Microsoft, the people competition was famous. Even though stack ranking didn’t officially happen, the employee rating process is extremely competitive and filled with monumental political efforts. I largely refused to play the game, but was inevitably sucked into discussions pitting employees against each other, often over incidental work issues that had little to do with overall accomplishments, leadership, or the bottom line.

Why I Left

Short answer is that the Microsoft culture – and especially the culture of the team I was on was the opposite of my own personal values and nature. Working on Microsoft Teams hurt my soul, but I couldn’t think of a product and role at Microsoft more suited to where I thought I could make the biggest difference.

In hindsight, I needed to leave to stay sane – the experiences of my last 6-12 months may have been the universe whispering “get out” in my ear.

The Dream Job

Teams was a dream job for me. I joined as the single “Quality” person on a team of 80 or so developers. Eventually I added people to my team, and took on more responsibility. I felt that if I was responsible for quality**, that it made sense for me to be responsible for everything from the moment a pull-request was submitted to the moment code was deployed to production (something I sometimes simply refer to as the code pipeline). I worked with smart people and was able to learn a lot about CI/CD, web tools, infrastructure and compliance. I also managed a moderately sized team of vendors (mostly offshore) who helped with build infrastructure and tools. The team I managed was the best team I ever worked with at Microsoft (with “Team-Fluffy” in Xbox a close second (that’s another story).

(** Yes, I said responsible for quality. Quality is absolutely team-owned, but I believe that I (and other Modern Testers are responsible and accountable for the quality culture in the teams we work with, so by extension, I was comfortable being “responsible for quality”).

The Hurt

Teams was also the most unnecessary stressful job I’ve ever had. The org was run by a VP who kept his fingers a little too deep in the day-to-day product decisions (e.g. “I think you should add a menu there. Drop what you’re doing and get it done asap”). By itself, that’s not a horrible thing, but it was coupled with a culture where pleasing your manager always trumped pleasing the customer. My manager was no different – knowing the culture (he worked for our VP for most of his career) he consistently prioritized making his boss happy over solving customer issues. And so on and so on. Two of my peers (who spent so much time together we merged their names and referred to them by a collective singular name (think Brangelina)) were famous for jumping on projects my boss or the VP wanted, doing absolutely nothing more than enough to say they were working on it, and blocking anyone else from jumping in and trying to solve things in the right way.

I’ve worked in plenty of bad teams at Microsoft, and too many times, I’ve watched strong egos get in the way of good software. I regularly read (and recommend) Orbiting the Giant Hairball to learn coping techniques (thanks Marlena for recommending this book to me years ago). I’m also an efficiency nut, and often get annoyed at many things that block team efficiency (there’s a reason that the mantra, Accelerating the achievement of shippable quality resonates with me). I had friends on the team (and still do), and mostly, I kept my team out of the crossfire, and we accomplished remarkable things.

It’s also worth pointing out that I have thought of leaving Microsoft for quite a while. I interviewed for (and was offered) a handful of positions, but none were right (Advice I often give is, “Never go from a job, always go to a job”). If the Unity job wasn’t such a perfect fit for me, I would have continued to plow forward.

The End

A few things happened that finally put me over the edge (although as I reflect, I probably waited too long. I could list enough of the things that happened to fill a glassdoor review or a reddit post), but it’s not worth the bits, nor is my intent to bash the company.

The first was an incident with our PM lead (note, I think Teams is the last Microsoft team to still have “traditional” 1990’s msft-style program managers). He worked for our VP. Our VP wanted features – so he wanted features, and made a list of features that “had to be in” for our next release (I don’t recall anymore whether it was for a beta, or for our preview release). In a meeting, he more or less stated that getting these features done and in the product as soon as possible was the absolute top priority. Wearing my quality hat, I pushed back with examples of how similar statements from him had tanked quality so bad that we couldn’t release for weeks, and asked that we check in the features when they’re ready rather than rush them. He turned red, basically told me to stfu, and (from what I’ve been told second hand) later used his influence to tank my evaluation).

The hearsay was somewhat supported in a check-in discussion with my manager, where for the first and only time in my career, my manager made up stuff that I didn’t do – he literally listed things that I didn’t get done that I had never heard of before. I suppose I could have blacked out for a while, but I usually don’t drop the ball.

Incidentally, quality on Teams was borderline average, and that made me feel awful. We routinely ran with a bug backlog near ~500, and I spent a lot of time making sure we were fixing the right bugs and playing a violent game of whack-a-mole to make sure the worst bugs were fixed in the feature onslaught.

One of the things I loved about my role was making those decisions on what needed to get fixed, and making sure the fix was done well, tested, and rock solid. I had a chance to talk with Chuck Rossi during an interview process with Oculus, and the big takeaway for me was an insight into Facebook’s release process. Taking a page from his book, about two months before our preview release, I blocked off check-ins to our shipping branch, and began reviewing every check in to make sure it was something that was truly needed for our release, and something that wouldn’t cause regressions. It was a shit-ton of work (not to mention the opposite of my CI/CD goal), but the only way I could gain some confidence that our preview release would make the impact we wanted. Two weeks or so away from our preview launch, my manager called me at home, on a Friday night around 9pm to ask about a certain check-in that I accepted and was going to integrate the following Monday. I’m being nice to say he he asked about it. He asked, “what the fuck are you doing – you’re playing with fire – how can I trust you.”. I believe that in times of stress that people express their true self, and this was one of the final red flags for me. I ate crow and apologized, he hung up on me. I came into to work on Saturday and removed the rogue pull request and cancelled Monday’s deployment.

There are two important follow-up points to this story. The first is that we shipped with a MAJOR bug with our preview launch (if you recall, Stuart Butterfield from Slack gave us massive publicity by publishing a passive aggressive welcome letter to our team). We announced the product, opened it up for IT admins to enable for their orgs, but most orgs couldn’t create teams. It was a fuckup, but I knew we had a way to get a fix rolled out quickly (very glad at this point that I took over the deployment pipeline). In the meantime, our early adopter customers were posting things like, “I guess it’s not rolled out to us yet”, and that loyalism saved our butt.

Second follow up point is that we did have one really ugly bug that people really complained about in our first week after launch. I had people (including the VP and PM lead above) express their disappointment to me about this bug being in the release. Fortunately, I had approached the release with a mindset not of “how do we nail the preview release”, but with a mindset of “how do we get the following releases to our customers regularly”. We shipped the front end weekly at that time, so the fix was out the following week.

Oh – the ugly bug we had to fix. It’s the one my manager berated me about and insisted I pull out of the product.

The Aftermath

I don’t mean to throw individuals under the bus (although I realize I did), but feel that the stories are necessary to convey the culture of Teams, and why it didn’t sit well with me. I also thought about sharing my thoughts on Teams shortly after I left, but felt even my early jabs at msft in my first few months away made me sound bitter and mad rather than a story of how I was able to walk away from a dream job and find something where I felt I could make an even bigger difference.

I haven’t followed the success of Teams in the year since I left, but I’ll assume that not much has changed. It’s slow, a little buggy, and yet is a really nice collaboration tool. In fact, it’ probably the best collaboration tool for teams that don’t know they need a collaboration tool – and I think it’s uniquely marketed at that audience (people using Office 365). But I fear that instead of trying to be the best collaboration tool for Office 365 users, instead there’s likely too much effort on competing with Slack. The culture demands competition, and that may be a bad path to follow for my old teammates.

Epilogue

A lot of what I learned – even in Teams has helped me at Unity – including some (to me) interesting insights that I never would have had without those experiences. I’m using those insights day-to-day, and hope to share stories soon.