Home › Topics › Team Knowledge Sharing › Measuring It

Measuring How Far Knowledge Has Spread Across the Desk

Thursday, 15:30, at Oakridge Academy, in the bursar's office for the quarterly review. Nikhil, who runs the five-person IT desk, has spent a year on the things in this series. Those were the grid in the spring, half hours every Tuesday, a huddle every Wednesday, and a handover when a technician left in the autumn. The bursar asks a fair question. "Are we less dependent on Dev than we were?" Nikhil says yes, he thinks so, definitely. The bursar asks how he knows. There is a pause in which Nikhil discovers that he has a year of effort and a strong feeling and no number at all. The feeling, however right, is not going to appear in the minutes.

The feeling is probably correct. That is what makes the pause so annoying. A desk that has done the work can usually tell that fewer tickets wait for one person. It can usually tell that the newest technician takes things she could not have taken in the spring, and that the huddle has stopped producing surprises. None of that is a count, and a manager who is paying for the half hours is entitled to one. The question is which counts, because the obvious ones measure the wrong thing. Measuring the wrong thing for a year is how a desk ends up praised for its documentation the week its only expert leaves.

Measuring knowledge spread is a small set of counts, taken once a quarter from data the desk already has. They show whether what the desk knows is in more heads than it was. Four counts do it. They are how many people resolve each kind of ticket and the bus factor by system over time. They also count how many tickets had to be reassigned because only one person could do them. The last count is how many documents each person wrote, read carefully as coaching. This article is part of our Team Knowledge Sharing series. This article is the last one, because it is the one that tells you whether the other five worked.

It covers why to measure and what not to, then each of the four measures with its counting rule and a worked example from Oakridge's desk. Next come reading the per-person count as coaching rather than ranking and putting the four together. The honest line in the quarterly report, a short war story, and the knowledge spread scorecard to copy come last, in that order.

Why Measure, and What Not To

Measure because the alternative is a feeling, and feelings do not survive the bursar, the budget round, or the week the expert resigns. A desk might say "a year ago five systems had one person who could run them; now two do". That sentence justifies the half hours, points at the next quarter's work, and will still be true when the person who said it has moved on. A desk that can say "we've done a lot of cross-training" has a sentence that is believed in proportion to how much the listener already liked the desk. The counts take about an hour a quarter, from the grid, the tickets and the knowledge base, which the desk already has. They are the only hour in this series that produces something a manager can read.

Do not measure inputs, and most of what desks measure under this heading is an input. Training hours attended measure attendance. Documents written measure typing. Forty articles a quarter is forty articles, and if thirty-eight are user guides to the printing portal, the desk's single points of failure are exactly where they were. Quiz scores measure quizzes. The thing the bursar is actually asking about is whether, on a Thursday when Dev is away, the desk can do what Dev does. The only measures that answer it count what would happen, or what did happen, when a ticket met a person who was not the expert.

Keep every count cheap enough to repeat, because a measure taken once is an anecdote with a decimal point. If a count takes a day, it will be taken once, in the quarter when someone is enthusiastic. In that case, the trend, which is the only interesting part, will never exist. Each of the four below is a filter on the tickets, a row count on the grid, or a column in the knowledge base. None should take more than fifteen minutes once the counting rules are written down. The rules are written down once, at the end of this article, so that next quarter's count is a reproduction rather than an argument. (Arguments about counting rules are how an hour becomes an afternoon.)

Measure One: Resolvers per Category

The first count is, for each kind of ticket, how many different people resolved at least two of them this quarter. A category here is whatever the desk already uses to sort tickets by what they are about. On most small desks, that is close to the list of systems on the grid. The counting rule is to take tickets closed in the quarter and group by category. For each category, count the distinct technicians who were the resolver on two or more. Two, not one, because one is a lucky Thursday; two is a person who can do it. The resolver is whoever did the fixing. On a ticket that was reassigned, that is the person it was reassigned to, not the person who triaged it or the person who clicked close. Those rulings matter enough to write down. And the general rules for which tickets belong to which quarter are in Counting Tickets Properly, which this measure leans on rather than repeats.

