Tower of Babel: 5 ideas for a common language in the SE

The lowest common denominator in communication is language. This is particularly important when we want to create something together, be it a project or a product. That's why we need a standardized language in systems engineering.

But that's easier said than done: a good example is the word "momentarily", which means "for a brief moment" in British and "shortly" in American.

Here are 5 simple ideas we can use to get a grip on language.

"Interesting" means "complete nonsense"

Fortunately, it has long been known that language contains traps. As a warning, satirical texts have been circulating for ages. English-English translation aids. This may be helpful when traveling abroad, but in systems engineering we face more serious challenges.

This becomes clear when talking to customers. Clients and contractors may use a different language, especially for complex systems. For example, what does "engine" mean for an aircraft? Is it just the turbine or, for example, also the fuel supply?

In larger companies, it even happens (and not infrequently) that different departments use different terms. Something should really be done about this, as the company has full freedom of action here.

Here is a list of ideas and measures that we can use to resolve the Babylonian situation:

The customer is king, so a supplier should be flexible and adapt to the customer. We should not offend the customer. Nevertheless, there are different ways of responding to the customer:

If the customer uses a meaningful vocabulary, then we should still not let this soften our own vocabulary. Instead, we should create a glossary that translates and additionally defines the important technical terms (be sure to include the definition!). This glossary can be included as the first chapter in the specifications. It is also important that the sales department has access to the glossary and understands it.

If the customer does not yet use an established language, or uses a grossly incorrect one, then we should Training materials (without offending the customer!). The customer is often willing and even interested in learning. This is why many companies have articles, whitepapers, infographics and much more. Used correctly, such materials can drastically improve communication.

Unlike the customer, we are in charge internally and one of the most important measures is training. Most companies have a formal on-boarding program for new employees. If such a program already exists, then it can be expanded quite easily, at least for the most important terms in the organization.

Training does not necessarily have to be carried out internally. There are excellent external training programs for many topics, with and without certification. We have to be careful here not to overburden our employees. Not every engineer has to be a certified systems engineer according to SE certificate become. Instead, it makes sense to teach employees the most important things they need to know in order to collaborate and understand. For many topics, I think it makes sense to differentiate between consuming and creating. Where MBSE is practiced, for example, many employees must be able to read SysML models, but only a few create them.

In schools, a distinction should be made between "learning to read" and "learning to write". All employees should be able to "read", but not everyone has to "write".

These days, it is particularly important to enable employees to undertake further training. Some knowledge should also be refreshed regularly.

I have seen several times how effective internal knowledge transfer can be. Employees share their findings and discoveries. The following two things are particularly important here: Firstly, employees must have the time to participate. For example, presentations can take place over meals. I have found breakfast talks in the USA to be very effective: people are fresh and it costs little to provide a few bagels. There is too much clatter at lunch. The employer should definitely provide the food, which drastically increases the number of participants.

Secondly, this event should definitely be offered across all departments and employees should be encouraged to take part. For example, many engineers are suspicious of sales. But when the engineers hear from sales what is important to the customer (and how the product achieves this), they suddenly gain a much deeper understanding.

Finally, there is also the option of setting up a shared glossary or similar. I mention this point last because there are some dangers lurking here. Let's start with the glossary: creating one is a lot of work, especially in larger companies and several departments. There is a high risk that the glossary will end up being incomplete, inaccurate and outdated. But the most important thing is: if it exists, is the glossary being used at all?

It is also possible to generate a glossary automatically. I am currently developing a product that takes on this task. Learn more >>

Concepts related to glossary are Ontology and Taxonomyboth of which map the terminology even more accurately than a glossary can. While some organizations face the challenge of creating and maintaining a glossary, we need tool support in order to use these concepts effectively. This works quite well on a selective basis, but I am not aware of any sensible solution that supports people effectively and across all tools.

Conclusion

As teams are getting bigger and bigger and are often scattered all over the world, even across company boundaries, good communication is becoming increasingly important. This is an investment that pays off, as frictional losses can quickly accumulate. Finding a common language is a tactic that can achieve a great deal at comparatively low cost and risk.

In the medium term, the tools must also improve and guide us in the process. But until then, the only thing that will help is to roll up our sleeves and invest in people.

Image by Pieter Brueghel the Elder - Public Domain