{"id":411,"date":"2026-08-24T19:22:59","date_gmt":"2026-08-24T17:22:59","guid":{"rendered":"https:\/\/heusje.nl\/?p=411"},"modified":"2026-08-26T21:47:35","modified_gmt":"2026-08-26T19:47:35","slug":"accountability-without-authority","status":"publish","type":"post","link":"https:\/\/heusje.nl\/?p=411","title":{"rendered":"Accountability without authority"},"content":{"rendered":"\n

The idea of silos<\/em> was not new to me when I joined Covestro.<\/p>\n\n\n\n

When the DSM business units were formed in 1992, several central services were dismantled or heavily decentralised. Maintenance was one example. People who had previously belonged to the same functional organisation became formally colleagues in different business units.<\/p>\n\n\n\n

For the plants it meant that people from different central departmens became colleagues in the same organisation.<\/p>\n\n\n\n

That did not mean that cooperation<\/em> emerged automatically. We had to learn how to work across the new boundaries. “Destroy the silos”<\/em> became one of the familiar expressions for this.<\/p>\n\n\n\n

People like me, with a more academic background and increasingly involved in managerial and coordinating work, were often asked to help make that happen. I experienced this, for example, in my work with the Applied Research department after it had been decentralised. Working from the plant, I inevitably interfered with their priorities. But there was something in it for both sides. When a research idea fitted an actual business or plant priority, the probability that it would eventually be implemented was much higher. Connecting research with the business therefore gave their ideas a better route to application.<\/p>\n\n\n\n

In hindsight, I think this taught me something important: formal organisational boundaries do not determine where the work itself takes place<\/strong>.<\/p>\n\n\n\n

Finding myself between the silos<\/h3>\n\n\n\n

This became relevant again after the transition to Covestro.<\/p>\n\n\n\n

I was initially expected to move into Engineering because Process Automation was responsible there for DCS and MES. I did not want to make that move and eventually found a place in Technology, where I could work with historian functionality and the applications being built on top of it.<\/p>\n\n\n\n

At first, that seemed like an ordinary organisational decision. But it made me increasingly conscious of the difference between where expertise is organised and where a problem actually belongs.<\/p>\n\n\n\n

A control-room project was a good example.<\/p>\n\n\n\n

It might look like a technical project: automation has to be redesigned, a DCS replaced, local panels removed, new equipment installed. But that is only part of the job.<\/p>\n\n\n\n

The plant may also have to reorganise its operation. Roles have to be described. The Works Council may need to be consulted. People have to be informed and selected. People whose positions disappear need to be treated carefully and helped through the transition. Communication has to be organised. At the same time, the technical work has to progress: automation, civil construction, room design, workplaces and equipment all have to come together.<\/p>\n\n\n\n

The plant therefore has one integrated change, while the expertise needed to deliver it sits in several different places.<\/p>\n\n\n\n

I experienced myself as one of the pivots in this process, together with local management and HR. I did not have authority over all these areas, nor did I need to. My role was to understand enough of the different perspectives to see the dependencies and help make the pieces fit together.<\/p>\n\n\n\n

That made me realise that there is nothing inherently wrong with organising expertise in separate departments. Engineering should have engineering expertise; Technology should have technology expertise; HR should have HR expertise.<\/p>\n\n\n\n

But then there needs to be a strong cross-silo capability<\/strong> that can bring those disciplines together around a particular result.<\/p>\n\n\n\n

For a major plant project, this might even mean temporarily making the plant organisation the overriding structure: bringing the relevant specialists together around the project, rather than expecting each function to optimise its own contribution and somehow having the integrated result emerge afterwards.<\/p>\n\n\n\n

I felt that this cross-silo mechanism was not sufficiently present.<\/p>\n\n\n\n

A different organisational memory<\/h3>\n\n\n\n

My DSM experience gave me an interesting comparison.<\/p>\n\n\n\n

The strong decentralisation of DSM had certainly had disadvantages. Some central expertise disappeared. Knowledge networks replaced parts of the former central functions, but those networks had less authority to impose standards and often had little budget for centrally developed applications.<\/p>\n\n\n\n

So decentralisation was not automatically better.<\/p>\n\n\n\n

But we had also learned to work around those disadvantages. Because people were closer to the business and the plants, cross-functional cooperation became part of getting things done. Expertise could be brought in through networks and personal relationships.<\/p>\n\n\n\n

In other words, we had lost some centralisation and standardisation, but we had also developed ways of working across the remaining boundaries<\/strong>.<\/p>\n\n\n\n

That became an important reference point for me at Covestro.<\/p>\n\n\n\n

Deductive and inductive thinking<\/h3>\n\n\n\n

There was another aspect that I came to think about, although I recognise that this is a subjective interpretation.<\/p>\n\n\n\n

One of my German managers once remarked that he saw Germans as tending more towards deductive thinking, whereas Dutch people were more comfortable combining deductive and inductive thinking.<\/p>\n\n\n\n

I found that interesting because it corresponded, at least partly, with how I had experienced my own work.<\/p>\n\n\n\n

Many of the plant projects I had worked on developed quite inductively.<\/p>\n\n\n\n

Take the control-room example. The work might start with a concrete automation problem: a new DCS is required, local panels are becoming obsolete, or another part of the automation infrastructure needs to be replaced.<\/p>\n\n\n\n

Then comes the question:<\/p>\n\n\n\n

\n

If we are changing all this anyway, what should we do with the control room?<\/strong><\/p>\n<\/blockquote>\n\n\n\n

That question leads to others. What should the future operating model be? What should remain local? What should be centralised? What does this mean for roles, workplaces and the organisation?<\/p>\n\n\n\n

Gradually, the larger concept emerges from connecting the individual observations.<\/p>\n\n\n\n

That is an inductive process.<\/p>\n\n\n\n

A silo organisation, by contrast, naturally lends itself more to a deductive way of working. Engineering defines the engineering problem; Technology defines the technology problem; HR addresses the people side; the plant addresses operations. Each can develop a very good answer within its own domain.<\/p>\n\n\n\n

But some solutions emerge only when somebody is able to connect things that were not originally defined as belonging together.<\/p>\n\n\n\n

This is not a statement that people in silos cannot think inductively. It is rather that the organisation gives them fewer opportunities and fewer incentives to do so<\/strong>.<\/p>\n\n\n\n

And this is why I increasingly saw the cross-silo role as more than coordination. Someone needs to create the space in which the different disciplines can discover what their problems have in common.<\/p>\n\n\n\n

Today, I would also be more cautious about the particular solution that emerged from those control-room projects. Mobile technology, remote operation and AI may make entirely different operating models possible. Perhaps the next generation will find ways of combining local presence, remote support and intelligent assistance that we could not have imagined.<\/p>\n\n\n\n

That does not change the point of the example.<\/p>\n\n\n\n

The particular solution may change. The need to connect technology, operations, organisation, people and business purpose does not.<\/strong><\/p>\n\n\n\n

And then came gMES<\/h3>\n\n\n\n

This was the background against which I experienced gMES.<\/p>\n\n\n\n

I was part of the gMES team from Technology, while Engineering led the initiative. The ambition was to develop a standardised MES template that could be rolled out quickly across plants.<\/p>\n\n\n\n

I understood the attraction. Standardisation could make implementation repeatable, and a lean template could make fast rollout possible.<\/p>\n\n\n\n

But two moments made me increasingly uneasy.<\/p>\n\n\n\n

The first concerned the balance between speed and plant value<\/strong>.<\/p>\n\n\n\n

During the initial gap analysis at the first implementation plant, I saw several specific functionalities that addressed concrete issues the plant was already working on and for which MES could provide a useful solution.<\/p>\n\n\n\n

Later, when the implementation speed became an explicit objective, I asked what had priority: making the implementation as useful as possible for each plant, or achieving the desired rollout tempo.<\/p>\n\n\n\n

The answer from the Business was clear: tempo<\/strong>.<\/p>\n\n\n\n

I found that revealing. The speed of deploying the template had become an objective in its own right.<\/p>\n\n\n\n

The second issue was the role of the plant.<\/p>\n\n\n\n

The plants had very limited capacity for this kind of work. Their organisations were lean and concentrated on running the operation. I argued that the plant nevertheless needed to be proactively involved, because what the MES should do and how it would create value depended on the purpose it served in that particular operation.<\/p>\n\n\n\n

Instead, the plant was largely waiting.<\/p>\n\n\n\n

The attitude was understandable:<\/p>\n\n\n\n

\n

I don’t know what’s coming. Let’s wait until it is finished and then see what it is.<\/em><\/p>\n<\/blockquote>\n\n\n\n

But to me that was precisely the problem.<\/p>\n\n\n\n

By the time the plant could see what had been built, many of the choices determining whether it would be useful had already been made.<\/p>\n\n\n\n

I could see Engineering trying to do a good job within its responsibility: develop a good, standardised template and make it possible to roll it out efficiently.<\/p>\n\n\n\n

I could also understand the plant: it had little capacity to engage in something whose outcome it could not yet see.<\/p>\n\n\n\n

Neither side seemed unreasonable to me.<\/p>\n\n\n\n

What was missing, in my eyes, was the cross-silo mechanism that would have made the plant’s purpose the organising principle of the project<\/strong>.<\/p>\n\n\n\n

I could see the problem developing, but I did not have the authority to change the way the project was organised.<\/p>\n\n\n\n

That was the point at which accountability without authority<\/em> became very concrete for me.<\/p>\n\n\n\n

It was not that somebody had formally made me accountable for the entire gMES outcome. It was that I felt sufficiently responsible for the outcome to see the problem coming \u2014 while the decisions that could change the conditions belonged elsewhere.<\/p>\n\n\n\n

What the experience taught me<\/h3>\n\n\n\n

Looking back, I would not conclude that functional departments are the problem. Nor would I conclude that DSM’s decentralised model was inherently superior.<\/p>\n\n\n\n

Both approaches have trade-offs.<\/p>\n\n\n\n

What I came to value was the ability to temporarily organise around the problem rather than around the permanent organisational structure<\/strong>.<\/p>\n\n\n\n

A plant does not experience an Engineering problem, a Technology problem, an HR problem and a management problem separately. It experiences one problem.<\/p>\n\n\n\n

The organisation may need specialised functions to solve the pieces. But somebody still has to connect the pieces back into the one problem the plant is trying to solve.<\/p>\n\n\n\n

That was increasingly the role in which I recognised myself.<\/p>\n\n\n\n

And perhaps that explains why I felt uncomfortable when I was being placed inside one of the silos. I did not primarily see my contribution as belonging to Engineering or Technology. I saw it in the space between them \u2014 connecting the what the plant wanted to achieve<\/strong> with the how the different specialists could make it possible<\/strong>.<\/p>\n\n\n\n

That space has no obvious place on an organisation chart.<\/p>\n\n\n\n

Yet, in my experience, a surprising amount of the success or failure of large projects happens precisely there.<\/p>\n\n\n\n

<\/p>\n","protected":false},"excerpt":{"rendered":"

The idea of silos was not new to me when I joined Covestro. When the DSM business units were formed in 1992, several central services were dismantled or heavily decentralised. Maintenance was one example. People who had previously belonged to the same functional organisation became formally colleagues in different business units. For the plants it […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_heusje_archive_order":140,"footnotes":""},"categories":[22],"tags":[19,18,21,23,20],"class_list":["post-411","post","type-post","status-publish","format-standard","hentry","category-career","tag-career","tag-covestro","tag-dsm","tag-english","tag-work-culture"],"_links":{"self":[{"href":"https:\/\/heusje.nl\/index.php?rest_route=\/wp\/v2\/posts\/411","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/heusje.nl\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/heusje.nl\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/heusje.nl\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/heusje.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=411"}],"version-history":[{"count":4,"href":"https:\/\/heusje.nl\/index.php?rest_route=\/wp\/v2\/posts\/411\/revisions"}],"predecessor-version":[{"id":438,"href":"https:\/\/heusje.nl\/index.php?rest_route=\/wp\/v2\/posts\/411\/revisions\/438"}],"wp:attachment":[{"href":"https:\/\/heusje.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=411"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/heusje.nl\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=411"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/heusje.nl\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=411"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}