Easy in theory, difficult in practice

Having the courage to speak up within a team without fear of social repercussion is a symptom of a higher level of psychological safety. Depending on the context of the complaint it might, in fact, be evidence of Challenger Safety which is the top level of Dr. Timothy R. Clark’s 4 Stages of Psychological Safety model, and is a prerequisite for unleashing the creativity of a team.

Sounds good, right?

But what should we do when one person’s raising of concerns becomes chronic? Left unchecked, such behavior could alienate the individual from the rest of the team as others within the team might not want to have someone bringing them down. If allowed to fester, the individual’s contributions will be criticized or rejected based on how they are perceived by others in the team. Even worse, their regular ranting could become contagious and infect other team members which will bring down the team’s overall morale and productivity.

It would be tempting to jump in and confront the team member, but before directly intervening, seek first to better understand what is going on. Consider their most recent set of complaints and ask yourself the following questions.

• Are their concerns legitimate or are they unfounded?
• Are the concerns they are raising too general or are they very specific?
• Assuming the concerns are both legitimate and specific, has the individual attempted to address them constructively and what has the response to those actions been?
• What are they seeing which you are not?

Once you have gathered this information, look at it objectively, and if you find yourself unable to do so, invite a trusted peer, in confidence, to review the evidence and provide their opinion.

Is your team member a chronic complainer or are they a cursed Cassandra? There are many examples of those unfortunate few who tried to make the many sit up and pay attention only to be persecuted for their efforts and do YOU want to be on the wrong side of history?

Intervene too soon and you will send the message to the individual and the rest of the team that you can’t handle the truth. The next time they feel concerned about something, they will stay silent as they no longer feel safe.

But once you are convinced that intervention is needed, don’t delay. Manfred F. R. Kets de Vries wrote an article for HBR providing guidance on how to do so once you know it is warranted.

Work with a diverse group of people long enough and someone is guaranteed to complain. This is natural human behavior and we want to encourage the healthy expression of concerns, especially if addressing these concerns directly could help to create a better outcome for our customers, our company or society in general.

Whether your team follows a specific framework or has taken a mix-and-match approach with its practices, a tenet of agile is the use of short feedback loops to support inspection and adaptation.

Whether your team sets a regular cadence for external product reviews or they are conducted on a just-in-time basis, it is important to get actionable feedback. But conducting a review is not just a matter of bringing people together.

While there are probably more than just these ways of messing up reviews, here are seven which I’ve witnessed.

1. The only attendee is a Product Owner (or similar role representing the voice of the customer). While we expect that Product Owners are knowledgeable, their feedback is one step removed from that of real external stakeholders. The Product Owner can judge whether the product is meeting needs, but the team loses the benefit of asking questions such as “What new ideas for the product does this feature give you?” or “How could we make this feature add more value to you?“. In addition, Product Owner feedback should be received by the team on (ideally) a daily basis rather than having a special event just for that purpose.
2. Cramming too much into a review and not allowing stakeholders sufficient time to digest what they’ve seen. As teams get better at delivering, they might be able to complete more work in the same amount of time. In such cases, the frequency of external reviews should be increased so the content reviewed is less and the content covered should be organized in some prioritized order.
3. Holding a demo rather than a two-way exchange. If the only purpose of a review is to show what the team has completed, that could be recorded and provided to stakeholders to watch at their leisure. The real value of a review is the rich back and forth discussions which happen between team members and stakeholders and between different stakeholders based on what they are seeing. Using powerful, open-ended questions is one way to ensure that the knowledge sharing doesn’t just happen in one direction.
4. Having the wrong people in the review. It is almost as bad to have the wrong external stakeholders in the room as it is to have none. If personas are being used to facilitate requirements discovery, there should be representation for each persona if the content of what’s being reviewed impacts them. And because a review is a working session and not just a forum for sharing information, we don’t want to have too many people in the room either.
5. Making commitments during the review. It can be tempting for a team member or the Product Owner to try to curry favor from a powerful external stakeholder by committing to a specific product change or to a release date, but this is not the right forum for it. Desired content and target dates can be captured but the Product Owner and team should take the time to understand the impacts of such changes.
6. Open criticism of the team’s work. It is natural for an external stakeholder to get frustrated if their expectations weren’t met for the content being reviewed. Such feedback is crucial to help the team improve over time. But if that criticism is provided in an abusive manner, the team’s morale and productivity will take a hit.
7. Not taking sufficient time to analyze what was learned during a review. If we are using up valuable stakeholder time, it behooves us to use their feedback well. It might be convenient to hold a retrospective or similar event immediately after a review but this might not allow the team and Product Owner the time required to properly digest the feedback they received.

Well-run reviews are a key ingredient of building the right product for our customers, so avoiding these seven sins will go a long way to getting real value out of these critical events.

HBR published an article this week on how leaders can help their teams to recover quicker from disruptions. Given the events of the past year, this topic is apropos and is likely to remain so for the foreseeable future.

In the article, the author introduces the concept of collective self-healing at the team level drawing upon observations of how ant and other social insect colonies respond to major upheavals. She identifies three characteristics which enable teams to become more resilient:

• The ability for a task to be completed by more than one person on the team even if that activity is not within their normal responsibilities. A team of generalizing specialists would satisfy this requirement, but even a team of specialists can behave in this manner if there is support for them to take on different responsibilities when the situation demands it and if they are willing and have confidence in their ability to learn new skills.
• The ability to operate efficiently with distributed leadership. Who leads depends on the needs of the moment and when the context has changed such that someone else on the team is better equipped to lead, that person steps in. This is a characteristic of mature teams where the lead role is not associated with only one member of the team.
• Sufficient self-awareness to know when they need assistance and the humility to seek that help in a timely manner without letting the fear of loss of social capital get in the way. Not only does this allay the fears of stakeholders that the team is hiding the true status of a situation but it also reduces the likelihood of major impacts which can occur if a problem is allowed to fester.

The author closes with three questions which leadership teams should ask themselves to determine whether they have the right system in place (e.g. values, policies & processes, roles and measures) to support the realization of these team attributes.

But one prerequisite which is not specifically referenced in the article is psychological safety.

When team members don’t feel safe, they will prioritize their own safety over that of the team. They will be less willing to take on unfamiliar responsibilities due to the fear of blowback if they fail. Even if they are the best person to lead the team in a given situation they will be less likely to do so for the same reasons or because they are worried about how others in the team will perceive or treat them. And they will avoid asking for help in a proactive manner since they won’t want to appear vulnerable within the team.

Just as it is for creating high-performing teams, psychological safety is an underpinning for creating resilient teams which are able to handle the vicissitudes of delivering during turbulent times. So the number one question which leaders should be asking themselves is “Have we cultivated sufficient safety within our teams?“

When we think of mythical heroes, they possess such traits as:

• Showing confidence in the face of overwhelming challenges
• Demonstrating a lack of vulnerability even though most heroes have their own “Achilles’ heels”
• Being able to inspire others based on what they were able to achieve but not always how they achieved it

I wrote an article a few years ago about the issues with an organizational hero culture including:

• A lack of recognition for the teams and individuals who deliver results without needing to resort to heroics
• The potential for so-called heroes to create crises when none exist to maintain their hero status or to stroke their egos
• The increased likelihood that luck will run out when a hero fails as other countermeasures might not have been instituted to guard against risk realization

Fear of failure or ridicule isn’t a concern for those lucky few who are anointed as heroes. When they fail, the goodwill they have built up based on their past heroics is usually more than enough to protect their social status.

You might think that this would encourage their followers to also take calculated risks. But if an “average Joe” tries something and it fails, would they receive the same support or benefit of doubt as a hero? If not, the hero culture might cause other staff to feel less safe to experiment.

A hero might also inspire their followers to blindly trust them.

While this trust might be needed in exceptional crises, it might also cause others to be less likely to confront the heroes if they witness them doing something wrong. Combine that reluctance with the backlash that whistleblowers could receive from other followers for challenging their heroes and it increases the likelihood that a hero could get away with bad behavior.

A hero’s (apparent) lack of vulnerability is also a cause for concern.

If they are unwilling to say when they don’t know or are afraid of something, those who look up to them may be tempted to behave in the same manner. And that can cause issues to arise which wouldn’t have if assumptions and knowledge gaps had been surfaced in a more open, timely manner.

Finally, a hero culture can be divisive as it naturally generates an “us and them” state. Dr. Timothy R. Clark identifies Inclusion Safety as the foundation of his four stage model on psychological safety as without inclusiveness you can’t unleash the power of diversity. It is hard to be fully inclusive when a subset of the organization is placed on a pedestal.

Leaders are expected to be force multipliers. If a hero can help others to behave and be treated like they are, that’s wonderful. But that won’t happen by itself.

“What if you could have that power… now? In every generation, one Slayer is born… because a bunch of men who died thousands of years ago made up that rule. They were powerful men. This woman is more powerful than all of them combined. So I say we change the rule. I say my power… should be our power.” – Buffy the Vampire Slayer

A project manager asked me a question which I’ve frequently been posed over my career.

How should I deal with a stakeholder who, when I provide a rough order of magnitude ranged estimate early in the life of a project, insists on holding me accountable to the lower end of that range later on even when sufficient evidence has emerged to contradict that value?

The question clearly states that a range of values was provided and no commitment was made. And yet, the behavior of the stakeholder was the same as if a single point, firm fixed estimate had been given.

Anchoring and confirmation biases can partially explain why this happens, but this provides little assistance to a project manager who is asked to provide an estimate at the beginning of a project.

But even if more than 50% of the project scope has been delivered, we might still be unable to provide an accurate estimate.

We learn that a simple way of calculating Estimate At Completion for a project is to base it on past performance but how often is that the case in reality? To provide an accurate forecast, we would need a delivery process which is in control, and yet, most of the time we may have limited influence over factors which could cause a predictive model to break down.

If we don’t have reliable availability of people, regardless of which delivery approach we use, we won’t be able to predict when we will be finished until all scope has been delivered. Metrics such as velocity, throughput or average work item age are as helpful as a magic eight ball under such conditions. Ensuring that everyone is available when needed is not impossible, but it is difficult to achieve when delivery commitments are made without taking an organization’s ability to deliver into consideration.

But even with dedicated staffing, unless the level of uncertainty associated with the remaining work is less than or equal to what the team has experienced to date, past history won’t be indicative of future performance. Risk management helps by encouraging a team to address high severity threats as early as possible, but that assumes that they are able to identify key threats. The more complex a project, the greater the difficulty in doing so. All it takes is the realization of one particularly nasty unknown-unknown to invalidate a high confidence estimate. Contingency and management reserves provide a degree of shock absorption but on extremely complex projects, the tail of the poor outcomes is long indeed.

A container ship got stuck sideways in the Suez Canal this Tuesday. It is not the first time such a shipping issue has occurred yet four days later no one is able to provide an accurate estimate as to how quickly the the canal will be unblocked.

If you are managing a project which is unlike any other, why would you expect to be able to do any better at forecasting when you will be done? #NoEstimates might not be acceptable to many stakeholders, but it might be the most responsible answer in some circumstances.