Author: Alan Page

Since announcing my pending job change, several people have asked me, “why did you choose the Office Communicator group for your next position?” The answer is also part of the internal talk I’m giving this week on career tips, so I thought I’d share it here.

One of my favorite things about Microsoft is the wide variety of teams, products and roles available across the company. While considering this change, I looked seriously into possible roles on at least half a dozen teams. One job was extremely technical – working on testing a major new feature for a critical and complex component (sorry, I have to be vague since it’s unannounced). Another position was working on a cool technology helping them with their test tool infrastructure. Talking to the managers in charge of these teams helped me figure out what kind of position I was looking for (when I started looking, I wasn’t entirely sure what I was looking for). In fact, when Ross (my new manager) and I first talked, I told him I’d keep him in mind as a backup – but we eventually talked and I began to change my mind.

When looking for a new job, the 3 Ps are important to keep in mind. You can follow a Person (a manager you really want to work with), you can work with People (teammates can make or break your experience), or you can go to work on a Product or technology you’re passionate about (or ideally, a combination of the three). As I mentioned, I’ve known Ross for 7 or 8 years (Ross used to chair the Test Architect Group before I took over). I’ve also watched Ross doing some extremely cool things as a manager over the past few years. As I dug in a bit deeper to the org (you should always do your homework when changing jobs) I found more things I liked. Ross’s manager spent some time with me, and showed me that he understood more about the challenge of software testing than just about any other manager of his level in the company. I also discovered that a peer of his, as well as a team mate-to-be are people I worked with and respected in previous jobs. I’ve met various other people from this org over the years and I’m certain it’s a team I can work with. What surprised me in my search was how interested I became in the technology (it’s quite common to love a job where you aren’t passionate about the technology). As I talked to the team and learned more about the product, I began to get pretty excited about the potential – and felt pretty good that I found a position that nailed the 3 Ps as well.

Office Communicator is about a lot more than an IM client (in the past, I have jokingly referred to the product as “messenger – enterprise edition”). There’s potential to do some pretty cool stuff with online meetings and recordings (and thing in the client too). There’s also plenty of more technical challenges below the surface (distributed algorithm testing anyone?), so I’ll get to do a wide variety of work. I think it will be fun working on a team like this and hope to have a lot of fun.

And, beginning Tuesday, I hope to begin to figure out much more about this team and start to figure out exactly what that wide variety of work entails. Stay tuned.

As you know, I’m getting ready to change teams at Microsoft. My current manager gave me the ok to spend a bit of time during my transition ramping up on my new team. It looks like I’m not going to get much of a chance to ramp up, but I think I will be able to get my new office set up in advance, and I spent a bit of time today moving furniture and setting up equipment (almost).

One quick aside about changing jobs at Microsoft. It used to be that when you changed jobs your computers stayed with your current team. Eventually, the finance guys realized that buying new machines after nearly every employee transfer was getting a bit expensive, and they changed the rules so that you could bring at least one computer with you when you move (or more if agreed upon by both managers).

Anyway – I’m in love with my laptop and chose to bring that with me (besides – my current work desktop machine is more suited for writing books and developing powerpoint slides than compiling large software products). I asked my new team if they could leave my new computer in my new office, and that I’d come by to set it up when I had a chance. I had an hour this morning to swing by and check on my new digs. It’s going to be a bit weird working in an office all day – I’m so used to the team room (and meetings), that sitting in an office is going to take a bit of getting used to. The first thing I did was move the desk around – I don’t like having my back to the door when I work. There was a big Dell tower computer in the office, so I started plugging in peripherals, power, etc. There were also two new 19” monitors, so I unpacked those and set them up … and ran into my first problem. They came with VGA cables only, but the computer only had DVI ports. I walked down the hall to find our groups business administrator (who is awesome, btw). She pointed me to the admin who gave me a funny look when I used words like VGA and DVI, but she pointed me to a box of cables. I found a DVI cable, then eventually found a 3-foot DVI cable (seriously, what is that good for). As a stop-gap, I found a VGA-DVI converter dongle and went on my way. I also noted that I need to order monitor arms since, for some reason, I like to flip my widescreens 90 degrees, and the stock stands wouldn’t work that way.

