Tag Archives: collaboration

/Estimating/ is often helpful. /Estimates/ are often not.

Recently, I tweeted, “/Estimating/ is often helpful. /Estimates/ are often not.”

Several people asked, “How can this be?” Let me say more, in more than 140 characters.

/Estimating/ is often helpful.

Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work..

Collaborative estimating gives the best results. Diverse experience yields a broader range of perspectives and questions.  Questions and perspectives build understanding of the what, why, and who related to the request. That’s helpful.

Group estimating reveals differences in knowledge and understanding. Finding those gaps early is helpful.

Group estimating surfaces assumptions. When we are aware of our assumptions, we can verify–or debunk– them.

When the group knows enough about the “what” to think about the “how,” they can analyze implementation.  Working out implementation details reveals more assumptions, and generates more questions.

Sometimes estimating reveals you only know enough to reason by analogy. The best you can do is posit that the desired functionality is about the same size as X.

But sometimes, estimators realize that they don’t know enough to think about size or effort in any meaningful way.

This situation calls for discipline. Discipline to resist guessing and speculation. Estimates born of ungrounded guesses are worse than useless. Rather than guess, experiment, interview, model, sketch designs or do some activity to gain more clarity about needs and context. Then try estimating again.

/Estimates/ are often not helpful.

People turn estimates into targets. Meeting the target becomes the de facto goal and the de facto method.  Meeting needs fades in priority.

People construe estimates  as promises. No one can predict the future, but many people treat estimates as guarantees. Failed predictions fan blame. Trust and openness suffer.

People construe estimates as bids. Bidding usually involves some calculation of profit. That implies a margin. However, managers discourage margins in estimates. Managers view “padding” as a moral failing–but it’s really a contingency for the unknown (or compensation for bosses who are known to cut estimates to fit wishes. See below).

Inappropriate precision in estimates implies that people know more than they do.  When expectations and reality meet, people may feel disappointed. More likely, they feel  deceived. Trust and openness suffer.

People game estimates. How many of you developers out there have thought long and hard about an estimate, only to have a managers say, “That estimate X is too high. The estimate should be X – Y.”  Me, too. Fudging estimates to fit wishes sets off another round of deceit and disappointed expectations. Trust and openness suffer.

So please, estimate. But don’t get caught up in estimates.

Peck, peck, peck

A participant in one of my workshops of my workshops declared that in every team there is pecking order….and every one knows what the order is from one to n.  Since this is the case, he reasoned, it follows that ranking people in organizations is a reasonable management practice.

This is not the first time I have heard this assertion.

It often comes up when I talk about performance reviews, annual evaluations, and the harm done by stack ranking.

This assertion rests on tired analogies from sports or the animal kingdom.

I’m not buying it.

Software development teams are not “just like” sports teams. Software development teams aren’t packs, pods, herds, clowders, flocks or clutches.  Groups of people developing software are people in goal oriented social units–often in teams.

Sometimes, on some teams, it appears that there is one person who is obviously the star. Maybe.

In some companies, smart talk substitutes for action. So is the smartest talker the best on a team?

Some times there is a self-proclaimed genius who writes code that is so brilliantly complex that other people struggle to understand it. How does that make him the star? He is making it harder for everyone else to do work.

Then there are the people whose manager declare are top performers (though the basis of their assessment isn’t clear)–even though colleagues and peers  view them no more than average,  brown-nosers or a hindrance.

I observed a team where one person was viewed as the star by many managers.  To those managers, Joan (not her real name) looked like the one who generated ideas and figured out problems. From inside the team, Joan, suppressed contributions from other people through aggressive interruption, belittling others’ ideas, and arguing  until people caved in because it wasn’t worth the fight.

Rarely, there are people who are real standouts.  But not on every team.

What about the people at the bottom? What is the basis of the assessment?  Does the assessment include all of the dimensions of performance? In most cases it does not– it might include one dimension, perhaps coding. But in collaborative work, that is not the only thing that matters. Some times a person with relatively weaker coding skills contributes in other important ways. He or she may excel at  synthesizing information, seeing the software from a customer’s perspective, creating an environment where every one on the team can be more effective.

And the people in the middle? People who ascribe to the pecking order view believe that all of the members of a team could be lined up in rank order. But what is the earthly good of that? What is the basis of the comparison? Does it included the breadth of contribution or just one aspect of performance?

What if people are measurably different on some dimension?  Software is a collaborative endeavor. What matters is how well the team is doing.  Spending time teasing out relative contribution or trying to discern the pecking order does not aid in team performance, and can cause real harm.

As a manager, don’t waste your time trying to figure out the pecking order.  Do everything you can to help the team, as a goal oriented social unit, perform to its full capability.  Treat the true stand outs as exceptions. Promote them, or find other ways to reward them (don’t limit your thinking about rewards to money).  Treat the people whose performance is obviously below par as exceptions, too.  Either get them them help so they can contribute, or get them to a place where they can contribute (which may not be your company).  It is extremely difficult to assess relative contribution to collaborative work. The effort is not worth the benefit, and the downsides are significant. So skip it. And get on with helping the 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.

There’s I(ntelligence)Q, and then there’s I(nfluence)Q

People who work in software are smart people who take pride in their abilities to understand complex information and solve difficult problems. But much of the work isn’t only about smarts. Creating most software requires the help and cooperation of other people. Telling, convincing, and winning arguments won’t work to bring people along, change their minds, or help them help you. That requires influence.

To some of people, influence is a dirty word. The word may bring up images of sleazy organizational politics or strong-arm tactics along the lines of “I made him an offer he couldn’t refuse.”

But influence doesn’t have to be slimy or manipulative. Simply put, influences is the capability to affect the opinions and actions of others. You don’t have to be in charge to have influence; the elements of influence are available no matter what your role.

Let’s eavesdrop on two conversations to see what we can learn about influence.

The Alpha team is working towards their next release. One of the major goals is to make it easier for customers to migrate their existing data when they install a new version of the software.

Brandon knows there are two stories in the backlog that will require table updates: one story is scheduled for this release and one for the next. He has figured out how to design the table to accommodate both requirements with one table change, which means customers will need to do only one database conversion, instead of two. Plus, they can roll out the improvement with this release rather than the following one.

Brandon wants to convince Cindy–who is working on the story that’s part of the current release– that his idea is the right approach. Brandon stops by her desk to chat about his idea.

We’ll pick up the conversation after Brandon’s sketched out his candidate design.

Cindy: You can’t do the tables that way, Brandon.

Brandon: Let me tell you why I this this will work, and be easier for the customer…

Cindy (cutting Brandon off): We’ll have to write lots more code with this table setup. Did you think of that?

Brandon: It might take another access call, Cindy, but it makes it much easier for the customer to install the new release.

Cindy: We’re going to have to write ten percent more code, at least. And then we’ll have to test it all. It’s a bad idea.

Brandon: I don’t agree, Cindy. It’s not going to take that much more code. And there are several advantages to this approach.

Cindy: Do you really want us to blow our iteration goal? Is that what you want?

Brandon (trailing off): No, of course, I don’t want us to miss our commitments…

Brandon felt like he was being backed into a corner and it felt like Cindy was picking a fight.

After a couple more brow beatings from Cindy, Brandon gave up.  Arguing with Cindy wasn’t worth it.

Cindy, however, felt a little rush of pride. She believed that her powers of argument had moved Brandon to see things her way.

Cindy is exhibiting one sort of influence, perhaps a sort that gives influence a bad name: browbeating and emotional manipulation.

Brandon is missing the influence boat, too. He didn’t ask Cindy what she needed or what her concerns were to see if they had some common ground.

Brandon made two other mistakes:

  • He responded to Cindy’s objection by explaining his position rather than exploring her objection.
  • He responded to her second objection by arguing the facts.

In another part of the country, Jason and Tom are working on a virtually identical project:

Jason: Tom, the customers are really screaming about having to convert their databases with every release. I think I’ve found a way to eliminate a conversion for the next release–three months earlier we thought we could. I think they’ll love it. Is this a good time to walk through my idea?

Tom: Sure, show me what you’ve got.

Jason walked through his approach.

Tom: Well, the way you have it set up, we’ll have to write another call every time we access this table.

Jason: Ah. That’s true. When I was fleshing this out, I saw there would be an extra call. Can you tell me more about the impact you think that will have?

Tom: Well, I’m worried about writing and testing those calls.

Jason: Can you tell me more about that? You’re not concerned about performance?

Tom: Performance shouldn’t be a problem (but we’d need to test that). I’m worried about Teddy. Teddy is sweating the release plan. He just added a a big new feature, and he’s worried about upholding his commitments to one of our key customers.

Jason: Oh, so your concern is about what we can fit into the release.

Tom: Yep, I don’t see what we can take off the plate to fit this onto the plate.

Jason: I see. Well, what if we talk to Teddy about the tradeoffs and see if we can shift something around to make this work?

Tom: Okay. Let’s to talk to Teddy. And let’s talk to the rest of the team. They may see something we’re missing.

Maybe Cindy would need Prozac to be this mellow. But most people will hear more and be willing to cooperate when they feel like you have heard their concerns and understand that your goals intersect with their goals.

Here’s what Jason did:

  1. When Jason approached Tom, he checked to make sure it was a good time to walk through the design before he started.
  2. Jason stated his goal explicitly, and tied it to something they both cared about, customer satisfaction.
  3. When Jason heard Tom’s objections, he asked for more information rather than starting to explain his position.
  4. He acknowledged Tom’s concern, and obtained Tom’s agreement that he’d heard the concern correctly.
  5. He showed his willingness to help Tom overcome that concern by talking to the Teddy, the product owner.

in short, he connected, listened, learned, and found a potential ally.  That’s high IQ.

As Goes the Contracting, So Goes the Contract

A while back, a colleague, Susan, called to ask me for some advice.

“I’ve been planning a vacation with my family for months,” she said. “And now my new client wants me on-site next week. I’d be happy to come the week after next, but they keep pushing. I told them I couldn’t come because I had family plans.”

“Have you been able to schedule the visit for a time that works for both of you?” I asked.

“No, not yet. The next day, my client called me back and said they really needed me, and to make it easy for me, they’ll put me and my family up at a five star hotel for the week and through the weekend. They’ll provide a nanny, a car and driver, and obtain VIP passes at the local theme park and children’s theatre.”

“Are you going to do it?” I asked..

“It’s tempting,” she said. “They say they really need me, and my kids would probably love it. But something doesn’t feel right.”

I had to agree.

Susan is at a turning point with her client: the way this initial exchange about scheduling her site visit unfolds will color the rest of their working relationship.

All of us establish working relationships, whether we are employees or external consultants like Susan. We make agreements with others about what’s expected and how we’ll work together. Sometimes our agreements are explicit, as in creating a project charter, setting a sprint goal, or establishing the boundaries of a new assignment. Other times the agreements are less explicit—the agreement comes about without conscious attention.

Pay attention to what happens in the early stages, when you’re working out how you’ll work together. The early stages often foreshadow the entire working relationship.

Susan’s client was establishing that he expects people to switch priorities at short notice and sacrifice personal balance to support his sense of urgency. If Susan acquiesced to this request, her client would have her asking “How high?” each time he said “Jump.”

After we analyzed the situation, Susan decided to stand firm. She called her client and thanked them for their generous offer, and said it didn’t fit for her to upend her family vacation. She reaffirmed that she’d be happy to be on-site with them the week after her vacation.

Susan’s client was surprised that anyone would act this way, but accepted her schedule.

After her week at the client site, Susan called me back. “You know how my client wanted me to drop everything, change my plans, and react to their sense of urgency? It wasn’t really urgent. And they treat almost everyone that way.”

