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.

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

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

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

Connection

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

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

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

Cooperation

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

Coordination

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

Conglomeration

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

Collaboration

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

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

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

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

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

This column originally appeared on stickyminds.com.

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.

I recently read some advice suggesting that when we’re stressed or feeling non-positive emotions because of situations out side work—the illness of a spouse or child, a divorce, or other personal problem–employees should hide their emotions and pretend to be eager and positive.

I can’t endorse that advice.

Let me tell you a little story that shows why.

The other day I had conference call scheduled with a colleague, Alysa. We’d emailed back-and-forth before hand, so we had a rough agenda going into the meeting. It only took a minute to list the 3-4 topics.

“Where should we start?” I asked.

“Let’s start with the conference session. No, I mean the consulting proposal. Did you send me email about this?” Alysa said.

“Yep, last Tuesday,” I said.

“Oh, I guess I lost it. Sorry, I’m sort of spacey today.”

“That’s OK,” I said. “I have it right here,” and started listing the open items.

“Did I tell you my husband’s been laid off?” Alysa blurted.

“No….sounds like we should talk about that first,” I said. “Tell me what happened.”

Alysa told me the about the layoff, how she was trying to give her husband, Harvey, support, and what Harvey was doing to find a new job. She was feeling anxious, worried, and angry. Mostly I listened and offered a few words of commiseration.

After about five minutes, Alysa had finished her story.

“Ok, I can concentrate on our agenda now,” Alysa said.

We continued our meeting, accomplished what we set out to, and ended the meeting on time.

Here’s the paradox: If I had tried to force Alysa to stick to the agenda from the start, and told her that Harvey’s layoff was off-topic, we would not have gotten our work done. Alysa wouldn’t have been fully present or focused. By taking a few minutes to acknowledge what was happening, we were able to move on to productive work.

We all deal with the potential for people to be emotionally pre-occupied at work everyday. It may be an argument with a spouse or a sick child. Perhaps the school has called to report that Junior is up for detention. All sorts of events outside of work come with us when we enter the office door. Work events can cause emotional responses, too. Mergers, re-orgs, new bosses, downsizing, and even mundane events can create emotional situations. We don’t turn off our human-ness or our emotions when we come to work.

For the organization, ignoring emotions takes a toll on productivity—people are distracted and unable to focus. For individuals, it adds to stress and alienation.

Now, I don’t believe that we should let it all out at work—even when we know our co-workers really well, we’re not in the bosom of our family. Consider the context and recognize that we are all human, and our emotions are part of what and who we are. We need to manage our emotions, not hide, fake, or ignore them. Deal with the human first, and it will be easier to get the work done.

Here are some strategies for managing emotions that make it to the office:

Confide in a friend.

Alysa and I know each other pretty well, and it was only the two of us in the meeting. Alysa feels comfortable saying things to me that she might not choose to say in a more formal meeting.

Sometimes it’s enough to tell someone what’s going on, like Alysa did with me. If you have a good friend at work, talk to him or her. Often when we feel heard and understood it’s easier to put the matter aside and concentrate.

Acknowledge emotional responses.

Karen, a team lead in a software company, was upset because her manager, Ted, had countermanded a technical decision she had made. When Karen told Ted she was upset, Ted responded “I’ve thought about it, and there’s no reason for you to feel that way.” Karen was not soothed.

We feel that way we feel, whether there’s a “reason” or not. Ted would have made more headway had he simply accepted Karen’s emotional response and talked about solving the problem… clarifying decision boundaries.

Notice what’s happening.

Earlier this month I was working with a group to surface requirements. I noticed that one of the key experts, Rosalind, was awfully quiet and kept looking down at her hands. When I looked more closely, I could see there were tears in her eyes. When we reached a reasonable stopping point, I called a break and called Rosalind aside.

“What’s happening for you?” I asked. Rosalind had just learned that her husband had cancer. We took the time before the break ended to decide what to do. Rosalind decided she’d stay for the session, and leave to be with her husband as soon as the meeting was over. Having that settled and telling someone what was going on allowed her set aside her worry and distress (at least for a short while) to participate in the requirements gathering session.

Use check-ins.

For a longer meeting or working session that requires everyone’s participation, consider doing a short check-in. A check-in serves as a boundary between outside and inside the meeting and allows people to say just a bit about their background noise, if they choose to. Something as small as being stuck in traffic and feeling rushed can block concentration. Saying it aloud can help to let it go.

