You Can Skip This Blog Entry

I’m just going to jump start my new blog here by introducing myself. Unless you are someone of renown, an autobiographical essay is likely of little interest to anyone but yourself. Since I do not want to risk boring my readers, feel free to skip this (my first) blog entry. But why then would I write this? Well one day if someone reads one of my subsequent blog entries and finds what I say to have either great penetrating insight or to be utterly without merit, they can come back here and find out just who is this character that writes those fantastic missives or vexing words.

I am currently the Test Manager for the Experimentation Platform Group (ExP) at Microsoft. "Test" at Microsoft being the somewhat regressive word for Quality Assurance, so I am a Software QA guy. Like many SQA folks I came to this business through an unconventional path. From Carnegie Mellon I have a B.S in Metallurgical Engineering and Material Science and a M.E. in Material Science and Engineering. Really, though, I have been interested in software all along… since way back programming BASIC in my TRS-80 Model I in High School and I had the pleasure of programming PL/C on punch cards via a course I took one summer at Brooklyn College. I find a lot of QA folks end up here from non-Comp-Sci backgrounds, with Physics seeming to be a recurring theme (maybe because there are only so many jobs manning the super-collider).


I tried working as a Metallurgist. While I did enjoy using science, a scanning electron microscope, and powerful acids to solve puzzles on 'just how did this thing break and why?' (Notice QA seems to have been in my blood all along), the acids are rough on the fingers and I didn't see a long-term future in steel. Since I enjoyed the time spent creating programs and spreadsheets to analyze the results, I thought I would escape to academia to get my Ph.D. and do research.


However, I honestly got bored of material science before I got the Ph.D, so with Masters in hand I saw an opportunity to transition to a more computer software related field. I took a job that leveraged my knowledge of metals and the physical sciences, but got my foot in the door in software programming. I joined a firm that built steel mills as the engineer who wrote the software to control those mills.


Imagine two steel rolls about 3 feet in diameter. Now take a 10 ton slab of steel, red hot at 2400 degrees Fahrenheit and repeatedly pass it between the rolls at smaller and smaller gaps applying thousands of tons of force and millions of foot-pounds of torque so that you end up with a coil of steel.


My software did that. The thing is Tippins was not a software shop…and I was not really a software engineer (yet). I knew little about good software process and was more than happy to do everything from design to coding to testing to field installation and debugging all myself. Yes I tested my own code…I did not even know there was such a thing as dedicated software QA. Since Testing in Production (TiP) will be a common future topic of my blogs I will admit that at least 30% of the code (not just mine, everyone's) got developed in the field after we installed and saw what worked and what didn't. Exciting times, and you really appreciate QA when you’ve seen some of the spectacular wrecks bad code can cause on a 5000 ton hot mill.

Tippins was a great job for teaching me not just about how software was made, but how it was used. I travelled the world: Thailand, Korea, Canada, and even the Mon Valley outside Pittsburgh with my code and made it work to deliver product…real product as in hot steel. Tippins also was where I got my first taste of management, though that wasn’t in the job description. My first forays into leadership occurred when I, an engineer halfway around the world, found myself the lone representative for my company when critical decisions had to be made. I learned to operate autonomously, to make the hard decisions that needed to be made, and to listen to the customer (and sometimes not listen to the customer).


Then in the heady dot-com days of 2000, I got my chance to join a start-up and leave metals behind forever. CoManage may have been the best job I ever had - working day and night on a cool new product in a cool new space and not even noticing the time flying by. In the bubble days of 2000 CoManage needed SQA people and there was a people shortage… so I got my introduction to QA…and to networking…and to real software processes.

I quickly realized this was my "fit". Within mere months I was in the highest level meetings for go/no-go and next steps for the product. I still did not have the formal QA background and was primarily doing black-box testing, but I had the knack for it. I quickly became the subject matter expert on how the product worked, and I got pulled into many customer engagements to track down those hard to find issues. Here I learned one of the true values of a good QA engineer is they know the product end to end and inside out. I moved on to technical lead of the QA group, and played a key role in shaping the SDLC processes. Our “PIG” - Process Improvement Group - took input from the engineers and put together the guidelines for the company to follow.

It was here I learned that a right-weight waterfall process for a small company can work (I may blog about this sometime). Later, missing the hands on coding, I did time as a developer, but all the time staying involved in end-to-end issues with lots of field deployments. Like with Tippins, I traveled the world but this time England, Italy, and Kansas City were the main destinations. Again Testing in Production plays a role once on the customer site. Out software interrogated high end network equipment which we did not always have access to when we did our development back in the office. The final development happened when we got access to the equipment at the customer site. In a future blog, I may tell you about the day I knocked out phone service to part of Kansas for a few hours.


The wife and I were looking for a change in venue. We were living in Pittsburgh and it was just fine, but we thought a change of scenery would be nice. We had visited Seattle previously and liked it, and I had a friend at Amazon who liked that, so I put my resume out there. I landed a job with the group that handles the backend catalog of item and offering data. It's an interesting problem considering Amazon had over 65 million items when I was there (and that number will be woefully out of date as of the time I write this).

I joined as an SDET and assumed a technical lead position on several projects. Further honing my leadership skills I pursued an opportunity with the Digital Media group (specifically Amazon Unbox, the Video Downloads folk) as a Dev Lead there. With that group I was introduced to scrum. As the scrum master I quickly realized an appreciation for this tool to manage time, resources, priorities, and communications in order to produce great software. I took that group from a disorganized proto-scum process back to whiteboards, stick notes, and burn-down charts so that they could see their progress and know where they stood with respect to the sprint and each other…. It was valuable and effective. Under my leadership the Unbox group produced several high value features including the TiVo buy on screen experience and the Video pre-order/season pass.

But it grew readily apparent that I missed QA. As I started to look outside the group for QA opportunities, the QA Manager position for all of Digital Media (including not just video but MP3, Kindle, and all the backend support systems such as ordering and delivery) became available.

I was a natural fit. This was a great job with a great team. I could write an entire blog entry just on the great products and features produced and certified by this QA team. The Kindle launch, MP3 launch, and Video streaming come to mind. But I will instead focus on what we did to build the Amazon QA community. Craig Zhou who came from Microsoft (and is now back at Microsoft) did a great job rallying the Amazon QA troops and one of his initiatives was spearheading the creating of Engineering Excellence days. As part of this I made sure my team was involved in education and dissemination of information about tools they had built for test automation. My team was involved with either leveraging, evangelizing, and providing technical improvements to tools built by other teams, or in cases were no other tool solved our problem we sought consensus (at least much as we could get) to build our own. These included primarily test execution frameworks.

In addition to the tools fair portion of Engineering Excellence days I served on the panel headed by Senior VP Brian Valentine that answered questions from the engineering community about QA and engineering excellence at Amazon. My interest there was primarily around QA career growth. I had been involved with QA career pathing on a company-wide level at Amazon, having contributed to the SDET career stage documents, technical manager career stage documents (representing QA), and having lead the QA Engineer career stage documents. If engineers feel there is a glass ceiling on the QA path then I am dedicated to, if not shattering that ceiling, carving out a nice size hole for talented individuals to get through and rise as high as their skills will take them.


So after almost 4 years at Amazon a terrific opportunity to join the ExP team at Microsoft presented itself and I am happy to be here today. Since I will probably write a lot about ExP, online experimentation, and Microsoft in future blogs, and since this is getting long, I will save the details of my Microsoft adventure to date for another day.