Category Archives: teams

establishing the conditions for team success, team dynamics, skills for teams.

Building Effective Teams: Miss the Start, Miss the End

(This article originally appeared on Gantthead.com)

“The beginning is the most important part of the work.” Plato, Greek philosopher and writer, 429–347 B.C.E.

I’ve written several articles about a manager’s relationship with a team that has already formed. A manager’s relationship with a team as they work is essential for cultivating a self-organizing team and maintaining a link with the organization. But a managers role in growing effectives teams starts long before the work actually begins.

The 60-30-10 Principle

J. Richard Hackman, has been studying teams for decades. One of his most significant findings is that 60% of the variation in team effectiveness is attributable to the design of the team, 30% to the way the team is launched, and 10% to leader coaching once the team is underway. By “design of the team,” he doesn’t just mean picking the best people. You also have to think about the nature of the work, articulate a goal, and plan for enabling supports.

Aim for Flexible, Long-lived Teams

You can call a group of people a team the first day they come together. But that doesn’t mean they’ll achieve teamwork right away. People need time to understand each others strengths, weaknesses and work styles. They need to agree on, try, and adjust the way they work together to find their groove.

In many organizations, managers from cross-functional teams to meet the needs of a specific project. In some cases, that means the team will be together for a long time. More often, it means teams will be disbanded after a few weeks or months. That’s barely enough time for a team to gel and gain the benefit of the team effect.

Analyze the work that’s in the pipeline. Aim to organize the work so that teams have “whole” work–creating a product or service that has meaning from a business perspective. Look at the trade-offs and tensions inherent in the product. Make sure people who represent those aspects are part of the team. Look for dependencies and to the extent possible, keep them within a team boundary. Form teams that have the breadth of skills to handle a broad range of work.

Then, bring work to the teams, rather than reforming teams for each new project. You won’t find a team that’s perfect for all the work in the pipeline. When teams lack a specific expertise, keep the core team in tact and add expertise.

Articulate a Compelling Goal

An effective goal statement does two jobs. First, it focuses the attention and effort of the team. When the team has a shared understanding of what their task is, they pull in the same direction.  When teams have don’t agree on the goal–or the goal is so vague it’s open to many interpretations–team members waste time and brain cycles arguing, working at cross purposes, or doing the wrong work.

Second, a well-formed goal engages the team in a meaningful challenge. An effective goal provides a sense of purpose to the teams work. The goal might be solving an important problem, enabling business, launching a new product, or meeting a  customer need. State the goal in a way that taps into purpose.

Take the goal handed down to the FinCore team: “Maintain the FinCore Product.” That goal isn’t enough to get someone out of bed in the morning. It talks about a process (maintenance), but leaves out the purpose. It misses the opportunity to tap into pride-in-work.  A more compelling goal might be:

Sustain the FinCore product by adding necessary functionality and ensuring the technical integrity of the code, so we can provide uninterrupted service to 40,000 customers.

Not all work is exciting and sexy, but all work should have a purpose. Making that clear will help people focus and engage.

Pillars of support

The right people and a compelling goal are a good start. But if you neglect the pillars of support, the team may still wallow. The pillars of support are:

Information related to the situation, domain, problem and technology. These reinforce the goal, and provide the context for the team to make good decisions.

Material support, such as machines, tools, facilities, adequate budget, and supplies. Adequate material support communicates that the work of the team is important. Starving a team for resources undercuts the goal and creates cynicism. Paradoxically, providing too much isn’t good either. A certain level of constraint can drive creativity (and over constraint kills it).
A strong foundation for team performance.

Expertise to supplement the knowledge and skills of the team when needed. Even when the team has all the skills required by the task, they may need an expert eye for consulting or reviewing. Some times there is some aspect of the work that requires scarce knowledge. It may not make sense to develop that knowledge on the team, or it may only be needed for a short time.

Feedback loops that connect the team to the organization. Regular demos of working software allow the sponsor or product owner to see how the team is doing–and allows for course correction. The heartbeat of progress builds trust.

If any one of these pillars is missing, you’ve put the team at a disadvantage.

This Sounds Like More Work for the Manager. Why bother?

Team design is a pay me now, pay me later proposition. It’s a myth that you can throw a group of people together and they’ll gel as a team. Strong effective teams don’t just happen by some magic chemistry. Well designed teams are more resilient. They make better use of the knowledge, talents, and skills of team members. They function and stay on track with relatively little management intervention. You may not always be able to bring together the perfect team. But you can set a team up for success….or failure. It is up to you.

Rethinking Manager’s Relationship with Agile Teams

This article originally appeared on gantthead.com 

In the early days of agile, some pundits (and developers) cried, “We don’t need no stinking managers.”

By now, most people realize that organizations still need management (and people in management roles) after they adopt agile methods. However, if those organizations want all the benefits of agile, managers must also change the way they work.

Managers can play an even more valuable role in organizations as teams become self-organizing and take on more responsibility. But if managers want teams to take more self-responsibility, they need to shift their focus from monitoring the day-to-day work of individuals and let teams grow up.  Here are three common areas of confusing as managers and teams negotiate their new relationships.

Messing with Team Membership

No group is a team the first day they are together.  Becoming a team takes time–time to learn how each person fits in and contributes, time to lean how to work together, time to develop group identity and trust.

If you want the benefit of the team effect, provide the enabling conditions:

  • A clear and compelling goal
  • Appropriate constraints
  • Stable membership
  • Time for the team to gel.

Plucking people off the team or poking people into the team causes a re-set in the team forming process. Mess with the membership often enough, and people will stop trying. When team membership feels like a revolving door, individuals won’t put in the effort to form team bonds. You may get a group that functions reasonably well, but you’ll miss out on the team effect.

