Politely saying no to other departments despite historic expectations?

Question

My highly technical department has historically had a problem of catering to every whim of everyone else in the company. If someone comes to my department and asks for a technical solution, they have almost always gotten it.

This has lead to excessive amounts of specialised, diverse systems that spread our capacity for maintenance way too thin. We no longer have time for far-sighted improvements that could lighten our maintenance load, because there's always some one-off system demanding attention.

This is where I came in. I was asked to head this department and change this trajectory.

That means my job is basically to say "no" to other departments when they request things that are outside of a tiny core of jobs that are the true responsibilities of my department.

Sometimes I run out of polite ways to say no. Especially when it comes to requests that truly are small, at least in isolation. In practise, I'm saying no on principle (because many of these small requests accumulate) but saying outright that you're uncooperative on principle is an unpopular way to put it.

These small requests come at a cost that while not unbearable, takes us further down on a road we don't want to go down. But the other departments seem to think that "now that we've come so far down this unpleasant road, what's a few more feet?"

In other words, they seem to not care about the marginal economics of the situation as much as I think they should.

That they have had years of simply getting their way no matter the cost to my department simply compounds the problem. From their perspective, I simply came in and immediately started ruining the nice collaborative atmosphere they had going.

What are ways to change this?

Answer 1

I have had to handle this exact kind of situation (in a different context) as a managing consultant.

These other departments are not coming to you on a whim. They are coming to get a technical solution to a legit business problem.

Over time, your department has become the "outsourcing partner" to build the tooling for other departments to use. These departments need said tools to optimise their functioning. This activity - tooling for other departments is now eating into a significant chunk of your department's resources. This is the problem.

The immediate solution is not to cut off these other departments from their tool-makers. That'd just be hampering the larger organization. At some point you will cut off something important (because to you it is all "requests" and to them some of it can be critical) and things will get escalated way over your head. And you and whoever gave you this remit will have to answer for it.

Departments do not exist in isolation to be self-serving. They are there to serve the company. The right thing to do is look beyond your precise remit and try and figure out with a collaborative approach what the right solution needs to be. In most cases, this will require the involvement of the top execs of the company to get all the parties on board.

Often this kind of problem happens in companies with outdated systems, which necessitate a lot of manual workarounds.

• A long term solution will be to get a more advanced system (ERP, accounting or whatever else it is) that addresses the needs of the different groups. This is a long process. Your company will need to study a number of systems, and go through the pain of adopting to a new one and do a bunch of migrations. 2-3 years work at a large company, involving lots of consultants.

• Another approach is to split the tech BAU (business as usual) processes from the "special" requests. Have a separate team handling these requests and ensure to get the documentation in order. This can be the best short-mid term solution. Understand that with this approach, you are in a way writing parts of the "operating system" of the organization - which in the long term is suboptimal compared to the previous bullet point.

• Yet another (potentially highly suboptimal) approach is to work out an arrangement where each department has its own tiny little engineering outfit. Depending on the scope and scale of the problems this can be a good idea (if the tools are simple to build and maintain). Depending on the need for interoperability and the level of interdependencies, this can be a terrible idea (tools from different departments need to talk to each other).

TL;DR - think at the level of the company - what is the best way for the work to get done. Departments can be reorganized, roles can be reassigned.

EDIT/UPDATE - I see this answer getting many upvotes. So here is what I think the first step should be in very practical terms.

Start documenting all of the different new requests you get. For each request, write down why it is needed (1 liner), who needs it (which function in which department), how often will it be used, what is the cost of not having it, how are they currently handling it, and a subjective rating of its relative importance. It will be really ideal if your department already has this for the recent past.

This is like the opposite of what a big ticket salesperson does to "discover customer needs". Let your boss know that you are starting this process and will share the results with him within 1-2 months.

Over a period of 1-2 months, after you have built a detailed record of what kind of problems you are actually solving for other people, it will become a lot easier for departmental managers and execs to wrap their head around and think of holistic solutions.

The departmental managers might even conclude that some of these requests should be solved internally instead of overloading your people. And doing this exercise will also discourage the other departments from coming with trivial requests. The other departments may even set up an internal procedure where a request to your department will have to go through an internal chain of command first. It is after all quite possible that because there's a free tool-builder department available, staff from other departments come to you to request tooling that may only be rarely used. And you will also figure out what resources you need to handle the situation.

Answer 2

What are ways to change this?

You will need to educate the population on the new way of handling requests.

For requests that are outside of the responsibilities of your department, you need to direct them to the proper person/department rather than saying "no". It is important to give said person/department a heads up prior, so that they are aware that they will start receiving these requests. You can respond to the request with something like:

Hello, regarding request X, this is not within the scope of this department. You will need to reach out to person/department Y who can assist with this.

If they bring up the fact that your department had historically handled these requests, you let them know that it is no longer the case:

