Categorie: Career

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

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.

There is a photograph on the wall next to my workplace at home.

At first sight, there is not much to it. It shows a small, rather bare conference room, with my team and me sitting around a table, together with an HR colleague and a consultant. On the table are some documentation folders and the ubiquitous white plastic coffee cups. There is little else in the room.

The photograph was taken arouind 1997 during a period when we were being coached in a new way of working: empowerment.

It was actually published in DSM Nieuws, the company’s internal newspaper, as an example of the work we were doing.

At the time, our team had quite a challenge. We were dealing with the “child diseases” of the newly started phenylglycine-amide plant that used a new technology. The business need of getting the plant to run properly put considerable pressure on the team — and on me as its leader.

The empowerment coaching therefore wasn’t some theoretical management exercise. We had real problems to solve and real pressure to deliver.

Two sides of empowerment

I experienced the coaching from two different sides.

As the team leader, I learned a different way of leading people.

The lesson was not simply “give people freedom”. It was more subtle: don’t prescribe; challenge.

Instead of telling someone how to solve a problem, I should challenge them to think through the problem themselves. What are you trying to achieve? What have you considered? What prevents you from getting there? What alternatives do you see?

The responsibility for the solution remained with the professional doing the work.

But I was also being coached from the other side — as a team member myself.

The HR colleague and consultant would sometimes accompany me when I had to go to my own manager to ask for money, people or other resources. I was learning how to operate within the organisation in the same way that I was learning to lead my own team.

The message was essentially the same in both directions.

I had responsibility for an outcome, but I also had to take responsibility for finding the way to achieve it.

That meant making a case for what I needed, challenging assumptions, negotiating for resources and taking ownership of the result.

The photograph returns

At the time, I probably did not think of the photograph as particularly important. It was simply a picture of a team, an HR colleague and a consultant, documenting one of DSM’s empowerment initiatives.

Almost twenty years later, it came back to me.

MyDSM departmenthad moved into a new building with open offices. There were no cupboards for storing large quantities of paper, so we had to get rid of much of the paper that had accumulated over the years.

The same HR colleague moved into the new building with us. While clearing out his own paper archive, he came across the photograph.

He gave it to me.

I was very happy to receive it.

It was a small piece of my professional history that had unexpectedly survived the transition to a paperless office.

And it is still on the wall next to my workplace today.

What I learned

Looking back, the most important thing about the photograph is not the plant, the team or even the empowerment programme itself.

It reminds me of a way of working that became deeply ingrained in me.

The basic idea was remarkably simple:

The what is given.
The how is yours.

You are given a goal, a timeframe and the constraints within which you have to operate. Then you are expected to work out how to achieve the goal.

As a leader, your job is not to prescribe the solution. Your job is to challenge, coach and remove obstacles.

As a professional, your job is not to wait for instructions. You are expected to use your expertise, creativity and judgement to find a way forward — and to take responsibility for the result.

After a while, this stops feeling like a particular management philosophy. It becomes what you consider normal.

That happened to me.

I only realized this much later

When I received the photograph, Covestro was still far in the future. I had no reason to connect this small piece of DSM history with anything that would happen later in my career.

On 1 April 2021, the DSM business I had worked in moved to Covestro. I followed it.

The plants were largely the same. Many colleagues were the same. The technical problems were the same.

But the organisational environment was different.

And that is when the photograph acquired a new meaning for me.

It made me realize that what I had come to regard as a normal way of working was not simply how professional organisations work. It was the result of a particular culture in which I had spent more than thirty years.

I had been trained in empowerment — not just intellectually, but through actual experience, pressure, coaching and practice.

And I had carried those instincts with me.

From empowerment to intrapreneurship

There is another consequence.

If you are given the objective but are allowed to determine how to achieve it, you inevitably start operating a little like an entrepreneur inside the organisation.

You have to find the right people, obtain resources, build relationships, overcome obstacles and make things happen. You cannot simply say that the prescribed solution doesn’t work. The outcome is yours.

I now recognize this as a form of intrapreneurship.

