Psychological Safety in Remote Teams

A sudden adoption of remote working.

In early 2020, due to the Covid 19 outbreak, many organisations around the world went through a sudden digital transformation and many teams became remote. With this near-instant operational pivot to distributed and remote teams, organisations and the people within them encountered new and difficult challenges such as poor internet connectivity, inadequate home offices, and trying to manage simultaneous family and work life.

One of the biggest challenges is the impact of being physically distant from our teammates on our psychological wellbeing. Distributed teams have fewer opportunities for spontaneous, casual conversation; team members have more difficulty picking up non-verbal cues in conversation, and people are more likely to feel alone, anxious, unsure of what to do, and may even experience self-doubt or imposter syndrome.

Fundamental requirements for high performing teams

Psychological safety is the number one requirement for high performing teams. Without it, a team will never achieve high performance and the members of that team will not be able to realise their full potential. Now that many of our teams are distributed and remote, psychological safety is even more difficult to build and maintain.

Here are ten things you can do, whether you’re a leader or a member of your team, to help foster and build psychological safety, and increase the performance and happiness of your team and yourself.

Ten key actions to improve psychological safety in remote teams.

1. Set the stage.

We’re all going through difficult times, whether it’s financial concerns, supporting vulnerable friends and relatives or just dealing with the mental load of what’s happening in the world. Be honest about this with your team. Be explicit about the challenges ahead, and show your vulnerability. Without you showing vulnerability, your team will be unlikely to, and it’s a key part of building psychological safety. Be positive and enthusiastic about facing these challenges. 

management and leadership

2. Make sure everyone knows what to do.

Knowing what to do, when to do it, and what good looks like is crucial for remote team members. It’s far more difficult to ask for advice or assistance when remote, and self-doubt will creep in quickly. So make sure team members know what is expected of them, and ensure that workloads and deliverables are realistic. 

3. Focus on outcomes, not outputs. 

Outcomes matter more than anything else. Whether your desired outcome is satisfied customers, revenue generated, uptime, or something else, focus on that, and ensure the team remain focussed on it. Resist the temptation to revert to more traditional, “lazy” styles of management by measuring outputs, lines of code written, story points completed or meetings attended. And certainly avoid falling back to input-driven management by logging hours worked – we already know that is a route to reduction of psychological safety and it’s the last thing a distributed team needs. 

By keeping the team focussed on what really matters to the business, psychological safety will be improved, because team members will know that their hard work makes a difference, and they can contribute to the success of the organisation.

outcomes vs outputs

4. Build a culture of appreciation.

When we’re all in the same place, appreciation and thanks are much easier to communicate and tend to be passive or automatic. With distributed teams, much more effort needs to be made to ensure team members feel valued and appreciated. This means being much more explicit with appreciation, and communicating it in multiple ways such as through video calls, emails, and instant messaging. It’s very easy to forget how often we thank each other when we’re co-located, and without that culture of appreciation, psychological safety will suffer.

5. Embrace routine and ritual.

The dramatic shift in ways of working has resulted in disruption to our routines – our start and finish times, any regular meetings, and lunch breaks have all been disrupted. Routines help us as humans feel more comfortable and psychologically safe when the world around us is changing and there is so much uncertainty elsewhere. 

Ritual also plays an important role in team cohesion, particularly so with distributed and remote teams. Every team will have its own rituals and ceremonies, from ringing a bell at a sprint kickoff, to having end-of-week drinks on a video call. Whatever the rituals are, keep them up in order to build psychological safety.

ringing a bell

6. Establish work boundaries.

Work has invaded our homes and our personal space and time. It’s very easy to allow work to spread out, particularly if strict boundaries are not set. Help your team set these boundaries, and enforce and model them. This may be ensuring that team members can turn off their phones after 6pm without worrying about missing important messages, or purchasing home office equipment so they don’t need to work from their kitchen table. 

To maintain psychological safety, team members need to be able to remove themselves from work and maintain their own personal, home and family space.

7. Use the many species of video call.

Video calls aren’t just for meetings. To bring back the feeling of cohesion and togetherness that is so important for psychological safety, try out different kinds of video call, such as “good morning” meetings to start the day, or by having an “always-on” watercooler style meeting where people can drop in and out as desired. Feeling more connected to team mates will build psychological safety and improve communication.

8. Be actively inclusive, or risk being passively exclusive.

In an office setting, it’s easy to see if someone is not engaged or is pulling away from the team. With a distributed team, this is far more difficult even on video calls. 

A critical stage of psychological safety is “contributor safety” – everyone needs to contribute if the team is to achieve high performance, and in distributed and remote teams, if you’re not being actively inclusive, you’re risking being passively exclusive. To build psychological safety, invite participation, ask questions, and always ensure that everyone has spoken at least once before ending a meeting.

one person withdrawn from the group

9. Adopt Hanlon’s razor.

First published in German in 1774, Johann Wolfgang von Goethe wrote in The Sorrows of Young Werther: “Misunderstandings and lethargy perhaps produce more wrong in the world than deceit and malice do. At least the latter two are certainly rarer.” A sentiment later attributed to Robert J. Hanlon, hence “Hanlon’s razor”.

That is to say, it is important to assume the best intentions. If an email or message comes across as rude, blunt, or offensive, assume it was a miscommunication or misunderstanding. If in doubt, ask for clarification, ideally via video or voice.

To avoid others falling into the same trap, embrace emojis and gifs in your communications, even if they’re not your usual style. Emojis and gifs can help build and maintain psychological safety by ensuring that your communication is received in the most positive way possible.

smiley emoji helps to reassure intention

10. Put your own oxygen mask on first.

If you’re struggling with your own psychological safety, you will not be as effective in helping others with theirs. Find a mentor to advise and help you, eat healthily (but remember to treat yourself), exercise, meditate, and take time away from work; essentially, do whatever you know helps you maintain a happy and healthy approach and pace of work. As leaders of teams, many of us get so focused on caring for our team members that we minimise or neglect our own needs, but if you don’t look after yourself, you can’t look after others.

Take your time.

Finally, be patient. These are difficult times, and it’s to be expected that we will all experience challenges that impact our psychological safety and that of our team members. Utilising the ten behaviours above will help you and your team maintain psychological safety and improve not just team performance, but happiness too. Remember, happy teams aren’t happy because they’re high performing: they’re high performing because they’re happy.

Check out information about how to measure psychological safety in your teams here.

Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

For more information about building psychologically safe teams, read more about DevOps and psychological safety, read about high performing teams and psychological safety, or get in touch if you’d like me to speak or work with you.

Psychological Safety in High Performing Teams – Digital Lincoln Meetup April 2020

This is a recording of a webinar I did for the meetup group Digital Lincoln on the 28th April 2020.

Psychological Safety in High Performing and Distributed Teams

Safety isn’t just necessary in order to prevent disasters, it’s also crucial to building and maintaining high performance teams and organisations.

Building high performing software requires high performing teams, in which team members need to feel able to express their creativity, talents and skills without self-censoring, self-silencing, or fear of failure. In this talk, Tom introduces the latest research in high performance technology teams, and provides actionable concepts to help you build and elevate your team, whether co-located or distributed and remote.

Download a complete Psychological Safety Action Pack full of workshops, tools, resources, and posters to help you measure, build, and maintain Psychological Safety in your teams.

Find out about Psychological Safety and Information Security, and more here about high performing design teams who utilise psychological safety.

Tom is an expert in transforming team performance. A “veteran technology team builder” according to Computing Magazine, Over his 15 years as a technology leader, he has come to believe that culture trumps strategy, and happiness precedes success.

Tom is currently the Head of Technology at MoreNiche in Nottingham, CTO of Ydentity, an identity protection startup, and a management consultant for Q5. Outside of work, Tom is a yoga teacher and mountain biker.

https://www.crowdcast.io/e/missile-destroyers

The State of DevOps Report 2019 – A Summary

