Categorie: Career

In 2019 I moved to DSM Resins.

By then the MES experience had travelled further. Within Engineering Plastics there had been the implementations in Emmen, Evansville and Genk, while Wilmington had shown that the same technological basis could be adapted to another business.

In Resins, the roll-out continued.

The next implementation came in Hoek van Holland, followed by preparation for two simultaneous implementations in Spain, at Parets and Santa Margarida.

But the context in Resins was broader than simply rolling out another application.

The director of DSM Resins wanted to push a digitalisation agenda across the whole business.

This included not only Manufacturing, but also functions such as Supply Chain, Marketing, Pricing, R&D and Patents.

The DSM IT Business Partner, who worked for the DSM IT organisation but was also a member of the DSM Resins Management Team, organised this effort.

The Resins COO did not attend these discussions for Manufacturing. He left that part of the agenda to me.

That meant I had to formulate a longer-term digitalisation agenda for Manufacturing.

The starting point was Asset Utilization. It was already proven, although the implementation was not yet completely finished.

From there, I saw a natural progression towards further Manufacturing functionality:

Asset Utilization → Track & Trace → Operate Plant → data integration → data-driven business steering.

The important change was that the MES was no longer just an application for one work process.

It was becoming a potential digital platform for Manufacturing.

A little pioneering spirit

There was also a more informal side to the way I experienced innovation at DSM.

The director of DSM Resins had her office in the World Trade Center in Amsterdam Zuid. I came there regularly, and I remember the atmosphere as quite different from the more traditional corporate environment I had known. There was a pioneering spirit: people were trying things, new ideas were emerging and not everything seemed to have to be fully designed before you could start.

One of the projects I encountered was a pricing application developed by a team working in what had been the IBM building in Amsterdam. It was a rather fancy, almost hip environment, and the way people worked seemed to fit the surroundings: there was experimentation, some improvisation and a willingness to find out what worked.

I found that energising.

In early 2020, the Resins director had taken responsibility for all the Materials Science activities in DSM, and an alignment of the automation initiatives across these businesses was organised.

I knew Engineering Plastics — which later became Envalior — quite well, because I had been involved in building parts of its automation and performance-management environment myself. But now there were businesses I knew much less well, such as Dyneema — later Avient.

I had to present our approach to Manufacturing Performance Management to this broader group.

Instead of giving a conventional presentation, I decided to turn it into a quiz.

I prepared simple questions with three possible answers: two were complete nonsense and one was the right answer. We went through the questions together, and after each one I could explain why the correct answer was what it was and what it meant for the way we worked.

It was not exactly a sophisticated training technique.

But it worked.

People participated, there was some laughter, and the explanations became part of a conversation rather than a presentation being delivered to an audience.

I remember that session because it captured something I valued about that period at DSM: serious things did not always have to be done seriously.

There was room for experimentation not only in the technology, but also in how we worked with people.

---

When IT became part of the question

There was a reason why this increasingly became an IT as well as a Manufacturing issue.

The original Wonderware implementation had been financed by Corporate and developed with substantial involvement from DSM IT. The systems were part of the global DSM IT environment, including Active Directory, and were set up and maintained with IT involvement.

The AspenTech systems that I inherited in Resins had a similar IT orientation.

So although these were Manufacturing systems, they were not treated as a separate OT world.

I actually saw that as an advantage.

The future I envisaged was one in which manufacturing information would increasingly be integrated with the rest of the company’s information environment. A completely separate OT world would make that more difficult.

But this view was not universally shared.

There was a strong OT community within DSM that regarded its environment as something that needed to remain separate. I experienced that tension directly through my membership of the global DSM Process Control network.

At the same time, DSM IT was increasingly outsourcing infrastructure services.

Network management, including local firewalls, was handed over to external parties. This meant that OT operations increasingly became dependent on IT services.

That caused considerable discussion.

And the problem became larger as more and more IT functions were outsourced to different parties.

A seemingly simple firewall request could involve a security review by one external provider, approval by the site, implementation by another provider, with DSM IT coordinating the whole process.

The IT colleagues involved were often genuinely trying to help. But they increasingly found that their hands were tied by the organisational structure around them.

Different teams had their own resource planning and prioritisation, often using different Agile environments. Each could operate efficiently within its own boundaries, while the end-to-end process became increasingly difficult for the customer to navigate.

