Explaining Technical Things to Management

Tuesday, 16:30, at Oakmoor College. Helen, the finance director, has asked Jonas, who runs the desk, to "explain the backup thing". The bursar mentioned it in passing and Helen did not like the sound of it. Jonas has prepared. "So, we're on a disk-to-disk scheme, nightly incrementals with a weekly full, thirty days of retention, which is fine, but the repository sits on the same storage array as production, so there's a single point of failure, and the array is out of warranty in..." Helen lets him get about ninety seconds in, then puts her pen down. "Jonas. What do you need from me?"

He had not thought of it as needing anything. He had thought of it as a situation to describe, and he had described it accurately. But Helen's question was the right one, and once he heard it the answer was obvious. He needed her to approve a second copy of the backups kept somewhere else. He needed her, or someone, to decide how much work the college could afford to lose if the array died, because that decision set the price. Two sentences. He had brought a lecture.

Explaining to management is explaining to a listener whose job is to decide. They are not going to fix the thing, operate it, or be the one whose files are lost. And they have no use for the mechanism beyond what it takes to trust your recommendation. What they can act on is risk, cost, time and options. What they are always asking, under whatever words they use, is "what do you need from me?" This article is part of our Explaining Technical Things to Non-Technical People series. It is about the explanation that ends with a request.

It covers the question management is really asking, then risk, cost, time and options as the four things a manager can act on. Next come the three levels of detail and letting them pull, then numbers a manager can use. We cover giving options, including doing nothing, then the one-page decision brief and how it is used. Next come saying "I don't know" and "it depends" upward, then what to do when they ask for the mechanism anyway. We finish with a short war story and the decision brief itself to copy, in that order.

Management Is Asking "What Do You Need From Me?"

Every question a manager asks a technician is one of three questions wearing different clothes. Do I need to do anything? Is something about to go wrong that I will be asked about? And what is this going to cost? "Explain the backup thing" was all three. Helen wanted to know whether the college's data was at risk and whether she would be the one explaining a loss to the governors. She also wanted to know whether Jonas was about to ask for money. A description of the backup scheme answers none of those. It is the technician's answer to "how does it work?", which is a question nobody in that room had asked.

Answer the real question first, in one sentence, and the rest of the conversation changes shape. "Our backups are on the same hardware as the live data, so a hardware failure would take both; I need your approval for a second copy elsewhere, and I need a decision on how much lost work we can tolerate, because that sets the cost." Helen now knows the risk, knows a request is coming, and knows there is a decision only she can make. She can spend the remaining twenty-eight minutes on the decision rather than on finding out whether one exists. The mechanism can follow if she asks, and she may well ask, but she will ask knowing why it matters.

This is uncomfortable for technicians because it means leading with the ask. And the ask feels presumptuous before the manager has been shown the evidence. The instinct is to build the case first and arrive at the request at the end, which is how an essay works and not how a manager listens. A manager who does not know what is being asked spends the whole explanation trying to work it out, and hears none of it. Tell them the request, then make the case. They can hold a request while they listen. They cannot listen while they hunt for one.

Risk, Cost, Time and Options

A manager can act on four things, and mechanism is not one of them. Risk is what could happen, how likely it is, and how bad it would be. Cost is money, people's time, and disruption to the organisation's work. Time is how long the thing takes to do and how long until the risk bites. Options are the different things that could be done about it, with the first three attached to each. Every technical fact you want to tell a manager can be translated into one of these four. If it cannot, it belongs in the appendix or in the ticket, not in the conversation.

Translation is the skill. "The repository is on the same array as production" is a mechanism. Its translation is "if the storage fails, we lose the data and the copy together; that failure is unlikely in any given year, but if it happens the cost is every document the college has." Same fact, now expressed as a risk with a likelihood and a consequence a finance director can weigh. "Retention is thirty days" becomes "we can get back anything lost in the last month and nothing older." "The array is out of warranty" becomes "if it breaks, there is no engineer coming, and replacement takes about three weeks." None of this is dumbing down. Each translated sentence says something the original did not, which is what the fact means for the organisation.

Risk needs all three of its parts. "There's a risk of data loss" is a phrase that is true of every organisation that has ever stored anything. Managers have learned to hear it as background noise. "A storage failure, which I'd expect once in several years, would lose every file the college has, with no copy anywhere" has a what, a how likely and a how bad. A manager can do arithmetic with it. Be honest about the likelihood. If you do not know, say "I can't put a number on how likely; what I can tell you is that it has happened to organisations our size and that when it does there is no recovery." The honesty is part of the case. A technician who overstates a risk once is not believed about the next one.

