How Software Engineering Leaders Help Teams Sustain a Healthy Pace

Our long urgent stretch every year is the holiday season. Companies send hundreds of thousands of handwritten cards through our robots between October and December, and the team runs hot for weeks with no room for side projects. We are 11 people, so everyone feels it.

The habit that keeps motivation intact is making progress visible every single day. We post a simple count each morning of what shipped yesterday and which client it went to. Engineers rarely get to see the end customer, so tying their fixes to a real order, like a car dealer getting 5,000 thank you cards out on time, makes the grind feel meaningful instead of endless.

The second habit is protecting small wins of craft. During a crunch I still let the team pick one annoying problem per week that they want to fix for their own sanity, like a flaky script or a slow deploy step. It costs a few hours, but it gives people a sense of control when everything else is reactive.

Third, I say out loud when the crunch ends and we actually slow down. Burnout comes from urgency that never has a finish line. Naming the end date, and honoring it with real downtime in January, is what makes people willing to sprint again next year.

Keep the Vision Visible and Keep Checking In

During long stretches of urgent delivery, the thing that sustains a team isn't a perk or a one-time pep talk, but instead, it's consistent, visible leadership attention.

I make a habit of regularly reconnecting the team to the end goal and the vision behind the push, so the urgency has a clear "why" attached to it rather than just feeling like relentless pressure. People can tolerate a demanding pace for a long time if they understand what it's building toward and when it ends. What they can't tolerate is pressure that feels arbitrary or open-ended, so I make sure that context gets repeated, not just stated once at the start.

Just as important is staying genuinely tuned in to how people are actually doing, not just what they're shipping. I keep a close eye on signs of burnout, check in with people individually rather than relying only on team-wide updates, and step in to help directly when someone starts to feel stretched too thin, by reshuffling priorities, or simply giving them space to recover before it compounds.

A big part of that is removing roadblocks before they pile up. When a team is already running on a demanding schedule, every unnecessary obstacle costs more than it would during normal times. A blocked dependency, a decision waiting on sign-off, a process step that could be skipped are all costly for the team. Actively clearing that path, rather than letting people absorb the friction themselves, is one of the most direct ways I've found to protect a team's energy during a hard stretch.

None of this eliminates the difficulty of a demanding period. But it makes the difference between a team that feels driven toward something they understand and a team that feels like they're just being run into the ground.

When an engineering team is trapped in an extended delivery crunch, motivational speeches and catered lunches only breed cynicism. What engineers actually need is the restoration of autonomy over technical debt. Our leadership habit is what we call 'The 20% Tech-Debt Release Valve.' Even during our most demanding product release cycles, every fourth sprint cycle is strictly protected: zero product feature tickets allowed. The entire engineering team spends that sprint refactoring fragile legacy code, fixing flaky CI/CD test gates, and upgrading infrastructure libraries. Knowing that there is an unshakeable date on the calendar where they get to clean up the operational debt created during the crunch gives developers the confidence to push through urgent delivery windows without burning out. In sustainable engineering velocity, protecting technical hygiene is the only thing that preserves team morale over the long haul.

During this high-pressure period, I changed how we viewed recovery, which would previously be considered a reward for the team after the launch. Instead, I built recovery time into the delivery schedule.

This happened on a regular cadence of a "reset day" every third Friday, during which no development work or meetings took place. The team could take the opportunity to pay off technical debt, improve the development tools, and get some much-needed rest. In fact, I had to fend off pressure from stakeholders regarding this.

We completed the entire effort during a 14-week sprint. In a previous crunch period, 2 of 9 engineers quit within three months, and defect levels increased by 35% during the last month. However, this time around, nothing like that occurred, and defect rates were only 6% higher than normal. The product launch was completed on time, and the score of our sustainable workload pulse survey increased from 5.1 to 7.4 out of 10.

