Tech super heroes


Three deadly sins of software teams

July 02, 2014

There are three* really fundamental mistakes I’ve come to realize characterize most team dysfunction. They may sound obvious, but it’s taken me many years to spot and generalize them. Each is a form of interpersonal dysfunction, rather than an environmental issue (e.g. lack of funding, etc.)

Dogma In my opinion, the most despicable sin of all. Dogma means believing something as unquestionable truth, and is something that no engineer should ever be called upon to do. Dogma is the antithesis of everything engineering stands for. The basis of all engineering is to establish net-positive practices through reason and experimental proof.

In other words, if you insist on doing something in a certain way either “just because” or “because we’ve always done it”, then you’re not being an engineer.

If you think something’s right, you have to know why it’s right; you have to be prepared to justify it, and you have to be prepared to change your opinion in the face of evidence to the contrary.

Pedantry If being dogmatic makes us turn a blind eye to our own mistakes, then being pedantic has the opposite effect – by highlighting every little tiny discrepancy the pedant is like the boy who cries wolf. Soon, those exposed to pedantry become so hyper-sensitized to minutiae being criticized that they either stop caring or they stop taking even the slightest of risks for fear of criticism.

Good engineers are thorough and meticulous, but functional teams need more than just good engineers – they need tolerance and trust between the members too. Pedantry undermines trust, fosters intolerance and corrodes healthy relationships within a team.

Control The most powerful of the three sins is control. There are various systems for categorizing different personality types, but a common feature is typically the recurrence of the “controlling” or “dominant” character. As humans we all recognize the desire for control and the tendency of some people to seek to impose control more than others. Great works of literature have been inspired by the topic.

In all knowledge-work (of which software development is most certainly an example), control is a major killer of creativity. Nobody can innovate when they’re being forced to work in a regimented way. They need a certain amount of freedom to create original ideas and concepts.

Of course, the reply comes: surely some control is necessary to avoid anarchy. If so, how do we know where to draw the line? In some ways, it’s a matter of opinion whether this is a true analysis. Is it really the case that a team of appropriate composition couldn’t create excellent value without the need for the few to tell the many what to do? If everyone’s talents complement everyone else’s, and if everyone is suitably motivated to succeed, then surely all the ingredients exist for a happily self-controlling team? Most agile models would argue that this is something worth striving for.

One thing is for sure, many people resent feeling controlled – perhaps more so with highly creative people than with any other – and resentment is not a good place to start from when building effective teams. Another point to consider is that if a team relies on (say) a single person to direct them in some way, that situation is neither scalable nor redundant. There are only so many people a single person can direct at once, and if the skills required to supply that direction are embodied in a single person then the effectiveness of the team is at risk should that person be unable to fulfill that role for any reason.

*Sure, I could have come with seven deadly sins, but then my point might have been diluted.

© 2020 Undeveloper Ltd.
Built with Gatsby