Systems engineering: understand each other to engineer together

Table of content

Introduction

Communities and languages

Communities

Linguistics

Finding the right name

Designing a system

Use case 1: brakes

Use case 2: lockers in touristic areas

Points of view

Interrelated systems

Designing a system organisation

Who’s in charge?

Mirroring

Systems organisation

Conclusion

Introduction

There’s a lot of literature on Systems Engineering. There are some methodology books. There are trainings, undergraduate or graduate. There’s an international council (INCOSE). And even a norm, ISO15288. Many businesses talk about it. And yet, it’s very hard to find an agreement on what it is. Some say there is no such thing, today, as real Systems Engineering. Some say everybody’s been doing systems all their lives, but they just didn’t call it this way. There are jokes on professional networks that if you gather 10 systems engineers to agree on what a system is, you will get 11 definitions.

Systems methodology has been described over and over, and yet, it is still hard for non-expert to grasp what this is all about. Some team members report that the department should do systems? Other team members report they’re already doing systems? External consultants propose to help you manage your systems? They all have a clear vision for you, they’re all consistent, but they also all use the word systems differently.

As the saying goes, when everybody is in charge, nobody is in charge. When everybody has a different understanding of Systems Engineering, nobody understands it. Before applying any kind of system methodology, it’s mandatory to ensure there is a common language between the teams.

Stephen Hawking said the greatest enemy of knowledge is not ignorance, it’s the illusion of knowledge. Applied to team’s collaboration on complex systems, the greatest enemy of understanding is not misunderstanding, it’s the illusion of understanding.

To ensure efficient delivery of a large system, it is necessary to ensure efficient communication, which means ensuring good understanding between teams. This good communication requires the right organisation, the right interfaces between teams. Systems Engineering is supposed to manage these interfaces, but the word System is a perfect example of the illusion of knowledge. Systems Engineering is understood differently by different teams. If the team don’t even agree on what the methodology means, how can we be sure they will agree on the product they’re working on?

The objective of this book is to raise awareness on the risks of misunderstanding, and to propose solutions to handle these risks, using tools to set up an organisation where teams robustly understand each other. This is why I’ve chosen to write a book about language and engineering. With linguistics as our guideline, we will lead the way towards better engineering through better communication between teams.

In a first section, to clarify what better communication means, we’ll first have a look at the importance of language, which relies on context, mindset, non-verbal exchanges as much as words, maybe more.

We’ll then see what it implies on defining a system, by looking at a few examples. We will see that a good definition is not just words, because words can be interpreted differently. A good definition is a complete description of the context.

In a third part, we’ll give practical tools to set up an organisation where teams from different background can understand each other, a prerequisite for efficient collaboration.

Communities and languages

People speaking the same language form a community. People gathered in a community need a language to communicate. We can’t talk about one without the other. We’ll start by looking at communities, why they need language, and then we’ll see the importance of language, from a practical and theoretical point of view. All this information is general, not specific to Systems Engineering, but the awareness of the traps of language and the understanding of how the principle of communicating through language will help us understand the constraints of Systems Engineering.

Communities

Human villages (or businesses)

In a small village, everybody knows what everybody else does or can do. Back in the days, jobs or skills were part of the names, which is why there are many Smiths and Coopers as last name. Today, it’s less obvious, and in towns or cities, or in medium to large businesses, it’s not easy what is everybody’s role.

Knowing naturally what everybody’s role is requires a special condition, size matters. In a small group, like a small village, all the villagers know each other. But the larger the group becomes, the more difficult it is to know everybody.

The threshold to manage direct relationships between members of a group is around 150 (for humans). Below this number, any individual can manage to know about everybody else. It’s not necessarily a close relationship, but it’s still a relationship. Above this threshold, individual one to one relationships can’t be sustained.

The same number shows up in different areas, for instance in management (maximum size for a department) or in military organisation (maximum size for a company).

It comes from experience, but there is also some science supporting it. Anthropology studies our primates cousins or our ancestors. Analysing several different primate species, research showed there’s a correlation between the group size of a species and its brain structure; more precisely, the size of the neocortex. The neocortex is the part of the brain managing high level functions, such as spatial reasoning or language. When the neocortex represents a large portion of the brain, individuals can successfully manage more parallel relationships (Dunbar 92), and the maximum size of a manageable group will be higher. The more intelligent a species is, the bigger the groups it can manage. The individual brain power enables the collective power.

For homo sapiens, based on human neocortex ratio, theoretical estimations predict 148 individuals in a group. This value is confirmed by observation of hunter gatherers population, with an average group size of 153, giving a good level of confidence on this socio-biological threshold, confirmed by business experience.

When the group exceeds this size, it requires an additional level of organisation. In the history of the human race, there is evidence that the need for management of larger groups led to the rise of language. When the groups were small enough, individuals would socialise through direct contact, with activities such as social grooming for instance. Grooming has health benefits of its own, but grooming another member of the community is also a way to build relationship. It can also be used as a conflict resolution tool. Our close cousin bonobos also use sexual intercourse as a conflict resolution tool. (Note that we will definitely not recommend grooming or sexual intercourse as a conflict resolution tool in a business context, even in small businesses).

In larger groups, it was not possible anymore to use this kind of tools. Verbal communication became necessary to enable exchange in the group or to resolve conflicts. The growth of the groups size, enabled by enhanced cooperation and the shift from foraging to farming, may be the reason for the apparition of language. However, we must admit this is only one of the many theories regarding the origin of language, and it is widely disputed. The origin of language is so controversial a topic that the Societé Linguistique de Paris (Paris Linguistic Society) simply banned it when it was created in 1866 (Article 2: the society forbids any communication regarding the origin of language or the creation of a universal language).