For Manufacturing, that distinction mattered.

The plant did not need a collection of well-managed services.

It needed one working solution.

---

The next step: cloud

Despite these frustrations, we continued with the Parets and Santa Margarida implementations.

The plan was to implement their MES environment in the AWS cloud.

For me, this was a logical next step.

I saw the future as an increasingly integrated IT/OT environment rather than two completely separate worlds. The cloud was part of that future.

But there was another important consequence of the way we had developed the systems at DSM.

Because the MES applications had been treated as IT systems, Covestro IT would later inherit responsibility for integrating them.

That would become significant.

The people who understood the applications and their manufacturing context were largely in Manufacturing.

The infrastructure and IT heritage pointed towards IT.

And the operational environment belonged to OT.

The boundaries did not line up neatly.

Then, while we were still working on the Parets and Santa Margarida plans, DSM became Covestro.

So I entered Covestro not with a blank sheet, but with a small ecosystem of legacy Manufacturing systems that had evolved over several years — Wonderware MES, AspenTech applications, Asset Utilization, and an emerging digitalisation architecture.

And with them came a set of assumptions about where MES belonged, how it should be developed, and how standardisation should work.

Those assumptions would soon be challenged.

My first substantial involvement with Covestro came immediately after the transition. I was naturally involved in the IT migration, particularly because I had systems that originated in DSM and had to continue operating in the new environment.

There was also a personal route into the new organisation.

One of the first people I got to know in Covestro was the leader of the Advanced Process Control department in Technology. She was managing an AspenTech APC implementation, so our work had a natural point of contact from the beginning. Through that work, I came into contact with her quite early in the integration.

I also discussed my hesitation about moving to Engineering with her. Process Automation, including DCS and MES, was part of Engineering in the Covestro organisation, and that seemed the obvious place for my background. But I did not really want to move there. She understood my hesitation and introduced me to the manager of a department in Technology where I eventually found my place.

That introduction turned out to be important for the rest of my time at Covestro. He became my manager and supported me throughout the years that followed.

My position was therefore somewhat unusual. I was in Technology, working with historian functionality and applications built on top of it, while at the same time remaining involved in the gMES team led by Engineering. And because of my existing MES systems, I was involved from the beginning in the practical consequences of the IT integration.

This was not simply a matter of moving servers from one place to another. The systems depended on network configurations, firewall rules, access arrangements and connections to other systems.

Some of these things were different between the former DSM sites and Covestro.

Third-party access to the MES environments was one example. The way we had previously arranged access did not fit the Covestro approach, so a new Third Party Access mechanism had to be established.

The local firewall configurations provided another example. The former DSM sites had their own configurations and rules, some of which were important for my systems. They did not simply match the Covestro standard.

Changing all of this as part of a fast integration was not realistic. The integration therefore had to distinguish between what could be changed immediately and what could not. In some cases, new acceptable standards had to be developed that allowed the systems to operate during the transition without making the integration unnecessarily slow.

I found this quite interesting because it was one of my first experiences of what a large-scale integration meant in practice. The organisational decision to integrate the companies was one thing. Making hundreds of technical dependencies fit together was another.

The first migration reminded me of an experience I had had in Scotland.

My impression was that the first migration had not been sufficiently prepared. The migration itself did not go particularly well either. We had to repair quite a few things afterwards, and some of those repairs caused significant outages.

Where in Scotland, I had to learn to trust “we’re getting there”, here I learned to trust that it would become OK after all.

The Covestro project team reacted very quickly. Problems were investigated, solutions were found and, where the original approach proved inadequate, the team was willing to change it. They were also remarkably flexible in helping to solve problems that were not necessarily part of the neat original project definition.

There was another difference with the IT environment I had known towards the end of my DSM years. Covestro still had a substantial number of its own IT people who could actually do things themselves. They could investigate a technical problem, change a configuration or make an adjustment without every action first becoming a ticket for an external service provider.

This made a surprisingly large difference.

When something went wrong, it was often possible to bring the right people together in a Teams meeting and work through the problem directly. Sometimes somebody who had not originally been part of the project or meeting turned out to have exactly the knowledge we needed. It was usually possible simply to bring that person into the discussion.

There was therefore a certain informality in the way problems could be solved. We could move from “something doesn’t work” to “let’s find the person who knows why” and then actually do something about it.

