This is a guest post by Johanna Rothman.
You may have seen these interactions on your team, as I saw at a recent client:
Tina, a tester on an entirely distributed agile team, received this message from Dan, the developer:
Are you done with this feature yet?
As part of the story refinement, they’d discussed how his unit tests and her system tests would also meet in the middle to verify the feature. The story was a little tricky and they both wanted to make sure they met the story acceptance criteria.
Tina was concerned. She’d only spent the last hour on the feature. Why was he asking her if she was done yet?
She started to compose a return message when she received this message from Polly, the product owner:
Are you done with this feature yet?
Tina felt frustrated. Why were both of these people asking her the “when” question? She’d be done faster if no one interrupted her since she was working alone. Maybe she’d ask Dan to pair.
From her previous distributed team experience, Tina knew she might not know what was behind the question. She decided to ask more questions about what each person wanted.
Tina messaged Dan. “I just got the same message from Polly. Did you mean you want me to go faster, or did you want something else?”
Dan messaged, “I just realized I didn’t do this part,” and he explained what that part was. “I’m so sorry. I didn’t want you to proceed until you knew I knew I hadn’t finished.”
Well, that wasn’t what Tina expected. She had to admit, this agile business made everyone take much more responsibility for their own work.
Tina and Dan started a video call to discuss what he still needed to do. They agreed where Tina could continue. Tina promised she would look for his changes in the next 30 minutes.
Then, Tina messaged Polly. “Are you asking because you want to accept this feature and see it work?”
Tina returned to her test development and testing work while she waited for Polly to answer. Tina looked at the team calendar. Oh, Polly was at a customer site. It might be a long time before Polly answered.
Sure enough, Polly didn’t message Tina back for several more hours, just before Tina stopped working for the day.
“Sorry to irritate you. If you were done, I would have been able to show the customer something. Since you weren’t, I talked about it. No worries.”
Same question. Two different meanings. And, neither of them was pressure on Tina. And, because Tina assumed each person had good intentions, she was able to respond without anger or frustration.
Assume Good Intent
In a collocated team, we can turn around and ask each other questions. We don’t need to send a message of some type. We answer in moments.
Because we have easy access to each other, we can see each other’s intention, too. If you turn around and someone’s pulling out his or her hair, you might offer empathy. Or, if you’re in a team room, and you hear someone banging on the keyboard, you might realize the depths of their frustration.
It’s easy to see what people do and maybe infer how they feel in a collocated team.
Distributed team members—and in this case, a totally dispersed team—can’t turn around and talk to each other. They might default to text-based communication, as this team does, especially for a quick question.
If you saw the question Tina saw about being done, what might you think?
- The team wanted her to finish faster for some reason.
- Polly wanted her to finish faster for some reason.
- Someone wasn’t sure that what she was doing was right, and wanted to look at her work.
All of those meanings were about her time or how she worked or the correctness of her work.
None of those meanings were what Dan or Polly wanted to learn.
Dan wanted to save her time because he hadn’t really finished—and he realized it after he thought he had finished. He didn’t want her to think he was a jerk when he hadn’t finished. He didn’t want her to waste her time.
Polly wanted to take advantage of possible serendipity with a customer, but that didn’t work. Polly wasn’t upset. Polly wanted to know if luck was on Polly’s side. It wasn’t and that was okay.
Neither Dan nor Polly blamed Tina for any work done or not done. That lack of blame makes the difference between a great environment (no blame) and an environment you want to escape every day (blame).
Both Dan and Polly were fine with the fact Tina hadn’t finished yet. All three were able to adapt to the situation once they all knew what the situation was.
Ask Clarifying Questions
When we assume good intent, we can ask a variety of clarifying questions such as:
- “Did you really mean…” to ask if someone meant what you thought they said.
- “What’s behind your request” to understand the other person’s goal.
- “Are you asking because” and offer what you think is behind the request, to clarify the other person’s goal.
Clarifying questions work well in any team. These questions work even better with distributed teams because it’s so easy to become frustrated with each other and jump to an incorrect assumption. When we clarify what the other person meant, we assume the best, not the worst.
Clarifying questions are open-ended. You can’t answer them with a single word or a number, such as yes, no, or 42. Open-ended questions require a nuanced answer.
When we use clarifying questions, we learn the reason behind the request. With that reason, we can offer alternatives.
Consider Alternatives That Fit the Situation
Tina took several actions that helped her know what each person wanted, as fast as possible.
- She asked a clarifying question to understand Dan’s perspective.
- She and Dan used video communication to make sure they each understood all the details.
- She consulted the team calendar to see where Polly was and if that would make any difference for their conversation.
Tina didn’t assume the worst. She assumed the best. She could ask “Did you mean” or “Are you asking” to clarify the entire situation.
She used all the communication channels and team information available to her to understand the other person’s context.
Tina appreciated Dan’s responsible information. When he explained his mistake and told her what he was planning to do, he clarified the entire situation.
Tina also appreciated Polly’s desire to show a customer something new and Polly’s understanding that things don’t always go according to plan.
You might need different alternatives than Tina did. However, when you assume good intent, you create the possibility of team unity, not individual separateness. Even at distance.
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Johanna is the author of fourteen books and hundreds of articles. Find the Pragmatic Manager, a monthly email newsletter, and her blogs at jrothman.com and createadaptablelife.com.