That doesn’t mean that team membership never changes. People leave (or are asked to leave) and people join. Hiring new people for a team should always be a joint decision, involving team members. And when people are asked to leave it shouldn’t be mysterious to the team why that happened. (For more on hiring as a collaborative process, see this article.)

Delegating then De-delegating Decisions

As a general rule, delegating decision making to the people who are closest to the work is an excellent principle. Doing so can remove bottlenecks, lead to faster decision-making, and improve customer responsiveness.

Except when it doesn’t, as happens when a manager and a team haven’t clarified who makes which decisions. Or when a manager delegates a decision, but doesn’t clarify boundaries or constraints around that decision.

When managers see that a team is about to make a poor decision, they may be tempted to countermand that decision. Countermanding a decision prevents the problems that would have been caused by a faulty decision. But it leads do a different kind of problem–loss of trust between the team and the manager.  Team members may feel the manager wasn’t serious about delegating decisions in the first place. They may believe that he only delegates decisions on the condition that the team decides exactly what the manager would choose.  Such situations will damage a mangers relationship with the team.

If the team makes a decision that will result in real harm to the company, a manager must intervene. How he intervenes makes a difference. To prevent real harm to the relationship, refrain from blame. Acknowledging that key constraints weren’t clear or communicated will help. Use the opportunity to learn from the mistake, and to set appropriate boundaries for team decisions.

Strategic decisions belong to management. But tactical decisions, course corrections, and decisions that affect day-to-day work belong with the development team. Some decisions fall in between, and require both management and front-line input.

Work with the team to identify which decisions are squarely with the team, which ones you share, and which ones are management decisions. Then set boundaries, about cost, impact, and scope.

For example, when it comes to hiring a new team member, the decision about what skills and qualities to look for in a new team member is probably a joint decision.  The choice among candidates is best done as a recommendation from the team (which you may over-ride at your own peril). But the offer and salary are neither a team decision or a joint decision. Employment terms and salary (in most organizations) are management decisions.

Clouding Team Commitments

One of the secrets ingredients for team success is that team members make commitments to each other to complete their goal. Peer pressure can be a wonderful thing. But commitments can lead to conflict, it’s not clear who makes commitments to whom about what.

Fred, a member of an agile team, participated in a planning meeting where he and his teammates committed to deliver six stories during the next iteration.  Then Fred when to the team manager, Megan, to get approval for a two week vacation, starting the second week of the next sprint–as he had done every spring for the last four years.

But this time, the result was a mess. The other team members were mad at Fred, for committing his effort to the team, when he knew he wouldn’t be in the office for half the next sprint.  The team members were mad at Megan, too, for giving Fred permission when they thought he should have talked to them first. Fred and Megan felt attacked–for doing what they’d always done.

Managers are still point-person for matters of company policy. But work commitment a happen between the team as a whole and their product owner or customer. Megan and Fred landed in the middle of that. In the end, Fred took his vacation. The team needed to renegotiate their commitment to the product owner. Megan attended the meeting to explain what had happened to the product owner.

When Fred (gratefully) returned from two weeks at the cabin with his three kids and the in-laws, they all had a sit down. They talked about which commitments the team could make, what the team could negotiate among themselves and where Megan needed to be involved for legal reasons.

I hear managers say they want teams to take more responsibility. The best way to make that happen is for managers to stop acting in ways that take responsibility away from teams. Start with these three areas.  Then, spend some time examining your relationship with the team. What else could the team do that would enhance their autonomy and responsibility? What else are you doing that might confuse the team about how much responsibility they really have?

Bridging Structural Conflict: Same and Different

No two people or groups are the same, but their differences don’t have to force them apart.

I recently talked to two groups who were feuding. On one side were the development teams, tasked with delivering new functionality every two weeks. On the other were the operations folks, who were charged with keeping the environment stable and available. Simmering resentment was getting in the way of working together. People were talking through proxies and hurling insults.

This is not the first time I’ve seen development and operations at odds.Conflicts like this are almost always structural. For example, the conflict may arise from the way the company is organized to accomplish work, different and conflicting goals, and different professional points of view. But, when people don’t realize the source of the conflict, it tends to get personal. People on each side of the conflict start talking about “those people,” as if the people on the other side are stupid, bad, or wrong.

Welcome to the fundamental attribution error. Humans tend to explain others’ behavior as resulting from personal characteristics and ignore the role of external circumstances. It’s seldom true that people have evil motives, are intentionally blocking progress, or are as dumb as dirt. The people employed in our field are reasonably intelligent, well-intentioned, and come to work wanting to do a good job.

Some structural conflicts dissolve if people are organized differently or when professional concerns are harmonized for complementary action, such as working together to create a software feature. When testers, GUI developers, database developers, and middleware developers come together in a cross-functional team, their differences can be a source of strength rather than conflict.

But, the structural conflict between the development (dev) and operations (ops) groups I was working with wasn’t going away. Dev and ops do fundamentally different kinds of work, with different rhythms and needing different skills. However, these two groups did (as they do in most organizations) need to find a way to dial back the conflict, appreciate each other, and work together reasonably well.

In cases like this, I find it helps to look at how the groups are similar and different. So, I asked the groups to work together to make a chart listing similarities and differences.  Same and Different Lists

As the list of differences grew longer, I felt a niggling worry that there wouldn’t be a difference the two groups could negotiate. So far, the differences they’d listed weren’t going away; they were inherent in the work. The items in the Same list were important—that’s the common ground where people can land when conflict arises—but this list was very abstract and “Mom and Apple Pie.” There wasn’t enough to bridge a gaping chasm.

Then, one of the ops specialists busted loose. He started listing all the ways the dev teams failed to prepare for production turnover.

