Ask HN: Developers – How did you learn to say NO?

You have a horrible PM if that person is tossing extra work at you. Your PM should be tracking your time to your goals and know if you are on track or behind. If you are ahead they should be able to add work if needed.

Anyone else that asks you to do something should go through the PM. Its up to your PM to decide if that work should be done before your sprint work is done.

So tell people to talk to your PM. If that person has no idea how to be a PM then its time to talk to your boss to find a real one

I have a hard time saying no myself.

But hey, for the big cases, you can always go back to the person and say, "sorry, but it's not really going to work. I didn't take into account _____." If they're mad, they're mad. It's like a breakup--it's not ideal, but people change their minds about things, and everyone has to make the best of it.

Sometimes, it's like a marriage proposal to in a public venue. It's hard to say no, but later on, you get to examine your feelings, and you have to eventually make a decision that's true to yourself.

The small cases have to be practice for the big cases.

Eventually, with experience, you'll start to see the patterns, but for now, just do what's best for yourself (which may include following through with the yes).

I think the realisation comes that a good, experienced programmer doesn't say, when asked to do something, "Yep, it'll be easy!". Instead he demurs and says, "That could be a lot of work, it would be irresponsible for me to commit to it."

I'm not the first person to say Agile is perfect, but Agile fixes this. "These are my tasks for this sprint. If you want me to do that task, we have to have a meeting to find out what I wont have time for".

I just said no one day.

It got easier the day after that, and easier still the day after that.

You just say no man, it's that simple. Then you follow up with the reason.. (no, because I have a deadline for X project, and X gets delayed, we'll make less money..do you wanna make less money?) They hired you, so they trust you.

Obviously if you don't have a reason for your no, then you have to go with the yes. As a manager, I'd rather get a no instead of a 'yes' that ends up fucking up everything later because I wasn't aware of something.

Start asking "why?" then practice saying no, or "ask me tomorrow". Its like any other habit; hard to quit cold turkey.

Saying "Yes" to one thing equals saying "No" to other things. Make the cost of the Yes-Es explicit and have the requesting parties prioritize whenever possible (or request prioritization from the decision makers).

For the PM and boss: "to attend to this new task, I'll have to postpone these other tasks which you asked me to do. Which one is more important?" + paper trail + "this week we focused on Y and are pushing X one week" in status reports.

For the peers and subordinates: if the request is legitimate, discuss, brainstorm, "Here's how I'd approach finding a solution, try it and check in when you find a few possibilities. Google and SO are your friends."

And, for subordinates: teach them to think for themselves and to lead

https://m.youtube.com/watch?v=psAXMqxwol8

Of course sometimes you'll have to put out a fire. But if it's a small fire then you should be training your firemen on it.

I'd tell the manager that I was overbooked (which I normally was), would list the activities, and ask him what should be cut.

It's not hard, and if you cultivate a track record of delivering on your word, he'll appreciate it.

If you say yes to things you cannot deliver, when you don't, he won't respect your judgment.

"Mastery can only be achieved through practice."

Try saying no to smaller things first.

Also, to get over the natural (for many people) social anxiety involved in saying no, try saying it a different way. Example: "Okay, I'd love to do this. Help me prioritize here, though. I've presently got to do X,Y, and Z. I can't do a good job with all 4 and stay on time. Should I cut X? Wait to tackle this? What do you think is best?"

Eventually you'll work up to speaking up and creating preventative measures. Eg "if we're going to frequently face interrupt-driven task priorities, we need to move to some Kanban-like and also give up on concrete milestones."

But yeah.. just start trying. Practice makes perfect. As long as your not a jerk about it and take care to explain yourself and not make a requester feel dismissed, nobody will hold saying no against you. (Unless you're just not as productive as others, or unless it's a crappy environment/culture, in which case you should bail if you can.)

OT but I'd be more curious to know how you handle things when you've done it "right". Said yes to this, no to that. You're booked with an abundance of time.

Then you hit a snag in a project and what you thought was going to take a few days ends up taking weeks. Then more weeks because of more unforseen issues.

Sure you could've researched things to death from the start but there were hidden gremlins you couldn't have seen until you were knee-deep in either research or development.

What then? You're going to blow your deadline and that'll cascade to other work scheduled after your current workload.

A client who knew nothing about programming whatsoever, much less the intricacies of programming languages, wanted my brother and I to build the stupid app they wanted in Ruby on Rails. We explained to them we don't know Ruby on Rails and doing it in that language would take us 4x longer because we'd have to learn both a language and framework as we were building the app.

"Nope, it has to be Ruby on Rails. Oh, and some firm in San Jose will do it $10K cheaper than your quote."

Fired the client, told them to go to San Jose.

As a manager (of managers), I keep reminding my team that if I'm delegating more than they can deal with then to let me know. Personally I admire someone that speaks up and says they're at capacity - it shows self awareness as well as the ability to ask for help.