This contrasted with the IT environment I had experienced towards the end of my DSM years, where an increasing number of services had been outsourced. There, a relatively simple technical problem could involve several organisations: a request had to be formulated, routed to the appropriate external party, perhaps subjected to a security review, approved and then implemented by yet another party. DSM IT remained responsible for coordinating the process, but the people coordinating it did not necessarily have the technical ability to solve the underlying problem themselves.

In Covestro, at least during this early integration period, I experienced something different: the organisation still contained enough technical capability to act.

That made the learning cycle short. If we discovered during one migration that something had not been considered properly, the people who encountered the problem could often work directly with the people who could change the solution. The next migration could therefore be different from the previous one.

And it was.

The subsequent site integrations went progressively better. Preparations improved, the actual transitions became smoother and a way of dealing with exceptions emerged. In some cases we discovered that server hardware itself would have to be replaced rather than simply migrated. By then, however, an effective process for handling such situations had developed.

Looking back, this was one of my first experiences of something that I would encounter repeatedly during my Covestro years:

an organisation can learn very quickly when it is willing and able to learn from the first implementation.

The first migration had been imperfect. But it became the basis for a better process for the next one.

I also had an individual IT contact who became, in effect, my IT companion for as long as I remained at Covestro. He helped me whenever he could, but what I particularly appreciated was that he did not wait until something had already broken.

When IT was planning an infrastructure change that might affect my systems, he would involve me proactively. When servers or operating systems had to be migrated, he was there. When functionality was added or the environment changed in ways that could affect the applications, he helped me understand what was happening and find a way through it.

That relationship became particularly valuable as the technical environment evolved beyond the initial integration.

The eventual cloud-based MES implementation in Santa Margarida was one of the more complex examples. By then, the lessons from the earlier migrations and the relationships between the different parts of IT and the business had accumulated. The work was no longer simply about moving something from the old DSM environment into Covestro. It involved building something new while dealing with the dependencies of an existing manufacturing environment.

I found the contrast with the first migration instructive.

The first experience had shown me the friction created when two technical environments, each with their own history and standards, suddenly had to become one. The subsequent integrations showed something else: the integration itself could become a learning process.

And perhaps that was my first real introduction to Covestro as an organisation.

It was not yet the Covestro of standards, governance and organisational boundaries that I would encounter later. It was an organisation trying to make a very large and complicated integration work — sometimes imperfectly, but with people who were prepared to adapt when reality did not match the plan.

That experience would remain an important reference point for me when, later, I encountered situations in which the ability to adapt became more difficult.

What does an operatorless plant mean?

Not long after I started at Covestro, I was invited to participate in an activity looking at the future of manufacturing automation.

I was familiar with batch manufacturing and had worked extensively with automation, although within Technology, batch automation itself had not been a major focus. So I came to the discussions with some relevant experience, but also with an open mind about what Covestro saw as the future.

The ambition quickly became clear: the operatorless plant.

Much of the discussion was about advanced automation, advanced process control and related technologies. I found that interesting, but I also started asking some questions.

If we were going to automate so extensively, why stop with the production operator?

Could we not also automate plant-support activities? Engineering? Perhaps even parts of process control itself?

Those questions did not seem to generate quite the same enthusiasm.

But there was another point I felt was missing.

From my experience, automation did not necessarily mean simply eliminating jobs. It changed what people did.

Work that had to be done during shifts could sometimes be moved to daytime activities. That could reduce the burden of night shifts and physical strain on operators. Repetitive work could disappear, leaving operators with work that was more interesting and intellectually challenging.

So I made a slide for the final presentation that expressed this human side of automation.

The presentation was being prepared for very senior management and the German Works Council. The material was professionally edited by an external agency. When the person from the agency saw my slide, he was actually pleased with it. After many slides about technology and the future of automation, he said, in effect, that it finally brought some human interest into the story.

I received drafts and commented on them, but I was not involved in the final editing. Eventually the presentation was released.

At some point I went through the final version.

My slide was gone.

Nobody had told me that it had been removed. There had been no discussion about it. It had simply disappeared somewhere between the draft and the final presentation.

Later I was asked to communicate the presentation in my own environment.

I did so.

But I added my slide back into the deck.

And when I presented it, I made sure to talk about it.

