Introduction
An employee notices that a colleague's script is deleting files instead of moving them. He fixes it, adds error-checking, and saves the entire team hours of rework. The result: he's called in by management for "doing someone else's job." The incident took place in the 1980s, at a municipal data centre. What's striking is how perfectly it maps onto workplace dynamics today.
Scope as a Hard Border
In many IT organizations, the job description has become a line that must not be crossed. Every team defends its territory, and any intervention outside the assigned remit — however well-intentioned — can trigger a defensive response. The logic seems reasonable: clear responsibilities prevent duplication and conflict. In practice, however, it creates a paradox: the most engaged people, the ones who see the full picture and want to solve problems, become a source of friction rather than an asset.
The consequences are concrete. Incidents that fall between two teams' domains go unresolved. Nobody officially "owns" them, so nobody acts. And when someone takes the initiative to step in, they're pulled back into line.
A Silent Race to the Bottom
The most capable IT professionals — developers, architects, DevOps engineers — tend to share one defining trait: they don't just execute tasks, they observe, anticipate, and look for ways to improve. When an organization systematically discourages that energy, it sends a clear message: your initiative is not welcome here.
These are precisely the people with the most options on the market. They leave. They join teams where their way of working is recognized — and more often than not, it's a direct competitor who benefits from their departure.
Retaining IT talent is already hard in a market defined by structural scarcity and high mobility. A culture that punishes initiative makes the problem worse in ways no HR metric captures directly. Turnover climbs, root causes stay opaque, and exit interviews produce polished answers that don't tell the full story.
What DevOps and SRE Figured Out
It's no coincidence that the methodologies driving IT modernization over the past fifteen years — DevOps, SRE, Platform Engineering — all rest on the same core principle: problems don't respect organizational boundaries. An engineer who spots a production anomaly and resolves it without waiting for the right ticket to land in the right queue isn't overstepping. That's exactly what operational resilience requires.
The organizations succeeding at digital transformation aren't the ones with the most precise job descriptions. They're the ones where teams feel empowered to act — and where management reinforces that behaviour rather than penalizing it.
Three Levers to Reverse the Dynamic
The 1980s anecdote belongs to a world of mainframes and batch processing. But the organizational reflex it illustrates is very much alive today. A few concrete actions can reverse it:
- Explicitly evaluate cross-functional initiative, not just execution within the assigned remit. What gets measured gets valued.
- Run blameless post-mortems, creating a space where flagging a problem is seen as a contribution, not a career risk.
- Avoid territorializing responsibility the moment an incident is detected outside someone's domain — the first question shouldn't be "who should have caught this?" but "how do we stop it from happening again?"
The goal isn't to eliminate clearly assigned responsibilities — those remain essential to day-to-day operations. It's to ensure that when a team member spots a problem outside their domain, their first instinct is to flag it or address it, not to look the other way to stay out of trouble.