Making the Invisible Work Visible Without Boasting

Thursday, 14:10, the budget review at Ashgrove Housing. Tom runs the three-person desk and has just been asked a question by Priya the finance director. Her tone is curious rather than hostile: "What does IT actually do all day? Tickets are down on last year." Tom knows the answer. In the last quarter the team patched every server on a schedule. They renewed four certificates that would have taken the tenant portal down in the night. They retired a laptop model that had failed nine times in a year. They tested a restore from backup for the first time in anyone's memory, and tuned the mail filter so that the phishing reports fell by a third. None of it was a ticket. All of it is why tickets are down. Tom says "quite a lot, actually", which is true, and which convinces nobody.

Invisible work is work that produces no ticket, no outage and no visible event when it succeeds, which is most of what an IT department does. It is the patch that was applied, the certificate that was renewed in time, and the capacity added before the disk filled. It is the backup that restored when tested and the change made at six in the morning so that nobody noticed it. When it goes well, nothing happens, and nothing happening is not news. This article is part of our IT's Internal Brand series. It is about the only cure for invisible work: write it down once a month in a note that people will read.

It covers the iceberg, and what sits above and below the line. Next comes why nobody sees the work, and why that is partly the desk's own doing. The three kinds of invisible work and how each is counted follow. Then come the monthly note, who gets it and what shape it keeps, and the change note. The article covers the outage that did not happen and how to report it honestly, then saying all of it without boasting. A short war story and the monthly what-we-did note to copy follow, in that order.

The Iceberg

Picture the desk's work as an iceberg, with a waterline at the level of what the organisation can see. Above the line is the visible work. It includes the tickets closed and the wait for them, the outage everyone noticed, and the printer that took two days. It includes the request that was declined and the reply that sounded like a policy. Below the line is everything else, and it is most of the mass: the prevented, the maintained and the planned. The organisation forms its opinion of IT from the tip, because the tip is all it can see. The desk is exhausted by the whole thing, and cannot understand why nobody notices.

The picture explains the budget meeting. Priya is not being unfair; she is reading the only instrument she has, which is the tip, and the tip got smaller. From where she sits, less visible work means less work. From where Tom sits, less visible work means the invisible work succeeded. Both are reading the same iceberg from different sides of the waterline, and nobody has drawn the waterline for her. That is the desk's job, and it is a writing job rather than a technical one.

The waterline is not fixed. A desk that reports only tickets keeps it high, so that almost everything it does is under the water. A desk that writes a monthly note moves the line down, a little at a time. Eventually the organisation can see the prevented and the maintained as well as the fixed. The iceberg does not get bigger. It gets seen.

Why Nobody Sees It, and Why That Is Partly the Desk's Doing

The first reason is the asymmetry built into the work itself. A failure has a start time, an end time and forty witnesses, and a success has none of those. When the certificate is renewed in time, the tenant portal stays up, which is what it was doing yesterday, and no one experiences the difference. The organisation cannot be expected to notice an absence. It can only be told about one, by the people who arranged it.

The second reason is the desk's own habit of not recording the work. Prevention happens between tickets, at the quiet end of the afternoon, or on a Saturday morning with a change window. It is done by one administrator from a list in their head, and the only record is that they were tired on Monday. Most desks log the work that comes in and not the work they decide to do. That means their own tool cannot tell them what they prevented. The strategy of choosing that work and protecting the time for it is the subject of From Reactive to Proactive Support. This article assumes some of it is happening and asks only that it be written down.

The third reason is a kind of professional modesty that is really a professional mistake. Administrators tend to feel that saying "we renewed four certificates" is either obvious or boastful, and that the proper reward for good maintenance is silence. The silence is real. The reward is not. A desk that never says what it did has agreed to be judged on the tip of the iceberg. The tip is where the printer lives.

The Three Kinds of Invisible Work

Invisible work sorts into three kinds, and each is counted differently. That matters because the monthly note needs a number or a fact beside each line. The three kinds give up their numbers in different ways. Prevented work is the thing done so that a failure would not happen: the patch, the renewal, the lemon model retired. Maintained work is the thing done so that something keeps working as it does: the backup test, the capacity added, the accounts cleaned up, the licences reclaimed. Planned work is the thing done toward something new, before anyone has seen it: the roadmap item progressed, the upgrade rehearsed, the quiet change that went in on Sunday. The table gives each a worked example and the sentence it becomes in the note.

Prevented work is the hardest to count honestly, because its value is a thing that did not happen, and the next section but one is about that. Maintained work is the easiest, because it is a list of actions with dates, and a date is proof. Planned work is counted in steps rather than outcomes, and the note should say the next step as well as the last. That is because a reader who knows what is coming next month is a reader who will not be surprised by it.

