The Matrix Organization and the Future of Test Management

I stumbled across an article by Steven Sinofsky where he discusses the merits of the Functional vs. Product team (tl;dr – managers of a discipline – e.g. all testers vs. Feature teams). Although the article was published just a year ago, Steve is discussing an organizational change from a decade ago in Windows where development, test, and program management all reported to respective vice presidents of those roles. If my memory is correct, there were over 3000 testers reporting to a VP of Test. Of course, everyone interacted, but Steve was a huge proponent of BUFD and test-last approaches, and I think the product quality reflected that approach.

Reading the article about functional testing reminded me how much that model doesn’t work – but here I am in 2017, and I’m the manager of a QA team of almost 40 people…

But it’s not the same. I think a lot of QA/Test organizations today (mine included) are run as a matrix organization – meaning that people in my organization have two different reporting lines. They meet regularly (including 1:1s) with feature team leads, and meet with me (1:1s and informally) to help solve problems, brainstorm, or share stories.

In Agile Testing (Crispin, Gregory), there’s a line that captures my feelings about the manager role exactly.

Rather than keeping the testers separate as an independent team to test the application after coding, think about the team as a community of testers. Provide a learning organization to help your testers with career development and a place to share ideas and help each other. If the QA manager becomes a practice leader in the organization, that person will be able to teach the skills that testers need to become stronger and better able to cope with the ever-changing environment.

In this model, I’m responsible for making sure my team have the skills and knowledge to be successful. I like the idea of being a practice leader, and think it serves the team well.

Long time readers may recall that when I joined Microsoft Teams, I was the sole quality guy in charge of getting a bunch of developers to worry about writing quality code. That model (mostly) worked as well, but probably only because I have a chunk of experience both in testing, and in dealing with ornery developers. A main point is that I didn’t really have embedded testers on that team, and overall, the team was quite non-agile anyway – but I did a good job on that team making sure we had a quality product despite ourselves, and I’ll always be proud of that.

I bring up the Teams story, because I can see a path where I do not have a team (or not a large) team anymore. As I build a community of practice around test and quality, and as our development teams take on more and more responsibility for quality practices, I can see a world where (most of) my team reports only to feature team leads, and my role (if it’s worthy of employment) is purely a practice leader in quality and testing for my organization. It won’t happen next month, and not even next year…but it’s a path that makes sense to me (and one I’ve mentioned on the podcast a few times too).

And of course, if I can see this future, odds are that someone else has already gone through this exact transition, and more will follow.

And so begins the downward spiral of the Test and QA Manager. May we all survive the revolution.

Similar Posts

  • Why bugs don’t get fixed

    I’ve run into more and more people lately who are astounded that software ships with known bugs. I’m frightened that many of these people are software testers and should know better. First, read this “old” (but good) article from Eric Sink. I doubt I have much to add, but I’ll try. Many bugs aren’t worth…

  • Making Time

    Yesterday, a colleague asked me where I find the time to blog, twitter, etc. This is something I get asked often, but the only answer I have is that I just make time. I put blogging, presentations, sasqag work, and other community stuff right alongside my core work on my todo list. I’m heavily driven…

  • Time Flies

    I wrote a bit of a career retrospective just a few months before I joined the Communicator team at Microsoft (the series is captured in these posts: (part 1 is here, part 2 is here, part 3 is here, part 4 is here, and part 5 is here). June 6, 1995 – exactly 15 years…

  • 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…

  • Exploring Test Automation

      I try to read a lot about testing in blogs, articles, books etc. A few days ago, I came across this quote, and it struck me in an odd way. “Commonly, test automation involves automating a manual process already in place that uses a formalized testing process” The source doesn’t matter, as it turns…

5 Comments

  1. In your matrix organization, does your QA staff report to you on a solid line or dotted line? I’m curious who their primary manager is, and whether that is likely to change.

    1. Excellent point. The QA org has reported *directly* to me up to this point – BUT, to make things easier for finance (and for other reasons), I’m moving a big chunk of my org to work for product / feature owners, and those folks will “dotted line” report to me.

      One thing I’ve been clear on, is that while the reporting structure changes, nothing else does.

Leave a Reply to jlottosen Cancel 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.