
Ask HN: Developers – How did you learn to say NO? - ninja_to_be
Your boss comes to you with some highly improbably task and you say YES.<p>Your Project Manager comes to you asking if something could be done and you say YES. And then you have a unbelievable deadline looming over you for the next few days.<p>Your peers ask you for some help on a task that they had been struggling with - for days. You say YES and then you end up having to feel the burn for their complete workload.<p>Your subordinates ask you for help every five minutes and you always say YES and end up helping them and sometimes end up doing all the task yourself - veiled under &#x27;mentoring&#x27;.<p>How do you say NO? How did you learn to say NO?
======
chadcmulligan
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.

~~~
mrweasel
Letting people know that their request will interfere with projects for
others, and they need to clear it with those people, not you, is always a good
idea. People tend to view their projects as more important and will always put
their needs before other, especially if they are pressured by their own
deadlines. You don't want to be the person that pick which project gets done
first. You'll always pick the wrong one.

One weird situation I often encounter is people wanting something on a
deadline, but there isn't actually enough time or circumstances have changed.
It's highly unproductive when people just keep repeating that a deadline must
be meet, regardless of circumstances. What I have resorted to in these cases
are not saying no, but asking what they'd have me do. That often removes the
expectation of magic or whatever management believes is going to intervene if
you just keeps pushing.

------
erdevs
"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.)