Where the desk does its own work as tickets, the counting is a filter rather than a memory exercise. A ticket opened by the desk for itself, "renew portal certificate, due in three weeks", closed with a note when done, is both the reminder and the record. At month end it is a line in the note with no effort. Most tools allow the desk to raise tickets to itself. If yours does, the invisible work becomes visible to the queue first and the organisation second. The queue is the harder audience.

The Monthly Note: What It Is and Who Gets It

The monthly what-we-did note is one page, sent on the same day each month to the same list of people. It uses the same five sections every time, saying what the desk fixed, prevented, maintained, changed and will do next. It is not a report, though it borrows from one. The monthly report of numbers for leadership is its own thing, built in The Monthly Report They Will Actually Read. The note links to it or sits beside it rather than replacing it. The note is written in sentences, for people who will never open a report, and its job is to move the waterline.

The list of readers is wider than the report's and narrower than "all staff". Send it to the managers of every department, the finance director, whoever the desk reports to, and anyone who has ever asked what IT does all day. Many desks also post it where staff can find it, on the intranet or in the knowledge base. That is fine as long as the managers get it directly. A note that is merely available is a note that is not read. Keep the list stable. The note's value comes from being the same shape in the same inbox on the same day. That lets a reader who has seen six of them read the seventh in a minute.

Each section is short and each line is a fact. "Fixed" is two or three sentences with the month's counts: tickets in, tickets closed, the oldest open one and why, the biggest single thing. "Prevented" and "Maintained" are the lists from the table, each line an action, a date and, where the history supports it, what it would have cost. "Changed" is the change note, covered next. "Next month" is three lines at most, each with a date, including anything that will interrupt anyone. Five sections, one page, no adjectives. The adjectives are the reader's to supply, and they will, if the facts earn them.

Write it on the first working day of the month, from the queue and the desk's own tickets, in under an hour. If it takes longer, the desk is not recording its work during the month and is reconstructing it from memory. That is the problem the note exists to fix. If you run QuerySolv, the standard reports on volume, backlog by age and response and resolution times give the "Fixed" section its numbers without a spreadsheet. Any tool with the same reports does the same. The rest of the note comes from the desk's own tickets. If there are none, it comes from the honest sentence "we did not record this month's maintenance, and will from now on". Say it once. It is a surprisingly effective sentence, because it is true and nobody expected it.

The Change Note

The change note is a paragraph, sent before and after any change that touches people's working day. It says what will change, when, what they will notice and what to do if something is wrong afterwards. It is the one piece of visibility the desk should never skip. That is because a change nobody was told about is experienced as an outage even when it worked perfectly. "The printers look different this morning" is a help desk ticket. "The printers will look different from Tuesday, here is what changed, here is the one-page guide" is a note that prevents thirty of them.

The change itself has its own record and its own review, and those live in The One-Page Change Record. The note is the public face of that record, in plain words, with the technical reason left out unless someone asks. For the notice itself, the timing and the wording that people read rather than delete are in Planned-Maintenance Notices People Actually Read. The monthly note simply lists the month's changes with a sentence each, linking to the notices that went out. A change that appears in the monthly note for the first time, after the fact, is a change that was not announced. The reader will notice, and should.

The change note also does something for the brand that no other piece of writing does. It shows the desk choosing to disturb people as little as possible and saying so. "Done at 06:30 on Saturday so that nobody was working" is a sentence about consideration, and it is the kind of sentence that gets repeated. The desk that announces its changes is believed about its outages. The desk that does not announce them is suspected of causing every one.

The Outage That Did Not Happen

The hardest line to write in the note is the value of a failure that was prevented. The rule is that the desk may describe what it did and what the same failure cost last time. The desk may not invent a number for what it saved. "We replaced the failing storage controller before it failed" is a fact. "The last time this controller failed, the file service was down for six hours and 140 people could not open documents" is a fact, if the ticket history shows it. "We saved the company 840 hours" is a claim, and the moment it is challenged the whole note loses its credibility. Give the reader the two facts and let them do the multiplication. They will, and their number will be believed, because they produced it.

Where the history gives a range rather than a point, give the range. "The nine laptop failures on the retired model cost between two and five hours each in lost work and a desk visit" is honest, and the reader can see both ends. Where there is no history, say so: "we have no record of what this failure cost before, because it has not happened here; we replaced it because the model is known to fail". The arithmetic for turning prevented failures into hours, in ranges, with the fictional-desk discipline that keeps it honest, is in Measuring the Shift to Proactive. The note borrows the result rather than redoing the sums.

Some prevented work has no countable outcome at all, and belongs in the note anyway, as an action with a date. A patch applied on time prevents a risk, not a specific outage. The note says "patched 22 servers on schedule; none outstanding", which is a fact about diligence rather than a fact about savings. Readers understand the difference. What they cannot do is value the diligence they were never told about. The outage that did not happen is only visible if someone says, in plain words, that it was going to.

Saying It Without Boasting

