Psychological Safety: The Mythical Man Month

Welcome to the psychological safety newsletter and thanks for subscribing. You are amazing. This week discusses “The Mythical Man Month”, agile software development, reframing risk, and psychological safety at Splunk.

The Mythical Man Month

Thanks to Amy Edmondson for the signpost to this tweet from George Orosz, who describes the damage that can be done when managers don’t trust in their team, or don’t understand the difference between “I’m updating you” and “I’m asking for help“.
 

The book George is highlighting here is called “The Mythical Man Month“, a fantastic selection of essays on software engineering by Fred Brooks, written in 1975. Brooks describes in one essay “Why did the Tower of Babel Fall” the pitfalls of poor communication and organisation in software projects. In another, “Aristocracy, Democracy and System Design“, he highlights the power of enabling constraints in software development (specifically architectural constraints) and quotes the artist’s aphorism “form is liberating“. Form gives the artist direction and relieves them of the oppression of infinite choices. 

Of course, the essay that the book is named after, “The Mythical Man Month” is now infamous in the technology world, in particular for coining what is now known as Brooks’ Law: “Adding manpower to a late software project makes it later.” This “law” is in part a result of team size and communication complexity that shows how communication becomes exponentially more difficult as more people are added to the group (unless we mitigate the effect with practices, tools, or segmentation):

And I suspect it’s also related to the effect of how wait time increases exponentially as utilisation increases: as people (or systems) become increasingly utilised, the likelihood of finding that resource free and able to be interrupted for a task decreases exponentially (thus wait time increases). People working on a late project are likely to be working at close to 100% capacity, with no buffer time to deal with unexpected or unplanned work – creating further cascading delays and the project goes into a death spiral.
 

In large part, Brooks’ Law is related to the J curve that we discussed a few weeks ago, which shows us how any change (even a beneficial change) will initially slow us down. We need to learn and adapt to new systems, new practices, knowledge or people. Folks joining a new team take time to on-board, and that requires time and effort from existing team members as well. I suspect that psychological safety has a huge part to play in this process, and mediates how quickly the team can adapt to change.

A number of mitigations exist for Brooks’ Law, such as having comprehensive, easily consumable documentation, plans, tools and processes, which is much easier said than done in most cases, especially once a project is already late and “extras” such as documentation tend to be deprioritised in favour of key deliverables.

Other ways include adding people to a project *before* it’s late (although this approach requires seeing into the future to anticipate a late project before it happens), or only adding people to highly transactional, simple, rapidly on-boarded tasks (and these are likely to be better automated by machine instead). Probably the most effective solution is the effective segmentation and decoupling of the work using design patterns and fracture planes, but this requires expert knowledge of *how* to segment the work, and is very difficult to retrofit onto an already-late project.

One way that I’ve never tried, but I’d very much like to (assuming I can be on the removed team!), is the “Bermuda Plan”, where the majority of the team are sent away (presumably to Bermuda) and the remaining, much smaller, team are left to deliver the work on time. Good luck with that 😀
 

The Mythical Man Month is well worth a read if you’re involved in software engineering, project management, or similar. You can read a pdf of the “Mythical Man Month” essay here.


I feel compelled to note the sexist language in the book – starting at the title itself, the book assumes all people working on a project are men, and Brooks never uses a female pronoun, ever, in his essays. The only time the word “woman” is used in the book is in this sentence: “The bearing of a child takes nine months, no matter how many women are assigned.” (which can be an effective metaphor for task concurrency in projects) but I’d love to read a new version of this book that wasn’t quite so misogynist!

This newsletter is sponsored by Conflux.

Conflux is the leading business consultancy worldwide helping organisations to navigate fast flow in software. We help organisations to adopt and sustain proven, modern practices for delivering software rapidly and safely.

Many organisations today are stuck using ways of working from a bygone age. In this article, Sophie Weston, Principal at Conflux, takes a look at why knowledge work needs a new approach in which psychological safety is a key ingredient.

Psychological Safety In the Workplace:

Here’s a great article from Fairygodboss with Nia Maxwell, a site reliability engineer at Splunk and a leader within two of Splunk’s employee resource groups (ERGs): Encouraging Personal Growth and Freedom While Offering Psychological Safety and Support. One of the points I actually like most in this piece is the simple management action of asking people what they want to work on. Being trusted to make that decision, as well as being able to choose what *not* to work on means we can focus our energies where we know we can provide most value as well as find appropriate stretch opportunities for personal development. 

Last week we talked about the weaponisation of psychological safety and “toxic positivity”. I love this piece by Matilda at Crazy Head Comics on the difference between toxic positivity and genuine optimism.

The incredible Deisa Tremarias, a feminist illustrator in Venezuela, has designed these fabulous “Cultivate Curiosity” psychological safety stickers, and you can order them in packs of 3 at the psychsafety swag shop! Other stickers are also available, as well as a selection pack!

Psychological Safety Research

This is interesting: Agile software development one year into the COVID-19 pandemic, by Pernilla Agren, Eli Knoph, and Richard Berntsson Svensson. The authors examined seven different organisations through questionnaires and interviews, through an explanatory sequential mixed methods study (which often rings alarm bells for me as a very effective way of finding a hypothesis first, then hunting for the evidence to support it…). They suggest that the switch to remote work affected the communication and social interactions of Agile software delivery, but did not impact technical practices – they highlight the increased difficulty in establishing psychological safety in remote interactions as a factor.

Things to do and try:  This is a fantastic paper on perception of, and reframing, risk in the public sector by Nesta and Collaborate CIC. With some excellent examples such as London Borough of Newham’s response to COVID-19, which focussed on prototyping rather than detailed planning – starting somewhere and acknowledging that things might not be perfect but can be quickly changed and improved. 

Considering “risk maturity” to be the ability to make informed decisions about the evaluation of risk, and identify “safe to fail” experiments where the reward of success is greater than the risk of failure, the screenshot below shows a useful survey on culture that addresses behaviours and practices that can inhibit risk maturity:

This week’s poem:

Bani Adam (“Sons of Adam or “Human Beings”), part of Saadi’s work “Gulistan”, written 1258.

In Persian:

بنی‌آدم اعضای یک دیگرند
که در آفرينش ز یک گوهرند
چو عضوى به‌درد آورَد روزگار
دگر عضوها را نمانَد قرار
تو کز محنت دیگران بی‌غمی
نشاید که نامت نهند آدمی

banī ādam aʿzāy-i yak digarand
kih dar āfarīnish zih yak gawharand
cho ʿuzwī bih dard āwarad rozgār
digar ʿuzwhā rā namānad qarār
to k’az miḥnat-i dīgarān beghamī
nashāyad kih nāmat nahand ādamī

In English:

The children of Adam are the members of each other,
who are in their creation from the same essence.
When day and age hurt one of these members,
other members will be left (with) no serenity.
If you are unsympathetic to the misery of others,
it is not right that they should call you a human being.

This poem adorns a carpet hung on the wall of the United Nations building in New York City.
 

Mission statement

The mission of this newsletter is to make the world of work a better, safer, more inclusive and equitable place. We work towards this by sharing, as widely as possible, new research and opinion, case studies, news, practices and methods related to psychological safety. 

This includes topics such as inclusion, human factors, facilitation, safety critical environments, systems thinking, leadership and management, diversity and equity, mental health, organisational dynamics, culture, ethics, and more. 

A core goal is to amplify the voices of minoritised groups and those who are less represented in this field. This includes (but is not limited to) voices of people of colour, neurodiverse people, LGBTQ+ people, women in leadership and tech, and more.

Another goal is to share insights and best practices across different domains: for example, so that those of us in tech may learn from healthcare, and those of us in education can learn from aviation.

I believe knowledge is worthless unless it’s accessible. A key principle of this newsletter is to only share content that everyone can access. This excludes content behind paywalls, research papers that are not open-access, and proprietary tools that don’t open source their algorithms (preventing us from observing how systems make decisions about us). There may be some exceptions to this principle in practice, for example, where authors are able to share original texts of papers.

Whilst this statement will evolve this over time, the core principles of equity, amplification, and progressive & humanistic leadership shouldn’t change.