How to Make Your Team Miserable: 3 Anti-Patterns (not) to Follow

Managers are in the best position to cause misery 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 ways you can make the people on your team miserable. other 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! The three so-called “anti-patterns” 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: Task treadmill Million-meeting agile Gantt-aholic 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. Task treadmill 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. Here’s how it works: Use Jira to store everything that people think about doing related to the team’s work. Break projects down into a ton of technical tasks. Bonus if the task has no description and has a very technical title that only one engineer can understand. The team works against those tasks. Each week you carry over the stuff that doesn’t get done. Ideally, at the end, you have the work completely finished. Task treadmill advantages Working in this way is assembly-line work, instead of problem-solving work. This results in engineers disengaging from the customer problems they should be solving. It results in shallow and incomplete solutions. You’re finishing tasks, not solving problems. Working from tickets can discourage people from challenging the approach, or thinking about the work they’re doing. So this discourages innovation and fresh thinking. If you have any discovery work as part of the project, or the project is subject to change (i.e., most product development work), your detailed breakdown has just become a liability — you’ve accumulated a huge backlog of tickets that need to be reworked. A splendid waste of time! Often, this approach is done without discipline behind the breakdown process, so you end up creating the tickets as you go. This results in having no idea how long everything will take, or how well you’re doing. You’re damned if you do breakdown, and damned if you don’t! Genius! This approach also can tend to encourage the project manager to focus on “points completed” and mechanical estimates based on the stories in Jira. This works fine if the work is completely broken down, but there are often areas of risk or uncertainty that are not accounted for. Thus it often leads to overconfidence based on false measurements. Another common failure is teams just don’t really plan out their work. They don’t think about what can go wrong. They don’t plan for learning. They don’t think through the contours of the project. Very work against the grind of the tickets in Jira. As you can see, this is a very effective way to demotivate your team. Task treadmill disadvantages 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. Million-meeting agile 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”. The approach is: 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?! Million-meeting agile advantages 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! Million-meeting agile disadvantages 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. Gantt-aholic project management 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. Gantt-aholic project management advantages 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. Gantt-aholic project management disadvantages Sometimes experienced project managers can use this approach successfully, because they’re aware of the failure modes. Be careful if you’re working with such a person. They might make things better than you want it to be. What is “better”? . 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 Thank you Many experienced engineering leaders give helpful feedback on early drafts of this post. Thank you to , and for numerous structural and content suggestions that made this post stronger and more focused. And thank you to , , and for their improvements! Seth Falcon Bjorn Freeman-Benson Kenichi Nakamura Brent Miller Davy Stevenson Darin Swanson