Software engineering career trajectory in Quality.

Being that I am having trouble sleeping tonight I decided to go ahead and use this time to get my blog out for this week (sorry it is late).  As most of you know Microsoft went through some tough layoffs last week.  This hit everyone in the company in different ways.  Some obviously found themselves looking for work and those that were left had to deal with such feelings as survivor’s guilt, a loss of security, and generally regrouping and taking some inventory.

As discussed in earlier blogs the Quality Discipline at Microsoft is going under some revisions and reorganization.  Some of these changes include:

  • Drawing down QA organizations to be 1 QA engineer for every 2 development engineers
  • Increasing the importance of data sciencesĀ in the QA discipline
  • Disconnecting QA organizations from software feature development
  • The technical bar is being raised for QA
  • More focus on fundamentals like Performance, Security, Localization, etc.
  • Moving more of the code, build, and functional quality to the development team

A lot of these changes above are good ones.  The couple that I am not so excited about are “Disconnecting QA organizations from software feature development’ and over indexing (IMHO) on “Increasing the importance of data sciences to the QA discipline”.  In the first I believe that separating the activities of the QA organization from the feature focused approach of the Dev and PM orgs only further distances the Quality Engineers from the organized work of the product group.  We are already seeing the negative impacts of this change when it comes to communication and planning.  In the second, data sciences is a super important part of the product learning and customer focus we have but the expectation seems to be that Engineers that used to do more functional validation activities are now supposed to become experts in aggregating and deciphering collected telemetry and usage data.  This retraining perception is becoming disruptive in my opinion.

The biggest hurdle I have as a manager right now is to work to change the perception of the QA engineer’s career trajectory.  Most of the engineers I talk to (both QA and development employees) see their ability and potential to achieve a target in their career is best described with help from the graph below.  I say perceived because the culture in the industry and our company tells them this.  QA engineers do not feel as valued as their dev counterparts.  This culture has got to change or I fear that we will loose not only good engineers but the great progress we have made in software engineering shipping products with an appropriate level of reliability and quality will start to suffer.

Perceived Career Directory

How do we fix this?  Well, it will not be easy.  We need to raise the technical bar for the QA engineers we hire.  We need to change our engineering paradigm to not only allow QA engineers to write product code at appropriate places in the development cycle but to expect it.  Then we need to show that these engineers with the tester-gene can add tremendous value by seeing the product as a system and catching really hard to find issues and ensure the customer love we all strive for.  When an engineer succeeds in contributing to shipping code and is able to affect the product in a positive way unlike your average developer we will prove our value and be sought by product leaders to augment and uplevel their teams profitability.  We will not be able to just tell people this is the way it is, we have to show it.

Whether we can do this as a separated discipline or not is yet to be seen.  The other option is to do away with QA management roles and move QA engineers to Dev leads/managers.  With current Microsoft dev managers (been at the company for 8+ years) I fear those QA engineers would just be used as lackeys to solve build and infrastructure problems.  As QA leaders the weight rests on us to influence product and dev management to adopt and accept this new approach.

Do you feel that your company has this problem with their QA engineering orgs?

Do you think this is a problem across the industry or just isolated to certain companies?

Do you have a different view or other ideas on how QA can change their perceived value?