How to not appear defensive when turning down requests from the rest of the company? [duplicate]

Question

Our company highly emphasizes that everyone should do their best at cross-departmental teamwork and as such we also have 360 degree appraisals, not just from our direct line manager. People get fired for declining to help those from other departments (or having an unhelpful attitude).

There is a common situation in my team (and my position specifically) where I am sent requests that are technically impossible, or would require more time or resources than other teams normally expect, or would severely interrupt our current processes.

Although I am not an airplane pilot, there are many projects or processes in my team that require the same level of focus and "adhering to the procedure" (whereas other teams are generally more flexible): A passenger cannot simply come into the cockpit and ask us to land at a different airport or change the route so they can have a great view over the beautiful mountains. What we can do is tell our passengers how to enjoy the flight, what to do in order to stay safe and not interfere with what's best for their journey. We can also accommodate special requests and cook a different meal for someone who needs it. We can divert in case of extreme emergencies. But apart from that, only we should have to say how the flight should be operated.

Yet at my workplace, there are such "passengers" who often request a non-standard task or project and my (and my team's) initial reaction is just to cringe at the thought of even trying!

Maybe it's because I am new to the scenario (well, it's going on since about 6 months), but I feel like when I say "we can't" I appear defensive - especially with the "passengers" who do their best to use logic, numbers, ideas, arguments, sales pitches etc. to "convince" me that I have to do the project the way they want.

I have learned how to say "no, we can't change the flight plan because that gets decided before". But I am aware that I say that with a negative vibe. I wish I could learn how to say it like "I'm so sorry, we can't change the flight path, but I am sure you will enjoy the view anyway".

I wish I could appear helpful, but I must admit that deep inside I know I cannot really help because it is technically impossible and I feel like these "passengers" are a nuisance trying to waste our time. My honest and frank reaction is simply frustration that these "passengers" just keep coming.

So how can I appear more helpful even if I know I cannot help, due to technical/procedural constraints?

(And if you suggest changing the procedure... ok, after many industry discussions, consultations, etc. but not during the flight! Hope this analogy makes my situation clearer)

Answer 1

The problem with your approach is that they are here to get a job done. They are not here to "enjoy the view" Your suggestion that they "enjoy the view" would be much better received if you can work out with the authors of these requests ways of getting their requests executed while remaining compliant with your team's methodologies and standards.

If all you are doing is say "no", it is inevitable that you will look defensive. If you are perceived as working pretty hard with the authors of the requests to get their requests executed in a way that's compliant with your team's methodologies and standards, the perception of you as being defensive is just about the last thing that will occur to them - They'll be too busy working with you to notice anything but that you are cooperative and supportive.

You need to escalate to your team leader and to the management of the team that they need to effectively communicate to the other teams the importance of the authors of the requests being compliant with your team's methodologies and procedures. Your officer ranks need to drive home to the other teams that trying to get your team to break its own methodologies and procedures won't work since your team is the one picking up the broken pieces, but working with your team and respecting your team's methodologies and procedures is what works.

Answer 2

I work in a similar environment. The things we do are critical and somewhat opaque to the rest of the company. Our company has a very strong culture of doing what is best for the client, and like it or not, folks from other groups are in fact your clients.

We manage the requests by having a "front door" process. We are open to all requests for our time, but you have to go through proper channels so that we can make sure that we understand what you want, scope it, prioritize it, and assign the appropriate resources so that in the end the "client" has a good experience. Sometimes the answer is "Sorry, we won't be able to do that in the time frame you need it in." or "It's just not possible without spending $42 million to redesign our infrastructure." but by going through a process, when we get to that point, the person or group making the request has a good understanding of why we can't take on their request and doesn't think that we're saying no because we didn't take them seriously or are just lazy.

You can only do this partially as an individual - you really need the support of your management to do it properly. However, if you don't have that support, you can have your own process to manage requests. When I worked at a different company where I had no support for managing "drive-bys" I did several things:

1. I had a list of my current projects in order of priority visible on a white board in my office with a brief status, e.g. "Waiting on data, "In QA", etc. Every new request went at the bottom of the list until the priority was negotiated with my manager. Once I had the list visible to everyone, there was a noticeable drop in some types of requests, and the people I was working on things for seemed more content.

2. I asked that requests be made in writing (e-mail is fine) so that I wouldn't misunderstand what they were asking for and potentially waste their time by doing the wrong thing. If they were reluctant to send me an e-mail, I would document our conversation in an e-mail and ask them to confirm my understanding.

3. After I had confirmed that I understood what the request was, I would scope it and send them my WAG at what it would take to complete their request and when, given the current priority and my work load, I was likely to be able to get it done. If it wasn't possible, I would let them know that type of changes that would be required were beyond my authority to make and they would need to escalate to a specific person.

Throughout all of it, make sure that you treat the requester like a client and not like an annoyance. The process doesn't have to be overly rigid or formal, but everyone should have to go through the same basic steps and get the same consideration if they do. The process you're asking them to follow is there to help them get what they want, when they want it, and to make sure that their request is prioritized fairly.

I find that most people appreciate that their request won't be deprioritized because someone who is more aggressive or vocal requests something after they've made their request. It keeps the demands for your expertise from devolving into a free-for-all, and generally the only folks that don't like it are the ones that are used to being able to manipulate people into prioritizing their requests even if they shouldn't be. Even some of those folks come around after a while if you are committed to putting every request through your process and you apply it to everyone equally (except your manager, of course, who should be able to change your priorities instantly).

Answer 3

Just say NO. I have so many people that want to change a requirement when it gets to test because they did not think through the requirement. Once requirement are frozen new requirements are the next rev.

You know what scope creep is. Some creep trying to change the scope.

Last minute changes destabilize.

It is not fair to the people that actually thought through what they wanted and got it in the requirements.

If you did not publish requirements (flight plan) then shame on you.

Another trick is they give vague verbal requirements. Write them up and get sign off. If they did not even read em then that is their problem.

360 review is not your raise or promotion (I hope). If you bring in projects on time and on budget and get criticized for enforcing process management will know the difference.

I have 360 review that I got slammed and boss said you played that right as I was enforcing policy that came down from my boss. I will even put a jerk on a 360 review so they can make themselves look bad.