Letting other suns shine

Eleven days into being a manager, I saw a critical bug in my team's code in thirty seconds. Holding my tongue took ninety minutes. This is what I'm learning to trade for that silence.

6 min read
  • management
  • career
  • craft
  • letting-go

It’s Monday, 10:14 AM in Bandung. I’ve been a manager for eleven days. I’ve just opened a pull request from one of my engineers — someone I trust, someone technically sharp — and I can see the bug in thirty seconds.

It’s a critical one. The kind that would take production down under the right load. Thirty seconds to spot. Maybe ninety seconds to explain the fix.

I don’t say anything.

I close the tab. I stand up, walk to the coffee machine, make a coffee I don’t want. When I come back, the PR is still open. I still know what’s wrong. I still know how to fix it.

I type three words into the comment box: “Have you considered…”

I delete them.

The promotion came through a week and a half ago. More managerial, less hands-on. Everyone said congratulations. What nobody said was this: the hardest part of becoming a manager isn’t learning to manage. It’s learning to shut up.

Two paths from the same pull request: a fast IC path where the manager commits the fix in ten minutes, and a slower manager path where the team reviews, asks questions, and the author finds the bug in two days — catching three adjacent issues along the way.
Two paths out of the same PR. The fast one ships in ten minutes and teaches nothing. The slower one teaches the whole team.

What I used to do

Two weeks ago I would have opened the PR, seen the bug, written the patch, committed it, tagged the engineer with a short explanation, and moved on. That’s what made me good at the IC job. I could see things fast. I could fix them faster. I could explain the fix in one paragraph.

My team knew this about me. They were comfortable with it. Some were a little too comfortable.

Here’s the thing I’m slowly understanding: the speed wasn’t the feature. The learning was. Every time I found the bug and shipped the fix, I got sharper. My team saw the fix and copied the pattern — but they didn’t earn it. They borrowed it. And borrowed skill doesn’t compound.

The critical bug I’m looking at right now isn’t there because my team is bad. They’re good. It’s there because they haven’t yet developed the specific instinct that sees it. And the only way to develop that instinct is to ship code that almost has it, watch it nearly fail, and remember what that felt like.

If I fix it, they never get that memory.

Why I had to stop

I read The Manager’s Path by Camille Fournier before I took the role. It prepared me for most things. It did not prepare me for how physically uncomfortable it feels to see a bug and not touch it.

Liz Wiseman’s Multipliers has a frame for this that I keep returning to. She separates managers into Multipliers — who extract more intelligence from their team than they could alone — and Diminishers, who treat their team as extensions of their own capacity. The tricky part: most Diminishers don’t think they’re Diminishers. They think they’re being helpful.

The bug I saw in thirty seconds is a Diminisher moment waiting to happen. If I jump in, I’ve told the engineer, without saying so: “I don’t trust you to find this. I don’t trust you to fail and recover.” I’ve shortened the feedback loop — and also shortened her growth.

Andy Grove put it in High Output Management as task-relevant maturity: your management style should match the specific team member’s experience with the specific task. The harder I worked to apply that frame, the clearer the answer got for this one. She’s shipped code like this four or five times. She has task-relevant maturity. My job is to stay out of her way and let the review process do its work.

What actually helped me stop

The books help. The philosophy helps. What actually got me through 10:14 AM with my finger twitching near the “Comment” button was smaller and more physical:

  1. Ask before telling. Even when I knew the answer, I phrased the review as a question. “What happens when two users submit within the same second?” instead of “This will race.” The question invited her to find it. Most of the time, she did.
  2. Give the bug one life to live. I let small issues I would have caught go through, watched what happened, and circled back in retro. “Remember this one? Let’s look at why it slipped.” The bug taught better than I could.
  3. Write the advice down instead of saying it. Every urge to intervene went into a note file I kept called things I wanted to say but didn’t. Half of them turned out not to matter. The other half became coaching moments later, when the timing was right.

None of these are clever. They’re all slower than just fixing the thing. Slower is the point.

The critical bug in that PR? I let it ride. We caught a version of it two days later when another reviewer flagged a different concern that led her back to the race condition. Two days instead of ten minutes — the math looks terrible written down.

In those two days, she also figured out three other things about the service that I hadn’t noticed. Including one I was wrong about.

That’s the trade I’m learning. I give up the fast path. I get back a team whose understanding of the system is growing faster than mine is.

Other suns

There’s a phrase I’ve been carrying around, from a note I wrote to myself last week: Sebagai manager saya harus bisa membiarkan matahari lain bersinar. As a manager, I have to let other suns shine. The English translation flattens it — the Indonesian is quieter, kinder. My engineers aren’t moons reflecting my light. They’re their own suns. My job is not to shine brighter. My job is to stop blocking them.

Michael Lopp writes about this transition in his Rands in Repose essays and in Managing Humans. He says the thing that separates good managers from great ones is whether they can still feel the satisfaction of someone else’s ship. I’m not there yet. I still feel twitches of I could have done that faster. But twitches are better than interventions. Twitches you can sit with.

The old craft was making the thing. The new craft is making the people who make the thing. Both are real. Both compound. The second one compounds differently — it doesn’t show up in your commits, it shows up in the slow widening of what your team can do without you.

I started this post by saying the hardest part is learning to shut up. That’s true, but it’s not complete. The harder part is learning to shut up in a way that doesn’t read as absence. I’m still figuring that one out.

Eleven days in

It’s still Monday, 10:14 AM. The PR is still open. The engineer has added a new commit. I scroll down.

She’s found the bug.

Her comment on her own commit: “Race condition — thanks for the review question, it made me look twice.”

I didn’t catch it. The review question I asked was adjacent to the bug, not on it. She caught it because she went looking.

I close the tab. I make another coffee I don’t want.

This one tastes better.