And, there it was (with a little reframing to get the blame out)—an area where the two groups could work together. Redefining “done” and making a production checklist gave them a chance to work together on a small, bounded project. Working together on a shared goal would help each group understand the other’s context, know each other as people, and understand how their different concerns added up to a similarity: “Our work is critical to the business.”

There’s some wrangling yet to come before these two groups stand down, join hands, and sing “Kumbayah.” Some people may even be reluctant to give up their belief that “those people” are idiots. It is convenient to have someone to blame rather than recognize that some conflicts can’t be resolved, and it doesn’t imply anything about intelligence or motives. It’s not likely—or desirable—that the two groups become of one mind on all things. They do different work; what’s necessary is that they find a way to cooperate and coordinate in a way that meets the goal of delivery and stability.

If you find your group in conflict with another, you can try this exercise to bring some needed coherence. First, discern that it is a structural conflict. Conflicts of this sort tend to happen when there are different departments or goals, different professional interests, different types and rhythms of work, and when the teams do not have an interdependent goal at the level where they do their work. Everyone in a company may have a goal of “producing valuable products profitably,” but at a department level, groups may be at odds. For example, both developers and auditors want the company to be successful, but they have different roles in meeting that goal, which often feel at odds—i.e., structural conflict.

Here’s another check. Some structural conflicts are self-imposed, as when testers and developers report to different managers and are measured differently. Testers and developers do have an interdependent goal: It takes both testing and development skills to deliver a complete and reliable product. If you bring together both on a cross-functional team, the conflict usually dissolves.

If you feel it really is a structural conflict, find someone neutral to facilitate the session. Get both groups in the room. Avoid recrimination and blame, and establish the following ground rules to keep the discussion productive:

No labels. That means neither group can say the other group is lazy, sloppy, or a bunch of slackers. Positive labels aren’t much better; they don’t give specific information, and they imply that one side is empowered to evaluate the other. The power-difference message comes through whether the labels are negative or positive.

No characterizations about motives or intelligence. Remember the fundamental attribution error? People and groups that are in conflict develop stories about the “others.” Over time, these can evolve into harsh judgments about the others’ motivation, intelligence, and general fitness as human beings. The judgments show up in statements such as “They don’t care about quality,” “They don’t get it,” and worse.

When you catch yourself saying something like “They don’t care about X,” rebuild the sentence as “They have a different perspective on X.” Rebuild “They don’t get it” to “They don’t see it the same way I do”—which might just prompt you to think, “And I bet I don’t see it they way they do. I wonder what they see that I don’t.”

Make the list. Write down all the ways the groups are the same and how they are different.

Consider these questions to help the group process the list:

Which differences can be negotiated or changed?

Which ones are most significant?

Which similarities and differences help us do our work? Which ones get in the way?

Would it help us do our work if we were more the same? More different?

Not all differences make a difference, and not all differences can (or should) be eliminated. We need different skills, different points of view, and different professional concerns to create valuable products.

The point is to find something that the two groups can work on together to build a bridge. Then, when conflict arises again (and it will) they’ll have some common ground to land on (the similarities) and at least one experience of working together.

Sometimes, fate intervenes to give two groups a common goal—like a fire or flood in the office. After fighting fire or flood, groups tend to see each other as real human beings, not the sum of misattributed characterizations. I don’t wish fire or flood on anyone, so look around for additional natural opportunities for to work together—but don’t start fires.

This article originally appeared in Better Software Magazine.

Peer-to-Peer Feedback

One of the traps people fall into on teams is withholding information that’s critical for the team to function. Sometimes the information is about friction between team members. When team members don’t have a way to talk about small frictions, they turn in to big events, damage relationships and spill over onto the team.  So here’s how to have one of those difficult conversations.

***

Not long ago, a developer approached me for advice about a problem team member. The developer reported that one team member was causing resentment, alienating other team members, and generally making life difficult for all. No one wanted to work with him.

“What is he doing to cause all this?” I asked, wondering what sort of wildly dysfunctional behavior was going on to cause these problems.

The answer surprised me. “He picks his nose,” the developer said.

“He picks his nose? Have you talked to him?”I asked.

“Of course,” my developer friend replied. “I talked about the importance of manners at our team meeting. And I talked about how we all had to be careful about spreading germs.

“He still picks his nose,” he continued. “It’s gross. The only thing I can think of is to start picking my own nose to see how he likes that.”

Nose picking is an unattractive habit. But the real source of this team’s problem isn’t nose picking. The real problem is that team members don’t know how to have an uncomfortable conversation—peer-to-peer.

How to talk about a difficult subject.
Remember, the over-arching goal of feedback is to improve working and social relationships. When you think of it that way, it’s easier to find a respectful way to deliver a difficult message.

Use “I” language.
Talk about what you see, and what you feel. Start your feedback with a sentence that starts with “I,” rather than with “you.”

Describe what you have seen and heard.
Stick to the facts of what you have seen and heard. Describe behavior rather than applying a label. For example, “Yesterday in our team meeting I heard you call Sara an idiot.” rather than “Yesterday you were rude.” Labeling the other person only puts him or her on the defensive.

Own your own feelings about the situation.
Some people advise using this formula to give feedback: “When you do X, I feel Y.” But this construction implies that one person is the cause of another’s feelings. No one else can make you have feelings. To remove the implied cause and effect, you might say, “When I hear you call Sara an idiot, I feel like you are disrespecting her,” or “I want to tell you about something that you do that’s a problem for me.” Then describe the behavior.

Talk about the effect the behavior has on you.
People often don’t realize the effect their behavior has on other people. Explain (briefly) how the behavior you are talking about effects you. Explaining the impact gives the feedback receiver information so they can choose what to do with your feedback. If there’s no impact, then a request seems arbitrary. The conversation could start with “When I hear you call Sara an idiot, I feel like you are disrespecting her. I worry that you talk about me that way when I’m not in the room.”

