Tag Archives: group dynamics

Lessons in Self-Organizing Social Systems

Last week, I had a chance to reflect on eleven years of the Retrospective Facilitators Gathering.

A bit of background on RFG: I started the Gathering in 2002 with Diana Larsen and Norm Kerth.  Each year, the different set of volunteers organize the Gathering.  Continuity comes from linking the immediate past organizer, the current year organizer, and the next year organizer as part of the organizing group.  Most years that’s worked reasonably well.

We’ve used light weight planning and a market place for sessions from the start. But over the years, I and other organizers learned more about self-organizing systems.  We lightened our planning even more. We planed the parts that need planning– the venue, and supplies, for example. Those aspects that don’t need close planning emerge organically.  But what emerges depends on setting the initial conditions, and attending to containers, differences and exchanges.

Based on a decade of experiments and experience, some considerations for setting the conditions for self-organizing social systems.

1. Initial conditions shape interactions for the life of the group.  Small actions can have a big effect, particularly those that amplify the sorts of differences that create division.

2. When structures and espoused values contradict each other, people sense the incongruity–and respond, often in incongruent ways.

3. The more people in implied (“organizers”) leadership positions take responsibility for the decisions and welfare of the group, the less responsibility the group will take for their own decisions and welfare.

As you think about the teams and groups that you work with, how do these factors show up?  How might you apply them now?

 

But are they working hard?

Recently, I met with a group of managers who work in an organization moving towards agile methods. People seem to be happy working on cross-functional teams. They solve problems and work things out without management intervention. Best of all, they produce working software that the customers like. This makes the managers happy.

But the managers have a lingering concern: How will we know that senior developers are doing senior level work?  How will we know they aren’t slacking off?

I hear variations on this question in many of the larger organizations I work with.

So let’s unpack what might be going on here.

It could be that these managers have no experience how teams work together to produce results. They don’t have a visceral understanding of what it feels like to say, “We can’t single out one person’s contribution. We did this together.”  Their own experience as managers in the organization reinforces the individual focus. In many organizations, management rewards and incentives leads to local optimization at the expense of over all goals–which obscures the interdependency of their work.

“Manager think” is shaped by emphasis on individual achievement in formative institutions such as schools, and by HR policies within their organizations. For example, individual ranking/rating systems ignore interdependency.  Finely differentiated job grade levels reinforce the notion that its possible to put a neat box around each person’s contribution. Further, they focus attention on “doing my job” –or not doing a job that a more senior (or more junior) person should do–rather than on accomplishing a broader goal–such as delivering customer value.  Narrow functional descriptions (automation tester, exploratory tester, front end tester) have the same effect.

Some people in management believe that if people aren’t pushed, pressured, and held accountable, they’ll slack off.

I have observed that many people are motivated by following through on commitments they themselves make. Many people find time boxes and deadlines useful to prioritize and organize where they spend time and attention. Commitments–made by the people doing the work–and time boxes can be useful structures.

Pressure, pushing, oversight work in a very different way (or, more likely, don’t work).These managers might be worried that people won’t do senior level work if no one is looking.

I actually find the opposite happens more often–people engaged in their work strive and go above and beyond.  OTOH, sometimes people create the appearance of striving (and doing senior level work) when they are pushed, pressured, and “held accountable.”

Here are some of the “senior level” things I would expect to see on a thriving team.

  • pairing
  • mentoring
  • informal lunch and learns
  • looking for patterns of problems in the code
  • convening discussions about standards to address code quality
  • initiating coding katas
  • modeling good engineering practices
  • task walls and a pull system for tasks
  • delivering working code each iteration
  • examining the teams practices and looking for ways to improve

Managers don’t need to be involved in the day-to-day  tracking of technical tasks to observe that these activities happen.

Senior people don’t have to initiate these activities.

I’ve seen many teams where junior people–both in terms of time on the job and technical skills– lead in these areas. If only senior level developers initiate good practices, I worry that they’ve created a pecking order on the team, and junior people with good ideas don’t get a chance to contribute. (Its a variation on the HiPPO problem–deferring to the Highest Paid Person’s Opinion).

Sometimes I try thought experiments.  I might say, “Suppose we formed four teams. After the teams have some time to get their legs under them, they’re producing results. They are getting software out the door, and the customers are happy. But you don’t know exactly what each team member is contributing. Could you live with that?”  Most people say they could live without knowing. When they can’t, that’s indicative of a bigger problem.

