Very dumb response to the code modernization work. Just because it's not a product feature, it absolutely doesn't mean it has no business value.
I also completely disagree that the lesson from it is saying no to such efforts. Increasing tech debt in the name of "more business value" is the worst idea any team can have.
If team leadership sees no value in such work, the team is set to fail.
If you are a careerist and working on your boss's pet projects is going to advance that, then say yes whether or not they have "business value." (If they aren't though, then work on something else.)
If you are an early employee / significant shareholder, then absolutely do what has "business value" and nothing else. That could be boring library updates or it could be something else.
...the author has reached the wrong conclusion from this. The problem is they weren't able to articulate why the modernization tasks were business priorities, not that the modernization wasn't a business priority in the first place.
If the tech debt is problematic, fixing it will presumably bring a number of benefits (faster development cycles, reduced defect rates, etc). They were doing the wrong work - they were doing a terrible job explaining why that work was necessary.
In many ways, tech debt and modernization is a near guaranteed way to have business impact, in a way product work is not. If you're at Meta and you figure out how to save 1% of total CPU time on the server by fixing some tech debt you can expect to be showered with money.
The way I read it, he waited two years to express his desire to pursue promotion.
The manager saw the topic as a starting point for the promotion discussion and tried to explain what steps to take to get there.
The employee saw the discussion as the end point of his unrevealed promotion quest and was surprised that his history alone was not aligned with promotion exportations.
This all could have been clarified with a simple conversation 1-2 years ago expressing intent to pursue promotion and asking what it would take to get there.
This is the wrong lesson to take from this situation.
If you start saying no to tasks assigned by your manager, you are not going to get promoted. You’re going to end up on PIP track for insubordination.
The appropriate response is to communicate. The OP arrived in this situation because they didn’t communicate anything about promotion expectations for two years. Discuss your desire to take on more important tasks in those 1 on 1 meetings and do it early. The fatal mistake in this blog post was waiting two long years before revealing the desire to pursue promotion, then being surprised that past performance did not meet expectations for something that was never discussed. You need to be periodically asking for feedback.
A perfect manager would have brought up the question and asked if promotion was a goal earlier on. However, in my experience this conversation is a lot more contentious than I assumed as some people prefer to be comfortable in their role and interpret unprompted promotion discussions as uninvited pressure or a subtle threat that it’s “up or out”. As an employee, you can’t wait around for your manager to bring up topics you want to discuss. You have to state your goals and ask for alignment.
randunel•1h ago
> 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.
adrianmsmith•1h ago
> 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.
darth_avocado•1h ago