Bullsh*t Jobs

I wrapped up my backlog last Tuesday by noon and spent the next hour rearranging sticky notes just so it wouldn’t look like I was free, though it didn't fully fix things. That little charade reminded me of a bigger one we all play — the “bullshit job.” Graeber popularised the term, but the feeling predates his book by decades: automation was supposed to drop us to 15-hour weeks, yet here we are, still clocking forty. (I could be wrong, but it sometimes feels as if society quietly decided that idleness is scarier than inefficiency.)

Some economists even argue that busy-work is engineered on purpose — a modern substitute for the WPA and other make-work programs that kept unemployment figures palatable in the last century. I’m not entirely sure that explains every status-update meeting, but it does explain why nobody pulls the plug when projects limp along for years.

a form of paid employment that is so completely pointless, unnecessary, or pernicious that even the employee cannot justify its existence even though, as part of the conditions of employment, the employee feels obliged to pretend that this is not the case.

The Book Bullshit Jobs

Graeber floated the claim that roughly half of modern jobs fit that definition. Important caveat (he mentions it, critics highlight it): the number comes from an online survey, not a double-blind longitudinal study. Still, the sheer number of people who clicked “my work feels pointless” should make any manager sweat a little.

Retail and hospitality give the cleanest example. If you can lean against a wall, the reasoning goes, you can refold the same t-shirts again. Appearance trumps outcome. Endless refolding, polishing already polished cutlery, or pacing the floor so the security camera shows “activity” — classic busy-work. Swap t-shirts for PowerPoint decks or CSV re-formats and you have half the corporate world.

The software industry isn’t immune. I’ve written about the promotion loop before — kickoff → release → title bump → bail. Products born only to tick CV boxes naturally breed bullshit tasks: weekly status PDFs nobody reads, dashboards that look impressive in quarterly reviews but never reach a user. I got this wrong for the first few years of my career; I genuinely believed every green light in JIRA equalled value shipped.

The rigid culture

Enter the “rigid” culture — process worship at the altar of predictability. Deviate from the dotted line and the KPI gods get angry. I’ve seen companies hire a small army of agile coaches, plaster the walls with burndown charts, and still ship less than two developers hacking over a weekend. (Side note: I’m not anti-Scrum; I’m anti-Scrum-as-scripture.)

• New hire joins mid-sprint? Park them on Confluence till Monday.
• Story done early? “Support your teammates” — which often translates to refreshing Slack until a blocker appears.
• No blockers? Great, daily stand-up anyway — managers need their audible heartbeat.
• Vision unclear? Summon a 15-person, 2-hour Zoom so everyone can “align.”

Critics (myself included) point to the ballooning admin layer — project coordinators of coordinators. Defenders argue those roles absorb real complexity so engineers can stay heads-down. I’m torn: I’ve seen one stellar TPM save a release and, on another team, three BAs spend weeks colour-coding a roadmap nobody used. Your mileage may vary.

Either way, when process eclipses outcome, meta-work crowds out actual work. The best teams I’ve seen rip Scrum for parts — keep retros, ditch planning poker, whatever fits — and measure themselves on shipped value, not ritual purity.

Zombie Projects

Then we have zombie projects: budgets without pulses. Somewhere in finance a cost centre keeps them technically alive, so no leader has to sign the death certificate. Over-hiring plus under-demand equals invisible idleness.

Large organisations lose track of these undead initiatives. Strategy decks change, managers rotate, yet the repo lingers. Fear of failure glues it all together — nobody wants “project cancellation” on their performance review. I’m sympathetic; killing work feels like admitting you wasted money. But dragging the husk on for quarters just piles good money on top of sunk.

Some developers don’t mind the arrangement: stable pay, no deadlines, plenty of time to port the codebase from Python to Rust “for learning purposes.” That comfort can last years inside a 10,000-person org. Just don’t ask about business impact.

Doomed bloatedness

I stumbled on the HN post below and winced because I’ve lived the lighter version of it.

One of my recent tasks at the investment bank was to analyze what a couple of software code templates provided by Microsoft could be used for… I completed my part in a few minutes and pretended it took much longer.

source

Estimation poker becomes a defensive sport: underestimate and you shoot yourself in the foot; overestimate and you end up Netflix-scrolling on the second monitor. In healthy startups, finishing early means grabbing the next ticket. In bloated orgs, it means risking the question “Why did you finish so fast?” — so tasks mysteriously expand.

The rot spreads when veterans learn that throttling output protects their equilibrium. New joiners try to sprint, get told “slow down, cowboy,” and either leave or conform. If most of the floor is idling at 50 % capacity, run — culture change from below is a myth.

Doomed projects

Multi-year waterfall endeavours deserve their own horror genre. Specs dribble in, Gantt charts get redrawn, teams churn, tech stacks age out before launch. I’ve twice watched a “next-gen platform” burn through millions only for someone, years later, to whisper the obvious: “we should probably start over.” By then the sunk-cost fallacy has a mortgage and two kids.

I had recently started a job where my new employer had been working with a contractor on their “next-gen” web application for four years, and it was nowhere near production ready… Fast forward two years and it’s still not production ready.

source

Few things sting like seeing your code live only in staging. The emotional tax compounds when the direction keeps shifting and your previous month’s work gets refactored out of existence. I don’t have a neat fix — sometimes the only rational move is to abandon ship before the rewrite of the rewrite starts.

Building the next big thing

Hype waves create bullshit jobs at startup speed. A shiny buzzword lands, budgets materialise overnight, and suddenly every internal tool needs GPT-4-powered sprinkled on top. Replace GPT with Hadoop, Blockchain, or Web3; the template is evergreen.

I’ve been on those strike teams. Great for leveling up: you prototype, you learn, you get to brag about bleeding-edge tech at meetups. But if the POC never graduates, the glow fades. Endless demo decks, half-baked integrations, and dataset re-formats no one will query — that’s the mundane side of hype.

This cart-before-horse approach makes companies overstaff teams to build unnecessary products… task bloating season started.

source

I won’t pretend I have a silver bullet. Some speculative bets do pay off, and hindsight bias makes the failures look obvious. Just remember: sexy tech plus no real user need still equals shelfware.

Conclusion

We keep filling forty-hour weeks, whether the work matters or not. That pressure spawns PowerPoints nobody opens, Jira stories nobody needs, and entire jobs that boil down to formatting datasets that never reach production. I don’t think we can eradicate pointless work — some of it is a social buffer against unemployment — but we can surface it and, case by case, decide if the masquerade is worth the salary.

Small fixes help: ruthless backlog pruning, public goals tied to user value, and permission to kill projects early. Not every role has to change the world, yet every role should at least make sense to the person doing it.

Other Newsletter Issues:

• Contracts you should never sign
• ⛓ Implementing Atomic Habits in IT
• Software Development is very subjective