When I was a kid, we used to play the telephone game. The “rules” were pretty straightforward: kids form a chain, one starts by whispering a message to the one next to them, who then does the same to the next one, and so on until it reaches the last one who would reveal the message. There is no individual winner: either the message is transmitted properly and the team wins (which, in a kid’s perspective, sounds pretty boring), or the message got distorted and the team loses, but it gets a good laugh.

This game seems to be pretty common across the world, and it also seems to exist in the world of software development. When I think about the lack of collaboration between designers and developers, I can only think about three-year-old Virginie putting her hands around the ear of another kid and whispering ‘if the user tries to validate the form without all the required information, then the system should return an error message’ to hear at the end, ‘if the text field called ‘name’ contains more than 8 characters, then the whole form is reset, and an ‘error 637’ message appears in the bottom right corner in red on black’. Verdict: our team lost. So did our users. So did the trust. So did the passion for the craft. And none of this is ok.

Let me say it again: none of this is ok.

How did we get here?

We can all agree that whispering the expected understanding of our work to the ear of the person next to us will get us nowhere, or even worse, to the wrong place. It is not a good practice. However, we continue to deliver our work, and silently expect it to be interpreted the right way as we let go of the control and ownership.

The telephone game is a classic problem encountered by teams with siloed domains of expertise. Roughly put, a set of requirements is expressed by the business and translated into a backlog where Design will attach some screens or a prototype. Development then picks it up and can only assume most of the answers to potential questions, because Design is already focusing on something else as stories in the backlog keep appearing to fulfill the business’s needs.

Even though nobody in this scenario is to blame, everybody owns a part of the solution. Let’s look closer at what is going on.

Lack of autonomy

Working in silo takes away the autonomy of the team. Siloed work turns everyone into a part of the chain and, unless individuals demonstrate a strong will and power of initiative, it also takes away opportunities to change the direction of a product.

Lack of ownership

Because of how the workflow is designed, nobody can take the initiative of changing the pace, or the logic of it, without having to handle an imposing and potentially unknown amount of consequences that go beyond their usual line of influence. Therefore, it becomes a safe choice to follow the dictated path to delivery: stay in line, go with the stream, maintain the pace, complain at the next retro, rinse, and repeat.

Lack of connection

As for the telephone game, if one element in the chain fails, the whole chain fails. Imagine the degree of responsibility carried by each contributor in the chain. It would make sense that no one wants to be the failing link. Therefore, creativity, ownership, and accountability have to be apprehended with deep skepticism and reserve.

Fear towards the building values

Creativity, ownership, and accountability: the three things expected from software crafters. Three things that we need to build innovative, impactful, and sustainable software. Three things that we take away from talented people when we put up walls instead of building bridges.

Blowing up silos. Building bridges.

To build bridges, you will need the following materials: empathy, shared vulnerability, and a desire to do the right thing.

Empathy 

Empathy is the ability to put yourself in the shoes of someone else, and to acknowledge their pain before trying to lower or solve it. The words we say when we express empathy are ‘that sucks, you are not alone, I am here with you’. With empathy as the pillars of your bridges, team members don’t feel alone, regardless of whether they’re facing success or failure.

Shared vulnerability

Creativity is the ability to generate and give life to original solutions for actual problems. Being creative requires you to lie comfortably alongside vulnerability. This is why fostering psychological safety in a team is vital. Shared vulnerability not only brings people closer together, but it also gets them to be more eager when challenging status quos. When vulnerability is shared, team members are confident in choosing courage over comfort.

Doing the right thing

Being right, making a point, and having an opinion may get you somewhere fast but it will get you there alone. There is no need to be right, as being right is lonely and monotonous. Aim to stay in this equilibrium state where everything is possible, and no judgment is blocking the flow of your creativity. With no urge of being right or wrong, every day is an ‘everything can happen’ day. Indeed, while being right or wrong is not worth anything, doing the right thing is priceless.

Forcing an organic process

The human brain loves connecting dots. And this is actually how we build habits. By actively trying to build bridges in our teams, we design a new set of habits.  At first, it requires strong intrinsic motivation and the ability to handle a lot of vulnerability, but I can guarantee you it is worth it and rewarding (been there, done that, got the reusable water bottle).

Eventually everything connects - people, ideas, objects. The quality of the connections is the key to quality per se.

– Charles Eames

Ultimately, by actively collaborating between the different domains of expertise, we can connect what we do with why, and how, we do it. This is a full circle of collaboration, and it is why it feels so good when we don’t just work like an element of the chain but like a connector.

Turning theory into practice

While the theory of building bridges is very inspiring, it is fair to ask ourselves how to turn this theory into practice. What can be done inside teams to increase and consolidate collaboration?

Pairing

Pairing is a powerful practice. While it creates a shared understanding of the problem and its solution, it also considerably increases the empathy, consolidates human bonding, removes the feeling of loneliness, and provides short feedback loops. Often perceived as reserved to developers, pairing can be practiced cross-discipline. Look in the backlog, there will surely be a need for design improvement, pre-delivery research, story grooming, documentation updates etc.

Documentation

A product can have different types of documentation, from technical to more traditional – like a user manual or FAQ. Indeed, explaining to end-users what the product is about, how it works, and what its boundaries are, is a must-have for every product. As documentation is usually the first step of collaboration with non-technical members or new joiners, it is recommended good practice to have it easy to modify.

Style guide 

A consistent product will have a defined collection of all the styles, colors, typographic elements, and recurring components. Those elements are subject to repetitive implementation, and maintaining them creates a splendid room for collaboration between designers and developers. While it is likely to be messy at first, building a living style guide gets rewarding very fast. Reusing elements from the style guide saves time that the team can dedicate to thinking about the future of their product. 

Persona

To keep in mind the needs and pain points of users, a team will often welcome some fictional characters called a persona. Personas are a shared working tool and building them as a team contributes to having more empathy towards the user, and getting a shared understanding of the overarching goals, problems, and journeys. Moreover, it is a fun activity to do together as a team. 

Sketching

Because it requires drawing some shapes, it is a common misconception to believe that sketching is reserved for designers. The goal of sketching is to cheaply envision potential solutions for a given problem. As it contributes to creating a shared understanding, and to discussing the feasibility of the solution at a very early stage, it is a great opportunity for collaboration. The team can plan a sketching activity for various upcoming epics in the backlog, or also sketch together at the whiteboard when a problem occurs (remote version: each member sketches on paper, takes a picture with their phone, and adds it to a shared document). By the way, anyone who can draw a straight-enough line, a squarish shape, and a roundish-enough circle can take part in sketching. 

More activities that can be done cross-discipline are usability testing, answering support requests (even if deeply technical), regular show & tell, reviews, ideation sessions, backlog grooming, drawing of the data model, and competitors analysis. 

A praise for building bridges

Full collaboration and autonomy might sound a bit like a trust fall, and in a way, it is. As team members, we craft software together, sharing vulnerability and ownership. We connect more than we contribute. We value how and why we do things as much as what we do. We don’t feel alone, we feel together. We don’t just build software, we also build a culture: a culture that will organically scale up as long as its individuals feel safe choosing courage over comfort. 

To technology and product leaders, bring your people together, and support them every step of the way as they try, fail, learn, and succeed. Developers and designers, stop contemplating the gaps between you, and start building bridges towards each other. You already have what it takes!