1. When a project is going to last for a long time (in our case several months), motivation depends more on trust than on enthusiasm. My engineers are working day and night to keep trading servers running for customers who can feel every millisecond of delay. I'm aware that sometimes those urgent stretches can last for days. In those days it's not that the work is hard that makes people lose motivation but rather that they stop believing that the hard part will ever end and that nobody but themselves is suffering right now. I treat my engineers more or less like clients. I try to be honest about what to expect, to explain the purpose of what they're doing and to never try to pretend that things are less challenging than they really are. I also try to make visible the "after the storm" work that the team has been flagging for me to do. Writing that down so that everyone can see it helps to remind them that their concerns have been parked, not forgotten.

2. I had a habit of taking the whole team for a short Friday meeting to ask them one question: "What drained you this week?" instead of "What did you get done this week?" Delivery status lives in the tools; this conversation is about energy. Most of the time we found one small thing to fix (e.g. a meeting that nobody needed to attend, a handoff that caused people to work late nights, someone working incredibly hard while others around them were not carrying similar burdens). I tried to fix one of those things every week and then proudly announce to everyone that I did. When the crunch finally ended we spent the first protected week going down that list of tiny things. They were trivial but we had promised the team that we would do this and so we did. It was a big part of regaining the team's faith in the leader in the subsequent long crunch.

Urgent stretches that leave only ticket closure drain motivation. Ones where people still leave the week with one visible craft win hold up better. I name the temporary trade-off out loud and guarantee a fixed weekly slot for one small improvement or cleanup. That keeps the debt backlog from feeling endless. Protecting a short non-negotiable 90-minute recovery window each week is the habit. The team picks one refactor, test, or tooling fix, treats it as delivery work, and we rotate who chooses. The slot collapses if leaders treat it as optional or reclaim it for fire drills.

Every two-week sprint during a heavy delivery stretch, I started blocking half a day that belonged entirely to my engineers. Not optional, not negotiable with stakeholders. They could use it to refactor something ugly, write a missing test, automate a manual step, or read documentation they had been meaning to get to. The only rule was it couldn't be tied to a current ticket.

What surprised me was how little pushback came from the business side once I framed it in their language. I told them this half-day was maintenance on the people writing their product, the same way you maintain the servers running it. Skipping it doesn't save time, it borrows it at a rate you can't afford.

The real change happened about six weeks in. My team stopped treating those blocks as a break and started using them to fix things that had been quietly slowing them down for months. Deploy scripts got cleaned up. Flaky tests got rewritten, and the friction underneath our delivery sprints dropped.

The leadership habit that's done the most for our pace is not letting urgency set priorities. Requests that show up outside the plan get weighed against what's committed, their cost and security impact, and the must-haves already on the roadmap, and we review pending requests against that roadmap on a regular cadence. We still handle real incidents immediately, but a looming close date doesn't bump planned work on its own.

We protect improvement work by building it into delivery. A standalone cleanup sprint competes with release deadlines and usually loses, so engineers own the call as they touch code. When someone is in a file shipping a feature and sees something that should be refactored, they fix it then. It sometimes slows a ticket down, but it keeps each piece of debt small enough to finish.

We also avoid asking engineers to task-switch constantly. Work like a migration or a complex integration needs runway, so we define a real emergency narrowly and leave people time to sink into a project.

Finally, we frontload risk reduction into the first months of every client engagement, building in self-healing infrastructure and reliability best practices, so urgent stretches are rare to begin with.

I would protect improvement work before the team reaches the point where every day becomes reactive. After a demanding delivery stretch, reserve capacity for fixing recurring friction, paying down technical debt and simplifying the workflow that caused the pressure. The leadership habit I favour is reviewing what created the urgency instead of praising people for repeatedly absorbing it. Sustainable pace comes from removing the causes of constant firefighting, not asking capable people to become better at enduring it.

The leadership habit that helped most during our hardest shipping stretch at Pigment was being honest about when it would end. Not optimistic. Honest.

Engineers can sustain intensity when they trust the timeline. What destroys motivation is the feeling that the crunch has no boundary. "Just one more week" three weeks in a row is worse than saying "this is going to be hard for six weeks, here is why, and here is what changes after." People run differently when they can see the finish line versus when they suspect it keeps moving.