It also explains something about the little “shop” I described in my earlier post: why it felt quite natural to me to take ownership of a small domain within Covestro and run it with considerable independence.

I did not set out to become an intrapreneur. By then, I had simply been working that way for a very long time.

For now, the photograph remains on my wall.

A photograph from around 1997, rescued from a paper archive almost twenty years later, has become a reminder of something I didn’t fully appreciate at the time:

The most lasting part of empowerment is not what you are taught. It is what eventually becomes your instinct.

And that instinct stayed with me for the next thirty years.

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.

There was one more, rather unexpected, part of the Rotterdam control-room project.

We had a budget for a piece of art for the new control room.

I had worked closely with the operators during the project, and one of them was particularly interested in finding an artist who could create something suitable. So I let him take the lead.

He arranged meetings with several artists, and I went along with him.

This took us to some of the strangest places in Rotterdam: artists’ studios and workplaces that were about as far removed from a chemical plant as you could imagine. We looked at portfolios, discussed ideas and listened to the artists explain what they might do with the space. They put quite some work into their proposals.

Eventually, we chose one.

From the plant to the molecular level

The result was a large wall painting in the control room.

The idea was to create the image using stamps of different objects. There was a whole box of them — I remember seeing all these different shapes together.

The painting had a kind of progression from left to right. At one end were very large objects, such as the Erasmus Bridge in Rotterdam. As you moved across the painting, the objects became smaller and smaller, until at the other end they were molecules — including molecules of products that were made in Rotterdam.

From a distance, all those individual stamps merged into an image of the plant and its equipment. When you came closer, you could see what the larger picture was actually made of.

I particularly liked that idea. The plant could be seen at two different scales: as a complete installation from a distance, and as the individual objects and molecules that made up the process when you looked more closely.

The artist even let me choose one of the stamps as a souvenir.

I chose the Erasmus Bridge.

I still have it.

The opening

When the new control room was officially opened, it was a much bigger event than the opening of a new workplace.

So many things had come together in the project: the consolidation of two control rooms, the new automation, the move from conventional panels to screen-based operation, the redesigned operator roles and the associated changes in the organisation and ways of working.

The opening therefore felt like a landmark event — almost a fresh start for the plant.

It was a moment when you could look at the new control room and see the future you had been working towards for several years.When the new control room was officially opened, I invited the artist to the ceremony.

He then asked me a slightly unexpected question:

Could he bring some fellow artists?

His reason was perfectly understandable. The control room was normally not accessible to them, and this would probably be their only opportunity to see the work in its final setting.

Of course, I said yes.

And so they came.

I don’t think I had ever seen such a bunch of colorful people at a DSM event.

There were operators, engineers and managers in their usual industrial surroundings — and now a group of Rotterdam artists had joined them.

It made for a rather unusual gathering.

Looking back

What I find interesting about this story now is not so much the artwork itself.

It is how it came about.

We had a budget and an objective: put some art in the new control room.

But I didn’t decide what the artwork should be. An operator took the initiative, found people with expertise I didn’t have, explored the possibilities and helped choose the result.

I trusted him to do it.

That was, in a very small and perhaps slightly absurd way, the same principle we were trying to apply to the rest of the organisation:

The what was given. The how was yours.

And sometimes the result is something you would never have designed yourself.

There is a small irony to this story that I only noticed much later.

One of Covestro’s C³ values is Colorful.

I have to admit that we managed to make a control-room opening pretty colorful at DSM too — without putting it in the corporate values first.

When DSM integrated the former Roche Vitamins business, one of the major drivers was cost reduction. It would later be integrated as DSM Nutritional Products (DNP). The different Roche Vitamins sites had to develop their own integration plans, with clear targets for reducing costs.

I became involved as team lead Process Automation, together with two engineers from Roche Vitamins.

We visited the major sites and organised workshops with the local teams. Each site had an integration team, including a DSM representative and a McKinsey consultant, which was working on the overall site integration plan.

Our part was to look at the process-automation and operator organisation, but the local teams were looking at the future organisation much more broadly.

Starting with the work

