Butter Scraped Over Too Much Bread

Everyone I know is tired. Not "I stayed up too late" tired. The other kind. The kind where you open your laptop on Monday and it feels like Thursday.

I keep thinking about Bilbo Baggins. Early in The Fellowship of the Ring, right before he walks out of the Shire, he tells Gandalf he feels thin and stretched, "like butter that has been scraped over too much bread."

I first read that as a kid and thought it was a funny line about breakfast. I now read it as the most accurate description of modern knowledge work ever written. Tolkien was an Oxford professor. He knew.

Growth is never enough
A lot of companies I know are growing fast. Double digits, year over year. By any sane measure, that's a great business. People write case studies about less. It still feels like we're losing.

Here's the math as it lands on a human being. Every one of us is allocated at 100%. Forty hours a week, all billable, all customer projects. No slack. No buffer. No time set aside for learning, which is a strange choice in a field that reinvents itself every six months.

Growth doesn't buy breathing room. It buys more bread. The butter stays the same size. (I have checked. The butter has not grown)

We would never do this to a server
Nobody reading dev.to would run a production database at 100% CPU and call it efficient. We'd call it an incident.

Queueing theory explains why. Take the simplest model: one server, jobs arriving at random. Queueing people call it M/M/1. In that model, the time a job spends in the system grows with 1 / (1 − utilization). At 50% busy, a job takes twice as long as the work itself. At 90%, ten times as long. At 99%, a hundred. It doesn’t grow politely. It goes vertical.

People are not M/M/1 queues. we're worse. I'm aware. I have been asked to stop saying "throughput" at dinner. But the shape holds. At 100% allocation, every surprise becomes a backlog. A sick kid. A customer escalation. A production bug at 4:55 on a Friday. There is no capacity to absorb any of it, so it gets absorbed by evenings and weekends instead.

We give our EC2 fleets headroom. We set autoscaling at 70%. We know that a system with zero spare capacity isn't efficient. It's fragile. Then we staff our teams like we've never heard of any of this.

Someone will point out that GenAI makes everything faster. More butter! I use these tools every day. They are fast. But look at the math again. Utilization is work coming in divided by work getting done. Double the speed, double the incoming work, and you’re right back at 100%. Faster servers don’t fix a queue if you just feed them faster. Economists call this the Jevons Paradox. When steam engines got more efficient, Britain didn’t burn less coal. It burned more. AI can absolutely be more butter. But if every hour it saves becomes another project, we haven’t fixed anything. We’ve just bought a bigger loaf.

Zero learning time is technical debt with a pulse
The part that bothers me most isn't the hours. It's the zero. Zero hours for learning means the only way to learn is on the customer's dime or on your own time. Neither scales. The first is risky. The second is how you get a team of people reading re:Invent announcements at 11 p.m. with one eye open.

We all understand technical debt. You skip the refactor to hit the date, and you pay interest later. Skipping learning works the same way. Except the interest compounds in people. Skills go stale. Curiosity goes quiet. The engineers who could have figured out the next big thing are too busy shipping the last one. And then, one day, a very good person updates their LinkedIn. That's the payment coming due.

More butter, or less bread
There are only two fixes. Get more butter, or spread it over less bread.
Some ideas, none of them new, all of them ignored:

Plan for 80%, not 100%. The missing 20% isn't waste. It's the headroom that absorbs surprises, so surprises don't eat people. Put learning on the schedule. Four hours a week, protected, not "whenever you find time."

Nobody finds time. Time is not under the couch.

Count recovery as capacity. A rested engineer does in one hour what a burned-out one does in three. That's not soft. That's arithmetic.
Hire ahead of the curve. If you're growing fast, staffing to last year's demand guarantees everyone is stretched this year.

Bilbo, notably, did not optimize his butter. He didn't install a better toaster or adopt a new bread framework. He left. He went to Rivendell, sat by the fire, and wrote a book. Most of us can't run off with the elves. But we can stop pretending that a team at 100% is a team at its best. It isn't. It's a team one bad week away from breaking.

If everyone you know is running on fumes too, you're not imagining it. And it's not a personal failing. It's a capacity problem. Those, at least, we know how to solve.