Once I got everything hooked up, I powered on and positioned my finger over the F12 key for a PXE boot (PXE is a network boot that is very convenient for installing a clean OS). Unfortunately, PXE hit an error and didn’t boot. I rebooted a few times, played with the bios, swapped out cables, pixie-booted another machine, and did the full range of trouble-shooting; which in the end pointed to a problem with the machine. Since the machine had an integrated NIC, I thought I’d check if there were any bios updates. I searched Dell’s site, found the update and downloaded it to my laptop. But then I noticed that the date on the latest updated was March, 2006. I looked inside the machine and saw a note saying it was manufactured in 2005. Admittedly, it’s a pretty sweet machine for something five years old, but how could this team give me a clunker instead of a new machine. C’mon – I’m Alan Page – I need to do …stuff…

I attempted to ask about the machine in a way that didn’t sound ungrateful, but at the same time say, sheesh, this machine is five years old. It turns out that they did order me a brand new dev box, and they left this one around for me to use as a test machine (and an awesome test machine it will be (dual proc Xeon)– once I get it to boot). I’m thinking I’ll have a pretty sweet setup fairly soon. If I remember to bring a camera to work, I’ll even take pictures. In the meantime, I have loads more work to complete on my current team, so most of my effort will be on that through the end of the week.

I’m heading up to the Vancouver for the Olympics this weekend and hoping to catch up on some reading on the trip. I’ve built up a bit of a backlog of books I want to read or re-read and I’m going to try to make a big dent in the list during the train ride (and while waiting in line for will-call tickets).

First on the list is Saul Alinsky’s Rules for Radicals. I’ve been meaning to read it for a while and I’m looking forward to seeing what people love (and hate) about it. second book on the list is The Checklist Manifesto. Atul Gawande spoke on MS campus recently and his talk inspired me to take a closer look at his book.

There are two other books on my re-read list. Both are controversial in that people seem to either really, really love them, or really, really loathe them. The books couldn’t be more different, but the value in both of them to me is beyond the printed word – the value is between the lines, in the thoughts and ideas they bring out in me every time I read them. ZATAOMM is a classic and a book that I read every few years, or every time I change jobs (whichever comes first). I’m  also going to re-read Quality is Free. A lot of software folks hate this book. At face value, of course, application of manufacturing approaches to software often fail, but the point (to me at least) is to remind me that quality can be improved through processes and culture change and it always gets me thinking of new ideas for improving software quality and building a quality culture.

That’s probably more than enough reading for a short trip, but I’ll bring at least three of those with me just in case there’s more waiting than I anticipate. I think Rules for Radicals is the only book that’s not commonly read among my peers, so I’ll plan to share any interesting insights in a mini book report once I finish it.

I give presentations to teams at Microsoft often. Some teams want a talk on a specific topic, and other teams just ask me what I want to talk about. It’s a good opportunity for me to try out different ideas and see if they have merit. I imagine only 10-20% of these talks would have any interest outside of MS (I think the same percentage of my external talks are interesting to MS folks too).

Anyway, for a presentation coming up in a few weeks, I’m sharing random bits of career advice. The title of the talk is Ride the Gravy Train …and other random career advice. I’ve collected a random assortment of interesting/bizarre/weird career advice over the years, and thought it would be fun to throw it all together into a presentation. I’ll likely use the backdrop of my own career as a storyline for the bits of career wisdom, so I think I can get it to flow fairly well.

Some samples include:

“Always put yourself on the steepest learning curve” – this was advice I received indirectly from Jim Allchin (via a Distinguished Engineer I was talking to). The idea is that if you’re not challenged, you’re not going to grow. I can think of at least 10 examples from my career where I was in so far over my head, I had no idea how I’d ever be successful – but I figured it out, and the experience of crawling my way out of the hole was huge.

Almost contradictory advice from another DE was this: “If you have a great manager who takes good care of you, Ride the Gravy Train”. Good managers watch out for your career and unblock paths you never even knew were blocked for you.

Another one I heard recently was “Sometimes, it’s a beauty contest” – meaning that doing the work isn’t always enough. Sometimes you need to put some lipstick and makeup on your work and show it around to people who matter.

I have several more, but I’d love to hear yours if you have them.

 

