> Looking back, I realized I had worked on a lot of low-impact projects — tasks that made no impact on users and no impact on the team, like updating outdated libraries. The old library worked fine without any updates. Updating it took weeks of my time but delivered zero value to the team or business. I did it simply because my manager told me to.
> Early in my career, I said “yes” often. As I got more experience, I learned when to say “no.”
-----
I'd hate to be the one who refused updating the libraries which caused the security breach and significant loss of data, reputation and money.
Then again, this person's job is to focus on their career. Their manager told them
> Because… some lack business value. These tasks aren’t business priorities and had no impact on customers and other teams
So if those "some" include upgrades, then I would say it's rational for the employee to focus on tasks that are going to get them a promotion.
I don't agree with that myself, I agree with you that upgrades are important, but this person is going to get a promotion through doing whatever their manager wants, and that apparently doesn't include upgrades.
The unfortunate reality of “creating impact” is that visible features in product teams will always be measured higher as compared to work that has 2nd or 3rd order effects that are hard to quantify.
What company has ever been seriously harmed by a security breach?
I'm clearly a bit nihilistic, but I've never seen a case where it matters. If a company leaks the information of millions of people there is, at most, a small financial cost and stock prices keeps going up.
Maybe that's true once companies are too big to fail or avoid. But small companies may face existential risk [0]. Even big companies like Sony can lose a lot of money despite recovering in the long term.
> I'd hate to be the one who refused updating the libraries which caused the security breach and significant loss of data, reputation and money.
The trick is to be working on a different project when that happens. Then it's someone else's fault.
Basically, your career advancement can be slow (if you do the technical work that is necessary to prevent problems, but "has no business value" from the perspective of the management) or fast (if you outrun the problems), but there is no medium speed. If you want a career, you need to commit to it fully.
> Early in my career, I said “yes” often. As I got more experience, I learned when to say “no.”
-----
I'd hate to be the one who refused updating the libraries which caused the security breach and significant loss of data, reputation and money.