73. Babel

The project fails to develop a consistent language that’s understood by all members of the development team and stakeholder community.

We expect to be understood—and most of the time, that’s a pretty safe assumption. When the people we are talking to share our contextual and cultural space, our meaning is usually communicated without distortion. In an English pub, when you ask for a pint, you get a pint of ale. Ask the driver of an electric dairy car in London for the same thing, and you’ll get a bottle of milk. Similarly, when you are talking to a co-located fellow team member about the network status or the customer discount rate or any other term you use in your project, you expect to have a shared understanding of the meaning.

It is this optimistic expectation of being understood that prevents you from asking, “Does he really mean the same thing I do? Are we simultaneously nodding yet speaking different languages?”

Babel is encouraged by the fiction that organizations have a common language and that as long as every project uses this language, all will be well. But organizations are large, dynamic, inconsistent creatures, and terms like service, order, asset, policy, customer, employee, and discount have very different meanings, depending on their context of use within a project. Rather than rely on the wishy-washy generalities of org-speak, every project needs to define its own common language. The degree of formality and rigor required depends on the likelihood and seriousness of the risk of being misunderstood, with loss of human life at one end of the scale and minor financial loss or irritation at the other.

The risk is increased by any of the factors relating to differences between individuals, such as domain knowledge, life experience, linguistic background, or personality traits. The list becomes longer when you consider other influences, such as geographical separation, assignment to parallel projects, and outsourcing to other organizations. Many organizations grow through acquisitions, and each acquired company has its own idiosyncratic language that may have to be decoded and normalized by the new parent company.

The language you need for your project is a living language that truly reflects what all the team members are learning about the problem space. Cultivating the language means progressively defining your terminology in writing, to reflect your growing understanding. This also means making those terms easily accessible and extendable by everyone on the team.

When a team does develop a consistent language, the effort may be almost invisible from the outside. But inside the project, the participants are willing to focus attentively and repeatedly—almost obsessively—on definitions. The successful team is the one that does not accept the fiction that there is already an organizational common language. It is willing to refine and refine again in order to build its language, the one that will protect the project from Babel.