Very often, the notion of social loafing comes up. Then we’ve reached the crux of the matter.

The original experiments on social loafing looked at uninteresting physical tasks. Some of the experiments involved people working under compulsion. But we aren’t talking about odious work done under compulsion–at least I hope we aren’t.

Remember the old saying, many hands make light work?  People talk about social loafing as if it is  morally wrong for  one person to reduce his effort because others are working at the same task.  I hear the same logic when a well-functioning team makes work look easy. Someone inevitably complains that if they aren’t struggling, they must not be working hard.

When people hold beliefs like these, the systems they build tend to be  self-reinforcing, dysfunctional–and difficult to dislodge.

When people are in small teams, and engaged in meaningful work, social loafing is rare and working hard is common. But it might not look that way to someone who hasn’t see a thriving team.

Empowering Leadership II

Every team needs leadership, even self-organizing teams.

When I make this statement, some people assume I mean that every team needs a designated leader.  I can’t blame them, most people are accustomed to thinking of leadership residing in a role or a charismatic individual—a “born” leader.

On self-organizing teams, there isn’t one leader.  Agile teams may have a coach; however, the coaches job is to help the team see where they need to improve and help them learn specific skills.  The coach may lead at times, but the coach isn’t the leader.  In fact, if the team looks at the coach as the leader, they’re in trouble. Holding up one person as leader will hamper team development.

Before we go any further, let’s define leadership: leadership is creating an environment where everyone can contribute to solve the problem at hand.

On teams that function well, every member of the team leads.  Each person takes responsibility for helping the team move forward.

But acting at random or on gut feel isn’t enough. Empowering leaders can be more effective when they work out of a model that helps them make sense of what they see happening on the team.

One such model is the MOIJ model articulated by Jerry Weinberg.

1. Every team needs motivation—and I don’t mean pep talks, cheerleading and extrinsic rewards.  Teams do best when they are intrinsically motivated, when they derive satisfaction from the work and team relationships.

Team members lead when they work for appropriate harmony and consensus—and engage in constructive conflict.  Leaders pay attention to how other team members are participating, so that everyone can use their talents and creativity. Leaders pay attention to how the whole team is working together, and building a team culture that supports achievement and good working relationships.

When only one person on the team pays attention to motivation, the team doesn’t learn how to create the environment for their own success.

2. Teams need organization.  Organization is more than the boxes on an org chart.  Organization includes physical space, time, and structure.

Leaders make sure that the workspace supports the team with appropriate equipment and information. Teams need someone to lead by pay attention to commitments and the ticking clock.  They need to figure out how to allocate the work so that it gets done and there’s a balance between people expanding their skills and relying on experts who can do the work most quickly. Teams need structures that help them work effectively together, for example, working agreements or configuration management.

When only one person pays attention to organization, he comes across as a nag. After a while, people ignore nags.

3. Teams need information.  They need to see a vision, generate ideas, bring in data and analyze and connect the dots.

Along with a flow of ideas, sometimes, a teams need a Devils Advocate.  A Devil’s Advocate challenges habitual thinking, checks solutions against foundational principles and values.  Without a Devil’s Advocate, teams can slip into group think, or miss risks and weaknesses when they consider options. But like the nagging organizer, no one enjoys a habitual naysayer. When there’s only one Devil’s Advocate he’s likely to be marginalized.  Like all the other leadership activities, it’s important to spread this one around.

Team members also need to know when they have too many ideas, and it’s time to slow the flow. We usually don’t think of following as a leadership activity.  But I’ve seen teams where everyone wanted to have his or her way.  I’ve seen teams sidetracked when members keep throwing in new ideas each time they come close to a decision.  Those teams argue and debate endlessly and don’t make forward progress.  Knowing when to zip the lips and follow is leadership, too.

4. Finally, every team needs people who can recognize when they are stuck and need a jiggle.  My favorite jiggle is a paradoxical question: “How can we make the situation worse?” Simply commenting on the stuck-ness can sometimes shake a team out of their rut. Changing position—standing up if the team has been sitting–can jiggle the team into productive action, as well.

***

