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 build and