Build a Great Software Team

Several years ago I went on a customer call with a sales rep who had raced crew in college. Over lunch she told me how her coach found the best racing team each year. At the beginning of the season, the coach would race prospective crew members in two boats and swap the women to different positions and boats until it became clear that one boat was consistently faster than the other. The results, she said, often defied logic: with women with less speed, skill or strength making the team at the expense of more capable colleagues.

In many ways, this story applies directly to building all teams, including high tech software teams. I have had the opportunity to work and even build a great software team or two over the years. Each one was unique, with different strengths and characteristics - but each one had had an aggregate output substantially greater than the sum of its parts.

My first great team was one I joined at Easel, a team which combined local software engineers, relocated German engineers from an acquired company, and some external consultants from Denmark. This team became known later as the "first Scrum team" thanks to Jeff Sutherland and his 1994 paper. But methodology and process aside, it really was a great team (although my thinking may be skewed by our ritual Friday meetings served with hard liquor and beer). Then there was the Firefly team, which was composed mostly of 20-something MIT engineers who could work to 11 PM, close the clubs on Landsdowne Street, and then start again the following morning. The team was dysfunctional in more ways than I can count, but its aggregate output - particularly in innovative products and ideas - was substantial. And then there was my team at SilverBack, a team which evolved over the first few years but eventually settled an a core group of engineers, many of whom I still work with today.

While each great team is different, I have always followed a few fundamentals principles in building software organizations. These include:

Hire a Few 10X Engineers

Software engineering is one of the few professions in which an individual truly can produce ten times the output of another. All great teams will have at least one or two of these engineers. They are the rock stars, the 10X engineers. Some times they are loud and aggressive; some times reserved and quiet. The trick as a manager is to have both the right number, types and mix. Always remember: some times you really can have too much of a good thing. Also, be wary of any manager who actually thinks they hired all rock stars.

Demand Passion

You can see it at a design meeting or code review: the team expects excellence, whether it is in the approach to handling of exceptions or the adherence to the right design pattern. Engineers in these teams share a passion around the craft of software engineering. They have a no compromise attitude to the software they create, and drive a culture in which members of the team must either step up their game or go home.

Support Constructive Conflict

The best work my teams have produced came as a result of a engineers doing battle at a white board. Conflict is inherent in building great software. The conflict is a natural byproduct of having passionate and diverse engineers solve complex problems. The lack of conflict should worry a manager as much as too much conflict. Great teams have the comfort and respect to engage in constructive conflict without crossing the line. The key I should stress is: constructive conflict.

Drive Clarity of Mission

Don Bulens, former CEO of EqualLogics (sold to Dell for $1.4B) said when I first met him that his success came by focusing exclusively on driving customer value every day. Great teams know what they have been organized to do, know their customer, and maintain maniacal focus on their mission and objectives. The mission of a software organization is not to build great software, but to drive real customer value through the delivery of great software. Ensure your teams understands their mission, and they will rarely go astray.

Maintain Cohesion

All software managers have their story of the great engineer that just couldn't quite fit in with the team. Achieving the right balance is essential to a successful team. There are many different types of engineers on software teams - rock stars, utility players, hard-core coders, etc... - and striking the right balance of types and personalities is essential to team cohesion. Do not sacrifice overall team cohesion and effectiveness for any individual or group of individuals. Remember: the strong boat in crew is not necessarily made up of the strongest rowers, but of the most cohesive team.

Demand Respect

Teams that have mutual respect between the engineers are more likely to produce great results. The respect enables constructive conflict, contributes to cohesion, and raises the expectation of performance. Respect is the oil that lubricates the software engine.

Drive Just Enough of the Right Process

You know the old adage: people trump process, politics trump people. We can argue methodologies until we are blue in the face, but the simple fact remains: great teams are great independent of process. The key is to find the right processes for your product, team and industry. Too much process will suffocate a great team; too little will produce chaos. Give up your search for the one right process, and start understanding the right process for your team, product, market and technology.

Hire Continuous Learners

A question I always ask when interviewing engineers is: what technologies do you like to play with in your free time? I'm typically not really interested in the specifics, but to know that they do have a personal need to stretch their knowledge. Engineers that constantly push the boundaries of their knowledge are more likely to be at the top of their game.

Conclusions

Building great teams requires a clarity of organization vision, rigorous hiring practices, an understanding of the needs and motivations of your engineers, and willingness to change - especially when that change is not easy. Unfortunately there is no recipe book to follow in building great software teams. You need to race your boat, making changes along the way, until you arrive at the optimum team for your product and organization.