I understand that this department used to handle these requests, but this role has been transitioned to Y, who will be handling it going forward.

As for the small requests that only your department is responsible for, you should be addressing them or speak with your boss if you feel that your department should no longer be handling them. If your department is backlogged with so much work that they cannot handle these requests ( at least not in a timely manner ) then you need to communicate that to the requestor. Let them know that you cannot provide a definitive or estimated timeline for starting to work on their request but that you acknowledge receipt and will work on it when able to.

Answer 3

Just keep saying no. It's what you were hired to do, don't expect it to be popular.

I've been in this situation a few times. Best to just do what needs to be done professionally and disregard anyone having issues with it until they get used to the new status quo.

Having said that, saying 'No' on principle seems strange to me, everything should be based on it's individual merits. So while I might institute a blanket procedure to make it more difficult to get frivolous requests actioned. I'd still take them seriously. I might ask everyone to hold off on new work requests unless they're urgent as the division is doing an analysis and restructure or something along those lines.

In addition to minimising new work I'd be looking closely at amalgamating or at least analysing existing systems for maintainability. Concentrating and phasing redundant systems out can make a big difference sometimes.

Answer 4

Don't say "No", say "That'll cost ya".

In the business world all revolves around money. If you use $1000 to save another department $2000 that is good business, The other way around, not so good.

But your budget should reflect the value earned. So, invoice them.

Unfortunately, keeping track of costs is itself costly. You need to track hours and other resources, issue invoices, check that they are paid and so on.

Your department should not carry those costs, your "customers" should. Also, add a profit margin.

You also have maintenance for existing systems. Estimate the cost for this. Find out who uses these systems. Say something like "six months from today, we will start charging maintenance for these systems. Pay up or it will be shut down." You should probably not add a profit margin here.

All this will need support from Above, so put together a proposal and present it to whoever can make it real.

Answer 5

Other answers really hit the nail on the head for work that another team owns or work that you can file and forget about. For requests where the external team is really insistent on getting the work done soon, a leadership triage works wonders.

saying outright that you're uncooperative on principle is an unpopular way to put it.

Your concerns are warranted. At my company, the executive team tasked our team with getting the product to a certain amount of 9s of reliability. They broadcasted to the entire company that this was the most important arc company-wide. Later, an external team was attempting to use an unreliable service we were in the process of retiring to meet their quarterly goals. We told them no, decision final, several times, after explaining the impact to reliability using this service would have. They escalated all the way up and our team was chastised for not being constructive, despite executing what we were told to. As it turns out, this project was also important to the executive team, and they asked us to support it even with the ding to reliability.

It was through this that our team learned to make use of leadership triaging. Your boss and whoever else tasked you with getting the ad hoc requests under control are human. They might not recall an important project when instructing you that yours is paramount, or may change their prioritization in light of new information or developments. If your leadership isn't very effective, they might change their priorities ad hoc just like the requests your team gets. In the end, if a request is so important to another team that they're willing to pester you about it, it may be a good idea to double check with upper leadership.

If your company is good with surfacing these well in advance before they're needed, you can sync with upper leadership in a quarterly or monthly triage. If it's not that responsible, you may have to schedule these syncs ad hoc as the requests come in. In either case, you need to keep track of the cost of everything your team is working on, including maintenance of the existing ad hoc systems. Do an initial estimate of the work required to build and maintain the requested system as well, and bring yourself, the requester, their leadership, and your leadership into a room to inform them that there are more requests than your team can field this / next / etc quarter and let upper leadership decide what gets chopped. This way, you avoid being seen as nonconstructive, and if the external request is the one that gets canned, they can't complain. In the event your company has any rogue teams which maliciously use dirty tricks to complete their deliverables at the expense of others, this is even more important: I've worked with these teams before, and they will harass your team for months or quarters until you finally cave in and they set precedent for future requests. Getting upper leadership involved is a very easy deterrent to these teams as they don't like the visibility.

Answer 6

If this is a new company policy, make it explicit :

I’m sorry, but our department is not allowed to accept this kind of request anymore.

In addition, if you’re allowed to, historic expectations would be more easily addressed through a transition phase :

We will fix your issue, but note that due to a change in the company policy, our department will not be allowed to accept this kind of request anymore after [DATE].

or

We will fix your issue this one time, but note that due to a change in the company policy, our department is not allowed to accept this kind of request anymore.

Answer 7

Don't say no. Say "yes, but you have to follow the new system".

What the new system is, is that new trajectory you're tasked with charting out. This might take the form of a ticketing system, not talking to developers directly anymore, a requirement to pass any request via a functional/technical analyst, a formal budgeted request, ...

At the end of the day, your department is there to provide solutions. This does not change. What does change is the manner in which you provide said solutions.

The people whose problem you solve need their problem solved. You will keep doing this, so don't say no because it suggests that you will no longer solve their problems, and you will encounter resistance to that.

