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.

Agile coaches are expected to help teams learn agile methods, engineering techniques, and improve the productivity of the teams they work with.  But before they can do they need to be ready to coach.  Being ready to coach means that you have coaching skills, relevant technical and process skills.

But the  foundational skill in coaching is skill in managing yourself.

Your attitude will contribute or detract from your ability to make contact, assess what coaching is needed, and actually help the client.   So,  before you begin, ask yourself a few questions.

Are you aware of your own emotional state? Manage your own emotions before you coach. Coach from a neutral, curious, and encouraging attitude. If you’re feeling angry or impatient, your emotions will leak into the coaching. Anger, frustration, or impatience won’t create a helpful interaction. Look inside to see where your emotions are coming from: Are you expecting an inexperienced person to perform as well as a master? What are your assumptions about what the other person should know or be able to do? Rather than blame the other person, reframe your judgment as “He doesn’t do that as well as I wish he did” or “She doesn’t know as much about this topic as I wish she did.” Shifting your attitude will make you a better coach.

Is coaching the best learning opportunity? When the team struggles and puts the team goal at risk, ask yourself: Where is the biggest opportunity for learning? Will the team learn most from making their own mistakes and learning from the consequences (That’s the beauty of short iterations—if the team misses a goal, the risk is limited by the length of the iteration) or will the team learn most if you coach them in a different direction?

Does the other person want coaching? Coaching always works better when the other person actually wants help. Try to wait for the person or team to come to you for help rather than immediately stepping in the moment you see trouble. Many people learn from solving problems on their own. That doesn’t mean you always have to wait until someone asks you for coaching. Coaching is part of your job, so you can always offer. But remember that it’s an offer—so ask before you inflict help. However, if you see a pattern emerging—a team member repeatedly refuses help when stuck—you have an opportunity to give feedback on how that pattern of behavior affects the team as a whole.

Does the other person want for coaching from you? Sometimes people want help, but they want it from someone else. Don’t take it personally if a team member would prefer to receive help from someone other than you. But again, look for patterns. If a team member is open to coaching from everyone but you, it’s a clue that the relationship may need repair.

Are you clear on the goal? If you aren’t clear on the desired outcome, you risk setting up a frustrating cycle called “bring me a rock.” “Bring me a rock” happens when success criteria are vague (or nonexistent). Here’s how it goes. You say, “Bring me a rock.” The other person goes off and finds a rock, and brings it back to show you. You look at the rock and realize it’s not the rock you had in mind. You hand the rock back and say, “Not that rock.” And the cycle begins again. The result is frustration and de-motivation—guaranteed! Of course, sometimes the goal isn’t known in detail. In that case, make it clear that the goal is to explore options and gain clarity.

Are you open to other approaches? You may have a very clear idea of how to accomplish the work or handle the interaction. But is it the only way? In most situations, there are many reasonable and acceptable paths to success. If you find yourself expecting things to be done a certain way, ask yourself if that way is simply your preference and not the only correct method. Help the person you are coaching think through different options and discuss the pros and cons of each approach. Then let the person choose the one that fits best for him or her. Team members gain capability when they develop based on their own thinking modes, strengths, and talents.

Are you ready to encourage rather than evaluate? Coaching is about helping another person develop skills and capabilities; it’s not a time for evaluation. Evaluation hinders coaching by creating a “one-up, one-down” dynamic. Most people have enough trouble asking for help in our culture without adding this burden. Stay away from comparative words such as good, better, worse, and bad. When you think the other person is headed down a rat hole, ask questions about risks and impacts rather than criticizing. Then help generate new ideas. Offer encouragement to let people know they are moving in the right direction.

When you can answer “Yes” to these questions, you’re ready to make contact.  And then you  can start to coach.

Slides from Team Traps!

Trust is a foundation for effective team work (and effective organizations).

