Dysfunctions of Successful Teams

Complete Developer Podcast - A podcast by BJ Burns and Will Gant - Giovedì

Categorie:

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. Episode Breakdown 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. Gatekeeping behavior 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 potentia...

Visit the podcast's native language site