Saying No Upward: Managers, Directors and the Exception

Friday, 16:20, at Bluewater Bank. The desk phone rings and it is Helen, the regional director. She is calling directly rather than through the queue, which is the first sign. "I'm travelling all next week and I need my new assistant to be able to get into my mailbox. Can you just give her my password? It's only for the week." Priya has been on the desk two years. She knows the policy: credentials are never shared, not for a week, not for a director. She also knows that Helen is five levels above her and that it is twenty past four on a Friday. "I'm afraid I can't do that" to a regional director is a sentence she has never said aloud. The pause on the line is about two seconds long. It feels longer.

Saying no upward is declining a request from someone with more authority than you, or more than the desk. It is different from every other no in this series for one reason. The technician usually lacks the authority to grant the request and also lacks the authority to refuse it finally. The person on the phone can, in the end, have the rule changed. The technician cannot. That asymmetry is why the right move upward is rarely a flat no and is almost always a redirect. It is not "no", but "I can't decide that, and here is who can, and here is what I can do right now". This article is part of our Saying No Professionally series, and it is about that redirect.

It covers why upward is different and the three mistakes, caving, refusing alone and going quiet. Then come the manager who wants the exception, the director's request, and escalating the decision rather than the ticket. Next come the written record and why it protects everyone, followed by the yes-with-conditions, which is the answer most upward requests should get. Then it covers what to do when you are overruled, a short war story, and the upward-no message to copy, in that order.

Why Upward Is Different

Every other no in this series rests on a rule the requester did not write and cannot change. Upward, the requester often can change it, or knows the person who can, or is the person who can. A director asking for an exception to the password policy is asking the technician to do something the director could, in principle, authorise. The technician who says "no" is therefore not reporting a decision made above them. They are making one, about a person above them, and both of them know it. That is what makes the pause on the phone so long.

The second difference is that the cost of the no lands on the technician personally, or feels as if it will. A store manager who is declined complains to the desk lead. A director who is declined is the desk lead's manager's manager. The fear here is not of the complaint but of the consequence. And it is worth saying plainly that in most organisations the fear is larger than the risk. Directors who ask for exceptions are usually busy people solving a problem, not people hunting for insubordination. Treat the request as a problem to solve rather than a test of loyalty, and most of the fear goes. Most. The sentence is still hard to say.

The third difference is that the upward request is often reasonable, and that is what makes it dangerous. Helen genuinely does need her assistant to handle her mailbox for a week. The need is real; the proposed method is the one thing the policy forbids. A technician who hears "share my password" and says no has refused a director. A technician who hears "my assistant needs to work my mailbox for a week" and says "yes, and not that way" has solved a director's problem. The whole skill of saying no upward is in hearing the second sentence when the first one is what was said.

The Three Mistakes

The first mistake is caving: the technician grants the request because of who asked. The password is shared. The exception is made. Nothing is written down. And the policy is now a document that applies to people below a certain grade. Caving feels like the safe choice and is the most dangerous one. The technician has personally made an exception they had no authority to make. When it goes wrong, as shared credentials reliably do, the record will show one name, and it will be the technician's. The director will not remember asking. They asked for the mailbox to be handled, not for the policy to be broken.

The second mistake is refusing alone: the technician says no, cites the policy, and treats the matter as closed. This is correct about the policy and wrong about the authority. The director now has a refusal from someone five levels down and no route to the person who could actually decide. They also have a problem that is still unsolved on a Friday afternoon. Most directors in this position do one of two things: they phone the desk lead's manager, or they find a way round the desk. And the second is worse than the first. A technician refusing alone has taken a decision that was never theirs to take finally, and has made an enemy of the policy while doing it.

The third mistake is going quiet: "let me look into that" followed by nothing, in the hope that the week passes and the request dies. It does not die. It comes back on Monday morning with the director's assistant locked out, the director on a plane, and the desk lead asking why nobody told them. Silence upward is not caution. It is a decision not to decide, taken by the person least entitled to take it. And it fails in the most public way available.