Teams don’t need blindfolded trust walks, ropes courses, or crash courses in sailing to develop trust. Activities like these may indicate absence of pathology. (If you’ve hired people that will let  a blindfolded person walk into a light pole, let them fall down a cliff, stumble into on-coming traffic, or fall onto their heads from a tall platform, you’ve got bigger problems.)

None of these team building/trust building activities have anything to do with the trust that’s needed on a team. Nor do team require the sort of trust that people (often) have with close family members, best friends, and clergy.

Teams need professional trust, trust that exists within the work context and relates to competence, commitment, and communication.

Team members need to trust that their coworkers are  competent related to the content of their work.

They need to trust their coworker’s intentions towards other team members and commitment to  the team (and their work) as a whole.

They need to know that team members won’t withhold important information–whether it’s related to the task or to relationships within the team. They need to trust that when something comes up—either related to a commitment, or an interpersonal interaction—the other team member will communicate directly with the person concerned, rather than taking it to the manager or talking to everyone else about it.

Each individual enters a team with a certain level of trust based on their outlook on life and past experience.  That level is different for every person. From that starting point, each interaction on the team either builds trust or erodes it.

Routines that maintain working relationships build trust.

Direct, congruent feedback builds trust.

Productive conflict builds trust.

Trust is not mystical, and it doesn’t come from a ropes course or a trust walk.  It comes from working together, working through the inevitable frictions, follow-through, and follow-up.

Also see:  Six Ways Team Members Build Trust with Each Other

I’m not talking about information related to the task and context, here, though that can damage a team. Withholding that sort of information is unacceptable, and probably pathological. I’m talking about a different sort of information: information about your internal state .

Let me tell you a story about a team I coached. They’d asked me to observe them solving a problem, help them see their process and offer advice.  Ten minutes into the task things started to go awry.

The team was standing around a  whiteboard, and had generated a list of possible solutions to the problem. They’d started filtering the options, testing them against the requirements of the assignment, adding notes as they went.  As they eliminated options the guy with the marker, Jon, crossed off the options.  Until he got to Harry’s idea.  The board was getting crowded and when Harry’s idea didn’t pass the tests,  Jon erased it.

Harry tilted his chin down.   Then he crossed his arms over his chest, and took two steps back from the group. Everyone else was focused on the white board and didn’t notice as Harry withdrew.

When he didn’t rejoin the group within a few minutes, I approached him, touched his elbow and asked “What’s happening for you?”

“They rejected my idea,” he said. “Wiped it right off the board, like I’m nothing.”

(Notice that he equated rejecting his idea with rejecting him. Easy for us to say that’s not the case; you have to start where people are, not where you think they should be.)

“You have to tell the team,” I said.

He shook his head.  ”No one is even notices that I’m not participating anymore.”

“All the more reason to let them know. They’re engrossed in the task, and they’re missing some important information about what’s happening to the team.”

Harry gave me a blank stare.  “You are withholding information that the team needs to function well,” I explained. “They need to know that one of their members has just checked out.  Will you tell them?”

He nodded, got the attention of the group, said his piece.

He was right, no one had noticed that he’d checked out, and that surprised everyone.  Jon was surprised that his erasure had affected Harry so. But he didn’t try to talk Harry out of his feeling or get defensive.  ”Gosh, Harry, ” he said, “I didn’t mean it that way.”

Harry rejoined the group.

This sort of thing happens all the time.  One member of the team feels like he’s not being heard, or isn’t valued and withdraws. The rest of the group goes on, discusses, makes decisions, starts to act. The team is missing out on the intelligence, creativity and participation of that member.  They won’t  have his buy-in for decisions, and won’t have his full-hearted support for action.  When situations like this aren’t handled, relationship fracture and drains away.  When you’re part of team, you need to be willing to say what’s going on for you, so that the team stays healthy and connected.

I anticipate that at least one reader will judge Harry as thin skinned. Someone will assert that people need to “man up” and stop being so sensitive.