Use the resources available.

Sometimes emotional distractions last longer than a few days. Jon, a programmer on my team, went through a nasty custody negotiation when he divorced. He needed to take time off work for legal appointments and mediation. When Jon came to talk to me about it, he was worried that between the emotions, stress, and time off, his work would suffer.

I put Jon in touch with the company’s Employee Assistance Program (EAP). He was able to find a support group for divorcing dads. (I didn’t try to be Jon’s therapist… that wasn’t my job as a manager. I did put him in touch with HR and worked out a flexible schedule with him, both of which were within my job as a manager.) Jon was able to remain productive at work.

If your company has an EAP, you usually don’t need to wait for your manager to bring it up. It’s there for you to use and there’s no shame in seeking support to cope with a difficult life event.

Manage employees who can’t or won’t manage themselves.

Once in a great while I encounter people who are unable to manage their emotions at work. It’s not your job to be a therapist or to fix your employees. When a member of your team is repeatedly unable to focus on work because of emotional issues, coach the employee to obtain appropriate professional help. If the employee continues to be unable to focus and do the work he’s paid to do, coach him out of the job.

What do you do to manage emotions at work? What’s the price of ignoring emotions at work?

An earlier version of this column appeared on Stickyminds.com in 2003.

What to do when your (so-called) MVP is destroying team productivity.

Luke, the manager of the Rev 2.0 team, was walking on eggshells. He’d had another blow up with Shelly, the team architect. He tried to talk to her about the way she had treated the newest employee, Brent, in the design review meeting on Tuesday. But when Luke asked Shelly to be more patient, she exploded.

“Look, my time is too important to waste explaining the obvious to the stupid,” Shelly snapped. “It’s not my fault you hire unintelligent people who can’t understand this stuff.”

“But, Shelly,” Luke said weakly. “It’s important that everyone on the team gets along.”

Shelly snorted. “Hire some smart people, and we’ll get along just fine. In the meantime, just remember that I’m the one who was smart enough to figure out the algorithms for this system.”

She didn’t need to add “You need me,” but the threat was hanging in the air.

Luke’s face burned every time he thought about that conversation. He knew they needed Shelly, but her abrasive behavior was upsetting the team. They avoided her, struggling silently to support her code rather than risking her wrath by asking a “stupid” question.

So when Luke attended a workshop on giving feedback, he asked for some coaching on responding to difficult people.

“Describe difficult,” the instructor prompted.

“Well, I have this architect,” Luke said. “She gets defensive when I give her feedback, and she doesn’t accept what I say. She thinks she’s always right.”

“Tell me more,” the instructor coaxed.

“Well, she’s brilliant. And she’s an order of magnitude more productive than anyone else on the team—she really cranks out the code. But while most people can hold six or seven thoughts in their heads, she can hold fifteen or twenty. Everyone else has trouble following her code, and when they ask for help, she’s disdainful.

“When I talk to her about it, she gets mad. I can’t afford to lose her. I need to find a way to coach her to be more patient with the other team members.”

The instructor paused a moment, then said, “So the way she writes code and the way she interacts with the team make everyone elseless productive?”

“I’ve never thought of it that way,” Luke said on reflection.

“I wonder what would happen if she left the company?” the instructor asked.

“Oh, that would be a disaster. No one knows the code the way she does, and no one can figure it out.”

“That sounds sort of risky.”

“You bet!” Luke agreed. “But what can I do? We need her.”

“Do you really? Or are you being held hostage?”

Luke mulled that thought over during the rest of the workshop. Back at the office, he spent a week observing the team and examining metrics. He listened carefully in one-on-one meetings and probed to gauge both current morale and aspirations. As he listened and watched, he formed a new picture of the dynamics within the group.

The following Monday, he asked Shelly into his office.

“Not another sermon on manners,” Shelly sneered.

“Nope,” Luke said. “We need to have a talk about how your code and your style are affecting the rest of the team.”

Shelly sat across from Luke and glared. “I can walk out the door any time and find a new job in two days.”

“I’m sure you can,” Luke agreed. “I want talk about each issue separately.”

Luke described the behavior and work results that were getting in Shelly’s way. He described the impact her behavior and style were having on the team and the department.

“Shelly, if you make some changes, you’ll be successful in this job. And you’ll put yourself in the position to be even more influential across the company. Are you willing to work on these issues?”

Shelly thought for a while, then gave a quiet “Yes.”