I came across a post this weekend about different types of knowledge It’s a well written post that calls out one of my favorite topics – you don’t know what you don’t know. I think the Five Orders of Ignorance (or my tribute to the five orders here) are brilliant, and the author nails Armour’s zero, first, and second level ignorance with his take on knowledge (described as “shit you know, shit you don’t know, and shit you don’t know you don’t know). 20I (read two-oh-eye) – what you don’t know you don’t know (aka the unknown unknowns) are a big reason why we suck at scheduling. Think about it – when we throw out estimates for how long a particular task will take, it’s often half guess, and half padding because we know “stuff” will come up (yes, there’s a lot we can do to make scheduling more accurate too, but that’s a topic for another day).

IMO, there are two pretty big things missing from this article. The first is a discussion of suitable methods to determine what we don’t know we don’t know (aka Armour’s 30I). A passion for learning, critical thinking (and the knowledge or acknowledgement of 20I) all help us identify and solve the unknown unknowns. The way we learn is to discover what we don’t know we don’t know, make it something we (just) don’t know, then make it something we know. We move knowledge down through the orders of ignorance – without a method for discovering what we don’t know we don’t know, it’s just a problem that we’ll never solve (or never know about). For some, I suppose that’s fine, but not for people who are interested in learning.

The second point is that the author doesn’t acknowledge Armour. What’s great about this is that I don’t think it was on purpose – I’m pretty sure the author just didn’t know that Armour had already discussed the same topic in depth. The unknown unknown’s will get you every time!

I’m a fan of The Pragmatic Programmer, and often use the parable of boiled frogs (which I first read in that book) when talking about organizational change. The concept is simple enough – rather than put the frogs (people) in boiling water (changing everything at once), put the frogs (people) in cool water; then slowly heat up the water (change things) until the water is boiling (you’ve reached the change you want). This technique works well for process-y things like cranking up which compiler warnings or fxcop rules you want to turn on, or raising the amount of code coverage you want developers to cover in unit tests.

The boiled frogs approach doesn’t always work as well with organizational change. With compiler warnings, for example, once you’ve reached your goal, it doesn’t “hurt” anymore – your comfortable in the boiling water. If you change the direction of an organization little by little, people may not notice right away, but eventually, they will notice that they’re sweating a lot and that their skin is bright red.

Of course, many people survive organization change – things change and they either like it, or are ambivalent to the change. Organizational change is an adaptive  challenge (as opposed to a technical challenge).  In Leadership on the Line, Heifetz and Linsky discuss adaptive challenges in depth and point out that with changes like this, sometime there are casualties – that some people, processes, etc. that just don’t survive the change. Some people may not have the capabilities to take on a new challenge, and in other situations, people just aren’t comfortable, or feel they’re at their best once the water is boiling. Casualties are ok as long as the reward of the organization change outweighs the loss.

I guess I am a casualty.

I joined the Engineering Excellence (EE) team at Microsoft nearly five years ago. Just over two years ago, I took over the Director of Test Excellence title. In the past five years, I’ve taught courses to thousands of testers, and met and worked with just about every senior tester and test manager at Microsoft. The work has been fun, challenging, and rewarding.

But EE is changing.

The changes in EE are good – maybe even great, and I think the org is headed in a solid direction – but the actual work has moved so far from what I really enjoy doing that I can’t do it anymore. I’ve wondered for some time what I’d do after I left EE, but I finally had the revelation that I needed to change something in December. Two things happened in one week that (as a colleague often says) made the scales fall from my eyes. The first was a team offsite, where we discussed the direction of the organization. The discussion was about how to deal with the parts of our job that were unfamiliar to us. Somewhere in the middle of wallowing and discussion, the lights went on – the job wasn’t for me anymore. The second “sign” was in the results of a medical physical. I signed up for an in depth health screening as part of Microsoft’s benefits, so I ended up getting two physicals in one year. The only problem with my second physical was that my blood pressure was up nearly 30 points. I thought it was a fluke since I’ve been 110 over 70 for as long as I can remember, but in a follow up checkup, it remained at 138 / 80.

