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!
It would be an understatement to say that project managers have had to deal with a lot of change this year. Projects have had their budgets vastly reduced or been cancelled outright, and remote work has become the norm rather than the exception. We are still far from the end of the pandemic, but in those areas where they have successfully flattened their first waves, some companies are starting to encourage their staff to return to the office.
For PMs who now have to adjust to being in the office with their team members, things are not as simple as winding the clock back a half-year or so. They will face a number of challenges including:
So how can a PM prepare for the transition and what should they do once they get back?
When the pandemic hit, many project teams were caught off guard. Project managers should heed the adage "Fool me once, shame on you. Fool me twice, shame on me".
If a survey of teams was conducted to find out what they hated the most about working on projects, governance is likely to rank fairly high. Ask a group of project managers working for a large organization the same question and governance is likely to receive the most votes. This is because most governance approaches are or at least perceived as being onerous and viewed as barriers rather than enablers to getting work done.
Have a theoretical conversation with project managers about governance and they won't argue about its importance unless they are anarchists. Governance keeps both individuals and the organization safe and ensures that resources get used in a responsible manner. The issue lies not with governance itself but with its implementation.
An approach I've supported in the past has been for governance leaders to effectively educate delivery teams on the control objectives which need to be satisfied but then leave it to teams to figure out how to meet those objectives. The challenge with this approach is that if teams feel under pressure to deliver (and tell me the last time you were on a team which didn't feel such pressure!), without simultaneous emphasis on achieving control objectives, those might get ignored. The project manager can try to act as the conscience of the team, but by doing so they might lose the respect of their team, or worse, the full burden of satisfying governance requirements might fall on them.
A different approach might be to leverage nudge theory.
Wikipedia provides the following overview (I have highlighted in bold the two most common approaches for implementing project governance): "Nudge is a concept in behavioral economics, political theory, and behavioral sciences which proposes positive reinforcement and indirect suggestions as ways to influence the behavior and decision making of groups or individuals. Nudging contrasts with other ways to achieve compliance, such as education, legislation or enforcement.". Later in the same page the authors state "A nudge makes it more likely that an individual will make a particular choice, or behave in a particular way, by altering the environment so that automatic cognitive processes are triggered to favour the desired outcome."
One example which many travelers have probably experienced is how bed linens get changed in a multi-day hotel stay. A number of hotel chains have adopted the practice of using a card which the guest needs to place on the bed to signal the housekeeper to change the linens. In the absence of this card, the housekeeper's default behavior is to make the bed with the existing linens, thus reducing the environmental impacts of unnecessary washing.
When introducing nudges there are a few principles to think about:
So what nudges can YOU come up with which might satisfy the governance requirements faced by your team?
In 2013 I wrote an article about the advantages and disadvantages of contract project managers.
Competent agile coaches have been in high demand for many years due to the large number of companies across multiple industries who are going through agile transformations.
Scrum asserts that the role of the Scrum Master includes coaching activities and this is fair in small contexts, but in larger organizations early in their journeys to greater agility, a Scrum Master is likely to find they have limited capacity to effectively coach stakeholders beyond members of the development team and Product Owner.
In such situations, a delivery team might try hard to be more agile, but functional managers, executives and other internal and external stakeholders might not be supportive of this transition. Applying Theory of Constraints principles to this situation, a coach would want to identify the primary bottleneck and focus their efforts there.
But should you hire them full-time or on contract?
While all the considerations from my earlier article apply to the role of an agile coach, here are a few more which should be considered before making any decisions.
While an agile coach is not mandatory, the support a good coach provides can accelerate the journey through an agile transformation. The best choice for many companies might be to staff a combination of full and contract coaches to make the journey as pleasant as possible.
Over the past couple of years I have regularly heard companies, their portfolios and even individual projects referred to as Complex Adaptive Systems (CAS). With a CAS, understanding of the individual components does not convey an understanding of the whole, and reductionist thinking which can work so well with simple or even complicated systems is of limited use.
Given this, I felt it was somewhat timely when I was invited to review Jonathan Sapir's new book, Thriving at the Edge of Chaos - Managing Projects as Complex Adaptive Systems.
In the first half of the book, Jonathan does a good job of covering the challenges we face when trying to apply traditional planning approaches to complex projects. His differentiation between complicated and complex contexts, the importance of systems thinking and his walk through of the Cynefin framework make these sections a good primer on the subject.
Whether it is Ian Malcolm's quote about non-linearity from Jurassic Park, the old joke about the drunk looking for his keys around a lamp post, or the analogy of a fence and treats for a dog as examples of boundaries and attractors, Jonathan provides many quotes, analogies and examples which all help to make a complex (no pun intended) topic approachable for most readers.
A number of the principles he covers in the first half of the book will resonate with both agilists and anti-fragilists including:
I liked his guidance that operating at the edge of chaos is where modern organizations should strive to be as excessive control leads to paralysis and eventual obsolescence whereas a lack of any guardrails will often result in chaos. Uber is frequently referenced in the book as almost a "poster child" for living on the edge, but I found the inclusion of Cemex and how they overcame the challenges they were facing in a traditional industry more appealing to me given that the majority of organizations are not founded to disrupt an existing business model.
The second half of the book covers Dr. Eli Goldratt's Theory of Constraints (ToC) and focuses heavily on its application in Critical Chain Project Management (CCPM).
While CCPM provides good solutions for dealing with common scheduling issues, I did feel that the book could have delved deeper in terms of applying ToC and other models to addressing some of the non-scheduling concerns caused by CAS. There could have also been some guidance provided for leaders who face the challenge where there are multiple resources who are all equally constrained. ToC works well when there is a single bottleneck but with multiple equivalent bottlenecks what should we do?
The following qualifier from the Introduction also raised some concerns: "This book applies primarily to repetitive, as opposed to one-off, never-to-be-done-again projects. It does not apply to software development projects that use agile methodology." I would argue that some of the most complex projects we have to deliver are highly unique. Also, while many of the ideas shared by Jonathan are already incorporated in agile methods, these approaches haven't fully solved CAS challenges and the book could have addressed those.
If we accept that complexity is going to continue to increase in delivery, Jonathan's book provides a solid grounding on the subject and I hope that a future revision will address some of the opportunities I've raised.