Last month one of our developers shipped a feature at 11pm on a Thursday. Unprompted. Nobody asked. It was a crunch period, the deadline was real, and they wanted to get it done. I thanked them and then told them to take Friday off. Not as a reward. As a correction. Because if we normalise 11pm Thursdays, we'll lose the thing that makes this team work.
The Stretch Problem
Enterprise delivery is intense. Deadlines are real. Client expectations are high. The work is complex enough that you can't just clock in and clock out. Problems follow you home. You're thinking about the data migration in the shower. You're debugging in your head at dinner.
Every enterprise team I know operates in a state of low-grade stretch most of the time. The workload is slightly more than comfortable but not quite unbearable. People absorb it because they're professionals. They care about the work. They don't want to let the team down.
The problem with stretch is that it doesn't announce itself as a crisis. It's a slow compression. People get a little more tired. A little less creative. A little more likely to take a shortcut. The code quality drops subtly. The communication gets shorter. The tolerance for ambiguity decreases.
And then someone burns out, and everyone acts surprised.
61%
of NZ workers report feeling burned out at work at least sometimes
Source: NZ Workplace Wellbeing Survey, Southern Cross / BusinessNZ, 2018
What We've Tried
We've tried the things every tech company tries. Flexible hours. Remote work days. Team lunches. These aren't bad. But they're surface-level interventions for a structural problem. The structure of enterprise delivery produces sustained cognitive load. You can't offset that with pizza.
What's worked for us is addressing the structure itself. Not the perks around it.
Meeting Breaks
No back-to-back meetings. Every meeting ends ten minutes early. This sounds trivial. It isn't. When someone goes from a client call to a sprint review to a design critique without pause, they arrive at the design critique running on fumes. The quality of their input degrades with each session.
The ten-minute gap does three things. It lets people process what they just discussed. It gives them time to switch context. And it provides a buffer when meetings run over, which they always do.
We lost roughly forty-five minutes of meeting time per person per week. We gained noticeably better decision-making in every meeting after the first.
Energy Accounting
We started paying attention to the energy profile of each week, not just the hours.
A week with two client presentations, a major deployment, and a complex design review is a high-energy week. Even if the hours are normal, the cognitive load is elevated. The week after should be lighter. Not artificially light. Just not stacked with another set of high-intensity commitments.
This requires awareness and planning. It means the person scheduling the work understands that delivery capacity isn't a flat line. Some weeks you can push. Some weeks you need to recover. Ignoring that cycle doesn't make it go away. It just means the crash comes unplanned.
We track hours because clients need to know where their budget goes. You have to pay attention to the person.
Isaac Rolfe
Managing Director
Workload Transparency
Nobody at RIVER should be silently drowning. We've built a culture where saying "I'm at capacity" isn't a weakness. It's information. The team lead needs that information to make good decisions about who picks up the next task.
This took time to build. Developers, especially good ones, have a default setting of "I'll figure it out." Overriding that default requires consistent signals that honesty about capacity is valued more than heroics.
When someone says they're stretched, the response is redistribution, not encouragement. We don't say "push through." We say "what can we move?"
No-Crunch Default
Crunch happens in enterprise delivery. Real deadlines. Production issues. Client emergencies. We don't pretend otherwise.
But crunch is the exception, explicitly acknowledged and explicitly recovered from. When someone works a weekend to hit a deadline, the expectation is that they take time back. Not as a favour. As a standard operating procedure. The books balance.
What we won't tolerate is sustained crunch. The project that's been in crunch mode for three weeks isn't a dedicated team. It's a planning failure. And the fix is in the plan, not in the team's capacity to absorb more.
Why This Matters for Delivery
Some people read this and think "that's nice for culture, but does it help you deliver?" Yes. Directly.
Rested developers write better code. They catch edge cases. They ask better questions in reviews. They push back on requirements that don't make sense instead of just building whatever's in the ticket.
Rested designers produce more creative solutions. They don't default to the safe option because they're too tired to explore alternatives.
Rested project leads have harder conversations earlier. They flag risk before it becomes a crisis. They push back on unrealistic timelines before the team has committed to them.
The relationship between team energy and delivery quality isn't a nice-to-have insight. It's the most operationally significant variable we've found. More than technology choice, more than methodology, more than individual talent. A well-rested, well-supported team with average skills outperforms a burned-out team of stars every time.
What We Haven't Figured Out
We haven't solved this. We're still learning.
We still have periods where the workload gets ahead of us. We still have people who don't speak up when they're stretched because they haven't fully internalised that it's safe to do so. We still sometimes schedule heavy weeks back to back because the client timeline demands it.
But the awareness is there. The structures are improving. And the conviction is clear: protecting the team's energy isn't a cost of doing business. It's an investment in the quality of everything we deliver.
I'd rather deliver slightly slower and deliver well than burn through people to hit an arbitrary timeline. Eight years of enterprise delivery has taught me that the fast path and the sustainable path are usually the same path. You just can't see it when you're too tired.