I took the next three weeks away from work. I’m not sure if it was being away from work, or the mental realization that it was time for something new, but I’ve been able to drop it quite a bit since then. I’m confident that I can get it (and keep it) back completely under control from now on.

So, while I’ve been avoiding blogging and twittering over the last month, I’ve interviewed with some non-MS companies and have talked to a variety of Microsoft groups. When I first joined EE, it was really weird for me not actually testing products. I thought I would get used to it, but I never did. If I could change one thing about the last five years, I would have found some way to do more hands-on testing. One thing I heard (both directly and indirectly) as I looked around was worry that I was “stale” – that I had been away too long to be relevant. I suppose that will be something I’ll have to “earn away”, but I hope that it’s just a perception and that I actually know what I’m doing.

The good news, is that I’ve found and accepted a new job. I’m staying at Microsoft, and will be working for someone who I think is one of the best managers at Microsoft. The org is small enough that I think I can make a big impact, and large enough that it will be a challenge. Mostly, I’m working on a team that values experimentation, trust, and fun. I’m reunited with testers I’ve worked with a dozen years ago, and others that I’ve met and mentored as recently as a few months ago. I’m excited and can’t wait to be a “real” software tester again. I expect it will also give me an endless supply of blog fodder, and that the mental joy of software testing will give my health another boost in the right direction.

My last day in EE will be Feb 28. In the meantime, I have a mountain of transition stuff to work through, but do expect to be back on top of my social media game shortly. It’s been a fun ride, but I’m looking forward to even greater challenges.

I have half a dozen different blog posts started but I thought I’d write this one instead. When you listen to customer feedback, you need to treat the good and the bad equally. If some customers say “wow – this is awesome”, and some others say “this is awful – are you on crack?”, either they’re both right, or neither of them are right. People base their opinion on their experience. It’s unfortunate that you created polarizing experiences, but that’s what happened. If  you write off the negative comments as flukes, it’s only fair that you say the same about the positive comments.

We get feedback on the courses we teach for testers at Microsoft. My team is pretty good at reviewing feedback and making adjustments as necessary. I remind my team of the same thing. They need to treat the positive comments (“the instructor made the class awesome!”) and the negative comments (“the instructor was an idiot”) the same. Either throw them both out, or treat them both as valid. Obviously, you can play the balance game. If 20 students said “great”, and 4 said “sucks”, then you’re probably on the right track (although you’d want to self-evaluate on why the polarity exists in the first place). It’s a frequent topic of discussion, but one that I think everyone understands.

The concept came up again this week when a teammate pointed out that someone commented about me on the mini-microsoft blog. The comment in question was mostly positive, yet it was in response to something negative (which, in full disclosure, I replied to a week or so ago). In this case, I either have stale ideas and have some talent, or neither. I don’t really care either way, but I suppose I’m happy for the attention (there’s no such thing as bad publicity).

The important lesson to learn is that there’s no bad feedback, and no irrelevant feedback. There’s just feedback – it’s your choice to listen to it or not.

I’m surprised that many people are still asking me what an angry weasel has to do with software testing. The answer, of course, is nothing. I’m surprised however, how many people can visit my site at angryweasel.com/blog and never check out plain old angryweasel.com (where I happen to share the story of where the name came from).

I expect that this year, among other things, will mark the return of the Weasel – stay tuned.

(part 1 is here)

(part 2 is here)

(part 3 is here)

(part 4 is here)

I’ve been in the Engineering Excellence (EE) team at Microsoft for nearly five years now, and the time has flown by. The job is completely different from a typical test role, yet almost all I talk about is testing. I’ve used my time in this group to continue to learn about testing, but to this day, I still miss the ebb and flow of adrenaline that comes from working on a shipping product.

The first big project assigned to me in EE was to design a course for our senior testers. I had no idea what I was doing, but I after talking to dozens of people around the company and receiving some critical help from some of my new peers, I ended up with a course that has been well received for going on five years now, and is relatively unchanged from the original. This work led to a ton of research over the last five years on growth paths for testers (one output of that research is in my pnsqc paper from 2009). I think of the work I’ve done in EE, this work on growth and career paths for testers is what I’m most proud of.

