Using Matrix Management to save your search for a unicorn

If you’ve managed technical teams you’ve probably come across this challenge: the junior team members need a good leader, yet they’ll only respect somebody with a strong technical background. Finding somebody who embodies both of these qualities can often seem like hunting for a unicorn, and even if you find that elusive person they soon become unhappy because they don’t get enough time at the coal-face. What can you do? Well, a version of matrix management is something I found can work well, and that’s what this post it all about.

Matrix management is a structure where individuals have more than one reporting line, and is often used in larger organisations to bring together people from different disciplines under one manager – typically for a long project – and often with mixed results. The purpose here is quite different: to ensure that junior staff benefit from both good career development through effective line management, and good technical development through effective technical mentoring.

The solution I describe is best explained through an example that worked well for me in a Scrum organisation. I employed experienced people managers to cover the disciplines of QA, Projects, Release and Technology, and they took on line management of all of the developers, testers and designers. Each Scrum team had previously been run by a Team Lead, whom I moved back into a Senior Developer role but gave them a technical mentor role to the rest of the team. The split of duties between was then as follows: Technical Mentor - mentoring of technical development of staff, and go-to person for people outside the team with technical questions. Line Manager - appraisals, objective-setting, training and career mentoring.

There are a few things to note. Firstly, don’t underestimate the reaction you’re going to get from anybody from whom you’re taking away line management duties (e.g. a team lead) – even if they say they’ll be relieved to get back to “real work”, they could really see it as losing power or status, or they may think they’ll be happy but then regret it. You need to be crystal clear with them on the new split of duties, but also discuss with them the career direction they next wish to take (e.g. architecture, data) so that they know they’re embarking on a new journey rather than just finishing an old one.

Secondly, give plenty of time for everybody in the organisation to understand which of the two people they need to speak to about what. The solution here is to repeat, repeat, repeat your communication about the changes and keep a close watch on who’s asking what of whom for a few months after the change. Keep a clear division of duties between the two roles and mentor those people closely to ensure they’re not bleeding into the other’s area.

Thirdly, expect a lot of questions about career development. Junior staff may think that management is now closed to them as the team lead role is defunct. You should offer other clearly defined routes to progress such as application architect, scrum master, automation tester, or devops, and don’t close the door to line management either if that’s what a person really want to do and shows an aptitude.

Finally, while this may seem a very “management” exercise, I’ve found it works very well with a Scrum setup as it can accelerate the ability for teams to self-manage. Without the perception that a lead is looking over their shoulder, and the removal of a line management layer, team members should take more individual responsibility for the technical direction of their product.

Running matrix management is more complex than regular pyramid-style management, but it brings clear benefits in giving developers two dedicated people who can advance both their technical development and their career. As with anything you need the right people in the roles, but assuming you can do that, it’ll mean that your search for a unicorn is at an end.