She and Luke worked out new expectations for code maintainability. Then, he coached her about different ways to work with the rest of the team.

Shelly didn’t experience an overnight transformation. She’s still gruff and has to count to ten in her head to keep from snapping at less-experienced colleagues, but she’s working on it. She has worked to simplify the code and has explained it to the other people in the group. She listens to questions and suggestions, and even pairs with less-experienced programmers to help them learn the code base.

Six months after their first frank conversation, Shelly asked Luke what he would have done if she’d walked out the door as she’d threatened.

“I would have let you go,” Luke said. “The way things were going, I was putting the company at risk and denying the other team members the chance to develop. I was underestimating the cost of turnover with the rest of the crew and not considering how their productivity was suffering. In a way, I feel I owe you an apology for letting the situation go on so long.”

“That was a tough conversation,” Shelly said. “But looking back, I’m glad you told me. No one had ever explained to me that my attitude was hurting my prospects. And now that I’ve gotten to know the other guys better, they aren’t so dim—just young and inexperienced.”

Luke smiled and thought, “I sure did talk my way out of that crisis!” {end}

This article originally appeared in Better Software magazine in 2006.

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.

This article first appeared on stickminds.com.

(c) Esther Derby 2004-2010

Many years ago, psychologist Kurt Lewin reduced the mysteries of human behavior to this simple statement:

B = ƒ(P,E)

Behavior is a function of the Person and the Environment

Of course, it’s not that simple. But I still find this notation useful, because it reminds me that the skills and abilities of the person aren’t the only factors that contribute performance.

Much of the time, organizations focus on the Person part of the equation. That’s important, because our work requires intelligent people with a wide range of functional skills, technical and domain knowledge, and appropriate interpersonal skills. Most managers work hard to hire the right people. Managers also provide coaching and feedback to help people hone their skills and develop their capabilities.

But that’s only half the equation.

Organizational factors, corporate culture, policies, and the direct work environment influence performance, too. The good news is that you can influence the environment for your group in ways that increase performance.

Are You Creating an Environment for Success?

Let’s assume that you’ve hired bright, capable people who have the appropriate skills and qualities for the job. They have the technical skills the job demands, they know the domain, and they’re familiar with the product. Yet the work isn’t going as well as you think it should. Maybe it’s the environment, not the person. Look at these areas to see if you can improve the environment for success.

People need to know what the priorities are. Managers don’t (and can’t) make all the decisions about how work is done. Managers need to establish clear priorities so that the people closest to the work can make good decisions. Communicate a clear mission and ensure that each person understands his top-three priorities. People perform better when they understand the mission of the group and what’s most important.

People can’t do their best without the right tools for the job. But hardware and tools, of course, aren’t the only resources people need. They need time, access to expertise, and training. No one I know can manufacture time, but setting clear priorities and keeping the workload reasonable reduce the sense of overwhelming demands. When budgets are tight, find inexpensive ways to feed the need for training and expertise. Offer to buy books for a lunchtime study group and support access to content websites and other free sources of information.

People desire respect. Every once in a while I hear a manager assert that people work best when they’re a little afraid. I don’t buy that. Show respect by keeping promises, communicating openly, and listening to other people’s ideas. Don’t take phone calls and pages or check email during meetings, especially one-on-one meetings.

People want challenging work. Make work assignments based on interests, or better yet, work with your team to have them self-organize. That way, people will have a chance to choose work that appeals to them. Now, every group has some scut work. Rather than assign that to one unfortunate person, rotate responsibility for the work no one really enjoys, but everyone recognizes is necessary.

People want recognition and appreciation. I’m not talking rewards here, monetary or otherwise. Humans crave genuine acknowledgement for their contributions at work—both concrete accomplishments and the intangible ways they contribute to the spirit and success of the group. Let people know that you notice and appreciate them every week. I don’t think saying “thank you” or “good job” is good enough. I like to address the person directly, like this: “Don, I appreciate you for shipping that data update on time. It makes a big difference to our clients.”

Are There Environmental Roadblocks Stifling Performance?

Suppose you’ve done all of these things (and more) to establish an environment for success. Your work is not done.

Corporate culture and norms are part of the environment and so are policies, procedures, measures, and reward systems. Examine the organizational environment to see if there are other obstacles that keep people from doing their best.

