> 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.
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.
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.
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.
> 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.
Nice post, really relatable. It also feels like a management miss. If someone spends years modernizing and only finds out later it “doesn’t count,” that should have been clarified early on.
Tech debt work absolutely adds value, it just rarely gets measured or recognized. Maybe that is one reason so many companies struggle over time, they keep skipping payments on their tech debt interest.
If you're waiting for your manager to tell you "do X" before saying, "no, I won't do X, it's not valuable" you are still way behind for high-level promotions even on an individual-contributor track.
Figure out what is important to the business - and specifically, what's important to the business under you're manager's area of responsibility. Figure out and clearly articulate why. Sometimes this will be modernization (especially if there are ongoing costly outage, downtime, or compliance issues), sometimes it will be features (if your customers, stakeholders, and other devs aren't having big issues from tech debt. Proactively propose this to your manager, work collaboratively to build the roadmap. Your manager rarely has enough time to deep into the weeds on prioritization from a technical POV, so your input will be appreciated as long as (a) it's actually in line with business priorities in a way relevant to your manager, and (b) your manager isn't a paranoid psychopath who thinks you're undermining them or coming for their job.
But if your manager is a paranoid psychopath you've got bigger problems and you're not gonna finesse your way around them by declining tasks either.
You should also communicate your career goals and expectations - this might help you figure out "is my manager a psychopath" earlier rather than later too. A strong manager would've stopped you from spinning your wheels much earlier, in this scenario; but even a meh manager can help you climb the ladder if you're collaborative. Especially if they start to feel like you're key to their success too.
> 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.
It's all nice and good until you're stuck with an EOL version of Spring, migrating to something newer is a gargantuan task that's measured in months so ofc nobody does it and as a consequence the project startup is slow and it eats resources, some libraries are incompatible and there are bugs that will not get solved and CVEs just pile up. Whereas if you update things constantly (or at least monthly), the deltas and breakages between any two states of the system and its dependencies will be way easier to manage.
You can prioritize what and who should do what, but I don't think you can categorically describe certain work as below someone, if they're good at it (assuming nothing urgent elsewhere) and it has a positive impact.
> “You’re doing great work,” my manager replied calmly. “But I have to stack-rank the team, and those tasks aren’t staff-level. Because… some lack business value. These tasks aren’t business priorities and had no impact on customers and other teams. Also, at the staff level, you need to work across teams, influence broader decisions, and build visibility beyond just our team.”
At that point:
* if it's not a golden handcuffs situation, might be easier to find another company to prosper in
* if it is, then yeah, you have to play their game if you care about promotions
* or just do good work where you're at, no matter what their myopic incentives say
10 comments
[ 3.2 ms ] story [ 28.3 ms ] thread> 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.
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.
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.
Tech debt work absolutely adds value, it just rarely gets measured or recognized. Maybe that is one reason so many companies struggle over time, they keep skipping payments on their tech debt interest.
Figure out what is important to the business - and specifically, what's important to the business under you're manager's area of responsibility. Figure out and clearly articulate why. Sometimes this will be modernization (especially if there are ongoing costly outage, downtime, or compliance issues), sometimes it will be features (if your customers, stakeholders, and other devs aren't having big issues from tech debt. Proactively propose this to your manager, work collaboratively to build the roadmap. Your manager rarely has enough time to deep into the weeds on prioritization from a technical POV, so your input will be appreciated as long as (a) it's actually in line with business priorities in a way relevant to your manager, and (b) your manager isn't a paranoid psychopath who thinks you're undermining them or coming for their job.
But if your manager is a paranoid psychopath you've got bigger problems and you're not gonna finesse your way around them by declining tasks either.
You should also communicate your career goals and expectations - this might help you figure out "is my manager a psychopath" earlier rather than later too. A strong manager would've stopped you from spinning your wheels much earlier, in this scenario; but even a meh manager can help you climb the ladder if you're collaborative. Especially if they start to feel like you're key to their success too.
[Phone rings]
Employee thinks: “Oh-oh… What should I do?”
Company with a strategy:
Employee says on the phone: “We don’t do that”
— Build a Better Life by Stealing Office Supplies: Dogbert's Big Book of Business, Scott Adams, 1991
It's all nice and good until you're stuck with an EOL version of Spring, migrating to something newer is a gargantuan task that's measured in months so ofc nobody does it and as a consequence the project startup is slow and it eats resources, some libraries are incompatible and there are bugs that will not get solved and CVEs just pile up. Whereas if you update things constantly (or at least monthly), the deltas and breakages between any two states of the system and its dependencies will be way easier to manage.
You can prioritize what and who should do what, but I don't think you can categorically describe certain work as below someone, if they're good at it (assuming nothing urgent elsewhere) and it has a positive impact.
> “You’re doing great work,” my manager replied calmly. “But I have to stack-rank the team, and those tasks aren’t staff-level. Because… some lack business value. These tasks aren’t business priorities and had no impact on customers and other teams. Also, at the staff level, you need to work across teams, influence broader decisions, and build visibility beyond just our team.”
At that point: