|
* Names and identifying details have been changed to protect privacy. The stories are real.
Opening Story
He Could Do Everything. That Was the Problem.
|
I used to mentor a coworker I'll call Marco. He came to Atlanta from Bogotá about eight years ago. Engineering lead at a mid-size software company. His team had five developers, and Marco could outcode every single one of them. When a deploy went sideways at 9 PM, Marco jumped in. When a junior dev's pull request was messy, Marco rewrote it himself. When a sprint was behind, Marco absorbed the overflow.
|
|
His performance reviews were glowing. "Incredibly reliable." "Always delivers." But when a director-level role opened up, the feedback from his VP stopped him cold: "Marco is a phenomenal individual contributor. But we need to see him build capacity in others, not just carry the load himself."
|
Marco did what many of us were taught to do: prove your value by being indispensable. In the culture he grew up in, you didn't hand work off. You handled it. Asking for help was a sign of weakness. Trusting someone else to do it "your way" felt like a gamble you couldn't afford, especially when your name, your accent, and your visa status already made you feel like you were on probation.
But here's what Marco's story teaches: the thing that got you here, doing it all yourself, is the exact thing that will keep you from getting to the next level. Leadership isn't doing the work. It's building the conditions for others to do it well.
This week, we talk about the hardest shift for high-performing immigrants: letting go without losing control.
This Week's Scenario
The "I'll Just Do It Myself" Moment
|
A report is due Friday. You assigned it to someone on your team two weeks ago. It's Wednesday afternoon and you open their draft. It's... not great. The analysis is shallow. The formatting is off. There are errors in the second table.
You have two choices. You can stay late, redo the whole thing yourself, and submit something perfect under your name. Or you can sit down with your teammate, walk them through what needs to change, and let them resubmit it, knowing it might still not be exactly how you'd do it.
Most of us pick option one. Every time. Because it feels safer. Because we've been taught that our personal output is our proof of worth. But here's what I've learned from watching people I've mentored navigate this: every time you redo someone else's work, you're training them to need you and training your leadership to see you as the doer, not the developer.
|
|