Wittgenstein on Business Process Management

Those familiar with the Anglo-Austrian philosopher Ludwig Wittgenstein know that one usually distinguishes two Wittgensteins: The earlier one who wrote the “Tractatus Logico-Philosophicus” (1921) and the later one who is best known for his “Philosophical Investigations” (1953). Both oeuvres contradict each other. The later Wittgenstein distanced himself from the earlier one.

Put in a nutshell (grossly oversimplifying and distorting his work), the early Wittgenstein says meaningful language about the “real” world needs to refer unambiguously to the “things” out there in the real world, things which “are the case”. He believed that in meaningful language everything out there can and should be referred to by one signifier respectively and if the thing out there exists and the sentence claims its existence the sentence is true whereas it is false, if the thing, despite being proclaimed to exist, is actually “not the case”.

The later Wittgenstein argues that language is a “game” with permanently and subtly changing rules. Members of such a “language community” understand the game although there are no written rules for the game, as it changes all the time, if only gradually. They understand it by way of practicing it, playing it. If a thing out there exists or not is a metaphysical issue. Nobody knows for sure. And it doesn’t matter. For the only thing that matters, i.e. what is meaningful, is what people come to agree upon by using their common “language game”.

In stark contrast to the early Wittgenstein, the later one thus proclaims that signifiers or nouns which denote “real” things like “chair” or “table” are not mental impressions of those things. Rather, these words derive their meaning from how they are being used by the respective language community. The idea of an eternally valid relationship between a thing out there in “reality” and a corresponding word is, according to the late Wittgenstein of the 1950s, a nonsensical supposition, not least because it is impossible to arrive at valid definitions solipsistically by oneself, i.e. without engaging in “language games”.

Today it is generally held, and this is independent of any particular philosophical creed like “realism”, “anti-realism” or “idealism”, that both of Wittgenstein’s positions, the earlier one of the early 1920ies and the latter one of the 1950ies, are somewhat elliptic, i.e. interesting but insufficient. But that has and will of course always be the fate of philosophy. The early Wittgenstein thought there is no point in talking philosophy anymore, because his Tractatus delineated the boundaries of meaningful language and “where of one cannot speak, thereof one should remain silent”.

So, how and what can all this possibly bear on understanding business process management?

I think, if one takes a step back from fundamental philosophy and last questions and simply accepts i) that – e.g. in the case of sales processes –  certain “things” like paying customers do exist out there and if one also accepts ii) that it is important for successful process management to define in a perfectly unambiguous way what it takes to arrive at such a customer, i.e. what measures need to be undertaken in what sequence to arrive at such a customer, then Wittgenstein A (the early Wittgenstein) and Wittgenstein B (the late Wittgenstein) surprisingly both meet, shake hands and indeed come in extremely handy. Why? Because in process management you connect a procedural “game” which everybody who is taking part (the team) needs to understand in exactly the same way with something you wish to earn or win by playing it properly. And this thing you want to earn (e.g. cash, certain growth, a flawless product, savings, whatever) is not an integral part of the game, but the result of it.

As a (process) manager it is crucial for me to have both the inputs and the outputs of my processes be defined in a perfectly unambiguous way. It is no good, if my team members each understand my or their inputs and the expected outputs differently. If person x in a sales department defines a sales lead in his or her personal way and person y understands it in his or her personal other way, then it will be impossible to manage and control the sales organization. So, there must be an agreed and accepted language game “sales” within a successful company. This must be game, where the rules are being laid down clearly and unambiguously. And the same holds for every other business process as well: Quality management, product management, production, marketing, advertising, you name it.

As manger or product owner you may want to “dictate” the rules of the game to your team members (“This and this is the required quality” in quality management) or you may want to let them agree upon the rules in a consensual way (Wittgenstein B). What matters in the end is not, how you arrive at the rules of the game. What matters is that the rules are being observed and followed in exactly one way (Wittgenstein A), because only then will you be able to control and manage the game, learn from the way you and your team are carrying it out and become both more efficient and more effective in the sequel. An open Wittgenstein B-type language game without neat and precise definitions (as demanded by Wittgenstein A) should be a no-go for you as a manager. How would you coordinate a team whose members do not “know” where it stands at a given moment in time?

