Easy in theory, difficult in practice

In a previous article I presented a three step model for building psychological safety within your team. The second step is that you as a project manager, team lead or functional manager need to live it every day.

Simple actions go a long way towards creating safety.

After a meeting, if you noticed that certain team members were quiet during the discussion of key decisions, seek them out and create a safe space for them to have a candid conversation with you to share any concerns they had.

When you make a mistake don't get defensive about it. Acknowledge it publicly within your team and apologize. When you don't know something, say you don't know. If you are making an assumption about something, make it clear to your team members that you are encouraging them to challenge your assumptions.

Don't be a superhero. Pulling off the occasional miracle is one thing, but if you frequently engage in heroics you may be conditioning your team members to have too much confidence that those in authority can walk on water. To counteract such perceptions, be vulnerable but in an authentic manner. False humility becomes irritating over time, but being aware of your own limitations and sharing those with team members will make them more likely to do the same with you and with each other.

Get outside your comfort zone. Every once in a while, learn something new or try activities which are not your expertise. Not only will this help you grow, it shows your team that it is safe to experiment and if things don't work out, there's no social damage done.

Actively listen when communicating with your team members. If you are multitasking or otherwise not fully present when speaking with them, not only won't you pick up on cues indicating that something may be wrong, you are also showing disrespect towards them.

Be mindful when receiving bad news, not just of how you respond, but of your body language and tone of voice. While it is perfectly natural to be annoyed or concerned when an issue occurs, your reaction to it will determine how likely it is that you will receive such information in the future. If the news is particularly troubling, thank your team member for bringing it to your attention and ask them for a little time for you to process it properly rather than shooting the messenger.

Pay attention to any micro-aggressions or ridiculing comments you might be making. What you feel is an innocent remark in a meeting might make a team member feel unsafe or insecure. Actively solicit feedback from individual team members afterwards if you aren't sure whether what you said was received the way you intended.

When staff complain about their work environment being toxic, the fault often lies with those managers who at are unwilling to address bad behaviors of their team members or worse, actively encourage or even participate in those. Leaders must model the behavior they expect to see from their team members and this is doubly important when it comes to building a safe working space.

After I had finished presenting on how to build psychologically safe virtual teams at a conference earlier this week, one of the delegates asked me what suggestions I'd have to help her with a team where some of the members refused to turn their cameras on during video meetings.

I'm not going to challenge the reasons as to why some team members might be reluctant about being on camera. Even if a team has developed ground rules encouraging everyone to use their web cameras, such working agreements need to evolve as the team's culture evolves.

Faced with this, team members who are willing to turn their cameras on would have an advantage when compared against their "anti-camera" peers as their body language will be visible to the facilitator and to the other meeting participants. If they seem to be uncomfortable about a topic, someone else is likely to notice and might either openly or using a one-on-one chat ask them to share their concerns.

But in the case of those team members who choose not to have their videos on choose to remain silent, it will be difficult for others to determine their status without regularly pinging them during a meeting.

Let's assume that you've already had one-on-one conversations with each team member to understand why they are unwilling to be on camera and the underlying causes are not ones which need to be resolved.

If the team is already at a high level of psychological safety, this is not a major issue. If a team member who isn't on camera has concerns with what is being discussed, they will raise it without fear of ridicule or social stigma.

But if your team has just formed or you are only seeing a few signs of nascent psychological safety, here are a few suggestions on reducing safety risks.

• At the start of the meeting, remind the participants as to how important it is for everyone to speak up if they feel concerned about something being discussed. Let them know that if they are not comfortable doing so that they can contact you directly either during or immediately after the meeting.
• Actively listen to the "anti-camera" participants. They might not speak what's on their mind, but they might sigh or you might hear them mutter under their breaths. Being conscious of this would give you an opening to call on them to share their concerns.
• Poll participants regularly about how they feel, especially after a potentially controversial topic has been discussed. Most video conference platforms support anonymous polling and you can use questions such as "On a scale from 1-5 where 1 is least comfortable, how do you feel about what we have just discussed?". If even one person indicates that they are uncomfortable, you could follow up after the meeting using one-on-one meetings if you have a small team or with an anonymous survey to try to get more details.
• If you are using a virtual collaboration platform such as Miro or Mural where a collaborator cursor is visible, construct a "live" barometer by using shapes or images representing different levels of comfort and ask participants to move their cursors over those shapes which best represent their current state of mind regarding the topic being discussed.

It is almost a year since the pandemic started, and "Zoom fatigue" has become a real issue for many workers. Generous internet bandwidth speeds are still a luxury in many parts of the world, and with many family members working or studying remotely within the same household, it might not always be possible to stream quality, latency-free video.

Building teams in such contexts might be harder, but with focus and creativity you can reduce the risks of out of sight, out of safety!

I've delivered a number of presentations this year on the importance of building psychological safety within project teams and the role which project managers play. During these presentations I'm frequently asked the question "How do I go about creating it?". While there are existing models such as Timothy R. Clark's progressive four stage model, a simple three step approach which I support is to Plan It, Live It and Champion It. I will cover these steps within my upcoming articles.

Planning for safety starts even before the project formally kicks off. Once you have been assigned as the project manager, meet with the key stakeholders who will have frequent interactions with your team members and get their commitment to developing and sustaining a safe environment. It is quite likely that some of them may not be familiar with psychological safety and this will present you with an opportunity to educate them on its importance. At a minimum, this should include the customer, the project sponsor and the functional managers who will be supplying the team members for your project.