All in all: asking for help is a good thing!

Interesting that is is a problem for people.

If anything, myself and the rest of our dev team have a problem with saying NO too often - an opportunity for us is to say either NO in a more productive way (as in, propose a compromise) or learn to be more ambitious and say YES.

Last time when i work, everybody yes to do extra work in my team in non working hour( sometimes 9 pm sometimes 3 am ?). And the boss blame me because not align with the team. Been fired because of it. And i dam happy because i can arrange my life back. Please said no , for non payment working hour.

By immediately following it with the word "problem"

I didn't have to, eventually.

Contracting means I just tell them how much it would cost them. It's a remarkably effective filter.

In my younger days I did find myself up at 3am regularly, not having eaten an evening meal with a boss literally sat behind me trying to make me code more. I'd come in the next day and have to undo loads of stuff, it just wasn't effective. One day he proudly announced that he saw his job as keeping salaried programmers in the office as long as possible.

Somehow it got a lot easier after that.

Learn not to answer in the moment, and commit to always give yourself time to think alone about the request and respond in 24 hours.

When you do that, you remove the immediate pressure to please the person with a YES answer.

You also give the (honest) impression that your answer has thought and weight behind it, and is the measured response of a professional.

You don't have to say no... Talk to whoever you report to, tell them the things you are working on and align your goals with theirs and prioritize what you should be working on.

When people ask you to do something, tell them where it will fall in your priority list and ask them if they would still like you to come back to them at that point.

I general this works for me, I have product managers come and ask me if I can work out a feature, I say, 'Yeah, I can do that, but i'll have to put off x in order to get to it... is this task more important than x?'

Also, in a similar but different note, at one point as a team lead, I did say no to a project which I felt didn't make sense for our company. It immediately went back up the ladder and turned into career growth for me. So there can be incentive for saying no also!

I seldom say no, I say "Yeh I can do that it might take so and so, I'm doing this at the moment, do you want me to put that on hold?" - if they're for the same person. If they're for different people then - "Yah I can do that, I'm doing this for fred at the moment, so have a talk to him if you like" (or to who ever else pays the bills). Seems to work. If it's a client, "I'll add it to the list and talk to (whoever's in charge) and see when we can do it for you". It gives an idea that there's a list and things are getting done as an added bonus.

Find agreement on priorities with short meetings on a regular basis. This can be done in a structured as part of Agile, or just as regular meetings to get everyone on the same page.

The approach I take is that I don't care what the order of the list should be (save for dependencies), so I give collective control over that to other stakeholders.

If someone then comes to me a few days later with an "urgent" request that will take a non-trivial amount of time, I simply put the pressure back on them to seek agreement on the change of priorities. They can make their case to the other stakeholders about why their project or task is more urgent or important than others on the list, and come back to me if/when they have that.

The extra benefit to this is that when other tasks are not finished when they were originally expected to be and you are called on this by a stakeholder, you can point out that they agreed to add new higher priority tasks into the queue, so the original time estimates were no longer applicable.

At one company, the way it worked was a PM would come to you and say something like, can you install the database on the new servers for project X? And you would say something like, no, because those servers haven't been delivered by the vendor yet.

Then the PM would go to your manager and say engineer Y REFUSED to help me with my project. All the PMs did this at that company, so I assume it was a technique taught on whatever training courses they were sent on. Well we all soon got wise to it, and after we started saying no to them in ever more "creative" ways, they soon learned a new technique...

There are some great advice in this thread. After many years of working at various levels, I have learned that behind the "Yes" answer lies many factors, when it can be done, how it can be done, does it depend on someone else etc.

This is also absolutely true for the "Yes" you get back from your requests for help as well.

So I usually say "Yes", but I would qualify it with when I can do it, or what resources I need to complete it etc.

It also comes down to managing the expectations of your requester. Is it OK for them if you complete their request by next week or you only have resource to do half of the tasks.

I am not sure this is ever a soluble problem - it is one of those things that demands perfect actions from all players in a "hierarchy".

If any person in your reporting chain does the very human thing of "trying to please", and undercuts your promises, you have a problem. Telling your boss "well I told you so, and I am not going to alter my activities to try and fix it" is a short cut to P45 land.

No matter how much lip service is paid to Agile, the sprint concept is not protected

Agile : it will be done when it's done, there are no schedules, only estimates.

very very few organisations accept this. Everyone has milestones on the board report and if you slip, others slip and lots of pain happens.

It is good to have your own schedule and to feed that out professionally, but it only seems to work in areas where your personal influence (your professionalism) reflects to the top of the decision chain.

Other than that m, saying yes or no is just squeaking of the wheels.

William Ury, of "Getting to Yes" fame, also has a book titled "The Power of a Positive No" that directly addresses your question. It should be required reading for all software developers. http://www.williamury.com/books/the-power-of-a-positive-no/

Really, if everyone on Earth read those two books and his "Getting Past No", the world would be a much happier place.