From code quality to business impact
Someone said something in a meeting that reorganized how I think about my job: focus on making the business better, not on building software. Building software is just a tool.
It sounds obvious written down. It is not how most engineers actually operate, myself included for years. It is easy to get trapped in a builder identity, measuring yourself by features shipped and how elegant the architecture is. None of that matters if it does not move things forward.
The progression
Looking back, my career has been a slow expansion of what I consider mine to own.
- I build this component. Early on, the unit of work was a piece. A form, a table, a screen.
- I build this feature. Later, I owned a whole feature end to end, from the database to the pixels. That changed how I thought about software more than any single technical skill.
- I build this system. Then the unit became an entire platform: how the parts fit, how it is deployed, how it holds up in production.
- I make the business better. This is the next one, and it is not technical at all. It is owning the outcome.
Each step widened the boundary. The final step widens it past code entirely.
What it changes
The questions you optimize for change with the altitude.
Before: How well did I build this? How clean is it? How clever is the architecture?
After: Did this solve the problem? Did it move the needle? Was building software even the right tool for this?
This also quietly resolves the anxiety about AI. If depth of understanding is the only thing I measure, then a tool that writes code for me feels like a threat to my identity. If impact is what I measure, the tool is just leverage. Deep understanding still matters enormously, but as a means, not as the scoreboard.
I am not all the way here yet. I still feel the pull to admire a clean abstraction for its own sake. But the direction is clear, and it is the right one. The craft is in service of the outcome, not the other way around.