Measuring Psychological Safety in your Team

measuring psychological safety

We know psychological safety is crucial for high performance teams, and particularly so for technical delivery teams. Innovation is so critical for creating products that delight customers and serve critical business needs, and psychological safety is a fundamental enabler of innovation.

Below are ten questions that you can ask yourself or your teams to determine the level of psychological safety in your team. Rate agreement with the below statements on a scale of 1 – 5. 5 being “completely agree” and 1 being “completely disagree”.

When carrying this exercise out with your team, perform the survey anonymously – if it’s possible that your team are psychologically unsafe, they will be more likely to be honest if the survey is anonymous. If the team are very psychologically safe, then it won’t matter if the survey is anonymous or not.

It is also important to allow for qualitative, verbose feedback for each question as well, because that verbose feedback will facilitate and clarify some of the actions that you may need to take in order to improve these scores.

  1. On this team, I understand what is expected of me.
  2. We value outcomes more than outputs or inputs, and nobody needs to “look busy”.
  3. If I make a mistake on this team, it is never held against me.
  4. When something goes wrong, we work as a team to find the systemic cause.
  5. All members of this team feel able to bring up problems and tough issues.
  6. Members of this team never reject others for being different and nobody is left out.
  7. It is safe for me to take a risk on this team.
  8. It is easy for me to ask other members of this team for help.
  9. Nobody on this team would deliberately act in a way that undermines my efforts.
  10. Working with members of this team, my unique skills and talents are valued and utilised.

To explain the context behind each question:

1 – On this team, I understand what is expected of me.

It is essential that team members understand what is expected of them in terms of delivery (speed, quality, cost, and other factors) and behaviour (everything from dress code and punctuality to coding standards) to foster psychological safety. Ensure tasks are clear and well defined, behaviour expectations are explicit, and negative behaviours are dealt with.

2 – We value outcomes more than outputs or inputs, and nobody needs to “look busy”.

Outcomes (such as revenue generated or satisfied customers) matter more than outputs (emails sent, lines of code written, or meetings attended). If the team focus on what truly matters to the business, they are safe to make decisions that can improve outcomes, even if those decisions reduce output. The ideal is a team that possesses enough psychological safety to decide not to do something that could make them look good in the eyes of others, but doesn’t deliver outcomes for the business.

3 – If I make a mistake on this team, it is never held against me.

A psychologically safe team will never blame a member of the team for a genuine mistake if their intentions were good. Indeed, by enabling mistakes to be made without a fear of blame, you enable innovation and risk taking that can drive your organisation ahead of the competition. Utilise systems thinking and DevOps approaches to prevent mistakes before they happen or mitigate the impact of mistakes when they do.

4 – When something goes wrong, we work as a team to find the systemic cause.

Related to the previous point but important enough to warrant its own question, a system of discovering the root causes of mistakes and failures means that not only do team members feel able to take risks without being blamed, but every single “failure” is an opportunity for learning and improvement. By building psychological safety through these retrospective exercises, everyone on the team gets to learn from mistakes, meaning mistakes are a gift, not a threat.

5 – All members of this team feel able to bring up problems and tough issues.

In a psychologically safe team, all members of the team are able to bring up problems and tough issues, ranging from personal struggles to concerns about other (even senior) members of the team. This psychological safety is crucial for allowing both vulnerability to show when you’re struggling and need help, and courage to raise difficult topics.

6 – Members of this team never reject others for being different and nobody is left out.

Evidence shows that diversity in a team results in higher quality products and happier team members, but diversity in itself is not enough: it is crucial that team members are all included in decision making and delivering results. To facilitate psychological safety (and high performance) every member of the team needs to be invested in the decisions made and the outcomes generated. This is particularly crucial for remote and distributed teams, where it is more difficult to see if a team member is becoming disengaged.

7 – It is safe for me to take a risk on this team.

Mistakes happen unintentionally, but risks are about taking actions that might not work, or may have unintended consequences. Psychological safety provides the framework for positive risk-taking, enabling innovation and ultimately, competitive advantage.

8 – It is easy for me to ask other members of this team for help.

In psychologically unsafe teams, team members try to hide their perceived weaknesses or vulnerabilities, which prevents them from asking for help. In a psychologically safe team, members prioritise the team goals over individual goals. Helping others helps achieve the team goal, and because team members feel safe to ask for that help, psychologically safe teams achieve more of their goals than unsafe teams.

9 – Nobody on this team would deliberately act in a way that undermines my efforts. 

In an unsafe team, members compete with each other to achieve their individual goals, and may even undermine other team members if it could benefit them or it is perceived that doing so may elevate their “rank” within the team or organisation. In a psychologically safe team, that counter-productive competition doesn’t exist, and the success of the team is more important looking good in the eyes of others.

10 – Working with members of this team, my unique skills and talents are valued and utilised.

We all bring our own unique experience, skills and knowledge to the teams that we’re in, but we also bring our own prejudices and biases. In a psychologically safe team where members are valued for being their true selves, biases are less likely to manifest. Indeed, team members may feel safe enough to identify, raise, and discuss their own biases or those of other team members. By doing so, we provide space for each individual to maximise their potential from utilising their own unique skills and talents.

Regularly Measuring Psychological Safety

By measuring the degree of psychological safety on your team, you can begin to build your own unique strategy for developing and maintaining it. For instance, this may involve running more regular retrospectives or by workshopping the team’s values and behaviours. For more information on building psychological safety, view my other resources.

Remember to be patient: this is a journey, not a destination, and work on your own psychological safety too. You can’t effectively help others if you don’t look after yourself.

Take this survey for yourself.

Psychological safety in distributed and remote teams

In early 2020, due to the Covid 19 outbreak, many organisations around the world went through a sudden digital transformation and many people became home workers. With this near-instant operational pivot to distributed 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.

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

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.

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.

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.

For a firehose of psychological safety content and links, send a blank email to “tom@SendYourSlides.com” with the subject line “performance”.

Psychological Safety in Distributed Teams (summary)

  1. Set the stage.
  2. Make sure everyone knows what to do.
  3. Focus on outcomes, not outputs. 
  4. Build a culture of appreciation.
  5. Embrace routine and ritual.
  6. Establish work boundaries.
  7. Use the many species of video call.
  8. Be actively inclusive, or risk being passively exclusive.
  9. Adopt Hanlon’s razor.
  10. Put your own oxygen mask on first.

Psychological Safety in High Performing and Distributed Teams

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.

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

Resilience Engineering, DevOps and Psychological Safety in High Performing Teams

The Links Between Psychological Safety, Resilience Engineering and DevOps

Psychological safety is cited as the key factor in team performance by numerous studies including Google’s Project Aristotle and the DORA/Google State Of DevOps Reports. The evidence shows that teams that operate in psychologically safe environments where they can present their true selves at work, take risks, admit mistakes, and ask for support from their teammates, significantly outperform other teams. 

However, establishing psychological safety is rarely prioritised by delivery-focussed leaders. Instead, leaders tend to focus on objectives, metrics, and modern practices such as value-stream alignment and cross-functional teams. While these have great value, and will go some way, or indeed a long way, to drive performance and delivery, they are not the full picture.

It can be very challenging, however, particularly for less experienced leaders, or capable leaders in difficult circumstances, to build and facilitate psychologically safe environments. This is particularly true in technologically-oriented organisations where the domain is complex and failure is explicit, obvious and can generate a large blast radius. 

In a psychologically unsafe team, a software engineer who makes a mistake in a complex system and releases a small flaw into production that later causes an outage may be blamed for the mistake. The flaw will be easily attributable, and the impact of the outage can be significant. In many organisations, the resultant fear of error can dramatically slow down the rate of change and speed to market.

Of course, the converse is not appealing either; it’s not acceptable to tolerate errors, outages, and mistakes. Speed to market with a faulty product or service may be equally as bad as a significant delay to reach the market. Customers do not tolerate poor quality services, so we need to build high quality services and do it at velocity. This delivery at pace is one of the key tenets of DevOps, and an effective DevOps culture requires psychological safety.

In my work on psychological safety in high performance teams, I’m often asked about how to achieve it, and whilst there are many general approaches that overlap significantly with principles of excellence in servant (or empathetic) leadership, there are also specific actions and approaches that are suitable specifically for technology teams. Here, we’re going to drill down into one of the key aspects of a DevOps approach: Resilience Engineering, and how it supports psychological safety.

Resilience Engineering is a field of study that emerged from cognitive system engineering in the early 2000s, largely in response to NASA events in 1999 and 2000, including the failure of the Mars Climate Orbiter. It is defined as “The intrinsic ability of a system to adjust its functioning prior to, during, or following changes and disturbances, so that it can sustain required operations under both expected and unexpected conditions.” 

