Home > Blogs > What We Bring to the Table

What We Bring to the Table

In many shops, I have seen situations where one person (or perhaps a few, but it is always a minority) appears to be getting in the way, and the perception is that they need to be sent on their way for the good of the team. While this actually is true in some cases, I think that more often than not it is more a case of failing to appreciate what others bring to the table.

The measurement of personal productivity is a powerful tool, but can be wielded in dysfunctional ways. It is possible to measure the amount of new code that a developer produces over a period of time, or the number of defects found by a tester, and these are great measures for the individual to use as a basis for estimates of future work. In the context of the team, though, there is a strong tendency to start comparisons. Alice produces more code than Bob, so is Alice better? Bob finds more defects than Cindy, so is Bob better? By this sort of measure of productivity, most executives would be seen as highly unproductive (unless of course we measured the amount of time they spent facing their Blackberries or iPhones). We need to go well beyond the surface.

I was on a project about 15 years ago and ran into this in a fascinating way. There was one developer whose numbers appeared quite low: he appeared to be very unproductive. Indeed, he was resistant to pressure from management to be 'more productive', and develop more code, faster. He was seen as a troublemaker, and there were attempts to remove him from the project.

I intervened on his behalf, and had quite a struggle to keep him on the team. Why? Well, it was clear that this person produced code more slowly than many others, but there is a difference between 'gross' production and 'net' production (and the terms are quite apt in this case). While many developers can produce code at a fast clip, the end result is that they also produce a larger number of defects as well. It is a running joke in our home that I can type at 75 errors a minute on a good day. This person, while slow on the surface, produced some of the cleanest code I have ever seen, and was rarely plagued by defects in the code he produced. He delivered on his expectations, often after deep clarification of the sloppy specifications and designs he was handed. He developed strong solutions and moved on. He was a craftsman, but was not appreciated by others who didn't work in that manner.

Everyone is an expert in some area, everyone is a craftsman with something that they do. While I think the industry would benefit from more of an approach where people worked in apprentice-master relationships to foster effective growth, something more is needed. We need to understand that while expertise or craftsmanship is good, it is the appropriate application of relevant expertise or craftsmanship to the problem at hand that really matters. For large or complex systems, there are many domains of expertise that are required to cover all of the problems, there are many forms of craftsmanship that are needed to efficiently provide a comprehensive solution.

Alas, in many teams, this is not considered explicitly. Even worse, there are many teams that are led by people who believe that everyone should behave as they do, that they should carry the same expertise or excel in performing the same tasks. It is easy to see how this tendency propagates, because when we find someone with similar interests or skills, this resonance leads us to believe they will be a strong addition to the team. We need to break out of this trap, we need to appreciate that a diverse range of skills and craftsmanship will make the team stronger. We will be able to provide more effective, more innovative solutions to the problems we face.

If we look at our present team, we need to understand and value everyone's contribution. Are they efficient developers, do they deeply understand the domain? Are they strong at working with clients, do they form the cultural glue that holds the team together? It is perfectly fine that others don't contribute to the team in the same way that you do, it is even better to appreciate their contributions, and perhaps to grow from them. In some ways, each of us can be apprentices to everyone else on the team, as they demonstrate mastery in what they bring to the table.

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.