Category Archives: Reading Rack

A collection of my articles that have appeared in magazines, newsletters, and on other websites.

Building Effective Teams: Miss the Start, Miss the End

(This article originally appeared on

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

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

The 60-30-10 Principle

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

Aim for Flexible, Long-lived Teams

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

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

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

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

Articulate a Compelling Goal

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

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

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

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

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

Pillars of support

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

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

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

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

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

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

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

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

Rethinking Manager’s Relationship with Agile Teams

This article originally appeared on 

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?

Yes. No. Negotiate.

Many people are conditioned to say Yes to every request that comes their way.

I met a CIO like that. He told me his policy was to never say No to the business. So he always said Yes, and the business was always angry because things he agreed to didn’t get done, or got done poorly or far later than they wished. His Yes meant nothing.

Sometimes, a clear No is the best response. When there’s no real possibility of meeting a request, No allows the person making the request to adjust accordingly. That may mean changing plans or finding another way to get some work done.

But other times, No is the starting point for a negotiation. Here’s a story about how one new manager learned to stop saying Yes, and getting talked out of No.

Recently, I met with Monroe, a new manager, over lunch. He was feeling overwhelmed, and recited a long list of projects he was working on. Monroe complained that his boss didn’t seem to realize how much work he was doing.

“Do you ever say no?” I asked.

“Of course I do!” Monroe said. “I try to say no, but then he gives me all the reasons it’s important for the company to do this extra project. He does have good reasons for what he’s asking for, so I cave in. But I can’t see how I’m going to get all this work done!”

Monroe isn’t alone in having difficulty in turning down his boss’s requests. Some people have a hard time saying no because they fear offending. Others have rules that say “Don’t disappoint,” or “Always be helpful.”

Rules may keep us from saying no even when we want to—when we realize saying yes doesn’t serve us. Some people don’t consider their own needs when they say yes, assuming (albeit unconsciously) that whatever the requester wants is more important than their own priorities, health, well-being, or ability to juggle one more task.

As Monroe and I talked over lunch, I began to understand that Monroe had a slightly different problem. He could say no, but he just couldn’t hold it. If Monroe stood firm in his refusal, his boss might think he wasn’t up to his new management role. But Monroe was paying a price for backing down.

Since he said yes to all the requests eventually, Monroe was actually training his boss to keep pressuring him until he wore him down. In doing this, Monroe was also bringing about the result he feared most: showing his boss he wasn’t up to his management job by failing to prioritize and follow through on agreements.

Underneath his inability to say no and have it stick Monroe suffered from having a two-speed switch: On (Yes) or Off (No). What he needed was a way to start a negotiation toward an agreement that recognized organizational goals and took into existing work commitments into account .

Monroe and I started thinking of ways he could start a negotiation. Rather than simply blurting out “No!” Monroe decided to start by affirming his boss’s intention by saying, “I can see why that’s important to the organization.” Having something to say would give him a bit of time to think.

Then, depending on the situation, he’d use one of these phrases to start a negotiation:

I can’t fit that project in right now. I can do it ___________.

I can’t do that, but I can do this ___________.

I’d be willing to offer________________. Would that help?

This is what I can do. I can do that instead of _______________.  Which is more important?

I can start on that project after ____________.

I can do that AND here is how that will affect ___________ (other work, commitments, etc.).

If Monroe didn’t have an immediate grasp of the impact, he’d one of these answers to gain time analyze the situation:

I need to check with ________ before I commit to that.

I can’t give you an answer I can stand behind until I review my other commitments.

Monroe and I met a week later to check in, and he reported on his boss’s latest request. “It was sort of funny!” Monroe started. “My boss asked me to take on another task, and I used one of the responses we rehearsed. Then I went over to the white board and did a chalk talk of our current work. When I finished the picture, I turned to my boss and asked him what work I should put on hold in order to fit in the new work.” Monroe grinned. “And you know what my boss said? He said, ‘Now you’re thinking like a manager.’”

The Agile Blindside

(this article originally appeared on

Agile project management depends on transparency and feedback. Visibility into the product and process is built in with iteration reviews and retrospectives. Task walls and Kanban boards make progress (or lack of it) and bottlenecks obvious. Stand-up meetings seek to raise impediments to management attention. But are managers ready to hear about these problems?

If organizations want to realize the benefits of agile methods, managers need to act on the problems that bubble up from teams, deal with unexpected events on projects and proactively find and fix problems that derail projects. Unfortunately, many managers behave in ways that communicate they aren’t interested in solving problems–and ensure they won’t learn of problems until it’s too late.

“Don’t bring me problems, bring me solutions.”

I suspect that managers who repeat this sentence believe it will encourage people and teams to solve problems on their own. But people don’t approach their managers with problems they know how to fix and can solve (or believe they can solve). The problems they raise are ones they don’t know how to solve, don’t have the organizational influence to solve or need some help to solve.What really happens when managers talk this way? Team members struggle in isolation or ignore problems, hoping they will go away. Managers who tell people not to bring them problems ensure that they won’t hear about small problems that are part of a larger pattern.

“Failure is not an option!”

Managers who rely on this exhortation ensure they won’t hear about risks and issues. The phrase sends the message that success is a matter of character and will rather than the result of planning, observation, re-planning and course correction when something unexpected occurs.

Will and character are assets in any endeavor; however, they are not sufficient for success. Success requires removing impediments and proactively finding and ameliorating problem situations. Failure may not be an option that managers like, but it is always a possibility; ignoring that fact forces problems underground and makes failure more likely.

“The thought that disaster is impossible often leads to an unthinkable disaster.”- Gerald M. Weinberg

“Get with the program or get off the bus!”

When managers give the impression that their minds are already made up, subordinates are less likely to bring up weaknesses, problems or alternatives. People fear that their concerns won’t be heard. Worse, they fear (often with reason) being labeled as naysayers or whiners. Discourage people from shining the light on problems and they’ll stop.

But managers don’t need to be obvious in their discouragement; more subtle actions can also plug the pipe.


Interrupting a person who brings unwelcome news makes it harder for that person, who is already facing a difficult conversation. People interrupt for many reasons–excitement, the desire for more details, etc. But to the person being interrupted, a stream of interruptions can feel like an interrogation. Interrupting implies impatience–and that anything the interrupter has to say is more important than what the other person was about to say.

Ignoring Intuition

A couple of years ago, a friend felt uneasy about an action his manager was taking. He couldn’t quite put his finger on why he felt concerned, but his feeling strong enough that he went to his manager–who dismissed his intuition, telling him, “Come back when you have some facts and we can have a logical argument.” But the situation outpaced data gathering and blew up.

Asking for excessive proof and demanding data ensures that a whole class of complex and systemic problems won’t come to attention early.

Non-verbal cues

I coached a manager who furrowed her brow and tapped her pencil when people told her about problems. She was thinking hard. They thought she was irritated with them for brining bad news.When there’s a problem on a project, the earlier you know about it, the more options you have to mitigate the impact, make a course correction or re-set expectations. But you won’t hear about problems if you plug the information pipeline.

“The problem isn’t the problem. Coping with the problem is the problem.” – Virginia Satir

As much as we might wish there were no problems on projects, that’s not the way the world works. Problems are a normal part of life. Managers need to know about problems so they can see patterns, find options and steer projects.
Here are three things you can do to make sure your information pipeline flows:

Tell people you want to hear about problems. Sounds simple–and it is. Assure people that you understand that nothing goes exactly as planned and you don’t expect perfection. You may not want every problem dropped at your doorstep to solve–but if you act as if having problems is a problem, you won’t learn about impediments and issues when they are small.

Learn how to listen. At a recent talk, a participant asserted that people from [fill a non-western country here] don’t know how to say “no.’” This is not true. What is true is that many Americans don’t hear it when people from different cultures say “no.” The same is true for hearing about problems. If you want to build an early warning information system, you need to learn how to listen. That means refraining from interruptions. It also means listening for less obvious cues and what isn’t being said. When there’s a long hesitation preceding a positive statement, there’s more to learn. If you don’t hear any mention of risks or issues, delve deeper.

Teach people how to speak up. I don’t want to clog the information pipeline by implying that I only want to hear about problems that have ready solutions:

The most important and dangerous problems don’t have an obvious fix.Here’s a framework that has worked for me. It provides useful information and an agreed-upon format that reduces the psychological barriers to raising issues:

“Here’s my hunch…” This makes it explicit that I don’t require excessive proof.
“Here’s why you need to know about it…” This signals that I recognize that I don’t know everything.
“Here’s my data…” If there is data, it’s good to know. And I’ve heard about intuition being born out enough that “I have a bad feeling about this” is good enough for me.
“Here’s what I’ve considered or tried…” I do want people to think about the issue and I want to hear about their thinking. Problem solving is improved by multiple points of view.

Standard agile practices such as visible charts, frequent demonstration of working product, and retrospectives are all ways to make both progress and problems visible. But if people don’t feel safe to bring up issues, you won’t hear about them until it’s too late. If you take the actions outlined here, it will be easier for people to bring up problems to you. Problems are part of life–and projects. Pretending otherwise creates a culture for them to hide and fester.

Fixing the Quick Fix

Here in the United States, our business culture tends to be action-oriented. We value the ability to think fast and act decisively. These qualities can be strengths. However, like most strengths, they can also be a weakness. Taking action when you don’t know the facts can lead to irreparable harm. Deciding too quickly before you’ve examined your options can lead you down the wrong path. Fixing fast may assuage symptoms but leave the underlying problem to fester.

Treating symptoms may work with the common cold, but with many technical and organizational problems it’s a prescription for disaster. Before you chase a solution, slow down and make sure you are looking at the underlying problem, not just soothing symptoms. (Sometimes, as with the common cold, you do need relief from symptoms in order to make any progress.) Of course, we can’t always tell right away whether we are fixing a symptom or an underlying issue. But, if the problem keeps coming back, you can be sure that you’ve been dancing around manifestations of the problem, not tackling the problem itself.

Start by Questioning Your Questions

Every question contains assumptions. While a question opens one avenue of inquiry, it closes others. The questions you ask constrain your thinking about the problem and your eventual solution. For example, in one company, the executives weren’t satisfied with the speed with which the IT department delivered projects. They sacked the VP of the IT department and brought in a new one with a reputation for decisive management action. The new VP immediately started asking questions, which seems like a good sign, until you know her questions:

Where is the dead wood?

How can we get the testers and developers to work harder and move faster?

These questions assume the source of the problem: lazy and incompetent people. But, what if the reason projects are late has something to do with the fact that people are assigned to several projects at the same time or that priorities change so quickly that teams never reach “done” before they are pulled to work on the latest urgent issue? The VP has already narrowed her inquiry and will only arrive at “solutions” that involve firing the “dead wood” and whipping those deemed “live wood.”

Examining our questions is critical, because not only do our perceptions influence the language we use, but also the language we use influences what we perceive.

Starting with a more general set of questions will help reduce perceptual bias and uncover the facts of a problem situation:

What are the visible symptoms?

What other effects can we observe?

Who cares about this issue?

What is the impact on that person/group?

What is the impact on our organization?

What other factors might contribute to the problem situation?

What other events might influence the context?

These questions may lead you closer to the real problem, or at least help you see whether the area you are looking at is the most fruitful for alleviating pain. Based on this, choose where to delve deeper, and get more specific as you explore the details of the situation:

When does the problem occur?

How frequently does it occur?

Is the occurrence regular or irregular?

Does it always happen, or is it an exception?

Under what circumstances does the problem occur?

What are the circumstances under which it doesn’t occur?

What else is happening around the same time? Are those factors connected?

At this point, you may start to feel you have a pretty good idea of what the problem is, so …

Back Up Your Hunches with Data

These questions will give you some clues as to the problem, but data will confirm your hunch (or point you in a different direction). I’m not talking about a measurement program here, but simple, “good enough” data gathered from observation or existing sources. Once you have data, look at it from several vantage points, or you may miss something important.

For example, at a large financial services company, operations analysts collected data on the number of minutes during which each application was unavailable during core business hours. They presented the data at a monthly management meeting using a pie chart. The chart clearly showed which application had the largest portion “outage minutes” for the month. Presenting the data in a pie chart facilitated putting the manager of the offending application on the hot seat at the management meeting. But, it didn’t help much with understanding the problem, or knowing where to look for solutions.

By the time I arrived to help them solve their problems, they had many months of data, and looking at it differently provided useful information.

I used the questions above to guide how I viewed the data. I looked at the total number of outage minutes each month. I look at the trends for each application. I looked at outages in time series. But, the data didn’t answer the question, what is the impact on our organization? I set out to answer that question, and found that not all outages were equal. A day-long outage in a specialized application only affected ten people. A five-minute outage in another system meant everyone in the department—several hundred people—couldn’t access any applications, but it had only happened once. A short outage in an application used by one-third of the department that happened every day accounted for most of the outage minutes over time. Knowing this didn’t solve the problem, but it told them where to focus their fixing.

Quick-fixers may bemoan the amount of time I spent cleaning the data, looking at it this way and that way, asking more questions and gathering more data. It took about a week. Of course it did take a bit more time to repeat this process at the application level. Still, taken in total, the time spent asking questions and gathering data was far less than the time that had passed while management tried to understand the situation with data presented in way that hid useful information—and less then the outage minutes for all affected employees for one month.

Generate At Least Three Candidate Solutions

Now, it’s time to look for possible solutions. Quick-fix thinking conditions us to choose the first idea that’s even remotely plausible. Don’t dismiss your first idea, but don’t stop there either. Develop at least three candidate solutions. You may go back to your first idea, but by developing additional options, you’ll understand the problem better. If you have difficulty thinking of more than one candidate solution, turn your thought process upside down and ask, “How could we make the situation worse?” That paradoxical question almost always jiggles more ideas loose.

As part of developing a solution, identify at least ten things that could go wrong with each candidate solution. Looking at the downsides might send you back to generating more options. Sometimes the best solution isn’t the most elegant; it’s the one with the fewest or least objectionable downsides.

Once you have several options to choose from, choose one and put it motion. Chances are it won’t work out quite as planned—and that’s an opportunity for learning. Observe and gather data, re-adjust, and try again.

Every solution carries the seed to the next problem. That’s a given. When you apply systematic thinking to the problem, it’s less likely that next problem will compound the problem you were trying to fix in the first place.

This article originally appeared on

Talk, Talk, Talk

I wrote an article about the many ways that managers inadvertently plug the communication pipeline (free registration required). In doing so, they deprive themselves of the information they need to do their jobs. It reminded me of one of the most common ways managers block information–talking too much, listening too little. Some advice for managers…


I recently observed a manager meeting with a team member. The manager gave the low-down on a leadership change at the top of the company, speculated on the economy, described his plans for the future, and detailed his mother’s heart attack.

At the end of the meeting, the manager smiled at the team member and said, “Keep up the good work. You’re doing a great job!”

How would he know?

The team member barely got a word in edgewise, and certainly didn’t have an opportunity to describe what he was working on.

Watch the Conversational Balance

In a social situation, a 50/50 balance between talking and listening feels comfortable. But management conversations are different. Managers need to understand how people are working, and where they need help. Managers need to understand the status of work, risks, and obstacles. The manager described above talked 95 percent of the time and listened 5 percent of the time. 30 percent talking and 70 percent listening is a more appropriate balance for management conversations.

Prime the Pump

Aiming for a 30/70 balance doesn’t mean you sit there silently and wait for the other person to fill the silence. Nor does it mean that you need to listen to a rambling monologue that doesn’t provide the information you need to do your management job.

Hone your questioning skills to help you explore the work and understand your team members. Ask open-ended questions, questions that invite expansion, to draw out relevant information. Open-ended questions often start with “What” or “How”.

Some of the questions I find useful in starting conversations with team members are:

• What’s going well?
• What’s keeping you up at night?
• What obstacles are you running into?
• How did you approach the ____________ issue we discussed last week?
• Tell me about your work on __________.

Ask probing questions to gain further insight:

• What else?
• Can you give me an example?
• What’s behind that?
• What else have you tried?
• What other information would be helpful?

Closed questions often start with “Can”, “Do”, “Are” or “Is.” Closed questions naturally lead to a one-word answer. A steady stream of closed questions feels like an interrogation: use closed questions when you want to confirm specific information.

• Did you check with Fred on that?
• Did you try the transaction under load?

Avoid “Why?” Questions

Of course, you want to know why, but asking “Why?” isn’t always the best way to find out. “Why?” questions put people on the defensive. Try asking questions that start with “How” or “What” to understand the reasons behind an action, approach, or decision.

• How did you arrive at that conclusion?
• What factors did you consider?

Ask One Question at a Time

I once sat in on a planning session where the leader started by asking a series of questions — eight of them (I counted). “Well, what are your answers?” he asked, looking expectantly at the dazed group. No one knew where to start. Should they start with the first question (if they remembered it)? The last? Some where in the middle?

Compound questions have the same effect:

“How are you doing on the performance tests – and are we getting anywhere with the memory leak – or is Ted handling that now, and is he able to work independently on that or is Sally helping him and how is that effecting the load testing?”

If you really want answers, ask one question at a time, and then…

Wait for an Answer

Some people like to think then talk. Others like to talk as they think. Our industry tends to have more people who like to think, then talk. So when you ask a question, give the other person some time to answer, pause, and count to ten. Wait patiently. The other person will answer.

The Other Side of the Desk

What can you do when your manager doesn’t leave room to get a word in edgewise?

Based on what I’ve seen, many people, like the 95 percent talk manager I observed, are unaware of that they are dominating the conversation. Some managers are uncomfortable with silence. Others assume that since the other person isn’t jumping in, they don’t have anything to say.

The trouble is, when you don’t share the same style, jumping vocally can be difficult. Try telegraphing your desire to speak in other ways:

• Send an email ahead of time with the topics you’d like to cover. Bring a copy with you to the meeting. Before the manager builds up a head of steam, gently push the topic list across the desk.
• Lean forward, open your mouth as if you are about to speak, and raise your hand slightly. Clear your throat, then begin speaking.
• Wait until your manager takes a breath (everyone has to inhale sooner or later). Start talking.
• Raise your index finger and place it in front of your lips. Most people recognize this as a sign you want them to be quiet for a while.
• If you are comfortable jumping into the monologue, say something like, “Excuse me, I have some information I think you need to know.” Then keep talking.

Managers need excellent communication skills and that doesn’t just mean talking. Part of good communication involves knowing when to ask a question and when to be silent and listen.

This article originally appeared on

Still No Silver Bullets

Not so very long ago, I made my living writing code. My colleagues and I did our best to understand what our customers needed, and to write code that was easy for other programmers to understand, solid, defect free.  When our managers asked us how long it would take to create a new feature or modify and existing program, we studied the problem, considered how much code we’d need to write or change, how we’d integrate the new functions with existing functions, and what sort of testing would allow us to feel confident our work was complete and correct.

Our managers were often not satisfied with our estimates.  They wished we could deliver working software more quickly.  They suggested we were exaggerating how complicated the work was.  They hinted we were padding our estimates, and spoke sternly of work expanding to fill the available time.  Then they revised the estimates to fit their desires and handed down a due date.

Strangely enough, the work usually took longer than the managers wished it would.  Our managers contemplated the gap between wished-for and actual delivery and pronounced us not sufficiently productive.

And so the quest to improve our productivity began.  First it was CASE tools.  They were supposed to improve productivity by an order of magnitude (they did not).  Then came Rapid Application Development (apparently the managers stopped reading after “Rapid”).  The next improvement, Object Oriented programming, was supposed to save the day (it did change the way we think about programming).  When I left that company, the productivity pill was a development methodology that took up an entire 4-foot bookshelf.

And the quest to improve productivity in software organizations marches on.  More and more often, the quest includes some flavor of Agile Methods, and a promise of hyper-productivity, quick delivery, and change for free.

Agile methods can help achieve business results, get software out the door faster, adjust to new priorities, and dramatically reduce the number of errors that reach the customer.

Agile encourages close collaboration with a product owner or customer (whether that’s an internal customer proxy, product owner or an end-user of the software). This helps teams understand the customer and his context, so they can make better decisions about feature design. Short iterations and frequent demonstrations of working features keeps development close to customer needs and wants.

Agile methods encourage planning based on demonstrated capacity, using agile methods can help prevent cost overruns and help managers make decisions to continue funding feature development–or not. Iteration planning and tracking story points helps teams and management understand capacity. Without this information, plans are merely wishes.  Armed with such information, managers have the opportunity to review progress and viability at the end of every iteration.

Working in short iterations to produce working software can allow a company to realize revenue early; when teams finish small chunks of features each iteration, it’s no longer necessary to wait until all the features are completed to test and deploy. Every feature slice is tested and ready for customer acceptance at the end of the iteration. When the slices add up to a marketable set, managers can choose to release.

Agile engineering practices such as automated unit and customer tests, pair programming, and frequent integration find errors early which reduces the number of defects released to the customer. That results in lower support costs, find and fix costs and bad press generated by buggy products. Practices such as simple design, Test Driven Development and refactoring keep the design flexible and clean, avoiding design degradation and escalating costs for future changes.

Many teams who use agile methods are building strong cross-functional teams and report that their satisfaction with work-life and work/life balance is higher. Working at a sustainable pace and re-establishing pride in work bring intrinsic motivation. That makes it easier to attract and retain employees.

But when agile methods—extreme programming, scrum, kanban or some combination there of—are imposed as a way to “fix” perceived programmer productivity problems, the effort almost always fails.  Sheep-dip training programs, “going agile” by decree and cherry-picking the agile practices that don’t seem difficult won’t achieve great results.

No method, or set of methods can improve results unless managers also change the way they do their work.

Managers need to get organizational systems working.  Managers must do the hard work of understanding the market, their customers, and make difficult choices about what work to do and what work not to do.  Managers need to study how teams and organizations really function and then create systems and environments that don’t hinder people from doing work.

Writing software is hard.  Agile methods can help.  But they are not a silver bullet.  And no method can improve productivity unless management also changes.

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

Are You Ready to Coach?

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

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

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

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

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

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

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

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

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

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

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