It’s a weird middle ground: you want your direct report to challenge another team’s architecture, but not become “that guy” → the one who points out flaws so bluntly, nobody wants him in the room.
The first instinct (especially for deep technical folks) is to lead with the flaw. It’s fast. It feels honest. But it also triggers egos and closes doors.
It’s not about watering down feedback - it’s about opening the door for context:
“Help me understand why we did X this way? I’m noticing it might conflict with Y.”
Suddenly, you’re on the same side, problem-solving together instead of throwing stones across the fence.
But that’s only half. Feedback without a shared goal is just noise. I push my DRs to always tie architectural challenge to what we are trying to achieve. eg:
“If we rename this endpoint, frontend will spend less time debugging.”
Make it about making the product (and team) better, not about personal wins.
And yes, radical candor. Challenge directly, but care personally. That last part is the hardest, because, for technical folks, “I care” doesn’t show up in the code diff. You have to say it, and mean it. “I want us all to move faster—and right now, I think this slows us down.”
This isn’t about being nice. It’s about being effective. Critique is easy. Building bridges takes skill. But it’s the only way teams actually level up together.
Bonus cheat lines
(copy-paste ready)
- “I might be missing a constraint— can you walk me through X?”
- “Goal is same as yours: ship safely. Here’s a risk I see…”
- “Happy to pair on the fix if you’re swamped.”