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:
- 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.
- 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.
- 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.
- 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.
- 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):
- Psychological safety Can we take risks on this team without feeling insecure or embarrassed?
- Dependability Can we count on each other to do high quality work on time?
- Structure & clarity Are goals, roles, and execution plans on our team clear?
- Meaning of work Are we working on something that is personally important for each of us?
- 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.
I’d like to delve into each one of these activities, and will be dedicating a blog post to each one of them. Some will be longer, some shorter, but bellow is a list of the posts I intend on writing over the coming weeks.
- Feedback & Cake A feedback cycle intended to give everyone an opportunity to give and receive feedback. And eat cake.
- Pairing checklist A foundation for setting mutual expectations during a pair programming session
- Getting better at X A foundation for continuous improvement
- Occupy hand signals Improving team communication by introducing hand signals
- Experiments as an entity When team members fear change, elevate experiments to story card level
- Pairing matrix Ensure a balanced opportunity for all team members to mentor and to be mentored
- Weekly Dojos Reduce the fog around coding practices by including everyone in the conversation as part of an ubermob
I hope you’re as excited by this list as I am.
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.