Resilience Engineering is the intentional engineering of a system to not only withstand both external pressures such as high load or malicious attacks, and internal changes, planned or unplanned, to the system itself and continue to serve customers whilst change occurs. Very little theory within this domain has been generated that doesn’t emerge from studies of real work; Resilience Engineering exists within high-stakes domains such as aviation, construction, surgery, military agencies and law enforcement. Most recently it has been adopted by software engineers where it includes approaches such as:

  • Decoupling and reducing dependencies between components
  • Utilising microservices and containerisation
  • Autoscaling applications based on demand
  • Creating self-healing applications and systems
  •  Using monitoring and visibility tools to facilitate responses to out-of-bounds events
  • Adopting error budgeting instead of (or in addition to) uptime measures
  • Using automated code testing, continuous integration and advanced deployment practices

Resilience Engineering even extends to concepts such as chaos engineering. This is where flaws and interruptions are intentionally introduced in order to examine how the system behaves and help engineers identify how they can improve it.

Resilience Engineering facilitates psychological safety because it allows team members to take risks while protecting the stability of the system.

As a new team moves through Tuckman’s Forming-Storming-Norming-Performing cycle, it relies more and more on cultures and practices that facilitate risk taking and admitting mistakes. If these practices are not embedded, the team will never be able to progress to the “performing” stage, because high performance explicitly requires innovation, and therefore, risk taking. Without psychological safety, teams will cycle around the Storming and Norming phases as elements change in or around the team, such as people leaving or joining.

It is only once a technology team reaches the high performing stage that they can truly deliver high quality services at velocity. By utilising resilience engineering approaches, engineers are supported to take risks, experiment, deploy changes and recover quickly. They can feel comfortable in the knowledge that if something did go wrong, they’d find out straight away, before customers start calling. These practices, far from being so-called “soft” skills, are measurable by solid metrics that describe velocity whilst maintaining reliability, such as Change Rate, Mean Time Between Failures (MTBF) and Mean Time To Restore (MTTR).

Resilience Engineering has many similarities with the concept of Site Reliability Engineering (SRE), introduced by Ben Traynor’s team at Google in 2004. SRE practices and capabilities may be implemented by an expert, dedicated, shared SRE team, or it may suit your organisation to embed an SRE function into each stream-aligned (SA) team if the products and systems are large enough to justify it. Alternatively, it may be feasible to empower software engineers themselves to carry out SRE responsibilities if your systems are small enough.

In addition to expert leadership practice, well organised teams, adopted shared values, systemic root causes being diagnosed in retrospectives, and an embrace of continuous improvement, we must adopt capabilities that empower team members to carry out their roles without fear of failure. In a technology team, those capabilities are the very same ones that enable high velocity change, security, and reliability. 

Whatever team you’re on, or whatever team you lead, implementing Resilience Engineering capabilities to protect the team from failures will improve delivery, safety, happiness, and performance. This enables people to work without fear, psychologically safe in the knowledge that errors do not flow downstream. This place is where true high performance, speed to market, quality and innovation happens.

For more information about high performance teams, psychological safety, DevOps, or any of the other concepts covered in this article, get in touch. I’m always open to opportunities for collaboration, speaking at events, podcasts, or other ways to get involved and help teams become more productive, safer, and most importantly, happier.

@tom_geraghty

tom@tomgeraghty.co.uk 

Click here for further resources about psychological safety and high performing teams.

For further guidance regarding technology team organisation, Matthew Skelton and Manuel Pais explore in great depth how software teams can be organised to deliver most value, safety, and performance in their book “Team Topologies”, where they examine how the concepts of Conways Law, Cognitive Load and Organisational Evolution converge. 

 

Psychological Safety and High Performing 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.

Psychological safety in technology teams – Computing Magazine

Psychological safety in high performing teams google slide deck

The DORA State of DevOps 2019 report

Google’s research on effective teams

Grace Hopper Biography

Psychological Safety and Learning Behavior in Work Teams – Amy Edmondson, Administrative Science Quarterly

The cause of the Chernobyl accident – Ukrainian Nuclear Society

The Tuckman model of team stages

Take the psychological safety assessment, or provide it to your teams.

Baseline data of psychological safety scores

Resilience Engineering, DevOps and Psychological safety

Digital Lincoln – psychological safety and high performing teams – my 45-minute webinar meetup recording.

 