What happens when only one person on the team—whether a formal or informal leader—tries to do all the leadership?  I suppose there are the rare individuals who can do it all. But on most teams that aren’t sharing leadership, are missing some leadership ingredients.  When teams rely on one individual they flounder when the leader isn’t available.  Worse, they don’t develop their own capabilities and slide into dependency.

Leadership is about making sure the team is functioning well and creating an environment where everyone can do his or her best work.  And it takes a whole team of leaders to make a self-organizing team.

Best at argument != Best ideas

I was talking to my friend Penny the other day about a team she coaches.

There’s a really smart guy on the team. I’ll call him Bob. Most of the time Bob is an asset to the team. But when the team needs to decide on a technical solution under time pressure, he’s not.

“But Bob is a smart guy,” you may say. “How is it he’s not an asset? Won’t he have the best ideas?”

When it comes time to solve a technical problem, Bob is always first to offer his idea. Then, Bob dominates the conversation with a constant stream of words, leaving no opening for another to insert facts, ideas, points of view. When someone does find a voice and interrupts the torrent, Bob cuts him off, declaring “I’m not finished.”

When Bob does finish, and another team members asks a question, Bob implies that the other person doesn’t get it, and might be too stupid to see the brilliance of Bob’s idea.

When another team member proposes a different idea, Bob shreds it. He points out the flaws in the other person’s idea, while pointing to the strengths of his own idea.

When he does let others speak, it’s pretty clear that he isn’t listening to learn. Bob is figuring out how to score his next point.

I don’t believe Bob has bad intentions. I believe he wants to be helpful, and believes he is. Bob is helping the team in many ways, but he’s also hurting the team. Here’s how:

1. The team don’t have enough ideas. Due to Bob’s style, there is seldom more than one idea (Bob’s) that receives serious consideration. That’s not enough. Even if Bob is smart, so are the other people on the team. But Bob is the most extraverted and the best at argument and debate. That’s not the same as having the best ideas.

2. Over time, Bob’s style will wear down the other team members. It’s really not terribly satisfying to be browbeaten, or have all your ideas shot down. At some point, other people will stop offering ideas, and acquiesce rather than endure another argument with Bob.

3. As long as Bob’s ideas prevail, others don’t have a chance to develop their ideas.They are deprived the opportunity to learn, think about problems and risks, and increase their capability. Over the long run, that’s bad for the individuals involved, bad for the team, bad for the organization.

Penny has given Bob feedback on the effects of his behavior. It’s made some impact, but when there’s pressure to come up with a solution, Bob–as most people do–falls back on his default behavior. Chances are, Penny won’t get Bob to change that. Bob’s behavior is driven by his natural tendencies, and years of cultural exposure that taught him that competition and argument are the way to find the best ideas.

However, Penny can change the process so that the team has sufficient ideas to consider, and that credible ideas receive due consideration.

Here’s how:

Separate generating ideas, explaining ideas, exploring ideas, and evaluating ideas. As it is now, all of these are mashed together (and done mostly by Bob).

Equalize participation. From what Penny has told me, I suspect Bob is a strong extravert and the other team members are introverts. That means that Bob is very comfortable thinking out loud, and the other team members need a bit of time to organize their thoughts. Before they have time to do that, Bob is on a roll. One way make room for more participation is to start the process with a few minutes of silent brainstorming. Then, ask each person explain (orally or through sketching) the essentials of his or her best idea.

Apply the Rule of Three. If you don’t have at least three ideas, you don’t have enough ideas, and you probably don’t understand the problem. You may end up with deciding the first idea that came up is the best one…but you may not, or you may refine the first idea based on further discussion.

Test for agreement. Some teams get carried away with voting. But when a decisions are routinely highjacked by one individual, it can help to test for agreement using a gradient of agreement or fist of five.

Establish a small set of tests for technical solutions. In this team, some of the tests that make sense might be:

The solution …

  • is the simplest thing that can work.
  • doesn’t add to technical debt.
  • can be implemented in the timeframe required by service level agreements.

Bob may have the best ideas on the team. We don’t really know if that’s the case. No one else’s ideas are fully considered. We do know he doesn’t have a perfect record. Some of his fixes don’t work the first time. Some of his fixes break something else.  If the team had a process to consider and refine ideas, that might not happen as much.

It may sound like it will take more time to separate generating ideas from explaining, exploring, and evaluating them. It may seem like a lot of effort to find more than one idea and test the ideas for soundness and test the level of support for a given idea.

