Share via

Engineering Lead

  • Article

In the last six months, I've transitioned from a QA Lead to an Engineering Lead position.  I'm still a persistent and tenacious driver of quality.  Now I get to influence the development process as well.  It is a great opportunity for me to optimize development for the benefit of quality, as well as a great career challenge.

I began my career as a product support engineer.  I was a temporary Microsoft employee for two years.  Despite all the negativity you might associate with that, I found it to be an excellent opportunity for me to learn and prove myself.  I started in phone support for Windows 95.  It was 2 weeks before Win95 was released and it was a very exciting time.  Product Support Services (PSS) was a fantastic environment for me to learn.  There was a lot of knowledge about Windows, networking, memory management, etc.  I just soaked it in.  So many people were happy to help others learn.  It was easy to find experts.  It was the ideal environment for me to learn since I could ask dynamic questions of an expert.

After 10 months of that, I knew I needed a change.  Although I enjoyed helping customers, the number of unique issues I encountered on a regular basis wasn't growing.  I was tired of hearing about how these issues negatively impacted customers and I wanted to go to the product team to find these issues before they were released.

So I became a manual tester.  My job then was as close as I've ever been to the persona we use to to design our Test Case Management product.  I tested third party applications to make sure they continued to work on new versions of Windows and Internet Explorer.  Next I worked on NetMeeting, testing the multi-conference scale and configurations.

During those two years, I was fascinated with what one could do with programming to automate things.  Whether it was a simple Excel macro to make a compelling report, a log parser to normalize disparate log formats, or automation to more quickly test an application... I was hooked.  I think at our core, all programmers are a bit lazy and we're attracted to the idea we can invest a bit in an application or script to do work for us.  :)

I finally made my entrance into the world of programming as a Software Design Engineer in Test (SDET) and became a full time employee.  Back when I started it wasn't the most common type of tester we have at MS.  SDETs are developers who use their programming knowledge to test the product.  It could be API testing, performance, or scalability.  We've even tried to automate UI tests with many essential attempts and failures over the last decade.  We learned a lot of lessons and each iteration gets a bit better than before.

I've worked on many different MS apps as an SDET including Microsoft Works, MSN Small Business, ActiveSync (desktop sync for Windows Mobile), and Exchange ActiveSync (wireless sync for Windows Mobile).

Eventually I became an SDET Lead.  I didn't think I'd like being a people manager, but I've learned differently since transitioning.  More on that in a future blog.  As an SDET Lead I championed quality, trained new testers, triaged bugs, and took part in product design.  My goal was to drive for quality at every stage.

It was difficult to convince my development leads to change their approach.  Now that I'm an Engineering Lead, I have the authority to make direct changes up stream.  I'm not out to ruin development at the expense of quality.  Now I feel I can make both better.  Scrum and agile have been a great guide for bringing that to my team.

Comments