I am calling my approach to these tasks to make them rot away. If CEO/customer wants something, I will ignore it until he will start demanding it repeatedly then I will start thinking like working on it. Because it can also happen that CEO/customer will want shiny thing you will deliver the shiny thing and he will have no clue why did you do that, because he forgot that he wanted that - the task has rot away.
Consider it self-regulating system. If task can't survive in a mind of a wisher for more then few days, it was not needed from the start. Now you are saving resources and time to company which you can redirect to actually required tasks instead of some silly whims.
It's not a "regulating system" of any kind, but plain passive aggressive arrogance. I know better what to do so I would just pretend like I am going to do what you suggested.
Unfortunately this trait is not so uncommon across IT engineers.
> It's not a "regulating system" of any kind, but plain passive aggressive arrogance.
Is it arrogance if the task won't stick? Because if it won't stick, it was not needed at the first place - system just regulated itself to have less workload.
> I know better what to do so I would just pretend like I am going to do what you suggested.
I would argue that developers probably know better what to do. Look on it from developer's perspective he has tasks which are supposed to be done yesterday, he is being pushed by his PM and then CEO comes in with completely wild and random task which will push existing tasks further down the line. And this is going to be done without any regard to existing tasks, existing deadlines and without any regard to ticketing system. So the best course of action, is to take no action and see if this random task will stick. In most cases it won't stick, because task is more a random thought than something to be worked on.
Yes. Because stick/not stick is "decided" by IT Engineer by excerpting leverage over someone who actually have decision making capability - a manager. And what it is "stick/non stick" in your perspective is just manager thinking how to make things work bypassing the annoying engineer.
> I would argue that developers probably know better what to do
Aaaand that's exactly where arrogance is. If developers "know better" why don't they become product owners/visioners?
> Because it can also happen that CEO/customer will want shiny thing you will deliver the shiny thing and he will have no clue why did you do that, because he forgot that he wanted that - the task has rot away.
Hate this. My boss: “Hey, why is it doing that. Who did this?” You did, you clueless idiot. You asked for it.
