Software Development: The Collective Knowledge

When I'm asked by my niece and nephew what I do, I liken writing code to solving mathematical equations; although I might know what the expected outcome should be, I'm still burdened with finding the appropriate way to solve it.

When given to a group, the same problem will likely be solved in completely different ways. That is completely normal. We think differently, and therefore solve problems differently. Make no mistake. There will ALWAYS be a better, more elegant solution.

This is true for development teams too. Developers, therefore, will occasionally find their solutions challenged by fellow team members.

I have witnessed two prevailing reactions to these challenges:

1. Developers who aggressively defend their position, rejecting any feedback

2. Developers who will avoid confrontation at any cost, accepting any other opinion

According to Patrick Lencioni, these are two sides of the same coin, and both stem from insecurity. The one might have an overt sense of self-importance, the other has a tendency to play down their contributions.

The healthiest teams I've worked on had members who did neither of the above. Instead, they were able to articulate the reasoning behind their decisions (including providing the sources that influenced them). It was then left up to the remainder of the team to provide feedback. The benefit of being accepted by the team increases the sense of accountability towards the outcome.

Reason leads to tolerance, empathy and (inadvertently) introduces new knowledge to the rest of the team.  It is this collective knowledge that is most valued at Patient Zero - not the particular contributions of an individual.