tatiyants.com Management Anti-Patterns on Product Teams

There are many ways to structure the management of product teams. Some of those management roles are vital, while others can be really problematic.

Below is a list of roles I find to be anti-patterns for product teams. To be clear, I’m talking about these roles strictly in the context of teams focused on building software intended to be sold to customers. In fact, I’m sure that some of these roles do have their place in technology organizations focused on supporting enterprise needs.

With that disclaimer out of the way, enjoy!

Director of QA

What does a Director of QA do? It varies, but the following job description is in the ballpark:

The Director of Software Quality Assurance is responsible for ensuring that solutions are developed, tested and implemented in a consistent manner while meeting established quality targets.

Sounds reasonable. Why wouldn’t you want someone responsible for ensuring that solutions are meeting quality targets?

Well, I think this role is problematic because it implies a separation between those responsible for writing software and those responsible for verifying that it works. This separation is certainly not preordained, but it is hard to avoid. The “us vs. them” trap is so easy to fall into when you have the “dev” team and the “QA” team.

Consider the priority mismatch. The goal of the dev team (and its manager) is to deliver as much as possible as quickly as possible, while the QA team (and its manager) wants to achieve the highest quality possible. In fact, their respective performance (and raises and bonuses) is frequently tied to those goals.

Well, those two goals are not the same. In fact, they’re sometimes at odds. And when they are at odds, the only way to properly decide a way forward is in the context of the larger team. Which means that someone’s priorities (and raises and bonuses) could be compromised. Which also means that someone will emerge the “winner” and someone the “loser”.

Whenever you have “winners” and “losers” as a consequence of making day-to-day decisions, unhealthy dynamics often emerge. People start focusing on trying to win instead of focusing on doing the right thing. I’ve personally seen all kinds of crazy behaviors which result from this (faking bug counts, shouting matches over inconsequential minutia like how many pixels off some element is, sabotaging builds, and so on).

A couple of caveats. First, I’m not saying that worrying about quality isn’t critically important. On the contrary, it’s important enough that everyone on the team has to play a direct role in making a quality product.

I also don’t think that it’s a bad idea to have someone specifically responsible for ensuring quality. This is not to absolve others, but to take a bigger picture view of things. I do think that effective test strategies, much like effective architectures, don’t just come into existence, but require forethought and planning.

Development Manager

First, just to be clear, I’m specifically talking about people whose sole responsibility is to manage developers and who don’t code. Why is this bad?

First, if you need someone to manage developers, you probably have developers who need to be managed. Someone I admire greatly once said “I don’t hire supervisors because I also don’t hire people who need to be supervised”.

Second, dev managers often have strong opinions about code. They have thoughts about how things should be architected and implemented, which languages, libraries, or frameworks should be used, which coding conventions should be followed, and so on.

Opinions are great. It’s good to have them and even better to share them. However, when it comes to opinions about code, they only matter if you have to live with their consequences.

I’ve been guilty of this many times. I’d make grandiose pronouncements like “we’re going to use framework X!” without understanding what it’ll be like to really live with said framework. Things like how easy it is to deploy, or debug, or understand, or look at. And, what’s worse, when hearing trepidation or outright concern from the devs who do have to live with it, I’d say “Oh, come on, how hard can this be”.

This is bad. Good devs respond very poorly to such jackassery (is that a word by the way?). In fact, it’s a great strategy for losing their respect. And once that’s gone, you’ve got real problems.

Non Technical Project Manager

The whole point of being a project manager is to help the team manage risk. I would claim that it’s virtually impossible to do a good job of managing risk you don’t understand.

Now, I’m not saying that it’s not important to be able to put together Gantt charts and progress reports or conduct planning sessions. I am saying that it’s a lot less important than understanding where the riskiest bits are and figuring out what to do about it.

So, as nice as it is to have “PMI” or “ScrumMaster” certifications, those things aren’t nearly enough to be an effective Project Manager on a software project.

Director of QA

Development Manager

Non Technical Project Manager

You may also like: