Saying No to Managers

This is a pretty common management strategy to stroke your ego and put you in a elevated position where you awkwardly feel the need to agree.I do the opposite, I say well it's not entirely clear how much work this is going to take, I'll need to do some initial assessment to get a more accurate idea.If they continue to pressure I ask them what changes they imagine need to be done since they're so assured of the scope and timeline of their request. I have not a care in the wor

Communication, you need to actively communicate what you're doing. I didn't really hear anything about how you communicated yourself throughout the project in your description, only what you said/thought at the end, and the merits and elegance of your code and how hard you worked - that's all nice but you're not being paid for elegance, nor for struggle; you're getting paid to get business needs accomplished on a timeline, maybe you can do that in an elegant way and

As an example: Something that used to drive me bats was being asked to do something I clearly knew was wrong for the project/company. Before, I would fight hard to make my point. Now, I try to illustrate my point the best I can, then I just do as told. (I bill by the hour anyways)On a previous project I actually told a non-technical owner: "What you are asking me to do is basically to hit your finger with a hammer.. That said, it is YOUR finger and YOUR hammer.. so say so and I will

I get a lot of mileage out of "I'm happy to help but first I need to let my manager know that you've asked me to do this." Usually the request dies about 15 minutes after.

I'm no dev but let's say that my job has a similar issue. The approach that I use focuses on being 1) truthful, 2) clear, 3) polite, 4) concise. In this specific order.In other words: "Sorry, I'm not going to do this because [insert here the actual reason, not some lame excuse]".Past that, if that user keeps insisting, the user is being entitled and you should not bother yourself with entitled people.

When I was a young programmer in the early nineties, an old IBM programmer told me 'Don't accept the invitation to fail.' Good advice but what if the goal posts are moved. Best then to keep positive and communicate early and often about how the changes will affect the schedule. Work together as a team and get your manager to help you and that'll go a long way rather than keeping 'obvious' things to yourself and catching management off guard when work slips.

I think bosses are like cats, when training them you have to make it think it is their idea. As I said in a sister comment the best way to do this is to not say the word "no" but to ask clarifying questions[0] so that all the puzzle pieces get placed on the table. Together you can assemble most of the puzzle, taking the lead but not lecturing them. But the final pieces have to be put together by them. Management is egotistical and if you just tell them then they get upset.Your loyal

It's really just poor communication on the part of the manager.M: Please do X/Would you like to do X/I need you to do X nowE: No.M: ...vs.M: We've had a change in priorities. I need someone to do X. I know you're working on Y, can you set it aside to work on X for a bit?E: No.M: Okay what gives?

As I said you should provide positive and constructive feedback. You are here to do your job and be helpful, not to pick and choose what you want. You cannot refuse a decision made by management apart from quitting.As an individual dev "we don't have the resources" is not something that you can really say, either.Maybe I'll take an example: You're fully busy and you are told that a new feature was requested and agreed that you need to implement. You don't just

Don't want to sound arrogant, but it seems that projects like this was a good lesson for you. With one lesson (among many others), that "I carefully explained all my suggestions and backed them up with UI conventions..." will not work with some people (technical ones) and there should be other styles of communication in your toolbox. I learned this the hard way when I wanted to be a freelancer and had to do everything (coding, managing project, accounting) on my own. Now I work at