------
andrei_says_
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](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.

------
mpolichette
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!

------
Cthulhu_
Get a todo list, do tasks in order of importance; if someone comes in and asks
you something, say "yes, but" and give it a place in your list. Don't leave
tasks half-finished before starting the next, if you can finish them at least.

~~~
metamicah
I'm a solo developer in a non-tech group and I'm all about this. I add every
idea to the issue tracking system. I prioritize based on consensus,
feasibility, and alignment with our group's strategy. Half the ideas won't
ever materialize and that's okay, because the other half are more important.

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

~~~
supercoder
Perfectly reasonable for a client to dictate the technology they want a
product built in. But yeah silly to engage a developer who is inexperienced in
it.

~~~
orthecreedence
> Perfectly reasonable for a client to dictate the technology they want a
> product built in

Not if they know nothing about programming and they are just throwing out
buzzwords they happened to pick up.

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

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

~~~
eitland
While 24 hours sounds much to me I agree on the principle.

Tom Limoncelli/Christine Hogan has you covered on this one I guess: The
Practice of System and Network Administration mention that you should ask
politely if the other party can fire a mail to the ticket system since "that
way you can be sure I won't forget".

Tada: off your mind in to a queue that can be sorted and prioritized.

~~~
marcuscreo
Ya, even 1 hours is better than answering in the moment.

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

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

~~~
WalterBright
In general, the way to move ahead with your boss and your customers is to
underpromise and overdeliver. Most people overpromise and underdeliver, so
there's a large opportunity there.

------
hubert123
Why would you ever say things that are untrue? You are simply a lier then.
Saying "yes" even though you DONT actually know if you can make it is a lie.
You are lying to your manager. Tell him that it's probably gonna be close, and
other work might suffer or even that work in particular. I mean why on earth
WOULDNT you tell him that? It's not like this won't come up immediately anyway
when you inevitably don't finish or don't finish properly.

~~~
amelius
Well, in principle you are right, but it sometimes goes like this:

[https://www.youtube.com/watch?v=BKorP55Aqvg](https://www.youtube.com/watch?v=BKorP55Aqvg)

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

------
inestyne
Remember that people with always push back when you attempt to change the
status quo. First drop the expectation that you'll be encouraged and supported
when you finally grow up and make the change. Just do it, and stop explaining
why you're doing it.

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

~~~
marcuscreo
No, agile doesn't. It's not a process problem, it's a people problem. People
still overcommit in agile, or commit for the wrong reasons.

------
angrymouse
Lots of good advice here about pushing back. Be sure to do it in your own
voice of course and no need for a revolution. It may be best to focus on small
things and grow from there

In that vein, the BBC used to vet new hires (in an assessment) around how they
would react to a colleague who kept asking for help on similar things but
refused to learn how to do it themselves.

No idea if they still do this but worth thinking if you are enabling your
colleagues to just dump it on you.

Ask yourself, do you completely take over? Have you tried getting them to do
it by talking them through but not hands on solving it for them?

Often quicker a couple of times to just take over but long term they'll be
reliant on you and you'll be stuck helping them solve that problem time after
time.

Harder to do that with tasks from a manager or similar, but I've found it
helps to talk through what you'd have to do, what you'd have to drop and
problems you see coming. You'll probably still have to do it but you can make
explicit what will move down your pecking order.

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

------
kchoudhu
I just said no one day.

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

~~~
mixmastamyk
This is it simply, part of growing up. Although I might clarify, you could say
yes until you plate is full, then you say, "sorry, I'm booked until…"

~~~
kchoudhu
I actually start saying "no" well before my plate is full. Optionality is
good, otherwise sometimes you have to say no even though you would very much
like to say yes.

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

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

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

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

~~~
Fordrus
Report, report, report. Who are you delivering the final product to? Email
that person, tell that person during stand-up, "I discovered issue X in my
project today, this pushes back my deadline by Y
hours/days/weeks/months/millennia." You don't HAVE to manage the entire
fallout, necessarily, right away, but if you start raising alarm bells early,
you can harness your team to assist in adapting! :)

The other thing? CUT. Can't have feature completed by next week? What are the
parameters? Could you do a mock-up or a skeleton of it and have it serve the
immediate, urgent purpose, while potentially still moving you towards final
feature nirvana? Better phrased: you've hit a snag, you can't deliver what you
said, on the deadline that you said- especially if you fear that manager
you'll be reporting to, tell him/her what you CAN still deliver on that
timetable. "What CAN you deliver, then?" is almost certainly on someone in
your chain of command's mind, desperately begging for an answer! :)

------
osmanscam
Answer of this question may vary depending on your goal.

Ask this question, in the way you describe here, to the person you are
reporting to, who is responsible reviewing your annual performance. Depending
on your target, you may say yes to all and ok be late for deadlines and no to
everything else and just focus on one task, and deliver before the deadline.

However, answering colleague's 5-15 minute long questions is different then
the above. You should do it even in the expense of doing overtime. If it takes
longer then that, you should return to your work.

------
corysama
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/](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.

------
userunknown00
I read a book once called "The One Thing", written by Gary Keller (of Keller
Williams Realty). Essentially what he says in the book is every day, identify
your _most_ important task, and do that. Everything and everyone else gets
"no" until you finish that one task. Then you move on to the second most
important thing, and so on.

I don't know how well all of his concepts translate to an IT environment, but
it was, for me, a good read with a lot of insights.

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

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

------
paupino_masano
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!

------
1000hz
By immediately following it with the word "problem"

------
saasinator
You can say "no" without saying "no". Try this, "We can do that, but I've got
a lot on my plate this week. Shall we log the task for next week or shuffle
some tasks around different sprints to make room for it?"

There you go, 9 times out of 10 they will shelve the idea.

~~~
stuxnet79
Not a fan of passive-aggressive tactics. I trust my colleagues to be
forthright in their answers so giving a convoluted yes when it is actually a
no builds distrust and resentment on my end. Sometimes a question is just a
question and deserves an honest, no fluff answer.

------
eitland
I picket it up while volunteering. It came to a point were I couldn't possibly
get everything done and at some point I could tell myself with confidence that
it wasn't lazyness but rather doing the right thing.

No is still not natural to me but I now master it when necessary I think.

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

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

------
richforrester
The trick to "not saying yes outright" is simply knowing that someone is
paying you for your expertise. Saying yes when you shouldn't, just means
you're not doing what you're paid for.

------
martin-toth
You dont say No.

You say Yes I can but first need to be finished this and that.

Then say: If you feel your task has priority let me talk to my supervisor 1st.

You will be yes man, expert and your boss will know u r busy.

Noone will feel bad about your attitude. Try it.

Martin

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

