Tag: Covestro

When I look back at my years at DSM, I realise that I experienced the development of its management culture in a rather peculiar way.

At the time, I did not see a grand design.

Things happened one after another: a reorganisation where central departments were resolved, management training, new ways of setting goals, new work processes, new roles. Managers behaved in ways that gave us more room to take responsibility. We learned new techniques and gradually started working differently.

Only much later did I begin to see how these things fitted together.

From a central department to the business

I joined DSM on 1 November 1990, in the central process-control department of the Division Chemicals.

I did not stay long in that organisation.

On 1 January 1992, the Division Chemicals was dissolved and its activities were reorganised into Business Units. I moved into the plants of the Special Products Business Unit.

For me, this was an important change in perspective.

I had moved from a central department of a large division into what felt much more like a small company within the company, with only a few hundred employees. I was suddenly much closer to the plants and to the business itself.

My work also broadened.

I became involved in the plants’ budgeting and planning process. One of my tasks was to assemble the data for the three-year operational plan.

We developed a base scenario: what would happen if the plants continued with their current performance, taking account of turnarounds and expected on-stream time?

Then there was a three-year scenario based on what we expected to happen.

For that I needed market-development estimates from the product managers. I also needed the improvements that were expected to come from our improvement portfolio, which I managed together with a small team of engineers.

So I was increasingly connecting things that had previously seemed separate:

plant performance, improvement, market expectations, production capacity and business planning.

I didn’t realise it at the time, but this was already part of a broader change in the way responsibility was organised.

Learning to manage differently

There was also a substantial investment in management development.

I attended DSM’s Basic Management and later Middle Management programmes. These were not just classroom courses. We worked in groups, including outdoor exercises, and discussed subjects such as the psychology of leadership. We were also introduced to Strategic Dialogues.

There were other programmes as well.

I remember one particularly well about setting goals. It was led by a Belgian teacher who, as we were told, also trained people at the Vatican.

The interesting question was not simply how to formulate a goal.

It was:

What makes a goal useful?

A useful goal should be constructed so that achieving the goal and achieving the desired ultimate performance go hand in hand. A target that can easily be achieved while producing the wrong behaviour is not a very useful target.

These sessions also created something less tangible but perhaps just as important: relationships.

Managers from different parts of DSM met each other, worked together and got to know each other. We learned intervision — discussing management problems with peers and helping each other think through possible solutions.

A management community was being created across organisational boundaries.

Then came the work processes

In 1998/99, DSM introduced a more formal framework of work processes, roles, meeting structures and KPI definitions. I remember that we were told the approach had been inspired by Dow Chemical.

The work processes included, among others:

• Operate Plant Normal
• Asset Utilization
• Improve Plant
• Do Maintenance
• Increase Equipment Reliability
• Small Projects.

These were not just descriptions of activities.

The idea was to clarify roles and responsibilities, create a structure for meetings and alignment, define how issues should be escalated and make performance visible.

And the work processes complemented empowerment.

The role was not supposed to become a detailed list of tasks that someone had to execute. The person in the role was expected to take responsibility for the result.

I remember lengthy discussions in our department about the meaning of “roles”. Some people found it difficult to see how a role differed from the traditional Dutch taken, bevoegdheden en verantwoordelijkheden — tasks, authorities and responsibilities.

The difference was subtle but important.

A traditional task description tells you what you are expected to do.

A role gives you responsibility for an area or result and leaves considerably more room for deciding how to achieve it.

That distinction turned out to be important for me.

Empowerment was not being left alone

There is another part of this story that I should make explicit.

When I describe the projects I subsequently led, it might sound as if I was simply given a lot of freedom and went off doing my own thing.

That wasn’t how it worked.

I had support and trust from my managers.

The coaching described in The photograph on my desk is a good example. The HR person and consultant did not only coach me in how to empower my own team. They were also there when I had to go to my manager and ask for money or other resources.

That was an important part of the system.

Empowerment does not mean:

“Here is your responsibility. Good luck.”

It means something more like:

“You are responsible for the result. You have room to determine how to achieve it, and we will support you when you need the organisation to make that possible.”

Of course, DSM was far from perfect. There were disagreements, bureaucracy and plenty of things that didn’t work as intended.

But there was a consistent direction.

Management was increasingly expected to set objectives, provide the framework, challenge people and remove obstacles, while people closer to the work were expected to take responsibility for achieving the result.

Looking back

Only in retrospect do I see how many pieces were reinforcing each other.

There was the reorganisation into Business Units, bringing responsibility closer to the business.

There was management development, giving managers a common language and new ways of thinking about leadership.

There were Strategic Dialogues and goal-setting, connecting objectives with business performance.

There were roles and work processes, giving the new way of working an organisational structure.

And there was management support and trust, making it possible for people to actually exercise the responsibility they had been given.