What I’ve noticed is that some people talk that way until they feel rejected ….and they they act pretty much the way Harry did (though sometime less grown up).

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 what, when, and why are clear to everyone involved.”

This article originally appeared in Better Software magazine.

Tom looked up to see Jonathan, who had just transferred onto the team, standing in the doorway to his office. Jonathan looked red and flustered. “What’s up, Jonathan? Looks like you’ve got something on your mind,” Tom said, waving Jonathan in and pulling up a chair for him.

Jonathan slumped into the chair. “You know I’ve been working with Danielle this week?” Jonathan began.

“Yes, how’s that going?” Tom asked.

“Is she showing you the ropes?”

“I can’t work with her anymore!” Jonathan blurted out.

“Whoa,” Tom said. “That sounds pretty final. What brought that on?”

“She’s always eating cookies, and the crumbs get all over the keyboard. On Tuesday she left chocolate fingerprints on the table,” he said. “And yesterday she put greasy marks all over my printout.”

“Have you talked to her about this?”

“Well, no,” Jonathan admitted. “But I wipe up after her, so she should get the hint.”

Tom took a breath. “If you haven’t talked to Danielle, how is she supposed to know you don’t like it when she eats cookies during your working sessions?”

“Anyone with a clue would know how rude it is to drop crumbs in the keyboard. Besides, giving feedback is your job,” Jonathan said.

“Yes, giving feedback is part of my job,” Tom said. “And it’s part of your job, too, when it comes to improving working relationships. You need to work this out with Danielle. I can coach you on what to say, but you have to say it.”

Jonathan crossed his arms and sank down in the chair. “All right. I’ll tell her,” he agreed grudgingly.

Tom and Jonathan discussed the outcome that Jonathan wanted and developed a script so he could practice what to say.

“Ready to go?” Tom asked.

“I guess so. I’ll ask her if we can talk right after lunch. She’s probably out buying cookies right now,” Jonathan replied.

Tom watched Jonathan walk out the door and then sighed. A year ago I would have fallen into the trap and talked to Danielle myself. Then she would have been hurt and angry. And it wouldn’t have helped Jonathan and Danielle work together—it would have made it worse.

Yes, it’s my job to provide feedback, Tom continued to muse. But it’s not my job to play middleman.

Tom had learned the hard way what happens when a manager delivers feedback for someone else. Last year at review time, Tom had asked everyone on his team to provide feedback for every other team member. He provided a form with a series of questions and a rating scale. At the bottom of the form was a space for additional comments. Tom had gathered up the feedback forms and consolidated the responses. I’ll have some solid information to provide people about how their peers view their skills, he’d thought. But the reviews didn’t go as well as Tom had hoped.

Martha had been mystified to learn her teammates rated her communication skills as poor. “What does that mean?” Martha had asked. “What can I change to do better?” Tom had made some general recommendations but couldn’t be specific.

Ted had been thunderstruck when he found out that Jenny had complained about an incident that had happened back in January. “I had no idea Jenny was upset about that. Heck! I hardly remember what happened. I wondered why Jenny had been cool toward me during that project, and this explains it. If she’d talked to me last January, I could have done something differently.”

Fred had summed up his review experience succinctly. “This feels like third grade—when someone’s upset, he goes to the teacher to tattle.”

Rather than improving teamwork, Tom’s experiment in delivering secondhand feedback had bombed. He could feel the trust level drop as co-workers wondered who had said what. Everyone seemed to be waiting for the next knife in the back. Even the team members who had received positive feedback weren’t basking in the glow—”I’d rather someone thank me directly rather than filling in a stupid form,” one person said.

It had taken months to rebuild trust between team members, and Tom had had to eat crow to do it.