The other thing I did was protect one thing during the push: choice over how they worked. I could not give people fewer tasks. But I could let them decide their own hours, work from wherever made sense, and structure their days around when they did their best thinking. Some people on my team do great work at midnight. Others need to start at 7 AM and stop by 4. During a crunch, the instinct is to standardize and synchronize. I went the other direction.

What I noticed was that autonomy over process sustained motivation better than any team dinner, bonus promise, or inspirational speech. People do not burn out from hard work. They burn out from hard work inside conditions that fight against how they naturally operate. Protecting that operating freedom during pressure is the cheapest, most effective retention tool I have found.

Long urgent delivery cycles wear teams down because everything starts to feel equally critical. Building Steven Mitts Services and advising founders has reinforced one leadership lesson for me: clarity has to come before effort. When you are launching offers, managing client work, and keeping a young venture moving, there is always another urgent request. The founder's job is to separate real priorities from noise before pressure turns into exhaustion. I try to make the work visible: define the next milestone, explain why it matters, and give the team enough context to make smart decisions without waiting for permission on every detail. People can handle pressure when they understand the goal, the trade-offs, and where they still have ownership. They burn out when urgency becomes vague, endless, and disconnected from impact. That mindset has shaped how I build Steven Mitts Services. Instead of treating motivation as a pep talk, I treat it as an operating system: clear goals, short feedback loops, visible progress, and regular moments to remove friction. The same approach sits behind the Digital Startup Playbook — founders do better when the path is broken into practical decisions instead of abstract pressure. During demanding periods, I focus on three moves: set the next clear milestone, recognize the small win when it ships, and build recovery or improvement work into the operating rhythm. Even a protected window for cleanup, automation, documentation, or technical debt tells the team, "We are not just surviving this sprint; we are building a company that can keep going." The leadership practice that helps me most is the regular one-on-one. Not a status meeting — a real pulse check. I want to know where someone is blocked, overloaded, unclear, or losing energy. That gives me a chance to adjust scope, reset expectations, or move resources before the team hits a wall. Healthy pace is not soft leadership. It is operational discipline. Entrepreneurs who learn that early build teams that can execute under pressure without making burnout part of the business model.

Predictability is a form of respect. Urgent work becomes exhausting when engineers cannot tell whether tonight's priority will be replaced by another emergency tomorrow. Leaders do not need perfect forecasts, but they must explain changes clearly. This helps teams understand what is changing and why.

During high-pressure periods, a daily decision window for new requests can bring more stability. Outside that window, changes require a clear reason and an explicit tradeoff. This limits constant context switching while allowing genuine emergencies to be addressed. Sharing known facts and uncertainties instead of false reassurance helps people plan their efforts and trust that interruptions are being carefully managed.

The habit that made the biggest difference was being honest about two things at the time: how hard the stretch was and when it would end.

Most leaders handle demanding periods by minimizing the difficulty or reframing it as opportunity. Engineers see through both. They already know the pace is unsustainable. What they need to know is whether their leader knows it too. Acknowledging the cost loud. Not as a complaint but as a clear-eyed statement that the team is carrying something heavy and it is being noticed. Does more for trust than any recognition program or team event. People can sustain a stretch when they feel seen inside it. What erodes motivation is not the intensity. It is the feeling that leadership either does not notice or does not care.

The second piece is naming the finish line explicitly. Returning to it regularly. Engineers can sustain anything if they know it is temporary and someone they trust has named when it ends. During periods the leadership habit worth building is a short consistent weekly update: here is where we are here is what has to happen before the pace changes and here is the date we are working toward. That transparency costs nothing and returns an enormous amount. It converts a ended grind into a defined sprint with a known end. The difference in how teams carry those two things is significant.

The combination matters. Acknowledging the cost without naming the end just confirms that things are hard with no relief in sight. Naming the end without acknowledging the cost feels dismissive. Together they send a message: leadership understands what the team is going through and has a plan to get through it. That is what sustained pace actually looks like. Not energy management. Wellness initiatives. Honest communication about reality. A credible commitment, to what comes next.

