The idea of silos was not new to me when I joined Covestro.
When the DSM business units were formed in 1992, several central services were dismantled or heavily decentralised. Maintenance was one example. People who had previously belonged to the same functional organisation became formally colleagues in different business units.
For the plants it meant that people from different central departmens became colleagues in the same organisation.
That did not mean that cooperation emerged automatically. We had to learn how to work across the new boundaries. “Destroy the silos” became one of the familiar expressions for this.
People like me, with a more academic background and increasingly involved in managerial and coordinating work, were often asked to help make that happen. I experienced this, for example, in my work with the Applied Research department after it had been decentralised. Working from the plant, I inevitably interfered with their priorities. But there was something in it for both sides. When a research idea fitted an actual business or plant priority, the probability that it would eventually be implemented was much higher. Connecting research with the business therefore gave their ideas a better route to application.
In hindsight, I think this taught me something important: formal organisational boundaries do not determine where the work itself takes place.
Finding myself between the silos
This became relevant again after the transition to Covestro.
I was initially expected to move into Engineering because Process Automation was responsible there for DCS and MES. I did not want to make that move and eventually found a place in Technology, where I could work with historian functionality and the applications being built on top of it.
At first, that seemed like an ordinary organisational decision. But it made me increasingly conscious of the difference between where expertise is organised and where a problem actually belongs.
A control-room project was a good example.
It might look like a technical project: automation has to be redesigned, a DCS replaced, local panels removed, new equipment installed. But that is only part of the job.
The plant may also have to reorganise its operation. Roles have to be described. The Works Council may need to be consulted. People have to be informed and selected. People whose positions disappear need to be treated carefully and helped through the transition. Communication has to be organised. At the same time, the technical work has to progress: automation, civil construction, room design, workplaces and equipment all have to come together.
The plant therefore has one integrated change, while the expertise needed to deliver it sits in several different places.
I experienced myself as one of the pivots in this process, together with local management and HR. I did not have authority over all these areas, nor did I need to. My role was to understand enough of the different perspectives to see the dependencies and help make the pieces fit together.
That made me realise that there is nothing inherently wrong with organising expertise in separate departments. Engineering should have engineering expertise; Technology should have technology expertise; HR should have HR expertise.
But then there needs to be a strong cross-silo capability that can bring those disciplines together around a particular result.
For a major plant project, this might even mean temporarily making the plant organisation the overriding structure: bringing the relevant specialists together around the project, rather than expecting each function to optimise its own contribution and somehow having the integrated result emerge afterwards.
I felt that this cross-silo mechanism was not sufficiently present.
A different organisational memory
My DSM experience gave me an interesting comparison.
The strong decentralisation of DSM had certainly had disadvantages. Some central expertise disappeared. Knowledge networks replaced parts of the former central functions, but those networks had less authority to impose standards and often had little budget for centrally developed applications.
So decentralisation was not automatically better.
But we had also learned to work around those disadvantages. Because people were closer to the business and the plants, cross-functional cooperation became part of getting things done. Expertise could be brought in through networks and personal relationships.
In other words, we had lost some centralisation and standardisation, but we had also developed ways of working across the remaining boundaries.
That became an important reference point for me at Covestro.
Deductive and inductive thinking
There was another aspect that I came to think about, although I recognise that this is a subjective interpretation.
One of my German managers once remarked that he saw Germans as tending more towards deductive thinking, whereas Dutch people were more comfortable combining deductive and inductive thinking.
I found that interesting because it corresponded, at least partly, with how I had experienced my own work.
Many of the plant projects I had worked on developed quite inductively.
Take the control-room example. The work might start with a concrete automation problem: a new DCS is required, local panels are becoming obsolete, or another part of the automation infrastructure needs to be replaced.
Then comes the question:
If we are changing all this anyway, what should we do with the control room?
That question leads to others. What should the future operating model be? What should remain local? What should be centralised? What does this mean for roles, workplaces and the organisation?
Gradually, the larger concept emerges from connecting the individual observations.
That is an inductive process.
A silo organisation, by contrast, naturally lends itself more to a deductive way of working. Engineering defines the engineering problem; Technology defines the technology problem; HR addresses the people side; the plant addresses operations. Each can develop a very good answer within its own domain.
But some solutions emerge only when somebody is able to connect things that were not originally defined as belonging together.
This is not a statement that people in silos cannot think inductively. It is rather that the organisation gives them fewer opportunities and fewer incentives to do so.
And this is why I increasingly saw the cross-silo role as more than coordination. Someone needs to create the space in which the different disciplines can discover what their problems have in common.
Today, I would also be more cautious about the particular solution that emerged from those control-room projects. Mobile technology, remote operation and AI may make entirely different operating models possible. Perhaps the next generation will find ways of combining local presence, remote support and intelligent assistance that we could not have imagined.
That does not change the point of the example.
The particular solution may change. The need to connect technology, operations, organisation, people and business purpose does not.
Being together
There was another, much less formal mechanism that helped to overcome silos at DSM: simply being together.
The Rotterdam plant was a relatively isolated site with its own canteen. At lunchtime, almost everybody would end up in the same room. The workforce was still small enough for the group to be quite manageable, and there were long tables where people from different disciplines would sit together.
Of course, people talked about their private lives. But the lunch table was also an informal information network. An engineer could hear what was happening in production; somebody from maintenance might mention a problem; somebody from the laboratory might have an idea. Conversations crossed the formal organisational boundaries almost without anybody deliberately organising them.
I experienced something similar elsewhere at DSM. Even during my Geleen period in DMC, I would often have lunch with people from the plant.
Looking back, I think these informal connections were more important than we perhaps realised at the time. We had formal organisations and departments, but the people were still physically and socially close enough to create their own connections across them.
This is another reason why I am cautious about simply equating decentralisation with silos. DSM did decentralise and dismantle central functions, but the resulting organisation still had many ways in which people could find each other and exchange knowledge across boundaries.
When expertise becomes more strongly organised into separate specialist silos, those informal mechanisms may become much weaker. Then cross-silo cooperation cannot simply be expected to happen. Something has to replace the connections that used to arise naturally.
There is also a more recent dimension to this.
The physical environment of Covestro in Leverkusen was very different from the plants I had known at DSM. Leverkusen is a large site, with substantial buildings, and functional departments tend to have their own building or their own floors. The physical organisation therefore already reinforces some of the functional boundaries.
And even when people are working on site, cross-disciplinary teams increasingly meet through Teams rather than by sitting together in the same room.
Corona obviously accelerated this development. We learned to work from home and communicate electronically because we had to. That brought enormous advantages, and I would not want to argue against them.
But I sometimes wonder whether something else was lost in the process.
When people meet physically, not every interaction has to be scheduled. You overhear something. You meet somebody in the corridor. You sit next to somebody from another discipline at lunch. You ask a question that you would never have thought important enough to put into a Teams meeting.
Those interactions can be inefficient in the narrow sense. But they can also create connections across organisational boundaries.
Perhaps digital communication has made it easier to communicate within the network we already know, while making it less likely that we accidentally discover somebody outside that network.
I don’t know whether this is actually what happened at Covestro. But looking back at the difference between the plants I knew at DSM and the large functional organisation I encountered at Leverkusen, I do wonder whether we have gradually removed some of the informal mechanisms that used to help us cross the silos.
The irony is that we may have become much better at connecting people technically while becoming less good at connecting them accidentally.
And then came gMES
This was the background against which I experienced gMES.
I was part of the gMES team from Technology, while Engineering led the initiative. The ambition was to develop a standardised MES template that could be rolled out quickly across plants.
I understood the attraction. Standardisation could make implementation repeatable, and a lean template could make fast rollout possible.
But two moments made me increasingly uneasy.
The first concerned the balance between speed and plant value.
During the initial gap analysis at the first implementation plant, I saw several specific functionalities that addressed concrete issues the plant was already working on and for which MES could provide a useful solution.
Later, when the implementation speed became an explicit objective, I asked what had priority: making the implementation as useful as possible for each plant, or achieving the desired rollout tempo.
The answer from the Business was clear: tempo.
I found that revealing. The speed of deploying the template had become an objective in its own right.
The second issue was the role of the plant.
The plants had very limited capacity for this kind of work. Their organisations were lean and concentrated on running the operation. I argued that the plant nevertheless needed to be proactively involved, because what the MES should do and how it would create value depended on the purpose it served in that particular operation.
Instead, the plant was largely waiting.
The attitude was understandable:
I don’t know what’s coming. Let’s wait until it is finished and then see what it is.
But to me that was precisely the problem.
By the time the plant could see what had been built, many of the choices determining whether it would be useful had already been made.
I could see Engineering trying to do a good job within its responsibility: develop a good, standardised template and make it possible to roll it out efficiently.
I could also understand the plant: it had little capacity to engage in something whose outcome it could not yet see.
Neither side seemed unreasonable to me.
What was missing, in my eyes, was the cross-silo mechanism that would have made the plant’s purpose the organising principle of the project.
I could see the problem developing, but I did not have the authority to change the way the project was organised.
That was the point at which accountability without authority became very concrete for me.
It was not that somebody had formally made me accountable for the entire gMES outcome. It was that I felt sufficiently responsible for the outcome to see the problem coming — while the decisions that could change the conditions belonged elsewhere.
What the experience taught me
Looking back, I would not conclude that functional departments are the problem. Nor would I conclude that DSM’s decentralised model was inherently superior.
Both approaches have trade-offs.
What I came to value was the ability to temporarily organise around the problem rather than around the permanent organisational structure.
A plant does not experience an Engineering problem, a Technology problem, an HR problem and a management problem separately. It experiences one problem.
The organisation may need specialised functions to solve the pieces. But somebody still has to connect the pieces back into the one problem the plant is trying to solve.
That was increasingly the role in which I recognised myself.
And perhaps that explains why I felt uncomfortable when I was being placed inside one of the silos. I did not primarily see my contribution as belonging to Engineering or Technology. I saw it in the space between them — connecting the what the plant wanted to achieve with the how the different specialists could make it possible.
That space has no obvious place on an organisation chart.
Yet, in my experience, a surprising amount of the success or failure of large projects happens precisely there.