The Manager Asking for the Exception

The commonest upward request is a line manager asking for an exception for their own team. Examples are admin rights for a developer, a personal laptop on the network for a contractor, a shared mailbox password for cover. Another is a software install that skipped approval because the project is late. The manager is not trying to break the rule. They are trying to get their team's work done. The rule is in the way. And they have correctly identified the desk as the place where the rule becomes real. "Can we make an exception?" is a reasonable question. It is simply not one the technician can answer.

The right response names the need, confirms the no at the desk's level, and routes the decision. "You need the contractor working on the project by Monday. I can't put an unmanaged laptop on the network, and that's not a call I'm able to make an exception to; the person who can is Tomas, the security lead, and I've sent him the request now with your Monday deadline. What I can do today is get the contractor a managed loan laptop, which usually takes an hour, so that Monday isn't at risk whichever way Tomas decides." Three sentences, no refusal of the manager, a decision sent to its owner, and the need half-met before anyone has decided anything.

Manager exceptions are also where patterns show. If the same manager asks for the same exception every quarter, or three managers ask for it in a month, the rule is in the wrong place. In that case, the exception should become the rule, or the rule should be rewritten so that the need is met some other way. The desk is the only place that sees all the exception requests together, which makes it the only place that can say so. Count them. A rule with a dozen granted exceptions is a rule nobody believes, including the people who grant them.

The Director's Request

A director's request differs from a manager's in speed and in distance. It arrives faster, by phone or in person, often outside the queue. And it comes from someone who does not know the desk's processes and should not have to. The director also has the power to get the rule changed by Monday. That means the technician is talking to someone who could remove the ground the no is standing on. None of that changes what the technician can do. It changes how quickly it must be done, and how carefully it is said.

Say the no at the desk's level in one sentence, and move immediately to what you can do and who decides. "I can't give out your password, and I'm not the person who could approve an exception to that. What I can do in the next ten minutes is give your assistant delegated access to your mailbox. That lets her read, reply and manage your calendar as you, without the password changing hands. If you need more than that, the security lead can decide by Monday morning and I've flagged it to him now." Helen's need is met before she has finished being surprised, and the exception question has gone to someone who can answer it. The call takes three minutes, and the technician has not once said "policy".

Resist the urge to explain the policy at length to a director. They did not ask about the policy; they asked for the mailbox to be handled. One sentence of reason is right. It is the one you would want to hear in their position. For example: "because a shared password means anything done in your mailbox can't be told apart from you, which protects you as much as the bank". After that, the alternative and the route. Directors, in my experience, tolerate being told no considerably better than being told why at length. Nobody in the building is shorter of minutes.

Escalate the Decision, Not the Ticket

The move that makes every upward no survivable is to send the decision to its owner, in writing, with a deadline. Do this while the requester is still on the phone or within the hour. This is not the same as escalating the ticket. Escalating a ticket, in the sense used in What Escalation Means, hands the work to someone with more skill. Escalating a decision hands the question to someone with more authority, and the work, the alternative, stays with the technician. The ticket does not move. The decision does.

Know in advance who owns each rule, because the moment the director is on the phone is not the moment to find out. Most desks can list their half-dozen rules that attract exception requests. Each should have a named owner on the scope or policy page. Examples are security lead for credentials and devices, finance for purchases, the desk lead for service levels and priorities. Another example is HR for anything touching a person's record. Where who decides is itself unclear, the desk lead decides who decides. In that case, the technician's job is to get it to the desk lead within the hour. The question of who holds the priority decision when a senior person says "this is urgent" is its own subject, in Who Decides the Priority. The upward exception uses the same principle: the decision belongs to a named role, not to whoever is loudest.