After weeks of watching the team pull apart, Tom had called a special meeting. “I made a big mistake,” Tom began. “I thought it would be helpful for the review process to gather your feedback for each other. But I see now that it wasn’t the right thing to do. You guys aren’t talking and joking like you used to. It’s as quiet as a tomb around here. Most of you are barely speaking, and you sound guarded and careful when you do. It feels like my efforts at second-hand feedback, instead of helping, has destroyed trust.”

Tom had paused. “Do I have it about right?” The members of the team murmured their assent.

“OK, I blew it,” Tom said. “What can we do to move past this?”

Finally, Ted spoke up. “I was hurt and angry to hear that Jenny had complained about me.” Ted turned to Jenny. “Jenny, I really wish you had spoken to me directly.”

“I didn’t know what to say to you,” Jenny said looking at her notebook. “But next time you do something that bugs me, I’ll try.”

“Maybe we shouldn’t save up our feedback ‘til the end of the year,” Fred offered.

The team continued to generate ideas on how to rebuild trust. Tom took an action item to arrange for a training session on peer-to-peer feedback.

It took time, but the team started chatting and joking again. And to Tom’s surprise, team members developed stronger relationships as they learned to give one another feedback directly and respectfully.

There were a few occasions when a team member came to Tom for advice on how to broach a sensitive topic. And Tom continued to provide coaching and feedback based on his direct experience. Tom knew that in some rare instances, he’d need to be involved in a peer-to-peer issue—in the case of harassment, ethics, or safety. And it was conceivable that someday he’d have to step in when peer-to-peer feedback didn’t resolve the issue.

Tom snapped out of his reverie. “These aren’t school kids, and I’m not the teacher,” he said to himself. “No more middleman for me.”

This article originally appeared in Better Software magazine.

Some managers seem to know instinctively how to create trust. But I doubt that managers in low trust groups set out to destroy trust. I suspect that they have learned some bad habits and have some assumptions that subtly (or not so subtly) communicate lack of trust.

So, what can you as a manager do to create an environment of trust? The first way to build trust with the people who report to you is to demonstrate that you trust them.

Demonstrating trust includes both the absence and presence of behavior. Here are six actions you can take to build trust:

1. Be transparent

Share relevant information with the group. Let them know what you know about organizational priorities, decisions, and goals. When you make decisions that affect the group, tell them what your thought process was and the factors you considered. If you ask for the group’s input into a decision, and tell them how you will use the information they provide and how that input affected your final decision.

2. Let people know where you stand

Tell your group what a successful performance looks like from your perspective. Also, tell the team how your boss will judge your success. That provides context for your actions and decisions and will help people see how they can help you.

3. Be consistent

You don’t have to treat everyone the same, because people are not the same. But, you do need to treat people equitably and consistently. If your favorite protégé breaks the build and then leaves for a two-hour lunch, treat him the same way you would if he were your least favorite person on the team and did the same thing. (Or better yet, give direct and respectful feedback that doesn’t let people off the hook whether it’s your favorite or not.)

4. Consult with the team before you make commitments on behalf of the team

When your boss asks you to deliver a project by a certain date, don’t automatically agree. Learn as much as you can about the project, and then tell your boss that you need to discuss the new project with your team before you give a definite answer. Promise only what you can—that you will look at the impacts and alternatives with the people who will actually do the work—and report the best options available to your boss.

5. Seek feedback from the group

Somehow, we’ve come to believe that feedback only flows downhill. Vice presidents give feedback to directors, directors give feedback to managers, and so on, all the way down the hierarchy. But managers need feedback from their groups, as well, to understand how they are performing their jobs. I don’t mean once-a-year, sanitized, 360-degree, review-type feedback. I mean direct information from the people who rely on you to create an atmosphere where they can be successful. (For more guidance on how to gather feedback from your group, see A Manager’s Guide to Getting Feedback.) Seeking feedback shows that you value the group’s perceptions and want to provide them what they need to do their jobs.

6. Keep Your Commitments