Why the UK Porn Block is an Awful Idea

From 15 July 2019, the UK’s age verification system for online pornography will become mandatory. Here’s why it’s a terrible idea.

  1. It actually doesn’t block much porn at all. It only applies to commercial porn, which you need a credit card to access anyway, and children generally don’t have credit cards. It doesn’t apply to porn on social media, free sites, or P2P sharing, which is much easier to access.
  2. It will likely do more harm than good. It may provide many parents with a false sense of security that their children can no longer access porn online, resulting in a lower emphasis being placed on parents properly managing their childrens’ internet access. Parental controls on home wifi, home computers, and mobile devices are widely available and relatively easy to use.
  3. It plays into the hands of the big commercial porn providers. The main age verification system (AgeID) is owned by the same company that runs the most popular and lucrative porn websites in the world. The largest porn company in the world is being tasked with controlling access to porn. Already, some smaller businesses in the realms of ethical porn and feminist porn have shut down because implementation of this system is too expensive for them. If we’re going to have porn on the internet (and who are we kidding, there will always be porn on the internet), do we want it controlled by one big US firm?
  4. It has serious privacy implications. The age verification systems will contain the personal information and erotica browsing history for every adult who’s ever wished to access online porn from July onwards. If (or more realistically, when) this database is breached, it will be a treasure trove for identity thieves and blackmailers.
  5. It just won’t work. Technologically, it’s easy to bypass the system. Because it only applies to the UK, a simple VPN to break out to a different country will easily and cheaply circumvent most controls. At the same time, as has been seen in China, India and other authoritarian regions, consumers simply switch to other channels, such as torrenting, social media, newsgroups (yes, they’re still a thing), and the dark web.
  6. It’s based on flawed evidence. Whilst there’s anecdotal evidence that children “stumble across” online porn, there’s very little evidence that they access commercial porn sites, particularly when parents make some effort to manage internet access. The main study cited as the catalyst for the Act “found” that “almost a tenth of all 12- to 13-year-olds thought they were “addicted” to pornography”, and was carried out by OnePoll, the same people who generate such hard-hitting research as “German men are the world’s worst lovers” and “Fifty percent of British adults think Mount Everest is in the UK“. There is evidence that children access porn online, and some evidence that it’s harmful, and some that it isn’t as harmful as you’d think. Whichever way it’s cut, this age-verification approach is not evidence-based.
  7. It’s censorship and control. It provides a mechanism for the government to monitor online activity and decide what content is acceptable or unacceptable for the population to access, and change this definition as they see fit. The terms in the act even include the ability to block “material other than the offending material”. We may trust today’s government (though do you, really?), but we’d be foolish to implicitly trust future governments not to extend the controls to other content. As the award-winning English lawyer Myles Jackman put it, “Pornography is the canary in the coal mine of free speech: it is the first freedom to die. If this assault on liberty is allowed to go unchallenged, other freedoms will fall as a consequence.”

Technologically, this approach is fundamentally flawed, is unlikely to work at all, and creates some worrying implications for digital identity and privacy in the hands of large US corporations.

Anonymous feedback can destroy your team

Feedback sucks. Advice is better.

First of all, feedback sucks. It really does.

Unless the person delivering the feedback is highly empathetic, has lots of free time, is highly skilled and is in the proper position to provide it, and the person receiving it is in the right frame of mind, open to feedback, confident, mature and in a safe place, it’s probably going to be uncomfortable at best or at worst, devastating.

Delivering feedback is hard. In my experience managing teams over a couple of decades, I’ve seen it done so badly that it verges on abuse (in fact, on occasion it certainly was abuse), and despite my best efforts, I’ve have delivered feedback so badly that the relationship took months to recover. I’ve learned from those experiences, and now I’m better, but certainly not perfect.

But ultimately it is important to give and receive feedback if we want to get better at the things we care about. Given how incredibly hard it is to deliver feedback in person, why would we facilitate anonymous feedback?

A misguided solution.

Anonymous feedback is often presented as a solution to problems including unequal power dynamics, bias, fear, or a lack of candour. In reality, anonymous feedback masks or even exacerbates those problems. Great leadership and management solves, or should solve, those problems.

Anonymity reinforces the idea that it’s not safe to speak up. It’s mistaken for objectivity. It presumes that the people who receive it will interpret it exactly as it was intended.

