Building a Culture of Ownership in IT Teams

Why responsibility disappears — and what it takes to bring it back

In 1964, a woman named Kitty Genovese was attacked outside her New York apartment building. Dozens of neighbors heard. Almost none intervened.

Psychologists John Darley and Bibb Latané later studied why. Their finding became one of the most cited results in social psychology: the more people present in an emergency, the less likely any individual is to act. Not because people are indifferent — but because responsibility diffuses across a crowd until it belongs to no one.

They called it the bystander effect.

Hotel IT teams don’t witness emergencies in the street. But they do operate in environments where the same psychological mechanism quietly unfolds — across tickets, teams, and handoffs — every day.

The structural production of non-ownership

In most hotel IT environments, responsibility is defined by system or role. Infrastructure owns the network. Applications owns the PMS. A failed integration between the two sits in the space between — visible to both, claimed by neither.

This is not negligence. It is a predictable outcome of how the work is organized.

When accountability is distributed across enough people, a subtle psychological shift occurs. Darley and Latané observed that diffusion of responsibility doesn’t require bad intentions — it requires only ambiguity about who is supposed to act. In complex IT environments, that ambiguity is built into the org chart.

Work happens. Tickets move. Problems persist longer than they should, bouncing between teams, accumulating context without resolution.

The system records activity. It does not guarantee accountability.

The ticketing trap

There is a deeper problem with how modern IT work is structured.

Ticketing systems create the appearance of accountability without its substance. A task is “complete” when the assigned action is done — not when the underlying issue is resolved. Closure is measured. Outcome is not.

This quietly reshapes behavior over time.

Philosophers would recognize this as a distinction between procedural compliance and genuine responsibility. Following a process and owning a result are not the same thing. But in environments where performance is measured by the former, the latter gradually atrophies.

Jean-Paul Sartre argued that humans are “condemned to be free” — that we cannot escape the weight of genuine choice and its consequences. Ticketing systems offer an escape from exactly that weight. The ticket is closed. The responsibility has been transferred. What happens next belongs to someone else.

This is not a technology problem. It is what happens when structure removes the discomfort of accountability.

What ownership actually requires

Ownership is commonly misunderstood as a personality trait — something some engineers have and others don’t.

This misreading is both unfair and strategically unhelpful.

Research in organizational psychology consistently shows that ownership behavior is less a function of individual character than of environmental conditions. People take responsibility when the structure makes responsibility legible — when it is clear what they own, when outcomes matter more than activities, and when the cost of disengagement is visible.

Genuine ownership in IT means something specific: accountability for the result, regardless of where the issue originates. An engineer who owns a function doesn’t stop at the boundary of their system. They follow the problem across interfaces, maintain awareness of how their work connects to adjacent systems, and hold themselves accountable to the outcome rather than the handoff.

This is not a job description. It is a posture — and postures are shaped by environment.

The architecture of accountability

Ownership is not built by instruction. It is built by structure.

The critical design move is a shift in how responsibility is assigned — not by system or tool, but by outcome. Instead of owning a platform, teams own a process: the reservation flow, the payment lifecycle, network reliability across properties. This reframes what success looks like. It also makes it harder to step back when something goes wrong at the boundary.

Psychologist Edwin Locke’s goal-setting theory offers a useful lens here. Goals that are specific, measurable, and tied to meaningful outcomes produce higher engagement and accountability than vague role descriptions. When a team owns “PMS uptime” rather than “the PMS,” the scope is narrower than it appears. When a team owns “reservation accuracy from booking to check-in,” the accountability is harder to avoid.

End-to-end responsibility changes the psychology of problem-solving. Issues are no longer hand