In last month's column, I singled out a few people whom I think of as software masters, and I believe our profession does still have its share of visionaries with the potential to produce masterpieces on their own. However, the success of most software work today hinges on teamwork, not individual brilliance. This month, we will focus on what it takes to create and sustain a high-performing team that can produce potential masterpieces. Let's begin by defining what I mean by a team.
The Merriam-Webster Online Dictionary offers four definitions for team. One is obsolete. The next two involve animals. And the fourth doesn't capture the essence of what I think the word means:
...a number of persons associated together in work or activity: as a group on one side (as in football or a debate).
Just because people are associated and working on the same activity or product does not mean that they are a team in my opinion, which is based on my experience.
Next I tried looking up team on Thesaurus.com. Although it offered thirty-nine synonyms, none matched my notion of a team, either. So I dusted off my non-virtual hard copy of Roget's Thesaurus and looked up the word again. I found a lot of entries beginning with co: complement, cohort, confederacy, cooperative, coterie, combine. This was getting closer to my notion: Team members are co-responsible for the team's success, and they collaborate and cooperate for a common purpose.
What determines that purpose? Based on the effective software development teams I have seen in my work, the answer is "a vision." In my July column, I mentioned that the great Renaissance masters assembled teams of apprentices and journeymen1 to help them complete large works. On these projects, it was the master's vision that drove the project. Period. The master was responsible for the overall design and execution of an artwork, and any apprentice who got a bit too creative might soon find himself out on the streets.
For software teams, too, the vision often originates with a master. If he or she can articulate it well, others will rally around that vision and willingly sign up for the project. However, that may be where the similarities between Renaissance academy work teams and software teams end. Although it's fine for one person to supply a software team's vision, it's not all right for that person to insist on controlling team members' every decision as they attempt to create a product based on that vision.
More typically, the vision for a software project comes from more than one person. When the first Rational Suite team came together, each of the three managers on our team thought he had the right vision for Rational Suite. All three could imagine the ways Rational tools might complement each other and benefit users if they were integrated, but until they took the time to hammer out a single vision we could all embrace, the team had difficulty finding its direction. In the end, this vision drove our work and eventually transformed Rational itself.
Collaboration is a distinction
In Michelangelo's day, master artists hired workers for their special abilities: gilding, painting background landscapes, rendering the folds of a garment, and so on. These people worked according to the master's plan and were paid accordingly. As a production model, this environment had its good points and bad points. Assigning the less technical work to apprentices allowed the master to produce much more than he might otherwise have done in his lifetime. But it placed the entire burden of success on the master.
I don't know of any projects that involved direct collaborations between two masters. Although some great works were completed by several artists, one always took up where the other left off. What might have happened if Leonardo da Vinci, Michelangelo, or some of the other great Renaissance masters had tried to collaborate on a project? My guess is that, a) they would never have finished it, and b) they might have tried to kill each other. Geniuses are often willing to learn from others but very unwilling to share the spotlight.
This is not an acceptable modus operandi for a software team member. Teams that are creating large and/or complex software systems need to harness the brain power of more than one person. If one of your team members regards himself as a Leonardo, you may find yourself in big trouble. In many companies, business managers protect such people; you can't just pull them aside and tell them to grow up, because the managers think you should put up with his bad behavior in order to get the product to market quickly. The best strategy is to avoid putting such a person on a team in the first place.
Organizations that thrive and survive are those that find ways to get very talented people to work together and share the credit. Typically, they do the following:
- Foster a genuine culture of collaboration.
- Match people to projects.
- Find ways to reward both individual and team performance.
- Offer continuous challenges and learning opportunities.
Let's look at each of these characteristics.
Fostering a collaborative culture
A few years ago, one of Rational's marketing slogans was "Software development is a team sport." This is even truer today. The day of an individual developer working alone on a significant project has passed. In the open source world, you have only to look at the projects on SourceForge (
http://www.sourceforge.net) to see that the really successful ones are those on which the team itself decides who will fill the project's various roles. For the top ten software development tool projects (based on popularity and stability), the average team size was 10.3 people, and the median was 9. Two teams had only two developers, and two had more than twenty. Only one project out of the top twenty five was run by a single developer.
2However, simply assigning several people to a project does not mean that you have a team. To create an effective work group, team members must be "checked in"3 with one another, and there must be synergy. The agile movement talks about self-organizing teams, whose members can acknowledge one another's strengths and deficiencies, and communicate well enough to support each other in achieving great things. This is the ideal, but it's hard to achieve. Sometimes you join a team and things just click. Then, with a little effort, the team really gels as you begin the work. However, sometimes you just can't get a team to come together, and you have to make the best of a bad situation.
Is there a way to ensure that you are assembling a high-performance team? I wish I could recommend a well-defined approach, but I haven't found one yet. There are plenty of organizational consultants who say they can transform groups of people into high-performance teams, and I have also been called in to help teams collaborate more effectively. Usually, the results of such efforts are mixed. People are unique, and it's hard to find a transferable approach, just as it is hard to find a single reward that will suit everyone (more about this later).
Depending upon their training and previous experiences, technical people may be either very open to collaborative environments or very much opposed to them. For the most part, I have found that the "touchy-feely" activities some organizational consultants try don't work with technical contributors. Group hugs just don't make them feel good.
What I can recommend is that you accept each individual's style and try to get others to do the same. If you are able to cultivate a real sense of mutual respect among team members, you have a good chance of coaxing that team into high-performance mode. You can remind people that respecting someone does not mean you have to "hang out" with that person. Instead, it means treating them in a professional manner and respecting their abilities and needs.
One of the toughest challenges for a manager is adding new members to an existing collaborative team. Some small companies start out with a core team that has worked together on prior jobs. As the company grows, and that tight-knit team has to take on new people, conflicts can develop. Sometimes they are so strong that the new people are forced out or the core team members give up and leave the company.
There are a few ways to avoid such a situation.
- First, when new people join a team, try to make sure that their personalities are a good match for the team. For example, if your team members like to go outside and play Frisbee while the code is building, don't bring in someone who is all business.
- Second, don't hire all superstars. Although it's tempting to always bring in the best, much of the work you want them to do would probably bore experienced people and not make the best use of their talents. Instead, look for good team players. Recruiters for our successful New England Patriots football team take this approach. They make their picks based upon how well the candidates complement other team members, not for their individual achievements. Good software organizations seem to have the same ability.
- Third, and perhaps most important, when new people join the team, assign them mentors who can help them learn the ropes and understand the culture. This will help them to begin contributing to the team more quickly and to feel a sense of belonging and accomplishment.
Alas, there are times when nothing works, and you must make the tough decision to remove people from a team. However, before you show them the door, take the time to assess their strengths. They must have some; otherwise you would not have hired them in the first place. Is there another place within your operation where the person might be able to use his or her strengths and contribute to the organization's goals? Taking time to help people succeed rather than treating them as if they are easily replaceable is a way to make all employees feel valued, and it brings real benefit to the organization.
Following the strategies I suggest in the sections below will also help to create a collaborative work environment.
Matching people to the project
In many instances, assigning people to a project that challenges them is a type of reward, which I will discuss in more detail below. However, some people may not be interested in taking on new challenges. Try as you might, sometimes there is no way to get a person fired up about a project. What then?
Here's the easiest answer: Find someone else to take on the work. A person who is not interested in a project will likely not produce his or her best work. This does not mean that the person has no value to your organization; it simply means that current project is not a good fit for him or her. Of course, if your organization only works on one type of project, then there may be a major mismatch between the person and the organization. In such cases, the best thing for both sides is to part company.
However, as most organizations have many types of projects that require different types of technical and personal skills, managers should take time to consider whether each potential team member's qualifications and characteristics are really a good match for the project. Motivation for learning is a key factor, as you will want people to acquire technical skills on the job (see Challenges and learning opportunities below).
In most instances, people can give you a pretty accurate assessment of their suitability for a particular project. For example, I know that I work best on small teams, and on small-to-medium-sized projects. All the large projects I've worked on took a long time (more than a year to see results), and team members spent more time dealing with the organizational infrastructure than on the "real work." I was frustrated by the process and did not enjoy having to stick with one task for weeks at a time. Perhaps I have an attention problem, but I like a lot of variety when I work. I don't think that makes me a bad person, but I would never present myself as an ideal team member for a large project.
In general, managers must always balance the needs of individual contributors against those of the project. Ideally, the two will complement each other. However, if there is a great mismatch, you may have to take drastic action. As Spock says in the Star Trek movie, The Wrath of Khan: "The needs of the many outweigh the needs of the few." When there is an irresolvable conflict, you must support the team over the individual.
Rewarding individuals and teams
We all work for rewards. Some people are motivated strictly by financial rewards; others work for more non-tangible rewards. Technical people, especially software developers, often have values that are quite different from those of other people. For them, money serves two purposes. First, according to a well-known definition by Herzberg et al., it is a "hygienic factor" in overall satisfaction.4 That is, developers regard money as necessary for existence but not a primary driver in job satisfaction. Of course, money is also a measure of status, but without other rewards an elevated status doesn't mean much.
That is a good thing, because in large enterprises, salary increases rarely reflect the individual's contributions. Instead, they are dependent upon the entire enterprise's overall performance, as well as the performance of the division IT reports to. Managers receive a small "pot" of money to distribute among all team members, and they typically opt to give something to everyone. So even if every team member performs above and beyond expectations, the size of the pot won't allow a manager to reward them accordingly. In fact, if the company has a bad year, puny (or no) salary increases can be a demotivating factor.
Smaller companies and startups may have more flexibility, and it's not uncommon to include bonuses and stock options in reward packages. Although the stock options may be worthless, they make individuals feel they have a stake in company success. As the company grows, and the technical staff represents a smaller part of it, the feeling of ownership tends to diminish. Technical experts might start to feel that their work, which used to be a passion, has now become just a job.5
There's a bigger issue than money when it comes to rewarding technical contributors. The stereotype of a software developer -- an introverted person who just wants to sit alone in front of a computer screen and crank out code -- is, as they say, so wrong on many levels. Today's software developers are social animals; they have learned to work as team members. However, many of them have a deep-rooted need to be appreciated for their individual contributions. In my experience, when a manager personally recognizes a team member for something he or she did, when the manager takes the time to say, "I understand you, and I have taken the time to find out what interests you," that can serve as a great motivator for a technical contributor.
You have probably seen cartoons of someone receiving a watch when they've served a company for fifty years. Most of us would prefer a different gift (e.g., a bicycle in my case). How hard would it be to find out what each of your employees would really like? You could even ask them.
Let me illustrate this with an example. At Rational Software (before its acquisition by IBM), it was a manager's responsibility to give employees their five-year service rewards. When I reached my five-year anniversary, I had not yet met the California-based manager I had been reporting to for about a month, because I worked in Massachusetts. She could have done what many managers did on such occasions: give me an American Express gift certificate and tell me to get something I really wanted. Instead, she talked to my coworkers and discovered that I collected Native American flutes and other wind instruments. Offhandedly, she asked me about my hobby one day on the phone, and I told her I was looking to get a Japanese bamboo flute -- a shakuhachi -- for my collection. That became my five-year appreciation gift. It is still the most prized flute in my collection, not because it is the most expensive, but because it means the most to me. Someone acknowledged my contribution in a personal way, and that really meant something to me.
The next time you are in a position to reward someone, I urge you to take the time to make it something meaningful for that person. Whatever time you spend will be rewarded tenfold, in terms of the employee's appreciation for your gesture.
It's also important to reward the entire team for a job well done. This is typically harder to arrange than an individual reward. You must be in tune with the team to know what would be meaningful to all of its members. Almost everyone enjoys an extra day or two off after finishing a difficult project, but chances are that not everyone would enjoy tickets to a baseball game.
Distributing team rewards also requires caution. If you do it regularly, the team will start to expect them, and view them as a right. On several projects I can recall, the company brought in lunch for my team and then began bringing in dinner as well for those who were working late. In part, this was a way for the company to keep the employees close to their desks, working longer. But most people saw this as a perk, and it wasn't long before they started complaining about the lack of variety in the food, asking for more expensive meals, and so on. Rewards must be special and not routine if you expect the team to keep regarding them as rewards.
Challenges and learning opportunities
Software development is a knowledge-based profession. Today, no one person can claim that he or she knows it all. In fact, it's not even possible to make that claim regarding a single area of the profession. Moreover, things will get more complicated, even as we strive for mechanisms to make them simple. This is the great thing about being a software developer. It is one of the most challenging professions you can choose. If you like challenge and continual learning, I can't think of a better way to spend your working hours.
Fortunately, just as Renaissance apprentices had masters to teach them the trade, we have knowledgeable journeymen who work alongside us, and even masters who write books and papers to guide us. We can look at their code and study their techniques. And, via e-mail, mailing lists, news groups, conferences, and blogs, we can even communicate directly with many of them. Some organizations also have acknowledged masters on staff who take on apprentices. For most software professionals, that experience is worth more than perhaps any other possible reward. I learned a lot from Philippe Kruchten when he was leading the RUP group, and I'd love to sign on for a stint with Grady Booch.
Software developers love a challenge. They love to learn new things. Knowledge is currency to them. For managers, the most obvious strategy in making team assignments is to look at what the different team members do and assign tasks according to their current skills. In other words, assign database work to the person with the most database experience, user interface work to the most experienced interface designer, and so forth. However, although this will likely produce a successful product, it is probably not the best way to make the assignments.
Instead, let the team decide, using the following strategy for maximizing members' exposure to learning opportunities:
- Determine who has the most experience in a specific area. Let that person decide if he or she would rather be the lead developer for that part of the project or a consultant for others who take it on.
- Let experts who decide to consult choose another area on which to focus their development time.
- Let those who choose to be lead developers also spend a small bit of their time on another part of the system. Don't force them, but suggest that it would be a good cross-training and learning experience.
If your team practices pair-programming, you can achieve similar results by urging them to switch partners frequently and try different parts of the system. In both cases, the goal is twofold. First, you want to cultivate versatile developers who can step in and work on any part of the system with confidence. Second, and more important, you want to give team members opportunities to face new challenges and learn new things. Team members who have just finished a particularly difficult project might resist; they might want some breathing room instead. That's okay. But, if you don't offer all team members these opportunities, those who want the challenges and learning experience will start looking for them elsewhere and could leave gaping holes in your project that would take a long time to fill.
At a former job, I worked with a brilliant woman. If you needed to know how something worked or needed a solution to a particularly knotty problem, you went to her. She was amazing. However, all of her solutions were hacks of the worst sort, and I never wanted to incorporate them into the products we had to deliver. Although she was an invaluable asset to the company, you had to know the right way to use her skills. We ended up making her a technical consultant for various projects; that made her happy because she got to solve challenging problems, and it made the team happy because they didn't have to deal with her code in the actual product.
As with most of the other strategies that successful companies follow, finding the right way to "package" challenges and learning opportunities takes time. But the benefits are worth the effort. With a team of motivated individuals who have a clear vision of where they are going, amazing things can happen. Michelangelo and Leonardo da Vinci knew this when they gathered people together to work on their next masterpiece. Along with their guiding vision, the promise of studying and learning under a great master was the "glue" that held the team together and made it the teamwork.
As a last bit of advice, I want to issue a caveat: If you hold a team-building exercise, make sure that it's aimed to building the right type of team. Some thesaurus entries speak of other types of teams: mob, gang, bunch, faction, sect. Do any of those describe the type of team you want to build?
This goes back to the discussion on rewards. Say you take your team into the wilderness for a team-building exercise, break up into smaller groups, and reward the group that gets back to the starting point first. If you have people on your team who really hate the outdoors, they might feel resentful rather than charged up about being in your organization. Plus, you might create factions within your teams that are intent on competing with each other rather than collaborating.
Also be careful about assuming that you can do large-scale team building in one fell swoop. Keep the focus on the people, not the event. John Whiteside, author of The Phoenix Agenda, describes an important project at Digital Equipment Corporation that required collaboration between engineers from the company's West Coast laboratories and East Coast production group. In an expensive effort at team-building, managers brought the two groups together for a meeting at a neutral site. The welcome dinner was a disaster reminiscent of high school dances at which boys stood on one side of the gym and girls on the other. Employees from each coast stayed in their own groups and refused to mingle with the other. The teams were never able to work together, and the project failed miserably. Had the company arranged a series of visits for small groups of people at one another's job sites, the two sets of employees might have come to know each other, and this might have produced quite a different team.
Chris Lowe, my former Rational colleague and co-author, once said something I'll always remember. "Things became much worse when personnel departments changed their names to human resources." I think this is extremely insightful. Keep the focus on people, and the rest of your concerns will take care of themselves, in most cases.
1 During the Renaissance, masters did not employ women to produce works of art. Women performed only the most menial tasks, such as cleaning up the mess in the studio. That is why I use masculine pronouns in my examples.
2 If you and your friends are bored some day, pick a project randomly from SourceForge and try to guess how many developers are on it. The closest guess wins.
3 Software for Your Head, Jim and Michelle McCarthy, Addison-Wesley Professional; 1st edition (December 27, 2001), ISBN 0201604566.
4 In 1957, Herzberg and his colleagues developed a motivation-hygiene theory focused on identifying factors that contribute to satisfaction and dissatisfaction at work. See F. Herzberg, B. Mausner, R.O. Peterson, and D.F. Capwell, Job Attitudes: Review of Research and Opinion. Psychological Services, Pittsburgh, PA, 1957.
5 In his book, The Software Development Edge (Addison-Wesley, 2005), Joe Marasco does a great job of discussing compensation for technical contributors.
Gary Pollice is a professor of practice at Worcester Polytechnic Institute, in Worcester, MA. He teaches software engineering, design, testing, and other computer science courses, and also directs student projects. Before entering the academic world, he spent more than thirty-five years developing various kinds of software, from business applications to compilers and tools. His last industry job was with IBM Rational software, where he was known as "the RUP Curmudgeon" and was also a member of the original Rational Suite team. He is the primary author of Software Development for Small Teams: A RUP-Centric Approach, published by Addison-Wesley in 2004. He holds a B.A. in mathematics and an M.S. in computer science.
Table of contents
Local resources
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
