> Now if my manager asks me to do tasks that I believe add no value to the team or business, I’ll politely say no.
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.
> 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.
Seems pretty awful that the manager let him work on software upgrades for two years without telling him that work would not lead to the promotion he was clearly planning on.
> without telling him that work would not lead to the promotion he was clearly planning on.
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.
A lot of words , and not as direct as they could be, to say "work on what is going to advance your personal goals."
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.
> These tasks aren’t business priorities and had no impact on customers and other teams
...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.
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.
> Now if my manager asks me to do tasks that I believe add no value to the team or business, I’ll politely say no.
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.
> 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.
Seems pretty awful that the manager let him work on software upgrades for two years without telling him that work would not lead to the promotion he was clearly planning on.
> without telling him that work would not lead to the promotion he was clearly planning on.
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.
A lot of words , and not as direct as they could be, to say "work on what is going to advance your personal goals."
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.
> These tasks aren’t business priorities and had no impact on customers and other teams
...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.
> Because… some lack business value
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.
... as is the company. This has Unicorn Project written all over it.