However it appeared, language was a new way to exchange information within a group. Language is not specific to humans. Different species also have some kind of languages, from our primate cousins to the much more basic insects such as ants or bees.

The specificity of the human language is its capacity to describe not only the things which are, but also things with don’t exist. Linked with language was the apparition of fiction, invented by homo sapiens. To enable collaboration within groups bigger than their brain can handle, populations have to share a myth or a belief, or a sense of belonging to a nation, or a purpose in a group enterprise (Sapiens, YN Harari). We won’t debate religions or politics here, and we’ll focus on businesses, but the concept is the same in all these different situations.

We use the word fiction here not as something which is false, but as something which is created by the human mind. A country can be defined by its boundaries and institutions. A business can be associated to its facilities and its products. Money can be implemented in coins and notes. But these concepts hold only as long as the group believes in it. If people stop believing in money, the coins and notes still exist, but they are not money any more, and become worthless.

Money is particularly interesting as a fiction. The first homo sapiens didn’t have money, they would exchange goods. When technology improved and there were too many goods to handle, it became necessary to introduce money to manage growth. Money, like language, is an invention of the humans to handle interactions between large groups.

Because of the limitation of the brain capacity, larger groups need a common fiction, and the language to describe it. However, that’s not enough. A larger group can’t be managed as a smaller group. Small tribes can be egalitarian, without a need for structure. When the group size exceeds its threshold, it has to be split into smaller groups. This leads to hierarchy as well as specialisation (Naroll 1956, Forge 1972). We are still citing anthropological studies here, but it does apply to gathering of humans in a community such as a business.

Hierarchy comes from the need of connecting and structuring the groups. Alternative to this structure is isolation, or even conflict between the groups. We’ll come back later to hierarchy, in the context of systems.

Specialisation is required for optimisation of a bigger population.

In old times small villages, everyone had a speciality. As the village is small enough, they could afford to skip the formal roles and responsibilities allocation. Any small business can also skip the structuring activity. Startups can bring incredible products and services with unstructured small teams. But there are things which require bigger structures. Apple has about 100 000 employees, Google more than 70 000 and Tesla has reached 30 000 in 2016 (from 3 000 in 2012, which was already much more than 150…)

Small businesses don’t have specialisation issues. Thanks to their small size, they can reach efficient interactions between their employees naturally. Interviewing engineers in various context, it appears clearly that the problems faced by organisations are very dependent on the size of the business. Some issues are universal, for engineers, and even for salesperson (define the problem before the solution), but lack of understanding or lack of communication between employees, is not something small businesses report as a priority.

However, if your company has more than 150 employees, direct communication won’t work any more. Obviously, it gets even worse, if your department within the company has more than 150 employees.

The transition from a small business to a large business is not easy. Similarly, the handover from a small team to a larger team, within a large business, does not come naturally. Usually, innovations are handled by smaller, independent teams in research department or in innovation labs. Their small size enables more flexibility, better efficiency between the team members. All the stakeholders can be gathered in one place. But once the innovation is defined, it needs to be transferred to the bigger team. Activities handled by less than 10 people in advanced engineering, to define the concept, may end up involving 200 engineers split across 10 departments, when the time comes for delivery, manufacturing, maintenance, etc.

What was done informally within the small group needs to be done formally for the bigger group. A small group will develop a common vision naturally. A bigger group needs leadership to cascade their vision. To reuse Harari’s vocabulary, the vision is the fiction which will join the whole group. To ensure smooth communication the fiction needs to be shared, through a common language, to enable connection of all the sub-groups. Language is of primary importance. In a small group, the vision is shared through direct interaction. In a large group, vision is transmitted through words, whether orally in conferences or in written form in documents. If the language used for transmission of information is not shared by all the employees receiving it, then the information will at best be lost, at worst be misinterpreted.

When we mention common language, we’re not referring to English or French. Even people speaking the same language can misunderstand each other because they use this common language differently.

When I started working, my first job title was diagnosis expert. As a young graduate, I had little idea of what diagnosis was. During my induction, discussing with all the teams involved in diagnosis, it became clear quickly that everybody had their own idea about what it was, but there was no unified vision.

For the electrical engineering team, diagnosis was just about communicating with Electronic Control Units (ECU). There was a standard protocol for on board diagnosis. If you’re using this protocol, you’re doing diagnosis, period.

For the manufacturing team, diagnosis was historically about end of line control of the newly build cars. The activity had evolved into more complex activities, such as programming ECUs or pairing smart keys, but electronic end of line activities was still mostly called diagnosis.

For the aftersales team, diagnosis was about solving the customer problem at the dealer. If you’re sick, you go to the doctor and they will do a diagnosis, and prescribe a treatment (medication, rest, surgery, etc.). Similarly, if your car is broken, you take it to the dealer and they will do a diagnosis, and prescribe a repair (part replacement, etc.)

Being at the center of these 3 worlds, Engineering, Manufacturing and After Sales, I gradually learned the different meanings, but it was clear that using the same word for different concepts could be a problem.

The focus at this time was the after sales. That was back in the early 2000’s, when the mechanical technicians were struggling with all the great electronic technologies engineers had introduced in the car.

When developing a new diagnosis tool for the dealer which embedded the service manual (diagnosis and repair