The workshops were essentially an activity analysis around the existing operator work places, in control rooms and elsewhere.

We went through what operators actually did, what activities were performed at each work place and what the workload was.

From this we could work towards the future organisation.

Two elements were particularly important.

The first was centralisation of the control rooms. If several existing operator stations could be brought together, the work could potentially be performed with fewer operators.

The second was the establishment of an operator day-shift team, moving activities that did not need to be performed by shift operators into a different organisational arrangement.

But the local teams did not look only at Operations.

They used the work processes as a basis for designing the organisation that would remain around the central control room. In particular, processes such as Improve Plant and Do Maintenance helped define what responsibilities would remain outside the shift organisation and how those activities should be organised.

At the same time, Operate Plant Normal provided a basis for defining the future operations organisation and the way the central control room would operate.

This was an important aspect of the work-process concept: it was not simply a description of what people did. It could also be used to design an organisation.

From activities to a business case

Based on the activity analysis and the proposed future organisation, we could estimate the required future headcount.

That estimate became an input to the site’s overall integration plan and therefore to the cost-reduction target.

There was another practical aspect.

If we proposed centralising control rooms, there would be consequences beyond the operator headcount. Where would the new control room be? What would have to be rebuilt? How much construction work would be required?

I therefore brought in an ergonomist to assess potential locations for the future control room and the associated construction work.

So the exercise connected several levels:

existing activities → work processes → future organisation → central control room → operator headcount → construction requirements → cost reduction.

This was quite different from simply saying: “We can save operators by putting the control rooms together.”

The work-process framework helped determine what the future organisation would actually do and how the responsibilities would be divided.

From one project to a larger transformation

This was also a significant step beyond my earlier Rotterdam experience.

In Rotterdam, I had been the project manager for a particular control-room consolidation and could develop the solution from the ground up.

Now the same basic ideas were being applied across several sites, within a much larger organisational transformation. But the experience also taught me that not every plant was suitable for exactly the same strategy. Some of the DSM Nutritional Products processes were much more complex, with considerably more manual work, and in those cases the case for centralising control rooms was simply not there. The approach therefore had to start from the actual characteristics of each plant rather than assuming that one solution would fit all.

There was an interesting combination of approaches.

The cost-reduction target provided the business driver.

The activity analysis provided the factual basis.

The work processes provided a framework for designing the future organisation.

And the central control room became one of the major changes through which that organisation could be realised — where the characteristics of the plant made such a solution appropriate.

From designing the organisation to teaching the way of working

The initial round of site analyses was only the beginning.

Once the future organisations had been defined, we started the work-process training. I was involved in training for Operate Plant and Asset Utilization.

This brought the work-process concept to a different level.

During the workshops, we had used the work processes as a framework for thinking about the future organisation. Now people had to learn what those processes meant for their actual work: their roles, responsibilities, interactions and the way performance would be managed.

And this was where I could bring something from the Rotterdam experience back into the story.

I invited one of the Rotterdam operators who had been particularly enthusiastic about the new control-room environment to participate in the training.

He could tell the new colleagues what had actually happened after the new system had been introduced.

He had not simply sat behind a different set of screens.

He and his colleagues had started asking for information they needed, building displays themselves and using the historian and other tools to create solutions for their own work. The new technology had given them possibilities that they had discovered and exploited themselves.

That was a much more convincing demonstration of empowerment than anything I could have explained in a classroom.

For the Improve Plant training, I also invited the plant staff manager from Rotterdam.

That was deliberate.

The idea was not to create a standardised training course delivered by people from the integration project. We wanted people who had actually lived with the new way of working to share their experience with colleagues who were about to go through the same transformation.

Looking back, I think this was an important characteristic of the DSM approach.

The change was propagated through people who had experienced it, not only through procedures and presentations.

The work processes provided the common language and framework. The control-room projects provided a practical application. And people from the earlier projects could explain what the new way of working actually looked like in practice.

The control-room concept was subsequently implemented at the different DSM Nutritional Products sites by the sites themselves — with one notable exception: Scotland.

