During a product retro a few weeks ago, my teammates mentioned where they're blocked. This made me remember a productivity post I'd read years ago that I can't find anymore. Something about "dealing with inefficient people." The argument was simple: some people get things done, some don't, here's how to manage the ones who don't. Stay detached, apply a little pressure, route around the blockers.
I bought it back then. When someone's missed deadline is holding up your work, you don't want to untangle why they're behind. You want things moving. You want a simple playbook: don't take it personally, push for the outcome, route around them if you have to. It sounded professional and resonated with me at the time.
But I've since managed teams, been managed, and made enough of my own messes that this approach felt sociopathic, or close to it, and was missing the whole picture. It might be all right in some situations, but it shouldn't be the first thing you resort to.
Efficient vs inefficient
Efficient people on one side, inefficient people on the other. That's a simple satisfying world view when you're frustrated. This could be more complex that it seems.
A person who takes three days to reply to your Slack might be doing the only work that actually matters this quarter. Someone else who responds instantly to everything is sometimes doing it because they can't prioritize. It's easier to look busy than to choose.
Efficiency isn't a trait. It's contextual. Someone looks "inefficient" when their constraints, priorities, or incentives don't match yours. You usually can't see those from the outside.
So when you say "this person is inefficient," you're often stating a conclusion. When you say "this process keeps producing bad outcomes," you're in a more useful place.
Indifference works until it doesn't
The emotional detachment advice is genuinely good. Don't make it personal. Protect your energy. I still think that's the right first instinct when something's blocked.
The problem is stopping there. If routing around someone is your only move, you end up maintaining that workaround forever without fixing what's broken. You can't do it all the time, and your frustration will only get stronger once this happens again.
What works better is curiosity. Not the passive aggressive or confrontational kind. More like: "help me understand what's blocking this." Most of the time you'll find out they're waiting on someone else, or nobody told them it was urgent, or they have five other things on their plate that their manager considers higher priority than your request. The block often goes away once you see that.
A five minute huddle usually gets you further than pressure.
Pressure works once
Social pressure works in the short term. Asking uncomfortable questions in public, going over someone's head, making someone feel accountable in front of peers. People comply when they feel exposed.
But they remember and someone who felt pressured will do the specific thing you wanted and then avoid you. You won a task and traded away the relationship. Over a year, that math rarely works out.
People who feel supported tend to help. People who feel judged tend to do the minimum to make you go away.
When you're the slow one
You might be the slow one sometimes.
If you've ever insisted on a process that someone else found pointless, you were the inefficiency in their day. If you've created a form, a checklist, a review step, or an approval flow that slowed someone down, even for a good reason, you were their red tape.
That doesn't mean those processes are wrong. Efficiency is relative to goals, and different people in the same org often have legitimately different goals. The finance sign-off process feels like an obstacle until you're the one explaining how $80k got spent without authorization. The legal review delaying your launch is often someone managing a risk you haven't thought about yet.
Calling other people's processes bureaucracy assumes you have the full picture, and it's often the case you don't have it.
It's almost always the system
Most "inefficient people" are just people inside broken systems.
Bad handoffs. Unclear ownership. Deadlines that were implied but never stated. Goals that got set in a doc nobody reads anymore. Communication split across six tools where context dies in transit.
Fix those and a lot of the people you were frustrated with start performing fine.
Think about the last time someone gave you a slow response. Did you tell them when you needed it? Did they know it was on the critical path? In a lot of cases, what looked like a people problem was a context problem. It's easy to drop the ball when it happens.
At times, boring structural stuff matters more than it feels like it should: who owns what, what "done" actually means, how information moves by default. Get that right and you spend less time being frustrated and more time doing work that doesn't leave you emotionally drained.
Let things fail sometimes
Sometimes the right call is letting someone fail. Not often, and not when the downside is real. When the stakes are low and the mistake is reversible.
That's the part the original playbook skips. Letting someone miss an internal deadline on a draft? Maybe, if they own the outcome and you were clear about it. Letting someone ship the wrong thing to a customer because you wanted them to "learn ownership"? That's outright negligence with a coaching label on it.
Here's how to check when it's ok: did they have clear ownership, the authority to act without you, and enough context to make a reasonable call? If yes, and they still chose badly, a small consequence can teach more than your rescue. If no, you're not developing people. You're watching them struggle inside constraints you left vague, then calling it a lesson.
If you always step in anyway, you become the load bearing wall. People stop bringing you problems they've already half-solved. They bring you problems they expect you to fix. Similar to a kid who still asks you to tie their shoes because you've always done it faster.
Letting someone live with a flawed approach teaches judgment that feedback usually can't. You learn it by dealing with the fallout of your own mistake, not by being warned about mistakes in theory - even though generally it's much cheaper to lears from others' mistakes, the experience of this lesson could be more valuable than the lesson takeaways.
You're not abandoning people, you're giving them ownership, a clear scope, and a safety rail on the stakes. Otherwise they'll keep waiting for you to lead, because that's what the system has trained them to do.
The framework I'd suggest using is different from "some people are efficient and some aren't." I'd start with: something here isn't working, figure out why before you figure out who. Most of the time, the problem isn't the person.