I don’t remember being particularly angry about the missing slide. What stayed with me was something subtler.

I had come into an organisation where there was clearly a lot of ambition and technical expertise. But when I tried to broaden the question from “How far can we automate the plant?” to “What could automation do for the people who work in the plant?”, I did not feel the same enthusiasm.

Perhaps that was simply because the exercise had a different purpose.

But it was also one of my early experiences of discovering that the questions I naturally asked were not necessarily the questions everybody else was interested in answering.

About a year after the transition to Covestro, I was asked what I thought of the company.

I do not remember my exact wording, but I remember how I approached the question. I started with the positive experiences I had had during the IT migration. The first migration had not gone particularly well, but the Covestro project team had reacted quickly, learned from the problems and become increasingly capable and helpful in resolving them. I regarded the strength of the Covestro IT organisation as one of the positive things I had experienced.

I then mentioned what I experienced as the other side of the balance. I had begun to notice a more top-down way of working than I was accustomed to, with more detailed prescriptions of how things had to be done and a considerable number of rules and standards. This was not only about formal external requirements. Engineering, and IT for example, had their own set of sometimes detailed standards and rules.

To me, this was a perfectly normal way of giving an assessment. At DSM, we were used to giving two-sided assessments. After an appraisal, a safety tour or almost any other review, you would normally mention what was good and also something that could be improved. Criticism did not imply rejection; it was simply part of giving an honest assessment.

The answer I received surprised me. I was asked, in effect, why I did not work for another employer.

The exact wording has faded from my memory, and at the time I did not regard the intervention as something that would stay with me for years. It was certainly uncomfortable, but I could put it aside.

The second intervention was different.

A Geleen Business Manager was also present. She started by describing positively how the integration of her people into Covestro had gone. She then raised a concern that she said was shared unanimously by her people: they experienced the growing burden of compliance work as a threat.

Her question was not whether her people could simply ignore the rules. Her business was small and did not itself perform chemical operations, and she was questioning whether all the requirements and compliance activities designed for a large chemical company were relevant and proportionate to her situation, and whether some of the burden could be alleviated.

She explicitly said that she was speaking on behalf of her people.

The response came from a very senior Covestro manager, someone from whom I would expect behavioral leadership. I was sitting next to the Business Manager and he was opposite us, so I could see him directly when he answered.

The argument itself was not necessarily unreasonable. He explained the potential consequences for managers, and even for a Board member, if applicable requirements were not complied with — including the possibility of imprisonment.

Of course, such personal liability can be a legitimate reason why certain requirements cannot simply be relaxed.

But that was not how I experienced the response.

It was the combination of the content, the tone and the situation that struck me. It sounded to me as if we were already on the brink of a situation in which somebody might actually end up in prison. That seemed far beyond the question that had been asked.

A simple “no, these requirements cannot be alleviated, and this is why” would have been an entirely acceptable answer. It might have been disappointing, but it would have addressed the question.

Instead, I experienced the response as intimidating.

What affected me particularly was the way I saw the Business Manager being treated. In my eyes, she had done exactly what a good leader should do. She had listened to her people, acknowledged what had gone well, taken their concern seriously and brought it forward. She was not challenging the legitimacy of compliance; she was asking whether the way it was being applied was proportionate to her business.

And yet the response made me feel that she was being treated almost as if raising the question itself was problematic.

There was a long silence in the room afterwards and the discussion stopped.

I cannot know what the other people in the room were thinking. Perhaps the silence meant something quite different to each of us. But I remember it, and I have sometimes wondered what the senior manager saw when he looked around the room after his intervention. Did he notice how strongly his answer had landed? Did he recognise the silence as a sign that something had gone wrong in the conversation? Or did he simply consider that he had explained an important responsibility and move on?

I never heard anything afterwards about how the intervention had been received. Nor did I hear from others that it had subsequently been discussed or evaluated.

For me, however, the moment did not simply disappear.

A different meaning of speaking up

What made the experience particularly striking was the contrast with the culture in which I had worked at DSM.

At DSM, I had learned that giving a responsible management assessment meant being able to say both what was going well and what concerned you. After an appraisal, a safety tour or another review, it was perfectly normal to acknowledge the positive aspects and then point out something that could be improved. A two-sided answer was not a sign of disloyalty. It was what I understood an honest assessment to be.

