They used to joke about my team that “It would take them six months just to agree on whether they want to use semicolons; and even then it would be open to debate for that one special project”, but today that couldn’t be further from the truth.

A couple of years ago, when I first joined Unruly, my arrival in the company coincided with the creation of a new team. The team was made up of several individuals who were invited to rotate over from other teams in the Product Development department, and a newcomer - myself.

The team members were to bring with them a handful of projects from their previous teams, consolidating these projects within a single team who’se focus was on one shared goal- driving Unruly’s effort of broadening its revenue stream from Programmatic advertising.

Even though the team was quite capable of agreeing on what they wanted to achieve from a product standpoint, once the conversation moved to technical implementation agreement would soon be replaced with debate on good occasions and frustration on bad.

Why was it so hard to make decisions?

Even though the team was quick to amalgamate around a shared purpose, they had all come from different teams with slightly different ways of working and as individuals they all had very different professional preferences.

If I were to write a play about the team (clearly the next best thing to hit the West End since Hamilton) the character descriptions would be something like this:

1. teammate #1 The person who has been at Unruly almost since the beginning, worked extensively in the key technologies the team currently uses, likes things the way they are and doesn’t see why things should change from how they have always been.
2. teammate #2 The person who has virtually no experience at half of the team’s tech stack, but has specialised in the other half, and has a need to prove themselves in a new team.
3. teammate #3 The person who isn’t too fond of any of the tech stack currently in use, but is happy to put up with it as long as they get to use this new technology everyone is blogging about.
4. teammate #4 The person who couldn’t care less what technology we use, as long as it allows us to build our product in the simplest, safest way possible and doesn’t require them to learn the new fad everyone is blogging about.
5. teammate #5 The person who loves the tech stack, but keeps their cards close to their chest, goes with the flow of whatever the team decides; but the moment they think a bad decision is about to be made, cut the debate short by pointing out how both sides are wrong and really, we should choose a third option no one else even contemplated.

I’d like to stress that I describe these characters with a lot of love; but imagine trying to unify such a diverse group of humans around technical choices. Especially where most arguments are more or less subjectively equal, and so the main (if often subconscious) driver is personal preference.

Focusing on trust

It has been illustrated on many occasions that in order for an effective team to exist, trust must do so as well. A study conducted by Google over two year found that whenever a team had been identified as high-performing, the individual makeup of the team wasn’t nearly as important as the evidence of five key dynamics driving their interactions and working practices.

On a personal note I would say that the individual makeup is very important when trying to encourage these dynamics in the first place, but the study focuses mostly on how impactful these dynamics are once they exist.

These five dynamic are (This list is copy-pasted from the study):

1. Psychological safety Can we take risks on this team without feeling insecure or embarrassed?
2. Dependability Can we count on each other to do high quality work on time?
3. Structure & clarity Are goals, roles, and execution plans on our team clear?
4. Meaning of work Are we working on something that is personally important for each of us?
5. Impact of work Do we fundamentally believe that the work we’re doing matters?

First Thing’s First

In the early days of the team we took very few steps to building psychological safety, and instead focused more on dependability and impact.

While these dynamics are important in their own right, my experience has been that without psychological safety, the other dynamics don’t actually form, but rather an illusion of their existance forms instead. In fact, I believe that only when you succeed in building psychological safety amongst members of the team, then the other four dynamics are possible. The good news though, is that I have observed that once you do so successfully, the other four dynamics naturally form, as individuals are then empowered to ask the right questions, express the right feelings and challenge the status quo where it is found to be lacking.

Practical Steps to Building Psychological safety

Following a year or so of experimentation with a wide variety of approaches, my team has identified several key activities which we find to be highly conducive to the cohesiveness we now enjoy.

Decision making has become far easier, experimentation has become an integral part of how we work and the team finally feels like a place were perspectives, opinions and vulnerabilities are celebrated, rather than tolerated.

Next let us delve into each one of these activities in detail. Some will be longer, some shorter, but all are valuable practices which we chose to adopt:

1. Feedback & Cake A feedback cycle intended to give everyone an opportunity to give and receive feedback. And eat cake.
2. Pairing checklist A foundation for setting mutual expectations during a pair programming session
3. Getting better at X A foundation for continuous improvement
4. Occupy hand signals Improving team communication by introducing hand signals
5. Experiments as an entity When team members fear change, elevate experiments to story card level
6. Pairing matrix Ensure a balanced opportunity for all team members to mentor and to be mentored
7. Weekly Dojos Reduce the fog around coding practices by including everyone in the conversation as part of an ubermob

Achievement Unlocked

Achieving Psychological Saftey is not a video game achievement to unlock and requires constant work. Just as you can build up Psychological Saftey through persistent effort, you can gradually lose it as the team continues to accumulate human interaction. Maintaining a persistent effort such as repeating ceremonies, constantly reevaluating your practices and ensuring open dialogue across the team is crucial.

One reason I maintain that persistent work is important is that new team are formmed more often than we realise. When a new person joins a team, or an existing member moves on, we tend to think of the team as the same team with a slight change. My experience suggests otherwise. In fact, I believe that every change in the makeup of a team marks the end of an old team, and the birth of a new one.

Activities that have already been normalised and adopted by the old team are easier to introduce to the new team, for obvious reasons, but ensuring adoption often requires a directed effort. How often have we seen a new person join an existing team with the unspoken expectation that this person will adopt the team’s existing practices through osmosis? And how often have we seen this assumption fail misserably? And how many new joiners will this unspoken assumption hold water for? One more? two more? My experience tells me that this assumption hardly ever holds water for the first new joiner, and never holds water by the second.

Ensuring adoption of the former teams practices by the new team will always require reevaluating each practice from scratch. Generating buy-in by the new team, even if overwhelmignly made up of members of the previous team, is critical to successfully achieving Psychological Saftey in the new team. The easiest way to ensure this reevaluation of each practice is to ensure that all practices are revisited at a regular cadance by the old team to begin with. When a new member joins reevaluate the teams’ list of adopted practices, ensure everyone still wishes to practice them and ensure a healthy debate is held for each and every practice. You might find that some members of the old team wish to shed an old practice, or adapt it slightly, and perhaps the new member will suggest a new practice. You never know.

The important part is to regularly reflect on whether our team’s practices are still appropriate to our changing context.

Wait, what’s this got to do with Marmalade, Chutney and Tahini?

Back in the olden days, Unruly had a naming convention for its development teams - they were named after condiments. When my new team was formed the naming convention changed to something a little more… boring, but it was made up of members from the Marmalde team and the Chutney team. And Tahini? That me… and it’s pronounced Tehina.