Make a request.
Most people don’t like to be told what to do, even by a peer. (Telling someone what to do implies that you are not actually peers.)  Ask for joint problem solving to work out a different way to work together.  But there are times when you want a particular behavior to change or cease.  Then make your request clear:  “I want you to stop calling Sara and our other co-workers idiots,”  or “Please check with me before you commit my time to a meeting.”

Don’t sell past the close.
Sales people warn about “selling past the close.”  Selling past the close happens when the prospective buyer has made the buy decision, but the sales person keeps selling.  This breaks the relationship because the buyer feels pressured and senses that the sales person isn’t actually listening to him.  And there goes the sale.

The same think can happen with feedback.

It’s helpful to prepare what you want to say–as it is in any situation where you feel anxious.  But don’t just stick to your script.  Pay attention to the other person, and listen to his response.  When he signals that he’s gotten the point, zip it.

If you open with “Laura, I want to talk to you about the meeting yesterday,”  and she responds “Oh, it’s about how I interrupted it you…I’m so sorry, let my enthusiasm carry me away. I know I do this, and I’ve asked Sara to help me monitor myself….”  Stop.  She’s got the point and continuing your feedback message won’t help your relationship.  Sometimes the feedback receiver gets it at the description, or when you state the impact (“Oh, I didn’t know my speaker volume irritated you.  I’ll turn it down.).

Don’t expect an admission of guilt or contrition.  Often, people need time to absorb what you’ve said, especially if this is the first time they’ve heard about a problematic behavior.  And after all, the feedback is about you, not the Truth about them.

It’s not always easy to give feedback. I still feel anxious when I prepare for a difficult feedback conversation. I have almost always found that the pre-conversation anxiety is worse than the actual event. And the pay off for having the conversation is well worth the effort.

So what happened with the nose-picker?
I advised the developer to have a private conversation with the offending team member. “Give him the benefit of the doubt,” I said. “What if he’s unaware he’s picking his nose? It may be an automatic habit. And even if he’s aware he’s picking his nose, he may not be aware of how if affects you and other people on the team.”

The developer agreed reluctantly, and we worked out a little script. Here’s what he decided to say to his nose-picking colleague:

“Joe, this is really awkward for me. I want to tell you about something that you do that’s a problem for me.”

[Pause]

“I’ve noticed that during our team meetings, you pick your nose.”

[Pause and wait for a response. This may be all you need to say.]

“When I see you picking your nose, I feel worried about you spreading germs. My reaction is getting in the way of our working together.”

[Pause and wait for a response. This may do it.]

“Would you please stop picking your nose while we’re working together?”

The next week, he reported back.

“You’ll never guess what happened,” he said. “You were right, he wasn’t even aware he was picking his nose. But it was really awkward,” he continued. “He was embarrassed but he was also grateful I told him. I guess I shouldn’t have waited so long.”

It is hard to address interpersonal and work issues directly-even when the issues aren’t as awkward as someone picking his nose. Respectful feedback can improve working relationships. And handling issues directly keeps little irritations from growing into major divisions.

An earlier version of this article appeared on Stickyminds.com.

Real leaders make space for others to shine

I’ve seen a renewed cry for leaders in organizations lately. Too often in these discussions, the definition of “leadership” boils down to a role where one individual creates a vision for others to follow. That’s not enough. We need more leadership, not just more anointed or appointed leaders.

“Leadership” is most potent when it’s a verb, not a noun. Leadership is taking actions that will help a group create a product, achieve their charter, grow in capability, solve problems, or improve results.

Looked at this way, we can create organizations that are full of leadership, not just individuals in leadership roles. And, sometimes, the most potent leadership action is the quiet act of choosing to follow. I call that being an active follower. Here are three ways to be an active follower on your group or team.

Step Back and Let Someone Else Step Forward

When one person on the team is the most skilled, it’s easy for the rest of the group to over rely on that person. Overreliance on one person poses a risk. On the operational level, there’s the truck factor: If the most-skilled or sole skilled individual leaves the job for whatever reason (and we hope it’s not because he is hit by the proverbial truck), the team won’t be able to function. No one will be ready to step in. In cases of extreme overreliance, the rest of the group won’t be aware of all the work that person was doing. It might take weeks before someone else can identify and pick up the pieces.

There’s also a long-term risk to team health. When person takes the lead, others don’t have the opportunity to learn and develop their own capabilities. If there’s no place to grow, people will check out and leave—or, worse, check out and stay.

Break Gridlock by Deferring to Someone Else’s Idea

When too many people want to be “the leader,” the result often isn’t action but a complete lack of forward movement. If no one is willing to step back and declare “I don’t have to have my way; let’s try your way this time,” the result is gridlock. An active follower seeing gridlock will choose to follow someone else’s lead for the good of the team.

Take a Supporting Role

There’s a reason that the Oscars have an award for best supporting actor. Without the supporting actor, the work of the lead falls flat. Many jobs demand the work of two people, but it’s not equal in every case. An active follower is willing to take that supporting role and let someone else take the lead. You may not get the credit this time, but chances are that if you’re willing to support someone else today, she’ll be willing to take the supporting role another day.

Back up a team mate when he chooses a difficult-to-implement story–or one that’s at the edge of his technical skills. Pair program with him, but let him drive. Offer informal peer review, offer feedback, or coach.

Let a less-senior member of the team make an important presentation. Play a supporting role by offering feedback on a draft, listening to a practice run, and sharing tips and experience that will help the other person succeed.