About a year and a half after joining EE, my manager left to join another team at Microsoft. Less than another year later my “new” manager left and I, for some reason, decided to step into the director role on the EE team. I’ve never been completely comfortable in a manager role, but after some long talks with my peers (soon to be employees) about the move, I decided to give it a shot. The core of my work didn’t change much, but I did spend more time on “overhead”  – budgets, scheduling, etc. I’ve had a chance to learn a lot in this role, and a chance to work with test leaders all across the company.

I’ve also used my time in EE to study. I’ve probably read a hundred books about testing, management, and leadership; taught dozens of classes and given more internal talks than I can count. I’ve spoken externally as much as I can handle, and wrote more about testing than I ever imagined I could. All in all, I have a lot to be proud of about the last few years of my career.

What will the future bring for me?

I’ll tell you later.

(part 1 is here)

(part 2 is here)

(part 3 is here)

When I joined the CE team in 2000, l knew nothing about embedded systems, and exactly as much about non-Intel processors. Furthermore, I didn’t know what I was supposed to do on the team. The Pocket PC had just come out, but the team was already pretty much set for the next release. Given my recent kernel experience with Windows Millennium, it made some sense for me to work on something similar on CE. I was still in the reluctant test lead role at this time, so they assigned the kernel and file system testers to work for me. The problem was, that they had it covered so well that there wasn’t much left for me to do. They gave me some other stuff to own (like drivers), but they had it covered to. Sure, I got to help out, but I was sort of turning into one of those managers who does nothing but manage.

But I still had some time, and I was looking for something “technical”. One day in a meeting, I discovered that they were going to punt/postpone every single bug and feature in the shell code (shell is the GUI on top of the OS – the basic explorer shell on windows). I volunteered to do the work and for some reason my manager and hid counterpart on the development team agreed. My role became the Kernel/Filesystem/Driver Test Lead / Shell Developer. I can’t recall how I actually survived this dual role.

Working on the shell was fun, but more importantly, it was a turning point in my career. When I agreed to take on the work, I thought it was my stepping stone to a software development position. I worked closely with the dev manager and hit all my deadlines – but I also discovered something important about myself. The workload was fairly light. I was supposed to fix 40 or so bugs and add 4 features. I love fixing bugs (actually, I love the investigation process). I love to figure out why things don’t work. The features on the other hand, were sort of ho-hum. The only thing I remember writing from that time was the feature that calculates the daylight savings time rollover. I’m not sure if my code is still running in windows mobile, but at one time it was. When I finally finished all of the work and had some time to reflect I realized something important.- I didn’t really like being a developer. I was certainly capable, but the core of the work didn’t align with the core of my passions. As soon as I finished my features and fixed my bugs I met with my manager and I told him that I wanted to be a full-time tester; no more development work, and no more management. This was probably the first time in my career I really took testing seriously.

Not too much later, I became a test architect. That title doesn’t really denote a specific role at Microsoft – at the time it was more of a fancy title they gave testers in senior roles. I started meeting with other test architects (we had, and still have, a weekly meeting). There were 6 or so of us at the time and we had a handful of projects we’d work on together. We gave a presentation to Bill Gates in December of 2000 (I remember, because the presentation was on my birthday), and it seemed to go well. At the same time, I began to study testing. I started reading books about testing. I found contradictions, good ideas, bad ideas, and things that made me think of new ideas. I know a tester who says that there are no good books on testing, but I disagree completely. Every book on testing is good as long as you read it critically and use the knowledge in the book to confirm or challenge your own ideas.

So, I studied, I read, I tested. I was having fun experimenting and trying new ideas out. I began blogging while on the CE team – mostly writing about the testing tools we used for Windows CE and sharing some of the utilities and slides I was showing at developers conferences. It was a time of a lot of growth for me, but by 2005, I felt I was ready for something new. I had been in CE for about 5 years, and we were wrapping up CE 5.0. One of the testers I had mentored for several years had the passion and knowledge to be a test architect, and it made sense for me to step out of the way. I wasn’t sure where to go, so I asked Harry Robinson if he had any ideas. Harry was in Engineering Excellence at the time, and I thought he may have some insight into what groups could use someone like me. As it turns out, Harry told me that he was leaving Microsoft, and that I should apply for his open position. So – I did, and in April of 2005, I transferred to the Engineering Excellence team.