Oakridge's count, from a fictional quarter of about four hundred closed tickets, looked like this. Printing: four of five technicians. Accounts and passwords: five of five. Classroom displays: three of five. Wi-Fi: two of five. The timetable system: one of five, and it was Dev. The finance system: one of five, also Dev. Four categories with a single resolver in the spring; two in the autumn. The number to report is the count of categories with only one resolver, and the trend in it. That number is the bus factor measured by what actually happened rather than by what people say they can do.

Two traps. A category with very few tickets cannot score well no matter how spread the knowledge is. If the finance system produced three tickets all quarter, it cannot have four resolvers. In that case, the honest entry is "fewer than ten tickets; not scored" rather than a one that looks like a single point of failure. And a category that scores five of five may still hide a single point of failure inside it. "Accounts and passwords" at Oakridge was five of five because everyone resets passwords. Meanwhile, the one person who could fix the directory synchronisation was still one person. That is the limit of the ticket count, and it is why the second measure exists.

Measure Two: Bus Factor by System Over Time

The second count is the number of systems on the bus-factor grid with one, two, and three or more people who can run them alone. It is taken at each quarterly audit and kept as a series. The grid itself is the subject of The Bus-Factor Audit. This measure is just its row totals, written down each quarter beside the previous quarter's, so that the movement is visible. Oakridge's series ran five singles, then four, then four, then two, over four audits. The flat quarter in the middle was the one in which a technician left and took two "alone" marks with her. The series shows that, and the feeling would have forgotten it.

Count "alone" marks only, with their evidence dates, and the measure stays honest. The grid's weakness is that it is filled in by people describing themselves, and people are optimistic in rooms. So the audit's rule applies with force here. A cell is "alone" only when the person has done the thing without help, on a dated ticket or rehearsal. A series built on "could probably do it" marks goes down beautifully and tells you nothing. A series built on dated evidence goes down more slowly and is the one you want in the report.

Measures one and two should agree, and where they do not, one of them is wrong, and it is usually the grid. Suppose the grid says three people can run the timetable system and the tickets say only Dev resolved any this quarter. One possibility is that the other two never got a timetable ticket, which the triager can confirm. Or they got one and passed it to Dev, which is the third measure's subject. Or the grid is over-claiming. Put the two numbers side by side each quarter. The grid is what the desk believes about itself; the ticket count is what the desk did. The gap between them is the most useful thing on the scorecard, and it should be closing.

Measure Three: Reassignments Because Only One Person Could

The third count is the number of tickets this quarter that were reassigned to a specific person because nobody else could do them. A forced reassignment is the moment the bus factor costs something. A ticket arrives, and the person who picked it up cannot do it. It goes to the one person who can, who was doing something else. Each one is a wait for the requester, an interruption for the expert, and a small confirmation that the knowledge has not spread. Counted per quarter, and by system, it is the cost side of the grid. It is the number that falls fastest when cross-training works. That makes it the most encouraging thing on the scorecard in the first year.

The counting rule needs one habit: whoever reassigns a ticket for this reason writes a fixed phrase in the reassignment note. The phrase is "reassigned: single owner" or whatever three words the desk agrees, used the same way every time, so that a search finds them all. Some tools have a reason field or a tag that does this; most small desks use the note, and the note works everywhere. Without the phrase, the count is every reassignment. That includes the ordinary ones, the misrouted tickets, and the handovers at the end of a shift, and the count means nothing. With it, the count is exactly the tickets that waited for one person. The general counting of tickets that moved between people, and what the other kinds of move tell you, is in Measuring the Cracks. This measure borrows the method and keeps only one reason.