“Yep,” I said. “Everyone but you.”

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.

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.

        Collaboration: more than facilitated meetings

        I’ve noticed something lately: when people write about collaboration, they discuss facilitated meetings or affinity grouping stickynotes. Well-run meetings that encourage participation and building consensus are certainly valuable. Grouping stickynotes can help people see common ideas. Yet, there’s  much more to collaboration than meetings and affinity grouping.

        True collaborative assumes shared responsibility, shared ownership, and boosts creativity and learning.

        Shared Responsibility

        Collaborative teams focus on meeting a shared goal. Everyone’s skills and contributions are needed to reach that goal. In the end, they’ll either succeed or fail together. No one can say, “I got my tasks done. It’s your fault we didn’t meet our goal.”

        Shared Ownership

        A colleague told me a story about a co-worker, Bob, who was very protective of his code. If anyone else attempted to refactor or add to Bob’s code, he’d pitch a fit and remove all the changes. The result was that Bob was the only one who really knew the details of that module, and all features and fixes had to funnel through Bob. That may mean job security for Bob, but it’s risky for the business.

        With a team goal, there’s no room for “my code” or “my tests.” The team shares ownership for its products. Individuals still may know a part of the system in more depth than others, but everyone has an understanding of the overall system, and that keeps the “truck-factor” risk low.

        Cross-functional Learning

        Shared goals, shared responsibility, and shared ownership drive cross-functional learning. Josh, a tester, applies the Java scripting skills he uses for test automation to write code for the GUI to help the team meet its goals. When the team members are worried about meeting their goals for test coverage, everyone pitches in to write automated unit tests. Team members learn from each other and expand their skills outside of their functional silos.

        Process and Organizational Learning

        When teams hold retrospectives, they share their perceptions about technical practices, work processes, and teamwork. Team members learn about the specific topic they are discussing and also about process analysis, process improvement, and influencing change.

        Deciding Together

        In business, we search for the “right” decision and often rely on experts to reach decisions for the rest of the group. While that’s the right approach some of the time, other times it’s more important to have decisions that the entire group will support and move forward. It’s a matter of looking for a good decision that the team will support rather than the “right” decision that doesn’t go anywhere.

        Thinking and Solving Problems

        Most people in the software field are really good at thinking and figuring out problems alone. Collaborative teams make use of each member’s insights and ideas to generate multiple solutions and then pick from the best. Looking at problems from different perspectives drives creative solutions. When I listen to teams that are starting to solve problems collaboratively, I hear comments such as “I never would have thought of that” and “Your comment sparked another idea.”

        Creating Together

        As with solving problems, many heads are often better than one when creating. Different people see different visions of what’s possible. Team members build on others’ ideas and challenge each other to fill gaps and weaknesses in solution candidates.

        If better results, lowered risk, and increased learning aren’t enough, collaboration is also more fun.

        I recently spoke to a domain expert, Sally, who was working with a software team to define features for the company’s main product. “After finishing customer research, I used to work on my own to create the perfect feature description,” she said. “Inevitably, I’d miss something or write an ambiguous description. Sometimes, I’d find out later that what I described was technically possible, but expensive. Those discussions always led to finger pointing. Now that the team and I are working on the features together, we catch those things early. They have good ideas that I wouldn’t have thought of, and we’re having fun.”

        When teams collaborate, there’s less pressure on each individual to create the perfect part. Everyone realizes that she has the help and support of the rest of the team, and together they’ll create something far better than each could do on her own.

        Collaboration Gone Bad

        In spite of all these benefits, some people shy away from collaboration. Collaboration isn’t for everyone. Some people prefer to work alone and do their best work solo. Trying to force collaboration on people who aren’t interested is an exercise in futility (and not very collaborative). Some might have had a bad experience and are wary of trying collaboration again.

        Just as collaboration isn’t a good fit for every person, collaboration isn’t a fit for all work. A work group responsible for installing and configuring servers was urged to work as a team and “be collaborative.” The group’s work was queued by tickets that specified the setup for each server. Each setup was a one-person job. While there were occasions when it made sense for people in the group to work together, most of the time there wasn’t a shared goal that required the effort of more than one person. Their manager decried the lack of collaboration—not seeing that the work didn’t require it—and the group members felt their boss was unfairly berating them.

        A weak goal can undermine collaboration and lead to churn. One company convened a cross-functional team to “redesign the organization.” Each team member had a different idea of the scope and authority of the group. After several weeks of argument and aimless conversation, group members quietly drifted off to more focused and satisfying work. They never reached the point of collaborating because they didn’t have a shared idea of where they were going.

        A team needs the right mix of skills to collaborate, too. If the group lacks key skills, they won’t be able to get the work done, no matter how well they get along and how creative and cooperative they are.

        I’ve also seen collaborative teams struggle when one person didn’t follow through on commitments or persisted in working as a lone wolf. Teams that have the skills to do so may hold the person to account or coach her off the team. However, if the team isn’t ready to manage its membership and the coach or manager doesn’t step in, that could spell failure for the team.

        Also, when the team members have a shared goal but are rewarded and rated as individuals, people have less incentive to cooperate. Depending on how people are rewarded in the company, they may be incented to compete with each other or even undercut each other. Some collaborative teams survive in organizations that stack rank and otherwise foster competition; these teams need some other motivator to overcome the factors that demotivate collaboration.

        And collaboration requires specific skills—skills that we don’t normally learn in school. Dealing with conflict constructively, giving peer-to-peer feedback, and reaching sustainable agreements are all developmental areas for collaborative teams.

        By all means, work to make meetings more effective by using participation and facilitation. But don’t forget the other parts of collaboration: shared responsibility and ownership, learning, creating, thinking, and deciding. When we hone our collaboration skills, all of us are smarter together than any of us is alone.

        An earlier version of this article appeared on stickyminds.com in 2007.

        Hiring for a Collaborative Team

        If you’re a hiring manager, you know that a typical hiring process emphasizes technical skills, functional skills, and industry knowledge. Interpersonal skills are near the bottom of the list, if they make the list at all. However, if you’re hiring for an agile team, or any other team that must collaborate to succeed, put interpersonal skills near the top of the list.
        Of course, that doesn’t mean you should ignore technical and functional skills or take a nice person you meet in the street and train them from the ground up. Look for a near fit on technical skills–you can train on that. Focus your attention on skills and characteristics that are a prerequisite for collaborative working relationships. A desire and ability to work collaboratively, self-management and a proven ability to navigate conflict, and self-awareness are key traits to look for. It’s not that people can’t learn interpersonal skills, but these skills are much harder to impart and often require a degree of intrapersonal change, and not everyone is willing to do that for a job.

        Screen Out the Lone Wolves

        Self-organizing cross-functional teams, shared code ownership, and team goals aren’t for everyone. It may seem obvious, but this is an oft-overlooked fundamental. People who crave star status and individual achievement aren’t bad people; they are a poor fit for a self-organizing team. Even when the candidate has fabulous technical skills and experience, move on. The lone wolf won’t be happy on a highly interdependent team, and you won’t be happy about your hiring decision either.

        Weed Out the Not-So-Nice

        This is a simple test that will quickly eliminate the not-so-nice. Have the unit admin make the initial screening call to verify employment dates, contact information, and other basics. Pay close attention to how the candidate responds. Is the candidate polite? If a candidate can’t be pleasant to the admin, it’s likely they won’t be pleasant to others either.
        This little test may seem simple-minded; and while it is simple, it gives an indication about self-management and empathy. Watch mainly for big red flags: A person who isn’t willing to be pleasant may not like working with people enough to function effectively (and happily) in a highly interdependent, collaborative environment.

        Involve the Team in the Hiring Process

        I like team-based hiring in general, and for an agile team it’s essential. Having the manager make a hiring decision in isolation belies the very nature of self-organizing teams.
        There are lots of ways to do team-based hiring, and some to avoid. Skip panel interviews where the candidate is interviewed by several people at the same time. Panel interviews save time for the staff, but can be intimidating for the candidate. Rather, have a subset of the team spend 45-50 minutes one-on-one with the candidate.
        Draw up the question list in advance, and then divide the questions between the interviewers–and don’t make the candidate answer the same questions several times! If you’re interviewing more than one candidate, make sure to ask every candidate the same set of questions. You can add additional questions to follow interesting threads, but be sure you have a common set of questions for all candidates so you can compare them apples-to-apples.

        Use Past Performance as an Indicator of Future Performance

        Behavioral or experience-based questions are open-ended questions that ask the candidate to describe how he or she has responded and acted in the past. Explore with a combination of requests for scenarios and questions:

        • Tell me about a situation where you disagreed with a co-worker.
        • How did you handle the disagreement?
        • How long did you wait to broach the topic?
        • Tell me about three approaches you use to deal with conflict at work.

        Look for candidates who can disagree–a certain level of conflict is healthy–without being disagreeable. What you don’t want is a team where people disagree all the time and can’t work together. Use behavioral questions to explore flexibility, ability to resolve conflict, helpfulness, and comfort with having work open to team review.

        Watch the Candidate in Action

        Auditions are a great way to see how a person works. If your team is pair programming, ask the candidate to sign a non-disclosure agreement, and then have her pair program briefly with several team members. How does she respond? Keep in mind that this is a very stressful position for many people–looking for a job is stressful enough, and you’re also asking her to jump into unfamiliar code. How does she handle that? Is she okay with being a learner? Is she comfortable offering feedback or expertise?
        When you’re serious about a candidate, consider inviting the candidate to have lunch with the entire team. A group lunch serves two purposes. It allows team members who weren’t directly involved in the interviews a chance to interact with the candidate. Don’t be too worried if the candidate doesn’t act like a social butterfly. But do watch to see if he talks to the people on either side of him and shows interest in the conversation.

        Make the Hiring Decision as a Team

        After the interviews, auditions, and other data gathering, assemble the interview team to share their findings. I like to use a “thumb vote” to test the level of agreement on candidates. Thumb up indicates support for the candidate, thumb sideways means “I’ll go along with the group,” and thumb down means “I object and wish to speak.”
        If everyone is thumb up or thumb down, the decision is easy. If a majority of the group is thumb sideways, keep looking. This should tell you that if everyone is just lukewarm about the candidate, he probably won’t be a good fit.
        Override the team’s assessment at your peril!

        Use Psychometric Tests Responsibly

        One manager whose company had adopted Extreme Programming (XP) stated that his company was now hiring for a particular Myers Briggs Type Indicator (MBTI). I predict that this company will have problems!
        Healthy teams have diversity of thought processes, preferences, and psychological traits. A team of people who all think alike or like to do things the same way will run into trouble. Remember that people of all temperaments can be successful. It’s not appropriate to select or exclude candidates based on MBTI type.
        Psychometric tests can be a useful piece of the puzzle. But basing a hiring decision on a psychological profile or even using it as the determining factor is not only inappropriate, it’s illegal.

        Be Prepared to Answer Candidate Concerns

        Be prepared to answer questions about career path and development. Self-organizing teams blur the lines between job functions and flatten job grades. Most companies have some form of job descriptions including job levels, career paths, and salary grades. This is what most candidates are accustomed to, and they may have questions on how this will work on a cross-functional team.
        I recommend having as few salary bands as feasible on a cross-functional team, and standardizing compensation for each band.

        Putting It All Together

        Hiring for a cross-functional, collaborative team requires a different emphasis from traditional hiring practices. In many cases, languages, tools, and functional skills are much easier to train in than interpersonal skills. Shift your focus to finding people who are able and eager to work in a cross-functional, collaborative environment and be willing to accept a near fit on technology and functional skills. Follow these steps and you’ll increase your probability of building an extremely productive collaborative team.