When Doing Too Much Is a Symptom, Not a Solution

6 min read Original article ↗

We are now back for more on the series Between Good Enough & Too Much with post #3.

It’s Friday.

Let’s refocus on the human side of engineering.

We don’t just ship code from abandoned basements.

We collaborate, we negotiate, and we push through conflicting priorities.

We work with people, and that makes all the difference.

Sometimes, the hardest part of the job isn’t the job itself.

Setting the Stage

Before I joined Shopify in 2023, I worked at a company where I had to juggle multiple priorities across various teams. I was brought in as the backend F# expert for a new team building critical infrastructure.

At the time, I was a member of the board of trustees for the F# Software Foundation. I was leading educational initiatives, active on the F# Slack, and excited about finding a role that actually used F# in production, a niche language that still feels relevant (and remains so).

Deadlines were already slipping.

Our mission? Rewrite a 15-year-old SOAP-based API into a suite of gRPC services with F#, ASP.NET Core, and Protobuf.

We were three backend engineers trying to modernize a legacy god controller (thousands of lines of code).

Early Ambitions

I remember sitting down with my manager during those early days. I shared that I wanted to grow into a tech lead role, maybe after a few years.

I wasn’t trying to take over. I wasn’t trying to lead right away.

It was my first real exposure to distributed systems, and I wanted to learn, contribute, and make a dent.

And for a while, it felt like things were going well.

But I missed the signs.

The Signs I Missed

The junior developer who had been on the team before me quit.

Others made the tough decision to leave without a job lined up.

Teams merged, scopes widened, and expectations grew — fast.

Worse? Entire teams went silent on Slack.

Just profile pictures. No green dots. Never active.

Four months in, I became the backend “lead” by attrition.

Then, the Scrum Master pulled me aside and said I was being quietly considered for the tech lead position.

A few days later, my manager denied it outright.

Shortly after, the Scrum Master was gone.

Blocked Transfers & Quiet Resistance

When the CPO announced a company-wide restructuring and encouraged team transitions, I felt a sense of relief. I’d already had three managers in four months — maybe this was a reset.

I met with a manager from another team. It felt like a good fit.

I informed my current manager I planned to move.

“Not so fast. It won’t happen for months.”

But the town hall had made it sound like transitions were immediate.

So I waited.

In the meantime, one teammate had a public blow-up and quit the same day.

Another left within a month of joining.

I had no assigned work.

So, I turned to something long overdue.

The Refactor Nobody Wanted

Our team owned a testless, 3,000-line SOAP controller.

No unit tests. No integration tests. Nothing.

Every backend change meant the QA and frontend teams had to stay late, sometimes until 2 or 3 a.m., manually verifying whether anything had broken.

That never sat right with me.

I even pushed back on a feature deadline to give QA and frontend more breathing room.

So, I started a refactor.

I broke things down, cleaned it up, added tests, and opened a draft PR.

It felt good. Like we were making space for better habits.

Like the late nights could stop.

Then came the backlash.

“Better to Leave It Alone”

My then-manager didn’t thank me.

He didn’t encourage the effort.

“If you go through with this, every time something breaks, we’ll call you. Even if you’re on another team. You’ll be the guy who owns this mess.”

I didn’t leave because of that moment, but that was when I knew I would.

A New Team, Same Pattern

Eventually, I switched teams. I hoped things would improve.

Spoiler: this wasn’t a Disney movie.

This one had two senior engineers, both of whom were new to functional programming and F#. They had chosen the language and designed the architecture before I arrived.

I was brought in as the expert.

The project was already six weeks behind.

My manager said they didn’t expect perfection. Just help ship something that worked.

The architecture? Ambitious.

On paper, it looked elegant. Ports, pure functions, GraphQL, infrastructure separation. All that should be the making of good and soundly designed software, right?

In practice?

Even minor changes felt like wading through molasses. We were only building a handful of GraphQL APIs, and yet the cathedral was already towering. Everything was over-engineered.

Fetching a single value from the AWS Parameter Store took days to review.

Not because it was wrong but because it “violated the structure.”

It became increasingly complex to determine where anything belonged.

Isolation by Process

Newcomers excited by F# often felt overwhelmed. I paired with them to help them through the noise.

But the other senior engineers?

The cold shoulders were real.

They gave me low-priority tasks. Hand-me-down test suites. Code they wrote with no tests. Not the feature work that was required to be done so we could move on from the late project.

They reviewed each other’s PRs but not mine.

My feedback on their PRs?

I was doing some of the following:

  • Blocking comments with examples of refactored code along with well-researched, documented, constructive comments,
  • Minor comments that would benefit the work but weren’t blocking such as styling or alternative approaches.

Eventually, they told me flat-out:

“We’d rather just copy your code after it merges.”

It wasn’t collaboration.

It was silent rejection.

Boiling Point

Eventually, the tension boiled over.

One of the engineers yelled at me for nearly an hour, belittling me in front of our manager.

My fourth manager in eight months.

That same day, the manager called to apologize.

A junior had just left the frontend team.

I could switch over. There’d be no backend work unless absolutely necessary.

“I don’t want you to leave over this,” he said.

So I stayed. But that was the beginning of the end.

What Burnout Feels Like

The spark I felt building things on the front end faded quickly.

Even there, we were doing well over 50 hours a week. When I left, I had been with my fifth manager. Because they all left.

It wasn’t about the tech. Or the structure. Or the stack.

It was the pattern.

Always fighting upstream.

Never quite allowed to fix what was broken.

Never truly trusted to lead, even when asked to.

Aftermath

A few months later, I joined Shopify.

New challenges. New beginnings.

But one lesson lingered:

Sometimes, doing too much is just a response to not being allowed to do enough.

If you’ve felt this, too

You’re not weak.

You’re not alone.

— Kevin