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

Ask this article

Answers come from this article only. Click any prompt below or open the chat at the bottom right.

🇺🇸 English

Ever spent weeks on a project, shipped it, and then found out the direction was wrong from day one? Or sat through a dozen meetings on some task where nobody actually had the power to make a decision — and then watched the whole thing quietly evaporate, never resolved? Here's the thing: that's not bad luck, and it's not because you're bad at your job.

Episode 667 of the podcast 大人的Small Talk has a great name for this. They call it "sucker work" — 冤大頭工作. And the key insight is that it's not random. It follows five structural patterns, and once you can spot them, you can catch a dead-end task before it eats your time.

So let's define our terms first, because not all painful work is wasted work. There's a difference between "busy work" — the stuff that's exhausting but actually produces results — and a sucker task. The sucker task is the one where you pour in real time and energy, and the output has basically zero impact. The tragedy is that it's structurally doomed from the very start. You just don't find that out until you've already finished.

Okay, five causes. Let's walk through them.

Cause number one: no clear goal. You know these assignments. "Make this good." "Clean this up." "Just look into it." What they all have in common is there's no clear standard for what "done" looks like. So the person doing the work has to guess. And if you guess right, that's luck. If you guess wrong, that's wasted work. Notice that whether you nail it has almost nothing to do with your actual skill — it's about how well you read the mind of the person who assigned it.

The fix is simple but powerful. Before you accept the task, ask: "What does done look like? What form is the output? Who's going to use it?" And if the answer comes back as "eh, whatever you think" — that's your warning light. It means the goal itself was never really thought through.

Cause number two: no decision-maker. So the work is happening, but ask yourself — who actually has the authority to say "yep, that's good enough"? A huge amount of wasted work happens because the person who can approve it just isn't around, or worse, there's no single owner at all. And what do you get? Endless revision cycles. That "let's take another look next week" loop that never ends. Or the task just disappears.

The fix: confirm there's one named decision-maker, and that they're actually available on your timeline. If you're not sure when they'll be reachable, nail that down before you start — not after you've done all the work.

Cause number three: no acceptance criteria. Now this one's subtle, because sometimes the high-level goal is clear, but "how good is good enough" is left totally undefined. And that puts you in this state of constant low-grade anxiety. How detailed should I go? Should I dig deeper here? Am I doing too little? Am I overcooking it? And it cuts both ways — the assigner can't even tell whether what you handed them is what they wanted.

The fix is to force those criteria out into the open before you start. Something like: "If I deliver X, would you consider this task complete?" That one question does a lot of work.

Cause number four: insufficient resources. And when we say resources, we mean the whole package — time, people, access to information, and decision authority. When the expectations for a task and the resources you actually have don't match, wasted work is almost guaranteed. You know the classic version: they want a report in a week that honestly needs a month of data-gathering. Or the task needs cross-team coordination, but there's no mechanism for that coordination to happen. Or a decision has to climb through so many layers of approval that it can never be timely.

So you're left with two options. Option one: produce something that looks finished but is really just duct-taped together. Option two: say clearly, up front, "this level of resource cannot meet this expectation." The second one is much harder to say out loud — but the first one is a straight shot to wasted work.

The fix: the moment you get the task, ask yourself, "What do I actually need to pull this off?" And if the resources and the goal don't line up, raise it before you start — not halfway through when you're already underwater.

Cause number five: no feedback loop. Some tasks you deliver, and then... silence. No "looks great," no "this doesn't work," no "here's how we're using it." For you, that drains the whole thing of meaning. But it's worse than that — for the organization, it kills any chance to learn. Which means the exact same wasted-work pattern shows right back up three months later.

The fix here is to be proactive. After you finish, follow up on how your output actually got used. And this isn't just for your own peace of mind — it's about building a feedback loop. Was this useful? Which parts landed? Which parts didn't? That information is what makes your next piece of work actually point in the right direction.

Now, if you zoom out, you can picture these five as a kind of gauntlet a task has to run. A task starts. Is the goal clear? If no — high risk right away. If yes, next gate: is there a named decision-maker? No? High risk. Yes? Keep going: are there acceptance criteria? Then, are the resources sufficient? And finally, is there a feedback mechanism? Miss any one of those gates, and the task is architecturally set up to fail — you'll finish it, and only then discover it was wasted. Clear all five, and you get work that actually has impact.

And that's really the whole point. Sucker tasks are so hard to dodge because at the beginning they look identical to real work. Same meetings, same output requirements, same time investment. The difference is invisible — it's structural.

So let me leave you with the three things to hold onto.

First: wasted work isn't random and it isn't your fault. It comes from five specific structural gaps — unclear goals, no decision-maker, no acceptance criteria, not enough resources, and no feedback loop.

Second: the fix is never to work harder. It's to ask the right questions before you start. Most sucker tasks can be spotted in the first thirty minutes of getting the assignment — if you know what to look for.

