Home » Blog » Leadership » Engineering Leadership » #44 Team Building Ain’t What You Think!

#44 Team Building Ain’t What You Think!

by Steven Cerri on February 11, 2008

Team building isn’t a cookie-cutter process.

As many authors, pundits, consultants, and academics have stated over the years and as many of us who have worked inside organizations known from experience, team-building and being on a team is very important and when you are part of a team that works, you know it. As a result, a major question that managers must answer is this, “Do all good functioning teams operate the same way?” To review the literature, the answer would be “yes”. Most would say there is a set series of behaviors that are necessary in order to be a productive team.

Many of the people who write about teams are people who haven’t managed organizations themselves. They have instead “interviewed teams” or “observed teams” and they are quick to provide a list of qualities that define a “good team”, as a result of their observations. They might have four or even ten qualities that all good teams display and they are just as quick to tell us that the job of a manager is to get the team to display these qualities. And this is indeed useful, except that the behaviors that good teams exhibit are both varied and the end result of a motivational process. It is this motivational process that managers must be most concerned with.

Therefore, as wonderful as all the behavioral characteristics may sound, the truly interesting point is that it just doesn’t seem to be borne out by the facts we encounter in everyday business situations. All one has to do is look around the business world and we find many, many, many different types of teams that are very successful. Some display a certain set of qualities while others display very different qualities, and yet they are all successful. Other teams, those who are unsuccessful in their endeavors, can sometimes display the same qualities displayed by the successful teams.

In fact, I recently worked with an organization in which there existed two teams. One team liked to fight, argue, and debate at every opportunity. They liked the passion that came from presenting an idea and fighting to defend it.

The second team liked to talk intellectually, respectfully, and with heavy use of data. They didn’t like the passion brought about by arguing. Both teams were “successful” by the standards of team dynamics, and yet each team used completely different dynamics. In fact, members of one team could not participate in the meetings of the other team.

So what are we to conclude? In the above example we have two teams with different styles and if you ask the members of each team they would have told you that their team was great and their team was successful. How can we reconcile these differences between the two successful teams who seemingly display different characteristics? It’s these observed differences in the midst of pundits telling us that there is a clear way in which teams must work that causes so much confusion in our new managers and leaders. When pundits, consultants, and authors make statements regarding teams that are contradicted by what is evidenced in everyday circumstances, they run the risk of being seen as irrelevant because their statements look like hollow platitudes.

The Importance of Team Building and Teams

So let’s set this whole team-building concept straight right now. I’ll begin by making an unequivocal statement: There are plenty of ways to build teams and to be successful with those teams. There isn’t any one “right” way to build teams if you want to be successful. In fact, the best way you build a team is more a function of the circumstances and people to be managed (what I call the context) than by anything else. And since the best team process is a function of the context (people and circumstances) you can now understand why I believe there are thousands of ways to build teams to be successful.

In fact, people will often do what we call “self-select” to be in a team. This means that people will often join a team or a company or an organization because it “fits”, at some level, who they want to associate with and who they believe themselves to be and how they want to move through the world.

Therefore, when people are in your organization, unless they have been forced to be there, there is “something” they want to associate with in that group. Your job as a manager is to find that aspect that brought them to your team in the first place and to amplify it, for each person, so that each person wants to belong to the team even more powerfully than before. This is what builds loyalty.

Now not everyone on the team will want to participate openly. Some will dominate the team. Some will provide just the right amount of input for the team’s effectiveness. The job of the manager is to “orchestrate” this group of people and circumstances to maximize the effectiveness and participation of the team.

Often the most difficult aspect for the engineering manager to grasp is that there is not a right way to do this and there is no clear sense of when the process is complete. This is a “dance” between the manager and the direct reports and this dance is on-going.

Engineering is not management!

It’s different in engineering. Most engineers know when their problem is solved, when they have an acceptable solution. Most software engineers know when their software is working, although they may never be satisfied with the output format. The electrical engineer knows when the circuitry is working as intended although they may not be satisfied with the number of components used to make the circuit work.

Engineering managers, on the other hand, never quite know when their team is working at optimum capacity. They may know when it’s working “well enough”, when it’s getting the job done. But “optimum”, never. Your job, the job of the engineering manager, is to build an environment in which everyone wants to belong and wants to give their best efforts. That may mean that you’ll use a top down, authoritative management style as is often necessary in the military or in high-risk, short time-frame projects. Or it may mean that you will use a participative or coaching management style as is often necessary in situations where you are managing software engineers or marketing personnel.

What a team “means”, what “team-work” means, and what a team “looks like” can be very different depending on the circumstances. Believing that a team always has the same qualities is what makes “cookie-cutter” managers.

I use six parameters to determine what team-building approach I’m going to use. These six parameters determine the optimum management style and therefore, the team-building processes I’m going to use. The six parameters are respectively more or less important depending upon the circumstances, depending upon the “context”.

What you will always notice about teams, however, is that they comprise a group of people who want to work together and are willing to “play by the same rules”. If they don’t want to play by the same rules they will leave the team, either literally or figuratively. It’s the managers’ job to help them fit in or to literally leave.

But fitting in can look very different in different situations and for different teams. Team members may argue for hours or they may be very respectful. They may never have formal meetings or they may regularly meet like “clock-work”. They may yell and scream at each other or they may speak in quiet voices. Whatever the dynamics, you will know it is a team because they all agree that this is how they want to work together. It is the managers job to “hold this space” so these people can continue to do so. Remember, it’s not the managers’ job to mold the team members into the “space” the manager wants them to fit into. It’s the managers’ job to determine what the situation demands the team look like and then hold the space so the team can deliver what the circumstances demand.

Therefore, the manager who wants to be successful at team-building, will not do so by generating a specific list of behaviors. Behaviors can vary. The key is to establish a set of values and then manage the team according to the context.

Just answer this question: Would you manage any or all of the following situations with the same team-building processes?

• A high-risk military operation

• A manned space flight

• A software development project for credit card services

• A software development project for a game

• An oil refinery

• A nuclear power plant

• A cattle ranch

• A farm

The biggest challenge for engineers who want to become managers is this:

Engineers deal with laws of physics that don’t change with blood sugar levels or emotional state. F=ma and E=IR don’t change with the weather. The laws of physics are predictable over the short term AND the long term. The syntax of software is as stable as a language.

Managers, on the other hand, deal with people who do change with blood sugar levels or emotional state or with the weather. Their behavior is not stable nor is it predictable over the long term. It is predictable over the very short term however.

To become managers, engineers must trade in the certainty and predictability of engineering and science for the uncertainty and unpredictability of management. They must trade in the “hard skills” of engineering for the “soft skills” for interpersonal people skills. This is the biggest hurdle in this transition… and it can be done!

Be well,

Steven Cerri

Previous post:

Next post: