Focus Is Saying No
Key topics
The author reflects on working on low-impact projects, such as updating outdated libraries, and concludes that saying 'no' to non-essential tasks is key to focus; however, the discussion reveals a more nuanced debate around the value of tech debt work and effective communication with managers.
Snapshot generated from the HN discussion
Discussion Activity
Active discussionFirst comment
37m
Peak period
14
2-4h
Avg / period
6.7
Based on 47 loaded comments
Key moments
- 01Story posted
Oct 5, 2025 at 1:08 PM EDT
3 months ago
Step 01 - 02First comment
Oct 5, 2025 at 1:44 PM EDT
37m after posting
Step 02 - 03Peak activity
14 comments in 2-4h
Hottest window of the conversation
Step 03 - 04Latest activity
Oct 6, 2025 at 7:13 AM EDT
3 months ago
Step 04
Generating AI Summary...
Analyzing up to 500 comments to identify key contributors and discussion patterns
Want the full context?
Jump to the original sources
Read the primary article or dive into the live Hacker News thread when you're ready.
> 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.
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.
[0] https://www.mastercard.com/us/en/news-and-trends/stories/202...
> 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 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.
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.
Code modernization in some circumstances does not bring business value. In the plants we have some hardware that is decades old and it works as well as the one built last year, more modern software would bring no difference as physical limits (ex: how many bottles you can fill on a line) makes a line capable to run on a smartphone with MS-DOS and Turbo Pascal on it (we don't use that, of course). If it runs and you cannot improve it more than the cost of the improvement, leave it as is.
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.
So I think the lesson here is wrong too - when the manager said
> These tasks aren’t business priorities and had no impact on customers and other teams
that didn't mean they were worthless tasks - just that they weren't business priorities and had no impact on customers or other teams. Which is probably true(ish - I would have phrased it very differently if I were their manager).
Improving the release process is great, and helps the team a ton - and indirectly helps customers by enabling the team to ship faster. This is incredibly valuable! And at the right scale, it can be a staff job: at my Large Tech Company, I know several people that have been promoted to staff SWE for this kind of work, but it's for systems that hundreds of SWEs work on. I also know people that have been promoted to senior SWE for this kind of work - these are systems that tens of SWEs work on. It sounds like this example was more like that - this person was doing a good senior SWE job, and the manager didn't see any reason to course correct given that they had given no signal they wanted to get promoted.
note that often preventing problems is not rewarded. Putting out a fire you caused is. Good managers will help you explain why this not obviously useful thing is valuable because of the proplem it prevented.
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.
So sometimes saying no to your n+1 is totally in line with your n+2 :)
I mean it. I want to work for a company where everyone is working towards the common goal of making the company profitable. But there comes a point where the company is overrun by politics and selfish and harmful decisions.
By the time dysfunctional company politics empower a "bozo", why should I stress or put any care into such a company? I'll just do the minimum.
Who wants to live like this?
Consider this example: I once worked for a contracting agency and we were on a project that was going really poorly and so I put in some effort to improve things and try to make it better. Things were not improving, people were angry with me. Eventually I learned that the person I was working for wanted me to fail, because he wanted to use a different contracting agency, so he wanted me to fail and look bad to give him an excuse to switch to a different contracting agency. But, then people even higher in the organizations were friends with my contracting agency and so I stayed on the contract and kept doing an honest but minimal amount of work. My boss literally wanted the project to fail.
It's fairly common for organizations to become this screwed up, and yes, it sucks to work for them, but it sucks even more to burn yourself out trying to change them when they don't want to change.
I wonder if someone can get scent of 'want you to fail' early, so one can play their cards a bit differently armed with this knowledge.
But I agree that promotion is not exactly an option, as I would become crazy only surrounded by bozos.
There is also an expert path, for people wanting to be promoted, but for their technical excellence. Guess what? There too, the political tricks have led to empower not so excellent people, i.e bozo-compatible ones.
I’m with the other commenter: If you find yourself in a situation this dysfunctional, you’ve already lost. Blowing off your boss to appease your skip level isn’t guaranteed to work out, even if the skip level likes you.
Either way, that’s not relevant to this blog post. The author said they were just going to say “no” to assigned work, which isn’t going to work out.
Does anyone have any advice on how to politely say "I like the company, I want to stay, but I don't like my current work and if it doesn't change for the better I'm going to leave in 6-months".
I once tried to say this as politely as possible, but I think I might have been too polite and tactful and they didn't understand. I had a date in mind, and had a conversation 6-months, 3-months, and 1-month before I left. When I announced my departure they tried to get me to stay.
You can just leave off the ultimatum and attempt to improve your situation by communicating it in a way that is directly actionable (I'd like to work on X instead of Y, can you arrange that?). You'll have your own internal deadlines of course, but you shouldn't communicate them.
It is the nuclear option, and you will lose the trust of your leadership chain.
if like many you switch jobs every few years you can never develop that reputation needed for an ulimatum in the first place. (Staying for years is never 100% in your power but some jobs have better chances of it)
I try really hard but never understand where does this belief comes that you have to love your work.
The truth is some jobs suck so much that I refuse to do them long term, and other jobs suck but I can do them long term.
I once left a job after I was so stressed I got shingles, I believe it literally would have killed me had I stayed.
Or maybe "I want to work on ____ new project, and my working this would be beneficial to the business because ____". But you have to have a real case for it and for why you are the right person for it
• I'll look into it
• I'll see what I can do
• I'll review that right away
This isn't me saying "say these things", I'm just pointing out this is an age-old problem, and saying "no" inwardly is different than saying it outwardly. Various ways of inquiring about options are also commonplace.
If you say you’ll review something or look into it, you still have to follow through on it. Using those phrases to dodge the work isn’t much different than failing to do the work. It will be noticed
I never saw someone saying no without a reason and if there is a reason, then there is a discussion around it, one can be right or wrong about it but it is usually easy to clarify and move on. It is not the "no" or a spoiled 5 year kid, it is the "no" of an experienced professional that values their time and priorities.
I've had a lot of success in asking "are you asking me to do this or telling me", when I've been tasked with something I think is extremely dumb.
If the response is "I'm asking", then I will usually respond with some variation of "can you assign it to someone else, or better yet, throw the task in the garbage".
If the response is "I'm telling you", then I'll go on a spiel about how I think it's incredibly stupid and the people involved in this decision are bad at their jobs, then get on and do it.
But if you're reading this, there is a good chance you are American, so take this advice with a massive grain of salt as I'm not. The culture here in NZ sounds extremely different to almost everything I've read on this forum.
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.
In any case, there may be others doing more important work and there may be others better suited for promotions. It is a zero sum game, the number of people, positions and promotions is always limited so if X is promoted, Y cannot be and if X is a better one for the promotion, Y will have to either wait, move on or keep doing what they do.
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:
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.