The same applied to representing the concerns of people in your organisation. If a manager brought a concern forward on behalf of her people, I regarded that as taking responsibility.

The two interventions therefore became, for me, an early and rather strong experience of a different organisational culture.

I do not know whether that difference should be attributed to Dutch and German culture. It may have been specific to Covestro, to the particular management environment, or simply to the people and circumstances involved. But the contrast with what I had experienced at DSM was unmistakable to me.

At DSM, I associated speaking up with responsibility and trust.

In this meeting, I experienced speaking up about rules and requirements as being met with authority and fear.

That distinction became emotionally significant.

Later I would often hear the phrase:

Nothing is worth getting hurt for.

I associated that with care. It expressed the idea that no production target, project or business result was worth putting somebody’s health or safety at risk.

But I had another phrase in my head:

Nothing is worth getting in prison for.

I associated that with fear.

I think the second intervention had created that association in me. It was not necessarily a fair description of Covestro’s intentions, but it was the emotional reference point I had taken away from the meeting.

And I noticed something else later. Whenever Covestro used the word “courageous”, I would think back to this experience.

The intended meaning of courageous was presumably positive: have the courage to speak up, challenge things, take responsibility and do what is right.

But I had my own reference point for the word.

I remembered a manager who, in my eyes, had shown courage by representing the concerns of her people. I remembered how that intervention had been received. And I remembered the silence that followed.

Perhaps this is why the word courageous could trigger a very different association in me from the one intended by the organisation.

Looking back, I think this episode may have influenced how I experienced what came afterwards. The later discussions about empowerment, standardisation, performance data and the organisation of projects did not happen to me on a completely blank sheet. I had already formed an emotional reference point for what could happen when somebody questioned the established way of doing things.

That does not mean that my later frustrations were necessarily caused by this meeting. Nor does it establish what Covestro as an organisation actually was. I cannot know the intentions of the senior manager, and I cannot know how the other people in the room experienced the event.

I can only say what it did to me.

And perhaps that is precisely why the episode belongs here. It became part of the lens through which I subsequently experienced Covestro.

The organisation may have intended courage to mean speaking up.

I had experienced a moment when somebody did exactly that — and the memory I carried away was not courage, but fear.

But I did not spend the rest of my time at Covestro trying to resolve that contradiction. I moved on.

I already had the network of MES users that I had built during my DSM years, and at Covestro I gradually expanded that network with many new colleagues. Many of them were very nice, friendly and enjoyable people to work with. They were the people I interacted with every day, and through them I could continue to do work that I found meaningful.

In that sense, I became less concerned with Covestro as an organisation and more concerned with the people and the work immediately around me.

Perhaps that was also a way of putting the experience into perspective. Whatever I thought about Covestro as a company, my experience of working there was not defined by one senior manager or one meeting. It was also made up of the many people I met, the relationships I developed and the work we managed to accomplish together.

The memory of that meeting nevertheless remained. I simply carried it with me, rather than allowing it to determine what came next.

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.

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.

Gradually when time passed, I stopped focussing on Covestro as a whole.

That did not mean that I stopped working hard or that I stopped caring about the people around me. Quite the opposite. I had my own area of responsibility, my own systems and, importantly, my own users. They were largely the people in the plants with whom I had already worked for many years.

I knew what information they needed, how they used it and what was useful to them.

So I decided, in effect, to focus on my own shop.

Part of that work was the reporting of OEE data coming from the systems I was responsible for. The reporting had originally been developed at DSM and, after the migration, was rebuilt on Covestro’s analytical platform.

This work could take place relatively unnoticed by the wider Covestro organisation. My customers were largely the plants that had previously been part of DSM. They already knew the data and were familiar with the way we used it. I could therefore concentrate on making the reporting useful in the new technical environment rather than having to redefine its purpose.

We automated much of the monthly reporting process and also built a data foundation for setting performance targets.

I also had to decide how much to standardise.

I chose to build standard Python scripts that could be parametrised for individual sites. The basic transformation architecture was common, but specific functionality could be added where a particular site needed it.

I could have made everything identical. Instead, I tried to find a middle ground:

Standardise what benefits from standardisation, but leave room for genuine differences.

When I later became involved in version 2.0, the technical environment had changed. The data was now coming from an emerging new standard tool, so parts of the solution had to be rebuilt.

But I kept the architectural principle.

The common functionality remained standardised, while the architecture allowed site-specific additions where they made sense.

In that way, I could carry some of the ideas I had developed earlier into the new environment without making a particular point of doing so.

I was no longer trying to change the organisation.

I was simply trying to build something that worked.

Another way of contributing

There was another way in which I moved on.

I became a union officer within Synergo, taking on organisational responsibilities, and became involved in the CLA negotiations. I organised union leaders’ tours around the Dutch Covestro sites.

Although I was a member of Synergo, a union serving higher professionals, I cared about cooperation between the different unions. I tried to facilitate a common line towards management rather than having the unions approach the negotiations as competitors.

Before the negotiations, I also helped organise surveys among employees, so that the combined union effort could start from as good an understanding as possible of what people actually wanted.

Sitting in the CLA negotiations, I learned another thing that I had not expected: quite a lot about negotiation itself.

The relationship between management and employees felt different there. Neither side could simply decide for the other. To reach an agreement, you needed each other.

I found that surprisingly instructive. The formal hierarchy that existed in the company was still there, of course, but at the negotiation table it was balanced by mutual dependence. Management needed an agreement; the unions needed an agreement. Both had something to bring to the table, and neither could simply dictate the outcome.

I also think that my increasingly limited emotional attachment to Covestro helped me in that role. I could represent the interests of employees and work towards a good agreement without feeling that I had to defend Covestro as a company.

I found the experience valuable enough that I would recommend it to colleagues. Even if you never intend to become a union officer, sitting through serious CLA negotiations gives you a quite different perspective on how an organisation works — and on negotiation itself.

I did this during the negotiation cycles of 2022, 2023, 2024 and 2025.

This was another way of having an influence that felt natural to me. I had a clear role, a constituency I was representing and colleagues from different unions with whom I could work.

I also became a member of the Works Council in Geleen, the site that was my formal work location.

I did not have direct colleagues there with whom I worked on a daily basis. And the site itself had changed considerably. The sale of one business and the closure of two others had greatly reduced the number of people remaining.

The Works Council nevertheless gave me a connection with the site and with the colleagues who were still there.

So my engagement with Covestro did not disappear. It changed its form.

Watching from the outside

Even when I was no longer trying to influence the direction of Covestro itself, I continued to follow what happened.

The transition of Covestro to ADNOC was another example. I followed the developments and was interested in what would happen to the company and its people. But I noticed something in myself: I followed it without feeling personally engaged in the outcome.

That was perhaps the clearest sign that something had changed. I was still working at Covestro, still doing my work and still engaged with the people around me. But my relationship with the company itself had become different.

I had moved on — while still being there.

Perhaps that is what “moving on” ultimately meant for me.

I had not stopped caring about doing good work. I had not stopped caring about colleagues. I had not even stopped being interested in Covestro.

But I had stopped carrying Covestro as a company.

My engagement had become more local and more concrete: my systems, my users, the plants, my colleagues, the unions, the Works Council, and the things where I could actually contribute.

And now even that phase is coming to an end.

After the 2025 negotiations, my successor will have to step into the organisational work I had taken on within Synergo. My professional work will also eventually be handed over.

Looking back, I think I moved on not by becoming indifferent, but by putting my engagement where I could make a difference.

By now I had experienced Covestro as a rather formal organisation. There were structures, responsibilities, standards and rules, and sometimes I found these constraining.

But that was not the whole story.

I gradually discovered that, if you stayed somewhat under the radar and found the right companions, quite a lot could still be done.

The Covestro Analytics Platform was a good example.

When I first became involved, the platform was still something of a pioneering activity. A first version of a serverless data lake framework (SDLF) had been set up, and not everything had yet been cast in stone.

I liked that.

There was a willingness to try something, learn from it and then build a better version, rather than pretending that the first design had to be the final one.

I built some of my applications on that first version. Later, when the second version of the platform, the broader Datazone, emerged, I was invited to migrate these applications to it.

I was not involved in designing the second version itself, but I received good support from the platform team during the migration. In the process, we also developed functionality for ingesting data from Layer-3 MES systems into the platform.

I could therefore contribute some of the experience I had gained from working with the first version. The Layer-3 ingestion functionality could become a reusable building block rather than something that had to be solved separately for every MES application.

This was exactly the kind of collaboration I enjoyed.