Every year or so since 2013, Puppet have carried out their “State of DevOps” report that attempts to gather, aggregate and analyse progress across the technology industry, backed by data and statistical analysis. In 2019, both Puppet and Google researched and released their own State Of DevOps Reports.

Here is a summary of the findings from both 2019 State of DevOps Reports.

(More detail to come shortly!)

  1. 2019 – Puppet:
    1. Doing DevOps well enables you to do security well.
    2. Integrating security deeply into the software delivery lifecycle makes teams more than twice as confident of their security posture.
    3. Integrating security throughout the software delivery lifecycle leads to positive outcomes.
    4. Security integration is messy, especially in the middle stages of evolution.

     

  2. 2019 – Google:
    1. The industry continues to improve, particularly among the elite performers.
    2. The best strategies for scaling DevOps in organisations focus on structural solutions that build community, including Communities of Practice.
    3. Cloud continues to be a differentiator for elite performers and drives high performance.
    4. To support productivity, organisations can foster a culture of psychological safety and make smart investments in tooling, information search, and reducing technical debt through flexible, extensible, and viewable systems.
    5. Heavyweight change approval processes, such as change approval boards, negatively impact speed and stability. In contrast, having a clearly understood process for changes drives speed and stability, as well as reductions in burnout.

 

 

Compliance in DevOps: Using public cloud services and automated governance

As a DevOps engineer, you’ve achieved greatness. You’ve containerised everything, built your infrastructure and systems in the cloud and you’re deploying every day, with full test coverage and hardly any outages. You’re even starting to think you might really enjoy your job.

Then why are your compliance teams so upset?

Let’s take a step back. You know how to build secure applications, create back ups, control access to the data and document everything, and in general you’re pretty good at it. You’d do this stuff whether there were rules in place or not, right?

Not always. Back in the late 90’s, a bunch of guys in suits decided they could get rich by making up numbers in their accounts. Then in 2001 Enron filed for bankruptcy and the suits went to jail for fraud. That resulted in the Sarbanes-Oxley Act, legislation which forced publicly listed firms in the US to enforce controls to prevent fraud and enable effective audits.

Sarbanes-Oxley isn’t the only law that makes us techies do things certain ways though. Other compliance rules include HIPAA, ensuring that firms who handle clinical data do so properly; GDPR, which ensures adequate protection of EU citizens’ personal data; and PCI-DSS, which governs the use of payment card data in order to prevent fraud (and isn’t a law, but a common industry standard). Then there are countless other region and industry specific rules, regulations, accreditations and standards such as ISO 27001 and Cyber Essentials.

Aside from being good practice, the main reason you’d want to abide by these rules is to avoid losing your job and/or going to jail. It’s also worth recognising that demonstrating compliance can provide a competitive advantage over organisations that don’t comply, so it makes business sense too.

The trouble is, compliance is an old idea applied to new technology. HIPAA was enacted in 1996, Sarbanes-Oxley in 2002 and PCI DSS in 2004 (though it is frequently updated). In contrast the AWS EC2 service only went out of beta in late 2008, and the cloud has we know it has been around for just a few years. Compliance rules are rarely written with cloud technology in mind, and compliance teams sometimes fail to keep up to date with these platforms or modern DevOps-style practices. This can make complying with those rules tricky, if not downright impossible at times. How do you tell an auditor exactly where your data resides, if the only thing you know is that it’s in Availability Zone A in region EU-West-1? (And don’t even mention to them that one customer’s Zone A isn’t the same as another’s).

As any tech in a regulated industry will appreciate, compliance with these rules is checked by regular, painful and disruptive audits. Invariably, audits result in compliance levels looking something like a sine wave:

This is because when an audit is announced, the pressure is suddenly on to patch the systems, resolve vulnerabilities, update documents and check procedures. Once the audit is passed, everyone relaxes a bit, patching lags behind again, documentation falls out of date and the compliance state drifts away from 100%. This begs the question, if we only become non-compliant between audits, is the answer to have really, really frequent audits?