In Scotland, instead of supporting the implementation from a distance, I would become the implementation project manager myself.

And there the question would become much less about designing the organisation on paper and much more about actually changing the way people worked within it.

The Roche Vitamins integration eventually brought me to Scotland.

By then, the central-control-room concept that had emerged from my Rotterdam experience had become part of the broader transformation of DSM Nutritional Products. At most sites, the local organisation implemented the new approach themselves.

Scotland was different.

There I became the implementation project manager, working together with the people responsible for the work-process implementation and with those reorganising the local organisation.

But the challenge in Scotland was not simply to install a new control room.

It was to change the way the plant was operated.

Changing the operating model

The Roche Vitamins operating model differed considerably from what I had experienced in DSM.

A chemist was responsible for the plant, while the operators and maintenance people were, in effect, his or her “hands”. The chemist would decide what needed to be done, and operators would execute it.

This also meant that chemists spent a considerable amount of time in the control room. Even during weekends, they could be called because an operational question might require their decision.

The DSM Operate Plant Normal work process was based on a different idea.

We knew how the plant should operate optimally. Operators did not necessarily need to have the detailed chemical background of a chemist to keep the plant in that state.

Their responsibility was to operate within defined operating windows and to respond appropriately when the process moved outside them.

For that, the work process used OCAPs — Out of Control Action Plans.

An OCAP made explicit what should happen when something moved outside its normal operating range: what the operator should check, what action should be taken and when the situation should be escalated.

This meant that knowledge which had previously resided largely with the chemist had to be translated into something that the operating organisation could use.

And that was an important part of preparing for the reorganisation.

The chemists increasingly moved towards Improve Plant and production-management responsibilities. At the same time, the shift leaders and operators were given more responsibility for what happened during their shifts.

The question was changing from:

What does the chemist want us to do?

to:

What happened during your shift, and how did you respond?

That was a substantial change in responsibility.

The new control room was therefore only the visible part of a much deeper organisational change.

Learning how to lead the change

I also had to learn how to work with the local organisation.

In the beginning, a local engineer supported me. I would give him an assignment and he would do it. He never seemed to object. At one point he even described me as a “tough taskmaster.”

At first I took that positively.

But then I started wondering why I wasn’t getting the kind of pushback I was accustomed to in Rotterdam.

There, colleagues would challenge me quite openly:

Why do you want this?

Wouldn’t it be better to do it differently?

I don’t think that will work.

I valued that. It forced me to explain my thinking and sometimes resulted in a better solution.

In Scotland, that kind of challenge did not come naturally.

I realised that this was potentially a problem.

If people simply did what I asked, I could easily mistake compliance for agreement.

And if we were trying to create an organisation in which operators and other employees were expected to take more responsibility, I could hardly expect them to become empowered simply because the organisation chart said so.

I needed to create room for people to question and challenge me.

That was one of my first personal lessons from Scotland: empowerment is not only something a manager gives; it also depends on people being willing and able to use it.

“We’re getting there”

Another small lesson came from the project action lists.

In Rotterdam, when I asked about an action, I would quite often get:

“Yes, finished.”

In Scotland, the answer was much more likely to be:

“Ah, we’re getting there.”

The first few times I heard it, I regarded this as a risk.

An action was either finished or it wasn’t. And “we’re getting there” didn’t tell me very much about what remained to be done.

Sometimes things did indeed become tight.

But gradually I discovered that the people saying it were genuinely committed to getting things done. They simply had a different relationship with the path towards the deadline.

And, most of the time, they did get there.

I had to learn not to confuse a different way of communicating progress with a lack of commitment.

It became an exercise in patience.

And, more importantly, in trust.

Staying close to the team

There was another small incident at the beginning of the project.

An open office had been reserved for the project team. It had one enclosed office, and when I arrived one day I was welcomed to “my new office.”

I was surprised.

I asked whether we could instead use the room as a conference room and have me sit in the open office with the rest of the project team.

The request seemed rather strange to them, but they accepted it.

I had learned from experienced project managers earlier in my career that staying connected with the team was an important condition for making a project work.

