The push-vs-pull conversation in the training was one I expected to read as confirmation. Flexing along this spectrum has been part of how I coach since I started — drawing on managers I’d worked under who modelled each end for me. The session was clearer than the cultural moral that “asking is better than telling” has been: there is a spectrum, both ends are legitimate, and the leader’s craft is reading the right end for the moment.
I want to spell out the spectrum the way I’ve been operating on it, name the two failure modes I see in leaders I’ve worked under, and walk through a recent worked example.
The spectrum, plainly
| Pull (empower) | Push (guide) |
|---|---|
| Ask open questions | Give suggestions |
| Help co-create solutions | Offer your point of view |
| Encourage reflection | Set direction when needed |
| Trust the person’s judgement | Lend yours when theirs isn’t ready |
Each row sounds like a binary. None of them are. A real conversation moves along the spectrum, sometimes within a single exchange. The leader who knows only pull becomes a frustrated coach in moments where the person needed clarity. The leader who knows only push becomes the bottleneck for every decision.
When pull is the right move
Pull is the right default for most conversations with people who have the capability to find an answer if given the room. It builds their judgement, it grows their ownership, it compounds across reps in a way push never does.
Pull is especially right when:
- The cost of the next mistake is learning. If the worst outcome of letting them try is that they get better, pull is almost always right.
- They have the data they need. Asking them to think through a problem they have all the inputs for is generative. Asking them to think through a problem they’re missing key context for is performative.
- They’re ready for the autonomy. Sometimes the kindest thing I can do is to hand someone a problem and trust them to navigate it. The signal that they’re ready isn’t always loud, but it’s usually present if I’m looking.
Pull is where I want most of my coaching to live. The first time I trusted someone to find their own way through a problem they’d normally have asked me about, I saw two things: they found a path, and the path was different from mine in interesting ways. The team gets better in directions I couldn’t have set, and that doesn’t happen if I push.
When push is the right move
Push is the right move in three situations, and I want to be specific because they’re easy to miss when pull feels like the morally right default.
When the cost of the next mistake is too high to be a learning event. Sometimes the problem isn’t one a person should be growing into; it’s one I owe them my perspective on because the team will pay if I don’t. The line I use: if the worst outcome is meaningful damage to the team or the work, I push.
When they don’t have the data or context yet. Coaching a person through a problem they don’t have the inputs for is cruel. The right move is to share the context first, then ask whether they want help thinking through it. Sometimes after the share, they don’t need coaching — they just needed the missing piece.
When they’re not ready for the autonomy. This is the one that requires the most empathy. People in the embarking zone, people new to a domain, people under specific pressure — they need clarity, not space. The push there is a gift. Forcing them to “find their own way” when they don’t have the judgement to do so yet is condescension dressed up as empowerment, and the team feels it.
The two failure modes I watch for
The spectrum has two opposite failures, and I’ve worked under managers who lived in each.
The performative pull is when a leader asks a question after already deciding the answer, performs the listening, then steers the person to the conclusion they had at the start. The team reads this instantly. It’s worse than just pushing, because it adds dishonesty to the slowness. If I have a strong view, I should say it. Pretending otherwise is its own kind of disrespect. I worked under a manager who did this for a year, and the team I was on learned to bring her our pre-formed conclusions and let her “ask” us into agreeing with them. That whole pattern shrinks the team’s actual contribution to the work.
The reflexive push is when a question is brought, an answer is given, the conversation closes. The person walks away with the leader’s answer and not their own. Repeated over months, this teaches the team to bring questions rather than attempts. The bottleneck the leader becomes is one they built. I’ve worked under one of these, too — a manager who answered fast and well, and whose team couldn’t function when he was on vacation. I learned a lot about what I didn’t want my team to feel from that experience.
Both failures are correctable. Both are costly. Both are subtle enough that I’ve committed both in the last few months and had to walk back from. The vigilance is constant.
A short worked example
A mid-level engineer brought me a question last week about how to structure a review of a controversial proposal. The honest read on the moment was: she had the capability, didn’t have all the context yet, and was on a tight deadline.
The pull move would have been: what are you considering, what feels hard, what would you want the meeting to do? The risk of going pull here was that she didn’t have the context that the proposal had political weight beyond the technical content.
The push move would have been: here’s what I’d do, with these constraints in mind, on this timeline. The risk of going push was that I’d hand her an answer she’d execute instead of own.
What I did, in the moment, was the hybrid the spectrum is actually designed for. I pushed first on the context — one thing you should know: this proposal has been pushed back twice already, and the room will be looking for signals about whether it’s worth a third try — and then pulled on the structure — given that, what would you want the meeting to do? The push gave her the data she didn’t have. The pull let her own the structure. The conversation took twelve minutes and the meeting she ran was excellent.
The team effectiveness piece
The throughput case for the spectrum, rather than for either end:
A leader who only pulls is one whose team grows quickly in the easy cases and burns time in the hard ones. The team is autonomous on routine work and lost on novel work, because the leader’s perspective never enters.
A leader who only pushes is one whose team is fast on the work the leader has touched and brittle on everything else. The leader’s calendar is full because every problem routes through them.
A leader who can read the moment is one whose team gets pull when the moment teaches and push when the moment costs. That team grows on the learning problems and survives the high-stakes ones, which is the combination teams need to stay effective over years rather than months.
What the session added
Two things.
The cost-of-next-mistake check. I’d been operating on this by feel; now I have it as a sentence. What’s the cost of the next mistake here? If it’s learning, I pull. If it’s harm, I push. If it’s unclear, I ask one more question to help me decide which it is.
A way to teach the spectrum to my senior engineers. They mentor too. The spectrum gives them the same explicit moves I now have, and lets them notice their own defaults. That’s the multiplier.
The practice
The check I run in retrospect: did I push when I should have pulled, or pull when I should have pushed? I keep a rough log of these calls. Not formally — just a note when I notice. The pattern, over months, tells me what my default is doing wrong, and the next quarter goes a little better.
I’m going to spend my whole career learning to read this spectrum, and that’s fine. The people on my team I’ve coached best so far are the ones I’ve read the moment right with, often enough, that they trust me to give them whichever they need. That trust is the real product of getting this right.