Under sustained pressure, leaders often postpone improvement work because its absence is not immediately visible to customers. That is misleading. Unreviewed access, fragile deployment steps, and undocumented decisions eventually surface as missed commitments or difficult audit conversations. I kept motivation steadier by making these risks concrete in delivery planning, rather than presenting them as abstract engineering preferences.

The habit was asking, before accepting each urgent request, what future promise does this create. A rushed workaround can create a support burden, customer assurance question, or release dependency. Naming that promise gave product, engineering, and security a language for tradeoffs. Careful work became protection for delivery capacity and customer trust, not competition.

The habit I'd defend is cutting scope before I cut rest. When a stretch gets urgent, the pull is to keep the list the same and ask people to push harder. That works for about two weeks. After that quality slips quietly and nobody says why.

On a small team, I treat each week as having a fixed amount of room. If something urgent comes in, something else leaves the list, out loud, with a name on what got dropped. People can handle a hard stretch. What wears them down is a hard stretch with no end and no say in what's on the pile.

I also hold onto a small slice for improvement work even when it feels like a luxury. Half a day to fix the build step that annoys everyone, or the flaky test that keeps interrupting people. It pays back inside the same sprint, and it tells the team their frustration counts.

Then I say what done looks like for the push, in plain terms, and when it ends. A sprint with a visible finish line feels different from one that just continues. When it ends, the recovery has to be real, meaning actual lighter days and not a thank-you message.

Burnout in a long crunch rarely comes from the hours alone. It comes from fighting the same fire over and over with no end in sight. That's why I stopped treating urgent delivery and improvement work as separate budgets. On one digital health platform, every new clinic integration used to take 16 to 20 weeks, built from scratch each time. Instead of just pushing the team to move faster, we turned that repeated work into a reusable integration framework. Go-live dropped to six weeks, and engineers could see their deadline work making the next deadline easier. The habit that keeps the pace sustainable: at each planning cycle, I ask the team which recurring fire they would fix if they had one free week. Then we protect time for it inside the delivery plan, not after it. People will push hard for a long stretch if they can see the pressure shrinking. They burn out when every sprint looks like the last one.

When a team is stuck in a long stretch of urgent delivery, I've found that motivation depends less on pushing harder and more on making recovery part of the work. In ballet, I learned that constantly rehearsing at maximum intensity doesn't improve performance—it eventually makes technique, focus, and decision-making worse—and I've seen the same principle apply to demanding team environments. The leadership habit I value most is a regular "pressure check": asking what genuinely needs to happen now, what can wait, and what recurring frustration we can remove before the next push. Even during busy periods, protecting a small amount of time to fix one irritating process or reduce unnecessary work gives people a sense that conditions are improving rather than simply surviving another deadline. I'd also make completed work visible and acknowledge progress specifically, because an endless urgent queue can otherwise make a productive team feel as though they're never accomplishing enough. A healthy pace isn't created by eliminating every demanding period; it comes from leaders refusing to let emergency mode quietly become the normal way of working.

During prolonged urgent delivery, I focus on reducing uncertainty and repeated effort. People can handle a demanding period more effectively when they understand what matters most, who owns each decision, and what can wait.

The leadership habit I find most useful is making trade-offs explicit in a short, regular delivery discussion: What must finish? What is blocked? What should we defer? When a new urgent request arrives, we need to reconsider the existing priorities rather than simply add it to everyone's workload.

In data engineering, repeated validation can become a significant source of pressure. My work has included reusable test cases and reconciliation across multiple reporting periods. I see that kind of improvement work as part of delivery: it helps teams build confidence without repeatedly starting the same checks from scratch.

Recognition should also include the less visible work finding a data inconsistency, documenting a decision, or preventing a defect not only launching a feature. A healthy pace depends on making progress visible and addressing the causes of recurring urgency. Sustained overtime should not become the team's definition of commitment.