The note is read as boasting when it contains adjectives, and as information when it contains facts. The whole craft of writing it without sounding like a brochure is in that one distinction. "The team worked incredibly hard to deliver a seamless migration" is a brochure. "Migrated the finance file share on Saturday; 1,900 folders; two permission problems reported on Monday and fixed by ten" is a note. The second is more impressive than the first and does not ask to be admired. Facts carry their own weight. Adjectives ask the reader to carry it for them.

Include the thing that went wrong, every month, in the same plain voice. "The portal was down for forty minutes on the 9th, because a change we made had an error in it; we have added a check to the change record so that it is caught next time." A note that contains only successes reads as an advertisement and is discounted as one. A note that contains the failure, briefly, with the fix to the process, reads as an honest account and is believed about everything else in it. The failure paragraph is the one that buys credibility for the prevented paragraph. Leave it out and you have paid for nothing.

Credit the people outside IT who made the work possible, by name and briefly. Examples are the facilities manager who found the change window and the finance team who tested the restore with the desk. Another is the manager who pushed her team to use the new form. Giving credit costs nothing and it is true. It changes the note from "what IT did" to "what got done", which is a story more people want to be in. It also spreads the brand to the people who will repeat it. Someone named in the monthly note tends to mention it.

Write in the voice the desk uses everywhere else: plain, named, in the first person, with no jargon and no policy tone. The style itself is owned by Support Tone and Voice. The way it shows up in signatures, auto-replies and signs is the subject of the next article but one in this series. Here the only rule is that the note sounds like the people who wrote it. If the reader cannot tell who wrote it, nobody will reply to it, and replies are how you know it was read.

A Short War Story: The Laptops Nobody Heard About at Redbrook Engineering

Kofi ran the two-person desk at Redbrook Engineering and, over one winter, quietly replaced the firm's worst laptop model. Those were twenty-six machines whose failures had been filling the queue every month. He replaced them with a different model that then failed not at all. He told nobody outside IT, because it seemed like ordinary work, and the laptop line in the queue dropped from about fourteen tickets a month to two. At the spring budget review the operations director was looking at the lower ticket count and a request for a laptop replacement cycle. The director said that laptops did not seem to be a problem and cut the cycle from the budget. Kofi, who had not brought the before-and-after, could not show in the room that the quiet had been bought. The old model's remaining machines, in the drawing office, went on failing for another year. Kofi later put the cost at somewhere between sixty and a hundred hours of engineers' time and one lost week of drawings. The cycle was approved the following spring, with the before-and-after on one page. Prevented work that is never reported is treated as work that was never needed, and the budget is where that treatment is applied.

The Monthly What-We-Did Note

The note below is the one-page shape, with the five sections in the order readers have come to expect them. Each section has a line for each fact that belongs in it. Fill it from the queue and the desk's own tickets on the first working day of the month. Keep it to a page, and send it to the same list on the same day. The last two lines are there to stop it drifting: a note that has to say who wrote it and when the next one is due tends to arrive.

WHAT IT DID IN ____________ (MONTH) — ONE PAGE
From: ______________ (name)        Sent on: ____________        To: the usual list

1. FIXED
   Tickets in: ____   closed: ____   open at month end: ____   oldest open: ____ days, because ______________
   The biggest single thing this month: __________________________________________________
   What went wrong, and what we changed so it does not again: ______________________________

2. PREVENTED (actions with dates; what the same failure cost last time, from the record)
   - ______________________________ on ______ . Last time: ________________________________
   - ______________________________ on ______ . Last time: ________________________________
   - ______________________________ on ______ . No previous record.

3. MAINTAINED (actions with dates; when it was last done)
   - ______________________________ on ______ . Previously: ______
   - ______________________________ on ______ . Previously: ______
   - Patching: ____ of ____ systems on schedule; outstanding: ____

4. CHANGED (one line each; link to the notice that went out beforehand)
   - ______________________ on ______ at ______ . Noticed by users as: ___________________
   - ______________________ on ______ at ______ . Noticed by users as: ___________________

5. NEXT MONTH (three lines at most; anything that will interrupt anyone comes first)
   - ______________________________ on ______ . Who it touches: ____________________
   - ______________________________ on ______ .
   - ______________________________ on ______ .

Thanks this month to: ______________________ (outside IT, by name, for what)
Questions and corrections to: ______________ . Next note: ____________

Tom sent the first one at Ashgrove Housing a week after the budget meeting. It had the four certificates, the retired laptop model, the restore test and the mail filter in it. A line at the top said that the desk had not reported this work before and would from now on. Priya replied within the hour, which no monthly report had ever achieved. She asked two questions, one of which was what the next certificate renewal would need from finance. The waterline had moved about an inch. It moves an inch a month, and after a year the organisation can see most of the iceberg. That is as much as any desk should want.

Frequently Asked Questions