And third: this is a shared responsibility. Spotting these causes isn't about pointing fingers and saying "well, that's the manager's problem." It's about giving yourself the power to see a dead end coming — before you drive into it.

🇹🇼 中文

有位聽眾 Han Yi 寫信到大人的 Small Talk。他是個五年資歷的軟體工程師，即將調任美國，想趁離開前把這幾年犯過的錯做個總結。他發現最拖累工作效率的，是一種他叫做「冤大頭工作」的東西——就是那些你投入大量時間精力、最後卻不被承認、甚至直接被取消的工作。有些是他自己主動想做的，有些是主管交辦、卻被更上層否決的。比如開發一個新功能，結果客戶根本不買單；或是提出後台架構調整，結果效能提升遠不如預期。

他真正卡住的，是那種「風險不低、但潛在價值很高」的事情。他公司有一套保護機制：新嘗試要先提案、審批、拆解任務才能動工，目的是讓失敗的責任不會全壓在個人身上。但這套流程有個副作用——很多有機會的事情，反而更慢才知道到底行不行。他舉了個例子：一位同事提的效能改善計畫，原本預期能提升五成，結果在一年多的審查跟挑戰過程裡，很多小優化陸續上線了，等這個計畫真正落地時，只剩下兩成。計畫沒失敗，但價值就這樣被時間稀釋掉了。

Han Yi 的問題其實是一串：直覺判斷怎麼養成？怎麼在風險還沒被完全量化前，就做出大致正確的決策？還有，怎麼建立那種「老闆不用我鉅細靡遺解釋、就願意信任我」的能力？他甚至有個預感——在 AI 普及、風險可以被大量自動化消除的時代，人類真正的價值，可能就在於這種提前判斷方向對不對的能力。

Joe 的回答，從一個提醒開始：不要把白工籠統地歸成「我運氣不好」或「老闆反覆無常」。你如果想在職涯上更進一步，就要學會把失敗拆得更細。

那要怎麼拆？依 Joe 多年的觀察，一個任務會變成冤大頭——努力半天卻被取消或失敗——通常不外乎五個原因。而關鍵是，這五個原因的解法完全不一樣。

第一個，技術問題。簡單講就是技術不到位。你以為某個功能能輕鬆做出來，搞了一個月才發現跟想像差很多，做不出來、或做出來效能很爛。Han Yi 講的後台架構改造、效能不如預期，很可能就屬於這一類。這沒有捷徑，就是回歸基本面把技術練上去。但更重要的方向是「不要貪心」——如果你判斷自己現在只有五十分的能力，硬去接一個九十分難度的任務，變成冤大頭的機率當然高。稍微跳高一點點，五十分的能力去挑六十分的任務，這是進步的動力；但落差太大的時候，關鍵是對自己坦誠，承認實力不夠、然後積極補強。

第二個，市場問題。技術上你做得出來，而且做得很棒，但推出去之後沒人要用；或者你以為大家會搶著買，結果發現是超級小眾的需求。這就是 Han Yi 信裡寫的「客戶不買單」。這邊他有個困擾：為了評估風險，老闆期待先做一個 MVP，而這個 MVP 可能就花掉七成的時間。Joe 的建議是——如果 MVP 真的要花掉七成時間，那它可能根本還不夠「最小」，你很可能不自覺地又把它做得離完美更近了一點。如果真的沒辦法簡化、非投這麼多成本不可，那就反過來確認：這個專案的預期價值夠不夠高？如果潛在回報巨大，那七成成本就是一個合理的賭注，就算輸了也不算冤大頭，因為贏了能大贏。但關鍵還是退一步想：怎麼用最低的成本去測試市場。Joe 舉 Dropbox 當例子——它不是先把產品開發完才拿去賣，而是在有點子的當下就做了一個網站、開始招募等候名單，確認真的有需求，才開始正式開發。

第三個，管理問題。技術到位、市場也有，但專案執行一塌糊塗：進度延遲、團隊吵架、資源沒到位、外包跑掉，整個專案被拖垮，最後靠一兩個大神勉強上線。

第四個，需求問題。老闆一開始需求講得很含糊，比如「我要一個風格大氣的頁面」。PM 或工程師其實沒聽懂，又不敢問、不知道怎麼問，或者以為自己聽懂了，就悶著頭做。搞了一兩個月東西端出來，老闆臉一沉說「這不是我要的」，整組打掉重來。

第五個，政治問題。A 部門想做、B 部門極力反對、C 部門有成本考量、D 部門希望趕快上線。你夾在中間，每個都做一半，最後因為部門高層的角力，專案走成一個奇怪的樣子，甚至直接被犧牲掉。

好，五個原因講完了，但 Joe 特別強調一件事：依他的觀察，職場裡搞不好有八成的冤大頭工作，不是死在技術，也不是死在市場，而是死在後面三項——管理、需求、政治。