In a sense, yes. However, we can no longer accept that audits with spreadsheet tick box exercises, and infosec sign-off at deployment approval stage actually work. Traditional change management and compliance practices deliberately slow us down, with the intention of reducing the risk of mistakes.

This runs counter to modern DevOps approaches. We move fast, making rapid changes and allowing teams to be autonomous in their decision making. Cloud technology confuses matters even further. For example, how can you easily define how many servers you have and what state they’re in, if your autoscaling groups are constantly killing old ones and creating new ones?

From a traditional compliance perspective, this sounds like a recipe for disaster. But we know that making smaller, more frequent changes will result in lower overall risk than large, periodic changes. What’s more, we take humans out of the process wherever possible, implementing continuous integration and using automated tests to ensure quality standards are met.

From a DevOps perspective, let’s consider compliance in three core stages. The first pillar represents achieving compliance. That’s the technical process of ensuring workloads and data are secure, everything is up to date, controlled and backed up. This bit’s relatively easy for competent techs like us.

The second pillar is about demonstrating that you’re compliant. How do you show someone else, without too much effort, that your data is secure and your backups actually work? This is a little more difficult, and far less fun.

The third pillar stands for maintaining compliance. This is a real challenge.  How do you ensure that with rapid change, new technology, and multiple teams’ involvement, the system you built a year ago is still compliant now? This comes down to process and culture, and it’s the most difficult of the three pillars to achieve.

But it can be done. In DevOps and Agile culture, we shift left. We shorten feedback loops, decrease batch size, and improve quality through automated tests. This approach is now applied to security too, by embedding security tests into the development process and ensuring that it’s automated, codified, frictionless and fast. It’s not a great leap from there towards shifting compliance left too, codifying the compliance rules and embedding them within development and build cycles.

First we had Infrastructure as Code. Now we’re doing Compliance as Code. After all, what is a Standard Operating Procedure, if not a script for humans? If we can “code” humans to carry out a task in exactly the same way every time, we should be able to do it for machines.

Technologies such as AWS Config or Inspec allow us to constantly monitor our environment for divergence from a “compliant” state. For example, if a compliance rule deems that all data at rest is encrypted, we can define that rule in the system and ensure we don’t diverge from it – if something, human or machine, creates some unencrypted storage, it will be either be flagged for immediate attention or automatically encrypted.

One of the great benefits of this approach is that the “proof” of compliance is baked into your system itself. When asked by an auditor whether data is encrypted at rest, you can reassure them that it’s so by showing them your rule set. Since the rules are written as code, the documentation (the proof) is the control itself.

If you really want your compliance teams to love you (or at least quit hassling you), this automation approach can be extended to documentation. Since the entire environment can be described in code at any point in time, you can provide point-in-time documentation of what exists in that environment to an auditor, or indeed at any point in time previously, if it’s been recorded.

By involving your compliance teams in developing and designing your compliance tools and systems, asking what’s important to them, and building in features that help them to do their jobs, you can enable your compliance teams to serve themselves. In a well designed system, they will be able to find the answers to their own questions, and have confidence that high-trust control mechanisms are in place.

Compliance as Code means that your environment, code, documentation and processes are continuously audited, and that third, difficult pillar of maintaining compliance becomes far easier:

This is what continuous compliance looks like. Achieve this, and you’ll see what a happy compliance team looks like too.

Re:Develop.io History of DevOps talk

I recently gave a talk at Re:Develop.io about the history of DevOps, and this page is where you can find the slide deck and other relevant resources.

Video of the talk

Re:develop.io DevOps Evolution Slide deck

The Theory of constraints

Agile 2008 presentation by Patrick DuBois

10+Deploys per day, Dev and Ops at Flickr – Youtube

10+deploys a day at Flickr – slide deck

DORA 

Nicole Forsgren research paper

2018 State of DevOps Report

My “Three Ways” slide deck

Safety culture

Amazon DevOps Book list

Deming’s 14 points of management

Lean management

The Toyota Way

The Agile Manifesto

Beyond the phoenix project (audio)

Netflix – simian army

My Continuous Lifecycle London talk about compliance in DevOps and the cloud