When Your Work Stops Looking Like “Work”

I remember when I was learning to code someone put into words what a bunch of the junior engineers and I were feeling, which was how crazy it is to spend all day building something and at the end of it just have the same laptop on the desk in front of you. You can’t see what you built, you can’t touch it. It’s hard for the brain to understand that level of abstraction.

Eventually I got used to it. I learned to measure what I built in other, non-physical ways: the tickets I closed, the pull requests I merged, the dashboards I created, the incidents I resolved.

But then I switched into management and had the same feeling all over again.

I knew I was doing the work, but why couldn’t I see it?

I could finish an exhausting day and struggle to point to anything I’d “done.” My calendar was full. Conversations had gone well. A conflict had been resolved before it became an incident. A roadmap had become clearer. None of those things looked like work in the way writing software had.

It took me a while to realize the work hadn’t disappeared. The evidence had.

As an engineer, my work naturally produced things people could point to. Engineering organizations are built to recognize those outputs because so much of their tracking, reporting, and planning depends on them.

Instead of producing software, I was increasingly shaping the conditions under which other people could produce it. I was preventing unnecessary work, clarifying ownership, aligning stakeholders, sequencing priorities. If I did my job well, other people’s work improved.

Engineering creates software. Management changes systems.

Execution leaves evidence. Strategy often doesn’t.

That’s where the transition into management can feel surprisingly disorienting. Execution answers the question, what happened? Strategy answers the question, why did it happen?

Most organizational systems naturally measure the first. Not because strategy isn’t valuable, but because visible outputs are easier to recognize than good judgment.

Performance reviews, promotion packets, and status updates all depend on visible evidence. As a manager, you’re still expected to fill those containers even though more and more of your work happens before anyone else sees the result.

That’s why promotion cycles can feel especially unsettling for new managers. As your work becomes more strategic, it also becomes less naturally visible.

Part of your job becomes making your thinking visible. Not because you’re self-promoting, but because other people can’t act on reasoning they never see.

That’s also why directors often ask different questions than engineers.

I’ve seen countless interactions where engineers become anxious because they’re being asked questions without understanding what senior leadership is actually trying to learn.

Engineers tend to ask: What shipped? What broke? How long did it take?

Directors ask: Why this work? Why now? What didn’t we do?

They’re trying to understand the reasoning behind the execution, because that’s the layer they can use to make future decisions.

Ironically, strategy often becomes visible only when it’s missing.

A dependency wasn’t actually ready. Two teams thought the other owned the migration. A launch slips because a stakeholder constraint surfaced too late.

Suddenly the alignment work everyone took for granted becomes obvious in its absence.

Early in management I kept looking for evidence that I’d done good work. A finished roadmap. A completed project. Something concrete.

Over time I realized I was looking in the wrong place.

Strategy rarely leaves fingerprints.

Sometimes the best work is the project that never slipped, the disagreement that never became conflict, or the dependency that never became an incident.

The work happened.

Your job is to make sure the thinking behind it doesn’t disappear with it.