But in years of observing teams, I find that slowing down and separating the steps of the choosing a solution helps the team speed up. A mashup process forced by a dominant individual may appear to save time in the very short-term. That’s seldom true if you account for all the time costs and other effects incurred.

Norms, Values, Working Agreements, Simple Rules

Bob Sutton recently posted a piece on Team Guidelines.  The guidelines–all Mom and Apple Pie–where handed down by a new boss for the team to follow.

The list starts with “Show Respect.”

I find it ironic that the new boss is advocating treating people with respect. Arriving with a set of rules for other adults you’ve just met doesn’t feel respectful to me.  And I’m pretty sure that imposing rules won’t have the desired effect.  Modeling behavior, engaging the group in discussion about patterns of interaction, yes. Coming in with the rules like a kindergarten teacher–not so much.

But the post got me thinking about how teams develop norms.

Teams develop norms whether they are paying attention to norms or not.

Teams build up a pattern of interaction and implicit understandings of what people can do, should do, should not do, must and must not do in various situations.  It’s part of being in group of humans.  Often, the patterns form without much thinking about the implications.  Norms form around where people sit in meetings, or acceptable late arrival, and whether someone should bring cookies on Tuesdays.

Effective teams have a shared approach to work (though not a rigid process).  They explicitly work out agreements about “How we do things.” The team’s agreements evolve to address both challenges and aspirations.  Teams find a way to talk about what matters, and decided how they’ll act out those priorities day to day.

When a team develops agreements, it helps to know what they are trying to accomplish, because different sorts of agreements serve different purposes.

Values

…are statements of what is important.  Value may guide behavior, but are not, in themselves, actionable. Values often represent the espoused beliefs in the organization–which don’t always match the values in action.

Example:   Balance work and life. (But pay attention to what really happens.)

Group Norms

…are informal, often implicit standards of behavior that develop from the interactions of the group.

Example: (By observing the group, we can deduces that…) It’s acceptable to be late for meetings.

Ground Rules

…are statements of expected behavior for specific times, places, and situations.

Example: (Posted in the meeting room) Don’t interrupt each other.

Working Agreements

…are protocols that the group develops and agrees to follow. The protocols aim to forge commitment and a shared approach that will help the team meet their goal.

Example: Code is *done* when all programmer and acceptances tests pass, the customer accepts the story, and the code is checked into the development branch.

Simple Rules

…are short statements that guide interactions and  decision making within the group and across other groups within the organization.  Simple Rules can generalize across many situations, and make values actionable. Simple Rules aim at brining coherence across the organization.

Example: Use every failure as an opportunity to learn.

All of these represent social contracts between group members. Effective teams use all of these tools to create a pattern of interaction and results that enhance their ability to reach goals and improve quality of both work life and results.

Reaching collaboration and high performance is possible without explicit agreements.  It’s much easier (and more likely) for a team to reach high performance when they pay attention to the pattern they want to create and use these tools to help shape the pattern.

Values, ground rules, working agreements, and simple rules each serve a different purpose. Some teams find it useful to both simple rules (which help make values actionable) and working agreements (which address specific practices).

For both simple rules and working agreements, the list should be…

  • focused on amplifying desired patterns of behavior
  • aimed at helping the team achieve their task and team-work goals
  • generalizable
  • minimum specifications
  • short: no more than seven items on each list (fewer than seven is even better)

Many teams I meet have some variety of agreements about how to act. The groups that do best have a short list, and refresh it as needed.  I visited one group that had a list of 20 team rules.  That’s too many for anyone to remember. And, such a long list is indicative of a different issue–probably that the group members hadn’t developed common language around practices and had very different mental models of how software development works.

I don’t think every group needs to have a list of values, ground rules, group norms and simple rules. The point isn’t to explicitly govern all aspects of behavior.  I visited a group once that had a list of 20 ground rules. It’s always interesting to see how and whether team members hold the group and individuals to their espoused standards.  So look at the posted rules, and then observe how people really act.

“However they arise, such rules test a group’s own credibility. For example, if everyone agrees to make team meetings a top priority and then members fail to show up, it signals that the group may not be able to manage even the simplest of details, let alone conquer its performance challenges. The rules must be enforced. One team we know decided on total confidentiality to encourage open discussion. Early on a member violated the rule by talking to outsiders. When the rest of the team learned that the leader had gently, but firmly, reprimanded the offender, team discussions became even more open, free-wheeling, and, ultimately, creative.”

 

