Great Teams Have Psychological Safety

I recently finished reading "Smarter, Faster, Better" by Charles Duhigg - a great read full of insights about how the most productive individuals and organisations work.

One of the best sections is about what makes a good team and it refers extensively to work done by Google during "Project Aristotle". Google spent several months studying all of their teams to try and determine what the highest performing teams have in common and whether traditionally accepted wisdom held up to scrutiny.

What they found was that it was surprisingly difficult to discover any features of a team that were always correlated with high performance. There were high performing teams that were very extroverted, but also those that were introverted. Some were best friends outside of work, while others never spoke outside of the office. They had hypothesised that teams who are physically located together would outperform teams who are distributed around the world - but even that turned out not to be the case.

The one thing that they found to be a reliable and consistent feature of high performing teams is what they called "psychological safety". The size, location, organisational structure, and every other feature you could think of turned out not to be essential for high performance. Only psychological safety is absolutely essential.

What is psychological safety? 

According Duhigg:

Psychological safety is a "shared belief, held by members of the team, that the group is a safe place for taking risks. "It is a "sense of confidence that the team will not embarrass, reject, or punish someone for speaking up... It describes a team climate characterised by interpersonal trust and mutual respect in which people are comfortable being themselves.

- Page 50, Smarter, Faster, Better.

A team that does not have psychological safety is one in which members of the team aren't comfortable being themselves and may worry about speaking their mind or taking risks once in a while. On the other hand, teams that do have psychological safety encourage innovative ideas and novel approach to be aired publicly. Of course, a team that has psychological safety is not guaranteed to be high performing, but, according to Google's research, those who don't have it will be very unlikely to reach their full potential.

How does one produce psychological safety within a team?

Again, Google has the answers. There are two behaviours that all good teams share and which contribute to an atmosphere of psychological safety: social sensitivity and equality of conversation turn-taking.

Social sensitivity is a short way of saying that members of great teams tend to be aware of how other people within the group are feeling. As Duhigg puts it, good teams "were skilled at intuiting how members felt based on their tone of voice, how people held themselves, and the expressions on their faces." (pg 60)

The other behaviour that leads to psychological safety is 'equality of conversation turn-taking'. This simply means that "all the members of the good teams spoke in roughly the same proportion... In some teams, for instance, everyone spoke during each task. In other groups, conversation ebbed from assignment to assignment but by the end of the day, everyone had spoken roughly the same amount." (Pg 60)

These two behaviours are perhaps not the two you would think essential for high performance, but once they are pointed out it's not hard to see some logic behind them. A team in which individuals are not socially sensitive are more likely to develop poor relationships over time. It's often said that a huge proportion of our communication is non-verbal i.e. There's more to understanding other people than just understanding the meaning of the words we say.

A team where individuals don't pick up social cues based on tone of voice, body language, etc is one where people will very often misunderstand one another. Best case scenario that means they will make mistakes because they're not all on the same page. Worst case scenario there will be hurt feelings, arguments and a sour mood.

As for speaking in equal amounts, it should also not be very surprising to discover that this how high performing teams operate. Assuming you have hired well in the first place, shouldn't you expect each member to have something valuable to offer when addressing a problem? The more voices that are heard, the more perspectives will be brought to bear and the more likely you are to find an innovative solution to a difficult problem.

What's more, it's almost certainly a universal law that people want a voice and they want to be heard. Giving each member of your team a voice doesn't mean that everyone gets a vote in the final decision, but it does mean that they feel valued, respected and meaningful. If you've ever been a part of a meeting where you can't get a word in you'll know how hopeless it feels. I wouldn't be surprised if that feeling spreads across all areas of your work over time.

The final comment on implementing a culture of psychological safety is that it's important that leaders set the tone and behave as they expect their team to behave.

"To create psychological safety, team leaders needed to model the right behaviours... Leaders should not interrupt team mates during conversations, because that will establish an interrupting norm. They should demonstrate they are listening by summarising what people say after they said it. They should admit what they don't know. They shouldn't end a meeting until all team members have spoken at least once.

... There are two general principles: teams succeed when everyone feels like they can speak up and when members show they are sensitive to how one another feels." (Pg 66)

--

I'd really recommend getting a copy of Harder, Faster, Better by Charles Duhigg. It's got a ton of really interesting stories and insights on motivation, setting goals, building a great team and more.

 

Hiring a developer - a guide for the non technical entrepreneur