I wanted to hear the conversations, notice problems and be part of the team rather than create distance around my position.

It was a small decision, but for me it was part of the way I wanted to lead the project.

Managing the conflicts

There were, of course, strong differences of opinion.

The Plant Manager and I had some fierce debates about the content of the changes.

They were genuinely fierce, but they were not personal. We disagreed about how the organisation should be changed and how the project should be implemented, while continuing to work together.

There was an important person in the middle of this: the Site Controller, who was the local integration director supporting the DSM/McKinsey team.

He had considerable authority, but what impressed me most was how he used it.

When there was a conflict, he would patiently listen to both sides. He did not immediately decide who was right. He helped clarify the arguments and then helped the parties find a way forward.

His interventions were particularly useful when the Plant Manager and I disagreed.

Looking back, this was another important element of the new way of working.

Empowerment does not eliminate conflicting interests.

If anything, when people have more responsibility, those interests become more visible.

You therefore need management that is less about prescribing the answer and more about alignment, mediation and helping people resolve conflicts.

The control room was only the beginning

Eventually the new central control room went live.

That was a landmark event. The physical change was obvious: the operators were now working in a completely different environment, with the new technology and the new organisation around them.

But the opening was not the end of the project.

The much harder task was embedding the new way of working.

Operators and shift leaders had to become comfortable with their new responsibilities. The OCAPs had to become part of normal operation. The work processes had to become part of everyday management rather than something belonging to the implementation project.

And the organisation had to learn to operate without constantly referring back to the people who had designed the change.

I stayed for that phase.

Gradually the other DSM people involved in the implementation left.

Eventually I was the only DSM person left.

My role had therefore changed again.

I had started as the person responsible for implementing the change. I was now helping the local organisation make the change its own.

That meant discussing problems, questioning whether the new roles were actually working, helping people use the work processes and supporting the transition from project implementation to normal management.

Eventually, responsibility could be handed over to the permanent organisation, including the continuing implementation and auditing of the work processes.

The project team had to become unnecessary.

That was, in a sense, the ultimate test.

What Scotland taught me

Looking back, Scotland gave me several different lessons.

I learned that changing an organisation is different from designing one.

I learned that empowerment requires more than giving people responsibility: people need the knowledge, information and confidence to use it — and managers need to create the conditions for them to challenge and take responsibility.

I learned to be more patient with forms of behaviour that initially looked like a lack of urgency or commitment.

And I learned that even an empowered organisation needs management: not necessarily management that tells people what to do, but management that helps reconcile interests, resolve conflicts and keep the organisation moving in the same direction.

Most importantly, the control-room project made the distinction between implementation and embedding very tangible to me.

We could define roles, write work processes, create OCAPs and switch on a new control room.

But eventually the people in the organisation had to answer a much simpler question for themselves:

“What happened during my shift, and what did I do about it?”

That, ultimately, was the real shift in responsibility.

And it was a shift that could not be achieved by the control room, the organisation chart or the work-process manual alone.

When I returned to Geleen after Scotland, around 2007, I found myself in a rather different organisation from the one I had left.

The DSM Manufacturing Center (DMC) had been established a few years earlier. It brought together activities that could be centralised relatively easily: the plants’ Improve, Maintenance and Project activities, as well as functions such as Finance and HR.

The plants retained their core operations and some of the key knowledge bearers.

Central Engineering had also been dissolved, with part of its engineering expertise becoming part of an engineering expertise organisation within DMC.

The logic was clear. Instead of every plant maintaining all these capabilities independently, DMC could pool expertise and allocate resources according to the needs of the plants.

And this was a carefully designed organisation. Resource planning was supported by an extensive planning tool intended to match people and expertise with plant requirements. The way of working was closely aligned with DSM’s work-process documents, and the associated tools were deliberately standardised. I remember, for example, that part of the Asset Utilization data gathering had been built into SAP BW.

There was a strong belief within DMC that this combination of expertise, standardised processes and systematic resource planning made the organisation best in class.

There was quite a lot of justification for that belief.