The question of what work matters most to the organisation, which is what sets the size of every risk, is one the desk cannot answer alone. The method for making business impact visible, so that the manager and the technician are weighing the same thing, is in Making Business Impact Visible. For this article, the rule is that every risk you present is stated in terms of the organisation's work, not its hardware. Nobody has ever lost sleep over an array. People lose sleep over the admissions records.

The Three Levels of Detail, and Letting Them Pull

Every explanation to management exists at three levels, and the manager decides how deep to go, not you. The first level is the headline: one sentence that contains the risk and the ask. The second is the paragraph: the four things, risk, cost, time and options, in a few lines each, with your recommendation. The third is the appendix: the mechanism, in as much detail as a technical reader wants. It is for the manager who wants to understand it or needs to defend the decision to someone else. You always give the first. You usually give the second. You offer the third and let them pull it.

Starting at level three is the single most common failure, and Jonas committed it in his first ninety seconds. It feels like thoroughness. To the listener it is a stranger reading them a manual when they asked for directions. Starting at level one and stopping feels, to the technician, like withholding. To the manager it is the most respectful thing you can do. It treats their time as the scarce thing it is and leaves the depth to their choice. A manager who wants more will ask. (They will ask quite sharply, in some cases, and that is still better than the alternative.)

The appendix is not optional to write, only optional to read. The manager who approves the second backup copy on the strength of your paragraph may be asked by the governors why. The appendix is what they will reach for. Write it as if for a technical colleague, because the governors may have one. Put it after the brief, clearly marked, so that a reader who wants only the decision never has to wade through it. The chain of causes, which the rest of this series keeps out of the requester's reply, belongs here.

Numbers a Manager Can Use

Technical quantities mean nothing to a manager until they are converted into the organisation's units. Hours of downtime become people unable to work, multiplied by how many people: "a day without the shared drive is about two hundred staff doing paperwork they cannot file". A quantity of data becomes what it contains: "every document since the college opened" says more than any number of gigabytes. Technicians use recovery objectives called RPO and RTO, the recovery point objective and recovery time objective. These become "how much work we would redo" and "how long before people can work again". Those are the two numbers a manager actually has an opinion about.

Give ranges, not false precision. "Replacement would take between two and four weeks, depending on supplier stock" is a usable number. "Replacement takes nineteen days" is a number that will be wrong and remembered. Say what each number is based on, in a clause: "about three weeks, which is what the last two orders took". A manager can work with a bounded estimate that comes with its reasoning attached. What they cannot work with is a precise figure that collapses in the first meeting where someone questions it. Then every other figure in the brief is questioned too.

Never invent a number to make the case, and never borrow one from an industry you cannot vouch for. The temptation is real, because a case with a number in it sounds stronger than a case without. A figure from somewhere about the cost of data loss is always available. Resist it. If a manager asks "what would it cost us?" and the honest answer is "I don't know exactly, but here is what we would have to redo and who would do it", that answer builds the kind of trust that gets the next request approved on your word. A number you cannot defend destroys it the first time it is checked.

Where the desk's own numbers help, use them, because they are the ones you can defend. Examples are the count of tickets about the shared drive in the last quarter and the age of the oldest open problem record. Another is the number of people who raised a ticket during the last outage. These are counts the manager can check and the technician can stand behind. If you run QuerySolv, the reports on volume, backlog by age, resolution times and reopen rates are the kind of figures a brief is built from. Each is a count rather than an impression. In any tool, the rule is the same: use the numbers the desk actually has, say where they came from, and leave the industry's numbers to the industry.

Options, Including Doing Nothing

Present options, not a single proposal, because a manager presented with one course of action has been handed an instruction and will push back to turn it into a decision. Three is the right number: the thing you recommend, a cheaper or slower alternative, and doing nothing. Each gets the same four lines, cost, time, risk, and what the organisation gives up by choosing it. The manager now has a decision to make, which is their job. The shape of the options makes your recommendation visible without your having to argue for it.