Putting your entrepreneurial vision into motion will almost certainly involve some coding at some point, whether it's a website or an app. But if you're not as tech savvy as you need to be, how do you make it happen? Learning how to code is possible these days with a wealth of free and affordable online courses (e.g. Codecademy), but not everyone has the time (or the desire) to spend a lot of time learning the ins and outs of programming. Unless you want to learn those skills for their own sake, you're more likely to get frustrated and eventually give up on the project altogether.

An alternative for most budding entrepreneurs is to get someone else to do the coding for you, but how do you go about it? I recently attended a web development workshop through NEF, led by the nice people at Steer. Here's a quick guide about what I learned on hiring a developer.

Step 1: Decide what you're building

There's no point looking for a developer until you know what you're going to be asking them to do. Are you building an app or a website? What will it do? What will the user journey look like? What features are absolutely essential and what would be nice to have as an extra?

Get as clear as you can with what you're hoping to achieve so that you can be very clear with developers who express an interest in getting on board.

It's also useful at this stage to build a wireframe - a visual representation of what the website or app will look like, where the buttons will be and what they will do. You can do this just using a pen and paper if you want, but there are also several online tools to help. Take a look at: balsamiq.com or gomockingbird.com.

Step 2: Think about cost

The amount you have to spend on developing your site can obviously make a big difference about what the end result is like and how many of the more complex features you have been able to include. On the other hand, if all you need at this point is a more basic product then you shouldn't waste money on hiring someone very over qualified for the task.

At the cheaper end of the scale a junior developer will expect to be paid somewhere in the region of £10-20 per hour and will most likely have between 1-3 years of experience.

A highly skilled individual developer with more than 5 years experience will usually be paid between £30-40. This option would be the best choice if you want to be really sure that the end result will be up to scratch, or if you want something complicated that would require the developer to really know what they're doing.

If time is of the essence or if one person is unlikely to have all the knowledge required to deliver the product then you may have to look at hiring a team of developers. Here things start to get very expensive and can vary wildly, but expect to pay around £100-200 per hour.

Finally, you have the option of hiring an agency that will take the whole project off your hands and do everything from designing to coding to maintaining afterwards. It's very unlikely that you will need to use an agency, particularly if you are trying to build a very first version of your idea. However if you do go this route, you could end up paying about £10,000 per project.

Step 3: Find a developer

Assuming you're not going down the agency route, you next have to actually find someone who might be interested in working on your project. This becomes more difficult if you have no idea at all about what developers do or how websites/apps are built. It would be extremely wise to educate yourself on at least the basics before moving ahead.

This doesn't mean you need to become an expert, but if you don't understand how the technology works, it will be impossible to articulate what you need in a developer! There are a myriad of ways to build a website or an app, but fortunately there are also dozens of resources that will allow you to teach yourself what you need to know. Have a google, speak to any tech-fluent friends you know, and write a list of required skills for your project.

When it comes to finding developers, depending on where you live there may be many different ways. In most major cities there are regular tech meet ups that can be found quite easily, but you should also make the most of your network to get the word out. Post on Facebook and LinkedIn, see if your friends know anybody that might be interested.

Another option would be to post your job on one of the many job boards out there that cater specifically to the developer community e.g. Stack overflow, GitHub or Silicon Milkroundabout.

Step 4: Vetting candidates

Okay, so you've worked out what it is you need done and you've managed to attract interest from a few developers who are keen to work on the next big thing - now you have to look a bit further and decide on who is most suitable.

Before the interview you should ask them to send you some code samples and/or previous projects they have worked on. Have them explain exactly what it is they did and if you're really new to coding you should ask a friend or technical adviser to take a look and ask for their opinion.

The final step is the interview, but it could be as informal as meeting for a coffee so you can get to know each other better. Again, if you have a friend who knows their stuff, see if you can ask them to join you for the interview, or perhaps arrange a phone call between the candidate and your friend so he can ask the right technical questions where relevant.

Aside from that you are looking for three things; do they have a personality that you can get along with?, do they have the time to commit to the project?, and are they actively involved in the coding community?

On the other hand, warning signs to watch out for might be; do they struggle to answer technical questions about their previous projects?, do they have a big ego or a bad attitude? And have they been unwilling or unable to share sample code with you?

Step 5: Success!

Hopefully you will end up with a developer who has the right skills, that fits your budget and who will do a great job for you!

Hopefully the quick guide will give you a starting point. If you have any more advice, leave a comment and let me know!