Oakridge counted thirty-one forced reassignments in the spring quarter, twenty-two of them to Dev, nineteen of those for the timetable system. In the autumn the count was twelve, five to Dev, and none for the timetable system, because by then two other people had reached "alone" on it. The requester-facing cost, in hours waited, fell with it. And the interruption cost to Dev, which nobody had ever counted and Dev had been quietly carrying, became a number that could be shown to the bursar. If you run QuerySolv, the complete event history on each ticket holds every reassignment with its note. In that case, the count is a search for the phrase rather than a memory of who passed what to whom. In any tool, the phrase is the measure; the tool only has to keep it.

Measure Four: Articles Written per Person, Read as Coaching

The fourth count is how many knowledge base articles, runbooks and known-error records each technician wrote or substantially revised this quarter. And it is the only one of the four that names a person, which changes everything about how it is read. The number is for coaching and never for ranking, and the rule from the metrics series applies in full. Do not read a per-person figure until there is a minimum sample behind it. Here that means at least a full quarter and at least a dozen documents across the desk. Three articles in a month by five people is noise with names attached. A quarter in which the desk wrote forty documents, and one of the five wrote none, is a conversation.

The conversation is not "you wrote nothing". It is "you resolved more timetable tickets than anyone and there is no timetable runbook; shall we fix that in the half hours?" That is the hero being found by a number and offered a route rather than a mark. The other pattern the count finds is the person who wrote eleven articles that nobody has used. That is not a problem to fix but a thing to notice. It usually means the articles are about the wrong systems or are not findable from the words in a ticket. Both uses are coaching. Neither works if the number has been on a wall screen. The moment a count of documents is public and compared, the desk produces documents, short ones, about easy things, in quantity. The reasons a per-person number should never be a league table are in Dashboards That Motivate Instead of Surveil. And they apply to this count more than to most.

Add a second column beside "written": "used by a second person", taken from the last-used line that every runbook should carry. A technician who wrote four runbooks that three colleagues have since run has moved knowledge. A technician who wrote nine that only they have opened has written a diary. The second column is the one worth more. And it is also the one that cannot be gamed by writing more, which is exactly why it belongs beside the first.

MeasureWhat it countsSource and ruleGood movementThe trap
Resolvers per categoryDistinct people who resolved two or more tickets in each category this quarterClosed tickets; resolver is who fixed it, not who closed it; report categories with one resolverFewer categories with a single resolverLow-volume categories cannot score; mark them "not scored"
Bus factor over timeSystems with one, two, three or more "alone" marks on the grid, each quarterThe audit; "alone" only with a dated ticket or rehearsalFewer singles, quarter on quarter, with datesOptimistic self-marking; compare with measure one
Forced reassignmentsTickets reassigned because only one person could do themSearch the reassignment notes for the agreed phrase; count per quarter and by systemFalling count, and spread across more peopleWithout the fixed phrase the count is every reassignment
Articles per personDocuments written or substantially revised, and documents used by a second personThe knowledge base; a full quarter and a dozen documents before any per-person readingThe heavy resolvers are also writing; "used by others" risingAny public comparison turns it into a count of short easy articles

Putting the Four Together

The four measures answer four different questions, and the scorecard works because of the way they check each other. Measure two says what the desk believes it could do. Measure one says what it did. Measure three says what it cost when it could not. Measure four says who is turning the first three into something that outlasts them. A quarter in which the grid improves and the forced reassignments do not fall is a quarter in which the grid is lying. A quarter in which the ticket count improves and the grid does not is a quarter in which the audit was skipped. A quarter in which everything improves and nobody wrote anything is a quarter that will have to be done again when someone leaves.

Take all four once a quarter, in the same week as the audit, and keep them on one page as a series rather than a snapshot. The first quarter's numbers are a baseline and mean nothing on their own. The fourth quarter's numbers beside the first are the entire case for the series. Oakridge's page, after a year, read: singles five to two; categories with one resolver four to two. It continued: forced reassignments thirty-one to twelve; documents used by a second person nine to twenty-six. Nikhil did not need to say he thought so. The bursar read it in less time than the pause had taken.