Feedback must be contextual. It must also be actionable, otherwise why provide it?

Conversations matter.

The reason we deliver feedback in person is because it demands a discussion; for example, imagine someone wishes to give you feedback on the way I behaved in a meeting because you came across as aggressive and intolerant. You’d certainly want to know, but you would also want them to know that an hour before that meeting, you’d received some upsetting family news and were struggling to deal with it. That conversational feedback then provides a channel for an open and frank discussion, and an opportunity to support each other.

If that same feedback was delivered anonymously, not only is your theoretical self having a tough time with family problems, but now (in your head, for that is where we all reside) you’re overly aggressive, intolerant, and failing in your role.

Feedback must be actionable.

Anonymous feedback is incredibly difficult to act upon, and can breed a sense of frustration, fear, and resentment, particularly in small teams and organisations.

All feedback must be a conversation. And in order to have a conversation, you must be able to converse with the other party.

You may work in a high-trust, low-politic environment. Or you may believe that you do, since rarely is this truly the case. If you believe that you do, check your privilege. Are you experienced, senior, well paid, white, cis, male, able-bodied or neurotypical? Chances are, for those that are not in those categories, the degree of trust and safety they feel may be somewhat lower, and the impact of feedback considerably greater.

Unconscious bias

There are numerous biases in effect when it comes to feedback and indeed all interpersonal relationships, particularly in the workplace. For example, women are often perceived as more aggressive than men when demonstrating the same behaviour, due to an unconscious bias that women should be more feminine.

Anonymous feedback, rather than removing that bias, enables it, and feeds it, because a woman receiving anonymous feedback that she should “be less aggressive” is forced to accept it as objective, when it’s actually less likely to be the case.

Bias affects everyone. A man may receive feedback suggesting he should be less softly spoken in meetings, an introvert may be told they should speak up more, or (and this happens a lot) a young woman may be told to smile more.

Motivations

Consider the motivations for someone providing anonymous feedback. One reason might be that they genuinely want you to be better, and they already think you’re great, so they’re giving you a chance to excel even more. That’s the only good reason for feedback. All others, including power-plays, envy, bias, inexperience, or simple misunderstanding of the situation, are terrible reasons, and will only have a negative impact on the team.

The point is that when providing feedback, even if your intentions are pure, you will not be aware of your unconscious bias, and working through those biases is that is something that only a conversation can facilitate.

Dialogue.

In every single 1-1 you have with a team member, ask what you can do better, what more or less you could be doing, or what, if anything you could change in you interactions with team members. This regular, light-touch, conversational cadence provides a safe space for feedback. And even if in 99% of the sessions, there is no feedback to give, it ensures that when there is some feedback required, it comes easily, and isn’t a difficult process.

Anonymity encourages poor leadership.

Anonymous feedback processes also provide a get-out, an excuse, for poor leadership and avoiding conversations where feedback is requested or proffered. The thinking may be “I no longer need to ask what more I can do or how I can be better, since we have regular anonymous feedback instead.” This is dangerous, and leads to a general degradation of good leadership practices.

For these reasons, I never provide or accept anonymous feedback. I will always, instead, have a conversation.

Culture.

If you’re tempted to use anonymous surveys and feedback, ask yourself why you feel that anonymity is required, and address the underlying issues. A truly great culture doesn’t require anonymity, and an organisation without a great culture is not maximising the potential of the people within it.

Using Hugo and AWS to build a fast, static, easily managed and deployed website.

Most of my websites are built using WordPress on Linux in AWS, using EC2 for compute, S3 for storage and Aurora for the data layer. Take a look at sono.life as an example.

For this site, I wanted to build something that aligned with, and demonstrated some of the key tenets of cloud technology – that is: scalability, resiliency, availability, and security, and was designed for the cloud, not simply in the cloud.

I chose technologies that were cloud native, were as fast as possible, easily managed, version controlled, quickly deployed, and presented over TLS. I opted for Hugo, a super-fast static website generator that is managed from the command line. It’s used by organisations such as Let’s Encrypt to build super fast, secure, reliable and scalable websites. The rest of my choices are listed below. Wherever possible, I’ve used the native AWS solution.

The whole site loads in less than half a second, and there are still improvements to be made. It may not be pretty, but it’s fast. Below is a walk through and notes that should help you build your own Hugo site in AWS. The notes assume that you know your way around the command line, that you have an AWS account and have a basic understanding of the services involved in the build. I think I’ve covered all the steps, but if you try to follow this and spot a missing step, let me know.

