Easy in theory, difficult in practice

I'm always happy to learn something new when it relates to the topics which interest me and even more so when it is something which I should have run across long ago. During an event this week, a participant shared that their secret facilitation power is holding space for the participants. I must have been living under a rock for the past three decades as I'd never heard of this term even though it is a core component of the Open Space approach which has had significant influence in the broader agile community.

When holding space was first described to me, it sounded almost identical to creating psychological safety within a team but after reading further I feel that there is an overlap between the two approaches rather than an equivalency.

While there is no single accepted definition for holding space, here are two frequently referenced ones which helped me better understand the concept:

• Heather Plett: "It means that we are willing to walk alongside another person in whatever journey they’re on without judging them, making them feel inadequate, trying to fix them, or trying to impact the outcome. When we hold space for other people, we open our hearts, offer unconditional support, and let go of judgement and control."
• Adam Brady: "Holding space is a conscious act of being present, open, allowing, and protective of what another needs in each moment."

What are some of the similarities between the two concepts?

• Not judging or ridiculing others
• Providing an environment where people feel safe to take risks even though they know that there is a chance that they might fail
• Enabling team members to express vulnerability or to allow their emotions to surface
• Being inclusive of others' diversity of opinion
• Giving others the respect of our full attention when they are communicating
• Demonstrating genuine compassion with others

But there appear to be a few differences too, including:

• Holding space applies applies to oneself as much as it can be applied to a team as it is difficult to hold space for others if we haven't done the same for ourselves. Psychological safety is normally considered as a team characteristic.
• When we are part of teams which are operating at higher levels of psychologically safety we are more likely to provide candid constructive feedback to other team members in a timely, direct but empathetic manner. This does not appear to be explicitly covered within holding space.
• In "Open Space Technology: A User's Guide", Harrison Owen writes "As the world would see it, the ultimate facilitator will do nothing and remain invisible". Ego is taken out of the equation. While this is important when one facilitates an event, psychological safety doesn't require that team members bury their egos, just that they should be mindful of them when they interact with one other.

Our abilities to hold space and to create psychologically safe environments are complementary but are both equally critical to becoming effective leaders.

If you have ever taken a course in project management, you may have learned the differences between contingency and management reserves. The former are used to protect project cost or schedule objectives from the impacts of identified, realized risks whereas the latter are used to address the impacts of unidentified risks. Project managers usually have the authority to utilize contingency reserves as identified risks are realized whereas they would normally seek approval from a higher authority such as a steering committee to use management reserves.

A challenging task faced by many project managers is defending contingency reserve amounts their teams have estimated are required for their projects. Sponsors or customers might understandably be hesitant to tie valuable funds up for events which may not occur as this represents unwanted opportunity costs. Some stakeholders might even be reluctant to think that things might go wrong with their projects. Expected monetary value can be used as part of quantitative risk analysis to justify reserves but that might not be enough to convince stakeholders who don't see the rationale in putting anything aside for contingency.

In such cases, educating them on why contingency reserves are important by using stories might work.

Ask the stakeholder if they own a home and whether they put any money aside each year for maintenance. Most folks would likely say that they do. Ask them why they do that. They'd likely say it is to avoid their having to cut planned expenses from discretionary accounts when they need to do some repairs or replacements in their homes over the course of the year.

Ask them if they own a car. If they do, ask them why they pay for car insurance. They'd would likely answer that it is to save them from significant repair or liability charges if they get into an accident or if their car gets stolen. Ask them what would happen if they didn't have insurance and as a result of an accident they needed more money than they could easily free up. They'd likely answer that they'd have to go to their bank and ask for a loan.

Finally, ask if they have teenage kids and if they give those kids a weekly allowance to pay for discretionary purchases. If they do, ask them how they react when their kids spend all of their weekly allowance and have to come to them for more money because they want to buy something.

Management reserves are the equivalent of having to go to our parents or our bank for loans or liquidating other other investments when risks get realized. It is bad enough when we have to request them to protect us from the impacts of unknown unknowns but even worse when they get used for identified, realized risks because we were unable or unwilling to secure contingency reserves.

Contingency reserves should not be considered a nice-to-have expense when budgeting for your projects. Securing them is the responsible thing to do to deal with the uncertainties which are always present when delivering projects.

In 2015 I wrote an article intending to debunk some common myths about project management. Like many of you, I spent a reasonable amount of time during my first few years participating in online forums correcting agile misconceptions. Unfortunately, just like lopping heads off the Hydra, every time I'd address one myth, a short time later it would re-emerge. Recognizing the futility of trying to permanently suppress fallacies, I stopped responding to such discussions. However, as I would still like to help, writing an article on five of the most common agile myths will give me a reference to provide to folks in the future.

Agile projects and agile methodologies

There's no such thing. You can have projects which get delivered by teams using an adaptive life cycle or in which the team elects to use certain agile tools and techniques but unless the project itself is suddenly going to become sentient, it can't be agile. Agile is not a method (which is what most folks mean when they use the word "methodology"). A team or a company can create a delivery method based on agile values, principles and practices but that is just a single instance of an infinite variety of ways of delivering projects.

We need to do agile

