There’s this moment… and I think a lot of senior engineers hit it eventually… where the most impactful thing you do all week is a 30-minute conversation. Not a PR, not a deployment, just a conversation. And at the end of the day you look back and think, “…did I even do anything today?”

That feeling sucks. And I think it’s worth talking about.

The feedback loop that built you

For years, “a good day” was simple. PRs were merged. Bugs were squashed. Features were shipped. The feedback loop was tight and satisfying… write code, push it, see results. You get recognized because you’re the person who solves the hard problems. You build your whole professional identity around that.

And honestly, it trains your brain. Commits are evidence and velocity is proof. If someone asks, “What did you do this week?” you can just point to the diff. That loop becomes more than a habit… it becomes how you measure your own worth.

Then the work changes

At some point… and the timing is different for everybody… the stuff that matters most stops looking like code.

I’ve started thinking about it as first-order vs second-order output. First-order is “I shipped it.” Second-order is “the team ships better because of something I did.” And the gap between these two is where all the discomfort lives.

Like… the difference between “I fixed the performance issue” and “I shaped the architecture so that class of performance issue is less likely to happen.” Or the difference between “I reviewed the PR and left comments” and “I mentored the engineer so their next PR doesn’t need those comments.”

The second versions are obviously more impactful. The problem is they’re basically invisible on a day-to-day basis. You can’t point to a diff. The impact is real, but it’s spread out across other people’s work and distributed over time. So it doesn’t feel like you did anything.

The identity thing

I initially wanted to call this imposter syndrome, but I don’t think this is imposter syndrome exactly (though I know that feeling pretty well… I talked about it in my engineering culture post). This is more of an identity crisis.

You spend years… maybe a decade or more… training yourself to value technical output. Then the work shifts and suddenly the most impactful thing you do in a week is a design conversation that saves three sprints of work going in the wrong direction. Or a mentorship session. Or an RFC review that catches a scaling issue before anyone builds it. Or documentation that kills an entire category of onboarding questions.

None of that shows up in your git log.

And the voice in your head goes: Am I still earning my seat? Am I resting and vesting? That voice is loud. And it’s wrong… but it’s using evidence you spent your whole career training yourself to trust. So it’s really hard to ignore.

Recalibrating

So what do you do? You rebuild your definition of a productive day. Which sounds simple, but isn’t.

I’ve been trying to watch for different signals:

• Did someone make a better decision because of a conversation with me?
• Did a design review prevent rework that would’ve shown up two sprints from now?
• Did my team pick up a pattern that reduced friction?
• Did someone I’ve been working with handle something they couldn’t have three months ago?

The frustrating part is these are all lagging indicators. You don’t see them the day they happen. Sometimes not for weeks. You just gotta get comfortable doing the work and trusting that it matters… which is genuinely hard when your entire career has been about same-day feedback.

The temptation to retreat

When the ambiguity gets uncomfortable, the temptation is to just drop back into heads-down coding mode. “Let me just hammer out this feature real quick”… and it feels productive because it is. At the level you used to operate at.

But here’s the thing… every hour you spend doing work that someone else on the team could do is an hour you’re not doing work that they need you to do. The team doesn’t always need another pair of hands writing code. They need someone at the layer above… seeing patterns, shaping direction, unblocking the blockers.

That doesn’t mean you stop coding. It just means you code with intent, not for comfort. There’s a real difference between writing code because it’s the highest-leverage thing right now and writing code because it’s the most familiar way to feel useful. Be honest with yourself about which one it is.

What’s helped me

I’m still very much figuring this out, but a few things have made a difference.

Write it down. Keep a running log of your second-order contributions. Not for performance reviews… for your own sanity. When the “did I do anything today?” voice kicks in, go check the log. It helps more than you’d think.

Reframe your calendar. Meetings aren’t overhead at this point. A lot of them are the work now. That architecture review, that 1:1, that cross-team alignment session… that’s not keeping you from the work. That is the work.

Build your own feedback loop. Code used to hand you feedback automatically. Now you gotta build one yourself. Follow up on your architectural decisions. Check in on people you’ve mentored (you’ve established lieutenants right?). See if the patterns you pushed for actually reduced the friction you expected.

Talk to people who’ve been through it. The identity crisis thing is surprisingly common at this level. Just knowing that helps.

The uncomfortable truth

Here’s the thing I keep coming back to: AI is about to make first-order output dramatically cheaper. Code generation, boilerplate, even non-trivial implementation… the cost of producing that work is dropping fast (it’s made me feel productive again too lol).

Which means the gap between first-order and second-order value is only going to widen. The ability to shape direction, mentor people, design systems that actually scale, make good architectural bets… that stuff gets harder to automate, not easier.

So if you’re in the middle of this shift and feeling like you’re not doing enough (even though your calendar is totally booked)… that discomfort is a signal you’re operating in the right zone. The old definition of productivity was never wrong, it just stopped being sufficient for what you’re being asked to do. So lean into the discomfort and re-evaluate what you consider productive.

Anyway. See ya!