None of these things, by itself, creates an empowered organisation.

Together, they can.

At the time I didn’t know whether this was a carefully designed master plan or simply a series of initiatives that happened to fit together.

Much later I discovered that there really had been a much more deliberate transformation behind it.

But that is another story.

What I do know is that, by the time I became involved in the control-room projects, empowerment had become part of the way I instinctively approached work.

I didn’t think:

“Now I am going to apply the DSM empowerment philosophy.”

I simply thought:

Here is the objective. Now let’s work out how to make it happen.

And that is where the Rotterdam control-room story begins.

In 2000, I moved to DSM Rotterdam in the Botlek. But Rotterdam was not where I first became involved in centralizing control rooms.

That had started a few years earlier in Geleen.

The Geleen site was quite different from Rotterdam. It consisted of a collection of relatively small plants, many of which were still operated locally from conventional control panels. I had developed the idea of bringing these operations together into a single control room.

For quite some time, nothing happened with the idea.

Then a consultancy came in looking for opportunities to reduce costs.

Suddenly, my old proposal became interesting.

I was asked to work out how it could be implemented. The idea combined automation — using a mini-DCS — with consolidation of the local control rooms into one central control room.

A project manager was appointed, and I became part of his project team.

Designing a control room is not only an engineering exercise

One of the interesting decisions the project manager made was not to leave the design of the new control room entirely to engineering.

Instead, he brought in an architect.

From earlier experience, I knew that another discipline could contribute something important as well: ergonomics. A control room is, after all, a workplace in which people have to monitor processes, recognise abnormal situations and make decisions, often under pressure.

So an ergonomist was brought into the project too.

The architect and the ergonomist approached the design from quite different perspectives. There was some tension between them — which was perhaps inevitable.

But both contributed something valuable.

The architect helped create a control room that was an imposing and coherent space. The ergonomist brought the perspective of the people who would actually have to work there.

In the end, the two perspectives came together in a design that was both visually impressive and suited to the needs of its users.

That experience stayed with me.

Rotterdam

When I came to Rotterdam, I was no longer simply a participant in such a project.

I became the project manager for the consolidation of two existing control rooms.

And I could bring the lessons from Geleen with me.

The Rotterdam project was considerably more than putting two control rooms together. One of the existing control rooms was already large, with extensive conventional instrumentation arranged in large panels. The other had its own control environment.

In the new control room, all of that conventional instrumentation disappeared.

The plant would now be operated entirely through screens. There had been screen-based operation before, but this was a fundamental change: the operators would no longer have the physical overview provided by the traditional panels.

At the same time, we had to redefine the operators’ roles and assess people for the new roles.

So we were changing three things simultaneously:

• the physical organisation of control;
• the technology through which operators interacted with the plant;
• the roles and organisation of the people operating it.

This was where the work-process model, automation and empowerment came together.

What happened after implementation

Once the new control room was operational, something happened that I found particularly interesting.

The operators started asking for things.

They would notice that a particular piece of information was useful to them but wasn’t yet available in the form they wanted. They would ask for a display, an analysis or another tool that would help them understand what was happening in the plant.

We had a historian system containing large amounts of process data, and we had provided tools with which displays could be built.

The operators started using them.

Rather than waiting for engineering or IT to develop everything for them, they began creating displays themselves, using the data that were already available.

This was particularly interesting because we had just taken away something they had previously had: the immediate visual overview provided by the conventional control panels.

Instead of simply accepting the new screen-based environment, they started shaping it to suit the way they needed to operate.

And then it went further

What surprised me was that the operators didn’t stop at process displays.

They began thinking about the information they needed as a whole. One of the operators even made a picture of the information environment around the control-room operator.

The operator is shown in the centre, connected to the different sources and tools needed to operate and troubleshoot the plant: the DCS, trends, laboratory analyses, a process-conditions tool, shift reports, maintenance, plant technology staff, other plant operators and a resource called Mockingbird, containing data and instructions..

The picture is interesting because it wasn’t an IT architecture diagram produced by an IT department. It was an operator’s view of the information environment needed to do the job.

And the operator didn’t just draw the picture. Using the simple tools we had made available, operators started building parts of this environment themselves.

One example was Mockingbird, a resource where documents could be stored and links could be created between related documents. Other tools brought together process data, trends and other information needed for troubleshooting.

By today’s standards, none of this was particularly sophisticated technology. But that wasn’t the point.

The people doing the work had identified what information they needed and started shaping the tools around their work.

Nobody had instructed them to develop an information system.

They simply saw an opportunity and took it.

The control-room operator at the centre

Looking back, I think the picture captures something important about the change we were trying to make.

The new control room had made the operator responsible for a much broader operating environment. The old control panels had provided a very tangible overview of the process. Now the operator had to construct that overview from information presented through screens and other systems.