But I increasingly found myself in an uncomfortable position.

Between the centre and the plants

The former Plant Manager from Scotland had become my boss. He headed four cluster leaders, each responsible for the improvement agenda of a cluster of plants. Each cluster had several engineers who worked more or less dedicated to those plants.

I became one of the cluster leaders.

Together, we also had responsibility for the HR aspects of all our engineers and, more remotely, for the other chemical engineers working in the business parts of the plant organisations.

So although I was part of a central organisation, I spent a lot of time close to the plants.

And that influenced how I looked at the role of DMC.

Some of my colleagues felt that I was too lenient towards the plants.

I understood why.

We had assembled a considerable amount of expertise in DMC. We had standard work processes, standard tools and a sophisticated system for allocating resources. From that perspective, it was quite natural to believe that we knew how things should be done.

But being close to the plants taught me something else.

A plant might do something differently from the central standard for a perfectly good reason. The people working there possessed knowledge that could not always be captured in a process document or a planning system.

I increasingly saw the question not as:

Who knows best — the centre or the plant?

but rather:

How do we combine the expertise of both?

I was not against standards. I was becoming sceptical about the idea that the standard itself was necessarily the best description of reality.

When following the process became the problem

The financial crisis provided a particularly good illustration.

In 2009, the credit crunch put considerable pressure on DSM’s finances and immediate cost savings were required. My boss was asked to establish a team to identify savings opportunities, and I was asked to join it.

Among the initiatives we examined was the effectiveness and efficiency of the maintenance process.

What we found was revealing.

The maintenance organisation was following the prescribed process very carefully.

And yet the process generated a lot of problems.

There were unnecessary delays and discussions built into the way work moved through the organisation. People were doing what the process told them to do, but that did not necessarily make the maintenance operation efficient.

During this period I helped develop what we called the “short route”.

The idea was not to abandon the process. Rather, we identified situations in which some of the prescribed steps added little value and could therefore be shortened under defined conditions.

But the exercise also revealed a different problem.

Many of the plants were old. When equipment failed, an identical replacement was often no longer available.

The alternative was a functionally equivalent, but non-identical replacement.

That immediately raised questions. Was it really equivalent? Did the specifications still meet the requirements? What about engineering, safety, documentation and approval?

The existing process generated plenty of questions and discussions around such cases, but there was no properly organised route for dealing with them.

As a result, non-identical replacements could become uncontrolled exceptions.

So while we were shortening the process where it contained unnecessary slack, we also filled a gap by establishing a way of dealing with non-identical replacements.

This taught me an important lesson:

A good work process is not simply one that people can follow. It has to deal with the situations people actually encounter.

If reality repeatedly falls outside the assumptions built into the process, telling people to follow the process more strictly is not necessarily the answer.

Sometimes the process itself needs to change.

When the standard tool meets a different plant

I encountered a similar issue with Asset Utilization.

One of the plants I supported was a relatively small Engineering Plastics plant. It sometimes produced a deviating product in campaigns, making its operation quite different from the larger, more repetitive plants.

The Asset Utilization application was not particularly strong in handling batch production. During these special campaigns, considerable workarounds were required to make the system represent what was actually happening.

Again, the issue was not whether the plant should use the standard application.

The question was how much effort should be spent making a standard designed around one operating model fit another.

It was another small reminder that standardisation and reality are not always the same thing.

Team targets

Another experiment from this period concerned team targets.

For some groups of employees, people in the lower grades did not receive individual targets. Instead, teams could subscribe to a target which was connected to their bonus.

The important part was not simply the target.

The teams were coached in setting their own goals and determining how they could achieve them.

Instead of:

This is the number you personally have to deliver.

the message became more like:

What do you think your team can achieve, and what are you going to do to get there?

The target created accountability, but the team retained ownership of how to achieve it.

For me, this was another practical example of empowerment through structure.

Empowerment did not mean removing accountability. It meant creating an environment in which people could accept responsibility and work out how to achieve the result.

A central organisation, but not a central answer

Looking back, I think my difficulty with DMC was therefore not really about centralisation itself.

