Have you ever had your work rewritten without a single comment?
“Dear Poornima,
One of my engineers pitched a project, teamed up with our team’s architect to design it, and then did most of the implementation. After it was completed, our architect rewrote the entire project. I’m now concerned about my engineer’s reaction. My engineer said they would have appreciated more feedback and would have gladly iterated, but it feels like they might be holding back. I don’t want to keep digging if they’ve moved on, but it does feel like a douchey move by our architect.”
– Engineering manager, navigating a difficult team dynamic
—
Your instinct is right, and this situation has three distinct outcomes that need to be addressed.
The architect: rewrote instead of coached the engineer. Whether the code needed improvement or not, a full rewrite after implementation is not feedback it’s erasure. It sends one message regardless of intent: your work wasn’t worth building on.
The leader: there was no feedback loop during the work. This could be viewed as a process gap as in the architect co-designed the project and then went silent through implementation because that was the end of their engagement. However, the gap needs to be brought up by the leader and revisited by them and the architect.
The system: the engineer can’t say what they actually feel. “They might be holding back” means the team doesn’t have the psychological safety for the engineer to name what happened directly. That’s a signal about the culture.
The conversation with your engineer
Don’t let this one go. “I don’t want to keep digging if they’ve moved on” is reasonable, but the fact that you sense they’re holding back means they haven’t moved on. They’ve concluded that saying the full thing isn’t safe or useful.
Don’t ask “how are you feeling about what happened”. It’s too easy to deflect.
Instead: “I want to be honest with you. I think what the architect did wasn’t handled well, and you don’t have to protect me from the real answer.”
That framing names your own read, gives them explicit permission to say the harder thing, and signals you want to actually know, not just be reassured.
If they open up: listen first, fix later. The engineer needs to feel heard before they can hear anything else.
The conversation with your architect
Yes, what the architect did was a poor call. Say so, directly and without hedging.
The framing isn’t “you hurt my engineer’s feelings.” That’s too easy to dismiss.
The framing is: “When you rewrote the implementation without iterating with the engineer first, it created a trust problem on the team. I need that to not happen again, and I need you to understand why.”
You’re not questioning the technical judgment. You’re naming the method as the problem. Keep those two conversations separate. It prevents the architect from defending the code quality as a way to avoid the real issue. If they push back with: “it was faster to rewrite than to explain,” name what faster actually cost: an engineer who no longer trusts that their work is worth building on, and significant relationship capital spent repairing something that could have been avoided.
Speed that creates that kind of damage isn’t efficient. It’s just invisible in the short run.
What to consider changing going forward
Build a feedback loop between design and delivery. Mid-implementation reviews, not post-completion verdicts.
The architect’s job when co-designing a project is not finished at the design document. It includes being present enough during implementation to catch drift early, and coaching the engineer through it, not around them.
A rewrite isn’t feedback. It’s a verdict. And your engineer received it without a trial.
Often I post a reply to a reader’s question. If you’re in the thick of it, whether that’s feeling stuck, weighing a move, or trying to size up a company from the outside, come along. I write about the climb from engineer to technical leader every issue: getting heard, getting unstuck, and knowing when it’s time to move on. Subscribe to my newsletter here, then hit reply with your own situation. The most universal ones become the next post.