But instead of simply asking someone else to design the perfect interface, the operators started building the information environment they needed.

This was empowerment in a very practical form.

We had provided the framework, the process data and some relatively simple tools. The operators provided the detailed knowledge of what was useful in their work.

The result was something neither side could have designed as well on its own.

This was empowerment in practice

Looking back, I think the important part was the combination of things we had done.

We had given people new roles and responsibilities, but we had also given them information and tools with which they could fulfil those responsibilities.

And then we allowed them to shape the tools themselves.

The work-process model provided the organisational framework. The new control room provided the environment. The historian provided access to information about what was actually happening. And the development tools gave operators the ability to turn that information into something useful.

This was a very practical demonstration of something I had learned through the empowerment coaching several years earlier:

Don’t prescribe the solution. Give people the responsibility and the means to find it.

Taking the experience further

A few years later, these experiences became relevant to the integration of the former Roche Vitamins business into DSM, which became DSM Nutritional Products.

Central control-room consolidation was one of the elements being considered as part of the integration and cost-reduction programme. The experience we had gained in Rotterdam therefore became useful beyond the original plant.

One of the Rotterdam operators had been particularly enthusiastic about using the new tools and developing his own solutions.

We invited him to become involved in the integration work and, in particular, to help train colleagues in the newly integrated organisation.

That was significant to me.

We could have sent an IT specialist to explain the technology. Instead, we took someone who had used the technology to improve his own work and asked him to show others what was possible.

You don’t teach empowerment by explaining the word.

You let people experience what becomes possible when they are given responsibility, information and the means to act on it.

When I moved from DSM to Covestro on 1 April 2021, I did not only move to another company. I also brought with me a small piece of the DSM world.

For the past five years, I have managed a number of MES implementations (computer systems for production management) that had originally been developed within DSM. The systems were running in manufacturing plants that moved from DSM to Covestro, and I moved with them.

These systems were never really part of Covestro’s standard MES landscape. They were, in a sense, legacy systems from the moment I arrived. There was therefore a fairly clear expectation that they would eventually be replaced by a Covestro solution.

“Eventually”, however, turned out to be a rather elastic concept.

In the meantime, the systems continued to do useful work. They provided historian data, but their role went considerably further. We collected batch-performance data from daily operations and used those data for Continuous Improvement. Within Covestro’s Analytical Platform, the data could be summarized and transformed into analyses that provided pointers to further process improvements.

There was also a less glamorous but very practical benefit. By automating recurring reporting and analyses, the systems took work away from local engineers and management. Some of the activities were simply tedious: producing regular reports, preparing statistics, or doing things such as annual target setting. Once the relevant data were available in a structured form, much of that work could be automated.

So although the systems were “non-standard”, they were not exactly redundant.

Running my own shop

What made my role interesting was that I was not simply the application administrator of an existing corporate system. Over time, I effectively had my own little “shop” within Covestro.

I was responsible for the whole environment: costs, IT interfaces, Managed Operations, migrations, extensions to the functionality, and all the practical things needed to keep the systems running and developing.

There was no large team behind me doing these things. In practice, I had to find the people I needed, arrange the interfaces, manage the suppliers and operations, decide what needed to be changed and make sure that the result worked.

Looking back, “intrapreneur” is probably a better description of what I was doing than “system manager”. I operated inside a large company, but with considerable independence. I had a small domain that I was responsible for and, within that domain, I had to make things happen.

Of course, that independence also meant that I sometimes felt rather detached from the mainstream Covestro organisation.

The museum

There was a particular place where this became almost a running joke.

In Geleen, there were still quite a few people around who had worked at DSM before the transition. Some were now at Covestro, while others had moved with parts of the old DSM organisation into successor companies.

During breaks and lunches, we would sometimes compare experiences. We would wonder about things that had changed after the transition, discuss things that we found difficult to understand, and, perhaps most importantly, laugh about them.

That laughter was useful. When something frustrates you, being able to tell the story to someone who immediately understands why it is frustrating makes quite a difference. And when you can laugh about it together, the frustration becomes easier to handle.

At some point I started referring to my little MES environment as my “museum”.

It was an appropriate name. The systems had their roots in an earlier DSM era, and I was still running them years after the organisation around them had changed.

One former colleague, now working at Envalior, took the joke a step further. Whenever we met — sometimes with other people around — he would address me as “Museum Director”.

I found that funny.

It also gave me an opportunity to explain what my “museum” actually contained. And the more I explained it, the more obvious it became that it wasn’t really a museum at all. It was still doing useful work.

