As managers, we’re in the best position to cause sadness on our teams. If you aspire to be truly great at inflicting pain on your team, pay attention! We’ll cover three of the most popular ways.
Note that this is focused on project management “anti-patterns”. There are many other ways you can make the people on your team miserable.
These techniques lead to slow delivery and can make your company less effective. With enough participation, you can cause engineering to completely fail in its mission. So not only can these techniques make your team unhappy, but they can also destroy your company!
Sadist managers have long copied these techniques, passing them from person to person. Today, I will share them with you so you can know when to use them.
The three secret anti-patterns are:
I’ve done all three of these approaches, and they all have merits and risks. I can report that they all cause a reasonable amount of suffering.
This is the most common pain-causing technique I see in startups today. Diabolical managers turn to it because it’s so effective at numbing the mind.
As you can see, this is a very effective way to demotivate your team.
You should be aware that this technique isn’t fail-proof. Or rather, it can succeed.
If you use this approach with someone that is very detail-oriented, and you break down your work completely, it can work.
Typically I see it work only if a senior technical person breaks down all the stories completely, and the project is completely thought through.
If you’re a twisted manager, you’ll want to know all the variants. This second way of managing projects is sure to infuriate your team! This approach is to follow the form of agile but to make it heavyweight. I call this approach “million-meeting agile”.
Have a meeting for backlog grooming (with the whole team). Go over each item with the whole group.
Hold daily standups. Go through each item in the sprint, and have each person talk through a script. Usually, this is talking about the work you’ve done and plan to do, and obstacles. Ideally, this will take an hour every day.
Have a sprint planning meeting (with the whole team). Plan out the work for the sprint. Go through each item and make sure everyone understands it. If you’re doing this correctly it should take half a day once a week.
Have a project estimation meeting. Typically this involves using agile poker to estimate each story, and discuss any points of disagreement. Bonus if you estimate things you may not even work on!
Have a demo meeting. Each person demos their work. While these may be good demos, it is yet another meeting.
Have a sprint retrospective after each sprint. A great practice, but oh my god another meeting?!
One of the biggest advantages of this approach is that it seems egalitarian. Everyone knows about everything! Everyone agrees on everything! It’s a wonderful cover for your perfidy!
Almost everything the team does is sequential. This ends up taking a LOT of time. The argument for doing it this way is that it builds up context as a group. That sort of shared context is valuable (and can help the team feel satisfaction from their work)! Fortunately, the meetings are so dull nobody is actually building context.
This works especially well if you use small stories. That way, the overhead for your process is multiplied manifold. Fortunately, most teams use fine granularity in their stories and tickets, making them a perfect fit for this approach. This means the team is essentially wading through a huge queue of junk to determine what to work on each week. And they’re building context on things that aren’t actually that important.
It is necessarily synchronous, which can be challenging in a remote or time-zone distributed organization.
The inefficiency of this way of working can lead to disengagement. Team members will feel like they go to a million meetings but don’t get to solve any problems. This will also lead them to feel like meetings are useless, so even collaborating with their teammates on a problem will feel like torture!
These practices are not in themselves terrible. A lot of them have good rationales behind them. So you can attempt to cause great misery but actually do an okay job if you’re not careful.
Teams that work with stories that are high-level will tend to avoid a lot of the pain of this approach. Be sure to make the stories small enough, or your team will avoid much of the pain. If the team is reviewing a couple of stories a week, they may be fine with this approach.
This approach does do a good job of building shared context.
Last and certainly least is Gantt-aholic project management. This is an approach usually taken by someone who is new to project management. They read a lot about project management techniques and apply them to software development. That can cause a lot of pain!
If you’re seeking to cause the world to be a worse place, I would start with the other two patterns, but this can do its part as well.
So how does Gantt-aholic project management work? It is an approach that uses fine-grained planning to determine a schedule.
The project manager builds Gantt charts or PERT charts, and is using project management software or complicated spreadsheets to manage things.
They spend a lot of time each week managing the project and maintaining their models.
They ask the team for estimates on everything, to build the information they need for their models. (This often goes hand in hand with heavy-weight estimation, like planning poker).
They often maintain a list of risks. And a decision-log.
Although this isn’t as evil as some of the other approaches, it is effective as making people doubt why they entered this terrible world of tech:
Most projects in product development have a high amount of change or uncertainty. Gantt-aholic planning doesn’t map well to change. It is precise, but it isn’t accurate. Discovery or changes in the project are hard to account for, because they’re not estimated in the same way.
Because the plan is so complicated, it requires substantial effort to handle the inevitable changes. This can make the plan more rigid than it should be, because the cost of making changes is so high. This inflexibility can unnaturally contort the outcomes of your project, and also result in work that is hidden from the model or unaccounted for. Changes can take a while to estimate because the cycle time for building the new state can be expensive. It is usually difficult to experiment with variations to the plan, and since the project manager is a dependency for any alterations to the plan, and the plan requires a high cycle time to be updated, the agility of your planning is compromised.
Because it’s based on a model, estimates are usually computed. This results in estimates that swing all over the place.
The project manager has to spend a lot of time managing the model (sometimes even taking away from their management of the project itself).
Usually the project manager is the only person who can update the model, as it’s too complex for anyone else to understand. This means they can’t go on vacation without losing your ability to manage the project.
The level of detail required means the team has to spend a lot of time estimating stories.
Occasionally, you may see fit to be merciful to the teams you serve. In that case, you might want to read about a painless alternative to these styles of project management, called demo-driven development.
Many experienced engineering leaders give helpful feedback on early drafts of this post. Thank you to Seth Falcon, Bjorn Freeman-Benson and Kenichi Nakamura for numerous structural and content suggestions that made this post stronger and more focused. And thank you to Brent Miller, Davy Stevenson, and Darin Swansonfor their improvements!