{"id":11183,"date":"2026-02-14T16:12:11","date_gmt":"2026-02-14T15:12:11","guid":{"rendered":"https:\/\/salomons.coach\/?p=11183"},"modified":"2026-02-14T16:12:15","modified_gmt":"2026-02-14T15:12:15","slug":"who-is-responsible-for-change-a-new-operating-model","status":"publish","type":"post","link":"https:\/\/salomons.coach\/en\/who-is-responsible-for-change-a-new-operating-model\/","title":{"rendered":"Who is responsible for Change – A new operating model"},"content":{"rendered":"\n

Why this topic still bothers me<\/em><\/h3>\n\n\n\n

For more than three decades, I have been involved in organizational change, sometimes leading it, sometimes advising it, sometimes cleaning up after it. I have worked with executives who genuinely cared, project teams that delivered exactly what was asked, and line managers who did everything they could to keep operations running while \u201cabsorbing\u201d yet another change.<\/p>\n\n\n\n

And still, I have seen the same pattern repeat itself.<\/p>\n\n\n\n

When change struggles, the explanation is often simple: \u201cThe line didn\u2019t pick it up.\u201d<\/em>
Or: \u201cThe project delivered, but the organization wasn\u2019t ready.\u201d<\/em>
Occasionally: \u201cPeople resisted.\u201d<\/em><\/p>\n\n\n\n

What rarely gets questioned is the underlying assumption behind all of this: that change management is something a line manager or a project manager can, or should, just do on top of their real job.<\/p>\n\n\n\n

I have believed that myself at different moments in my career. Especially when results mattered, timelines were tight, and adding \u201canother role\u201d felt like unnecessary overhead. But experience has a way of teaching you where your own shortcuts stop working.<\/p>\n\n\n\n

Over the years, I started to notice something uncomfortable. In organizations where change did<\/em> stick, where new ways of working survived the first crisis, the first peak, the first leadership change, there was almost always an invisible system at work. Not a glossy change plan. Not a flood of communication. But a deliberate way of thinking about ownership, leadership behavior, reinforcement, and the role of managers in making sense of what was happening.<\/p>\n\n\n\n

In organizations where change failed, we often did the opposite. We pushed responsibility downward, assumed capability would somehow appear, and called it \u201cownership.\u201d When it didn\u2019t work, we blamed execution.<\/p>\n\n\n\n

This blog is my attempt to slow that reflex down.<\/p>\n\n\n\n

Not to argue that line managers or project managers are doing a poor job, quite the opposite. But to question whether we are asking them to succeed in a system that was never designed for change to succeed in the first place.<\/p>\n\n\n\n

Over the years, I\u2019ve learned that change doesn\u2019t fail because people don\u2019t care. It fails because adoption is assumed instead of engineered.<\/p>\n\n\n\n

And that is what this blog is really about.<\/p>\n\n\n\n

I have read many books and article on this subject over the years, and combined with my experiences, I thought it was about time to combine the two. This blog is my view on change management as I have learned it, and the operating model I now advise organizations to implement and execute. <\/p>\n\n\n\n

But first things first, lets start with the usual assumptions in the field.<\/p>\n\n\n\n

Change management is often treated like \u201csomething the line manager or project manager can just do.\u201d<\/h2>\n\n\n\n

In many organizations, change management is perceived as soft overhead<\/em>. Something you can \u201cembed\u201d into the line, or \u201cadd\u201d to the project manager\u2019s job. The logic sounds reasonable:<\/p>\n\n\n\n