Responsibility Bingo

A Game No One (really) Wins


There's a quote attributed to Abraham Lincoln: "Give me six hours to chop down a tree and I will spend the first four sharpening the axe." Whether he actually said it or not doesn't matter. The point stands. The preparation is not the delay, the preparation is the work.

The story is quite famous among my peers. In its variations, let's use this one to make a point:

Organizations need to cut down trees (metaphorically speaking). Instead of sharpening the axe they already own, they order a new one. The new one arrives, it's shiny and came with a nice pitch deck. That one doesn't get sharpened either, so the result is...you get the point. (→ The Axe get’s dull. Cutting trees takes a very long time again. “They” order a new Axe).

Two sprints (fixed time cycles for delivery) later, someone suggests maybe the problem isn't the axe, maybe it's the tree! So, a consultant gets hired. A workshop gets scheduled. And the original axe sits in the garage, untouched, still perfectly capable of doing the job if anyone had bothered to sharpenit.

This is what happens in organizations more often than most would admit. And when it does, the same question floats through the room, spoken or unspoken:

whose responsibility is it to sharpen the axe?

That question sounds reasonable. It isn't. Because the moment someone asks "who is responsible?" the axe is already lying on the ground and no one is picking it up. Let me elaborate:

Shouting into the Forest

A Product Owner (the person responsible for maximizing the value a team delivers) I supported needed a yearly absence overview for two teams. The idea made sense: if you're planning support coverage, you need to know who's out when. Fair enough I thought, though a bit puzzling that an organization that size didn't already have something in place. The PO had been in the company for fifteen years. So, the request came to me: "Can you set up an Excel for the team's availability?"

The PO mentioned that Confluence (a shared knowledge platform the entire department uses) couldn't handle it properly. Fifteen years of company experience felt like a reasonable basis to trust that claim. So four hours went into building the spreadsheet. Formatted, shared, ready to maintain. When approaching the other teams to include their data, the other team's Scrum Master looked confused: "Why? We have this in Confluence. The entire department uses it."

Three clicks later: Add a team calendar, subscribe, adjust the time range. That's all it would have taken. The solution had been sitting in the tool the PO had been using for multiple years.

The reaction was a mix of annoyance, embarrassment, and something close to disbelief. Four hours, gone. Back to the PO with the discovery. The response: "Oh. Well, show me next time. But I still prefer Excel."

Five hours total. Four building a spreadsheet that already existed. One going back and forth. One search query could have prevented all of it. One question to an internal LLM (Large Language Model, the technology behind tools like ChatGPT or Claude): "Where does the department track absences?" That's all it would have taken.

So whose responsibility was the whole thing? The Product Owner's, for not knowing what tools existed in their own department after fifteen years? The Scrum Master's — so, me —, for not asking "does this already exist somewhere?" before spending four hours building it? The department's, for not making it visible enough?

The answer is all of them. And none of them. Because the question itself is the problem. Asking "whose responsibility?" is already the first step away from taking it. The PO didn't know Confluence well enough. I took the request at face value. The department assumed it was common knowledge. Each position was reasonable on its own. And between all those reasonable positions, five hours disappeared into a spreadsheet that already existed.

Responsibility doesn't begin with a title or a role description. It begins with the decision to look before building.

The Projection

The same pattern showed up in a different room. In a session about how to properly set up a work management tool, one of the product owners said: "Yeah, but that would require real discipline from the people."

That sentence sounds like a practical concern. It's actually a verdict. It says: even if we invest the time to set this up properly, the people on the other end will fail. So why bother?

And it goes even a bit deeper:

In 1960, management theorist Douglas McGregor described two assumptions abouthuman motivation. Theory X assumes people are inherently lazy and need control. Theory Y assumes people are self-motivated and capable if given the right conditions.

Ask a room full of people: "Do you know someone who fits Theory X? Someone who avoids work, needs constant oversight, doesn't take initiative?" Almost every hand goes up. Then ask: "Would you describe yourself as Theory X or Theory Y Person?" And pretty much everyone considers themselves a Y-Person.

A room full of self-declared Y-people who all know X-people, but none of them are one.

The best part in all of this is, the Theory X person doesn't really exist. It's a projection. Pointed outward. Rarely turned inward.

Projecting responsibility onto "the people" is just another way of not taking it yourself.

"They need discipline" means "it's their problem."

"They won't use it properly" means "so it's not worth MY effort."

The projection becomes the excuse, dressed as an "observation".

But here's the part that makes it genuinely complicated: the people in that room aren't making things up. They DO see disengagement. They DO see colleagues who don't "seem to care". What they're seeing is real. The explanation is just wrong. It's not laziness. It's a system that has planned every minute so tightly that there's no room left for anyone to engage deeply with anything. Including the tools they're expected to use.

The Century-Old Blame Game

The product owner in that session also said: "Even if we do all that, it won't solve all our problems!" Immediately followed by: "Who's supposed to set something like that up? Who has the time? We most certainly don't!"

Let's ignore the fact that sharpening your tools won't fix all your problems — no one really ever said they would. (And those who do are lying to you.)

So, those aren't lazy questions. They're exhausted ones. They come from people who have been planned at 120-150% capacity for so long that the idea of slowing down to do something properly feels like a luxury they can't afford.

But the pattern of explaining away responsibility is older than any of us. In 2022, Canadian researcher Paul Fairie compiled every newspaper headline and media snippet he could find containing the phrase "Nobody wants to work anymore." The compilation stretched all the way back to 1894. Over a century of the same complaint. Every generation convinced the next one just doesn't “want to put in the effort”.

It was never true. Not in 1894. Not in 1952. Not in 2026. The world changed. The reflex didn't. Instead of looking at the conditions, someone pointed at the people and said “they just don't want to.

That might be the oldest responsibility shift in the book. And it doesn't just apply to employees. It applies to tools:
"Jira doesn't work."
"Confluence is too complicated."
"The framework isn't the right fit."
Same sentence, same structure, same function: pointing at something else so the uncomfortable question of what wasn't invested in doesn't come up. Every example so far is the same pattern wearing a different costume. A PO who doesn't check. A room that projects. A generation that blames. The costume changes. The pattern doesn't. And the pattern has a system underneath it.

Having "Nothing" to do

In 1981, software engineer Barry Boehm published research showing that a defect found during the requirements phase costs roughly 1x to fix. The same defect found during coding costs 10x. Found after delivery: up to 100x. The math is clear: every hour invested in preparation saves multiples of that in execution. Sharpening the axe isn't just a nice idea. It's measurably cheaper than swinging a dull one.

And yet. There was a time when "we'll fix it in the next version" wasn't an option because the next version was eighteen months away. When software shipped on physical media and a manufacturing defect meant a recall. In that world, taking responsibility for quality wasn't a value. It was a necessity.

Then updates became cheap. Then instant. If you can always push another fix, another patch, another iteration, then nothing ever has to be truly finished. "Good enough for now" became the permanent standard. Not as a conscious decision. As a drift. The system kept pushing more in, and the time to do things properly quietly disappeared. Because protecting it would have meant someone taking responsibility for saying:"No. We finish this first. Properly!"

A question that comes up often in coaching sessions is: "What would happen if we planned nothing new for one sprint and just...cleaned up?" The reaction: "We can't do that! The Customer/User/department lead/Manager/Other Team...needs X by then." Or: "we can't just do nothing!"

Really? Would there really be nothing to do? "Stop starting, start finishing" is a well-known principle in Lean (a methodology focused on eliminating waste). Most teams know the phrase. Doing it is a very different story. Because stopping requires someone to take responsibility for saying "enough!"

Shopaholic

When sharpening keeps getting deferred, opening catalogues and buying new stuff takes its place.

