Table of Contents
Have you ever spent weeks on a project, delivered it, and discovered that “the direction was completely wrong from the start”? Or run dozens of meetings on a task where nobody had authority to make a decision — and watched it quietly disappear without resolution? This isn’t bad luck, and it’s not your fault. EP667 of 大人的Small Talk names this pattern “sucker tasks” (冤大頭工作), and identifies five structural causes you can learn to recognize before they consume your time.
TL;DR
- Sucker tasks aren’t random — they follow five identifiable structural patterns
- Five root causes: unclear goals, no decision-maker, no acceptance criteria, insufficient resources, no feedback loop
- Most wasted work already contains at least one of these causes before it starts
- The fix isn’t working harder — it’s asking the right questions before you begin
- This is a shared responsibility between employees and managers
What Makes a Task “Wasted Work”
Not all hard or frustrating work is wasted work. The specific pattern: you invest significant time and energy, and the output has near-zero actual impact. Unlike “busy work” (which is exhausting but produces results), sucker tasks are structurally doomed from the start — you just usually don’t find out until after you’ve finished.
Cause 1: No Clear Goal
“Make this good,” “clean this up,” “look into it” — what these assignments share: no clear completion standard.
When the goal is unclear, the executor has to guess. Guessing right is luck; guessing wrong is wasted work. And whether you guess right depends on how well you understand what the assigner expects, not on your actual ability.
The fix: Before accepting a task, ask: “What does done look like? What form is the output? Who uses it?” If the answer is “whatever you think,” that’s a warning sign — the goal itself hasn’t been thought through.
Cause 2: No Decision-Maker
A task is running, but who has authority to say “this is good enough”?
Much wasted work in organizations happens because the person who can approve the work isn’t available, or there simply isn’t a single owner for the task. The result: endless revision cycles, indefinite “let’s review it again” loops, or the task simply disappearing with no resolution.
The fix: Confirm that there’s one named decision-maker, and that their availability aligns with the task’s timeline. If the decision-maker’s window is uncertain, align on “when can I get a clear direction?” before starting work — not after.
Cause 3: No Acceptance Criteria
Even when the high-level goal is clear, “what level of done counts as done” is often left undefined.
This puts the executor in a state of sustained anxiety: unsure how detailed to go, whether to dig deeper, worried about doing too little or too much. It also makes it impossible for the assigner to assess whether “what was delivered is what I wanted.”
The fix: Before starting, use something like “If I deliver X, would you consider this task complete?” to force acceptance criteria into the open.
Cause 4: Insufficient Resources
Resources means: time, people, information access, decision authority.
When task expectations and available resources are mismatched, wasted work is nearly inevitable. The most common version: being asked to produce a report in a week that needs a month of data gathering; needing cross-team coordination with no coordination mechanism; needing a decision approved through too many layers to be timely.
The executor’s choices are: produce something that looks complete but is actually cobbled together — or say clearly upfront that “this level of resource can’t meet this expectation.” The second is harder to say; the first is a direct path to wasted work.
The fix: After receiving a task, immediately ask: “What do I need to achieve this?” If resources and goals don’t match, surface this before starting — not halfway through.
Cause 5: No Feedback Loop
Some tasks are delivered and then disappear. No “looks good,” no “this doesn’t work,” no “here’s how this gets used.”
For the executor, this removes meaning. For the organization, it removes any learning opportunity — the same wasted-work pattern can reappear three months later.
The fix: After a task is complete, proactively follow up on how the output was used. Not just for personal satisfaction — to build a feedback loop: “Was this useful? Which parts? Which weren’t?” This information makes your next piece of work more directionally sound.
The Structural Picture
graph LR
T[Task starts] --> G{Clear goal?}
G -->|No| W[High wasted-work risk]
G -->|Yes| D{Named decision-maker?}
D -->|No| W
D -->|Yes| A{Acceptance criteria?}
A -->|No| W
A -->|Yes| R{Resources sufficient?}
R -->|No| W
R -->|Yes| F{Feedback mechanism?}
F -->|No| L[Task complete, but no learning]
F -->|Yes| S[Work that actually has impact]
W --> S2[Done — and then you find out it was wasted]
Summary
Sucker tasks are hard to avoid because at the start they look identical to real work — same meetings, same output requirements, same time investment. The difference is structural: when any of the five causes is present, the task is architecturally unlikely to produce actual impact.
Recognizing these five causes isn’t about shifting blame (“that’s the manager’s problem”). It’s about knowing what questions to ask before the task begins. Most sucker tasks can be identified in the first 30 minutes of receiving the assignment — if you know what to look for.
References
🇺🇸 English
Here's the script:
---
You've been there. Weeks of work, dozens of meetings, a polished deliverable — and then someone says, "Oh, we actually went in a different direction." And the worst part? The direction was wrong from day one.
This isn't bad luck. It's a pattern. The podcast 大人的Small Talk calls these "sucker tasks" — and once you know the five structural causes, you'll start seeing them everywhere.
---
Here's what separates sucker tasks from just hard work: you invest real time and energy, and the output has near-zero actual impact. The brutal part is that sucker tasks look identical to real work from the outside. Same meetings, same effort, same deliverables. The failure is baked in structurally — you just don't find out until after you've finished.
So let's go through the five causes.
**First: no clear goal.** "Clean this up." "Look into it." "Make this better." Sound familiar? When an assignment has no clear completion standard, you're not doing work — you're guessing. And whether you guess right has nothing to do with your ability. It depends entirely on how well you can read the mind of whoever gave you the task. Before you accept anything like this, ask: what does done look like? What form is the output? Who actually uses it? If the answer is "whatever you think," that's your first warning sign.
**Second: no decision-maker.** A task is running, but who has the authority to say "this is good enough"? In most organizations, this person is either unavailable, or genuinely doesn't exist for that task. What you get instead: endless revision loops, perpetual "let's review again" meetings, or the task quietly dying with no resolution. Before you start, you need a single named decision-maker and a realistic sense of when they're actually available to give direction. Find that out before you've already put in the work.
**Third: no acceptance criteria.** Even when the goal is somewhat clear, "what level of done counts as done" is usually left open. This creates sustained anxiety for the person doing the work — how deep do I go, is this enough detail, am I doing too much or too little? And on the other side, the person who assigned it has no real way to evaluate whether what you delivered is what they wanted. A simple way to force this into the open: before you start, ask "If I deliver X, would you consider this complete?" Make them answer yes or no. That question alone surfaces more assumptions than most kickoff meetings.
**Fourth: insufficient resources.** And resources here means more than budget — it means time, people, access to information, and decision authority. The most common version: you're asked to produce a report in a week that actually requires a month of data gathering. Or you need cross-team coordination with no mechanism to get it. Or a decision has to pass through so many approval layers that by the time it comes back, the window has closed. The executor's temptation is to produce something that looks complete but is actually held together with assumptions. That's a direct path to wasted work. The better move — and the harder one — is to surface the mismatch between resources and expectations before you begin, not halfway through.
**Fifth: no feedback loop.** You deliver the work. It disappears. No "great job," no "this didn't land," no "here's how we actually used it." For the person who did the work, this strips away meaning. For the organization, it removes any chance to learn — so the same structural failure can replay three months later, fresh, as if it never happened before. The fix here is active: after a task closes, follow up on how the output was actually used. Not for validation — for calibration. Which parts were useful? Which weren't? That information makes your next piece of work substantially more likely to matter.
---
Here's what ties all five together. Think of it as a quick checklist you run in the first 30 minutes after receiving an assignment. Is there a clear goal? Is there a named decision-maker? Do we have agreed acceptance criteria? Do I have the resources to actually meet the expectation? And is there a feedback mechanism after delivery? If any of those is missing, you're not yet working on a real task — you're working on a sucker task in progress.
The point isn't to shift blame. Managers own some of these failures, employees own some, organizations own some. But the person who can catch these problems earliest is almost always the person receiving the task — because they're the one about to invest the time.
Most wasted work can be identified before it starts. You just have to know what you're looking for.
---
Three things to take away: One — sucker tasks are structural, not random. They follow the same five patterns every time. Two — the window to catch them is right at the beginning, not after you've delivered. Three — the intervention isn't working harder. It's asking better questions before you say yes.
🇹🇼 中文
有沒有這種經驗:花了好幾週做完一個專案,交出去之後才發現——方向根本就不對。或者開了幾十場會,最後任務就這樣消失了,沒有人知道它去哪裡。這不是你倒楣,也不是你哪裡做錯。「大人的 Small Talk」把這種現象叫做「冤大頭工作」,而且背後有五個可識別的死因。
先定義清楚:冤大頭工作的核心特徵是——付出了相當的時間和精力,但實際影響接近於零。它跟「忙但有成果」的忙碌工作不一樣,冤大頭工作的輸出從一開始就注定沒有意義,只是這件事通常要到工作結束之後才變得清楚。
第一個死因:目標不清。「把這個做好」、「整理一下」、「研究看看」——聽起來熟悉嗎?這類描述的共同問題是:完成的標準在哪裡?當目標模糊,執行者只能靠猜測。猜對了叫運氣,猜錯了就是白工。破解方式很簡單——在接任務前就問清楚:這個任務的完成標準是什麼?輸出是什麼形式?給誰用?如果對方說「隨便你」,那本身就是個警訊。
第二個死因:沒有決策者。任務啟動了,但誰有權說「這樣就好了」?很多白工的來源是:執行者做完了,但能拍板的人沒空,或者這個任務根本沒有一個明確的負責人。結果就是反覆修改、無止盡的「再看看」,最後任務就消失了。破解方式是:確認任務有一個明確的決策者,而且這個人的時程和任務時程是對得上的。如果決策者的窗口不確定,先討論「什麼時候能得到明確方向」,而不是先埋頭做。
第三個死因:沒有驗收標準。即使大方向清楚,「做到什麼程度算達標」常常是模糊的。這讓執行者持續處於焦慮狀態:不知道要做多細、不確定要不要繼續深入、擔心做太少或做太多。一個實用的做法是:在任務開始前,用「如果我交出這個,你會認為任務完成了嗎?」這類具體問題,把驗收標準逼出來。
第四個死因:資源不足。資源包括時間、人力、資訊存取和決策授權。最常見的情況是:被要求一週內完成需要一個月資料蒐集的報告,或者需要跨部門協作但沒有協調機制。執行者在這種情況下通常會選擇做一個「看起來完整但實際上是湊出來的」東西。這是做白工的捷徑。正確的做法是:拿到任務後先確認資源和目標是否匹配,不匹配就在開始之前提出,而不是做到一半再說。
第五個死因:沒有回饋迴路。有些任務做完送出去之後,就石沉大海。沒人說好,沒人說不好,也沒人說這個之後怎麼用。對執行者來說,這讓工作失去意義;對組織來說,這代表沒有學習機會——同樣的白工三個月後可能再出現一次。破解方式是在任務結束後主動跟進:「這個有用嗎?哪裡有用?哪裡沒用?」這些資訊讓你下次的工作更有方向。
把五個死因串起來看,其實就是一條清單:目標清楚嗎?有決策者嗎?驗收標準確認了嗎?資源足夠嗎?有回饋機制嗎?任何一個環節缺失,這個任務在結構上就很難產生實際影響。
最後三個核心帶走:第一,冤大頭工作不是偶然,是可識別的結構性問題。第二,大多數的白工其實可以在接任務的前三十分鐘就被識別出來——前提是你知道要問什麼問題。第三,這不是推卸責任的框架,而是讓你在任務開始前就把問題問清楚的工具。更努力不是解法,問對問題才是。
Tags
Related Articles
Don't Envy People Who Dare to Move Abroad or Start a Business — They've Just Seen Enough People
People who seem fearless about big moves aren't braver by nature — they have richer reference points. They've seen enough people 'do the thing and survive' that the unknown has become an estimable risk. And that's something you can deliberately build.
How AI Reshapes How You Think: The Cognitive Shift Beyond the Tool
AI tools change more than your speed — they change how you think. The shift from 'how to do it' to 'what to do' and 'is this right?' has real long-term implications for engineers.
10 Weird OSS Projects You Actually Need
From Carbon (code-to-image), nektos/act (run GitHub Actions locally), to Ink (React-based terminal UI) — 10 OSS projects that each solve one specific problem really well.