As humans, we like to label things and put boundaries around them. As we have limited intellectual and information-processing capabilities, this helps us abstract otherwise complex concepts and use them in building even higher-level concepts that we can use to explain, predict or create things. Of course, the nature of this process is that it helps us ignore the vast number of aspects associated with a concept and focus on a very small number of remaining aspects that are considered to be integral to the notion itself.
When we work in teams, this is even stronger as we tend to build a team or organizational vocabulary that helps team members communicate efficiently. We all know of the TLAs (three-letter abbreviations) most companies use. Of course, it doesn’t only concern efficiency but also points to an insider-versus-outsider perspective as the comfortable use of TLAs signals that you’re ‘in the know.’
The challenge with referring to “the system” is threefold. First, it can easily lead to misinterpretation. The term “system” has quite a few interpretations. Of course, the basic one is where we refer to “a regularly interacting or interdependent group of items forming a unified whole.” However, there are many other definitions, including the capitalist system, the Newtonian system of mechanics, the system of species or a systematic process for accomplishing a particular task.
In addition, drawing the boundary around a system is often particularly hard. Any system we refer to is typically part of a larger context. It usually has difficulty operating on its own without the context being present. Similarly, the parts that make up the system often can be considered independent systems themselves. Considering a system as a unique, stand-alone, independent entity generally is conceptually wrong. Hence the term “systems-of-systems,” which appears more and more frequently in the last decade.
Even within the same organization, the actual interpretation can easily differ in non-trivial ways. This can easily lead to confusion or even conflict when people operate under different definitions of the same term. In the embedded-systems industry, a typical definition referred to the physical product being sold to customers. However, with digitalization and connectivity, for most companies, the system encompasses the physical product as well as the mobile application to interface with the product and the cloud solution to store data and functionality not incorporated in the physical item.
A second problem is that, in many contexts, the system can become a fixation for the organization, meaning that everyone is considering it to be the source of all problems as well as where the solution has to originate from. As Einstein famously said, no problem can be solved by the same level of consciousness that created it. This is also true for systems where many problems are created by outside forces.
For example, I’ve worked with many companies on platforms and I often am brought in when a platform fails to deliver the benefits everyone expected when it was first created. A typical pattern is that requests for new functionality and new configurations of the platform take too much R&D effort and time. Management wants to know what the problem is and often leans toward outsourcing and getting rid of the idiots in R&D. Often, though, the situation is that the platform hasn’t received any resources for architecture refactoring and technical debt management for years. Instead, numerous customer requests have been forced in with hacks instead of proper engineering as the business side prioritized closing the next deal over maintaining the long-term integrity of the platform. In this case, the platform and R&D organization aren’t the problem, but rather the challenge is outside of the system’s scope.
Third, focusing on the system very often becomes an excuse for not making the necessary changes in the organization. By simply stating that the system is the problem but that we have no way of changing it because of “reasons,” it becomes easy to keep going forward with the anchor holding you back. The challenge in this case is that each individual is correct in that from their perspective, it’s impossible to change the system. It requires a coordinated, cross-organization effort to actually drive the necessary changes in a system-wide fashion. This, however, calls for coordination and action outside the scope of the system itself.
An illustrative example at the business ecosystem level is where companies are held hostage by others in the same business ecosystem. In a value chain, especially upstream partners are explicitly told not to change and adopt new technology. The threat is that this partner will be ostracized and kicked out of the system and replaced with someone else who will play ball. This is of course a great way to maintain the status quo in the short term, but it’s devastating in the long run. If individual companies in an ecosystem don’t change continuously, it will cause an ecosystem-wide disruption, replacing all companies with a new set of players serving the end customer in a better way.
There’s no such thing as “the system.” Of course, we can use the term in our work, but we have to be very careful to ensure that everyone uses the same meaning. Also, we need to avoid getting fixated on the system itself and realize that there are layers below and above to consider. Finally, we should never use the system as an excuse to avoid or delay change. As Edwards Deming so eloquently said, your systems are perfectly designed to give you exactly what you’re getting today. If what you’re getting isn’t what you’re looking for, it’s time to redesign your system.
Want to read more like this? Sign up for my newsletter at jan@janbosch.com or follow me on janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch), Medium or Twitter (@JanBosch).