These are my personal views, not statements on behalf of my employer or clients.

During demanding delivery periods, I have found that one of the most important things is being clear about what actually needs attention now and what can wait. In application security, giving a development team a long list of issues when they are already working against a tight deadline usually does not help. I try to prioritize the work based on risk and make sure the team understands what is most important.

One habit that has helped is keeping communication simple and consistent. If priorities change, I explain why. If something does not need immediate attention, I avoid treating it like an emergency. I also try to move security feedback earlier in the development process so teams are not dealing with unexpected issues right before a release.

I have learned that sustaining a healthy pace is not about asking people to continuously work faster. It is about reducing unnecessary work, setting realistic priorities, and giving teams enough clarity to focus on what matters most. That helps maintain momentum during demanding periods without making every issue feel urgent.

The trap most founders hit is thinking motivation dies in a delivery crunch, when really it dies after the crunch ends and there's no let-up. Your team doesn't burn out on the sprint, they burn out on sprint three with no visible breathing room.

When we hit sustained delivery pressure at Pageloot, the worst thing I could've done was motivate harder. Instead I did something mechanical: I blocked two days every other sprint for what we called "friction work" , not a nice-to-have, scheduled right into the calendar like it was a client deadline. Someone's build was slow, someone else's local setup took an hour, a test suite was flaky. Pick the three smallest things that annoyed people in the last sprint and fix them that week.

It sounds trivial but it's the opposite of motivation. It's permission. The moment your team sees you defend that time the same way you defend shipping time, they stop feeling like they're choosing between "be reliable" and "be sane." They're not grinding toward an invisible finish line anymore.

The other part: I stopped asking "how are we doing" and started asking "what's one thing you'd change about how we're shipping right now." Not sentiment, just friction. One founder I know did this and found out his team hated the deploy process so much they were shipping less frequently to avoid it. Thirty minutes fixing that unlocked more throughput than any pep talk.

Sustain happens in the dailies, not the speeches.

What wears engineers down in a long crunch usually isn't the hours. It's shipping things they know are fragile, with no sign anyone will let them come back and fix them. Tired people recover with a weekend. People who feel they're quietly building a mess they'll be blamed for later don't. That's demoralization, not fatigue, and more pizza doesn't touch it.

So the habit I leaned on was an IOU list. Every time we took a shortcut to hit a date, whoever flagged it wrote one line: what we skipped, why, and what it would cost to fix. Nobody argued about it in the moment. It just went on the list. Then, before the crunch ended, not after, I put a date on the calendar for paying down the first chunk, and I protected that date like a launch.

That changed the mood more than any pep talk. Engineers will tolerate an ugly shortcut if they trust it's a loan and not a permanent decision. The list made the debt visible and owned, and the date made it believable. It also gave me a real read on risk. When the same system showed up on the list three times, that was where the next outage was coming from.

The other half was simpler. I left at a reasonable hour, and I made sure people saw it. If the person setting deadlines is online at midnight, everyone reads that as the real expectation, whatever the memo says. I'd rather do good work at a pace I can repeat than look busy and burn the team out by month two. Long pushes are won by the people still sharp at the end.

What burns engineers out isn't only the hours. It's the feeling that the crunch has no end and that the mess they're piling up will be theirs to clean later.

The habit that's helped most on teams I've led is protecting a small slice of every sprint for fixes the engineers pick themselves, even during the busiest stretches. It might be a slow test that wastes ten minutes a day or a deploy step everyone hates. Small, but it tells the team their pain matters and the codebase isn't just getting worse.

The second piece is being honest about the finish line. "We push hard for six weeks, then we slow down and pay back what we borrowed" is something people can get behind. "Just keep going" isn't. And when that date arrives, keep the promise, or nobody believes the next one.

I also try to say no to extra scope out loud, in front of the team, so they see someone is guarding their time.

People will sprint for a deadline. They won't sprint forever for a deadline that keeps moving.