When only one person leads, the rest of the team members are turned into passive followers. Unlike active followers, who make a choice to allow someone else to lead in a particular instance, passive followers always hang back. Passive followers fall into the habit of depending on others, whether it’s keeping track of time, coming up with ideas, or galvanizing the group into action. Passive followers wait for someone else to step up, not out of an intention to achieve results, but out of habit or a sense of disempowerment.

Over time, the de facto leader may resent being the only one who attends to time or urges action. When only one person comes up with ideas, the team is missing out on a rich mix of ideas to choose from and may be missing good options. Other team members don’t exercise their own creativity, and the team as a whole misses out on their talents. Some people prefer to let others take the lead and the credit (and also the blame). But, most people want at least a slice of the glory. When they’re always in the background, they don’t get that and eventually disengage. They may even undercut the star who won’t move off center stage so they can get their own moments of fame.

Productive teams count on leadership throughout the team and know that each can lead at different times. Likewise, they expect that, at some point, each will follow another’s lead all in the interests of the team and team results.

When you consider your team or group, which sort of followership do you observe? How is that serving your team? What are other ways to be an active follower? Post your comments.

(An earlier version of this article appeared on Stickyminds.com.)

Are you part of the team if you are on the team part-time?

“Part-timers just don’t seem to fit in with the team,” a manager complained recently. “I do everything I can to impress on them the importance of teamwork and team spirit, but they just don’t gel with the team. What can I do to motivate these people to fit in?”

“These people just aren’t accountable,” another manager declared, referring to individuals who were assigned to four or five projects at a time. “I need people who will be accountable.”

Here’s the news nobody wants to hear:

The problem is not with the part-time people; it’s with the part-time assignment.

When people are assigned part-time to teams they face several hurdles that hinder their ability to contribute. The hurdles are structural, not personal.

Priority

When a person is assigned to more than one team, she’ll gage priority by the proportion of her time that’s allocated to each project. One tester I know was assigned 90% to developing manual test cases and 10% of her time to creating a “critically important” automated test harness. No matter what words her manager said about the importance the test harness, the fact that she was directed to spend only 10% of her time on it communicated a different message.

Furthermore, when she attended meetings or working session with the automation team, she spent most of the time catching up on what had transpired since her last sliver of time with the team. The arrangement wasn’t satisfying for her, and frustrated the automation team. Soon, she stopped working on test automation at all.

Ambiguity

Many people will opt to spend their time on work that has clear-cut outcomes over work that’s ambiguous. The more clarity around the part-timer’s contribution, the more productive the situation will be for everyone. When the assignment isn’t clear–or the relationships between the part-timer and the team isn’t clear, it’s harder for the part-timer to contribute effectively.

Team Cohesiveness

If the full-time team is cohesive, the part-timer may not be able to fit in. Gelled teams develop their own subcultures. They may have unspoken rules of engagement, communication patterns, and established relationships that make it difficult for someone who isn’t full time to fit. Over time a part-timer may acculturate, though the process will be slower than it would be for a full-time team member.

Missing Context

When someone works on a team part time, he is by definition missing part of the context of the team. While the part-timer is off doing something else, the full-time team makes decisions, solves problems, and exchanges information. While the full-time team may document and transmit major events, there are numerous small decisions and communication events that may not seem important enough to pass along but still affect the way the work is done. The adage “You never step in the same river twice” fits this situation. Each time the part-timer re-enters the team, the team has inevitably moved on from the last time the part-timer participated.

Design Before You Assign

So, what can managers and team members do to improve the situation? First look at the work and how the part-timer needs to contribute. Design based on the needs of the work before you assign the worker to the team part-time. As a contributor, if you find yourself assigned, negotiate the dynamic of the relationship so that you–and the team–can be successful.

Here are some of the questions to ask about the work:

Is the contribution time-limited, meaning that part-timers skills are needed for several days, but not for the duration of the project?

Maybe the person only needs to contribute at some critical point. Perhaps he is only needed for one or two iterations, when the team is working on a particular feature. Consider contracting for the person to focus full attention for those periods of time.

Can the contribution be batched so the part-timer interacts with the team for a day or two a week?

Blocking out a day or two a week to work with the team is more effective than having the part-timer spend an hour here and an hour there with the team. This may require more clarity and coordination from the full-time team, but it will make better use of everyone’s time in the long run.

Is the part-timer needed for hands-on work, or can he act as a reviewer, consultant, or coach to members of the full-time team?

Sometimes the full-time team needs to use a certain skill a little bit each day or week, but needs the skill over all long period of time. In this situation, it probably makes sense to develop the skill on the team and have the part-timer act as an expert coach or reviewer until the full-time team members are self-sufficient.

A person can act as a resource to a full-time team without being a member of the team. The team can contract for deliverables, consulting, review, or time. After you understand the nature of the work and the contribution needed, work with the full-time team and the person whose skills are needed to develop explicit agreements. Don’t rely on happenstance and assumptions. Reach agreement on how the full-time team and part-timer will work together, how the part-timer will contribute, and how the full-time team will keep the part-timer in the loop. Don’t expect he’ll gel completely as a member of the team–because he won’t.

Sometimes I see groups in which almost everyone is part time. Sometimes a group working together part time will gel, usually when they have a long, shared history. Don’t expect groups made up entirely (or mostly) of part-timers to gel as a team without time and attention to creating a cohesive whole. And as long as the group is accomplishing its goal and managing the interdependencies between tasks, that’s OK.

It may look simple on paper to say a team needs a specialized skill X amount of the time, but by analyzing the nature of the work and being explicit about part-time arrangements, you will help the team and the part-timer work together more productively.

Dealing with “Difficult” Co-workers

We all have coworkers who rub us the wrong way, get on our nerves, and generally drive us crazy.

Let’s consider these examples of three people who have difficult coworkers:

1. Ted finished working on a difficult bit of code and headed for the team meeting. When he got there, Sandy looked at her watch and glared at him. “You’re late,” she snapped. “Hey, it’s only ten after,” Ted responded.

How selfish! Sandy thought to herself. Ted has no respect for other people’s time.

Meanwhile, Ted wondered why Sandy made such a big deal about arriving precisely on time. It’s hard to put down what I’m working on when I’m in the middle of something important. What’s more important, anyway?  Getting the code done so we can release this fix or coming to a  meeting? Why doesn’t Sandy understand that?

2. When the technicians showed up to install more memory in Frank’s computer, Frank asked Talia if he could use her machine, since she was going to a meeting. “Sure,” Talia replied. When she returned to her cube and logged into her computer, she discovered that Frank had changed the settings. She spent half-an-hour fixing the obvious ones, and stumbled over more of Frank’s little “fixes” for the rest of the day.

Sheesh, thought Talia. He asks to use my computer for an hour, and he acts like it’s his. I’m never letting him use my computer again. I wonder if he read my mail, too.

Frank, however, was pleased that he’d set up several helpful shortcuts on Talia’s machine.

3. Sam greeted Jennifer with a cheery hello as he entered her office. “How was your weekend,” he asked. “Did you do anything fun with the family?” Jennifer scowled. “Let’s get down to business, Sam,” she said.

What a grouch, Sam thought. I’m just trying to be friendly and build a working relationship.

Jennifer, on the other hand, wondered why Sam was so nosey. Doesn’t he get that I don’t want to discuss my private life at work? I don’t want to talk about having to take Chad for a psych evaluation over the weekend.

No one in these examples is a bad person. They aren’t wrong or behaving atrociously. But Ted, Frank, and Jennifer are acting in ways that are different from how Sandy, Talia, and Sam expect people to act.

The opposite is true, too: Sandy, Talia, and Sam are acting in ways that Ted, Frank, and Jennifer find puzzling and irritating.

Conflicting Definitions of Appropriate Behavior

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.

In the first example, Ted and Sandy have different ideas about how important it is to arrive exactly on time. Sandy believes that not arriving on time shows disrespect for the group. Ted believes it’s more important to accommodate individual needs and be “close to on time.” These mismatches are easy to spot and most people are able to reach some accommodation because there is some external reference point: the clock and the agreed upon meeting time.

Other mismatches are about personal space, personal property, and privacy. What may seem like friendly conversation to one person may seem like prying to another, as in the example with Sam and Jennifer. Fred doesn’t view Talia’s computer as “hers.” To him, it’s company property and, therefore, belongs as much to him as to anyone else who works in the group. There’s no external reference point for these.

Each individual has his own idea of what’s appropriate. Psychologists call them “boundaries.” But, unlike boundaries on maps, we don’t always know where our boundary lines are until someone crosses them. Others don’t know where our boundary lines are unless we tell them.

Deal with Difficult People Where You Have the Most Leverage

We can hope that people we find difficult will realize how unreasonable they are and will change on their own, but they won’t. They won’t wake up and change because they don’t see themselves as difficult or inappropriate. These troublesome (to us) people believe they are acting in a reasonable way. In fact, they may wonder why other people are so upset.

To deal with difficult people more effectively, start where you have leverage. Start with you. When you feel yourself becoming upset, ask yourself if you’ve been clear in what you expected from the other person. Check on your emotional response. If you are having a strong response and wondering why the other person doesn’t get it, it may be a clue that someone just walked all over your boundary lines for acceptable behavior.

Understanding why people drive us to distraction at work doesn’t mean you have to tolerate behavior that you find distressing. Talia could set a boundary with Frank by saying something like “Frank, it’s fine for you to use my computer as long as you return the settings to my preferences when you’re done.” You can always make a request for a change—not for the other person to fix herself, but to respect your boundaries or find a third way that will work for both of you.

Life is too short to let the people we work with fray our nerves. We can’t change those irritating people, but we can recognize the source of our irritation and change our own response.

An slightly different version of this article appeared on stickyminds.com.

A Tale of a Too-Hands-Off Manager

I recently worked with a team that was struggling. One of the team members, Tad, wasn’t playing by the rules the team had established. When the team formed, members agreed that each day they’d have a fifteen-minute stand-up meeting to report on progress. The team members agreed that they’d chunk their work into tasks that were a day or two long, knowing that would help them stay on track and make progress visible.

But all was not well. When the other team members picked a story off the task wall, they’d break it down into tasks and post them back on the wall. When Tad picked a story, the card disappeared from the wall. At the stand up meeting, his reports were vague. “I’m coding,” he’d say.

After a couple of rounds of such murky reports, two team members, Sally and Will, sat down with Tad.

“What’s up?” Will asked. “Do you need some help?”

“No,” Tad replied. “I’m working on it.”

“But we don’t know what progress you’re making,” Sally said.

“I’m working on it,” Tad replied, staring at the notebook in his lap.

“Tad,” Will implored. “You agreed to report tangible progress every day. We all did.”

Tad closed his notebook. “I’m working on it. Now leave me alone so I can keep working on it.”

The team’s agile coach tried, too. After a vague report in the next stand-up, the coach probed for more information.

“What exactly are you working on, Tad?” he asked.

“The reset feature,” Tad replied.

“When will you finish it?” the coach asked.

“I’ll be done when I’m done,” Tad replied. “I’m working on it.”

“That’s not good enough,” the coach said, laying down the law. “When you don’t report demonstrable progress, it hurts the team. We don’t know if we’re on track or not. We can’t give our customer an accurate read on meeting our iteration goal.”

“I’m working on it,” Tad replied.

The coach tried benching Tad, telling him he couldn’t take any more tasks. Tad took them anyway, working at odd times, checking out code, and keeping a local copy on his machine.

After weeks of Tad’s odd behavior, the coach approached the development manager. “We’ve tried everything we can think of,” the coach said. “We need you to step in and help us get Tad on track.”

“You are self-organizing,” the manager demurred. “You need to figure out how to deal with team members.”

And that was that.

The team tried everything it could think of to induce Tad to report on his work, finish his work, and see his contribution—or lack thereof—to the team’s iteration goals. And as their manager continued with his “hands off” attitude, team members’ morale plummeted. It felt like their manager had abandoned them. He had.

Fortunately for this team, the hands-off manager left the organization. The new manager recognized the team was struggling and handled the performance issue.

Managers of self-organizing teams need to discern when it’s time to step in and when to step back, allowing the team to solve the problem on its own. How do you know when a light touch is called for and when action is needed? Ask:

  • Does the team have the knowledge to solve this problem?
  • Does the team have the experience to solve this problem?
  • Does the team have the will to solve this problem?
  • Does the team have the courage to solve this problem?

If so, give the team some time to work out the issue. If you sense team members are stuck, coach them with open-ended questions to recognize the resources they already have to address the issue.

  • Is this a new area of responsibility for the team?

If the team is taking on a new responsibility—one that’s been yours in the past—offer a process to help the team make the decision or solve the problem. Be wary of stepping in. If it looks like you are trying to take the decision back or influence the team, your credibility is lost.

  • What are the consequences of failure?

It’s been said we learn more from failure than from success. So do you really want to deprive the team of a learning opportunity? Consider the consequences of letting the team learn from its mistakes. Most projects can survive a missed iteration goal. Most projects can survive going a short way down the wrong technical path.

This article originally appeared as a sidebar to an article in Better Software magazine.

Tale of a Yo-Yo Manager

There is much more to empowering a team than simply stating “You’re empowered.” Consider the three Ws of empowerment: “what,” “when,” and “why” when creating boundaries that define which decisions are the team’s and which need management approval.

“I want you to be empowered,” Bob told his team at the team meeting. But several weeks later, Bob expressed his disappointment to his colleague Sue. “My team members have a victim mentality,” he said. “They’re too passive. They wait for the team lead to tell them what to do. And the team lead checks everything with me. I want these people to show some initiative!”
Sue cocked her head. “What have you seen that makes you say that?”

“You remember the middleware bug we had last month?”

Sue nodded.

“Well, the team came up with a solution that was all wrong,” Bob said. “It’s a good thing I caught it before they forged ahead. If I hadn’t wandered into the team room and seen the diagrams on the whiteboard, I never would have known about it.”

Sue raised an eyebrow.

“I called the team into a huddle and explained why that idea wouldn’t work. Then I had a meeting with the team lead. I really dressed him down. He should be leading them–not letting them make stupid mistakes.”

Sue’s other eyebrow went up.

“I want the team to dig in and solve problems,” Bob said. “So last week at the team meeting, I asked everyone to offer at least one idea about how we can meet the deadline for our next release without dropping any features.

“One of the team members actually said it was impossible. Another one suggested we could implement a partial solution that included some manual work in the customer care department. When I told her that she hadn’t examined all the issues with her approach, she backed down! How can we come up with creative solutions if we can’t argue our ideas?

“Now they just sit there. It’s like they are afraid to make any decisions at all.”

Sue held up her hand to stop him.

“Bob,” Sue said, as gently as she could, “do you think you might be sending mixed messages?”

Bob looked puzzled. “What do you mean?”

“I wonder how your team members felt when you overrode their technical design.”

“I saved them from a big mistake,” Bob said. “I’d think they’d be grateful.”

Sue shrugged. “Maybe. And I bet they also felt like you told them the decision was theirs to make, and when they didn’t do what you wanted, you took the decision back.”

“But what they were planning was wrong!” Bob exclaimed.

Sue nodded. “No, it wouldn’t have been very efficient. But it might have been more effective in helping team members learn how to think through the issues together. They are new to this and still need to learn through experience.

“Do you remember when you were learning how to drive?” Sue asked.

“Sure. My dad took me to a big, open parking lot and gave me instructions: Ease up on the clutch, press the gas pedal gently. After I mastered the clutch, he took me out on a quiet road.”

“And after you received your license, did he let you drive anywhere, anytime, with no restrictions?” Sue asked.

“Of course not. At first I was allowed to drive to school alone, and later I was allowed to drive after dark. It was months before my dad let me drive with my friends in the car. At the time I hated it, but looking back, he was helping me build my driving skills before he turned me loose.”

“Exactly,” Sue said. “And that’s what you didn’t do with your team. In essence you told your team members they could drive anywhere. Then, at the first small mistake, you pulled their license and showed you didn’t trust them.”

“Oh,” Bob said. “I never thought about it that way. You mean I’ve actually brought about exactly what I didn’t want? I’m making the team more passive instead of more empowered?”

“The key to empowerment is to tell team members what the boundaries are before they cross one by accident,” Sue said.

“Otherwise, they’ll feel jerked around,” Bob said.

Sue nodded. “If you really want to empower your team members, you need to consider their skills and how much you trust them. Find the boundaries where you feel comfortable with the risks and give them free reign within that area. That’s probably not the empty parking lot where your dad started your driving lessons, and it’s probably not the freeway during rush hour, either.”

“I have to work harder at this empowerment thing than I thought,” Bob said.

“There’s more to it than declaring, ‘You’re empowered,'” Sue agreed. “I think about the three Ws of empowerment: what, when, and why.

What delineates the decisions and the standards that apply when making those decisions.