Instead, redirect them to the correct way of them getting you to help them. This will encounter much less resistance.

Amended from comment:
For those cases where their request is truly out of scope of your department (e.g. asking the developers for what is essentially IT support); it is still more helpful to redirect the person instead of stopping them with a hard "no".
It will go much smoother if you redirect, because you're not telling people that they won't be helped (which makes them stop and protest), you're just telling them that they can get the help they need via [redirection] (which makes them move on to the thing that can actually help address their problem).

For those annoying ones who refuse to be redirected because they stick to their old guns, don't budge. Instead, address with their/your manager that an official announcement needs to be made about the new system, and that this system is to be followed.

Answer 8

they request things that are outside of a tiny core of jobs that are the true responsibilities of my department

This is the key here. This is not a thing about politeness or collaborative atmosphere.

Your job is not to say "no". Your job is to identify which of these requests proceed and which not, by following the policies of the department and the priorities of the company.

If your department has true, official resposibilities to attend but over the years they have diverted into attending all kind of request, the way to change this is to have all request pass through an official proccess that evaluates them, determines which are accepted and which not, and put those that are accepted into a queue ordered by priority (and additionally if you want to be polite/mantain the collaborative atmosphere, provide alternative solutions or redirect the request to the department that could/should resolve their issue).

My suggestion for achieving this would be:

1. Make official an publicly available (to the workers of the company, of course) the jobs or procesess that are true responsibilites of your department; be clear on what are the priorities the department will always work on.
2. Create an official channel for receiving requests; provide a guideline or a premade form on how requests should be made and what kind of information should be provided in order for a request to be received and analyzed (e.g. source of the issue, problems that is causing, expected solution or results, current workaround that's being applied - if any).
3. Define an analysis process that all received (not yet accepted) requests will go through; make clear that people from the requesting department will most likely be involved in order to better understand the issue.
4. Create a queue with all the accepted requests in order of priority (based on the policies defined in the first point) and status (accepted, in process, resolved...). Make it public so everyone that wants to make a request or has made one is aware of the work your department is doing and how much is left to be done.
5. (Optional) Along with the queue, provide feedback on all the "not accepted" (rejected sounds harsh) requests: reason why it wasn't accepted, alternative solution or workaround to their issue, redirection to the department that could/should resolve it; this will serve both as a knowledge base and as a way to show attention to them even if their request was not accepted.

Changing something that has been done for years is a hard task that will take some time for people to get used to, specially if you're "the new guy hired to change things"; be patient, be sure to follow the process as thoroughly as possible, and remember: it's not about saying "no"; it's about picking what to say "yes" to.

Answer 9

Original question asker here: by reading the answers here, I have realised that there are essentially three components to the solution. No answer has captured all three, so here is my attempt:

• The big problem, described by Ahron in the most popular answer at the time of writing, is that when I changed how my department goes about things, I created a tension in the organisation; I created a situation where different parts of the company work on very different, somewhat incompatible, principles. That tension needs to be resolved explicitly, involving upper management.

However, that being a long term project and the problem being something that hurts my department right now, there are two more levels at which I can affect change already: the immediate, and the intermediate.

• In the immediate term, I will continue to do what I have been doing, which is basically what's decribed by sf02 in their second-most popular answer at the time of writing. This has been mirrored by several other answers and comments, and seems like the most sensible immediate solution: continue saying no, but in a helpful way. Instruct the requesting departments in how to get their problem solved in a way that doesn't involve my department.

• In the intermediate term, to tie the two solutions above together, I must do what's suggested by Josh Part in the newest answer at the time of writing: clarify for myself and others what it is I imagine is my department's responsibilities, to make sure that everyone in the organisation are actually arguing about the same things and not talking past each other by having different definitions of words.

I did not initially appreciate how multi-faceted and complex this problem was, so I'm glad I asked and got such varied, high-quality answers.

---

There was one more big theme brought up in a few answers and comments. This theme is one I will not adopt (yet, anyway) but I wanted to mention it anyway for completeness: transferring the economic risk of the request to the requesting department.

I really like that idea, and I have considered many versions of it:

• Actually start to record revenue and costs independently for each department, and have them charge each other for their services.

• Set up some sort of virtual slush fund for requests like this and have the other departments battle it out over who gets what share of it.

• Reserve a slice of our time for requests like this, and make clear with the requesting department that this is what they are consuming and it's a finite resource.

However, talking to the employees in my department, they are not particularly excited about any of those approaches. Their concerns are too diverse to summarise, but all legitimate. They mainly revolve around the additional administration required to make such a quantitative approach work. I agree with them: once you start to put things into report cards or cash flow statements you spend more and more time documenting your work instead of doing it.

My dislike of bureaucracy and the fact that I want to go for a solution that sits well with as many people as possible, means I won't pursue this until I can find ways to resolve those concerns.