Focus Is Saying No | Hacker News Reader

Focus Is Saying No

medium.com

94 pointsHideInNews47 comments

> 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.

During a face2face with my n+2, he once told me « manage your manager ». I discovered later that he had been forced to hire my n+1 but did not like him at all. And that the message was basically: « he is a bozo whereas you a competent engineer. Don’t be fooled by the organization chart. »

So sometimes saying no to your n+1 is totally in line with your n+2 :)

I’ve seen a situation like this. The n+2 changed jobs, leaving the employee reporting to an n+1 who now hated them and no n+w to back them up.

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.

By the time a company is that dysfunctional, why bother? Just do the minimum to get paid.

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.

My company is insanely profitable, plagued with bozos as middle managers. But after some years you have your network of righteous fellows, and live with them much more than with your organization chart. So that is not a big deal.

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.

> Just do the minimum to get paid.

Who wants to live like this?

I don't want to live like this. It's miserable, but not as miserable as putting in effort to change a dysfunctional organization that doesn't want to change.

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.

What were the clues, in hindsight?

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.

Conservation of energy is highly selected for biologically.

On a related tangent:

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.

I personally don't think ultimatums are a tool that you should ever employ in an employment situation outside of collective action.

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.

Ever is too strong, but remember the less often you give an ultimatum the more powerful it is when you do. When you have a long standing reputation (must come first) as a 'team player' a sudden ultimatum will get a lot of attention, but it will be years before you can give another.

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)

The ultimate exists whether or not you communicate it. I would hope that with enough tact that truth could be communicated.

The main thing is that if someone isn't going to do something in normal circumstances, an ultimatum is really for yourself to be done with waiting.

Just be careful - some will see it as having their arm twisted. You may get what you want in the short run, but in the long run, when you negotiate with leverage, people dislike that.

It is the nuclear option, and you will lose the trust of your leadership chain.

Sounds like what you are really trying to say is "I want to change teams".

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

> but I don't like my current work and if it doesn't change for the better

I try really hard but never understand where does this belief comes that you have to love your work.

That is part of what I would be politely saying to my boss.

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.

In a similar boat right now. The org is good. So is the culture. The manager is also good. But the work....! Neither learning something nor finding any alignment. Really confused.

Saying "no" can get you into trouble in a hierarchy. There are many ways leading to no without saying "no", such as:

• 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.

The solution is to have a conversation with your manager about the work you want to take on, not to play word games where you pretend to take on a task but don’t do it.

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

If I tell someone to do thing A and they look into it and decide to not do it, the reason better be a whole lot better than I didn’t feel like it or I wouldn’t be promoted if I did that.

> 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.

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.

I think it is a wrong take of what he said. There are many cases when you can say no to small tasks or projects if you can prove they are low value and there are better items on the list. I do that all the time and none of my managers had a problem with it, in the past decade most of my managers let me pick what I want to work on because they know I can prioritize better than they can.

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.

In many occasions, if there's a proposal for something very stupid or pointless I've found it's better to just say "yes", knowing full well the thing will never get done. The manager didn't really want the thing. He wanted a good happy meeting and to hear "yes".

> 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.

[0] https://www.mastercard.com/us/en/news-and-trends/stories/202...

> 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.

Company without a strategy:

[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 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

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.

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.

This is how I read it too. What's more, it looks like they're interested in going senior -> staff; at all Large Tech Companies, senior is a perfectly reasonable "terminal" role for a SWE, and many SWEs don't want to get promoted to staff. (Staff SWE is a different job from senior SWE; you might not want want to do that job, and that's typically fine.)

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.

Managers should figure out plans with their employees. It is too easy for someone focused on one thing to get lost in something that doesn't matter. It is your manager job to stop from doing that.

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.

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.

As a manager you may have 10 people reporting to you. Some do more important work, some do less important work, but when you are considering them for promotions there are other factors too. I am not talking about promotions from junior dev to regular or regular to senior, I am talking about promotions to positions where they are responsible for other people. In my almost 30 years working in IT in multiple companies I found that most good technical people are not good managers; similarly most managers are technically bad. Best managers are the ones that Steve Jobs described in one of his famous interviews (I will leave the pleasure of having him tell it, it is worth spending the 3 minutes).

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.

https://youtu.be/QplyFXgIx7Q?si=zhSSJ5Hcu2hNWZkz

> 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.

These days I am working on some 20 year old code used in a few dozen manufacturing plants around the globe; the reason I asked to be allowed to fix it and the reason my manager allowed me to do it is that we have performance issues in some of the biggest plants (by the number of production lines) and this code is part of the problem. If that would not be the case, that code would continue to run as is for another 10 years.

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.

In some cases it does make sense (imagine something like Voyagers for instance where you simply can't change things even if you wanted to), but in most cases it doesn't.

... as is the company. This has Unicorn Project written all over it.

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.

Reply on news.ycombinator.com