Give each engineer one bounded piece of the system that's theirs, and keep some work in every sprint that can't page anyone. That held our team through the roughest stretch I've been part of.

That was at MyTona (Cooking Diary, 22M+ downloads), when we moved game analytics from nightly batch to streaming on Flink and Kafka. Building the pipeline was the easy part. The first three months in production were worse. Checkpoint storms whenever a seasonal event spiked traffic, three incidents in the first two months, each a manual savepoint recovery plus reconciling downstream tables. In month three a game update added a high-frequency event we hadn't partitioned for, one partition went hot, the consumer fell behind, checkpoints slowed, it fell further behind. Nobody got a quiet week. I wasn't the manager, I'd built the pipeline and carried the pager for it, so this is the view from inside.

The first thing that worked was giving each failure mode an owner. Whoever got paged for a class of problem wrote its runbook (savepoint recovery, topic rebalancing, Flink upgrades with state compatibility, schema migrations). Those runbooks ate as much engineering time as the pipeline had, nobody budgeted for that. The person who wrote one stopped dreading that page, it was their checklist now. And they could watch the number move, recovery went from 2 to 4 hours of full re-run to 5 to 15 minutes of checkpoint restore. The team knew whose runbook had moved that number.

At Softline now it's client migrations, SQL Server to BigQuery, on the client's deadline, and we keep one name on each of our 15+ connectors for the same reason. I do it to myself too. Between pushes I write small open source tools with no deadline, promptfirewall, a PII and prompt injection scanner in Rust, started that way.

The second thing at MyTona was work that couldn't hurt anyone. When I built ML anomaly detection on that pipeline, it ran for several weeks with paging switched off. That was our recovery, a job that couldn't wake anyone. Alerts went to a chat channel and on-call sorted them against the incident log. One engineer did most of the sorting (tedious, a couple of hours a week). That engineer wrote the filter rules that shipped and kept tuning them months after the rest of us moved on. The last change to those rules before I left was theirs, a threshold tweak ahead of a holiday event.

During one long stretch of urgent delivery, I noticed that our daily stand-ups had quietly turned into a performance. Everyone reported what they had crossed off, and the engineers who were stuck said as little as possible, because admitting you're behind feels terrible when the whole team is sprinting. So we changed the format and started every stand-up with blockers instead of progress. It was a small change with a big effect: being stuck became a normal thing to say first thing in the morning, people asked for help days earlier, and problems that would have simmered in silence got solved much quicker. It also improved collaboration amongst the team members who were previously hacking away at their individual tasks. Engagement went up because the meeting stopped rewarding people for looking busy and started rewarding them for being honest about what was in their way. Under pressure, the most useful thing a leader can do is make it safe to say "I'm stuck" out loud.

When software teams spend too long in urgent-delivery mode, motivation usually drops because people stop seeing progress beyond the next deadline. The leadership habit that has helped us most is a weekly capacity reset.

During demanding periods, we review three things with the team: what truly must ship now, what can be delayed, and what recurring work is creating unnecessary pressure. We also protect a small amount of capacity for technical debt, automation, documentation, testing improvements, and recovery. Even during a critical delivery cycle, engineers need to see that we are not simply adding more work without removing anything.

Another important habit is making priorities explicit. When everything is labeled urgent, engineers are forced to make priority decisions themselves, which creates stress and rework. Leadership should make those trade-offs clear and explain why a deadline matters.

We also rotate people away from the most intense work when possible instead of relying on the same engineers for every emergency. Pairing, code reviews, shared documentation, and cross-training make that easier because knowledge is not concentrated in one person.

The goal during a demanding period should not be to ask the team to “push harder” indefinitely. It should be to continuously remove friction. If a manual deployment, repetitive test, unclear approval process, or unnecessary meeting is consuming engineering time, leadership should treat fixing that friction as part of delivery—not as work that can only happen later.

A healthy engineering pace comes from clear priorities, protected improvement time, shared ownership, and leaders who actively remove unnecessary work. That approach has helped our teams maintain quality and momentum even when delivery timelines are tight.