Doing nothing is always an option and must always be written down, with its risk stated as plainly as the others. "Option C: leave the backups where they are. Cost: nothing now. Time: none. Risk: a storage failure loses everything with no recovery; I would expect such a failure once in several years. What we give up: the ability to recover from the one event that would end the college's records." Writing it out does two things. It makes the real cost of inaction visible, where "we haven't got round to it" hides it. It gives the manager an honest way to accept the risk on the record if that is what they decide. A risk accepted knowingly, in writing, is a decision. A risk accepted by default is an accident waiting for a date.

State your recommendation plainly and say why in two lines. Managers trust technicians who commit. "I recommend option A, the second copy off-site, because it is the only one of the three that removes the single point of failure, and the cost is roughly one term's printing budget" is a recommendation. "There are pros and cons to each approach" is a shrug with a page number. You are the person in the room who knows. The manager is asking you to say what you would do, and then deciding whether to agree. If you would not do any of them, you have not finished finding options.

When the thing you are explaining upward is a refusal, the request from above is the one that must be declined. The options method still works but the conversation has its own rules. They are in Saying No Upward. For the decision brief, the no is simply one more option with its risk and cost attached. The manager, having been shown the four lines, usually reaches it on their own.

The One-Page Decision Brief

The decision brief is a single page that carries the three levels in order. First comes the headline, then the paragraph of risk, cost, time and options with a recommendation. Last comes a clearly separated appendix for the mechanism. The brief exists because managers decide between meetings, in corridors and at the ends of days, and a conversation evaporates while a page does not. It is the right vehicle for anything that needs money, a policy, or a manager's acceptance of a risk. And it is the wrong vehicle for anything smaller, which gets the three-sentence version by e-mail instead.

Write the brief before the meeting and send it with the headline in the body of the e-mail. That way, a manager who reads only the e-mail still knows the risk and the ask. The meeting is then for the decision and the questions, not for the explanation. That means a decision can be made in ten minutes that would otherwise have taken an hour of listening. Put the date a decision is needed by at the top, and what happens if that date passes without one. "No decision" is a choice with consequences and the brief should name them. A brief with no date is a suggestion.

Keep to a page. The discipline of the page forces every mechanism into the appendix and every risk into a sentence, which is the translation this article has been describing, done on paper. If the brief runs to two pages, something from level three has crept into level two; find it and move it. The same discipline, applied to the particular case of a help desk explaining its ticket mountain to the people who fund it, is worked through in Explaining the Backlog to Management. The method there is the method here with the numbers filled in.

Saying "I Don't Know" and "It Depends" Upward

Managers accept uncertainty when it is bounded and resent it when it is bare. "I don't know how long the array will last" is bare; "I can't predict when it will fail, but it is past the age at which the maker stops supporting it, and I would not want to be running it in a year" is bounded. The second tells the manager where the edge of your knowledge is and what you would do standing at it. Every "I don't know" to a manager should come with a range and a reason. It should also come with the thing that would narrow it: "a week with the supplier would get me a firm date and a firm price".

"It depends" is the phrase that most annoys managers and most often escapes technicians. The fix is to say what it depends on and what you would do in each case. "It depends on how much lost work we can tolerate. If a day's loss is acceptable, the cheaper option covers us. If we need to lose no more than an hour, only the first option does, and the price roughly doubles. I'd want to hear from the registrar before I chose." That is "it depends" turned into a decision with two branches and a named person who can settle it. The manager can act on that. They cannot act on the two words alone.

Never guess to sound sure. The pressure in the room to have an answer is real. And a confident wrong answer about cost or time will be remembered against you long after a candid "I'll know by Thursday" would have been forgotten. Managers deal in uncertainty all day; it is most of their job. What they need from the technician is an honest map of where the certainty ends, so that they can decide how much of the uncertainty to pay to remove. Give them the map. The unmarked parts are not a failure, as long as they are marked as unmarked.

When They Ask for the Mechanism Anyway

Some managers want the mechanism, and when they ask, give it, at the level they ask for and no deeper. "How does the second copy actually get there?" deserves a plain answer: "Every night, after the main backup finishes, the changed files are copied over the internet to a storage service in another building, encrypted on the way; it takes about two hours and if it fails I get an alert in the morning." That is the three-sentence shape from The Three-Sentence Explanation, pitched for a manager: what happens, what it means, what happens if it goes wrong. It is not a tour of the configuration.

