Sustainable pace beats heroics: best practices explained

Sustainable pace beats heroics

I've watched good engineers burn out. Not because they weren't capable, but because somewhere along the way, we normalized the 60-hour week as a badge of honor. The truth is brutal: sustained heroics are a delivery risk, not a solution. When I look back at projects that shipped reliably, the common thread wasn't the all-nighters—it was the teams that protected their time, planned ahead, and treated rest as non-negotiable.

Long hours hide planning problems

Here's what I've learned the hard way: long hours are often a symptom, not the cure. When a team consistently works overtime, it usually means the planning phase failed somewhere. We underestimated scope, we didn't push back on unrealistic timelines, or we kept adding features mid-sprint because stakeholders weren't aligned upfront.

I remember a ride-hailing platform we built where the backend team was regularly staying until 10 PM. We thought it was normal scaling work. Then a new tech lead joined and asked a simple question: "Why are we rebuilding the same payment logic every sprint?" Turns out, requirements kept changing because the product team hadn't thought through edge cases. We spent a week clarifying the spec with stakeholders instead of coding. After that? The team left by 6 PM most days.

The pattern repeats across projects. When I see teams grinding, I start asking:

• Did we size this story properly, or are we discovering complexity during execution?
• Are we blocked waiting for decisions from product or design?
• Is the codebase so messy that simple changes take hours?
• Did we commit to too much for the sprint?

Long hours expose gaps in planning. The sustainable fix isn't to work harder—it's to plan better. That means saying "no" to scope. That means shipping less, more often. That means a tech lead pushing back on dates before the sprint even starts, not during it.

Protect evenings and weekends by default

I treat evenings and weekends as defaults to defend, not exceptions to earn. If you've built this habit, you start making better decisions during work hours because you know you won't have extra time to catch up later.

This isn't about being selfish. It's about sustainable delivery. A brain that rested for 48 hours writes better code, catches more bugs in review, and spots architectural problems earlier. A brain that's been coding for 12 straight hours? It's probably introducing the bugs it should be catching.

I've implemented a few practices that work:

• Block your calendar. If you finish at 6 PM, mark yourself unavailable after 6 PM. Yes, really. It's not flaky—it's professional.
• Use async communication by default. A Slack message at 7 PM doesn't need a 7 PM response. Slack is not a live chat protocol. Set status as "away" and mean it.
• Batch critical decisions before the end of the day. If something needs alignment, get it done by 5 PM so engineering isn't blocked at 8 PM trying to figure out the approach.
• Deploy differently. Don't deploy at 5:59 PM. Deploys happen during business hours, or they happen with explicit on-call coverage, not panic.

The first time you leave a fire for someone else on-call to handle, you feel guilty. The second time, you realize the fire usually doesn't need a senior engineer—it needs a process that prevents the fire. That's the shift.

I once worked with a SaaS team in Colombo that made a hard call: no deployments after 4 PM unless it was a production incident. For the first two weeks, the backlog piled up. Then something interesting happened. The team started planning better. They bundled features. They did more thorough testing before the cutoff. Bugs that used to get fixed via late-night patch went away because they caught them earlier. And yes, the 4 PM cutoff stuck.

Celebrate prevention, not firefighting

This is where company culture either enables burnout or prevents it. If your heroes are the people who fix things at 2 AM, you're celebrating the symptom, not the cure. You're rewarding the people who let problems fester.

Real heroes prevent the fire. They write tests. They push for code review. They notice technical debt and make the business case to pay it down. They say "this architecture won't scale" before it collapses. These engineers rarely get mentioned in standup because nothing dramatic happened.

I've seen two different reward systems. One company celebrated the engineer who stayed up all night to restore a database. Another celebrated the engineer who implemented the backup strategy that meant the restore took 10 minutes instead of becoming a crisis. Only one of those teams stayed intact after 18 months.

As a tech lead, this is your job: make prevention visible. In retros, call out the things that almost went wrong but didn't. When someone flags a risky dependency, thank them in front of the team. When QA catches a bug that would have hit production, mention it. Ship retrospectives that talk about what we did right, not just what broke.

And when someone does get paged for an incident? Don't praise the person who fixed it. Praise the person who designs the postmortem to make sure it doesn't happen again. That's the career you want to build.

Rest is part of the job

I'll say this clearly: rest is not laziness. Rest is recovery. Rest is when your brain processes complexity and finds better solutions. Rest is when you're not in code-reading mode and you can actually think about architecture.

Some of my best decisions came after I stopped thinking about the problem. I'd leave the office frustrated that I couldn't solve a concurrency bug. Next morning, I'd be in traffic and suddenly see the issue. That's not magic—it's sleep letting your brain work on the background task.

Protect this fiercely. If your company or team pressures you to skip vacation, that's a red flag. If your on-call rotation doesn't include real rest days (days where you're truly unreachable), that's broken. If you feel guilty taking a sick day, the culture is toxic.

I schedule my leave months ahead because I know I'll try to skip it otherwise. I put my phone down on weekends. I don't check Slack Sunday evenings. These aren't character flaws—they're boundaries that keep me effective for the 40-50 hours I do work.

The best time to take a vacation is when you think you can't afford to. That's when the team is usually carrying too much, and your absence will expose it.

Common mistakes

• Glorifying the grind. "I shipped this in one weekend" is not the flex you think it is. It usually means your planning failed. Don't build a career on exceptions.
• Treating time off as guilt. You don't need to work extra hours before or after vacation to earn the break. PTO is part of your compensation. Use it.
• Letting urgent override important. Just because something is blocking someone doesn't mean you drop everything at 5:47 PM. Can it wait until 9 AM? Almost always yes. Escalate the decision, don't solve it heroically.
• Accepting "we're just busy right now" as permanent. If you've been "busy" for 6 months, you're not busy—you're understaffed or poorly planned. Those are different problems that need different solutions.
• Rewarding individuals over systems. Don't promote the person who worked weekends. Promote the person who built a system that prevented weekends from being necessary.

Key takeaways

• Long hours aren't a solution—they're a symptom of planning gaps. Fix the plan instead.
• Protect off-work time as a default. You make better decisions and write better code when rested.
• Celebrate prevention over firefighting. The real heroes are the ones who stop problems before they happen.
• Rest is recovery. It's when your brain solves hard problems and builds better systems.
• Sustainable pace compounds. A team that ships at 80% capacity consistently beats a team that alternates between 150% and 0%.