Mark the ticket so the lead sees it without pretending the request is more urgent than the outage beside it. A director's exception request is important and usually not urgent in the ticket sense. The outage affecting forty people is urgent and not a decision anybody above the desk needs to make. Tools that keep an escalation flag separate from priority, as QuerySolv does, let the technician raise the first without inflating the second. The lead sees "needs a decision from above" rather than "a director is cross". Where the tool has no such flag, an internal note to the lead with the deadline in the first line does the same job. The point is that the decision is visibly waiting on a named person, with a time. The technician has stopped carrying it alone.

The Written Record

Every upward exception, asked, granted or declined, lives in the ticket. And the reason is that the ticket is the only account of the conversation that will exist in three months. The director will not remember the phone call. The security lead will not remember whether they said yes or "probably". The technician will remember everything and be believed about none of it, because a technician's memory of a conversation with a director is the weakest evidence in the building. The ticket, with its times, its messages and its approval written in the approver's own words, is the strongest.

Record four things. Record what was asked, by whom, for when, and what the technician said, including the alternative offered. Record who the decision was sent to and when, and the decision itself, in the decider's words, with its conditions. "Verbal approval from Tomas" is not a record; it is a claim. Ask the decider to reply in the ticket, or forward their e-mail into it. That way, the approval sits in the history under their name. If you run QuerySolv, every ticket already carries its complete event history. So the request, the handover to the decider and the approval sit in one place without anyone keeping a separate file. In any tool, the test is whether a stranger could open the ticket in a year and see who decided what, when, and why.

The record protects everyone, and the technician most. When the exception goes wrong, and some will, the review asks who approved it. The answer is in the ticket, with a name that is not the technician's. When the exception goes right, the record is the evidence that the rule may need changing. And when the director phones a second time, the record tells the next technician that delegated access was set up last time and worked. That turns a hard conversation into "the same as before?" The record is not bureaucracy. It is the desk's memory, and the only one anybody will trust.

The Yes-With-Conditions

Most upward exception requests should come back from the decider as a yes-with-conditions. That means the request is granted, bounded by time, scope, review and a name. That makes the exception a decision rather than a hole. The conditions are what make an exception safe to grant. And a decider who can see them written out in the request will grant far more readily than one asked a bare "can we make an exception?". Part of the technician's job in escalating the decision is to propose the conditions, because the technician knows what is technically possible and the decider often does not.

The table below gives the five conditions that belong on nearly every exception, with an example and what goes wrong without each. Not every exception needs all five, but an exception with none of them is a rule change nobody announced. Proposing them is also the technician's best chance of getting a yes they can live with. "Grant it until Friday, for one mailbox, logged, reviewed by Tomas on Monday" is a sentence a security lead can say yes to in ten seconds.

Where the exception amounts to a change to a shared system, it belongs in whatever the desk uses to track changes, with the exception as its reason. Examples are a firewall rule, a mail-flow rule, a permission on a shared resource. The question of which changes deserve a review before they are made is in What Needs Review and What Does Not. The yes-with-conditions is a change with a sunset, and the sunset is the part that gets forgotten.

When You Are Overruled

Sometimes the decision comes back as a plain yes, conditions declined, and the technician still thinks it is wrong. Say so once, in writing, in the ticket, in one sentence, and then do it. "I've recorded that I recommended delegated access rather than a shared password, and I'll set up the shared password as approved." The sentence is not insubordination and it is not a protest. It is the technician's professional view, placed where the review will find it. And it is the single most important sentence in this article for the technician's own protection. Then the work is done properly and promptly, because the decision was made by the person entitled to make it.

The exception to doing it is the thing that is unlawful or that puts a person at risk. It also includes something the technician is personally forbidden to do under a regulation that applies to them. Those are rare. When one arrives the route is not refusal but a further escalation, to the desk lead and if necessary above, in writing. That escalation includes the words "I am not able to do this and here is why" and the specific rule. Everything short of that, the technician does, with their concern noted once. A desk where technicians refuse approved exceptions on personal judgement is a desk that has made itself the rule owner, and the organisation will replace it with one that has not.