Remember: count what would happen and what did happen, never what was typed. Keep four numbers a quarter, from the grid, the tickets and the knowledge base, as a series. The per-person count is read only after a quarter and a dozen documents, and only for coaching.

The Honest Line in the Report

The quarterly report carries one line of knowledge-spread numbers and one line of caveats, and the second line is the one that earns trust. The numbers line is the four counts, this quarter beside last: "Systems only one person can run: 4 to 2. Ticket types with a single resolver: 3 to 2. Tickets that waited for one person: 19 to 12." The caveat line says what moved the numbers that was not the desk's work. A technician left and took two "alone" marks with her; volume in one category fell so its score is not comparable. The finance system had too few tickets to score. A report that gives the good numbers without the caveats is believed once. The format of the page these lines sit on, and the discipline of a number per question, is in The Monthly Report They Will Read.

Report the bad quarter in the same shape, because the bad quarter is where the measures do their most useful work. "Singles: 4 to 4. Forced reassignments: 12 to 15. Cross-training half hours skipped: nine of thirteen" is a line that says the desk had no slack this quarter, in numbers that a manager can act on. It says it without anyone having to describe how the quarter felt. A desk that only reports when the numbers are good is a desk whose reports are read as advertising. A desk that reports the flat quarter with its reason is a desk whose good quarters are believed.

Never let the line become a target. The moment "singles down to zero by year end" is written in a plan, the grid will show zero singles by year end. It will do so by marking people "alone" who have watched a thing once. The measures work because they describe; they stop working the day they are asked to persuade. Report them, discuss them, and let them choose the next quarter's three systems. Leave the targets to things that cannot be gamed by optimism in a room. The bus factor is not one of those things.

A Short War Story: Forty Articles a Quarter at Pennywell Credit Union

Pennywell Credit Union's four-person desk reported one knowledge-sharing number to its board every quarter: the count of knowledge base articles written. That rose from eleven to forty-three over a year and was praised each time as evidence that the desk was reducing its reliance on individuals. The articles were real and mostly good, and almost all were guides for members and staff to the online banking portal. Those were the tickets that came in most and the articles that were easiest to write. The member statement run produced and dispatched statements on the first working day of each month. It had one person who could run it, Agnes, and no article, because it generated no tickets and nobody had drawn a grid. Agnes left for a rival with three weeks' notice in a quarter the report called the best yet. The first statement run after her last day failed on a step nobody had seen. Statements went out eight days late, and the regulator asked why. The desk spent two of those days finding out what the step was. The chief executive had a question at the next board, with the forty-three articles on the page in front of him. How had a number that had tripled described a desk that could not produce a statement? The desk now reports the bus factor by system beside the article count, and the article count is the smaller line. Count what could happen, not what was typed.

The Knowledge Spread Scorecard

The scorecard below is the four measures on one page, as plain text, with the counting rules written in. That way, next quarter's count is taken the same way as this one. Fill it in the week of the audit. Keep the previous quarter's column beside the current one; after four quarters, keep the first and the latest and archive the rest. The honest line and its caveats go to the manager; the per-person block stays on the desk.

KNOWLEDGE SPREAD SCORECARD — ONE PAGE, ONCE A QUARTER
Desk: ______________   Quarter: ________   Taken in the week of the audit by: ________

COUNTING RULES (write once, do not change to improve a number)
  Ticket in the quarter = closed date in the quarter.  Resolver = who fixed it, not who closed it.
  Resolver counts for a category only with 2 or more tickets in it.  Categories under ____ tickets: "not scored".
  "Alone" on the grid = done without help on a dated ticket or rehearsal.
  Forced reassignment = reassignment note contains exactly: "________________________".
  Per-person reading only after a full quarter and at least 12 documents desk-wide.

                                              Last quarter   This quarter   Movement
1. CATEGORIES WITH ONLY ONE RESOLVER              ____           ____          ____
   Which: _________________________________________________________________
   Not scored (too few tickets): _____________________________________________

