More on careers

I left out a couple of obvious things in my career post yesterday and thought I’d write them down before I forgot.

Managers

Yesterday, I wrote about the non-management career path for testers at MS. There is, indeed, a career path for managers – I just tend to talk about the non-management career path because that’s where I’ve tried to keep myself. We have two titles for people managers at Microsoft. We call managers who manage a team of non-managers Leads, and call managers who manage leads Managers. In other words, a Test Lead manages testers, and a Test Manager manages test leads. Got it?

Generally, Test Leads are in the Senior band, although it’s somewhat common to have leads in the upper ranks of the SDET IIs. The level of knowledge (and more importantly, amount of different testing experiences) testers have by the time they get to these levels gives them the confidence, ability, and credibility to be successful. Leads are expected to get some “real” work done in addition to managing their team. Test Managers are typically Principal or higher (although, as with Test Leads, may be in the upper bounds of Senior).

Something else to note is that the Lead role does not necessarily need to grow to the Manager role. If you are a lead, but never want to manage a large team of leads, you can grow to Principal+ levels as a lead. Or, you can be a lead for a while, bounce back to being an individual contributor, and bounce back to being a lead if you desire (and if the opportunities and business needs are there).

Another take on career stages

I recently re-read Spolsky’s Smart and Gets Things Done. That (the title, and the description from the book) is pretty much what SDETs and most of the SDET2s do. Senior SDETs (and SDET2s who are on their way) move to a stage of Smart, and Makes Stuff Happen. It’s one thing to know how to do stuff really well, but leaders are able to make stuff happen through influence (and the help and support of others). We expect Principal’s (and those about to be Principal) to think more about How Stuff Happens. Strategy, decision making and and solid systems thinking all feed into the “how”. Of course, you still need to dive into making stuff happen and getting things done once in a while, but setting the right direction, for the right reasons, is critical.

Similar Posts

  • PBKAC?

    Yesterday, I read a mail sent to an email alias I’m on, where the author was asking why tool X wasn’t enabled on his latest build. The mail looked something like this (genericized to protect the innocent). foo.service doesn’t appear to be working Repro: I installed the build from <build_path> I verified the binaries existed…

  • Scaling Code Coverage

    I’m going to do one more (I think) post on this subject. Markus asked the following about my latest post: But how do I answer the question for “what’s the coverage of your testing?” for a multiple component-based application, consisting of a C/C++ major component, an application server, and customized business logic? The answer is…

  • The future of the automation engineer

    Although I’ve tried to avoid writing about test automation since publishing The A Word four years ago, I suppose I should probably take some time soon to add a few more chapters before the book (like my last one) becomes largely obsolete. Not too long ago, I posted some predictions. In those predictions, I said: Testers writing…

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.