The organisation had been created for good reasons. Pooling expertise, centralising activities where this made sense, establishing common processes and sharing resources could all create real value.

The problem arose when the success of that model encouraged the belief that the model itself was the answer.

The standard work process became the way work should be done.

The standard tool became the way information should be collected.

The resource-planning system became the way resources should be allocated.

And deviations could easily start to look like weaknesses in the plants rather than information about where the central model needed to adapt.

My experience was pushing me in the opposite direction.

I increasingly believed that the centre should provide expertise, structure and standards, but that the plants needed room to apply them to their own reality.

That was probably one of the reasons I welcomed the opportunity to move back into the business.

Back to Engineering Plastics

When an opportunity arose to return to DSM Engineering Plastics, I took it.

In a way, I was moving back towards the environment where I felt I could contribute most effectively: closer to the business, closer to the plants and closer to the people who actually had to make the processes work.

That move, around 2011, brought me to Emmen.

And the question of standardisation followed me there.

But now it appeared in a different form.

Could a standard information system really serve different plants and different ways of operating?

And where should the standard end and local adaptation begin?

Those questions became very concrete when we implemented Asset Utilization in Emmen.

There I would learn that even something as apparently simple as the meaning of a loss category could not simply be prescribed from the centre.

And that experience would eventually lead to a much bigger story about MES, standardisation and the tension between a corporate platform and the reality of the business.

Around 2011, after my period working with team targets and performance management in Geleen, I moved to DSM Engineering Plastics.

The site in Emmen was the largest and most important site in the business. It had a number of extrusion lines and large tumble dryers, where post-condensation of nylon compounds took place.

My original assignment was to develop a track-and-trace application for raw materials.

But by the time I arrived, the immediate priority had changed. The site needed either a substantial cost reduction or an increase in capacity — both were considered valid outcomes.

I therefore became part of a team supporting the site, with McKinsey also involved.

First improve, then sustain

The largest improvements came from what we called S5.

There was a lot of manual work, with various tools and an established way of working that contained considerable inefficiencies. By analysing the actual activities and changing the way the work was organised, the team was able to achieve significant improvements.

The Asset Utilization work process played a different role.

Asset Utilization was essentially our DSM version of OEE. We measured performance and registered the causes of losses.

But the site did not initially see it as the tool that would produce the improvement.

The improvement team was already working directly on the major performance problems.

Instead, Asset Utilization was seen as a way to sustain the improvement after the team had left.

That made sense to me.

A project team can identify problems and change the way work is done. But eventually the project team disappears. The organisation then needs a way of knowing whether the improvement is still there.

So I needed to establish the current performance, identify the major performance killers and make the information available centrally. The intention was to publish the data through SAP BW.

The logic was simple:

First improve the process.
Then make the improvement visible.
Then continue measuring it so that the organisation can see when the improvement starts to disappear.

But there was another problem.

Before we could sensibly use the data, we needed to agree on what the data actually meant.

What does a loss actually mean?

Before implementing the Asset Utilization functionality in the two Emmen factories, I gave a refresher training on the work process.

The site was already familiar with Asset Utilization, but I thought that a refresher could do no harm.

Part of the training concerned the assignment of a specific loss category to an actual event.

DSM had a standard catalogue of loss categories. That was important because a common catalogue made it possible to compare information between plants.

For the workshop I had prepared five scenarios.

I deliberately made them quite detailed.

They did not simply describe a machine stopping. A scenario might describe a disturbance that was already underway, followed by a particular action that the operator had forgotten to take, which then caused another loss.

I asked the participants to assign a standard DSM loss category to each scenario.

The group consisted of several operators, a shift leader, the Improve engineer, the Maintenance engineer and the Plant Manager.

The result was surprisingly lively.

Different people assigned different categories to the same event.

The discussion then moved to the meaning of the individual terms in the standard catalogue. What exactly did a particular category mean? Where was the boundary between two apparently similar categories?

This was more than an exercise in getting the right answer.

It showed me that a standard vocabulary is only useful if the people using it attach the same meaning to the words.

