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 Microsoft). 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.

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 to 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 have watched strong egos get in the way of good software. I regularly read (and recommend) Orbiting the Giant Hairball to learn coping techniques. 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” 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. 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.


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.

Five for Friday – January 19, 2018

  • Quote I’ve been pondering: “An expert is not someone that gives you the answer, it is someone that asks you the right question.” —Eli Goldratt
  • I’ve been thinking about the new-employee experience recently, and recalled this article about starting new employees on Friday. It’s something I want to try.
  • I’m traveling this week, and wanted to give a shoutout to the Osprey Ozone 46. I never check a bag, and this bag holds everything I need for a week, along with my electronics, etc. If not fully packed, I can shove it under a seat, but my assumption is that since it’s a backpack, I’ll never be asked to gate check it.
  • Yet-another-article-on-microservices worth reading.
  • I may have mentioned before my admiration for Simon Sinek. I don’t normally like “fluffy” books, but I just gave my leads at Unity a copy of Better Together, as I’ve found so many great quotes and so much inspiration from this little book.

Five for Friday – January 12, 2018

  • I’m finally reading Pat Lencioni’s latest book on Ideal Teams. I’m a huge fan of Pat Lencioni’s business novels, and enjoying this one just as much as the others.
  • You’ve probably already seen this article on testing microservices. I shared it with my team this week, and think it’s a good read.
  • All About Lean has an article on The Toyota Employee Evaluation System. Some good stuff there, and some stuff to ignore. As an aside, I so do not miss the msft annual review process.
  • A few months ago, I mentioned the neuroma in my left foot. To give my foot an even better chance of lasting longer running distances, I recently switched to Altra running shoes. Altra’s have two unique features: a wide toe box (to give my toes more room to spread out and not pinch the nerve; and a “zero drop” – meaning that the heel and toe are at the same level. So far, they’ve been fantastic.
  • The 2018 State of Testing survey is out. While I’m not often a fan of these surveys (too much room for bias in the interpretation for me), this one is the best one, and the only one I take and read about. If you haven’t filled it out already, go ahead and give it a shot.

Five for Friday – January 5, 2018

I’ve missed doing these, but glad to get started again.

  • “The world doesn’t reward perfection. It rewards productivity.” – 18 Minutes by Peter Bregman
  • I’ve been working my way through Tribe of Mentors by Tim Ferris and finding a lot of ideas and a lot of inspiration.
  • While on the subject of Tim, I also recommend his recent podcast where he “interviews” Terry Crews (I use quotes because Terry really interviews himself).
  • Speaking of books, I just bought the Humble Bundle Python pack – if you’re not aware of Humble Bundle, they sell packages of books, games, comics and more on a scaled pay-what-you-will basis…with proceeds going to charity. I bought their Data Science bundle a few months back as well.
  • Camille Fournier (author of The Manager’s Path) recently posted about her (self) Yearly Review. I value (and use) self-reflection a lot, but have never applied it on a full year. I’m working through the list myself and finding it valuable.


The angryweasel guide to safe backups

Warning – not software quality related, but perhaps even more important information follows.

I am diligent about backups (and paranoid about losing files)…and frugal, so dumping my backup strategy here for those who may be like minded.

First thing to be paranoid about is work in progress. If it’s code or text based, put it in github and push often. For docs, drawings, and other files, put them in google drive, drop box, or similar. Several times in the past few years I’ve had Windows problems that just couldn’t be solved (and this was working at Microsoft), so having backups in onedrive (and google drive today) make it brain-dead easy to pave a machine and pick up where I left off as quickly as possible. Of course, the same method makes it just as easy to recover from damaged hardware, theft, or malware. I attempt to organize my work, so that a sudden and complete wipe of any of my computers will leave me with little else to do other than re-install the OS and apps (and the latter can also be easily automated).

At home, the whole family backs up files on our Synology server. The server has four 3-terabyte drives striped RAID 5 for (roughly) 9TB of storage. All of our photos since the dawn of digital cameras, all of my presentations and docs and manuscripts ever, backups of computers I haven’t seen in years (need to clean those out), and basically any file my family has even slightly owned is on this server. It’s an integral part of our family and family history.

Of course, losing the Synology server would be heart-breaking, so using the backups rule of three (Scott Hanselman blogged about it here), everything (almost*) on the Synology is backed up to Amazon Drive. The price is competitive with other backup solutions ($60 a year for 1 TB of storage) – but more importantly, it’s easy for anyone in the family to access.

When I first signed up for amazon drive, storage was unlimited, but they now charge another $60 a year for anything between 1 and 2 TB. I have a large CD collection ripped to FLAC that also lives on the Synology server. While I still have the CDs, and could rip them again, I’d rather not. But – I’m also too cheap to pay $60 a year to keep a backup of files that are technically replaceable. So – these ~25,000 FLAC files (just under 400 GiB) all go to Amazon Glacier storage, where retrieval (if I ever need it) is slow, but I pay $1.40 a month (~$17 a year) for peace of mind.

There’s enough weird stuff going on in the world to worry about – with the above, backups are something I don’t worry about at all.

Angry Weasel Twenty-Seventeen Recap

It’s been a pretty remarkable 2017 for me – so much so, that it’s worth (for me) a little reflection.

This time last year, I had made the choice to leave Microsoft (but hadn’t told anyone yet). I went into work the week after Christmas (when nobody is there), and quietly cleaned out a bunch of personal stuff (I didn’t know if my resignation would be met with a “walk to the door” or not). Many of my reflections at the time made it into The Breakup, and the feelings that went into that post haven’t changed.

I officially left Microsoft in mid-January, and after a week off, began a journey at Unity that I have had absolutely zero regrets about. It’s been such a good mixture of problems I know how to solve (same movie, different cast), brand new challenges I don’t know how to solve, and wonderful, passionate people every direction I go. My new direct reports have all helped me so much in learning about the people and business at Unity.

In the meantime, I’m super-proud of the direction of the AB Testing Podcast, and how it’s helped me in my role at Unity (and how Unity have given me freedom to experiment using the principles of Modern Testing that Brent and I discuss frequently). Based on our vague plans for 2018, I’m even more excited about where our podcasting journey will take us.

I blogged a bunch of times – sometimes about testing, sometimes about Unity, and sometimes a combination. I also started the Five for Friday series which I hope folks find valuable.

I had a light speaking schedule in 2017 (although less light than the previous year where I was pretty much locked inside of Microsoft). I spoke at the Online Testing Conference, and then late in the year at Heisenbug. Next year is kicking off with three external talks in the first half of the year – that’s a bit more than I’d like to do, but an achievable task.

Back in July, I asked testers to join me in cleaning up the Wikipedia page on Software Testing. I think the page can be a lot more clear and reflect the state of the industry much better. While my contribution has been close to nil, it’s been great to see a few folks from the community step up and make incremental change. I’m not big on resolutions, but I do plan to play a bigger role in making the site a bit better for the masses in the coming year.

I’ve also had a chance to balance a hectic work schedule, kids with homework, and my own health. I began 2017 with a goal to run 510 miles (820km) (10 miles for every year of my age). While I thought it would be a slam dunk; I didn’t anticipate travel, live, and a month taking care of my dad in September. I made it to 480 miles though, and I’m confident that, barring injury, that I’ll make it to 520 easily next year. The good news is that since leaving Microsoft, the combination of lower stress and a bit more chance to exercise has dropped my blood pressure more than 10 points, and I’ve been able to lose 25 pounds (12kg).

I hope everyone reading had a fantastic 2017, and I hope we cross paths soon and often in 2018.

Fear Factor

I had one of those meditative weekends, where between solving Advent of Code challenges, seeing the new Star Wars movie, and cleaning my home office, some ideas (sort of) merged in my head.

One part of the recipe was yet-another-discussion on twitter over the weekend (over) reacting to the Test is Dead theme that came out of a few conferences several years ago. For me, I knew what that phrase meant before I saw the content – it means that how software is tested is changing. While I’m fully onboard with the changes, the talk of test is dead, and the role changing causes a large amount of fear, uncertainty, and doubt (FUD) among a lot of testers in the industry who haven’t seen how these changes can improve software quality, and how they can adapt their skills to a new world.

While in my office (during a conscious retreat from the world of twitter), I noticed my copy of Crossing the Chasm, the Geoffrey Moore book with a lengthy dissertation on how people adopt new technology. A quick fact check tells me that this curve, is called Diffusion of Innovation, and was actually first proposed in 1962.

For anyone who has somehow missed seeing this curve explained before, it’s an explanation of how people adopt a new technology; broken down into innovators and early adopters who jump in early (Moore refers to these as Tech Enthusiasts and Visionaries respectively, and as “The Early Market” as a whole). The Early Majority (Pragmatists), the Late Majority (Conservatives), and the Laggards (Skeptics) make up the Mainstream market of a technology.

While I have a vision for how test and quality specialists (described in AB Testing as “Modern Testing”), I also realize that the role of testing is in different levels of maturity across the industry. Modern Testing (which I see largely as an evolution of Agile Testing as described by Crispin and Gregory) is absolutely happening in many companies – but it’s in the Innovator’s part of the curve.

If I squint and look at the curve as “waves” of testing approaches, Agile Testing is farther along the curve, followed by separate teams of (largely) SDETS, separate (or outsourced) Test teams, and finally, low (or lower) skill teams of manual testers testing quality into a product.

The percentages are (obviously) made up, but based on biased and anecdotal information, I think the graphic makes at least a little bit of sense. There will always be shitty testing (far right side of graphic). There’s a large area in the middle that is an area largely (IMO) in transition. Armies of SDETs came and went while I was at msft – and while I still think Microsoft handled both the transitions to and from SDETs horribly, a world of testers as programmers focusing on automation is the norm for many teams.

As hinted above, with change and transition comes fear. The “manual” tester fears a world where they may need to learn automation. The automation engineer fears a world where they may write diagnostics or utilities (or, gasp, production code) instead of automation, and dedicated testers of any kind may fear a world where their work is owned by developers (or computers). As a result, many folks dig in their heels, refuse change, and all but flat out deny that test (and in general, the way teams around the world are making and shipping quality software) is changing.

Instead of yelling, “It won’t work”, I encourage these folks to ask, “How will it work”. Instead of worrying, “Will I have a job”, ask, “How can I help make these changes happen”, or even, “What could my role be in this new world”.

My thinking on the subject is as far away as it can be from worrying if I have a job in the future. I’ve said many times (to listeners, readers, managers, and co-workers), my goal is to make my job obsolete. I’m trying to make my job disappear. Not because I don’t like it (I love it), and not because I’m incapable, bored, fearful or ignorant. I want to build software teams that intuitively know how to efficiently create quality software that excites customers. In the short term, I and my team have skills and knowledge that can help in that goal – but in my opinion, if I don’t remove the need for me in that process, I’m not effectively leading my team and the feature teams we work with.

Embrace change, not fear.

Five for Friday – December 15

I’ve enjoyed my string of FfF posts as an easy way to share stuff I like with little need to elaborate. It *will* continue, but I’m going to take a break for the last two weeks of the year. FfF will be back on January 5, 2018.

  • I recently read Ray Dalio’s, Principles. In the preface, he has a line that rings true (I think) to all of us who suffer from impostor’s syndrome.
    Before I begin telling you what I think, I want to establish that I’m a “dumb shit” who doesn’t know much relative to what I need to know.” That give me reason enough to keep on reading and learning more about what makes Ray tick.
  • On my last team at Microsoft, the team started using Git, and became over-excited about Gitflow – which I often describe as source control for those who like to add extra layers of confusion to their source control and release. We eventually treated ‘master’ as a release tag, and were (I think) close to working out of a single trunk. Now, Trunk-Based Development is a thing, and I think it’s a good thing.
  • I’m a huge believer in 20% time (invented by GM, and popularized by google as a way to give people a chance to self-direct and learn). I recently discovered that schools are using the concept to give students alternate opportunities to learn and grow.
  • A rare shot at cross-promotion. The year-ending episode of AB Testing will be out Monday. I’m really happy with how the podcast has developed and matured over the last few years.
  • Brent Jensen and I often discuss Modern Testing – but I recently discovered that Modern Agile is also a thing.

See you in 2018.

Five for Friday – December 8

It’s the FfF Moscow edition (I’m here for the Heisenbug conference.

  • As I approach my one year mark at Unity (and hopefully established a small bit of credibility), I’m beginning to push a bit harder on some topics. I’m reminded of this quote from Colin Powell, who says, “…leadership is sometimes about being willing to piss people off“. I’ve heard the substance of this phrase in many forms, so whenever I see it, it reminds me that making often change requires friction…and that’s ok.
  • I’m (finally) reading Principles by Ray Dalio. His story is interesting, but the way he approaches life and work is truly inspiring. Bonus quote this week (from above web site): “Principles are ways of successfully dealing with reality to get what you want out of life.
  • I visited a nuclear protection bunker in Moscow this week. Amazing to have such a structure so far under ground.
  • I have a minor addiction to the Advent of Code. I’ve completed the puzzles through day 8. Several times, I’ve looked at the puzzle, and declared, “nope – too hard”, and closed the web page, but I keep going back and plowing through the puzzles. Despite working at Microsoft for so long, I never really had a chance to write much c#, but for this project, I’ve been using Visual Studio on Mac to write c# solutions, and have been having fun learning the language and solving the problems.
  • Seattle is getting a Hockey Team (potentially). Too many commitments these days to drive to Vancouver to watch the Canucks, but I’m excited that we may have a NHL team here someday.

Five for Friday – December 1

Some of my favorite / most interesting thoughts and links from the week…

  • Yet another quote from one of my heroes, Simon Sinek: “There are only two ways to influence human behavior: you can manipulate it or you can inspire it.” I half-jokingly told someone on my team this week that “leadership is manipulation”, and it reminded me of this quote. The two sides of the “or” have similarities and marked differences that are important to remember.
  • The Tester’s Island Disc podcast with me came out early this morning.
  • We all heard about the apple root password bug this week. What you may have missed, is this nice writeup on what exactly was wrong (I love debugging – if you do too, you’ll like this).
  • I discovered a test conference (European Testing Conference) that wasn’t on my radar, and looks interesting. Program looks good, and hope it continues.
  • I’m a big (HUUUGE) fan of soccer, and last night, it was great to see the home team make it to the MLS Cup. I will be in Moscow for the final (kickoff will be midnight, local time), but hope I can find a place to watch it.
%d bloggers like this: