Pair Leadership?

This morning I was walking the dog and thinking about a few different projects I'm working on. I seem to always have 4-5 "big" projects going on and my thoughts tend to bounce between them. Often, when I let my mind wander like this, I come across some idea that makes so much sense that I'm compelled to do something with it. Sometimes I just make a note of it, sometimes the idea turns into a conference proposal or paper, and other times, I just let it sit and stew for a while. Today, however, the idea will become a blog post.

I have spent most of my career as an "individual contributor" (Microsoft speak for someone who doesn't manage people). In the five or six years previous to joining the EE team, I reported directly to a director of test. My peers were senior test managers managing teams from 15-30 people each. My role included technical leadership for the test team, mentoring, process improvement, cross discipline initiatives and various other projects. The reporting structure did a lot to enable me to be successful in my job. I took part in the "leads meeting" and was part of any other initiatives taking part among my peers. My peers (the test managers on my team) trusted me to advise and direct their teams, and my manager benefited from the technical growth on the team.

I could go on with the benefits of this, but the main point is that I highly recommend that senior non-managing testers work as peers with senior managers, and are involved relatively. I think this structure benefits everyone immensely. The team benefits from a senior technical leader, the manager benefits from having someone own strategy and growth, and the senior tester benefits from learning how to effectively influence without authority in a leadership role.

I think this concept works at any level of test management. In my group, each of my test manager peers had several "test leads" reporting to them. As I think about this, I think it makes complete and perfect sense that anyone who manages managers have a non-manager technical leader reporting to them as a peer of their managers. For those of you who like pictures (and further proof why I shouldn't be a manager), here's a diagram of what I think every test org should look like.


The "IC" can worry about technical growth, leadership, strategy, etc., and the managers and leads can focus on the management aspects of their jobs.

It also gives non-management folks a reasonable and challenging set of positions to grow into. (note that the diagram above does not represent the number of leads or people reporting to leads I think is appropriate - I'm just pointing out that I think test managers are doing themselves and their teams a disservice if they only have leads or managers reporting to them.


Comments (2)
  1. Alan Gregory says:

    I apologize to being dense.

    What are "testers"?

    Alan Gregory

  2. Alan Page says:

    In this context, I’m referring to software testers – those who do some aspect of verifying, validating, or improving software through exercising the product (definitions may vary, but that should give you the general idea).

Comments are closed.

Skip to main content