Dear diary, today I learned that
thinking about the business impact can change your definition of “important”
When I was an individual contributor, I was pretty confident I knew what mattered most.
There was a service with spaghetti code that everyone avoided touching. We had a deprecated feature that lived far too long. There were missing pieces in our platform that forced engineers to do manual work. Our infrastructure could’ve been faster, cleaner, cheaper.
These pain points were obvious, concrete, and frustrating. And they felt urgent.
But then I became a lead engineer.
The Bigger Picture
Stepping into this role brought a wave of new conversations: weekly syncs with product managers, strategic planning sessions, deep dives with design. At first, it was overwhelming. But slowly, it started to shape a new perspective.
I began to see that software is just one part of the business. And while the quality and maintainability of the software matter, they’re not always the most impactful thing in a given moment.
What I used to perceive as “important” was often a local maximum. But now I’ve learned to look for the global maximum.
Local vs. Global Maximum
Here’s what I mean:
As an IC, I was frustrated when product managers pushed for new features instead of polishing what was already there. Like when we shipped something that let users create a resource—but didn’t let them delete it. Or when we built an API to return resources but skipped the syncing logic, so engineers had to manually make updates whenever something changed.
It felt wrong. Wasteful. Lazy.
But then I realized something:
Those engineers doing manual updates?
Their time felt expensive.
But skipping the syncing logic allowed us to ship a new feature that closed a €100k ARR deal.
Was it inefficient? Yes.
Was it bad engineering? Arguably.
But was it bad business? Not necessarily.
The Bucket Metaphor
The image that helps me now is a bucket with holes.
As an IC, I was obsessed with plugging the holes. It seemed obvious: water is leaking out, fix it!
But now I see the other side:
- A bucket with holes isn’t a problem if there’s not enough water in it yet
- There are limited taps, and we need to fight for them. Our competitors also have buckets to fill.
Of course, there’s a limit. Let the holes go unpatched for too long, and eventually the bucket can’t hold any water. One of the challenges of leadership is balancing impact and sustainability.
What Really Matters (And When)
I’ve come to accept a few things:
- Tech debt is inevitable. It’s a cost of moving fast. But it’s also a debt—you have to repay it before the interest compounds.
- Customer complaints about “missing” or “incomplete” features might actually be a signal that they love your product enough to care.
- Manual work by engineers is not always waste. It’s sometimes the most cost-effective trade-off at a certain stage of the product lifecycle.
- Business value doesn’t always align with technical elegance.
- Sometimes what feels “important” from inside the codebase… isn’t.
I’m still an engineer and this discoveries were hard to swallow.
Final Thought
Leadership is rarely about fixing everything. It’s about understanding which problems, at what time, are worth solving.
So these days, when I hear myself thinking “we have to fix this,” I pause.
And I ask:
Does this hole matter more than getting more water into the bucket?
Thanks for reading LED — Lead Engineer’s Diary. If this resonated, share it with someone who’s also figuring it out as they go. Find all posts from the series here.
