I recently had a really excellent, deep conversation with a sales specialist. He’s working at an up-and-coming startup. Those of you who enjoy data collection and analysis might enjoy their products. Over the course of the conversation, he mentioned one of the more pressing issues in his organization: poor communication.

IMPORTANT NOTE: The anecdote that follows is applied to my friend’s situation, specifically. The methods used can be applied to any situation where communication between teams (whether it’s technical or otherwise) is facing challenges! For instance, a non-profit might use a similar process to think up better ways to incentivize donors.

Poor communication can manifest in about a million different ways, and there are a lot of different causes. Thankfully, there are some great tools in my kit for solving communication issues, especially in an organization willing to adapt their culture and their expectations. Startups tend to be a lot more adaptable in those contexts than most large companies. So, there was an opportunity for my friend to put them to use in solving this communication problem.


He started by detailing the “day-to-day” experience that best exemplified the complaint he and his team were experiencing. In their organization, “Sales" is divided into two different teams, managed by two different leaders. Those two teams are Sales and Business Development. One develops the leads, and the other closes them before passing them on to the Accounts team. That’s how their sales flow goes. Pretty typical.

As the team “in the middle,” Sales has the most interest in creating a process that works. Most obviously because it will reduce their own friction, which means an increase in throughput: like removing a kink from a water hose, except in this case the hose is carrying revenue potential. To that end, we started hatching a plan to “remove the kink."

The first step is to find an internal champion. My friend is awesome, and great at what he does. Unfortunately, though, that doesn’t always mean someone has the “pull,” politically or culturally, to be a change agent inside their organization. He had someone in mind already, who he had previously established a good rapport with, so that challenge seemed handled.

The next step is to figure out who should be involved in the collaborative part of this process. As always, it’s imperative that any team directly impacted by potential changes should be in the room. With those teams clearly represented, other competencies and perspectives can be loaded in to extend the knowledge available to participants. These people should not all be managers, nor all ground-level employees. A group no larger than 10 should be facilitated (ideally be somebody like me!) through a process designed to help understand needs.


I like to use an activity called “question-storming,” where participants are asked, individually, to brainstorm the 5 most important questions they would ask Team A. In this case, the questions asked should be process-oriented: what information does each team need the others to capture? What systems are they using to communicate? What frustrates them about the way things work today? 

After a time-boxed brainstorm period (no more than 5 minutes), participants share. Over-lapping themes and repeating questions are looked for. Once all of the participants have shared, open up the floor for group discussion. Make sure the representatives of the teams have some input, along the way. Next, dot-vote the questions, and determine the 15 highest priority questions. After one more time-boxed round of open discussion, settle on the top 15. Repeat for Team B (and C, D, etc. as necessary.)

With these questions in mind, select someone to be “the interviewer,” and select a few people from each team to be “interviewees.” In my experience, I’ve found this process works best by holding the actual conversation in a separate room with only the interviewer and interviewee present. Set up a phone bridge so the other participants can listen in on the conversation.

The interviewer should start the interview with something like this, “Hey X, thanks for spending some time with me today. Just to let you know, there are a few other people listening in on our conversation, but they aren’t going to interact with us. They just want to hear your honest thoughts on these questions. I’m going to ask you a few questions, and I think we’ll probably talk for 20 or 25 minutes. Okay?"

As the interview proceeds, the other participants (in the separate room) should be taking notes, gathering insights, thinking up new questions, etc. After each interview, those thoughts should be collected in one place. On a wall is great, and large Post-Its can be used to separate one interviewee’s notes from another. Don’t worry about a deep analysis until all of the interviews from a team are finished.

This isn’t a rigid process, per usual. Each interview *can* inform future interviews, although it’s important to make sure the questions are still *working to capture the same information.* As with all things, consistency is key. Inconsistent questions will yield inconsistent direction, which defeats the purpose of employing this process.

Once interviews are completed, the notes for each person should be discussed and analyzed. Synthesize insights from the collected notes of the participants. Consider using some sort of priority voting (dot- or dollar-, maybe?) just to amplify the really important things that are uncovered. Once insights for individual interviewees are collected, move on to synthesizing notes from each team.


From here, the process needs input from the activities previously performed in order to move forward. Taking the insights from the interviews and creating actionable experiments is a great next step. A discussion about the metrics used to determine the success or failure of this process is appropriate. Mapping the systems being used and where points of friction coincide might be helpful in the short-term.

Ideally, this process will give an organization the information and direction it needs to move forward with removing points of friction between different teams. As I mentioned above, while this anecdote is about a conversation between different teams inside a sales group, it can easily be deployed to gather a better understanding of challenges between any two teams, regardless of the context. How you apply what you learn is another activity on it’s own!

I hope you’ve found this example helpful. If you or your teams wants to see this in action, get in touch and I can teach you how, or facilitate it for you!