Working Up

by Dwayne Phillips

The number of people on a project influences the management practices that will succeed. An easy-to-remember heuristic is the breakpoints at 3 to the n power.

Yes, that is mutters with a “u.” As the size of a team on a project increases, so does the muttering. This implies that what works for a team of one size may not work for a team of another size.

It should be no surprise, although for some it is, that increasing the size of the team increases the patterns of miscommunication, misunderstandings, disagreements, arguments, and general muttering. Communication methods as well as other methods break when team sizes grow and shrink.

When should the methods change? At what team sizes do they break?

One heuristic for the breakpoints is using the number 3 raised to its powers. I learned this from author and consultant Jerry Weinberg. The breakpoints are:

1, 3, 9, 27, 81, 243, …

These numbers aren’t exact breakpoints, but they are close enough and since they are powers of 3, they are easy to remember. Moving from one size project team to another (say from 3 to 9 or from 27 to 81) breaks most management methods. The methods that worked at one level don’t usually work at the next.

Jumping two levels, e.g. from 9 to 81, breaks almost all the working methods.

There are various ways that the different size levels manifest themselves. In this paper, I will only discuss one – the communication patterns (also from Jerry Weinberg).

The communication patterns can be illustrated as follows:

—-

# of people – communication pattern

1 – self-knowledge

3 – knowledge of intimates (like spouse and children)

9 – knowledge of teammates (we may not know their intimates, but we know “about” their intimates)

27 – we know their names, but not their birthdays or where they live or who they love

81 – we recognize each of them as belonging to this organization, but we don’t know all their names

243 – many of them are strangers, most of them, in fact

—-

In the 1-person project, I know myself and what I am doing. This is simple enough.  I’m not concerned about anyone else on the project and  how I communicate with them.

In the 3-person project, I know the other two people quite well. I may know the names of the people with whom they have intimate relationships like their spouse and children. We communicate well with one another because we “almost” know what one another is thinking.

In the 9-person project, I know the other eight people well. I know personal information like if each person is married or not and has children or not, but I don’t know the names of these spouses and children. We communicate well with few words.

In the 27-person project, I know the first and last names of everyone on the project. That, however, is it. I may know three or four of them quite well, but the rest are really strangers to me. Communication is slow as I have to explain everything with almost exact terms. We don’t have a common slang or figures of speech.

In the 81-person project, I recognize people’s faces. I would know it if a stranger wandered into the offices. The people on my sub-team are familiar to me. We communicate well, but the rest of the people are strangers. We spend much of our meetings introducing one another. At least we should spend time introducing one another. Otherwise we seem to have a lot of misunderstandings that causes mistakes and wasteful rework.

On larger teams – well, those really aren’t teams. Most of the faces in the group are recognizable, but I know the names of only a few.

Some people struggle terribly when they lose the intimacy of moving from 3 to 81 people. The struggle is because while they like the work they love the people. Being “techies,” they may not realize or will not admit that they love the people. They may not realize what has happened when the intimacy is gone.

They know something is missing, but cannot identify it. The project just seems to be “going to hell in a hand basket” or something.

For example, a couple of years ago my organization was doing some proof-of-concept work with a contractor. There were about ten people involved in the work with three or four in my group and six or seven from the contractor. The proof-of-concept work succeeded wildly, and management funded a large project to take advantage of the new technology in a full-scale development project.

The number of people involved changed. We still had three or four people in my group, but the contractor’s cadre grew quickly to 60, then 70, and finally 100 people. We jumped two levels in the 3-to-the-power-of chart (9 to 81).

The communication pattern changed drastically. One person in my group, Jim, was struck particularly hard by the change. Jim would sit in our group’s meetings and complain about the  drop in service from the contractor.

“Something is wrong with Susan (a counterpart at the contractor),” Jim lamented, “She used to answer the phone before the second ring. Now I always get her answering machine, and sometimes she doesn’t call back until the next day. By then I am away from my desk and we play telephone tag.”

Susan was still hard at work, but the communication pattern in her office had changed. She now met with groups of people to ensure that everyone knew what they were supposed to be doing. She no longer sat at her desk all day ready to answer the phone.

Jim had lost the close attention of a colleague via the quick phone call. E-mail and other asynchronous communication worked much better in the new project, but Jim didn’t realize that and didn’t want to change. He longed for a return to close attention. (See Footnote)

Changes in the size of the project are common. You may work with teams that are the same size all the time; I don’t. At this time, I work with project teams of 100, 50, 20, 5, 2, and 1. I am in constant flux and, until I realized what was happening, I was in constant confusion. At least now, I better understand what is happening to and around me. The communication patterns in these different projects with different team sizes differ. I could try to force one pattern on all the sizes. The result, however, would only be frustration and failure. Instead, I adapt to the communication pattern that fits the team size. The result is less stress, more success, and more enjoyment.

I urge fellow project managers and team members to try three things:

(1) draw upon your good experiences with teams,

(2) understand the size of your current team, and

(3) think about what communication pattern fits.

Try to recall good experiences with teams on past projects. What worked for you? What did you enjoy? How many people were on that project? Where was your team on the communications pattern example given earlier? Was your experience similar to the relationships given in that example?

Examine your current team and the current project. How many people are on your team? Are you in the same power-of-3 as you were on the earlier, enjoyable project? What communication pattern are you trying to use on the current project? How is it working?

Think. Are you trying the same communication pattern you used on that earlier project? How is it working? How do you feel? What might work better? What might improve how you feel?

I sat in a meeting for a new project yesterday. Four of us worked together to initiate a product that will allow several hundred people spread around the world to communicate about requirements. Four people communicating about how several hundred people will communicate; that jumps several powers of 3.

At first, we were trying to design a product that would have people communicate the same way the four of us around a single table were communicating. After a few moments, we saw that this wish would create frustration among the hundreds of people instead of closeness.

We settled on using different approaches for the different situations. I think that was a wise choice.

Footnote:

This project is an example of how success may lead to failure. The proof-of-concept project succeeded. This spurred an avalanche of funds and an exponential growth in the number of people involved. Had most of us not changed our patterns of communication, the large development project would have failed. Success (on the proof-of-concept) would have led to failure  (on the development).