Previously I have written about the power of sharing context in order to create high functioning teams. Some of the areas of context I talked about were: product direction, customer needs, business goals as well as organizational structure. Notice each of these dimensions points outward from the team. And this is key. High functioning teams cannot just be inwardly high functioning; they must be high functioning outwardly in how they collaborate with other teams to accomplish the larger mission. And for this type of collaboration to occur, there must be a common language understood by the different teams.

A big barrier between teams effectively sharing context or having a shared understanding is the fact that different teams speak different languages.

Amusingly it is bit like the Tower of Babel story from the book of Genesis (Bresheit) in the Bible/Torah:

Genesis 11:1-8

1 Now the whole world had one language and a common speech. 2 As people moved eastward, they found a plain in Shinar and settled there.

3 They said to each other, “Come, let’s make bricks and bake them thoroughly.” They used brick instead of stone, and tar for mortar. 4 Then they said, “Come, let us build ourselves a city, with a tower that reaches to the heavens, so that we may make a name for ourselves; otherwise we will be scattered over the face of the whole earth.”

5 But the Lord came down to see the city and the tower the people were building. 6 The Lord said, “If as one people speaking the same language they have begun to do this, then nothing they plan to do will be impossible for them. 7 Come, let us go down and confuse their language so they will not understand each other.”

8 So the Lord scattered them from there over all the earth, and they stopped building the city. 9 That is why it was called Babel—because there the Lord confused the language of the whole world. From there the Lord scattered them over the face of the whole earth.

I love the phrase, “If as one people speaking the same language they have begun to do this, then nothing they plan to do will be impossible for them” when applied to product development teams! If we could get teams to understand each other, nothing would be impossible for them!

Teams multiply their effectiveness when they develop a shared understanding of the needs of the customer and the needs of the business. One key ingredient of this is getting teams to understand the other team’s unique language. There is a real need for creating a shared vocabulary across teams.

When I joined Netflix, it quickly became apparent to me that the engineering organization and the design organization spoke different languages. It was a virtual Tower of Babel.

The design organization was internally high functioning. The engineering organization was also internally high functioning. Yet, there was a lot of friction between the teams. One place this manifested most clearly was in Design Review Meetings (a weekly meeting where the Design team presented the design plans to the rest of the organization and received feedback). They were just painful. And dreaded by all. They became known for the rancor they engendered when designs being presented were immediately challenged. And often harshly. Designers became reluctant to share any work that wasn’t fully finished for fear of it being attacked. Engineers felt like designs were being foisted upon them with no chance to be part of the process. And frankly both were justified in feeling this way. It became so bad that one point the leader of the meeting instituted a rule that no one could speak unless they raised their hand and were given permission to speak by him.

I also saw it in the vocabulary that the teams used. Engineering spoke in technical terms that focused on the how of building the product. Design spoke in more general terms about what the product should look & feel like. And because of the training and tools used by each, they spoke in different languages.

Netflix Round Table

So what did I do? With the head of design, I organized a Friday afternoon design & engineering round table. The idea was to bring the teams together in an informal setting, have some snacks and break the ice with casual conversation. In Netflix tradition that was often discussing movies we had recently watched. The rules were simple:

• It was a required meeting
• It had no set agenda
• Questions would come from the individual team members
• The focus would be on asking each other questions about the challenges the other teams were facing
• No blame was to be assigned, but eagerness to solve problems was encouraged
• Leadership was to listen and not interject

I remember the first meeting vividly.

Engineer: I hear designers using the term “Lock Up”. I think I might know what that means, but where the hell does this term come from and can you explain it to me?

Designer: Oh! Many of us come from the brand/advertising world. As an example, a logo can have multiple elements that when put together forms a “lockup”. Or you might have a product logo and a brand logo that have to go together a certain way. That is also a “lockup”. So when we mention “lockup” on the Netflix web site, we are talking about the box shot, the description text, the star rating and the Add to DVD button. All these together form a “lockup”.

Ok, so this is interesting. I had been at Netflix for a year. Many of my engineers and the designers had been there even longer. They had used the term lockup all throughout that time. Yet, never, ever, had an engineer been brave enough to ask a designer what is a “lockup”? Why? because if we don’t ask the first time we hear it, then everyone assumes that everyone else knows what it means. The longer the terminology is bantered about, the harder and harder it gets to say, “hey, I have heard this term for 18 months, what does it mean?” That is hard to do in the normal daily work environment.

But the roundtable created an environment that gave questions like this permission to be asked. It was ok to admit that someone didn’t understand something about the way the other team worked.

Engineer: I get it! That makes so much sense now. 

When getting to a shared understanding, a shared purpose, a shared vocabulary is a key goal of the teams, then it is never embarrassing to admit that there is something you don’t understand! Instead it becomes part of the learning journey. It builds respect between teams. They switch roles teaching & learning. Instead of languishing in misunderstanding.

The next question that came up in that same meeting was from one of the designers.

Designer: Why doesn’t your team use CSS (cascading style sheets)?

Engineer: (puzzled look)

Designer: I have heard some of you talk about how hard the site is to style. Wouldn’t it be easier with CSS?

Engineer: Well, actually we do use CSS. In fact one of the problems is we have WAY too much CSS. The CSS we have is bloated, not well structured and we are trying to rewrite it. Also the site is hard to change not really because of the CSS, but because of the way we have to generate our pages.

Then at that stage a really fascinating discussion took place where the engineers walked the designers through what they have to do to take the beautiful designs and turn them into code. Talk about the design team getting to a shared understanding and developing some serious empathy!

These round tables went a long way to creating a shared understanding and raising the bar on our experiences at Netflix. It spilled out of the roundtable discussions and began to happen on a daily basis.

Travelocity Babel

I saw something similar happen many years earlier at Travelocity. I was called in to see if I could bridge the gap between the design and engineering teams. After a half an hour of finger pointing, I finally asked the engineers if they had ever been part of or watched the process of creating the designs that they received? No was the answer. I turned to the design team and asked them if they knew what happened to their beautiful designs after they handed them off. No, actually they hadn’t. 

So what did we do? I asked a few designers to shadow engineers for a day to understand every step of the process. And I asked a few engineers spend time with designers as they created specs. What transpired was they begin to speak the same language as it began to express the whole process of bringing design to life. Designers altered the way specs were created & delivered and engineers changed the way they built their components based on learning each other’s context and learning each other’s ways of working. Their language became common.

It’s a good exercise to began to notice the way different teams talk about the product. The executive, sales, marketing, product, design, engineering, and other teams build unique dialects. These really restrict the flow of information and a shared understanding. Once you note these different dialects, see if you can bring key members of these teams together and discuss the customer, the product, the business together and see where the mismatch is. Allow the teams to ask questions that might appear dumb. The various players will take turns teaching their language and learning a new language. Your customer and your business will thank you.