Just as you expect team members to do what they say they’ll do, they expect you to follow through when you say you’ll take action. Of course, sometimes it’s not possible or feasible to follow through, and reasonable people don’t expect perfection from you (nor should you expect perfection from the people on the teams you support). If you find you cannot follow through on a commitment, tell the team and renegotiate the commitment if appropriate.

7. Clarify Decision Ownership

Clarify which decisions the team owns, which you own as a manager and which decisions are shared between team and manager.  Lay out who will establish boundaries and criteria, who will generate options, who will actually make the choice and who will implement the choice. Too often, this is a murky area for self-organizing teams.  Both manager and team make assumptions about who will be involved and what their involvement will be. When those assumptions don’t match, and the team makes a decision he doesn’t agree with, it’s tempting to step in and countermand the decision.  Unless it’s a huge financial or organizational impact, don’t do it.  Doing so will erode trust.  Take it as an opportunity to explicitly agree on the areas where the team decides, where you decide, and what issues you decide together.

8. Manage Your Desire to Help

Some managers–like some parents–have a tendency to swoop in in a the first sign of trouble and save the little darlings from taking a fall, making a mistake–and from learning.  If you really want a team to mature and increase in capability, don’t inflict help.  Let the team figure out how to solve problems together.  The more you step in, the more the team will look to you for answers and guidance.  On the other hand, don’t let the team flounder.  You can always offer help and information–withholding a piece of information that would help the team solve a problem is just plain bad.

***

I’m going to assume that you never engage in abusive behavior, insults, intimidation, or physical threats, all of which torpedo trust and create fear, and should never be tolerated in the workplace. But, there are some widespread management behaviors that are counterproductive and destroy trust. Below are three actions you’ll want to avoid:

1. Withhold feedback

If you observe behavior or results that are not what you expect, tell the person immediately, or this very week. Do not wait until the annual performance review cycle. Do not wait until you get around to it. Withholding feedback communicates that you are more interested in judging a person than in helping him or her succeed.

2. Dismiss evidence of the team’s capacity

I hope you are using some reliable way to assess the capacity of the group. I personally like velocity, a measure of how many points (an estimate of size and complexity for a piece of functionality) a group can complete in a given time box. Suppose the team is consistently completing ten to twelve points in a two-week iteration, There are six weeks until release date and the customer (or your boss) wants 300 points of functionality out the door in that release. One manager I met was in this situation. Rather than go to the customer and discuss what they could do to change the release date or release fewer features, he exhorted his team “You’ve got to try!” Well, they were trying, and the manager’s response made him look like an idiot. The group didn’t trust him to stand up for them or to create a situation where they could succeed. They felt set up and abused. No trust there.

3. Micromanage

There are two aspects of micromanagement, both of which you should avoid. The first on is specifying exactly how something should be done when there’s more than one way to do it. That communicates that you don’t trust people’s competence or judgment to find a reasonable approach on their own. The second aspect of micromanagement is incessant inquiry into status. I had a manager (briefly) who stopped by each desk several times a day to ask, “Are you done yet? What are you working on now? Do you need more work?” Clearly, he didn’t believe that we’d actually work without his constant urging. He thought we’d slack off if he didn’t ride us. In short, he communicated he didn’t trust us. Of course, you do need to know what the status of work is—but there are better ways of obtaining that information than hounding and harassing people.

Obviously, there’s more to creating the bonds of mutual respect and trust than I can cover in one, short column. However, if you consistently practice these six actions and avoid the three, you will be well on your way to creating a trusting atmosphere. When trust is present, you will have a conduit for accurate information because people won’t be afraid to tell you what’s really going on. When trust is present, people will be more creative because they won’t be afraid to take reasonable risks and try novel solutions. When trust is present, the people in your group will work hard for you because they know you are working hard for them.

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

I’m a big believer in 1:1 meetings on manager-led teams. It’s a way to connect with people, stay in touch with progress, learn about problems early, coach, work on career goals, offer feedback.