Can a team have 100 (or more) members?

I recently set aside my analog wrist watch and started wearing a runners watch. It’s accurate to the second on the face, and to a 100th of a second on the split timer.

I’ve noticed that when I have a precise measure, sometimes I use it, even when precision isn’t necessary.  For example, when someone in a workshop asks me how much time is left in a simulation or exercise, they don’t need to know that there are 2 minutes and 27.15 seconds remaining.  “Two minutes” would be an adequate response.

But there are times when a bit more precision is helpful– like in the way we name the social units that perform work in organizations.  Take the term “team,” for example.

I hear the term used for any group of people who share almost any common characteristic.

In some organizations functional groups are referred to as “teams” even though the people in those groups don’t work on a common project and their work isn’t interdependent or aimed at creating a whole product.

Teams have these characteristics:

Teams….

  • Share a compelling work goal, and that goal is well-understood by all members of the team. Some person(s)  in the organization eagerly await the product the team is producing–else there is no reason for the team. Without an external goals, a group may form a social unit, but they are not a team.
  • Members are mutually accountable for achieving the external goal. Team members do focus on completing their work; but they know that completing individual tasks–by themselves–isn’t enough for success.  Success comes from achieving the overall goal.
  • Are doing interdependent work that requires the skills of all to create a finished product.   Their skills are complementary and it is the combination of their skills that enables them to reach their goal.  It’s not like a ski team where everyone has the same skills, and the team result is the sum of individual scores.  On a team, the results aren’t additive, they’re integrative, generative, and collective.
  • Have a shared approach (though not a rigid process).  Team members make agreements on how they will work together.  They choose methods that fit the work and the goal.  They need enough constraints on their process so that they can work creatively–avoiding both anarchy and stifling routine.
  • Teams almost always have fewer than ten members. Some say five is the sweet spot.  When there are fewer than five members, there’s not much sense of teaminess.  When there are more than ten, the work is so big that it breaks on along natural lines…and so do the people, falling into sub-groups that act more like a team than the bigger unit.
  • Have shared history/identity.  This implies that a group is not a team on it’s first day together.  It also implies that shaking up groups every few weeks or months ensures that you’ll never really achieve the surpassing results that cohesive teams are capable of.

But what about a group of 100 people focused on a common goal of creating a whole product?

At a local user group, there was discussion about such “teams.”

That stretches the definition of “team” too far. Teams are small enough that they can coordinate planning and the flow of information necessary for day-to-day work themselves. They may use task boards, build lights, and other mechanisms to help disseminate information and reduce the load on interactions between individuals.  But they seldom need a person whose job is coordinating efforts of individuals. They’re small enough that they don’t break down into sub-groups.

One of the participants in the discussion asked how teams that large made decisions quickly.  The person advocating large teams (100+ people) described  how the overall manager pulled together people and information and then /he/ made the decision.  That’s a perfectly reasonable way to handle decision-making when there are 100 people working towards a whole product in a commercial enterprise.

But if there’s an overall coordinating structure, it’s not a team.  Teams are small enough that  they don’t need additional coordinating structures and people in coordinating roles who are not working members of the team.  (They still need managers who provide support and create an enabling conditions.)

Some times it does require the coordinated effort of hundreds of people to create a whole product.  Within that collection of people there may be units of social organization that are teams.  There may be work groups and individual contributors.  And there are people whose role is the efficient coordination of communication, activity, and decision-making across the various sub-units within the overall structure.

Each of these units–work groups, real teams, conglomerations of workgroups and teams–are different social organizations and have different needs.  Each requires different support structures, boundaries, and infrastructure.

Calling such disparate arrangements by the same term causes confusion, inappropriate expectations, and mismatched actions.

So let’s have a little more precision, please.

Team Trap #3: Failing to Navigate Conflict

“The absence of conflict is not harmony, it’s apathy .” Eisenhardt,  Kahwajy and Bourgeois

“(….or acquiescing, or avoiding).” Esther Derby

