“Don’t Touch My Area” — Improvement or Stepping Into Someone Else’s Role?

At a screen showing the company’s sales tool. Olek shows Marek a simpler version of a process he redesigned on his own initiative.

— We can cut this from six steps to two.
— Who told you to change this process?
— Nobody. I wanted to simplify it.
— I spent years building this. Do you know why those steps are there?

Olek sees a technical process that can be improved. Marek also sees years of his own decisions and responsibility.

What really happened

Olek sees a process that could be simpler. Marek sees the same process, but beyond the steps and forms he also sees years of work, decisions, knowledge, and accountability. When Olek changes it without consulting him, he is unintentionally touching not only a procedure but something Marek experiences as part of his professional territory. That is why Marek’s reaction is stronger than Olek expects. Olek hears, “nothing is allowed to improve.” Marek hears, “what you built for years made no sense.” Their conflict is not only about process quality. It also touches identity, competence, and the right to decide what happens in “my” area.

What the research says

People in organizations can experience ownership not only over desks or equipment, but also over ideas, roles, relationships, projects, and ways of working. When someone else enters that space, people may defend it much like territory — organizational territoriality (Brown, Lawrence & Robinson, 2005). That does not mean Marek is right and the process should remain untouched. It means the process may carry more than technical meaning for him. If the change is presented as “fixing something someone did badly,” task disagreement can easily become a judgment about the person’s professional value (task and relationship conflict; Simons & Peterson, 2000).

How to handle it

A better opening than “I built a better version” is: “Show me what this process protects and what we cannot afford to lose.” The experienced person can then explain why the existing solution was designed that way, while the newcomer can identify which parts may no longer be necessary. A shared criterion helps too: “What must stay, what can we simplify as a test, and how will we know the change works?” The general rule is: the more of someone’s history and responsibility is embedded in a solution, the more important it is to separate evaluating the solution from evaluating its author — and to invite the owner of the knowledge into the change rather than changing it over their head.

How Empatyzer and Em can help

Empatyzer can show Olek in advance that for Marek this process is not just six steps on a screen. It is also part of his accountability, expertise, and professional history. Assessment data and role information let Em see the difference between Olek’s drive to simplify and Marek’s attachment to quality, safety, and ownership of the area. Before the conversation, Em can suggest a different entry point: “I see a way to shorten the process. Can you show me why these steps were introduced before I propose the change?” Marek keeps his status as the owner of the knowledge, while the idea can still be tested. Team-level insights can reveal similar tensions between innovation and experience, and micro-lessons teach that solutions are easiest to change when their authors are not forced to defend their own value.