This is a transcript of episode 180 of the Troubleshooting Agile podcast with Jeffrey Fredrick and Douglas Squirrel.
Squirrel rants about matrix management and then Jeffrey calms him down by describing self-managing team structures that work better. They agree that multiplying responsibilities and separating them from the place where the work happens is a bad idea.
Show links:
Listen to the episode on SoundCloud or Apple Podcasts.
Introduction
Listen to this section at 00:13
Squirrel: Welcome back to Troubleshooting Agile. Hi there, Jeffrey.
Jeffrey: Hey Squirrel. We were talking before the podcast and you mentioned something in passing and said, ‘of course, we talked about on the podcast before.’
Squirrel: ‘Of course we have! I can’t believe it, we haven’t?’
Jeffrey: No, we haven’t! I said, no, we haven’t. Then you said, ‘OK, we haven’t recorded an episode, but you and I have talked about it before.’ And I said, ‘nope.’ So we get to do kill two birds with one stone. What was this topic that you’re ready to rant about, which you and I have never discussed before?
A Profusion of Leads
Listen to this section at 00:45
Squirrel: I get really riled up over situations in which people have a people leader for their team—by team I mean four to six people—and also a tech lead, or something like that. I get myself in all kinds of hot water because when I see a person who’s leading that team and making sure that they deliver stuff—not the product manager—the person who’s doing the people leadership, and the accountability for where that team is going, and making sure that the team is managing its technical debt, and lots of other things, as well as probably writing some code…I call that person the tech lead. Some of my clients call a tech lead something else. They say a tech lead is a person who just does technical leadership: just looking out for the technical choices the team makes, maybe reviews, pull requests, but doesn’t manage the people, doesn’t have accountability outside the team. There’s somebody called a ‘delivery manager’ maybe who’s in charge of that. Then there’s sometimes also an ‘engineering manager.’ I get this all very confused because I think of an engineering manager as a person who manages engineers, and that’s a tech lead! I kind of know who that is. So I get terribly, terribly confused by these complicated models. They go under names like ‘Matrix Management’ and other things like that. They try to draw charts for me with multiple dashed lines all over the place, I get completely muddled. The very worst one I’ve seen I didn’t change because they told me it was working, which I doubt. In it, you could pick a mentor from anywhere in the organization. So you had your technical leader, your line manager is for people issues, and then you could have a mentor. The org chart was crazy. There were different types of dashed lines, some of them had to reach all the way onto the other page, it was nuts. I get driven nuts by these complicated organisational structures when we have one that we’ve been using for a fair amount of time. It seems to work and it’s called a tech lead. So that’s my rant. What do you think?
Jeffrey: Well, welcome back.
Squirrel: Yep, I’m down on earth again.
Jeffrey: I do have one question here. You said this is the small team version, four to six people. Let’s maybe up that to eight to twelve? Two pizzas. That’s about the modern team size.
Squirrel: You might have many of these teams! You might have ten of these. In my view, each of them has a tech lead and a product manager, and those two are cooperating and life is good. There’s almost certainly people above them. I just don’t understand this crazy matrix stuff.
Jeffrey: At TIM we moved from a structure probably similar to what you’re describing to self-management. As part of that, we decomposed the job of the technical lead, though the title we had was engineering manager. As we discussed it, we found it had different types of responsibilities bundled into this one person. I think that’s part of what you’re saying: you’re used to having what you’re calling the technical lead here be both people management plus technical leadership plus project coordination and all in one person.
Squirrel: Yep! Some of those are shared. For example, in this model that I’m used to, project coordination is shared between the product manager and the technical lead. We have a whole episode on the ‘How’ shirt and the ‘What’ shirt, link in the show notes. I know we did this one, don’t tell me we didn’t.
Jeffrey: We did do that. That’s a good example because there the ‘how’ and ‘what’ was divided. They’re coordinated, but the technical lead—in your parlance here—is wearing one of those shirts.
Squirrel: Exactly.
Jeffrey: They’re wearing the ‘how’ shirt, for anyone who’s not sure. At TIM we were moving towards an increasingly self organised department, having people signing up for different projects and moving between them without necessarily having managers decide that. It was as part of that change that we wanted to understand ‘what is the manager doing?’ And we made a distinction then between these three roles. We observed we had bound together three different concepts, the people manager, the technical lead and the project lead. But those don’t need to be the same person. These are really different skill sets! The kind of interest that someone has as a people manager is different than someone might have as a technical lead. I think it’s common in smaller start-ups to have experienced senior developers who can easily handle both. But if you project into the future, these people are going to have different paths, different areas of speciality. There’s some advantages to allowing people to do the part they care about most. So you have these people managers who care a lot about skill development, people’s career paths and so on, and the people who really care about the technology. In my experience it’s not optimal that the person who is really focused on technology says, ‘oh, and then I also have to do the people management stuff.’ The concern would be that they give really short shrift to the one on ones and people development.
Squirrel: No, we certainly don’t want that. In the model I’m used the person who does people management, who is accountable for the how, and who is responsible for making sure decisions are made, is the tech lead. There might also be senior engineers on that team who have that different career path. But they start out as people who are writing code in a team with a senior technical focus. If you want to give them a fancy title in the team, I’ve no objection whatsoever. But the delivery management or accountability for what the team is producing, and staying in touch with what techncial decisions are being made, and the people progression of those people? If you try to separate those three, I don’t see great success. Did you find that that worked? That would surprise me.
Fragmentation vs. Distribution
Listen to this section at 08:32
Jeffrey: We found it worked.
Squirrel: OK. How?
Jeffrey: You have to understand, we we went further than that and actually ended up removing the people management role. Essentially, that one dropped away. That’s probably getting into the larger ends of self-management. But it really it went down this route of self-organisation. That sort of coordination you’re talking about became a team activity. ‘That person’ who is responsible for the how became instead a shared responsibility in the team. I will say, the fact that it’s shared responsibilities does not mean it’s equal responsibility. There are people who have much more affinity for what the product manager was trying to get done or what the client interests were, and they could really plug into that. There are other people who really plugged into the technical issues and the technical architecture. Those things were worked out amongst the group using this amazing tool that I think everyone should learn about, something called ‘conversations.’
Squirrel: Oh, amazing. You should write a book about that.
Jeffrey: Truly. But this is the key point: I think what made it work was rather than slicing the responsibility and giving it to individuals, it was about having a collective where many voices were put in. These things need to happen. You need to have technical decisions made. There needs to be coordination with the product manager. There needs to be a client focus. Those things still need to happen. That becomes a joint problem for the team to solve.
Squirrel: That’s not one that I object to. If you can make a team work that way, all power to you. I’m not Jeffrey, I haven’t had the privilege of working with a team over a long period. I tend to be quick, come in, help a team, move on. But the anti-pattern I often see is where someone says ‘we will not have broad responsibility for decisions about how or about roles or accountability for progress. We’re going to have a person in the team called the tech lead, and their only responsibility will be technical decisions and it will be just them. Somebody outside the team will be the engineering manager of a number of people in a number of different teams and be in charge of the people leadership.’ That seems the opposite of what you just described, because it’s separating the decision making even further. Am I understanding you correctly there?
Jeffrey: I think you’re right. I will hasten to add, anything can work if the dynamics on the team are right.
Squirrel: As we always say.
Jeffrey: I have seen the pattern that you’re describing and most often it doesn’t work. Most often what it leads to is alienation from the team, because what you have is a proliferation of the number of people who have decision making authority, and it’s clearly not them. There’s other people making essentially every type of decision. ‘I’m clearly one of the people who’s not making a decision.’ It tends to lead to a combination of either fragmentation, where you have these small teams only worried about their own lone technical problems rather than alignment with the project and delivery, or people feeling disempowered because they’re not getting a say in what’s happening and they feel left out.
Squirrel: The worst case is when those different people disagree! You have your engineering manager and your tech lead and if they don’t agree and tell you opposite things, then what do you do? This is the part I can never figure out about this matrix management stuff. In your model where the team is self-managing, there are processes and tools and culture and ao on, you’ve spent a long time setting up such that the team can make those decisions. The kind of situations I come into are nothing like your team. They’ve got an awful lot more dysfunction.
Jeffrey: The thing you spoke about that really stood out to me was you said you had this org chart with a line for mentors. I thought that’s really strange. Why is that even on the org chart? That feels like people are trying to control things being able to draw static diagrams rather than having the right dynamics in the group. That’s what it sounded like to me.
Squirrel: That’s what I observed a lot. And guess what? That’s my stock in trade. So I’m happy to work with teams that aren’t functioning well, but I sometimes do have to let it out and rant a bit about what’s not working. So thanks, everybody, for listening to me ranting. Thanks, Jeffrey.
Jeffrey: Thanks, Squirrel.