Skip to content
José da Cruz

Enterprise Architect, and Life Thinker

José da Cruz

Enterprise Architect, and Life Thinker

The Volunteer Tax: Why Raising Your Hand in a Meeting Makes You the Permanent Owner

josedacruz, September 25, 2026September 25, 2026

TL;DR: Volunteering to fix something in a meeting feels like a one-time favor, but it usually isn’t. The team quietly remembers who spoke up, and from then on every related problem gets routed to that person by default — no raise, no title change, just a standing tax on their time. Understanding this pattern helps you decide when to speak up and how to hand a problem back once you’ve solved it.

Myth: Volunteering is a one-time favor

Picture a Monday standup. The deploy pipeline broke again over the weekend, and nobody is quite sure why. There’s a pause. Then one engineer — let’s call her Priya — says, “I can take a look after standup.” She means exactly that: she’ll spend an hour today looking into it. But that’s not how the team hears it. From that moment on, the deploy pipeline has an informal owner, and it’s Priya. The next time it breaks, someone will Slack her directly instead of opening a ticket. The time after that, she’ll get looped into a planning discussion about it “since you know that system.” One hour turned into a standing responsibility, and nobody ever decided that on purpose — it just accumulated, one small ask at a time.

Myth: The person who knows the most should own it

This sounds fair on the surface. Expertise and ownership feel like they should go together. But look at how the expertise was earned in Priya’s case: she didn’t get assigned the pipeline because she was the resident expert. She became the resident expert because she got assigned the pipeline, by accident, the day she raised her hand. Ownership created the expertise, not the other way around. That distinction matters because it means anyone else on the team could have become just as capable if they’d been the one to speak first that Monday. Treating “most knowledgeable” as a natural, earned state hides the fact that it was often just a coin flip decided in a two-minute silence during standup.

Myth: If the workload gets unfair, someone will notice and fix it

In theory, a manager glancing at ticket boards or sprint velocity should spot that Priya is quietly buried in pipeline work nobody else touches. In practice, this kind of load is almost invisible in the tools teams use to track work. It doesn’t show up as a ticket assigned to her — it shows up as a string of Slack DMs, “quick calls,” and “can you just eyeball this” messages that never get logged anywhere. A manager reviewing the sprint board sees a normal-looking distribution of tickets. What they don’t see is that Priya is also the de facto on-call for a system that isn’t officially anyone’s job. Nobody redistributes what they can’t see, so the imbalance doesn’t get fixed by itself — it just grows.

Flowchart showing how a moment of silence in a meeting leads to permanent task ownership
The path from “who owns this?” to permanent ownership rarely involves an actual decision.

Myth: Staying quiet makes you look uncooperative

Plenty of engineers speak up in these moments precisely because they’re worried that staying silent will read as not being a team player. But there’s a difference between being unhelpful and declining to become the sole, permanent point of contact for something. You can offer a bounded amount of help without accepting standing ownership. Saying “I can pair with whoever picks this up” or “I can write up what I know so someone else can run with it” is genuinely cooperative — often more useful to the team long-term than quietly becoming a single point of failure that nobody else can safely touch. The team doesn’t actually need a hero. It needs the problem solved in a way that doesn’t depend on one person being available forever.

Myth: This is really just about individual work ethic

It’s tempting to frame this as a story about hard workers getting rewarded with more work — as if the lesson is simply “don’t work so hard.” But that framing misses what’s actually happening structurally. The team has an expected model of ownership (work is supposed to be shared roughly evenly, based on skills and capacity) and an actual model of ownership (work sticks to whoever spoke first, regardless of whether that’s sustainable). The gap between those two models isn’t caused by anyone’s character. It’s caused by the fact that “who owns this?” moments almost never get followed up with a real decision — a written-down owner, a rotation, a plan to spread the knowledge. Without that follow-up, the informal answer from the first awkward silence just becomes the permanent answer.

Block diagram contrasting the expected model of evenly shared ownership with the actual reality of one engineer owning everything while others stay idle
What teams expect ownership to look like, and what it usually looks like six months later.

So what actually helps?

None of this means you should never volunteer — someone has to say something when a system is on fire. The fix isn’t refusing to help; it’s making the handoff explicit instead of letting it default into permanence. A few things that work in practice:

  • Name the scope out loud. “I’ll investigate today” is different from “I’ll own this.” Say which one you mean.
  • Write down what you learn, immediately. A short doc turns “ask Priya” into “read the doc,” which is the difference between a bottleneck and a resource.
  • Ask for the follow-up decision. After you fix the immediate fire, ask your manager or team explicitly: is this now a permanent responsibility, and if so, whose? Don’t let the answer default by silence a second time.
  • Rotate on purpose. If a system genuinely needs an owner, make that a deliberate, visible assignment — not a residue of who happened to speak first.

The volunteer tax isn’t a moral failing on anyone’s part. It’s what happens when a team never converts an informal “I’ll take a look” into an actual, examined decision about ownership. The fix costs almost nothing — a sentence of clarification, a doc, a follow-up question — but it has to be said out loud, because silence is what created the problem in the first place.

Related

architecture engineering managementoffice politicsorganizational-behaviorownershipteam dynamics

Post navigation

Previous post
Next post

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

  • architecture (154)
  • artificial-intelligence (6)
  • books (2)
  • courses (4)
  • decision-frameworks (4)
  • finances (1)
  • java (8)
  • life-improvement (20)
  • metrics (3)
  • observability (2)
  • puzzles and challenges (3)
  • reviews (1)
  • security (8)
  • spring-boot (36)
  • Systems Thinking (3)
  • GitHub Weekly: MCP Tools Trending Right Now (September 28 – October 4, 2026)
  • The Bulkhead Pattern: Why One Slow Dependency Shouldn’t Sink the Whole Ship
  • Essential Reading: A Philosophy of Software Design — Fighting Complexity One Module at a Time
  • GitHub Weekly: Top 10 Trending Repos (September 21 – September 27, 2026)
  • The Volunteer Tax: Why Raising Your Hand in a Meeting Makes You the Permanent Owner
©2026 José da Cruz | WordPress Theme by SuperbThemes