2. BUS FACTOR BY SYSTEM (from the grid)
   Systems with 1 "alone"                         ____           ____          ____
   Systems with 2                                 ____           ____          ____
   Systems with 3 or more                         ____           ____          ____
   Cells that changed this quarter, with dates: ____________________________

3. FORCED REASSIGNMENTS (search the agreed phrase)
   Total                                          ____           ____          ____
   To the single most reassigned-to person        ____           ____          ____
   By system (top three): _______ ____  _______ ____  _______ ____

4. DOCUMENTS (desk total)
   Written or substantially revised               ____           ____          ____
   Used by a second person (last-used lines)      ____           ____          ____

   Per person (coaching only; never displayed; minimum sample met? [ ] yes [ ] no)
   Name ________  written ___  used by others ___  heavy resolver with no runbook? [ ]
   Name ________  written ___  used by others ___  heavy resolver with no runbook? [ ]
   Name ________  written ___  used by others ___  heavy resolver with no runbook? [ ]

CROSS-CHECK
   Grid says more people can run a system than resolved its tickets?  Which: ______________
   Reason: [ ] no tickets came in  [ ] tickets were passed on  [ ] grid over-claims

THE HONEST LINE (to the manager)
   "Systems only one person can run: ___ to ___.  Ticket types with one resolver: ___ to ___.
    Tickets that waited for one person: ___ to ___.  Documents used by others: ___ to ___."
   Caveats: ______________________________________________________________________
   Half hours skipped this quarter: ___ of ___

NEXT QUARTER'S THREE SYSTEMS (chosen from the above): 1. ________  2. ________  3. ________

Frequently Asked Questions

Our categories do not match our systems. Which should measure one use?
Use whatever the desk already sorts tickets by, because a measure that needs tickets re-sorted first will not be taken twice. If the categories are too coarse to show a single point of failure, add the system name to the resolution note in a fixed form and search for it. Fixing the category list is a separate job, and worth doing, but do not wait for it to start counting.
How big does a desk have to be before these measures mean anything?
Two people is enough for measures two and three, which are about systems, not statistics. Measure one needs enough tickets per category to have two or more resolvers. So on a very small or quiet desk mark most categories "not scored" and lean on the grid. Measure four's per-person reading needs a quarter and a dozen documents regardless of desk size. On a two-person desk it is a conversation rather than a count.
A technician left this quarter and the numbers got worse. How do we report that?
Exactly as it happened, in the caveat line: "one technician left and two systems lost their second owner". The scorecard is describing the desk, and the desk did get more fragile. Report the handover's sign-off states alongside. That way, the manager can see which of the lost marks were replaced during the notice period and which are now the next quarter's work.
Should the scorecard be on the team dashboard?
The desk-level numbers can be, if the desk wants them: singles, forced reassignments, documents used by others. The per-person block never goes on a screen, because a displayed count of articles turns into a contest to write short ones. Keep that block in the lead's folder and bring it out in one-to-ones.
Can we count ticket resolution time by system as a fifth measure?
You can watch it, and it often improves as knowledge spreads, but do not add it to the scorecard. Resolution time moves for many reasons that have nothing to do with knowledge, such as volume, vendors and the mix of tickets. A scorecard with a number on it that can move for the wrong reason is a scorecard people stop trusting. Four counts that only move when knowledge moves are enough.
What is a good number to aim for?
There is no benchmark, and the scorecard is damaged by having one. The useful reading is the direction over four quarters on your own desk: fewer singles, fewer forced reassignments, more documents used by a second person. It comes with a caveat line that explains what moved for other reasons. A desk that reaches zero singles has usually been optimistic on the grid. A desk whose series falls steadily with dates against each cell has done the work.

From the QuerySolv team: we build self-hosted help desk software for Windows. QuerySolv runs as one Windows service on your own network. It takes requests by web form, e-mail, live chat, social messages and REST API. It is licensed once per installation rather than per agent per month. The free trial runs the full product for 30 days.