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.