Notes on Build – Test – Deploy:

Hugo was installed via HomeBrew to build the site. If you haven’t installed Homebrew yet, just do it. Fetch by running:

/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Then install Hugo:
brew install hugo

One of the things I love about Hugo is the ability to make rapid, on-the-fly changes to the site and see the result instantly, running the Hugo server locally.

hugo server -w -D

The option -D includes drafts in the output, whilst -w watches the filesystem for changes, so you don’t need to rebuild with every small change, or even refresh in the browser.

To create content, simply run

hugo new $postname.md

Then create and edit your content, QA with the local Hugo server, and build the site when you’re happy:

hugo -v

V for verbose, obvs.

You’ll need to install the AWS CLI, if you haven’t already.

brew install awscli

Check it worked:

aws --version

Then set it up with your AWS IAM credentials:

aws configure
AWS Access Key ID [None]: <your access key>
AWS Secret Access Key [None]: <your secret key>
Default region name [None]: <your region name>
Default output format [None]: ENTER

You don’t need to use R53 for DNS, but it doesn’t cost much and it will make your life a lot easier. Plus you can use funky features like routing policies and target health evaluation (though not when using Cloudfront distributions as a target).

Create your record set in R53. You’ll change the target to a Cloudfront distribution later on. Create the below json file with your config.

{
            "Comment": "CREATE/DELETE/UPSERT a record ",
            "Changes": [{
            "Action": "CREATE",
                        "ResourceRecordSet": {
                                    "Name": "a.example.com",
                                    "Type": "A",
                                    "TTL": 300,
                                 "ResourceRecords": [{ "Value": "4.4.4.4"}]
}}]
}
And run:
aws route53 change-resource-record-sets --hosted-zone-id ZXXXXXXXXXX --change-batch file://sample.json

Create a bucket. Your bucket name needs to match the hostname of your site, unless you want to get really hacky.

aws s3 mb s3://my.website.com --region eu-west-1

If you’re using Cloudfront, you’ll need to specify permissions to allow the Cloudfront service to pull from S3. Or, if you’re straight up hosting from S3, ensure you allow the correct permissions. There are many variations on how to do this – the AWS recommended way would be to set up an Origin Access Identity, but that won’t work if you’re using Hugo and need to use a custom origin for Cloudfront (see below). If you don’t particularly mind if visitors can access S3 assets if they try to, your S3 policy can be as below:

{
  "Version":"2012-10-17",
  "Statement":[{
	"Sid":"PublicReadGetObject",
        "Effect":"Allow",
	  "Principal": "*",
      "Action":["s3:GetObject"],
      "Resource":["arn:aws:s3:::example-bucket/*"
      ]
    }
  ]
}

Request your SSL certificate at this time too:

aws acm request-certificate --domain-name $YOUR_DOMAIN --subject-alternative-names "www.$YOUR_DOMAIN" 

ACM will automatically renew your cert for you when it expires, so you can sleep easy at night without worrying about SSL certs expiring. That stuff you did last summer at bandcamp will still keep you awake though.

Note: Regards Custom SSL client support, make sure to select ONLY SNI. Supporting old steam driven browsers on WinXP will cost you $600, and I don’t think you want that.

The only way to use https with S3 is to stick a Cloudfront distribution in front of it, and by doing this you get the added bonus of a super fast CDN with over 150 edge locations worldwide.

Create your Cloudfront distribution with a json config file, or straight through the cli.

aws cloudfront create-distribution --distribution-config file://distconfig.json

Check out the AWS documentation for details on how to create your config file.

Apply your certificate to the CF distribution too, in order to serve traffic over https. You can choose to allow port 80 or redirect all requests to 443. Choose “custom” certificate to select your cert, otherwise Cloudfront will use the Amazon default one, and visitors will see a certificate mismatch when browsing to the site.

