Responsibility

THE TENSION

Responsibility. Most technical leaders believe they own their outcomes - until something goes wrong and the first instinct is to locate the cause somewhere other than themselves. The invisible line between ownership and blame is where leadership either starts or stops.

“When you blame the process, you give away the power to change it.”

THE SCENARIO

Thomas O’Brien has been Operational Mapping Team Lead at Queensland Fire and Emergency Services for fourteen months. His role is high-stakes: his team produces the real-time mapping that supports bushfire, flood, and cyclone response across the state. Getting it wrong has consequences that extend far beyond the office.

A recent activation went poorly. The spatial products his team produced for an evolving flood event were delivered late and contained boundary errors that caused confusion in the field. At the post-incident debrief, Thomas is thorough. The data request process was unclear. The system was under load. One team member was ill at a critical point. Two of the layers came from an external supplier whose metadata was inconsistent.

Every point is accurate. The room listens. And then moves on without resolution.

Thomas’s manager pulls him aside afterwards. “I hear what you’re saying about the process,” she says. “But what’s your part in it?”

Thomas pauses. He hadn’t framed it that way. He had catalogued the causes - correctly - without ever asking what he could have done differently. The activation had several points where a decision from him might have changed the outcome. He’d seen the risks building. He’d hoped they’d resolve.

WHAT’S DRIVING IT

Responsibility, in the Being Framework, is not about blame or fault. It is about being the primary cause of what happens in your domain - choosing to respond rather than react, and to own outcomes regardless of their source. When Thomas catalogued the system failures, he was being accurate. What he was not being was responsible.

The distinction matters because responsibility is where power lives. When you locate the cause of a failure entirely in the process, the platform, or the team member who was ill, you simultaneously locate yourself outside the problem - and outside the solution.

Thomas’s manager wasn’t asking him to take blame. She was inviting him to take power.

Technical leaders are often highly skilled at causal analysis. The harder skill is applying that same rigour to their own role in the chain.

A HEALTHY RELATIONSHIP WITH RESPONSIBILITY

A healthy relationship with responsibility means you see yourself as the primary cause of what happens in your team - not because everything is your fault, but because you understand that you are the active agent with the most capacity to influence outcomes. You own both results and consequences, and you make informed decisions rather than waiting for circumstances to resolve themselves.

Others experience you as someone who can be counted on to take ownership, even when ownership is uncomfortable. You welcome being held accountable because you hold yourself accountable first. When something goes wrong, your first question is not ‘what caused this?’ but ‘what’s my part, and what can I do from here?’

REFLECTION PROMPTS

• When something goes wrong in your team, what is your first internal move - to locate the external cause or to examine your role in it?

• What is a current problem in your team that you have framed as a process or system issue - and what would change if you owned it as yours?

• Do the people who report to you experience you as someone who absorbs accountability or someone who distributes it?

• What decision have you been waiting for circumstances to resolve that you could actually make today?

Responsibility is the aspect of being that separates the leader who is acted upon from the one who acts. If that distinction is alive for you - if you can feel the edge between ownership and explanation - the Being Profile is designed to go exactly there.

Get in touch at hello@mappingbeing.com.au

While the organisations referenced exist, the team lead, other people and the team name have been used for demonstration purposes only. Any resemblance to real-life people, teams, organisations or situations is purely coincidental.

Reference: Tashvir, A. (2021). BEING (p. 277). Engenesis Publications.

[Published 13 May 2026]