In my job as a Consulting Architect working with Red Hat’s Open Innovation Labs, I am in a very fortunate position where I get to help kick start new product teams. We use a range of open practices to help bootstrap these teams and get them off to the best start. One practice, in particular, I’ve come to realise is foundational for getting the team off to a great start: Social Contracts.
A Social Contract is not some big consulting engagement, but it is rather a simple set of rules and behaviors put forward by a team for how they would like to interact with one another. It promotes autonomy and self-governance within a team.
Do I need one? If so, how do I build one?
In modern software development, we’re all about tearing down walls. The wall between Development and Operations was only the beginning! Open organisations want their teams to act with more autonomy, so we need to give them a shared purpose around their products.
Often teams react to this by trying to embody the “You build it, you own it, you run it” mantra. How can we kick start this change in people’s behaviour? How can we accelerate our teams to be high performing? Especially when starting with a new team who knows nothing about each other… This is where our friendly Social Contract comes into play.
When I am kicking off work with a new team, I first get them to come up with a name. Team identity is fundamental in setting up the ownership part of a high performing team’s culture. The next step is simple: get the group to spend a few minutes thinking about the best teams they’ve worked with previously or the best products they’ve been a part of creating. With this in mind, think of all the amazing characteristics and behaviours of these working groups and capture them on sticky notes. Conversely, think of all the terrible projects and what things created the toxic environment the team operated in. With some ideas of behaviours we want to adhere to, the group will discuss these further to get a shared understanding and hone in on the specific language to use.
A good social contract will contain concrete, actionable items and not fluffy statements. To tease these out, lead by giving examples of how someone would embody the statements they’ve come up with, and try to capture that. For example, “be open” could be a good seed for an item in a social contract, but I think it lacks specificity. I would explore this more by getting examples of where we are, or are not, adhering to it. Teams may then come up with ideas like “Everyone’s opinion and contribution is valuable,” “Give space to the quiet person,” and “Actively listen to others the same way you want to be heard.” With some items in the contract, the group signs the contract and hangs it high and visible. It is now the responsibility of the team to abide by it and call out when others do not.
The example above is from a cybersecurity firm I worked with recently. Their team had a mix of Developers, Designers, and SREs. Some of the things they included in their Social Contract were:
Core Hours (10.00 to 16.00) - This is the team’s agreed collaboration time. This is not the hours that teams spend working, but the time in which they will have sync ups, meetings, or do pairings. In this engagement, one of the team members wanted to miss the early morning traffic, so if he came in a tiny bit later it would take him a lot less time to commute. Also, another member of the team had child care responsibilities so getting out at a reasonable hour would make his life easier.
Mob to Learn / Pair to Build - This is a simple mantra that describes how the team wanted to interact when writing code, tests, or even documentation. If there were new things to be tackled, such as a scary new microservice in a language or framework that’s unfamiliar, then do it as a full team. Get everyone on the same page from the beginning and ensure we’re not creating individual heroes with all the knowledge in the team. Pair up on implementing features to raise the skill set across the board. You can read more about pairing and mobbing in a previous blog I wrote here.
Have a Weekly Social - Celebrating success is an important event for lots of teams. Taking the time as a group to get away from our desks, socialise together, and eat together, helps build positive relationships. These events can lead to improving team morale and creating a positive culture around the people working on the product.
Blending the practice with other ones
The Social Contract, when it is first created, represents a snapshot in time. It showcases a best guess of how a team should interact, often when we know the least about each other or our habits. It is a useful tool to accelerate a team to a comfortable position built on trust and psychological safety. It is not, however, a fixed or static thing! Items could be invalid or possibly missing. A great thing for a scrum master or agile coach to do would be to bring the social contract to the team’s Retrospective. This provides an opportunity for the group to inspect and adapt, possibly updating the contract with new things.
When working with the cybersecurity company from the example above, we found a great opportunity to update our social contract. In this scenario, there were two developers on that team that were quite hot-headed, and both liked to be right. Often they could not agree on the approach to take for any given solution, which had created a toxic environment within the team, and reduced morale. Through a retrospective, the team identified this issue. After some discussion, and getting the issue out into the open, we updated our social contract with one simple phrase: “It’s OK to be wrong.”
This change had a profound effect on the team going forward. The competition within the team had started to evaporate as we could focus less on “who was right”, and more on “does the solution work for our end users.” We looked for opportunities for both developers to have their voices heard by trying more than one implementation of a feature, building both solutions, and evaluating each. The two developers then started to pair on building out each other’s solution, thus creating a better bond between themselves and others. This had a net benefit of creating a better solution by combining and building upon ideas from both individuals.
Social contracts are powerful and easy to implement as a practice - they promote team autonomy, self-governance, and psychological safety. If your teams are not using them, it’s not too late to build one. Most importantly, keep it visible on the wall by the team, and don’t forget to revisit it when needed.
Connect with Red Hat Services
Learn more about Red Hat Consulting
Learn more about Red Hat Training
Join the Red Hat Learning Community
Learn more about Red Hat Certification
Subscribe to the Training Newsletter
Follow Red Hat Services on Twitter
Follow Red Hat Open Innovation Labs on Twitter
Like Red Hat Services on Facebook
Watch Red Hat Training videos on YouTube
Follow Red Hat Certified Professionals on LinkedIn
About the author
Browse by channel
Automation
The latest on IT automation for tech, teams, and environments
Artificial intelligence
Updates on the platforms that free customers to run AI workloads anywhere
Open hybrid cloud
Explore how we build a more flexible future with hybrid cloud
Security
The latest on how we reduce risks across environments and technologies
Edge computing
Updates on the platforms that simplify operations at the edge
Infrastructure
The latest on the world’s leading enterprise Linux platform
Applications
Inside our solutions to the toughest application challenges
Original shows
Entertaining stories from the makers and leaders in enterprise tech
Products
- Red Hat Enterprise Linux
- Red Hat OpenShift
- Red Hat Ansible Automation Platform
- Cloud services
- See all products
Tools
- Training and certification
- My account
- Customer support
- Developer resources
- Find a partner
- Red Hat Ecosystem Catalog
- Red Hat value calculator
- Documentation
Try, buy, & sell
Communicate
About Red Hat
We’re the world’s leading provider of enterprise open source solutions—including Linux, cloud, container, and Kubernetes. We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.
Select a language
Red Hat legal and privacy links
- About Red Hat
- Jobs
- Events
- Locations
- Contact Red Hat
- Red Hat Blog
- Diversity, equity, and inclusion
- Cool Stuff Store
- Red Hat Summit