Leadership — The Problem of Helping

The problem of helping

The last post ended on “motivation starts with understanding the person”. And once you do understand them? The most natural impulse in the world shows up: help. They’re stuck, I can see the problem, I’ll step in. This chapter (Ch12–13) is the bucket of cold water: helping is itself the problem — and the more eagerly you help, the easier it is to fall in.

Weinberg’s verdicts on helping get less merciful one by one:

1. Help nobody wants never succeeds — however smart you are, however correct the solution.
2. Effective help starts with both sides agreeing on what the problem is — you think you’re helping with A, they think the problem is B, and your help is just interference.
3. Agreeing to be helped is not a lifetime contract — wanting it this time doesn’t mean wanting it next time; wanting it at the start doesn’t mean wanting it to the end.
4. And the harshest: every act of “helping” also helps the helper — there’s self-interest in every helper, and everyone believes they’re the exception.

The three gates

Stack those verdicts up and you get this: the urge to help has to clear three gates before it becomes actual help — fail any one of them, and it turns into something else:

Gate one stops help nobody wants. Ask before stepping in — actually ask, out loud, instead of deciding “they obviously need it”. And one yes isn’t enough: agreeing to be helped is not a lifetime contract, so when they want to take it back mid-way, let go.

Gate two stops help aimed at the wrong problem. This is the helping version of the no-problem syndrome: the moment they open their mouth you feel “I’ve got it” and rush to the answer, without ever confirming where they’re actually stuck. Effective help starts with both sides agreeing on the problem — one minute spent aligning on “what exactly are you trying to solve” often beats ten minutes of answers.

Gate three stops help that’s really for yourself. This gate is the hardest, because it asks you to admit something uncomfortable: the urge to help has “proving I’m useful” mixed into it — and everyone believes they’re the exception. Weinberg’s advice isn’t to eliminate that ingredient (you can’t); it’s to see it: know how much of this intervention is for them and how much is for your own satisfaction, and the help comes out cleaner.

The most common gate-crash in an engineering team

A junior is stuck. You walk over, see the problem in thirty seconds, and your hands itch: “here, let me.” You take the keyboard and it’s fixed in ten minutes.

All three gates, crashed in one move: they never asked you to take over (gate one); what they wanted was probably “learn to solve this myself next time”, what you solved was “make this code compile sooner” (gate two); and the person who enjoyed those ten minutes most was you, fluently demonstrating how fast you are (gate three). The code works now — but they still can’t do it next time, and they’ve learned one extra thing: get stuck, and someone takes your keyboard away. You thought you were helping. You were confiscating their chance to learn.

Learning to be a motivator: understand yourself first

Ch13 is about becoming a motivator, and its direction is inward: work out what drives you, and what being helped or being motivated feels like to you — because every intuition you have about “why people move” comes from a sample size of one: yourself. Leave that sample unexamined and you’ll fit your own motivation model onto everyone — which is the gentle version of the last post’s “treating people like computers”: treating them as computers of your exact model.

Reflection

What my motivation actually looks like

Let me put my own sample on the table first. Playing LoL recently I noticed something: I would rather play a hard-to-execute, interesting champion and lose than play a boring champion and win. The pick list is honest — I don’t play Malphite, Miss Fortune, or Kai’Sa. I pick Irelia, Draven, Samira.

Take that apart and the difference between the two groups isn’t strength — it’s where the performance ceiling lives. Malphite is the classic press-R-and-you’ve-contributed pick; the champion carries its own floor. Draven has to catch his own axes for the damage to exist, and Samira’s combo system is literally the game grading your execution. In a zero-stakes setting — no performance review, no audience — my preference function shows its true shape: even a win has to be a win I can attribute to myself. Win on Draven and nobody can say the champion carried you; win on Malphite and I can’t prove to myself it was skill at all. It’s exactly isomorphic to A3/B9 from the vision dig: I’m mastery-driven, and results are just the anti-counterfeit label.

Which is Ch13’s first step done: I can now say what drives me — and therefore what will stall me: tasks that are copy-and-done, wins that can’t be attributed, problems with nothing to dig into.

Don’t make a Draven play Malphite

But the step after understanding yourself is admitting other people may be a different model.

Every team has Draven players and Malphite players — some people are driven by “deliver steadily, see a clear win”, and hand them work that needs stable output and they’re fast and at ease; force an open-ended research problem on them and all they feel is anxiety. Flip it around and a mastery-driven person handed SOP work simply stalls. Assigning tasks is picking champions for people — and the most common mistake is a leader picking from their own champion pool for the whole team.

That’s exactly what I have to watch in myself: because I’m the Draven type, my reflex says “a challenging task = a good task” and I hand it out as a reward — but to a Malphite-type teammate that’s not a reward, it’s a punishment. The last post said KPIs measure everyone with the same ruler; defaulting everyone to your own motivation is playing every position on one champion — the same laziness.

Re-reading “I was the clown”

One last pass over the clean architecture incident — I’ve already owned the “judged it before I understood it” part, but hold this chapter’s gates up to it and another layer shows: it was also help nobody asked for.

Nobody invited me to rewrite his architecture — I’d cast myself as “helping the project stay consistent” (gate one, crashed). The problem he was solving was “keep the domain logic from being welded to the ORM”; the problem I was handling was “this looks different from the rest of the code” (gate two, crashed). And being honest now: how much “guardian of the codebase” self-image was mixed into that intervention? Plenty (gate three, crashed). Same incident: btl-7’s mirror showed idea-killing, this one shows fake help — self-appointed help is where ideas get killed: the murder weapon isn’t malice, it’s eagerness.

So the rule I take from this chapter runs on the same line as the last one: before stepping in to help, clear the three gates — do they want it, is it the same problem, and is this for them or for me. Wanting to help is instinct; managing to help is discipline. And the first step of that discipline is the same as every lesson in this series — understand it first. This time, the thing to understand is helping itself.