But if you are the manager for a self-organizing team, you need to adjust the way you do 1:1 meetings.

First, unless you are coaching someone on task accomplishment, do not ask about progress and status of tasks. On self-organizing teams, team members organize the work and make commitments to each other. If you as a manager insert yourself into this, you are communicating the the commitment is still to you, not to other team members. If you want to know about task progress, walk into the team room and look at the task wall or burn down chart.

You will probably have less visibility into the day-to-day workings of the team and team members. That means you are less likely to have useful feedback to offer on a regular basis. Ideally, much of the feedback on a team should be peer-to-peer. You need to get involved when the team has tried (using effective feedback techniques, not hints, not vague general statements), there hasn’t been a change, and the behavior is impeding the team. Getting in the middle of a feedback between team members when you don’t need to only creates problems and erodes trust on the team. When someone comes to you hoping you’ll carry a message for them, coach them on how to offer effective feedback, so the situation gets handled where it lives, between the team members.

Don’t meet every week, unless you are coaching on a specific issue (that you are qualified to coach on), or unless there’s a “get well plan” that you need to manage. You do need to stay connected to people; there are lots of informal ways to do this with out meeting every week. Meeting every week sends the message that you still want people to look to you for answers, help, and guidance. You may want that, but consider the effect on the team and their growth and capability.

You may still have a role in approving vacation (work on changing that, since it implies that the company doesn’t trust people very much). Keep that to a formal sign-off role. The first negotiation needs to be with in the team. I talked to a manager who approved a vacation request right after a team had committed to work for an iteration. (Who knows why the person didn’t mention it to the team, but he didn’t. That’s a separate problem.) The manager approved the vacation, then asked the team to cover the guy’s commitments while he was sunning himself on the beach. The team rightly refused, and insisted on renegotiated with the product manager to reflect the fact that they weren’t going to be able to accomplish as much with one team member gone for the entire iteration. The manager realized much later that he’d set the team back in mutual trust and accountability by not sending the guy back to work it out with the team.

Work on professional development, but remember that the team member you are mentoring needs to negotiate tasks and roles with the team. For example, if someone wants to learn more about project management, you don’t get to say “start managing the iteration as a project.” That breaks down the work the team has done to organize their work and erodes shared commitment.

Ask about impediments and blocks outside the team, those that need management action to fix. You can’t fix everything, but you can investigate, look for patterns of blocks mentioned by multiple team members. You can create an impediment backlog and post your burndown to the team.

Ask about HR concerns. For many agile teams, traditional job descriptions, career paths, and other personnel systems don’t fit agile work very well, so you want to know when there’s dissatisfaction and understand when and how policies are getting in the way of teamwork and team work.

Your job with a self-organizing team is to establish conditions for success, make sure the team has appropriate resources and appropriate boundaries, to remove impediments and improve the work system. It’s not to give task direction and hold individuals to account (except as noted above) . The team is responsible for organizing their work, tracking progress, and communicating to you when there’s a problem. You job is not to inflict help–that keeps the team from learning, and keeps them dependent on their manager.

Hierarchy acts as an amplifier, and manager’s actions are always under scrutiny. If you want the team to self-organize and reach their potential, don’t send them a confusing message that they still need to turn to you for day-to-day task guidance, status reporting, and problem-solving.

Building trust may seem mysterious—something that just happens or grows through some unknowable process. The good news is there are concrete actions that tend to build trust (and concrete actions that are almost guaranteed to break down trust).

First, let’s agree on a definition of trust in the workplace. We all know that trust is the foundation for teamwork. But to hear some people talk about it, you’d think team members were getting married, not creating software together. What we need in the workplace is professional trust. Professional trust says, “I trust that you are competent to do the work, that you’ll share relevant information, and that you have good intentions towards the team.” Taken broadly, that’s trust about communication, commitment, and competence.

0. Trust Other People