Are there factors that actually punish people for doing a good job? I once worked with a support group that was having a crisis in customer satisfaction. Support agents were expected to meet certain targets for the length of calls.That worked fine with simple problems, but when a tough problem that took more than a minute or two to fix came along, it was a problem. The measure actually punished people who went the extra mile for the customer and stayed on the phone long past the allotted time. These folks had the knowledge and skills to perform, but an environmental factor (a poorly designed measure) was in the way.

Sometimes policies and procedures are the culprit in stifling performance. One organization I know of requires bi-weekly budget reporting and forecasting. It can take up to seven working days to assemble all the bits of information needed to create a report. The procedure is difficult and frustrating, and the time people spend every month on budgets means they aren’t doing other valuable work. In another group, each team member is required to provide written feedback to every other team member every quarter. It wasn’t so bad when there were five team members, but now that there are twenty people in the group… well, you can do the math.

Pile on enough environmental roadblocks and people become frustrated and cynical. And frustrated, cynical people are less likely to do a good job.

Individual managers can’t always change measurement systems, policies, and procedures. Insulate your group where you can and put the rest in context.

Remember that an individual’s skills and abilities aren’t the only factors in performance. Managers need to attend to both the person and the environment when assessing performance. Don’t wait until the next performance evaluation season rolls around. Evaluate the work environment now. Does the management infrastructure enable high performance? Are you working to remove or reduce the obstacles that are hampering performance? What else can you do to create an environment for success?

© Esther Derby 2001 – 2010

This article originally appeared in STQE May/June 2001.

As test and development managers, we pay attention to developing technical personnel, but what about managers? Do we do enough to help manager and team leads develop and improve their leadership skills–especially when we are those managers?

Some companies, GE for example, have a strong tradition of developing managers from within. Promising employees are carefully groomed through a series of increasingly complex and responsible assignments, with formal and informal mentors to guide them along the way. Along with teaching specialized domain knowledge, mentors coach new managers in the “soft” skills that are crucial for top management performance. How often to you hear of managers being carefully trained, developed and mentored in the software world?

I didn’t go to software development or test manager school, and they didn’t teach much about the people side of management in the school I went to. I ended up in management because I had good technical skills. I was originally promoted to project manager because I was a good software developer, and I stayed in management because I hoped I could do a better job than the people who had been managing me. I meet a lot of managers with stories similar to mine.

As a new manager, I got a clear message: Managers are supposed to know what needs to be done and how to do it (or at least act that way). And that message put me in a kind of trap: if I’m supposed to know what to do, it’s harder for me to admit I don’t have the answer or I need help.

The truth is, few people know intuitively how to manage process, projects and people. Like anyone else learning a new skill, new managers need training, guidance and mentoring. And just like technical staff, experience managers need to keep their skills current and evolve with an evolving workplace.

As managers, we spend time and effort improving testing, configuration management and development processes. What about management processes? What can we do to improve our own management processes? The good news is that good managers are often made, not born. Here are some of the things I’ve done to develop my management capabilities:

Get to know “me.” The most important things I’ve learned that resulted in direct improvement in my management capability weren’t about managing other people — they were about me. How do I cope with conflict, what assumptions do I have about people, how do I respond when I feel angry or hurt or scared? How do my emotions effect the way I make decisions? What are my strengths, my weaknesses and my blind spots? These skill have to do with self-management….if I can’t manage myself, I don’t stand much chance of managing anything or anybody else.

Find a model. Like most humans, my first lessons in navigating relationships came from watching and imitating my parents. I got my first lessons in management that way, too, watching other managers. Only thing was, I didn’t have real good management models in my first few jobs. It took a while to find a manager I wanted to emulate: someone who not only got the project in on time, but build decent software and treated people like adults. I try to learn from other managers who get things done and always have a list of people waiting for a position to open in their group.

Find a mentor. A model shows me what to do; a mentor will tell me when I don’t quite hit the mark. Trust is a big part of a mentoring relationship, and it takes a certain amount of personal chemistry, too. My first mentor [Jerry Weinberg] didn’t work for the company where I was employed, though he was consulting in the organization when I met him. He was a willing to provide feedback, answer questions and help me puzzle through all sorts of management challenges. He’s also given me some of the hardest messages I’ve ever had to hear (and I’m a better manager for it!).

Start a book study group. I don’t have the luxury of reading every book I’d like to. But I can usually find an hour to read a chapter. So I divide the labor and get together with a group and read. Each person reads a chapter and reports on it. Everyone gets an overview of the book, and I can focus later on chapters that are most meaningful to me. Sometimes we meet two or three weeks later and discuss how we’ve applied the concepts from the book in our work.

Keep a journal. I find that recording events, decisions and results helps me see patterns and analyze the results of management actions. It’s not always pretty, but it helps keep me from making the same mistake over and over and over. The habit of reflecting on the outcomes of decisions is a simple and powerful way to improve management abilities.

The key really, is to remember that mangers never really arrive–there’s always more to learn. The more effort I put into improving my management capabilities the more effective I’ll be in managing people and projects. And that means better software.

(c) 2002-2010 Esther Derby

This column originally appeared in STQE magazine, July/August 2002

ac-count-a-ble adj. 1. Subject to the obligation to report, explain, or justify something; responsible; answerable. 2. Capable of being explained; explicable.

(The Random House College Dictionary, Revised Edition, 1988.)

Did you know that’s what accountable means?

I never would have guessed that from listening to how people use the word. And I hear people use it a lot lately. It seems like the one of those management buzzwords that pops up from time to time, like “leadership” and “nimble” a few years back. When I ask, most people who use the word can’t give me a precise definition. They trail off saying, “Accountable means . . . well, you know . . . accountable!”

I suspect that accountable is used as a surrogate for other, less palatable, expressions. I’ve got my decoder ring right here, so let’s figure out what’s really behind this word.

False Definition 1: To be pressured

When you hear someone say, “You must hold him accountable,” pay attention to the emphasis the speaker puts on the words. When the there isn’t any particular emphasis and the statement is followed by some examples of what the staff members are expected to do, and the tools they have to do the job, the speaker is probably talking about setting achievable goals and tracking progress.

But if you hear particular stress on one or more words (“You must hold him accountable,” for example), the speaker may have a mental model of management that says, “people are basically lazy, and if you don’t push them, they will take their own sweet time getting anything done.” Listen, too, for what comes after the statement. If you hear that colorful phrase “hold his feet to the fire,” or the word “disappointed,” then accountableis a code word for pressure. And the speaker really means, “You must pressure him to perform.”

False Definition 2: To be blamed

Take for example, “The project manager is accountable for project success.” If you read this according to the dictionary definition, it might mean, “The project manager is responsible for reporting on the current state of the project, explaining the situation, and justifying the need for resources that will provide a reasonable chance of success.” It might also mean, “The project manager is responsible for explaining and justifying plans to achieve the project goals.” Or even, “If something goes wrong, the project manager must explain why.”

Unfortunately, I often hear “The project manager is accountable for project success,” (or it’s more obvious evil twin, “You are accountable for project success”) in situations where the chances for project success given the current situation are slim to none (and none just left town). Then it really means, “I will blame you if this project fails.”

False Definitions one and two are forms of pressure: a threat of unpleasant future consequences. Will that pressure really help? Or just make the blamer feel better?

False Definition 3: To be responsible for someone else’s mess

Ever heard this one? “The problem around here is that no one is accountable.” I usually hear this variant in organizations where the measurement or reward system is driving behavior that makes life “downstream” a misery. The problem isn’t really that people aren’t being held accountable; it is they are being held accountable for goals that are in conflict. For example, a certain project manager was held accountable for meeting a schedule. He’s now in the Bahamas enjoying his bonus for getting the project out on time. Meanwhile, the support manager is working overtime dealing with irate customers whose software is crashing. He is being held accountable for a goal (perhaps maintaining a certain customer satisfaction rating) that is nearly impossible to achieve, because the project manager had a goal to meet a delivery date, but did not have a goal to meet a quality standard. When someone says, “no one is accountable,” it probably means, “Because of the way someone else did his job, it is very hard to do the job I am accountable for. I feel like I’ve been left holding the bag.”

Say what you mean. Mean what you say.

Why am I making such a big deal about this? After all, accountable is only a word. And I do believe that people should be accountable for their actions. But when there’s a coded meaning involved through context or emphasis, then no one is well served. I believe that the vast majority of people want to do a good job. They may not always know how or have what they need to get the job done, but their intention is to do good work.

We will all be more accountable if we remember the true definition: The first part “subject to the obligation to report,” reminds us to report on our understanding of the task and our ability to get it done with the current resources. The second part, “capable of being explained; explicable,” reminds us to check that the task can be credibly described. When we remember the real meaning of accountable, we can stop talking in code words and get on with building solid software.