And that led me to propose something that might initially sound contradictory to standardisation.

The site should be allowed to have a site-specific loss-category catalogue, provided that every local category could be translated into the DSM standard categories.

The system would contain a translation table.

The responsibility for creating that mapping would be with the local team.

My argument was simple:

These terms are used for mutual communication. It is important that everybody understands the same thing when we use them.

The corporate catalogue remained useful for comparison and reporting.

But the local organisation had to make sure that the terminology actually worked for the people who used it every day.

This became a principle I would encounter repeatedly afterwards:

standardisation does not necessarily mean that everything underneath the standard has to be identical.

Not everything is an equipment failure

There was another aspect of the Asset Utilization approach that was important to me.

A loss did not necessarily have to be attributed to a piece of equipment.

We wanted to understand what had actually caused the loss.

That could be an equipment failure. But it could also be something that happened in the operation: an action that was not taken, an operating mistake, or another way in which the work process had failed.

The purpose was not to blame someone.

I had learned this already from working with performance data in the control room: an operator should not be held responsible for something he or she cannot influence. But if an operator’s response can influence the outcome, making that visible can be useful.

That distinction was important.

The data was intended to help the organisation learn and improve, not simply to identify somebody or something to blame.

This would later become an interesting contrast with Covestro’s Production Loss Accounting, where the concept of a “bad actor” was much more prominent — and where a bad actor was an object, such as a piece of equipment.

At the time, however, I was still working within DSM.

And another development was about to make the question of standardisation much bigger.

One work process, one application

Corporate Operations was reinforcing the DSM work processes and wanted each of them to have a standard application.

The idea was straightforward:

One work process, one standard application.

Asset Utilization was one of the first candidates.

Corporate Operations approached us — the Business Group COO and me — with an attractive proposition. The first three implementations would receive financial support from Corporate and consultancy support from KPMG.

After some initial hesitation, we decided to take the opportunity.

And suddenly we were implementing the first DSM standard application for Asset Utilization.

Corporate took the lead in the process. They selected the system and led the development of the requirements.

The other two candidates for the first three implementations never materialised.

So for quite some time I was effectively the only person involved who had a direct stake in getting the system right for my own business.

Corporate had a stake in creating a standard.

I had to live with the result.

And there was an important difference in how we looked at the system.

Corporate defined the scope as Asset Utilization.

But the platform selected was an AVEVA/Wonderware MES platform.

I could already see much more potential in it, particularly for Operate Plant. This materialised when later all compounding related departments were combined into a single department with – yet again – a new centralized control room. The MES system was extended with a number of Operate Plant Normal functionalities that made this consolidation possible.

Corporate did not see it that way. From their perspective, this was an Asset Utilization application. The fact that the underlying platform was an MES was not the purpose of the project.

For me, that distinction was becoming increasingly artificial.

If we were establishing an MES platform in our plants, why would we regard its use for other work processes as something completely separate?

There were many discussions.

And this was my first real experience of a problem that would return later in my career:

what exactly are we standardising?

A particular application?

A work process?

A technical platform?

Or the way people actually work?

The template grows

The first implementation was followed by a second installation at our Evansville site in the United States.

The third candidate still did not materialise, so later we implemented another installation ourselves in Genk, Belgium.

By then, what had started as an Asset Utilization application was becoming a reusable template.

But a template immediately raises another question:

How much of it should remain the same when the operation changes?

That question became particularly relevant when I later moved to DSM Resins.

The Resins operations were quite different from the extrusion lines and post-condensation tumble dryers of Engineering Plastics. The template could therefore not simply be copied. It had to be significantly modified.

That experience reinforced something I had already learned in the Emmen workshop.

Standardisation was valuable, but it had to leave room for the reality of the operation.

And that, in the end, was perhaps the most important lesson I took from Emmen.

The system was not valuable because it was a DSM standard.

It was valuable because it helped people understand what was happening in their operation — and because the organisation could use that information to sustain improvements and improve again.

The technology was becoming more important.

But the question of who the technology was ultimately serving remained the more important one.