I think it is also important to distinguish between your role because being a Jira administrator can mean many things. You can be a consultant or a support administrator, and then you are in a servant position. If you are like me, in a Platform or Product owner position, then you are no longer in a servant position, but in a position of authority and guidance. In a servant position, you don't really have the mandate to say no, so you have to convince with logic and hope the customer is smart enough to listen. In a position of authority, people listen more to you, but there will still be people that are narcissist, psychopaths or Machiavellian that you just can't reason with. So you always have to choose what hills you want to die on and when you let trash configurations into your product. That is when you document a technical debt as well, so you make sure you have it on record that the user demanded a change against your recommendation. I never compromise. I show them what I believe is the right solution and then we either go with that solution, or their solution. Sometimes we might come up with a new solution based on both of our views as well.
To get more resources and get in contact with me check out this link linktr.ee/apetech
My meetings always start with "Whatever you want me to configure for you, the answer is no. You have 30 minutes to change my mind."
Prioritization includes knowing who is paying and/or which initiative the request is associated with (to be certain who is paying) 😅
I think it is also important to distinguish between your role because being a Jira administrator can mean many things. You can be a consultant or a support administrator, and then you are in a servant position. If you are like me, in a Platform or Product owner position, then you are no longer in a servant position, but in a position of authority and guidance.
In a servant position, you don't really have the mandate to say no, so you have to convince with logic and hope the customer is smart enough to listen. In a position of authority, people listen more to you, but there will still be people that are narcissist, psychopaths or Machiavellian that you just can't reason with. So you always have to choose what hills you want to die on and when you let trash configurations into your product.
That is when you document a technical debt as well, so you make sure you have it on record that the user demanded a change against your recommendation.
I never compromise. I show them what I believe is the right solution and then we either go with that solution, or their solution. Sometimes we might come up with a new solution based on both of our views as well.