We Tripled Output and Stopped Working Weekends in the Same 90 Days

Within 90 days of my joining CoinDesk, the product and engineering team I worked with tripled its productivity, and people started going home by 5pm on Friday. Before that, they'd been working nights and weekends and still shipping almost nothing they committed to, so projects that should have taken weeks were taking nine months. Both of those changes happened in the same 90 days, and I don't think that's a coincidence. I think the second one is part of why the first one happened.

It matters right now, because a slice of the tech industry has decided the answer to a late roadmap is more hours.

The 72-hour week is back

It even has a borrowed name: 996, for 9am to 9pm, six days a week, the schedule China's tech sector made famous before its courts ruled it illegal in 2021. This year it's been showing up in American AI startups, and not quietly. The BBC quoted a job ad from Rilla, a New York AI company, warning applicants not to join "if you're not excited about… working ~70 hrs/week in person." The Pragmatic Engineer collected a run of similar examples, including Cognition's CEO describing an "extreme performance culture" where people are routinely in the office through the weekend.

I understand the pressure behind it. Money is pouring into AI, the window feels short, and every founder is afraid someone else will get there first. When I talk with people who are working more hours because of AI, though, what I mostly hear is FOMO and insecurity – a fear of falling behind – rather than a plan. And working more, faster, doesn't mean anyone exercised good judgment or did the right work.

Output stops climbing somewhere around hour 50

The best-known evidence here is old, but it's careful. Stanford economist John Pencavel went back to data on British munitions workers from the First World War, where hours varied widely, and found that output rose in step with hours up to about 49 a week. Past that point it rose more and more slowly, peaked somewhere around 63 hours, and "output at 70 hours differs little from output at 56 hours." Those extra 14 hours bought almost nothing.

That was physical work on a factory floor a century ago, so I wouldn't push the exact numbers too hard. If anything, I'd expect knowledge work to fare worse, because the thing that degrades first when you're exhausted is judgment, and judgment is most of what a product team sells. The BBC piece also cites Michigan State research that's blunter still: "an employee working 70 hours per week has almost no difference in output than an employee working 50 hours per week." And the costs don't stop at output. A WHO and ILO analysis linked weeks of 55 hours or more to 745,000 deaths from stroke and heart disease in 2016.

Even some of the investors funding these companies aren't buying it. Deedy Das of Menlo Ventures told the BBC that "the thing young founders get wrong is they view hours worked in and of itself as necessary and sufficient to think of themselves as productive. And that's where the fallacy lies."

Where the hours were actually going

The CoinDesk team wasn't lazy or untalented. Engineering was working incredibly hard and long hours and still getting blamed for things that weren't their fault. When I walked into my first sprint planning, the pattern was easy to see: tickets went into the sprint without clear requirements or acceptance criteria, engineers built what they thought was right, stakeholders rejected it, and the cycle started over. Key decisions kept getting tabled "until the next meeting." The nights and weekends were going into rework.

The single biggest leak was defects, or what everyone was calling defects. Something like 70–80% of what went into a sprint was bug work, and when I looked at it, most of it was a slight color change or a pixel alignment that no user would ever notice. Nobody else had been willing to put their foot down, so I did: "These aren't bugs and they don't matter. We're not doing them." If a fix had a real reason behind it, like mobile performance or accessibility, we bundled it with others so people weren't constantly switching between tiny tasks.

Then I became the firewall. Stakeholders could no longer go straight to engineers; they came through me, so I could get a clear definition of the work and figure out its real priority and business value before it reached the team. I limited how much work was in progress at once so engineers could focus on fewer things and do them well. None of that asked anyone to work harder. It asked them to stop working on things that didn't matter, and within 90 days output was three times the baseline and the weekend work had stopped. (I've written up the whole CoinDesk turnaround if you want the longer version.)

Long hours are a signal, not a strategy

Leaders keep asking for the hours anyway, and in my experience it's usually a signal. An executive wants to be able to tell the CEO, "we're working nights and weekends to get this done for you," and the hard hours themselves become the thing being reported upward. But the hours aren't the outcome. The outcome is a team that does good work, solves real problems for users and ships when it said it would, and an exhausted team can't be creative enough to do any of that.

I hold myself to the same math. I was working 45–50 hours a week last year and I'm down to about 40 now, on purpose, after spending this year building tools to free up time for thinking instead of grinding. Working fewer hours has made me better at the part of the job people actually pay me for, which is judgment.

There's a related trap on the staffing side. When a project is late, the other instinct is to add people, and I've watched a team grow to 60 engineers and get later. More hours and more heads are the same move, and they fail for the same reason: neither one touches whatever is actually making the work slow.

What to do instead when the roadmap is late

Before you ask anyone for a single extra hour, go find out where the current hours are going. In my experience, a late team is almost never short on effort. The hours are disappearing into a few predictable places:

• work that starts before anyone has agreed on what done looks like, so it gets built twice;
• decisions that keep getting pushed to the next meeting while people wait or guess;
• a backlog full of "bugs" nobody would ever notice, treated as urgent because somebody senior asked;
• too many things in progress at once, so everything is half-done and nothing ships.

Each of those is cheaper to fix than a weekend, and fixing them is what gives a team its weekends back. It's also slower to show up on a dashboard than everyone staying late, which is part of why the hours are so tempting. Late nights are visible. Rework mostly isn't.

Nobody on that CoinDesk team started working harder. They started working on fewer, clearer things, and their Fridays came back on their own.