Team Lead
•

Dear Morgan - Do I reward heroics?

Agony aunt Morgan answers how to deal with coding heroics
Dear Morgan - Do I reward heroics?

Dear Morgan

I’m near the end of a project, and time is tight—we haven’t even started one of the major deliverables.
I submitted a PR with a couple of workarounds. Not elegant, but it works.

A senior data scientist (who’s built most of the codebase) isn’t happy.

He’s proposed changes.
A lot of changes.

I explained: I’m fine with making updates, but we’ll need to restructure some things.

Instead, he completely rewrote it.
And introduced new problems in the process - including a tangle of circular dependencies.

I don’t want to come off as dismissive or disrespectful - he’s thoughtful and clearly invested.
But we only have 8 weeks left.

What do I do?

Morgan says

Been there. Done that.

It’s a fun one.

At the start of one project, I had a data scientist work an entire weekend—without asking—and turn up Monday morning with a 35,000-line PR.
A single framework. Entirely new.

The whole week started and ended with that PR.

It’s a pivotal moment.
If you wave it through, you set a dangerous precedent:

  • Heroics get rewarded.
  • Collaboration loses to solo effort.
  • And worst of all, any future disagreement gets settled by weekend code marathons.

And you’re stuck with that framework for the rest of the project.

So maybe you reject the PR.
You cite the lack of planning, the sheer size, the inability to reasonably review it.
All valid.

But that won’t be the story they tell.
What they’ll hear is: you don’t value their work, their ideas, their effort.

Here’s the tension:
You’re the engineering lead.
You’re accountable for delivery.
And this is an engineering decision.

So the question becomes: is the tech debt an acceptable tradeoff?

Probably.
Otherwise, you wouldn’t be asking me.

So - what would I do?

You’ve got 8 weeks.
That’s not much time for an entire use case…
…but it’s enough to create a mentoring moment.

Redo his redo.

Circular dependencies are bad. Like, really bad.
So turn it back into a teachable moment.

If he insists on rigorous standards above all else, fine.
Flex your engineering might and show him what a clean, crafted solution actually looks like.

Then schedule a careful pair programming session after the fact.
Walk through what it took to do it right—highlight the time cost of a quick-and-dirty versus a designed approach.

The project ends up with the code quality it deserves.
You’ve asserted your status as alpha (with as much toxicity as HR guidelines allow)
And your data scientist walks away with a lesson in compromise.

Everyone wins. Sort of.

Finished without failure
Older post

Finished without failure

Newer post

God, I love recruiting

God, I love recruiting
Further reading for leaders

Explore the archive

So, you wanna be a team lead
Team Lead
•

So, you wanna be a team lead

What is a team lead? Do I want to be one? Where would I start? This practical guide breaks down the role and how to start.

The line between solid and senior team lead
Team Lead
•

The line between solid and senior team lead

If you're asking, you're closer than you think. Here's the rest of the map.

LEADERSHIP, SCALE, AND THE HUMAN ELEMENT

Principles & Perspectives

How do you define successful engineering leadership?

The Philosophy

Many view technical leadership as being the “smartest architect in the room.” I see it as the opposite. My job is to build a room where I don’t have to be the smartest person because the systems, culture, and communication are so robust that the team can out-innovate me.

The Strategy

  • Alignment: Does every engineer understand how their sprint task impacts the company’s bottom line?
  • Velocity vs. Stability: We aren’t just “shipping fast”; we are building a predictable, repeatable engine that doesn’t collapse under its own weight at the next order of magnitude.
  • The Human Growth Curve: Success is when the engineering team’s capability evolves faster than the product’s complexity. If the team feels stagnant, the tech stack will soon follow.

What is your approach to scaling technical organizations?

The Philosophy

Scaling isn’t just “hiring more people” - that’s often how you slow down. Scaling is about moving from Individual Heroics to Organizational Systems.

The Strategy

  • The 3-Continent Perspective: Having managed global teams, I focus on “High-Signal Communication.” As you grow, the cost of a meeting triples. I implement “Asynchronous-First” cultures that protect deep-work time while ensuring no one is blocked by a timezone.

  • Modular Autonomy: I advocate for breaking down monolithic teams into autonomous units with clear ownership. This reduces the “communication tax” and allows us to scale the headcount without scaling the bureaucracy.

  • Automation as Infrastructure: At petabyte scale, manual intervention is a failure. I treat the developer experience (CI/CD, observability, self-service infra) as a first-class product to keep the “path to production” frictionless.

How do you balance high-growth velocity with technical stability?

The Philosophy

Technical debt isn’t a “bad thing” to be avoided; it’s a set of historical decisions that no longer serve you. Like any loan, leverage can accelerate growth when investments payoff. But if velocity and returns are slowing you need a payment plan before the interest kills you.

The Strategy

  • The ROI Filter: I don’t refactor for the sake of “clean code.” I don’t refactor a micro-service with no users. I refactor when the pain on that debt - measured in bugs, downtime, or developer frustration - starts to exceed the cost of the fix.

  • Zero-Downtime Culture: Especially at scale, stability is a feature. I implement “Guardrail Engineering” where the system is designed to fail gracefully, ensuring that a Series B growth spike becomes a success story rather than a post-mortem.

  • The 70/20/10 Rule: I typically aim to dedicate 70% of resources to new features, 20% to infrastructure/debt, and 10% to R&D. This ensures we never stop innovating, but we never stop fortifying either.