Avoiding Burnout While Still Getting the Work Done

What Would You Do If a Project Needed Overtime?#

This is a story about someone who really didn’t want to work overtime—
but still cared deeply about getting things right.

A New Thought Process#

After hitting a wall with the framework upgrade, I began looking for other ways to support the current system and prepare for future service separation.

One promising direction was a CSS framework migration.

Without formal engineering management practices, it’s easy to end up with multiple solutions to the same problem.
In frontend work, this can be especially costly—since client-side assets directly affect performance.

At the time, our project used three different CSS frameworks—a nightmare for any frontend engineer.

Every new design meant figuring out which set of components and styles it referenced.
It was inefficient, error-prone, and painful to maintain—plus the performance hit from loading redundant styles.

I’d seen this problem before, and had led similar refactors in a previous job.

What’s More Important Than Performance#

Performance was a concern, but the deeper issue was structural.

Some implementations directly coupled business logic with UI components from external libraries.
Without an abstraction layer, switching frameworks or updating the design system later would be painful.

I didn’t believe any of the current frameworks were long-term solutions.
For a mature B2C product, a custom UI layer—optimized and lean—is often the logical next step.

But without the resources for that, I proposed a pragmatic alternative: standardize on a single framework.

Three key goals:

• Normalize the abstraction layer between business logic and UI
• Reduce ambiguity in design/implementation discussions
• Eliminate unnecessary decision-making during development

How to Deliver Without Overtime#

The company wouldn’t allocate dedicated resources.
I worked with the not-yet-official Platform Team, using just 50% of their capacity.
Team composition shifted weekly, depending on priorities.

At 30% completion, things got tricky.
We estimated two more quarters to finish—too long and too risky.
The project could be cut at any time.

I Refused to Burn Out the Team#

I didn’t want to waste the effort already spent.
Every piece of tech debt we repay is a chance to build a stronger foundation.

But I wasn’t going to sacrifice my teammates’ health to do it.
This was my vision, not theirs.

So I asked myself:

If every frontend developer will benefit,
why not let them participate?

If people helped build it, they’d also help sustain it.

I spoke with R, my manager, about product team availability.
We devised a new collaboration model—later the prototype for Platform–Product team work.

I acted as project owner and tech lead, managing code reviews and technical decisions.

Each week, I broke down work into well-scoped tasks, synchronized across teams, and aligned on staffing and delivery.

This sped up progress so much that R assigned more engineers—letting us finish the migration that same quarter.

More Resources = Finish Faster?#

If that were the end, it would be a happy story.

But when a manager adds resources, they’re not saying:
“Take your time and do a great job.”

They’re thinking:
“How can we do this faster and better?”

R checked in often about staffing and timelines.
I understood his pressure.

But I also wanted this project to grow our teammates’ skills—especially in UI engineering and design collaboration.
Focusing only on the deadline would lose that chance.

Switching Gears#

When R asked again about the timeline, I told him I’d bring a plan the next day.

That night, I shifted into project management mode.

From the company’s perspective, the migration needed to be visible to upper management—a functional requirement.
But the deeper value—less decision fatigue, more consistency—was a non-functional requirement.

Could we split delivery into phases?

Looking into the CSS framework’s source, I found a workaround:
By moving certain components into the codebase, we could defer deeper refactoring to next quarter—while still showing visible improvements now.

It met the “immediate results” need and protected the team’s health.

I adjusted the plan, got R’s approval, and realigned staffing.
We shipped the migration without overtime. (Whew.)

My First Fully Owned Large-Scale Project#

I managed shifting resources, strategic pivots, architectural decisions, and over 13 developers.
Weekly, I handled task planning, code reviews, and stakeholder updates—working closely with R to keep cross-team participation steady.

Toward Engineering Culture#

This wasn’t just about performance.
It laid the groundwork for future service separation.

More importantly, it changed my thinking:

Why are we doing this?
How do we make sure our future selves are glad we did?

I started out fixing maintainability and performance.
I ended up learning that lasting change needs:

• Well-designed systems
• Strategic planning
• Flexible resource allocation

This brought me closer to the core of engineering management:
Building stability in a world of constant change.

The lessons were worth more than the output.
And the trust I earned became fuel for even bigger changes later.

At the time, I didn’t know it.

But this was just the beginning.