很多工程師因為職能的關係，會非常專注在解決技術問題。這是好事，但也導致他們一碰到管理、需求、政治問題，就覺得「那超出我的控制範圍」，於是歸咎於運氣、歸咎於老闆。可是這三項其實都能解決、也該解決，因為公司一旦變大，它們一定會出現。而解決的核心能力，廣義來說就是專案管理。這也是為什麼大人學一直鼓勵技術人員——不管你最後會不會掛上 PM 的頭銜——都要去點專案管理這個技能樹。它是避免自己變成冤大頭最強的一面盾牌。

一個懂專案管理的人，在老闆丟出模糊需求的時候，不會急著動手寫 code，而是先做需求訪談；而且訪談也不是直接問「你要什麼」，是用特定的溝通方法去確認老闆真正的意圖。懂利害關係人管理的人，在專案啟動前會先看看這案子可能踩到誰的線、誰會反對、誰會支持，先去疏通、合縱連橫。當這五個潛在失敗原因，你能主動控制其中四個——技術 OK、管理擅長、需求談清楚、政治先擺平——只剩市場比較難控制，成功率自然就高了。

那回到 Han Yi 問的「直覺怎麼培養」。Joe 的答案是：你能解決的問題種類越多、碰過的越多，直覺就越準。他舉了一個投手的報導——當投球次數超過某個很大的量之後，球一出手、還沒進手套，投手在那一瞬間就知道會不會進好球帶、會不會被打出去。這就是直覺。但直覺不是魔法，從理性角度看，它就是大量經驗的內化。就像談戀愛，第一次交往，看對方傳個貼圖能猜半天；交往經驗多了，光是對方回訊息的速度快慢，你馬上就能捕捉到訊號。那些資深前輩看起來「不用做實驗就知道方向對不對」，是因為他們已經看過十個、一百個類似專案死掉的樣子。所以方法沒有捷徑：把工作當成練功。踩了坑是經驗，避開坑也是經驗；不管是成功的專案，還是失敗的冤大頭，都是很好的教材。

具體怎麼做？下一個任務來的時候，強迫自己跳出工程師視角，去掃描那五個維度：技術上有沒有坑？做出來誰會買單？這任務誰負責、資源夠不夠、時程合不合理？老闆到底要什麼、他背後想解決的目的是什麼？誰會不高興、誰是潛在阻力、我要怎麼合縱連橫？你能想得越周全，就越看得見漏洞在哪。「大致正確」不是靠猜的，是靠全面的掃描、靠經驗跟知識堆出來的。

Han Yi 還問了一題：怎麼建立那種讓老闆不必聽你鉅細靡遺解釋、就願意信任你的能力？很多專業人士有個誤區，以為要「證明自己很厲害」老闆才會信任，於是簡報塞滿數據、架構圖、程式碼，想展現自己多辛苦多嚴謹。但 Joe 點破了——老闆很可能看不懂，也不想看那麼細。老闆之所以要你做繁瑣報告、設一堆審查流程，只有一個原因：他不安心。他不確定把事情交給你會不會搞砸、會不會讓他賠錢、會不會讓他沒辦法對上面交代，只能用控制手段來減緩焦慮。

所以獲取信任的關鍵，不是展現你技術多高超，而是讓老闆覺得「你不但能搞定技術，還能搞定意外」。而意外，正是來自市場、管理、政治、需求那幾個面向。當老闆發現你拿到需求不是埋頭就做，而是會反問問題——他從你的提問就能判斷你的程度、確認彼此有沒有對焦；當他發現你會主動控制進度、會預先想到別的部門會不會吵架，他就不用一直盯著你了。因為你跟他在同一條路線上，他有了可控感，自然願意放手，把最大的信任交給你。說穿了，專案管理就是在建立一套「可預期性」的技術。這東西一旦有了，判斷會更精準、專案推進會更順、人和會提升，連老闆的安心感都會增加。

最後 Joe 對 Han Yi 的提醒，也呼應了他信尾那個預感：未來 AI 會讓寫 code 越來越快、產出越來越容易，到那個時代，最有價值的——以 2026 年第一季來看——還是能定義問題、整合資源、看懂局的人：能判斷現在該不該做、該怎麼做才不會死在半途，以及怎麼讓專案順利落地。

所以不要怕做錯，但記得三件事。第一，冤大頭工作有五個死因——技術、市場、管理、需求、政治，而且大部分白工不是死在技術，是死在後面那三個，別再全推給運氣。第二，直覺沒有捷徑，它是大量經驗的內化，每次任務都強迫自己用五個維度掃一遍，看得越周全，判斷就越準。第三，老闆的信任不是靠證明你多厲害，而是讓他相信你連意外都搞得定——當你不只用工程師的腦袋、還會用專案經理跟老闆的腦袋去復盤，那道職場上的信賴高牆，其實沒有想像中那麼難跨越。

Tags

#workplace#productivity#communication#career#management#adult-small-talk

Related Articles