The 'Sustainable Pacing' Trap: Why Engineers Push Back (and How to Navigate It)

Ah, sustainable pacing. A phrase that sounds like something you'd find on a wellness retreat brochure, not in the trenches of software engineering. But here we are – or should be. You might have read my stuff before about work-life boundaries and burnout math; those concepts often tie directly back into how we manage our pace at work.

The thing is, engineers (and developers, product managers, designers... let's be honest, most tech folks) get a certain vibe from the word "sustainable." It sounds like compromise. Like maybe cutting corners or accepting less ambitious outcomes. And that’s understandable; after years of being told to just document everything when you were once knee-deep in code refactoring, it can feel insulting.

Sustainable pacing isn't about slowing down just for fun – no way. It's about finding a pace that allows consistent, high-quality output without burning people out and crashing the whole system (metaphorically speaking). Think of it as not starving yourself during a marathon; you need fuel along the way to keep running strong.

But why does this idea feel counterintuitive? Why do smart engineers often push back when sustainable pacing is suggested?

Why Sustainable Pacing Feels Counterintuitive for Engineers

It's ingrained culture. Tech work, especially in startups or high-pressure environments, thrives on intensity. The "crunch" mentality isn't just a phase; it can become the default operating rhythm.

Remember being an engineer? You lived for solving complex problems late at night. There was pride in finishing that tricky feature marathon-style. This culture persists even when scaled up – think about the "grind," where everyone pulls slightly harder, maybe into weekends or evenings.

This isn't just about putting in long hours; it's deeply tied to perceived progress and output:

• The Illusion of Productivity: Long hours feel productive. Seeing lines of code committed late at night provides tangible feedback (often illusory). Sustainable pace relies on different metrics – velocity over time, predictability, quality.

• Fear of Stagnation: Engineers are intellectually curious and driven. Slowing down can feel like regressing, like you're not demanding enough, or that the team isn't capable of faster delivery under pressure.

This is where my slightly-less-than-objective view kicks in: I was an engineer who thrived on intensity for a while myself. We all have these ingrained habits from our past roles. The key shift for managers is understanding that sustainable pace doesn't mean less ambition, but often means more predictable and higher-quality results over the long haul.

The Burnout Math Revisited: What Happens When We Don't Set Boundaries?

Okay, let's revisit the burnout math, because this is where sustainable pacing really becomes urgent. I've written about it before – think of it like a bank account for energy reserves.

Every engineer starts with a certain amount of daily or weekly "energy" to spend on work. This isn't just physical energy; it includes cognitive (brain cycles), emotional (resilience to stress), social (team interaction without fatigue), and even creative energy.

Work tasks drain this pool:

• Cognitive Drain: Deep focus, debugging complex systems, learning new technologies.

• Emotional Labor: Handling stressful situations, firefighting bugs that break user trust, dealing with ambiguity in requirements.

• Social Drain: Meetings (especially endless ones), collaboration, communication overhead.

When we don't set boundaries – when engineers are pulled into pajecka curves (those relentless high-intensity cycles) or simply asked to work longer hours indefinitely without recovery – their energy account goes negative. Fast.

This isn't linear; it's exponential decay in disguise. The initial burn is the price you pay for unsustainable intensity, but what happens after?

1. Initial Output: You get a burst of productivity from exhausted engineers.

2. Diminishing Returns: As they become fatigued and overwhelmed, their output per hour decreases significantly. Context switching increases dramatically due to fatigue – that's the hidden cost.

3. Increased Error Rate: Tired brains are slower and more error-prone. Brain fog sets in. Typos happen; logic errors creep in under pressure.

4. Collateral Damage: Burnout isn't just individual. An overwhelmed engineer creates bottlenecks, slows down teammates (who might now feel the need to help), increases handoff friction, and reduces overall team velocity.

This is unsustainable because it leads to a downward spiral: harder problems -> more fatigue -> lower output -> even more pressure on fewer people. It's like constantly trying to sprint uphill with worn-out shoes – eventually, everyone collapses or quits, taking valuable institutional knowledge (and vacation time) with them.

Approach 1: The Directive Manager (Spoiler: It Doesn't Work Well)

This is the classic command-and-control approach: "You engineers will now work a sustainable pace." Or perhaps setting unrealistic expectations that lead to burnout anyway. Think of it as trying to change team velocity by decree alone – it rarely works.

The problem with this approach isn't just that it feels demoralizing (which it absolutely does). It's fundamentally flawed because:

• It Dismisses Expertise: Engineers are smart people, and they know how to pace themselves. Or do they? Often, their understanding of sustainable pace is filtered through the lens of past unsustainable demands.

• Lack Buy-in: Mandating a change without explaining it or involving those affected creates resentment. It feels like micromanagement dressed up in buzzwords.

The directive manager often fails because engineers feel infantilized. They're professionals capable of self-regulation, given proper conditions and support. Telling them directly how to pace their work bypasses the crucial step of understanding why a change is needed – which is usually about protecting quality or preventing exhaustion for everyone involved.

This approach can backfire spectacularly: engineers might comply initially out of fear but will likely rebel eventually when they feel management has overstepped. Or, worse yet, they'll just quietly work at an unsustainable pace anyway because that's the default expectation in their environment.

Approach 2: Leading by Example (Hint: It's More Effective)

This is a core concept for Samir Haddad types – leading with your own behavior sets powerful norms. Forget telling; show them what sustainable pacing looks like from the top down.

I used to think this was just "soft skills." Now I see it as fundamental operational strategy. Your actions speak way louder than your words, especially when you're talking about something perceived as 'weak.'

What does leading by example in sustainable pacing mean?

• Define and Communicate Boundaries: If you need deep work time to complete complex tasks without interruption, schedule those blocks visibly on your calendar (calendar 😉) and enforce them. Don't be the person who promises 90 minutes of uninterrupted focus but then is pulled into a dozen meetings because someone above didn't plan properly.

• Prioritize Your Own Well-being: This might sound like hypocrisy, but let's break it down: Sustainable pacing isn't just about engineers; it applies to everyone involved in getting the work done. If you're perpetually burnt out or visibly stressed during off-hours (like a team meeting), your message is contradictory.

• Model Deep Work: Engineers need uninterrupted focus time for their best work. Protecting that means resisting the urge to schedule trivial meetings just because someone has free cycles.

Crucially, leading by example isn't about being perfectly sustainable all the time – nobody is wired that way without proper structure and support. It's about demonstrating commitment to long-term health while still demanding high standards.

When I was a manager, my most effective "sustainable pace" modeling involved saying no strategically to non-essential requests outside my core focus hours (which were deliberately set back). This wasn't just for myself; it sent the message that protecting capacity is prioritized. People started respecting those boundaries because they saw I respected mine.

Meeting Hygiene Makeover: How to Structure Meetings Around Sustainable Pace

Meetings are often the biggest energy drain in software engineering. We need them, no question. But we keep scheduling them like it's 1970 – think of endless status updates or context-switching sync-ups that kill momentum and drain batteries.

A sustainable pace meeting strategy is about minimizing friction while maximizing value (information transfer). Here’s how to structure your meetings:

• Define Purpose Upfront: Every meeting should have a clear, measurable objective. If you can't state it quickly ("We need X specific information from Y team member by Z date"), then maybe it's not necessary or needs restructuring immediately.

• Limit Frequency and Duration: Default to asynchronous communication unless the topic demands synchronous discussion. Keep meetings short – under 60 minutes if possible, aiming for true "standup" length (15-20). Avoid anything resembling a town hall without a clear agenda and facilitator. Structure your meeting calendar like you would code: minimize overhead.

• Ensure Value: Before sending invites, ask yourself rigorously: Is this meeting necessary? Can it be an email or a Slack message? Does everyone truly need to attend (or is it just for show)? If unsure about attendance value, schedule it later with clearer goals. Make sure the output of each meeting directly contributes to team progress.

• Respect Off-Peak Times: Schedule critical sync-ups during times when most people are likely fresh – perhaps mid-week rather than late Friday afternoon.

This isn't just being polite; it's a matter of efficiency mathematics. Meetings scheduled poorly or inefficiently create technical debt for everyone on the team, in terms of wasted time and energy that has to be repaid later with rushed work cycles (crunches).

Crafting Your Team Agreement on Sustainable Pacing & Wellbeing

One powerful way to codify sustainable pacing isn't through directives but by creating a shared understanding via a team agreement. This is collaborative contract management for humans.

Think of it as establishing the ground rules for how your specific unit operates, agreeing on standards and boundaries together rather than having them imposed top-down from HR or corporate policies alone.

Elements might include:

• Core Values: Explicitly state what matters most – quality, predictability, health, collaboration. These guide decisions about pace.

• Work Boundaries: Define the team's commitment to respecting each other's off-hours (e.g., no after-hours pings unless truly critical) and vacation time as non-negotiable buffers against burnout math.

• Definition of Sustainable Pace: What does it look like on this team? Perhaps agreeing that "sustainable pace" means being able to deliver predictable value without resorting to heroic overtime (the occasional crunch might be needed, but let's define what healthy baseline looks like).

• Feedback Mechanisms: How will the team surface concerns about pace? Regularly scheduled feedback sessions or a clear channel for raising issues non-verbosely?

Crucially, this agreement must be regularly reviewed and updated. As projects change, tech stacks evolve, and team maturity increases, so do our needs regarding pacing.

The Crucial Conversation Script: Asking for Feedback on Pace Without Blame

You need to talk about pace directly with engineers if you're serious about sustainable practices – but how? This is where the art of coaching comes in handy. Forget blaming or shaming; that triggers defense mechanisms and leads nowhere useful.

Instead, frame it as a shared goal:

• Opening: "Hey team, we've been talking about [mention context like recent workload changes/launches]. I want to touch base on how things are feeling – particularly around energy levels and pace. We're aiming for sustainable output here."

• Check-in: Use phrases that invite honest feedback without assuming negativity: "How's the rhythm working out for you?" or "Is there anything weighing heavily on your ability to maintain focus right now?"

• Focus on Impact: Connect pacing issues to tangible outcomes, not individual shortcomings. "I'm worried we might be setting ourselves up for a predictable crash later if we keep this unsustainable pace without proper recovery."

• Collaborative Goal Setting: Frame it as a team goal: "Let's figure out together what adjustments are needed so everyone can contribute effectively while feeling reasonably okay about their long-term workload."

This approach acknowledges that sustainable pacing is collectively responsible, not just an individual discipline. It focuses on the shared objective of sustained high performance.

Key Takeaways

Here’s a quick recap to help you implement this in your own context:

• Sustainable Pacing Isn't Weakness: It's about smarter work and long-term capacity.

• Engineers Need Boundaries Too: They're professionals who need predictable conditions to perform well over time, just like everyone else. Don't treat them as exceptions if you don't value their sustainable health yourself!

• Directive Won't Work: Mandating pace changes without context or buy-in is counterproductive and demoralizing.

• Lead by Example First: Model the behavior you want to see – schedule your own focus time, protect your off-hours visibly.

• Tame Meetings Ruthlessly: Use meeting hygiene principles consistently. Think about how much energy each scheduled meeting costs versus gains.

• Build Consensus with a Team Agreement: Collaboratively define standards and boundaries around pace rather than dictating them alone.

• Frame Conversations Correctly: Ask for feedback collaboratively, focusing on shared goals and impact, not individual blame.

It’s tempting to think that sustainable pacing is just one more policy layer you need to implement. But the reality, from my time as an engineer turned manager, is much deeper. It requires a cultural shift away from the hero-worship of crunch culture towards valuing consistent effort over burnout-induced bursts. And it absolutely involves some math – not complex statistics, but simple energy accounting that guides every decision about workload and rhythm.

Good luck navigating this tricky path!