You can know a codebase perfectly and still be replaceable.
I say that gently, because it took me a long time to understand it.
Early on I measured myself entirely on technical depth. I knew where everything lived, why the odd bits were odd, which service would break if you looked at it wrong.
What I could not tell you was how the company made money.
I did not know which customers mattered most. I did not know what the sales team promised. I had no idea which of the features I maintained were actually used.
So every decision I made was a coin flip dressed up as engineering judgment.
The engineers around me who seemed to always pick the right thing to work on were not smarter. They just knew something I did not.
They knew what the business was trying to do.
Once you know that, half your hard technical questions answer themselves. Should we invest in this refactor. Is this edge case worth handling. Do we need it perfect or do we need it Thursday.
Those are business questions wearing technical clothes.
Learning this is not complicated and nobody will assign it to you.
Ask your manager how the team is measured. Ask what happens to the number if you succeed this quarter.
Sit in on a sales call if anyone will let you. Read the support tickets for a week. Find out what customers actually complain about, which is almost never what you assumed.
Learn the name of the metric your leadership talks about, and understand what moves it.
None of this makes you less of an engineer. It makes your engineering land.
And it changes how people see you. The person who says this will save us two weeks of support load gets listened to differently than the person who says this code is ugly, even when they are describing the same fix.
Your technical skill is the price of entry.
Knowing what the work is for is what makes it matter.
– Asael Shinder
Top comments (0)