Principle #10 Build A Team

Principle #11 Employ Your Team In Accordance With Its Capabilities

No one owns the code. Everyone owns the code. While not everyone has the same capabilities, we all contribute to a common code source, and we all want it to be as high a quality as possible. There are a handful of tools that are essential to distributed development: Bug trackers and Wikis and etherpads are essential, but so is IRC, email, and, lately, a code review system. These are the tools by which you communicate.  Communication is key, and respectful communication is essential.

Your job as a leader is not just to communicate, but to ensure that others are communicating.  You need the right technical tools, and the right attitude. To build a team, you need to set a vision where the project is going, and help people realize how that vision works to their advantage. You need to be willing to get obstacles out of developers way. You need to make sure you are not that obstacle.

Inspire cross-team communication. Keep it light, without letting humor degenerate into something hurtful. Keep a constant eye out for bottlenecks that will discourage contributors. If two people are working on two different aspects of the same project, put them in communication with each other. Facilitate the language choices to make sure they have a common solution, even if they have different problems to solve.

Diversity of interests helps build a team. Some people are more detailed oriented, and do wonderful code reviews. Some people are dreamers, that have grand ideas for project directions. Some people have skills in more esoteric areas like cryptography or databases. The net total set of skills you have on a team increases that teams capabilities. Thus, balance off the need for different skills with the need for a commonality of purpose.

At some level, programming is programming. But, there is a different skill set in doing user interface than in doing highly performant multiprocess number crunching. Your community coalesces around your project due to both a shared need and a common skill-set. Make sure that your project stays within its bounds.

But…that isn’t always possible. When I was a team leader for a Java based web application running on JBoss, we were affected by a Kernel scheduling issue that caused JBoss to get killed by the Out of Memory (OOM) killer. While it didn’t devolve on me to fix the kernel, it did mean that I had to understand the problem and find a work around for our company. I had enough of a Linux background at that point that I was able to get us onto a stable kernel until the problem was resolved upstream.

However, I was also aware that I was spread too thin. as a team leader, I picked up all of the tasks that had to be done, but that were too small to justify distracting a team member that was working on a strategic problem. I was the lead programmer, QA engineer, system administrator, as well as the guy that had to do all of the management tasks that had nothing to do with coding. Something had to give, and I got my boss to hire a system administrator. Knowing what your team needs in order to succeed, and knowing that you don’t have the skill-set in house is vital to getting a product built.

Conclusion

When I wrote this series of articles a decade ago, I didn’t really have a way to tie them together, so I just kind of faded off. Recently, I found myself ready to rewrite the articles, and figured I would go back and look at what I originally wrote. I like most of it, although I have made a few additions and edits.

I realize now that one reason I wrote these articles was to be able to start conversations with people about leadership. Some of these conversations would be with my own team members, including my future managers and higher in the chain-of-command. It also would help peers to extract wisdom from experience.

I happen to love what I do. I am a happy coder. I do not need to run a big business to show success. I prefer to be a team member or team leader at the writing-code level. But I am an extrovert, and I like communicating and collaborating. I hope these articles will help you the reader to be happier in what you do as well.