There was something interesting about that wider Geleen community. It was not only a community of people from the same company. It included people who had ended up in quite different organisations but who had shared the same DSM background. Envalior is an interesting example: its engineering-materials business combines former DSM engineering plastics with the former LANXESS high-performance materials business. They too have been going through a transition in which an old organisational culture meets a new corporate environment. Maybe even similar, because LANXESS is also a Bayer successor, like Covestro.

We therefore had something in common that was difficult to describe in organisational charts. We recognised similar changes in the way work was organised, similar differences in expectations, and sometimes similar frustrations — even though we were no longer colleagues.

That community turned out to be valuable.

When a legacy system becomes useful

Meanwhile, the replacement of my “museum” was progressing — or, more accurately, being discussed for quite a long time before it actually progressed.

For years, the systems were regarded as something that should eventually disappear because they were not the standard. Eventually Covestro did develop a replacement with similar functionality and started rolling it out, including to sites that were still using “my” MES solution.

The plan is now to retire the legacy systems by the end of 2026.

There is a certain irony in the timing.

After years of having systems that were considered non-standard, the standard replacement has finally arrived. And it arrives just in time: in about six months, my retirement will lead to the wind-down of my activities for Covestro anyway.

The “museum” is therefore finally closing.

But the work continues

I am not completely leaving the story behind.

Within the replacement project, I still have a role in developing the new data platform. In essence, this is a 2.0 version of what I have been running.

The new platform goes a step further. It provides ready-to-use datasets for batch and batch-step analyses, including things such as duration histograms and statistical analyses. These data can then be used to derive manufacturing and scheduling targets.

That is actually the part I find most satisfying.

The systems themselves are technology. Technology has a lifecycle, and eventually old systems should be replaced. There is nothing wrong with that.

What matters more is what you do with the data — and the way you think about using them.

So, after all those years, my systems will probably not survive me.

But there is a fair chance that the way I worked with the data will.

And perhaps that is a better legacy for a Museum Director anyway.

For all episodes about Career in the correct sequence please follow this link.

This is the start of a main topic about my work career that started 1 February 1985 and will end end of March 2027.

The most recent period, starting 1 April 2021 was with Covestro, a German chemical and materials company that was once part of the legendary Bayer, one of the great traditional companies of Germany.

An observation arises when something catches your attention. Usually this happens because it differs from what you are used to, surprises you, or interests you enough to remember it and try to understand it. But it can also happen when something familiar confirms a pattern you already recognize. Or, alternatively, if you see a familiar pattern that fits a backdrop.

Specifically the observations around my time in Covestro has three backdrops:

1. My professional background. Until 1 April 2021, I had spent a long period working at DSM, where I had been trained in a particular company culture. I had grown up professionally in that culture and had been part of the journey that shaped it. Things I encountered at Covestro sometimes contrasted sharply with what had become familiar to me at DSM.
2. My personal experience of Germany. My wife is German, born and raised in Cologne, close to Leverkusen and through her I have become familiar with German family life and culture. Working in a German company sometimes revealed differences between the Germany I knew privately and the Germany I encountered professionally. These differences became another source of observations.
3. The border. I live a few hundred meters from the Dutch-German border. Crossing the border is enough to encounter visible differences in everyday life. This has made me particularly conscious of differences between the two countries.

My observations are about culture and ways of working, not about individual people. I have worked with many good and enjoyable colleagues throughout my career, including at Covestro.

From time to time, I was frustrated at Covestro. I see this primarily as my problem, rather than as a judgement about Covestro. My professional culture had taught me to take the lead in achieving relevant results and to use my own creativity to find the best way of getting there. I had come to believe strongly in that way of working.

My frustration arose when I encountered a different approach. Decisions taken by (higher) management were often treated as unalterable, even when they appeared not to work. Even raising the question of whether such a decision should be reconsidered could be difficult. The same applied to requirements, rules and norms: even when they seemed irrelevant to a particular situation, counterproductive, or sometimes inconsistent with other requirements, they were nevertheless to be followed.

Another source of frustration was the tendency to prescribe in detail what to do rather than what to achieve. This was particularly difficult when the people prescribing the solution did not have the relevant expertise and therefore did not necessarily see the consequences of what they were asking, while at the same time leaving little room for a discussion of the substance.

I entered Covestro with one set of assumptions about how an effective organisation works, and encountered another set of assumptions. The differences made me notice things that I might otherwise never have noticed.

In subsequent posts, I will describe some anecdotes that illustrate these observations and, hopefully, make the differences more tangible.

I welcome reactions and different perspectives; you can always contact me

Outline of published and planned episodes

Act I — The Covestro question
What did I encounter, and why did it strike me as unusual?

Act II — The DSM backdrop
Where did my expectations come from, and what did empowerment actually mean in practice?

Act III — Back to Covestro
Now that the reader knows my reference frame, what did I actually observe and feel?

Act IV — Farewell
Put “observations from a career” into perspective and final remarks