The Invisible Output
A developer turned manager no longer has code to show for their day. Learning to see what you've actually built — and teaching them to see it too — might be the most important thing you do as their manager.
The first thing a new manager loses is the ability to point at something and say: I made that.
When they were a developer, the feedback loop was tight. They wrote code, the code ran, the feature shipped. There was a diff. A green test. A ticket moving to Done. The work was legible — to themselves, to their team, to anyone who cared to look.
Then they got promoted. And the diff disappeared.
Now their days are made of conversations. One-on-ones. A difficult message delivered carefully. A decision unblocked. A junior engineer who came into a meeting anxious and left with clarity. A conflict that didn’t escalate because someone saw it early.
None of this shows up anywhere. There’s no commit history for culture. No pull request for the thing you prevented.
And so, within months — sometimes weeks — the new manager starts to feel like they’re not doing anything. They look at their old peers still shipping features and feel a creeping sense that they’ve become overhead. Useless. Decorative.
This is how imposter syndrome gets its grip on new managers. Not because they’re failing. But because they haven’t yet learned to see what they’re building.
This is where you come in — the person who manages them.
How you handle a new manager’s first year sets more than their trajectory. It sets the management culture of your entire organization. The way they learn to manage is the way they will teach others to manage. The habits they form now will be inherited by everyone they ever lead.
Most organizations treat this as obvious and skip it entirely. They promote a strong individual contributor, give them a team, and wait to see what happens. What happens, more often than not, is a capable person quietly suffering through an identity crisis while trying not to show it.
The skill they most need — and are least likely to develop without help — is self-assessment.
As a developer, self-assessment was almost automatic. Did the code work? Did you close your tickets? Were you shipping at the pace of your peers? The metrics were ambient. You absorbed them without trying.
As a manager, you have to construct the metrics yourself. And nobody tells you this. Nobody hands you a rubric for is my team healthier than it was three months ago or did I help anyone grow this quarter or am I creating clarity or confusion when I walk into a room.
So they default to the only measure they trust: output. And their output is invisible. So they conclude, quietly, that they have none.
What I’ve found works is making the invisible visible — explicitly, repeatedly, until they can do it themselves.
In practice this means asking different questions in your one-on-ones. Not just what are you working on but what did you unblock this week, what decision did you make that your team didn’t have to make, where did you absorb uncertainty so your team could move forward.
It means helping them build a personal log — not a performance document, not something they share — just a private record of the moments that mattered. The conversation that changed something. The hire they almost got wrong and didn’t. The thing they noticed before it became a problem.
Over time, the log becomes evidence. Evidence against the voice that says nothing is happening.
The new managers who come out of their first year well are rarely the ones who figured it all out on their own. They’re the ones who had someone — a manager, a mentor, someone who’d been through it — say plainly: the work you’re doing is real, it just looks different now, and here’s how to see it.
That’s not a soft thing to tell someone. That’s one of the most load-bearing conversations you can have.
The culture you build is made of those conversations.