Conflict is inevitable at work. Sooner or later, people will disagree about what to test, how to implement a feature, what “done” means, or whether “always” means 100 per cent of the time or some thing else. If team members can’t muster the involvement for a disagreement, you’ve got problem. failure to navigate conflict

Conflict holds the possibility for building trust or tearing it down. How team members choose to approach conflict will affect the outcome, relationships, and ultimately the ability of the team to function.

Conflict often feels personal–but often it is not.

Structural Conflict

Systems and structures drive behavior, and in almost every organization structures create conflict.  Misaligned departmental goals, reward systems, emphasis on functional roles , and differing priorities can all engender conflict

But often people don’t recognize the structural source of the conflict. When the structure  behind the conflict isn’t visible people personalize the conflict.  I hear this when developers talk about how stupid the marketing people are or when testers complain that devs don’t really care about quality.

Communication Misfires and Mismatches

Once structure is ruled out, the most common source of conflict in groups stems from communications where language is misunderstood, mis-construed or data is missing.  These sorts of conflicts are usually easy to fix.

Many English words have precise meanings.  But there are plenty of common terms where definitions vary between professions or among people. When I worked in a mutual funds company the term share price was used to refer to the monetary value of an individual investment vehicle (a share of stock), and the monetary value of a share in an mutual fund.  If you didn’t know which area a person worked in, it was pretty confusing. Confusion can escalate to conflict when people don’t recognize that they are using one word with two (or more) definitions.

Entrenched Positions

Advocacy isn’t bad in and of itself. But when advocacy proceeds without inquiry, it can become a position conflict.  Position conflicts are often easy to recognize. Each person (or party) argues forcefully for a preferred solution without reference to the problem they are trying to solve.

When neither party is willing to explore the other option, examine assumptions, and  generate additional candidate solutions, advocacy turns into conflict.  Once people frame advocacy as win-lose, it’s hard to back down. Doing so might look weak, feel like giving in, or imply that one was*wrong.*  Most people will go to great lengths to avoid admitting they were wrong, especially when eating crow is part of the bargain.  Backing down from a strongly held position can feel like eating crow, especially when the other person crows over his victory.

At a recent workshop, a participant asked “Why wouldn’t you start by advocating your own idea?”  It’s an understandable question; in the US we grow up on in a system where the best argument (or at least the loudest one) wins, where competition is valued and zero-sum game thinking is the often the norm.

The first reason not to advocate is that when you advocate, you are not learning.  You’re defending and pressing your idea, not examining the problem and seeing different points of view. You aren’t learning about another possible solution or seeing improvements for your own.

Different Values

Arguing points of view and potential solutions is one thing; some times a conflict goes deeper and touches basic beliefs about what is valuable, true, and good.

This sort of conflict can look like a position focus conflict.  The difference is that each proposed solution seems as if it could solve the issue or be a reasonable approach. But either or both may leave out key elements of what the other party describes as “reality.”

Different Preferences and Styles

Differences in how people process information, make rational judgements, and plan their day can provide the fuel for conflicts.  So can differences in boundaries, social needs and styles, times-sense and ideas about ownership.

We find other people difficult when they don’t meet our expectations of “appropriate” behavior. The trouble is that each of us has a different definition of “appropriate.” To further complicate matters, some areas of mismatched expectations are easy to see and comment on, but others aren’t.

All Roads (May) Lead to Personality Conflict

Some times conflict does get personal–usually when a string of smaller unresolved conflicts fester.

From the outside it may look like two people plain don’t like each other.  At it’s worst, it looks like the warring parties are out to destroy each other, no matter what the personal cost to career prospects or the productivity of the team.

It starts with one interaction that goes off track, an irritation that’s not addressed, or an action that’s interpreted as a slight or attack.  When these situations aren’t checked an corrected, one person starts making up stories, stories about himself, and the other person.

The story he tells about himself portrays him as someone whose motives are pure, and bears no responsibility for the situation.  The other person is portrayed as the perpetrator, the one who is insensitive, crass, or down right evil.

Once you have some idea about the source of the conflict you can apply different strategies to steer back towards productive discussion.  Conflict isn’t bad, and it doesn’t have to be painful or confrontational.  Conflict–handled well–is an opportunity for learning, creativity, and building trust.

Entering Groups

Most of the time, people integrate into groups well enough that we don’t really notice how it happens.  But a recent rocky experience got me noticing.