The zeroth step in building trust is to display trust. One way to do that is to make a generous interpretation when someone else makes a mistake or disappoints you in some way. People who always jump to the worst conclusion about others’ competence and motivation inspire wariness, not trust.

Most people don’t set out to be evil or stupid, so give the benefit of the doubt until you have data that proves you wrong.

1. Address Issues Directly

Ruffled feathers come along with close collaboration; it’s bound to happen that one person will rub another the wrong way. Maybe it’s the way your cube mate chews his gum or listens to voice mail on speaker phone. Maybe someone used your laptop and changed all the preferences or broke the build and then left for lunch.

When someone on the team is bugging you, speaking directly to that person builds trust. It says, “I value our working relationship, and I’m willing to have an uncomfortable conversation to make it better.” It says, “You’ll know where you stand with me; I won’t be talking behind your back.”

These conversations aren’t always easy, but the alternatives are worse.

Some people avoid the uncomfortable discussion and let their anger and resentment build until it explodes. That almost always leads to damage that’s more difficult to repair than the original irritation.

Another way people avoid the conversation is to tell their managers about the problem. If you really want to damage trust with coworkers, play tattle tale and complain to the boss. (As with everything, there are exceptions. If the situation involves sexual harassment, an ethical breach, or physical safety, tell your boss).

When people don’t know how to have difficult conversations or think it is someone else’s job to navigate working relationships, trust erodes. And that’s why people need a framework to talk about interpersonal feedback.

2. Share Relevant Information

Knowledge is power, but it’s more powerful when it’s shared. When someone on the team withholds an opinion or concern on a topic and comes back later to say, “I thought it was a bad idea from the start,” other team members feel blindsided. That breaks trust. If you don’t support an idea or approach, say so. (Of course, there are more effective and less effective ways to do this.)

Relevant information is about the task, but it’s also about you. People tend to trust people they know as individuals and can identify with. Shared experience, shared interests, and identification form solid ground that people can land on when there is friction and conflict. You don’t have to share your deepest secrets, but letting other people on the team know something about life outside work makes people “real.” It’s hard to trust a cipher but much easier to trust and be generous with someone who shares some of the same challenges and interests that you do.

3. Follow Through on Commitments, or Give Early Notice When You Can’t

In order for teams to function, team members need to believe that their coworkers are reliable. Without the confidence that others are reliable and will carry their share of the load, few will commit to a shared goal.

No reasonable person expects that every person can meet every commitment all the time. Sometimes a piece of code turns out to be more complex than anticipated, or we discover we didn’t fully understand the task when we made our estimate. But when you wait until the moment the task was due to let people know it’s going to be late, you appear unreliable. So let people know as soon as you know, and renegotiate.

4. Say No When You Mean No

Sometimes you just can’t take on another task or do a favor that someone asks for. Most of us are programmed from an early age to please other people, so we’re afraid of being labeled selfish or “not a team player” if we say no. But if you really can’t do what’s asked, it’s more respectful to say no and let the other person have his need met elsewhere.

Saying yes without follow through leads others to doubt your word. If you can’t say no, your yes won’t mean anything.

5. Share What You Know and What You Don’t Know

Be generous in sharing your knowledge (without inflicting help). But also be willing to hear other people’s ideas, build on them, and help others shine. Admit when you don’t know the answers. There’s nothing worse than a know-it-all who is wrong.

It may seem paradoxical, but building competence trust—i.e., your coworkers’ trust in your capabilities—sometimes means admitting that you don’t have all the answers. Asking for help helps others see you as a real person, and people generally like to be helpful.

Most people enter a new situation with a basic level of trust. That level may be high or low, depending on their outlooks and life experiences. But from there, every interaction is an opportunity to increase or decrease trust. With the techniques I’ve listed above, you are now armed with several ways to build a strong foundation of trust for your team.

This article originally appeared on stickyminds.com in 2009