Agile is an adjective, not a noun. Becoming (more) agile should also never be the goal of a team or organization but rather a means to achieving one or more goals. Make it a goal unto itself and the downstream impacts might result in worse outcomes than your current state.

Agile started with the Manifesto

The Manifesto for Agile Software Development is a curation of specific software delivery values and principles. None of these values and principles were revolutionary or novel in 2001 as they had all been identified before in one body of knowledge or another. Concepts, tools and techniques associated with agile have been used for decades and many popular delivery frameworks such as Scrum and XP were published before the Manifesto was written.

To be agile, you must be/have/do "X"

Whether it is sprints, story points, user stories, product owners, servant leadership or any one of a myriad of other roles, tools, techniques and buzz words, the agile community has become really efficient at dividing and conquering itself. Being agile needs to be assessed by outcomes and not merely by how those outcomes were achieved otherwise you risk sliding down the slippery slope to cargo cult.

Agile delivery is better (or worse) than waterfall

Context counts. There is a wide range of possible life cycle choices from fully adaptive to full predictive and very few projects fit cleanly at one end or another of the spectrum. Profiling a project to learn where it falls along this continuum is a critical step for teams to take when tailoring their approach to find better ways of delivering that specific project.

Any others I've missed? Feel free to respond in the comments and I'll add them to the list!

Harvard Business Review published an article this week about how boards can prepare for unexpected calamities such as pandemics, natural disasters or cyber-attacks. The authors provided a three-pronged approach for dealing with both true black swan events as well as the more common black elephants (a low probability significant threat which leaders are aware of but don't wish to address proactively). While the strategies provided apply to board members who are looking after the health of their companies, after reading the article I felt they could be adapted to apply to projects as well.

Boards play a key governance role in the successful running of companies. Steering committees play a similar role when it comes to projects. A common mandate for a steering committee is to help guide projects in the right direction by providing ongoing support to the sponsor and project manager. Some steering committees merely play an advisory function whereas others might be more directive. If the sponsor or key risk owners are ignoring looming threats, the steering committee could push them to do more and can encourage these stakeholders to take a more proactive stance. Steering committees can ask these stakeholders the tough questions which project managers or team members might be afraid to ask. To do this, committees need to be staffed with a diverse group of leaders.

Boards are often actively involved in the succession planning process for leadership positions, helping to cue up the best candidates for key leadership roles. Executive teams can play a similar role with projects by identifying who possesses the right risk appetite to be the best sponsor for a project. They can also plan for the future by creating leadership development programs incorporating effective risk management lessons. And, capacity permitting, they can act as mentors for senior stakeholders on critical projects, helping those leaders to plan for the threats they'd rather not think about.

The article also recommends that boards can design or adjust leadership compensation programs to compensate leaders for taking steps which will protect the company from unplanned disruptions. These programs can also be tuned to penalize leaders who prioritize personal short term gains over long term organizational resilience. The same ideas can be used when defining performance plans for sponsors and other key senior project stakeholders. Incorporating project success within the performance plans for these leaders is a good start, but ensuring that the measures also assess how the leaders are going about ensuring success and what they are actively doing to protect against threats is equally important.

The authors close the article by reminding us that building up organizational resilience is a long game. If senior leaders fail to plan for black swans and elephants they will plan to fail when those are realized.

Following a presentation I gave this week on how project managers can cultivate psychological safety within their teams, an attendee asked me to what the relationship is between psychological safety and emotional intelligence (EI). After answering her I felt it was worth writing about it.

EI is normally considered to be a personal trait although it is possible to claim that one group of people has a higher degree of EI than another. Psychological safety is usually defined in the context of a team as it wouldn't make sense to assess the level of psychological safety of an individual unless they are suffering from multiple split personalities! It would be difficult to assess psychological safety for an overall organization as companies are normally composed of multiple overlapping teams. However, it is possible to assess if the executive team is committed to building a team culture of high psychological safety within the divisions which they lead.

One model for EI uses the following four attributes: self-management, self-awareness, social awareness & relationship management.

How do these traits help a team to become psychologically safe?

Team members who are effective at self-managing and are self-aware will be better equipped to handle actions, comments or behaviors from their team members which they take exception to. They know what their own strengths are but they also understand their weaknesses which means that they are more likely to say when they don't know something, are making an assumption or need assistance from someone else on the team. They have self-confidence which means they are comfortable with experimenting and not feeling that a failed experiment reflects poorly on their abilities.

Social awareness and relationship management relate to how much empathy we demonstrate towards others and to our ability to work well in a team as both a contributor and a leader. Having higher levels of these characteristics means that individuals will be better at picking up on the discomfort of their peers and can help those who are silent to find a voice. It also means that they will be more effective at resolving conflicts which could mean interceding on behalf of a team member if they are being persecuted.

So it seems like a reasonable assumption that on those teams where the members exhibit higher levels of emotional intelligence they are likely to become psychologically safe quicker than others.

But is there an inverse relationship as well?

It is difficult to effectively improve one's emotional intelligence without receiving coaching and support from those whose feedback we trust. In psychologically safe teams, team members feel safer providing feedback with radical candor to their peers. As such, I'd assert that psychological safety can act as an accelerator for increasing the overall emotional intelligence of the members of a team.

A rising tide lifts all boats!