I recently facilitated a session for Extreme Tuesday Club on Mental Health on Software Development, which I promised to write up and share with the wider community.
What follows is a summary of the discussion topics and the points shared by the groups, with names and companies removed.
Hey, what’s Extreme Tuesday Club?
It’s a meet-up for practitioners of software development in London, particularly those who work with Agile or XP methodologies.
The sessions are quite free-form and are run as the facilitator thinks would work best for the topic.
For this session, I made sure the room was split up into small groups of 5-6, and then we worked through and discussed some topics led by me (in the form of open-ended questions).
Each topic was discussed within the small groups for 15-20 minutes, followed by a 5 minute re-cap where each group shared the output of their discussions with the rest of the groups.
I really like this format for the balance it strikes between group discussions, individual contributions, and the level to which an individual in a group can contribute as much or as little as they feel comfortable doing.
Why run a session on mental health?
It’s an important topic to me personally - I have been through several rounds of therapy to help me deal with specific forms of anxiety and OCD that I was struggling with. How my coworkers handled that was an essential part of how I was able to deal with it in my work context.
As a software developer, I want to develop good software, and to do that as part of a team means making sure that the environment works for the biggest cross-section of society. Otherwise we’re losing out on valuable talent and people with potential.
But most importantly, we’re all just people at the end of the day, and I want to work in a place, an industry, a career that supports the people there. It’s just the kind and decent thing to do.
Right, on to the content.
Topic 1: Focus on software development practices
“Extreme Programming is centered around the core values of simplicity, courage, respect, feedback, and communication. It suggests practices such as pair-programming, test-driven development, and continuous integration. In what ways does XP support the creation of a environment that supports a broad spectrum of mental health? In what ways can it cause problems? How might we tackle those issues?“
-
Respect - Almost all the groups identified that one of the core values of XP, Respect, should guide us towards creating supportive environments but that there’s often a general focus on practices rather than principles or values. The XP site has a lovely sentence about Respect - “Everyone contributes value even if it’s simply enthusiasm.”, which was one of my take-aways when researching the subject for this session.
-
Feedback (cycles) - It was suggested that the values of early feedback and simplicity encourage us to work in multiple small-scope pieces of work rather than delaying value until the very end. We can work in smaller slices rather than month-long epics to reduce stress and pressure on developers, and reduce the cost of failure (both financially and emotionally).
-
Pair programming - This was the most discussed part of how XP can cause problems for mental well-being. Enforced collaboration between individuals that are not in the necessary head-space to work that way can cause a raft of issues. Even if both participants are willing, an unbalanced power-dynamic in a pair, mis-aligned objectives, or a lack of empathy for one’s pair partner have the potential to make pair-programming a miserable experience.
-
Feedback (personal) - Giving and receiving feedback is one of the hardest things to get right. Done well, it can create a team that is psychologically safe. An environment where feedback is given or received poorly can cause a negative effect that builds on itself, dissuading people from engaging in future. One group mentioned the value of Radical Candor and that while it’s a powerful tool, it has to come from a place of true care and empathy for the other person, which isn’t always a given.
-
Communication - A lot of the groups tied this in with Respect. Good communication requires respect for the people that you are communicating with, and with that comes a requirement for empathy. The level of communication between managers and those they manage was a discussion point. In particular, how good communication can build a culture of engagement and how bad communication can be authoritarian and fail to get buy-in. A company where communication is bad might not be a good environment for people who suffer from mental health problems.
Topic 2: Focus on software development as culture and industry
“The culture of software development extends beyond values and practice. Some of us work for companies, which hire people. Some of us go to meet-ups to learn new things and network. Almost all of us will have gone through a hiring process. What works well in the wider culture and industry of software development to support a broad spectrum of mental health? What doesn’t? How might we address those issues?”
-
Long-hours / overtime - Several groups identified a cultural trope of “staying late and crushing code” leading to an unsustainable work environment. One suggestion to tackle this was to make it clear that regularly working late is not seen as an example of good behaviour and isn’t the norm, and (as explored in the final topic) using what privilege we have as leaders to set good examples.
-
Pressure to be “more than a job” - There’s a widely-held belief that in order to be a good software developer, it needs to be more than just your day-job: you should be going to meet-ups after work, writing code at the weekend, and using your free time to learn more about building software. This meme feeds into the recruitment process, e.g. having your GitHub on your CV can be seen as a positive. It also ties into how common Impostor Syndrome is within our industry - “If I’m not writing code as my hobby, then people will figure out that I’m crap at my job!”. Changing such a large cultural trope is difficult, but positive example-setting from managers and role-models would certainly help.
-
Inclusive events and meetups - Multiple groups raised the stereotypical beers-and-pizzas meetup/hackathon, how it can cause problems for people suffering or recovering from alcohol addiction, and why it’s important that we provide for as wide a cross-section of society as possible. A great example of this was that the recent London Lead Developer Conference had free child-care, a quieter chill-out space, and live captioning for talks. One group mentioned how small huddles can make sure that they’re always leaving at least one space in the circle for new people to come and join in.
-
Being part of an under-represented minority - If you’re a member of a minority group within software development, there is a pressure to perform Diversity and Inclusivity work in addition to your actual role, coupled with a lack of role models within the industry compared to majority groups. On top of this, these groups are competitive within themselves as much as any other group, rather than being the stereotype of a united group that work together. This touches on wider issues within software development, which we can improve by doing the diversity and inclusivity work ourselves rather than ask minority groups to shoulder the burden.
-
Recruitment - Several groups expressed a dislike of how interviews are conducted in a lot of companies, relying on un-representative coding exercises or “code on a wipe-board” rather than something closer to what your day-to-day role at the company would be.
-
Office environments - Some people struggle with loud open-plan offices, and while there might be trained first-aiders they may not be trained on how to deal with specific mental health issues. There are now accredited companies that provide Mental Health First-Aid training specifically for these issues, which software companies could invest in to supplement other first-aid trained staff. Designating and more importantly enforcing a “quiet” zone in an office can really help people who struggle with loud and open environments. Workplaces could provide better training on how to transform and resolve conflict, and make sure employees have the necessary tools and support networks available.
Topic 3: Focus on individual attitudes and practices
“Modern software development practices are largely focused around teams. We interact with other individuals on a 1:1 basis or as part of those teams. Both as a team, and as an individual, what things can you do TOMORROW to support the construction of an environment that supports a broad spectrum of mental health?“
-
Start with empathy - Starting from the position of putting yourself into someone else’s shoes and trying to understand their motivations and needs can have a positive effect on individual and team relationships. Norm Keth’s “Prime Directive” of retrospectives encapsulates
-
Work in small achievable tasks - We can always be better at working in incrementally valuable steps, so that each task represents less risk and uncertainty. If a task “fails” but it’s deliberately small in scope, then the sunk costs and potential damage are also much smaller.
-
Use your privilege to help others - The onus to make software development more accommodating for mental health does not fall solely on those for whom it’s a problem. This is also true for diversity initiatives in general. If you have authority, whether perceived or literal, you can use that privilege to raise issues, lobby for change, and set examples (I try to speak publicly about my own mental health issues when appropriate, so as to normalise talking about it). One group suggested celebrating failure in retrospectives to make visible how common it actually is and so make it less of a negative.
-
Make psychological safety a first-class concern - From Wikipedia, Psychological Safety is “a shared belief that the team is safe for interpersonal risk taking”, where interpersonal risk includes volunteering opinions, giving constructive feedback, asking questions, and more. More importantly for this context, members of a psychologically safe team would not feel that being open about say, having a particularly rough day and needing a bit of quiet time to work, is unnecessarily risky.
Conclusion
This was an editorialised version of around 45 minutes to an hour of discussion. Given more time, there were definitely more topics we could have discussed, but I hope that publishing this gives anyone reading it some food for thought. If want to improve how mental health is talked about and supported in your own workplace, some of the points under Topic 3 are a good place to start the conversation.