Common sense tells and experience also shows us that rules are being followed more readily, more effectively and more efficiently, and foremost more consistently over time, if team members have a say in defining them. Also, it is important to recognize that definitions might change and at times even should chang, because circumstances change, people who carry new ideas will join your team, will bring new experiences into the team and might expect or operate on the grounds of alternative definitions for the loops and steps of your workflows. This is where Wittgenstein B comes into the game.

The Wittgenstein A game could be automated if, and this is a huge “if”, there was no ambiguity as to the respective stage of processes, i.e. if all team members always knew and agreed on the stage of a process at any given point of time. If this was the case Business Process Management Software (BPMS) could play the early Wittgenstein game (which according to the early Wittgenstein is not a game but simply the only meaningful way how to linguistically engage with the empirical world out there), because every understanding team member would understand intuitively, how to produce an outcome.

However, we know that software by itself does not get you anywhere. It’s the oft told topic: You may have got a wonderful tool, but if you don’t know how to operate your core game, the tool won’t help you much, or actually won’t help you at all.

Your team may actually move along these “Wittgenstein A” – tracks. But understanding the stages of the respective processes unanimously won’t happen by itself or by BPMS. What is required of a team is a uniform interpretation of what has been achieved so far and what needs to be done. Here you need a language game of the Wittgenstein B sort. And the really absolutely essential issue here is how to secure, that everybody perceives the stages reached so far in exactly the same way? According to Wittgenstein B this won’t necessarily happen (there are no rules for the game) and does not need to happen ether, because it would be sufficient if team members grasped by and large where they stand and where they want to go. For business processes such a by and large understanding evidently does not work very well. At the same time everybody knows that most of the time you will find that there are as many different notions of process stages in a room as there are team members present.

Now, how does one bridge this gap between Wittgenstein A and Wittgenstein B? How does my team appropriately assess where it stands before it decides to advance from stage x to stage y?

Philosophically there really is no solution. Not an easy one and not a complex one either. Practically however there is. The best way to solve the dilemma is by means of protocols. Before you advance to step y you need to ascertain whether step x has been executed appropriately by your team member/s.

And who decides, if step x actually was executed appropriately? Well, again: your team (ideally as a whole). The team might agree to decide by majority votes, consensually or in any other way. What matters is that the decision-making process is protocolled just as the precedent and following steps are. If, for instance, your production processes were carried out lege artis, but the resulting products do not meet the required predefined standard of, say, 0.1% failure rate/deviation from unambiguously defined quality norms, you need to either redefine the processes to arrive at a better rate or check, if the respective steps were protocolled appropriately. Just one person will not be able to make an appropriate assessment. He or she might be biased, or afraid or simply guided by motives which are alien to the quality cause. It is by means of discussion, by executing the quality language game among all team members that the solution will become apparent. This is how you will eventually succeed in arriving at real success out there in the world. So, if you find out in retrospect that the results of your processes actually do not meet the standards which a process was supposed to guarantee you can always retrace the process by means of the protocols and discuss, if either the process or the execution of the protocols require amendments.

Why are protocols so important for procedural success? Because they are the only connection between publicly certifiable outcomes in the real world and individual and/or team inputs. In corporate, start-up or even public practice, alternative ways to achieve procedural success simply don’t work. If you do not define a wished-for outcome by agreed compulsory inputs in an agreed sequential order by means of agreed definitions, you will arrive at people seemingly talking about the same things and using the same words, but meaning entirely different things. And that is deadly for any process.

Will it be possible to automate this hybrid Wittgensteinean workflow game? That’s an interesting question. We will discuss it next year. Merry Christmas and a good 2019 to everybody!