Live data from Hacker News

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

news.ycombinator.com

21–30 of 54 posts

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

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

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

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

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

#23
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!

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

#24

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.

> and ask him what should be cut

Or her.

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

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

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

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

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

#27
post #5

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.

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

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

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

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

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

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

Post reply on HN