Leader, get your team to talk with each other!

Published in

Coach Jose — Leadership and Project Management

6 min readApr 10, 2024

Source: AI-generated by https://copilot.microsoft.com/

The Problem

Leaders make two unspoken assumptions that could seriously jeopardize the leader’s initiative. One of these assumptions is that the team members will talk with each other to resolve coordination issues. The other assumption is the opposite of the previous one. It is that everything the team members need to say and do most go through the leader. Both of these assumptions are wrong! These assumptions lead to situations that many of us are unfortunately familiar with: when we deliver the item, the recipient says “this is not what I wanted” and/or “you are late and have impacted my work!” Or worse yet, “what is this and why do I need it?” Or “where is my widget? I expected it last week!” and this is the first time you hear about it.

Leader’s lack of expertise

My experience is in knowledge work, where the effort (project) depends to a large amount on individuals’ knowledge, expertise, and experience. In these situations, the team members usually know more about their area than the leader. Maybe it’s because team members are recent college graduates with the latest knowledge or, more likely as they work regularly with the technical aspects of the work, they are much more knowledgeable than the leader. So the old expectation that the leader could and would do any team member’s work is invalid. With the current pace of technology change, the leader no longer knows enough to determine all of the tasks and deliverables that would entail building the product.

They don’t talk with each other

But it is also the case that team members tend to work individually and not talk with each other. They are focused on their work and while they may reach out to someone they are dependent on, the reverse, reaching out to someone dependent on them, is less likely.

The leader as a bottleneck

Even if the leader could do the work, they can be a bottleneck to the effort. A while back I was leading the software development aspects for our IT organization to support the company’s first SaaS offering (yes, a while back was over 15 years ago!) I had five project managers leading five different teams. We had developed a plan we regularly updated using Commitment-Based Project Management (CBPM) or Map Days in Intel terminology — see https://www.pmlead.com for details. I met weekly with each of the five project managers and we also met as a team to review and discuss progress.

In one of these weekly team meetings, one of the project managers says “John (name changed) has not delivered what I need.” I was surprised as this had not come up before. So I looked at our tracking sheet and it was obvious that John had not delivered on this item but neither had he committed to delivering it on any specific date as the complaining project manager expected.

So, I turned to the complaining project manager and asked: “Have you spoken with John about your need?” Their response was “no”. I then proceeded to say “John has not committed to a date for this item. So, by definition, he is not late. While this meeting is a good place to raise issues, as we only meet weekly, you waste on average 3.5 days (1/2 of a week) in waiting for the meeting. You, all of you, should reach out to the other project managers who you are dependent on and get agreement and commitment on expectations.” My goal was to eliminate me as a bottleneck and have the project managers talk with each other to resolve any issues. This would save time and miscommunications (“lost in translation” from PM to me to PM).

Getting Team Members to Communicate

How can a leader encourage this communication? Besides stating, possibly multiple times, that it is expected for team members to talk to each other and refusing to take the task of resolving the issue that should be handle by team members directly (See “Management Time: Who’s Got the Monkey?” in the Harvard Business Review Nov. 1999 issue for a detailed explanation). In brief, the concept of “monkey on your back” is that team members tell the leader of an issue, expecting the leader to take it on and resolve it for them. This is a major problem as the team member should be responsible for resolving the issue. If the leader keeps taking on issues, they will end overloaded and not being able to meet all of their own commitments. One of my current clients has this issue and we are working to put steps in place to eliminate this “monkey on your back”. How to do it is a possible topic of a future article.

Another helpful approach is group planning. Many times a team member is unaware of the context. Who depends on their work? Group planning, such as done with CBPM, provides this contextual information to team members. It makes them aware of who is dependent on them, what for and when, and then they commit to each other to deliver the items. Working with a major luxury e-vehicle software development teams using this approach, their QA VP said “…this was the first time that even spoken with each other…” The goal of these planning sessions is not just to come up with a plan, but almost as important if not more important is for the team members to understand the dependencies on each other.

Leveraging the group planning, make the dependency visible to everyone. It is very valuable when a team member has a way to see and remember that they owe something to someone. Unfortunately, many project management tools and approaches do not address this mutual dependency, creating potential problems when something expected by a team member does not fit their expectations or is on time. These tools don’t track who needs what by when as well as the commitment and expected dates. Partially for this reason I have a spreadsheet that makes this very obvious, including turning red when something is late. The first time I used this approach, one of my PMs said to me “no one likes being red.” As this was visible to everyone in the project and even senior managers, it reinforced the need to meet commitments without me having to remind them.

The example below shows the “Need by” information (circled item).

Finally, Contextual Leadership can be instrumental in helping team members work together. Clarifying how the team can best work together and how everyone’s efforts fit together (Coherence subdomain) as well as Focus and Simplify subdomain can be extremely helpful. We as leaders tend to skip over these areas or, at most, just explain it once. It needs to be communicated and reinforced on a regular basis. See my “Why don’t they get it? The need for context in leadership” Medium article. Or head to https://deltaleadership.com for details about Contextual Leadership and the Six Domains of Leadership™ model.

To recap: