This article is based on a very commonly used but flawed premise that all product-driven work actually delivers value to the business and that tech-driven work doesn't.
This is only really true in the real world for a subset of brand new startups, where none of the low hanging fruit product ideas have been built yet but the "idea" for the business is very good. Tech-driven work doesn't pay off here because of scale. It's not worth working on perf when your total server bills is in the hundreds or thousands of $. It's not worth working on dev exp when you have < 10 developers. You don't need to refactor yet as it's greenfield code anyway and it's easy enough to glob stuff on to support business ideas ... for now.
If you are working on a sufficiently mature product, there is a fairly high chance that the product-driven feature you are about to spend months on will fail to gain any traction and be totally scrapped. Anyone who has 5+ years experience has probably experienced this multiple times, this happens all the time even at "good companies".
This is because all the obvious low-hanging fruit ideas were already built years ago (which is why the business even has any money to employ YOU as a software engineer).
In more established companies you are less likely to deliver value to users but more likely to deliver value to the business by executing on "tech-driven" initiatives. This is because of scale:
- If you work on perf, cutting 10% of server costs is a big deal when you run thousands of them vs. tens of them
- If you work on developer efficiency, improving that for hundreds or thousands of developers is a big deal
- If you refactor to support future changes, preventing forced "big bang" rewrites of large established systems you will save the business millions of $ in salary
This is only really true in the real world for a subset of brand new startups, where none of the low hanging fruit product ideas have been built yet but the "idea" for the business is very good. Tech-driven work doesn't pay off here because of scale. It's not worth working on perf when your total server bills is in the hundreds or thousands of $. It's not worth working on dev exp when you have < 10 developers. You don't need to refactor yet as it's greenfield code anyway and it's easy enough to glob stuff on to support business ideas ... for now.
If you are working on a sufficiently mature product, there is a fairly high chance that the product-driven feature you are about to spend months on will fail to gain any traction and be totally scrapped. Anyone who has 5+ years experience has probably experienced this multiple times, this happens all the time even at "good companies".
This is because all the obvious low-hanging fruit ideas were already built years ago (which is why the business even has any money to employ YOU as a software engineer).
In more established companies you are less likely to deliver value to users but more likely to deliver value to the business by executing on "tech-driven" initiatives. This is because of scale:
- If you work on perf, cutting 10% of server costs is a big deal when you run thousands of them vs. tens of them - If you work on developer efficiency, improving that for hundreds or thousands of developers is a big deal - If you refactor to support future changes, preventing forced "big bang" rewrites of large established systems you will save the business millions of $ in salary