Looking back over several teams I’ve observed and groups I’ve been part of, here are three (rather spectacular) examples of a newcomer failing to integrate.

***

A skilled XP programmer joined a group that was adopting agile engineering practices.  On his very first day as part of the team, he told his new team mates that they needed to start doing TDD, and gave them a lesson in refactoring.  Over the next several weeks, he found the opportunity to coach each member on his programming skills.

He was quickly ostracized.

***

A newcomer to a loosely organized professional group decided to join a two-day informal retreat organized by the group. The night before the retreat started, he announced to all within earshot that the group was highly dysfunction….and he was going to “fix” the group.

He started right in the next morning, issuing challenges and confronting people. When one of the organizers offered the newcomer feedback, the newcomer shouted at him.

It was later noted that that was the most dysfunctional event the group had experienced in their relatively long history.  The newcomer did not become an old hand–he was not invited back.

***

A new team member joined a distributed team that met face-to-face only twice a year.  The team arranged to hold one of their F2F meetings to coincide with the new member joining the group. The group hired a facilitator and worked with her to design an agenda that would share group history, revise working agreements to reflect the new group, and identify priorities for the year.

Without consulting anyone, the new member set up a meeting with representatives from a commercial product company. The new member announced he’d arranged a breakfast meeting prior to the main meeting to discuss the product and that five people from the product company would be present.

The “old” members declined the breakfast meeting. The group had been wrestling with the question of product endorsements and had decided, after much heated discussion, to remain neutral.  The newcomer felt the group was “resistant” to his ideas, and that set the pattern for his participation. At the  end of the year, he was asked to leave the group.

***

In each of these instances, the new group member wanted to contribute.  Why did their efforts backfire?

The new members failed to:

make contact and establish relationships before offering help and ideas.

understand the group, how the group viewed issues and develop empathy for their struggles.

orient to the group’s goal, history, and context and see how their ideas could fit in.

In contrast, when people enter groups successfully, they:

Get to know the other group members and become known by them.

Learn something of the group’s history and context.

Orient themselves to the goal, tasks, and priorities of the group.

Look for ways to contribute that line up with those goals and priorities.

People have different needs for affiliation and inclusion, which affect how they go about entering. But  you can’t skip these processes, if you hope to become part of the group.  And this is especially important if your views are divergent from the rest of the group.  Coming in loaded for bear won’t help you be effective. Showing empathy for the groups journey will.

Looking back on the three examples I described above, the result isn’t surprising.  However well-meaning the newcomers were, they failed to integrate into the group.

I suspect all three wanted to be helpful, and to do something meaningful for the group. I suspect they wanted to be valued by the group and were trying to prove their worth.

But without entering the group before they tried to turn it, their actions assured the opposite result.

 

Team Trap #1: Messing with the membership

One summer, long ago and far away, I was on a softball team.  It would be an exaggeration to say I played softball, but I did participate in practices, showed up for games and imbibed of the general post-game joie de vivre (beer).  There were a lot of team members like me. It didn’t matter so much if everyone turned out, or if some people didn’t show. Friends of friends were invited. They might play half the season and then disappear.  It didn’t matter because it wasn’t about reaching a goal, it was about socializing.  

Too many teams have boundaries like that softball team. It’s never clear who will show up, and who the team can count on to play. If you care about getting work done, don’t mess with team membership.

The fundamental criteria for a team is stable membership.  To be a team, people need to know who the team members are. Weak membership boundaries make it hard for any team to do it’s work. Unstable team membership leads to miscommunication and misunderstanding.  And that adds up to time and money. Team members can’t be mutually accountable if they don’t know who is makes up “we” when they commit to deliver.
Weak Boundary
Some organizations assign people who in between projects (or managers) to what ever team seems (operative word “seems”) to need more staff.  This is the warm-body theory of staffing, that holds that you can plug a person with roughly the right skills into a team and achieve productivity right away.  (There’s a related fantasy, that full utilization is desirable and efficient).  The reality is that plugging people into a team creates a revolving door effect and the effort to bring people up to speed slows down productive work (see Brook’s law).

In terms of getting work done (and keeping people engaged) organizations are better off it people who are “in between” work on their own special projects, attend training, or just take a breather.

The belief that a group can start working at full potential the first week they are together is a fantasy. It’s also a fantasy that teams can function with who ever shows up.