7 Sins of Doomed Teams

1. Lust

With development teams, this takes the form of constantly being attracted to shiny new things. The next programming language, the latest framework, the newest platform.

As engineers we are curious by nature. We are also obsessed with efficiency and hold the belief that everything should be optimized. If only we used that newest language, we’d be set.

While continuous improvement is a very laudable endeavor, adopting something new has a cost too. There is always a learning curve. There are teething problems. There are unforeseen dependencies. There are unknown unknown.

Eliminate those distractions. Focus on solving your problem at hand. Stick with what you know and stop lusting after shiny new things.

2. Gluttony

This is the sin of excess. Trying to do too much, being too broad and far reaching.

Unnecessary features creep into the product. Too much code is needlessly created. Valuable programming hours are consumed and waste is generated.

This behavior perpetuates unneeded complexity and yields high maintenance cost. Often as a result, deadlines are missed and bugs pile up.

Watch for unwanted features sneaking in, bogus justifications for unnecessarily complex architectures and signs of premature optimizations. Keep the product lean.

3. Greed

Excessive specialization and compartmentalization creates fiefdoms. Hoarding mentality settles in. My code. My module. My area of concern. There is no sharing. No collaboration.

An unhealthy co-dependent relationship with those individuals develops. So-called “Ninjas”, “Rock Stars” and “High Priests” can exhibit those tendencies.

Establish a culture that values collective code ownership and focus on collaboration — such as pair programming or peer review — instead.

4. Sloth

According to Larry Wall, the author of Perl, laziness is one of the three great virtues of a programmer.

But laziness should not be confused with apathy. Leaving a build broken for too long. Allowing bad code smell to fester. Not refactoring cut-and-paste code duplications.

There should be a sense of urgency towards fixing those aspects of software development. These are not details. They are part of maintaining good engineering hygiene.

5. Wrath

In some places, there are engineers that everyone respect and fear equally. You’ve probably encountered those alpha geeks. They throw their weight around to get what they want, while others tip-toe around them, avoiding controversial topics.

They can be volatile and their anger is often misguided. They are demeaning to others and poison the environment.

Watch for those thriving on unwarranted confrontation. Refuse to be subjected to their wrath and replace them promptly.

6. Envy

Instead of being content with the tools and systems they have, some teams keep looking at what others have.

I’ve experienced situations where one wiki was in use but another one was introduced because the marking syntax was perceived to be superior. There were two issue tracking systems, multiple chats systems, disparate blogging platforms, etc.

If you’re dissatisfied with a particular tool and believe there is something better out there, great, consider adopting it. However, make sure that you commit fully to deprecate what you have. Being stuck in a half way state generates confusion and slows you down.

7. Pride

Some teams can be too smart for their own good. They are overconfident about their abilities. They never ask for help.

Worst, they think that everything should be done by themselves. And while they might be capable to do just about anything, they fail because they take on too much and get distracted. They don’t identify what’s core and what’s not. They build their own servers when they could use the cloud, they re-invent deployment systems instead of using proven ones, they create custom frameworks that duplicate existing ones, etc.

Sure, some of these pursuits are fun. They are often justified as “essential” and “innovative” but they take precious cycles away from creating business value in the product in the first place.

Keep an eye for NIH syndrome. Be rigorous about defining what your core mission is, your job #1. Everything else is secondary and can probably be borrowed from others. There is no shame in that.