Do not argue the case twice. The decision was sent with the technician's recommendation; the decider read it and decided otherwise; the recommendation is on record. Reopening it by e-mail, in person, or through the technician's own manager turns a decision into a dispute. The technician will lose the dispute while being right about the risk, which is the worst of the available outcomes. Note it, do it, and make sure the review date is in the ticket. The review is where a wrong exception gets corrected without anybody having to be wrong in public.

A Short War Story: The Encryption Rule at Fenwick Legal

At Fenwick Legal, a partner called Richard asked the desk to switch off the rule that encrypted outgoing attachments over a certain size. A client's deal documents were being held up and the client's own systems could not open the encrypted files. A technician called Sam replied by e-mail that the rule was firm policy and could not be disabled. The reply offered no alternative and no route to anyone who could decide. Richard telephoned the managing partner. The managing partner telephoned the desk. Sam, now overruled by voice, disabled the rule that afternoon for the whole firm. Nobody had said "for one client" or "until Friday" and he did not feel able to ask. Nothing was written in the ticket beyond "rule disabled as requested". The rule stayed off for five months, until an associate sent a different client's settlement terms, unencrypted, to an address one letter away from the intended one. The firm reported the breach to its regulator, lost the client, and spent a week establishing who had approved the change. The ticket could not say and the managing partner did not recall. The review found that a yes-with-conditions had been available on the day. The available option was an exception for one client's domain, for the life of the deal. It called for written approval by the managing partner and a review at its end. An exception granted by phone and recorded nowhere belongs to whoever typed the change, and Sam had typed it.

The Upward-No Message

The template below has three parts, in the order they are written. First comes the reply to the requester, sent within the hour. Next comes the note to the decider, written in the ticket at the same time. Finally comes the record of the decision when it comes back. The first part never contains the word "policy" more than once and always contains what the technician can do straight away. The second part proposes the conditions, because a decider given a bounded yes to approve will approve it. A decider given a bare question will ask the technician what they recommend, which is the same work later. The third part is the memory, and the last line of it is the one that protects the person filling it in.

THE UPWARD-NO MESSAGE — REQUESTER, DECIDER, RECORD
Ticket: ________   Requested by: ______________ (role: ______________)
Rule involved: ______________________   Owner of the rule: ______________

1. TO THE REQUESTER (within the hour)
   Thanks for the request to ______________; I understand you need it for
   ______________ by ______________.
   I can't approve this from the desk, because ______________.
   The person who can decide is ______________, and I have sent it to them
   now with your deadline. I will update you by ______________ either way.
   What I can do straight away is ______________.

2. TO THE DECIDER (same hour, in the ticket)
   ______________ (role) has asked for ______________, needed by ______________.
   The rule this touches is ______________, because ______________.
   Options:   [ ] decline
              [ ] grant with conditions:  until ________ / scope ________ /
                                           reviewed by ________ on ________
              [ ] grant as asked
   Risk if granted: ______________.   Risk if declined: ______________.
   My recommendation: ______________.
   Offered in the meantime: ______________.   Decision needed by: ______________.

3. THE RECORD (when the decision comes back)
   Decision: ______________   by ______________ (name, role)   on ________
   In the decider's own words, in the ticket:  [ ]
   Conditions:  until ________   scope ________   review by ________ on ________
   Change made: ______________   by ______________   how to reverse: ______________
   Requester told:  [ ]      Review date set in the ticket:  [ ]
   My concern, if any, noted once in the ticket:  [ ]

Priya used the first block on the phone with Helen, more or less from memory, at 16:22 on the Friday. She set up delegated access for the assistant by half past. The second block went to Tomas in the ticket at 16:40 with "grant delegated access only; decline the shared password" as the recommendation. His reply, in his own words, was in the ticket by nine on Monday agreeing. Helen never asked for the password again, because she had never wanted the password. She had wanted her mailbox handled. And it was, by a technician who had said no to a regional director without either of them quite noticing.

Frequently Asked Questions