Category Archives: Trust

trust in the workplace

Rethinking Manager’s Relationship with Agile Teams

This article originally appeared on 

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

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

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

Messing with Team Membership

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

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

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

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

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

Delegating then De-delegating Decisions

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

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

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

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

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

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

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

Clouding Team Commitments

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

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

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

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

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

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

Bridging Structural Conflict: Same and Different

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Consider these questions to help the group process the list:

Which differences can be negotiated or changed?

Which ones are most significant?

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

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

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

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

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

This article originally appeared in Better Software Magazine.

Peer-to-Peer Feedback

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

The same think can happen with feedback.

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

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

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

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

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

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

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


“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

A Tale of a Too-Hands-Off Manager

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

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

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

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

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

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

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

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

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

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

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

“The reset feature,” Tad replied.

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

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

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

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

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

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

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

And that was that.

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

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

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

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

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

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

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

  • What are the consequences of failure?

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

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

Tale of a Yo-Yo Manager

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

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

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

Sue nodded.

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

Sue raised an eyebrow.

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

Sue’s other eyebrow went up.

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

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

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

Sue held up her hand to stop him.

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

Bob looked puzzled. “What do you mean?”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bob gave Sue a pained look.

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

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

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

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

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

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

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

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

This article originally appeared in Better Software magazine.

No More Middleman: Avoid triangulated feedback

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.

For Managers: 8 Ways to Build Trust, 3 to Break It

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 in 2009.

Six Ways that Team Members Build Trust with Each Other

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 in 2009