When configuring my Cloudfront distribution, I hit a few issues. First of all, it’s not possible to use the standard AWS S3 origin. You must use a custom origin (specifying the region of the S3 bucket as below in order for pretty URLs and CSS references in Hugo to work properly. I.e.

cv.tomgeraghty.co.uk.s3-website-eu-west-1.amazonaws.com 

instead of

cv.tomgeraghty.co.uk.s3.amazonaws.com

Also, make sure to specify the default root object in the CF distribution as index.html.

Now that your CF distribution is ready, anything in your S3 bucket will be cached to the CF CDN. Once the status of your distribution is “deployed”, it’s ready to go. It might take a little while at first setup, but don’t worry. Go and make a cup of tea.

Now, point your R53 record at either your S3 bucket or your Cloudfront disti. You can do this via the cli, but doing it via the console means you can check to see if your target appears in the list of alias targets. Simply select “A – IPv4 address” as the target type, and choose your alias target (CF or S3) in the drop down menu.

Stick an index.html file in the root of your bucket, and carry out an end-to-end test by browsing to your site.

Build – Test – Deploy

Now you have a functioning Hugo site running locally, S3, R53, TLS, and Cloudfront, you’re ready to stick it all up on the internet.

Git push if you’re using Git, and deploy the public content via whichever method you choose. In my case, to the S3 bucket created earlier:

aws s3 cp public s3://$bucketname --recursive

The recursive switch ensures the subfolders and content will be copied too.

Crucially, because I’m hosting via Cloudfront, a new deploy means the old Cloudfront content will be out of date until it expires, so alongside every deploy, an invalidation is required to trigger a new fetch from the S3 origin:

aws cloudfront create-invalidation --distribution-id $cloudfrontID  --paths /\*

It’s not the cleanest way of doing it, but it’s surprisingly quick to refresh the CDN cache so it’s ok for now.

Time to choose a theme and modify the hugo config file. This is how you define how your Hugo site works.

I used the “Hermit” theme:

git clone https://github.com/Track3/hermit.git themes/hermit

But you could choose any theme you like from https://themes.gohugo.io/

Modify the important elements of the config.toml file:

baseURL = "$https://your-website-url"
languageCode = "en-us"
defaultContentLanguage = "en"
title = "$your-site-title"
theme = "$your-theme"
googleAnalytics = "$your-GA-UA-code"
disqusShortname = "$yourdiscussshortname"

Get used to running a deploy:

hugo -v
aws s3 cp public s3://your-site-name --recursive
aws cloudfront create-invalidation --distribution-id XXXXXXXXXX  --paths /\*

Or, to save time, set up npm to handle your build and deploy. Install node and NPM if you haven’t already (I’m assuming you’re going to use Homebrew again.

$ brew install node

Then check node and npm are installed by checking the version:

npm -v

and

node -v

All good? Carry on then:

npm init

Create some handy scripts:

{
    "name": "hugobuild",
    "config": {
        "LASTVERSION": "0.1"
    },
    
    "version": "1.0.0",
    "description": "hugo build and deploy",
    "dependencies": {
        "dotenv": "^6.2.0"


    },

    "devDependencies": {},
    "scripts": {
        "testvariable": "echo $npm_package_config_LASTVERSION",
        "test": "echo 'I like you Clarence. Always have. Always will.'",
        "server": "hugo server -w -D -v",
        "build": "hugo -v",
        "deploy": "aws s3 cp public s3:// --recursive && aws cloudfront create-invalidation --distribution-id  --paths '/*'"
    },
    "author": "Tom Geraghty",
    "license": "ISC"
}

Then, running:

npm run server

will launch a local server running at http://localhost:1313

Then:

npm run build

will build your site ready for deployment.

And:

npm deploy

will upload content to S3 and tell Cloudfront to invalidate old content and fetch the new stuff.

Now you can start adding content, and making stuff. Or, if you’re like me and prefer to fiddle, you can begin to implement Circle CI and other tools.

Notes: some things you might not find in other Hugo documentation:

When configuring the SSL cert – just wait, be patient for it to load. Reload the page a few times even. This gets me every time. The AWS Certificate manager service can be very slow to update.

Take a look at custom behaviours in your CF distribution for error pages so they’re cached for less time. You don’t want 404’s being displayed for content that’s actually present.

Finally, some things I’m still working on:

Cloudfront fetches content from S3 over port 80, not 443, so this wouldn’t be suitable for secure applications because it’s not end-to-end encrypted. I’m trying to think of a way around this.

I’m implementing Circle CI, just for kicks really.

Finally, invalidations. As above, if you don’t invalidate your CF disti after deployment, old content will be served until the cache expires. But invalidations are inefficient and ultimately cost (slightly) more. The solution is to implement versioned object names, though I’m yet to find a solution for this that doesn’t destroy other Hugo functionality. If you know of a clean way of doing it, please tell me 🙂