Ask HN: Developers – How did you learn to say NO? | Hacker News Reader

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

60 pointsninja_to_be52 comments

Your boss comes to you with some highly improbably task and you say YES.

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.

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.

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

How do you say NO? How did you learn to say NO?

View on HN

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.

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.

This is my approach with things too. Instead of saying know I explain the complexities of what would happen by saying yes:

- Other projects will be pushed out of the way

- Your deadline is not feasible, I can do it by this date.

- The cost/time of me doing something would be high, due to my inexperience in doing that task.

- I personally think it is a bad idea and a waste of everyone's time, but it's your call.

Things may work differently for others, but turning a "no" to a "yes, on my terms" is what has worked well in any situation I've been in.

One twist on this that I like when "priority" is a foreign concept is "So you want me to drop so-and-so's work for yours. I'm happy to do that on one condition - anyone else can come over and ask me to drop your work for theirs."

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

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.

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!

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.

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.

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.

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.

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

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

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.

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.

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

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

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.

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.

> and ask him what should be cut

Or her.

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.

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

https://www.youtube.com/watch?v=BKorP55Aqvg

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

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.

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

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.

+1 for "which other thing should I not get done?"

Not a confrontational question, just a logical one.

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.

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.

I just said no one day.

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

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…"

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.

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.

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.

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.

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.

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! :)

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.

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.

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.

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.

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.

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!

By immediately following it with the word "problem"

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.

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.

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.

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

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.

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.

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

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

Reply on news.ycombinator.com