The Invisible Column: What Three Years of Patience Actually Cost My Team

The day I hired him, I wrote a line in the onboarding doc: This one, I’m willing to invest time in.

His first commit was an interface for a backend permissions check. I did the code review and flagged seven things that needed fixing. After each comment, I attached a short snippet of demo code — spelled out why the conditions should be split that way, why that exception shouldn’t be swallowed. He replied, “Got it, Zhou. I’ll fix it.”

He turned in the changes the following week. Seven issues. Four and a half fixed.

I didn’t say anything. I just added three new comments.

Back then I figured, everyone needs a ramp‑up period. I gave myself a deadline: three months. As long as he could handle a small feature on his own by then.

Three months came. He was assigned an export‑report feature, end to end. The night it went live, ops called me: one of the pagination parameters had no boundary check. As soon as the data set got large, the CPU spiked to a hundred percent. I ran to the study in my slippers, restarted the service, and messaged him at the same time. He wrote back, “Oh, I didn’t think that parameter could get that big.”

You couldn’t just put a limit on it? I typed that into the chat box, then deleted it. Replaced it with: “Tomorrow let’s add a unit test for the parameter validation together.”

When things like that kept happening, I started keeping an invisible column for him in my own weekly report. That column had no heading, but I knew what it was: bail‑out time.

A year and a half in, we were adding a feature‑flag rollout to a core service. I put him in charge of one module. During the design review, right after he finished presenting his deck, I asked in front of everyone, “If the config center push fails, what’s the rollback strategy?” He paused for a beat and said, “It shouldn’t fail, right?”

No one in the room said a word. I said, “Alright. I’ll write up the exception‑handling design and send it out tonight.”

I worked on that design until one‑thirty that night. When I closed the laptop, my stomach started hurting again. I went to the living room to find the stomach medicine and noticed the pothos on the coffee table was wilting a little. I gave it a cup of water, almost without thinking. That was the moment a thought surfaced: He’s probably never going to be the person who thinks about the “what if.”

But I still didn’t make a decision. I told myself: Give it one more quarter.

The thing that finally broke me was today, July 12, a Sunday. I’d planned to take my daughter to her swimming lesson. Instead, at ten in the morning, I was online chasing a discrepancy in the payment reconciliation. I eventually traced it back to an order‑status sync he’d written ages ago. In a specific timeout‑retry scenario, it would overwrite “Payment Successful” with “Timed Out, Unpaid.” He hadn’t written a single line of error‑logging in that block of code.

I fixed the bug, pushed the commit, and stared at the commit history on the screen for a long time. Then I opened his WeCom chat window, typed a few words, and deleted them. I closed the chat, opened a new document, and typed four words into the title: Exit Assessment.

It was three in the afternoon by then. My daughter poked her head around the doorframe. “Daddy, are we still going?”

“We’re going. Give me three minutes.”

I shut the laptop, stood up, and grabbed the car keys. At the front door, I turned around, went back to the drawer, pulled out that box of stomach medicine, and dropped it into my bag.

The offboarding process was completed by the end of that month. On his last day, he rolled up the keyboard skin from his desk, put it into his backpack, and said, “Zhou, thank you for everything you taught me.”

I nodded. I didn’t say much more.

After that, I did two things.

First, I went through the CODEOWNERS file for every project the team owned. For all modules that required cross‑review, I added a mandatory rule: At least two reviewers required.

Second, for every new hire, at the end of their first week, I now open a separate page in Feishu Docs. The title is “Growth Watch.” On that page, there’s a line in red:

Observation period: three months. If the independent‑delivery rate is below 70% at the end of three months, I will schedule a face‑to‑face conversation.

At the very bottom of that doc, I added one more line, in small text. Visible only to me:

Not everyone can be developed. But that sentence shouldn’t wait until year three to be said out loud.