A team uses Jira. Not well, not badly, just the default setup. Epics and stories, a board, some filters. No one has taken the time to understand what the tool can actually do, because when would they? The hierarchy is flat because it was never configured differently. The workflows are generic because no one mapped them to how the team actually works.

And then: "Jira doesn't work for us. We need something bigger/better/faster/stronger. Let's use THIS other tool as well/on top/instead of..." You get what I mean.

So, a new tool gets purchased. For real money. A lot of money. Something that promises roadmapping features, portfolio views, strategic alignment layers. All things the existing tool could have probably done if someone had taken responsibility for setting it up. The new tool arrives. The time to learn it doesn't. Two (or more) tools, both half-used, neither understood.

Buying a new tool feels like taking action, really, but that's it. It's the system choosing to avoid the responsibility of understanding what it already has.

DLLM: The Dullest Large Language Model

A friend of mine works with an LLM despite her company not allowing it. High security environment. She anonymizes what she can, takes precautions, takes the risk. Her verdict? "Honestly, it's not even that great. The results are mostly garbage, but at least it's faster. I'm drowning in work. I can't keep up otherwise."

When I asked what her prompt looked like, whether she'd set up any context files, system instructions, or anything that helps the model understand what she actually needs, the response was a genuine: "What do you mean? What's that?"

She's using arguably the most powerful knowledge tool ever built. Even taking a career risk to use it (with potential serious legal consequences). And she hasn't spent twenty minutes learning how it works! I was shocked, annoyed to be very honest.

Since the invention of the smartphone, the entirety of human knowledge fits in a pocket. We carry it around with us all day (to just watch silly cat videos). The pattern keeps repeating: a tool arrives, the time to understand it doesn't, the tool gets blamed, the next tool gets purchased. Jira. Confluence. Scrum. OKRs (Objectives and Key Results, a goal-setting framework). And now: AI.
Same cycle. Different price tag.

The axe doesn't sharpen itself. Not when it was made of paper or steel. Not when it was made of hardware. And not now that it's made of code. Someone has to take the time. And taking time is taking responsibility.

But here's what changed: the game is no longer just about internal efficiency. A company recently shared that they genuinely want to work with local suppliers. But while the German companies in question hadn't even sent a cost estimate, a competitor overseas had already started shipping the materials. Not because they're cheaper. Because they're faster. Because someone over there sharpened the axe, cut down the tree, and started delivering while the others were still discussing whose job it was to write the quote.

That's the new reality. It's not just about wasting five hours on a spreadsheet that already exists. It's about the fact that while one organization is playing responsibility bingo, another one has already finished the game. The axe gap isn't an internal problem anymore. It's a competitive one.

A Moment of Your Time, Please

There's a principle in Kanban (a method for managing and improving work): encourage leadership at all levels. Not leadership as a title. Leadership as a behavior. The willingness to say "this is going to take time, and that's okay" even when the system says it isn't.

A team member who doesn't engage with the tools they've been given is not taking responsibility. A leader who introduces a tool without creating space to learn it is not taking responsibility. And asking "who is responsible?" without looking in the mirror first might be the quietest form of not taking it at all.

But responsibility needs room. Teams planned at 120-150% capacity don't have space to sharpen anything. Time is already occupied trying to chop down the promised trees.

The solution isn't telling people to try harder. Cutting trees "harder" with a dull axe just makes people sweat blood and tears and burn out.

The solution is easy: providing the tools to make sharpening the axe easy and welcome, and protecting that space.

A sprint where "nothing" new gets planned and the team cleans up, polishes, finishes, learns. A quarter where someone in the position to do so says: "We need to fully refine and polish our axes this quarter." A moment where buying the next tool gets replaced by the question: "Have we sharpened the one we already own properly?"

Those who want to will find ways to do so. Those who don't will find excuses. And play Bingo.

Responsibility Bingo: A Game No One Wins

Sometimes the sharpest tool is the one someone finally had time to understand. Book a free consultation call:

Next
Next

The Westworld Paradox