This post is mostly a reflection on Irina Stanescu’s article and how it connects with situations I’ve seen, and sometimes created, myself.

The quiet version

My weekend read was about territorial behavior in engineering teams, and it stayed with me longer than I expected. Not because the idea was new, but because it named a pattern that is easy to miss when you are the one doing it.

I have seen the obvious version before: people shutting others out, guarding access, treating a system like private property. That is easy to spot from the outside.

The harder version to catch is quieter.

• It shows up when someone comments on an area you know well and your first instinct is to defend it.

• It shows up when a suggestion feels like an intrusion before you have properly evaluated it.

• It shows up when “this is risky” is partly true, but not the whole truth.

Where it comes from

In platform and data work, I think this is easy to fall into. Ownership matters. Context matters. Bad changes can create real downstream pain. If you have spent enough time carrying production responsibility, some protectiveness is understandable.

The problem is that the feeling may be understandable while the behavior is still counterproductive.

When I look back on situations where I was too defensive, the issue was usually not pure ego. It was something more ordinary:

• I wanted to be consulted earlier.
• I felt responsible for the consequences.
• I did not trust that the full context had been considered.

Those are all legitimate concerns. But if they come out as territorial behavior, they do damage anyway. People stop raising ideas early. They become more careful around you than they should be. Collaboration becomes slower and more political than the work deserves.

Catching it in yourself

That was the part of the article I found most useful: not how to deal with territorial behavior in others, but how to deal with it in yourself.

For me, the practical version looks like this.

• First, slow the reaction down. The first defensive thought is not always wrong, but it is often incomplete. If I move too fast from discomfort to rejection, I skip the part where I might learn something.

• Second, separate the technical objection from the ownership emotion. Sometimes an idea is genuinely weak. Sometimes it only feels wrong because it touches an area I identify with. Those are not the same thing, and mixing them makes the conversation worse.

• Third, say the real concern plainly. “I want to understand the impact before we change this.” “I would like to be part of this decision.” “I am worried about the operational cost if this goes wrong.” Those are much more useful statements than acting like the territory itself needs defending.

The cost of getting it wrong

I do not think this is only a management problem or only a Staff-level problem. But as your scope grows, the cost gets higher. If people learn that bringing you an idea means walking into a defensive conversation, they will either avoid you or work around you. Neither outcome is good for trust, and neither helps the system.

One small adjustment

I am writing this mostly as a note to myself. I do not think I have this solved. I just know that some of my worst collaborative moments started with a reasonable concern expressed in an unhelpful way.

The adjustment I am trying to make is small but difficult: ask one more question before saying no.

That alone does not solve everything. But it creates enough space to tell the difference between real technical risk and simple territorial reflex. In my experience, that distinction matters more than it first appears.

Weekend read: The Ownership Problem: Why We Get Territorial And What To Do About It by Irina Stanescu