The platform team brought the cloud and data expertise. I brought the MES and plant perspective. And there was another IT colleague who was particularly valuable because he could bridge the gap between OT and the AWS environment.

None of us had to know the complete answer beforehand.

We could work it out together.

That was quite different from some of the more formal processes I had encountered elsewhere in Covestro. There was room to experiment, learn and adjust.

A different story: Santa Margarida

The MES implementation at Santa Margarida was a completely different story.

It originated from an idea that had already existed at DSM and followed from the earlier migration work. Turning that idea into reality was a fairly tedious project. Halfway through, we had to redo the architecture in AWS, which made an already complicated project considerably more cumbersome.

But eventually we got there.

Santa Margarida went live in 2023.

At the time, I did not think particularly much about whether this achievement was visible to the wider organisation. We had a project to do, we found people who could help us, solved the problems that arose and got it running.

Then, in 2025, I encountered an amusing consequence of having worked rather under the radar.

In the context of a Covestro award, the gMES programme was presented as the first cloud implementation of an MES in Covestro.

That was not quite how I remembered it.

Santa Margarida had already been running in the cloud for two years.

I did not make much of it. In a way, it was almost the logical consequence of how I had worked. If you operate quietly with a small group of people, solve problems together and do not need the wider organisation to validate what you are doing, there is a small downside as well:

sometimes nobody outside that circle knows what has actually been achieved.

But perhaps that was a price I was quite willing to pay.

Because there was also an upside.

I had discovered that the formal organisation did not tell the whole story. Within it were people who were curious, technically capable and willing to cross boundaries. With the right companions, there was room to experiment and to build things that had not yet been prescribed.

And that became one of the more positive things I took from my time at Covestro.

Amazing things can happen when you find the right companions.

Even if, occasionally, the organisation finds out about them only later.

Looking back,

I also realise how much of what I was able to do at Covestro had been shaped by my years at DSM.

DSM had given me the opportunity to develop not only as a professional, but also as a person. Working with colleagues, managing people at times, dealing with different personalities and trying to understand what motivates or frustrates people had made me increasingly aware of the psychology of organisations and of the people within them.

Professionally, DSM had given me an unusually broad playground. I had been able to move between technology, operations, projects, IT, data and organisational questions. I had not followed one narrow professional path; I had gradually accumulated different ways of looking at a problem.

Covestro continued that development, but in different directions. The migration and the work that followed gave me the opportunity to develop further in areas that had been much less familiar to me before — particularly cloud computing and, later, AI.

So although I sometimes found the Covestro organisation difficult to navigate, I cannot separate that experience from the things I learned there. I added new professional capabilities to a foundation that had largely been built at DSM.

Perhaps that is also why finding the right companions mattered so much. By then I had learned enough to recognise when someone had a different piece of the puzzle — and enough confidence to work with them without needing to know everything myself.

We are One — but I did not forget where I came from

There was also a repeated message from management, including from people who had themselves come from DSM: “We are Covestro now.” The intention was understandable. The integration had to become a success, and at some point people had to stop thinking in terms of “us” and “them”.

I nevertheless found it difficult when this seemed to imply that we should simply forget DSM.

I could not do that.

DSM was not just the company I happened to work for before the integration. It had been my formation period, professionally and personally. It had given me opportunities to develop in many different directions, to work with people, to manage people, to learn about organisations and their psychology, and to develop as a professional. Much of the way I looked at problems had been formed there.

You cannot simply switch that off because the name on the building changes.

Over time I came to see this less as a question of choosing between DSM and Covestro and more as a question of having more than one identity.

I sometimes think of people of Italian descent who have lived in the Netherlands for several generations. They may be completely Dutch, while still speaking Italian at home, knowing where their family came from or even putting an Italian tricolore on their car.

There is nothing contradictory about that.

You do not have to abandon one identity in order to acquire another.

Perhaps the same applies to organisations.

I could become part of Covestro without pretending that DSM had never existed. I could carry the things DSM had taught me into Covestro, learn new things there and gradually add them to what I already knew.

In fact, that is exactly what happened.

DSM had given me a broad professional foundation. Covestro added new experiences, particularly in areas such as cloud computing and AI.

So perhaps “We are One” does not have to mean that everybody has the same history.

It can also mean that people with different histories become part of the same organisation — without having to erase where they came from.