Small teams can be highly effective at creating big systems. In this "Behaviorially Speaking" feature, Bob Aiello explains how to be successful in a small team environment and also handle the growth often necessitated by success.
Small teams can be highly effective at creating big systems, and there are published studies describing the many ways in which high-performance teams achieve their amazing levels of success. [1] I have enjoyed being the build and release engineer for a number of small and very successful teams, often in the most demanding trading environments. I have also seen previously successful small teams lose their effectiveness as they have grown. Small teams may add a member or two, only to have their previously high-performance team structure disrupted along with their effectiveness and productivity. Read on if you would like to be successful in a small team environment and also handle the growth often necessitated by success.
Most of us would not want to find ourselves in a battle where the opposing army has superior numbers. Law enforcement uses omnipresence to prevent crimes, and when cops get into trouble, their first step is to call for backup. Clearly, there are times when you want to be in a very big team.
So, why would a small, elite team be more effective in some situations than a larger group? The first reason might be as simple as the psychology of being a member of a small group that faces an overwhelming task. When a group fears for its very survival, the group members may bond together and accomplish amazing things against all odds. Small startups may find themselves in exactly this situation with “survival”—continued employment for workers—at stake each and every day. It's not hard to understand that everyone in a successful startup would need to expend significant discretionary effort covering many different roles that, in larger companies, would be handles by other employees . It is also not hard to understand that members of a very successful team will likely reap significant rewards. These rewards can include stock options and the experience reaped from playing a wider role.
Many hedge funds are known for paying their team members a lot of money while demanding and receiving superior performance—monetary motivation. While being in a successful hedge fund may be very profitable, these rewards do not come without their own set of risks. Many hedge funds also stumble and go out of business. Interestingly, the members of the team often find themselves working together in another organization. I have worked with many of my own colleagues across two or even three different organizations.
Small teams must use the most efficient software methodology methods, or they won't be successful and they won't survive. A rapid build, package, and deploy system is a must have for any high-performance technology team. This means that you need to establish effective source code management procedures so that your build server can pick up the correct baselined release. Usually, small teams don't require complex branching and merging, although being able to fix a bug in production does require at least a bugfix branch. Your build automation is probably written in Ant, Maven, Make, or MSBuild, and you most likely have some supporting scripts to automate the entire process. I usually set up a simple continuous integration server in these small teams and fully automate not only the build but also the deploy to the test environment. Setting up the right tools and process is important, but the CM guru in a small team often wears many other hats, too.Small teams often require each of their members to help out with any task that needs to be completed. I am not usually the right resource to write code unless it is a shell script used perhaps to automate the deployment process. However, I can jump in and help with production support and systems administration. I’m also a pretty good testing resource. Members of a small team often have to back up each other and perform whatever task is necessary. This is great for everyone, because learning every role will help you understand the whole system that is being developed.
Large development teams often are divided into separate functions, commonly called silos. This makes sense because large teams need to specialize by establishing shared services that support everyone in the organization, but it can also lead to serious problems. I have seen many large teams in which each specialized group knew their own domain but knew next to nothing about what the other teams were doing on a daily basis. Silos make for inefficient troubleshooting, because each specialist knows very little about what the others do. You usually don't run into this problem in a small team because its members often wear many hats and better understand the big picture.
Many small teams exist within a larger enterprise organization. I have seen small teams maintain their identity quite well, even while existing within a larger context. The key is to have a way to communicate and represent your team to the larger organization, providing transparency and enabling governance that is essential for larger organizations. In agile, you have a representative of your team participate in a Scrum of Scrums where members of different teams meet to share information across different (scrum) teams. I know of one company that grew so quickly it literally did not have enough seats and desks to cover all of its employees. One manager took his team to the disaster recovery site and worked out of that location. Although the manager traveled back and forth between the disaster recovery site and the main building, in every other way the team operated like a small team.
Small teams can be highly effective if they understand what needs to be done while maximizing the synergy of working within the small team structure. Each team member needs to understand his role and how he can help with whatever tasks need to be completed at any time. CM best practices are essential for small teams to perform effective source code management and automated build, release, and deployment. You may find that some of your own best work is done when you are a member of a small team. Make sure that you drop me a line and share your own experiences with implementing CM in a small team!
References
1. Clint Bowers, Eduardo Salas, and Florian Jentsch. Creating High-Tech Teams: Practical Guidance on Work Performance and Technology (American Psychological Association, 2006).
