The Facebook Marketplace moment that showed me what I’d been doing wrong as a manager…

The other week, I sold some computer monitors on Facebook Marketplace to a young Ukrainian immigrant and her dad. She couldn’t have been more than fifteen.

She quietly asked if the price was negotiable. When I said sure and asked what she was thinking, she offered something fair, a bit lower than my asking price, but reasonable. Her dad stood in the periphery the whole time, only saying this was all her—her money, her plan, her room setup. He was just there for the ride.

We agreed and I helped them take the monitors to his vehicle.

The thing that struck me most was how he was clearly restraining himself. She was nervous, negotiating in her second language, figuring out how to use her voice. And he just… let her work through it. (She did great, by the way.)

Watching that dad hold back, when he easily could have “jumped in and ‘helped,’” I realized I’d spent years as a manager doing exactly the opposite.

The Big Picture

For years, I thought being helpful meant fixing things. Someone submitted a subpar technical report? I’d redline it in under an hour and send it back (and when I say redline, I mean it. Sometimes the document came back more red than black). When the revision still wasn’t good enough, I’d just fix it myself and send it out.

This felt efficient. Pragmatic. The output had my name on it, so the quality had to meet my standards.

What I actually created was a team that couldn’t function without me.

I became the bottleneck on everything. Every technical document needed my revision and attention. Every project deliverable sat in my queue waiting for me to “fix” it. And my team? Completely underdeveloped because I never let them struggle through enough revisions to actually get better.

Instead, I taught them their work would never be good enough, so why bother trying harder?

Core Insight

Here’s what I didn’t see until I stepped into a different role—one where I wasn’t responsible for that team’s output anymore: I didn’t need to take over. I’d just convinced myself I did.

That realization hit fast once the accountability pressure lifted. Without my name on the line, it became obvious: every time I “helped” by completely rewriting their work, I robbed them of the productive struggle that builds capability. Without me in the picture, they did just fine.

I left that firm for three months in 2015. The young engineer I’d hired and actually mentored—rather than just fixing his work—took over. He’s still running the show today, a decade later. The team I thought neededme constantly? They were fine. Better than fine.

Just like that dad could have negotiated a better price faster, but that wasn’t the point. The point was his daughter learning to use her voice in an uncomfortable situation.

Every time I jumped in to “save” a report, I sent the same message: your development matters less than my efficiency.

Why This Matters To You

Technical leaders are especially vulnerable to this trap because we CAN do it better and faster. At least initially. And we’re accountable for the output quality, so ‘just doing it myself’ feels pragmatic rather than harmful.

Here’s what you’re not seeing: Every time you take over instead of coaching through the struggle, you create three problems at once.

First, your team stops developing. Why struggle through three revisions when you’ll just fix it anyway? You’ve taught them that good enough gets the same result as giving up—you swoop in either way.

Second, you become the permanent bottleneck. That presentation sitting in your queue? The code review only you can do? The client deliverable waiting for your final pass? You built a system that can’t function without you.

Third, you can’t advance. While you’re stuck being the only person who can “do it right,” someone else is building the team that runs

without them. Guess who gets the bigger role?

So, where are you “helping” right now that’s actually preventing someone’s growth? The report you’ll inevitably rewrite? The meeting where you’ll take over when they stumble? The project you won’t delegate because ‘it’s faster if I do it’?

Every one of those moments is trading their capability for your comfort.

Practical Steps

1. Today: Look at your calendar and task list. How many things are sitting in your queue because “only you can do them right”? That’s your bottleneck inventory—and your signal about where you’ve  prevented development most.

2. This Week: Pick ONE report or deliverable you’d normally take over and fix. Send back three specific issues that need addressing. Nothing more. Make them figure out how to fix it. Then do it again when the revision comes back if needed. Yes, this takes longer. That’s the point.

3. This Month: Track how many times your instinct is to “just do it myself because it’s faster.” Every time you feel that urge, ask  yourself: “What’s the real cost if this isn’t perfect on the first try?” versus “What’s the cost of staying the permanent bottleneck?”

This isn’t about “stop helping.” It’s about recognizing when “helpful” actually means “taking over”—and choosing development over efficiency.

That Ukrainian teenager learned more from one uncomfortable negotiation than she would have from watching her dad handle ten transactions for her.

Your team learns the same way. But only if you let them struggle.