When defines boundary conditions. For example, my test team can make decisions about test approaches where there isn’t an existing test bed and when the tools team members need are open source or already available within the company. If they want to try a testing approach that requires a new tool or replaces a functioning test framework, then they come to me with a recommendation.

Why sets the context. I find that when people see how their decisions fit into the value stream and affect customers and the bottom line, they make better decisions.”

“I can’t just go in and tell them what the boundaries are now,” Bob said. “They won’t believe me.”

“You’re right, Bob. First, you need to rebuild trust, and the best way I know to start that process is to admit you’ve made a mistake.”

Bob gave Sue a pained look.

The very next day, Bob called a team meeting. “I’ve made a big mistake,” he said. “I asked you to make decisions and offer ideas, and then I stepped in and took over. I was wrong to do that. I was worried about looking bad, and in the end, my actions made us all look bad.”

Several team members looked down at the table. The team lead squirmed in his chair.

“Are you willing to try again?” Bob asked. “I have some ideas on how we can all be clear on which decisions are yours and which decisions are mine.”

Tentatively, the team agreed. Together, Bob and his team created a grid that listed decisions and boundaries.

Bob realized that he wasn’t ready to let go of every decision. He specified some areas where he would make the decision based on the team members’ input and some cases where he wanted to review their decision before they implemented it. He was surprised to see that team members were grateful that they wouldn’t have to carry the weight of all the decisions.

Bob asked the team to remind him if he started stepping over the boundaries he’d set.

It took some time for the team to trust him again, but eventually the team saw that Bob really had turned over a new leaf. Bob realized that the team was gaining skill and perspective in making decisions. They weren’t always the decisions Bob would have made, but he had to admit the team’s ideas and choices worked out reasonably well–most of the time. And when the decisions didn’t work out as hoped, the entire team held a decision retrospective to learn from its mistakes.

Several months later, Bob went out to lunch with Sue. “The team is making better decisions and seems to have more ownership of its work,” he said. “Once we agreed on the boundaries, the team stepped up to the plate. Empowerment really can work,” Bob said. “But it works best when the whatwhen, and why are clear to everyone involved.”

This article originally appeared in Better Software magazine.

Is Collaboration the Right Way to Work? It Depends.

As a manager, your job is to organize people and work for success. That includes work design–figuring out whether you have a group or a team and creating an environment where people can do their best work. I don’t know about you, but work design wasn’t part of my training as a technical person, and it’s not explicitly included in many business and management programs.

The default belief seems to be “teams and collaboration are good,” and in a previous column I wrote about the benefits of collaboration. But is collaboration always possible? Is it even the right thing to do in every situation?

In this article, I’ll show different levels of collaboration and lay out the questions that managers need to answer to decide whether they have a group or a team.

Connection

Josh and Julie work in a tech support area. The primary responsibility of the unit is to configure, tune, and support servers. The workflow is controlled by a ticket system, in which the requestor submits an order with basic requirements and most of the work is handled first in, first out. Of course, there are exceptions when there’s extra lead time to order a special server or establish the configuration for a new product, but those orders are the not the rule.

And though different people excel in different areas and each brings unique talents, most server installs in their company require a core set of skills.

Josh, Julie, and their coworkers have a connection. They share professional skills, hold each other in high regard, and let each other know what they are working on. They help each other when asked, but they don’t really collaborate. The workflow in their department isn’t conducive to collaboration, nor does the work require it. They may call themselves a team, but they aren’t engaged in teamwork, and that’s just fine. There’s nothing wrong with being a workgroup if that’s what the work needs.

Cooperation

Deb and Doug report to the same manager and run test labs for two different products. Because their respective products are on different release schedules, there are times when the equipment in each lab isn’t fully booked. They cooperate with each other by loaning resources when it’s possible and makes sense to do so. Deb and Doug are working together to meet organizational goals, but they aren’t a team.

Coordination

Frank and Frannie work in a product development group. Each has responsibility for a distinct product aimed at a different consumer group. They meet on a regular basis to keep each other abreast of release schedules. They consult with each other about market trends as they prioritize features. It is necessary to coordinate, but given the product mix in their company, it’s not necessary for Frank, Frannie, and the rest of the group to collaborate with each other to achieve their goals. No team here.

Conglomeration

Ellen and Eddy work on a large project–over one hundred people. Their manager calls it a project team, but they wouldn’t recognize each other if they passed in the hall. Their project is too big to truly be a team, though there are subgroups within the larger project that function as collaborative teams. Groups larger than twelve or so almost always break down in to subgroups–which may or may not be teams.

Collaboration

Abby, Alec, and their four teammates work on a software development team. They have overlapping skills, all of which are necessary to build the product. They jointly commit to a goal and work very closely to deliver working software in two-week iterations. They also share mutual accountability. If they don’t work together, they won’t succeed. They are a team.

So, as a manager, how do you determine how to organize people to accomplish goals?

    1. Consider the work goals. Are people committing to a leader to achieve individual goals, or are group members mutually committing to each other and sharing accountability?
    2. Examine the skills needed to do the work. Does all of the work require the same (or similar) set of skills, or does the work require a broad range of skills?
    3. Analyze the work. Does it consist mainly of projects that one person can complete from start to end (e.g., individual products)?  Or does the work of several people need to integrate to create a coherent whole (e.g., collective products)?

        If you answered yes to the second question in each pair, the work is probably best suited for a team. On the other hand, there’s nothing wrong with workgroups that aren’t teams. If you answered yes to the first question in each pair, the work is probably best suited for a workgroup. Your management job is to determine which will best meet the needs of the work. Then, create the environment that best suites the needs of the group or team.

        Building a team doesn’t happen by accident, and your job as a manager of a team will be different from the manager of a workgroup.  More on that to come.

        This column originally appeared on stickyminds.com.