When you meet with your project sponsor to establish mutual expectations you have another opportunity to confirm that they will commit to acting as a champion by supporting you if you are encountering challenges with ridiculing or criticizing behavior of a senior stakeholder.

When team members are assigned to the project, it is a good practice for you to help them define the starting set of working agreements for how they will interact with one another. Highlight the importance of safety within this session and get their commitment towards building it within the team. Help them to discover specific actions, rituals or practices which will support safety and to identify behaviors which will hurt it. When new team members join midstream, review the topic of safety with them as part of their onboarding.

Psychological safety planning should also be part of your preparation for any event where key decisions will be made. One way to make it safe for your team members to voice concerns or dissenting opinions is by asking for a volunteer to act as devil's advocate during the event. Communicate to everyone participating in the event that the role of this volunteer is to reduce delivery risk by raising concerns and that they are not just being difficult.

Kick-off meetings provide another opportunity to communicate the importance of safety. If the kick-off meeting is at the start of a new phase, share examples of those actions or behaviors which contributed to safety over the previous phase as well as those which hurt it.

Without planning for team psychological safety, “A goal without a plan is just a wish.” ― Antoine de Saint-Exupéry

Harvard Business Review published an article by Sabina Nawaz this week on some challenges managers face when they delegate work to their staff. The gaps identified with team members being able to perform the tasks successfully included a lack of critical thinking, a lack of initiative, a lack of quality and a lack of speed.

While these are valid concerns, some times the issue is that we avoid delegating activities to team members. This might be a valid response if the outcomes from past delegations were bad but past poor performance could be addressed by the guidance provided in the HBR article. But some times we might not have even tried to delegate work which could have been successfully performed by our team members.

What might cause this reluctance?

While there might be many causes, one of the more compelling ones is the fear of the negative impacts on us when delegated work is not completed successfully. We could play it safe and choose to only delegate rote tasks, thus guaranteeing that there will never be a failure. Unfortunately that eliminates one of the key benefits to a delegee of taking on work which is their personal growth.

When we choose to delegate work to our team members which they have not performed in the past, we are testing a hypothesis that they should be capable of doing so. We hope that with our support and that of their peers they will be able to successfully complete the work within acceptable time or quality constraints but there are no guarantees of this.

If our manager has cultivated a culture of psychological safety within their teams, we probably won't worry too much about the personal impacts of delegated task failure, so long as there was a reasonable likelihood of success in our team members performing the work and the stakes are not so high that we needed the buy-in of our manager to delegate the work.

But if our manager doesn't take bad news well, prefers to play it safe, or encourages unhealthy competition and ridicule within their teams, we will think twice about delegating challenging work. We will prioritize our short term safety over the long term benefits of developing our team members. And this in turn will reduce their intrinsic motivation which increases the risk that we will lose some of our best staff.

We are responsible for creating psychological safety within our own teams but if our manager doesn't act the same way the impacts of that will cascade down. And if safety isn't prioritized at the top of the company, the resulting snowball effect might hurt the entire organization.

While there are many cases where we might have to use our powers of influence and persuasion to sell stakeholders on supporting what we feel is the right thing, I thought I'd share three specific examples which might be a much harder sell than usual.

While Fred Brooks wrote that "Adding manpower to a late software project makes it later" in his book, The Mythical Man-Month, in most cases this applies to any industry or domain.

Does it always hold true? Not if the project just got started and there's sufficient time before a key milestone to make up for the onboarding costs of adding team members. It also won't apply if your project was understaffed from beginning and by adding team members you will bring staffing up to an optimal level.

But in many cases, the recognition that a project is critically late and sufficient motivation to take action occurs late enough in the life of the project that the Law does apply.

But try convincing a customer or sponsor that throwing more people at the problem isn't the right thing to do? It is, after all, the second easiest way for senior stakeholders to demonstrate that they are doing "something" to help out (the first being to replace the project manager whether or not they were responsible for the delays!). Reducing scope might be a much safer approach, but if the choice is to give something up or add team members to get what they had originally asked for, stakeholders are likely to push for the latter.

Which leads to my second example - project sunk costs. If I had received a dollar for every time I heard a senior stakeholder exclaim "Well we've spent $X so far on the project, so it doesn't make sense to pull the plug now", I would be a rich man. I've even run across some project finance analysts who are well trained in the correct treatment of sunk costs to be guilty of this sin.

As a project manager, your responsibility is not to deliver the project, damn the consequences. It is to increase the odds that the expected business outcomes can be achieved through your project's delivery and if this is no longer possible, to convince decision-makers that the best action they take might be to cancel the project to avoid throwing further good money after bad.

Finally, let's consider changes. When a change is identified, the usual expectation is to request our team members to analyze it so that decision makers can decide whether to accept it or not.

But what happens when the project is late and you'd like your team members to remain focused on delivering the approved scope? In such cases, it might make more sense to have someone (you, the sponsor or customer) filter all change requests before the team even looks at them to ensure that only "must do" changes get analyzed.

But if your stakeholders have become accustomed to the normal approach, this might be a hard sell.

Good judgment is a key trait for project managers. But merely possessing good judgment is useless unless we are able to convince others of the merit of what we are proposing so that they accept our recommendations. And when projects are in trouble, this might get harder than usual.