disrupt_tech_managementIn our modern tech world, the holy grail is to come up with a new idea or develop new technology that is such a game-changer that it “disrupts” an existing industry. If you want attention, success, and respect in this industry, disruption is the way to go.

But what if you’re in tech management? There’s a temptation to feel like you need to disrupt there too — come up with a game-changing playbook — in order to be on the cutting edge. But while our ever-changing tech landscape naturally leaves doors wide open for new ideas, there’s less reason to imagine that the task of organising a team of engineers to construct something should change dramatically from one decade to the next. So maybe we should consider trying out some old-school ideas.

One of the key components of Scrum and other modern management playbooks is the idea that the team should manage itself. As I explained in my previous article, the tech industry has a huge problem with undervaluing management skills — indeed treating management as though it’s not even a task and doesn’t require skill and expertise. I think the idea of “self-managing teams” is the fruit of that misconception.

If your company needs a custom internal app, you’re not going to make a committee of the accountant, the communications director, and the lawyer, give them a weekend course in design patterns, and tell them to go to it — even if they’re the ones who are going to use the app. You would hire an engineer. Even for a task that requires less specific training than programming an app (say, writing the content of your company’s brochure), you would give that task to someone who is qualified to do it.

Now, if you take a team of engineers — all of whom were hired specifically for their engineering skills — there is no particular reason to believe anyone on that team is qualified to manage it. Chances are that there’s at least one person on the team who is not qualified to be managing other people and projects — so making them all manage together as a committee doesn’t really help. The only way this idea makes any sense is if you believe that management does not require any skills.

Good Fences Make Good Neighbours

As just one simple illustration of the problem, consider the old adage that good fences make good neighbours. In this context, I mean that engineers can easily get into interpersonal conflicts. Even if everyone involved is a valued employee and a productive contributor to the team, they sometimes step on each others’ toes. Sometimes friendly competition turns sour.

In such cases, a skilled manager can see it developing and nip it in the bud before it grows out of proportion. Something as simple as moving someone to another task or just listening to each person individually and validating their perspective can completely resolve the issue.

The one thing you most want to avoid is escalating it. By, say, getting the whole team involved. So that the people who perhaps weren’t aware of the conflict and/or didn’t have an opinion about it are encouraged to form an opinion, in order to contribute to the meeting. Say, in a “retrospective” meeting about how the last set of tasks went.

It doesn’t matter if the rulebook specifically states that the meeting isn’t supposed to be about criticising people. When you criticise actions, you’re just putting a thin veneer over criticising the person who did them if everyone knows who did what. And sometimes the problem really is a person, in which case a rule against criticising a person is a rule against addressing the root of the problem, which prevents it from being resolved.

Authority, Responsibility, Accountability

Another problem with eliminating the position of team manager is that when you eliminate the chain of hierarchy, you also eliminate the chain of responsibility.

The project manager or team manager is the one who is ultimately accountable for ensuring the successful completion of the project (or the timely warning if major unexpected problems arise). The manager needs to be someone who says, “the buck stops here.”

A colleague of mine once explained that the problem with managers is that they just promise the higher-ups whatever they want to hear, and when it doesn’t materialise, they just blame their team. Yeah, no. I’m sure that sometimes happens, but that’s what’s known in the biz as being completely incompetent at your job as manager. You can maybe get away with that once, but your error should be the experience that gives you a more realistic picture of what your team can deliver, and how fast. If you make a practice of scapegoating your team, then you’d better hope that your own boss is similarly incompetent — otherwise, prepare to look for some other line of work.

By contrast, when “the whole team is responsible,” then no one is responsible. After all, nobody on the team is “the whole team.” I’m not joking when I say this — that’s how it ultimately registers when a team misses a sprint goal.

I guess the theory is that everyone on the team should feel personally responsible for meeting the team’s goals. But individual team members — even if they have the right ideas for how to make the project succeed — don’t have the authority to make the decisions. If one person made a good suggestion that was ignored by the team committee in the planning meeting — and that suggestion very likely would have led the to the project’s success — then, no, that person isn’t responsible for the team’s failure, and shouldn’t be held responsible for it.

Really, no one on the team should be held responsible for a failure caused by internal management issues if nobody on the team was hired to be (or given the authority to be) responsible for managing the project.

But what about startups?

Startups, of course, are often too small to have even one team that’s large enough to have a dedicated manager. In that case, let me roll back what I’ve said above a bit. I do think that if you have a team of just a handful of people who have a good rapport, then you don’t necessarily need a full-time team manager. But as I said in my previous article, this is something that changes quite rapidly as your startup grows, so you need to prepare to make good decisions about how your IT team will be organized as it grows.

If you have one person who has the skills to be both the lead architect and the team manager, then by all means have one person do both. But if you don’t, it’s better to split these two jobs than to give both responsibilities to one person who is only qualified for one of them.

The problem with having a team be managed by a tech lead is that the role contains an inherent conflict of interest. If you got your job by being the best engineer, then you succeed if the project succeeds… or if you can demonstrate to your boss how much smarter you are than your colleagues. The latter, unfortunately may not include the project’s success.

If, on the other had, your job is manager, then you succeed when your team succeeds and your project succeeds. Full stop.

Why would you want to disrupt that?