Dysfunctions of Successful Teams
New teams who are building entirely new projects are often very similar. Due to working on new things with people they don’t know well, along with incredible uncertainty, they certainly have their share of dysfunctional behavior. However, one thing that often surprises newer developers is that older, more established, and successful teams often have their own major dysfunctional behaviors that have to be overcome in order to take things to the next level.
Unfortunately, these behaviors are often much harder to correct. For starters, if the team is currently successful, it’s much harder to convince anyone to rock the boat. However, just because a set of behaviors served you well when getting to your current level, that doesn’t imply that those same behaviors will work well to make your team even more successful. Further, for at least some of the behaviors we are going to discuss, those behaviors could also cause catastrophic team failure in the future.
When you look in a mirror, you are going to notice imperfections, no matter who you are. The same is true of teams, even the most successful ones. It’s important to remember that problems in an established team are often the result of adaptations gone wrong, rather than the result of neglect, gross malfeasance or a desire to do things incorrectly. It’s just that people adapt until they are comfortable and then stop adapting.
Fixation on Process and unwillingness to change it.
Why it happens: Getting processes nailed down is one of the keys to success. It makes it easier to train new people, systematize/automate work, and make sure that everything that needs to happen happens. Consistent refinement of process is why your team is still around.
What it does when it is no longer useful: Process starts to rapidly waste time when things change and the process doesn’t change with it. Change can be as simple as subtle shift in team dynamics and as complicated as changing your application’s target market.
How to correct it: One of the best ways to correct a fixation on process is to have regular retrospectives (or post-mortems) when problems occur and to solicit input from the team on how the problem can be avoided in the future.
What not to do: Don’t show up with suggestions on how to fix busted processes. Even if you are right, politically you are pitting yourself against the team and your role will be remembered if anything goes wrong.
Why it happens: As teams grow and change, some people hang on to knowledge. This isn’t necessarily because they are trying to protect their careers – it can often happen when a previous employee makes an expensive mistake. Management is naturally gun-shy afterward.
What it does when it is no longer useful: Gatekeeping behavior can often backfire in a big way when the person engaging in it goes on vacation, retires, leaves the company, or is simply overloaded dealing with another crisis.
How to correct it: First, find out the history of the situation. Also take time to prove that you (or someone else) can actually help, then suggest some cross-training when things are slow and there is an opportunity for learning with less risk.
What not to do: Don’t start on your first day trying to suggest cross-training, and don’t insert yourself into someone else’s code where you aren’t welcome. You’ll make enemies that way and you won’t make friends.
Concealment of weakness
Why it happens: As teams evolve, they will often go through periods of downsizing (or worry about downsizing). As a result, established team members may be reluctant to be open about their weaknesses, even if those weaknesses are easily mitigated.
What it does when it is no longer useful: This is potentially very dangerous to product stability and project timelines, as developers try to bend new frameworks into old ways of thinking.
How to correct it: Show people how to do things by volunteering to explain it during a lunch and learn. Talk to the people who you suspect are hiding their ignorance, explaining how you would like to show some of the new technology to the newbs to try and get the team on the same page.
What not to do: Don’t come in talking about how someone doesn’t know their way around new tech. You might not know as much as you think. Remember that success is a team affair, while failure can be a remarkably individual one.
Why it happens: Teams change over time. Old projects stop being actively developed, but still have to be supported. The developers who work on those projects often take care of support rather than burdening the rest of the team with the interruption.
What it does when it is no longer useful: Like concealment of weakness, this can often result in catastrophic failures when the developer who understands that system is unavailable. It can also make it difficult to migrate from the old system to a newer one, simply because there aren’t enough people who understand the old system.
How to correct it: Much the same as the concealment of weakness, you have to tread carefully. Probably the best way to overcome this problem is to ask questions about the old system when it comes up. When small issues come up, ask if you can help or pair with the person who understands this stuff.
What not to do: Don’t try to push your way in suddenly. It’s one thing to express interest; it’s another to be pushy. The latter makes enemies. Whatever you do, don’t talk trash about the older tech – your newer tech may not be that great either.
Why it happens: After people work together for years, they end up understanding each other’s triggers pretty well. They tend to avoid conflict, because most conflict is unproductive and wastes time.
What it does when it is no longer useful: As time goes on, some conflicts that need to be resolved won’t be, because everyone is trying to remain polite. If the conflict matters, the lack of resolution can cause innumerable problems over time.
How to correct it: You can’t, unless you are high up enough that you have the power to fire people. Even then, it’s a minefield. You do, however, have to bring the conflict forward and get it resolved. This may require that someone leave, or could be easier if you are lucky – it’s very dependent on your situation. If you don’t have this kind of power, learn from both sides and act as a bridge between the two.
What not to do: Don’t take sides obviously unless you can enforce your decision. You are almost always better off not jumping in to existing conflicts.
Unofficial Communication Channels
Why it happens: Old friendships and good working relationships can persist even as the org chart changes. These tend to develop into informal communication channels over time. These communication channels become stronger if the normal communication channels are dysfunctional, slow, or politically encumbered.
What it does when it is no longer useful: When communication channels are not the official ones, this can result in decisions being made in a way that is unpredictable to people who aren’t privy to those communication channels. This can be hard to handle when you make decisions based on what you THINK is supposed to happen.
How to correct it: Get into that communication channel however you can. It’s there for a reason, and only management action is likely to remove it. If you are management, you need to acknowledge and fix the situation so that official communication channels are a better option.
What not to do: Don’t threaten or try to break that communication channel. Recognize that human communication channels route around problems and that their evolution will continue until the problem that caused them goes away.
Why it happens: Successful teams often have had very good results from being deliberate about the decisions they make. Rushed decisions are expensive and cause a lot of problems.
What it does when it is no longer useful: Not all decisions need to be debated to the extreme. Sometimes you need to make a decision for exploratory purposes. When you can’t do that and are forced to make a perfect decision or no decision at all, it can severely hamper your ability to take advantage of changes in the market.
How to correct it: Encourage trying new things out in very limited circumstances, in situations where you can quickly switch back to the tried and true. Make decisions less risky and it’s easier to make decisions. Decisions are made slowly if they are costly, so lower the cost.
What not to do: Don’t go raging around about how slowly decisions are made. Not only is it unlikely to make any potential decision faster, but if decisions are slow for a reason, it makes people think that you are too hasty and emotional.
Lack of Accountability
Why it happens: Blame games are typically not very productive. As a team ages, they either tend to engage in them more, destroying the team, or engage in them less, which tends to result in a lack of any accountability at all.
What it does when it is no longer useful: When this behavior becomes pathological, it means that mistakes cannot be acknowledged. When mistakes cannot be acknowledged, they cannot be corrected or avoided next time.
How to correct it: First, start by acknowledging your own mistakes. Publicly. Without shame. Ask for feedback on how to do it better next time. Similarly, try to convince your team to engage in regular post-mortems and retrospectives when problems occur. It doesn’t matter WHO made the mistake, so long as you can acknowledge a mistake and fix it.
What not to do: Don’t focus on WHO made the mistake. Focus on WHAT the mistake was and how it can be avoided in the future. WHO doesn’t matter, but WHAT can save you from a more expensive mistake later.
Focus on Outdated Metrics
Why it happens: Early on, someone will come up with some metrics that can show whether a team is getting better or getting worse. These metrics sometimes stick around far longer than they are useful.
What it does when it is no longer useful: When old metrics no longer are useful, people will make decisions that make the metrics look better, while making actual results worse.
How to correct it: First, find out the goal that the metric is intended to address and determine where things went wrong. Remember that these things are in place because they were useful at some point in the past. You will not get around them without addressing the business reasons for that particular metric and you shouldn’t try.
What not to do: Don’t attack the metric itself. Address your concerns towards what the metric is intended to measure, with the intent of refinement.
Tricks of the Trade
You want to make yourself replaceable. So many people think they need to be irreplaceable because that means they can’t lose their job. This isn’t the case as if they want to get rid of you they will make due. What it actually means is that you can’t take time off or get a real break. It also means you can’t leave your current role. In order to move up you have to be replaced and to do that be replaceable.