Some managers ask for the mechanism to check that you know it, and that is a fair test to pass. Answer briefly, accurately, and in plain words, and then stop. A manager testing your grasp is reassured by a clear short answer and made nervous by a long one. Long answers sound like someone talking around a gap. If the question goes somewhere you genuinely do not know, say so and say when you will. The test is not of whether you know everything. It is of whether you know what you know.

A few managers have a technical background and want the real thing, in the trade's words. With them you use the trade's words, because the rule throughout this series is to write for the reader. That reader is asking for depth. Recognise them by the questions they ask, not by their title. The subject may be a framework or a process rather than a piece of hardware. The particular problem of explaining that upward, including the words to avoid and the ones that land, is in Talking ITIL With Management. ITIL is the service-management framework whose vocabulary causes most of that trouble. The method is the same: risk, cost, time, options, and the ask up front.

A Short War Story: The Firewall Renewal at Larkspur Media

Petra ran the desk at Larkspur Media, a publisher with about eighty staff. In the spring she e-mailed the managing director, Gideon, six careful paragraphs about the office firewall. Its support contract was ending in three months, and the maker had stopped developing it. Its throughput was marginal for the new video work, and the failover arrangement would not survive a hardware fault. Gideon read the first paragraph, and found no request in it. He took the rest to be the kind of thing IT people tell you, and replied "noted, thanks". The support contract lapsed in the summer, and the firewall developed a fault in the autumn. There was no engineer to call. The office had no internet for two working days while a replacement was bought at an emergency price and configured from scratch by Petra over a weekend. Eighty people did what they could without the network, and two issues went to press late. The replacement cost roughly half again what a planned one would have, with the overtime on top. Petra's e-mail had contained everything except the one thing Gideon could act on, which was a request with a date. The brief she wrote afterwards, for the file, was four lines long and ended "I need your approval by the end of the month". The lesson Larkspur's desk kept was that a manager cannot act on information, only on a request. And a request is what you were sent to make.

The Decision Brief

The brief below is the template for this article: one page, the three levels in order, with the appendix clearly cut off from the decision above it. Fill it in before the meeting, send it ahead with the headline pasted into the e-mail body, and bring one printed copy. Every blank is there because its absence has cost somebody a decision. The appendix is written last and read least, and it is still written.

DECISION BRIEF — ONE PAGE
To: ______________   From: ______________   Date: ________
Decision needed by: ________   If no decision by then: ______________________

THE HEADLINE (one sentence: the risk in our terms, and the request)
  _______________________________________________________________________

WHAT IS HAPPENING (two lines, plain words, no mechanism)
  _______________________________________________________________________
  _______________________________________________________________________

WHAT IT MEANS FOR THE ORGANISATION
  What could happen: ______________________________________________________
  How likely (and what that is based on): __________________________________
  How bad, in our work (who is affected, for how long, what is lost): _______
  _______________________________________________________________________

OPTIONS                    A: ____________   B: ____________   C: Do nothing
  Cost (money)             ______________   ______________   none now
  Cost (people's time)     ______________   ______________   none now
  Time to do               ______________   ______________   none
  Risk that remains        ______________   ______________   ______________
  What we give up          ______________   ______________   ______________

RECOMMENDATION (which option, and why, in two lines)
  _______________________________________________________________________
  _______________________________________________________________________

WHAT I NEED FROM YOU
  [ ] Approve option ____     [ ] Decide between ____ and ____
  [ ] Accept the risk of doing nothing, on the record
  [ ] Nothing; for information only

WHAT I DO NOT KNOW, AND WHAT WOULD NARROW IT
  _______________________________________________________________________

------------------------------------------------------------------------
APPENDIX (for readers who want the mechanism; not needed for the decision)
  How it works now: ______________________________________________________
  Evidence and numbers, with sources: ____________________________________
  Questions I expect, and the answers: ___________________________________

Jonas rewrote his backup lecture as this brief that evening. The headline read: "Our backups sit on the same hardware as the live data, so one failure would lose both; I need approval for a second copy kept elsewhere and a decision on how much lost work we can tolerate, by the end of the month." Helen read it in the e-mail on the bus, and chose the option that lost no more than a day's work. She approved it before the meeting, and spent the meeting asking about the appendix, which she had read. The second copy was running within the month. Jonas keeps the brief as a template now and has used it eleven times. He has not been asked "what do you need from me?" since, because it is the first thing on the page.

Frequently Asked Questions