The Limits of Shift-Left: What Must Stay, and When to Stop

Friday, 16:45, at Acme. Hannah, who runs the desk, has had two good quarters. Nine ticket types moved from the specialists to the front line, with the escalation rate for those types down to almost nothing. She had a report to the operations director that she was proud of. This afternoon three things have landed on her at once. Sol on the front line has fourteen tickets open, nine of them the types that were moved to him this year. The queue's first-response time has crept from forty minutes to over two hours without anyone deciding it should. The reopen rate for the mailbox-rule fix, one of the nine, has doubled since it moved. And there is ticket 8831, from this morning. A user asked Sol to "do the thing you did for Priya's mailbox last week". Sol recognised the same fix and did it. The mailbox this time belonged to the HR director. The thing was a delegation change that should have had an approval on it. Nobody did anything wrong on purpose. Three limits were crossed in one afternoon, and the report had shown none of them.

The limits of shift-left are the places where moving a resolution down the staircase costs more than it saves. There are four of them. One is the ticket types that must stay with the specialists whatever the hours say. Another is the front line that cannot absorb another type without something else giving. A third is the quality that drops when a runbook is stretched past what it was written for. The last is the user who should not be asked to self-serve even when the type is safe. A strategy without written limits is run by its own momentum, and the momentum is always downward. This article is part of our Shift-Left Strategy series. It is the one that says where the staircase ends.

It starts with why a good strategy needs a written stop. Then it covers what must stay with the specialists, in security and in data and changes. Next come the front line overloaded by the shift, the quality drop and how to see it early, and the user who should not self-serve. A table covers the honest trade-offs. Then it explains how to know when to move a type back up. A short war story and the shift-left limits list to copy finish the article.

Why a Good Strategy Needs a Written Stop

Shift-left is measured by what moved, and anything measured by what moved will tend to move everything. The report Hannah was proud of counted types moved and escalation rate falling. Both numbers improve whether the moves were wise or not, right up to the quarter when something breaks. The limits exist to be read on the days the numbers look good, because those are the days a desk reaches for the tenth type without asking whether the ninth has settled. Enthusiasm is a fine thing in a desk lead and a poor thing in a strategy, and the written limit is how you keep the first without letting it run the second.

The limits also protect the front line, who are the people least able to say no to a move. A technician handed a runbook and a permission will take the type, because declining looks like declining to grow. They will say nothing when the fourteenth ticket lands on a Friday, because saying something looks like complaining. The limit written by the lead is the front line's permission to stop, in the same way the runbook's limit is their permission to escalate. Both are things the desk gives in writing because nobody will ask for them aloud.

What Must Stay With the Specialists: Security

Nothing that depends on verifying who a person is moves down a step in the form of a shortcut. The front line already performs the verification standard for a password reset, and it is the standard that does not move. The questions, the checks and the refusal when they fail are the same on the front line as they would be with the specialist. No runbook may contain a faster version because the requester was in a hurry or senior or known to the technician. The standard, and why it must be identical for everyone, is in Verifying Identity Before a Reset. Shift-left can make the reset itself cheaper. It cannot make the question "is this really you?" cheaper, and a desk that tries has shifted its security left and out of the building.

Anything whose symptom might be a security event stays as a triage, not a fix. The front line triages a reported phishing message and a user who says "I clicked something" by a flow written for that purpose. The flow ends in a handoff to whoever owns security, with containment steps the desk is allowed to take and nothing more. The flow is in The Phishing Triage Flow. The shift-left mistake is to notice that most such tickets turn out to be harmless and write a runbook that resolves them on the front line as "harmless, closed". The runbook will be right nineteen times. The twentieth is the one the organisation remembers, and the runbook will be the exhibit.

Access changes stay with an approver, and the approver is not the technician. Granting a right, delegating a mailbox, adding someone to a group with data in it: each is a decision with an owner. The ticket carries the owner's approval before the technician does anything, whichever tier the technician is on. Ticket 8831 was not a shift-left failure because Sol could not do the delegation; he could, correctly, in four minutes. It was a failure because the runbook for "delegate a mailbox" had moved to the front line without a crucial line. That line said "only with the mailbox owner's approval on the ticket". The fix was the easy part. The approval was the whole ticket.

What Must Stay: Data and Changes

Anything irreversible stays until there is a reversible version of it. Consider restoring a file over the current copy, resetting a device, deleting a mailbox, or clearing a queue of jobs that cannot be re-submitted. The specialist does these with a backup taken first and a known way back. A runbook that gives the front line the action without the backup has given them a way to make a mistake permanent. The restore workflow, with its "copy aside first" step that exists for exactly this reason, is in The Restore Workflow. A front line can run it, and should. The step that makes it safe is the one no shift-left runbook may drop to save time.

Anything that changes a shared system is a change, and a runbook is not a change record. That includes restarting a service that forty people use or altering a setting on the file server. It includes updating the room system's firmware because the runbook for "room screen blank" happens to end that way. Each one needs the question "what else does this touch, and when is it safe?" The question is answered by the change process, not by the technician at step six. What needs a review before it is done and what does not, drawn for a small desk without a change board, is in What Needs Review and What Does Not. The rule for shift-left is simple. A runbook may contain a change only if the change is pre-approved as a standard one, in writing, with the conditions under which it may be run. The runbook must say so at the top.

Judgement stays where the judgement is. A ticket type whose fix is "decide whether this is worth doing" is not a procedure. Writing it as one produces a front line that either always says yes, because the runbook ended in yes, or always escalates. In the latter case, they escalate because they can tell it is a decision and do not feel allowed to make it. Exceptions to policy, prioritisation of a senior person's request against the rules, whether a user's unusual software is a risk: these are the specialist's or the lead's. The front line's runbook for them is one line long and says who to ask. That is not a failure of shift-left. It is shift-left working as designed, which includes knowing what it is not for.

The Front Line That Is Overloaded by the Shift

The hours move; they do not vanish. A type that cost the specialist half an hour a ticket and costs the front line twelve minutes has freed eighteen minutes a ticket from the desk. It has added twelve to the front line. The front line's twelve come out of the same working day as the phone, the walk-ups and the queue. At Acme the nine moved types freed about twenty hours a month at the specialist step and added about eleven to the front line. That is a good trade for the desk and a bad week for Sol, because nobody had asked whether Sol had eleven hours. He did not. The hours came out of first response, which is why the queue's forty minutes became two and a half. That is why the requesters of every other ticket type were quietly paying for the shift.

The sign is first response rising for the whole queue, not for the moved types, and it appears before anyone on the front line says anything. Watch the first-response figure monthly during a shift-left programme and treat a rise as a load signal rather than a performance one. If you run QuerySolv, response targets are set per priority on a business-hours schedule and the response figures are on the standard reports. In that case, the signal is already on a page somebody reads. In any tool, the median time from ticket opened to first human reply, by month, is the number. When it climbs in the quarter after a move, the move has overloaded the front line, whatever the escalation rate says.

The rule is that a type moves down only when the receiving step has the hours, and "has the hours" is a number, not a feeling. Measure the front line's load before the move, in tickets and in interruptions, and decide what will go to make room. That could be a type moving on from the front line to self-service, a walk-up culture being redirected, or a hire. How to measure load honestly, including the interruptions that never become tickets, is in The Interruption Load. A desk that cannot measure its front line's load should not be shifting work onto it. It will not see the overload until it reads it in a resignation. Shift-left done to a full front line is the specialist's problem relocated to the people with the least power to object.

The Quality Drop, and How to See It Early

The quality drop is a runbook stretched past the case it was written for, and it shows up as reopens before it shows up anywhere else. The mailbox-rule fix at Acme had moved cleanly for three months. Then a new mail client rolled out. The runbook's step four referred to a menu that had moved. The front line, who could not see that anything had changed, kept running it. The fix now cleared the wrong rule, the user's mail kept misbehaving, and the ticket came back two days later. Escalations for the type stayed low, because the front line believed they had fixed it. Reopens doubled. The runbook had become wrong without becoming visibly wrong, and the only number that noticed was the one nobody had put on the shift-left report.

Read three numbers together for every moved type, and read them for the type alone, not for the desk. Escalations falling is the point of the move. Reopens flat is the proof the fix still works. Satisfaction flat, or the free-text comments not mentioning the type, is the proof the users agree. Escalations down with reopens up is a front line that has stopped handing the type up and has not started fixing it. Escalations down with satisfaction down is a front line resolving the ticket in the tool and not in the room. The honest way to count a reopen, including the fresh ticket that is really a reopen in disguise, is in Measuring Reopens Honestly. The last article in this series puts the three numbers on one scorecard. One number on its own is a target. Three together are a measurement.

The "same fix" generalisation is the quality drop's other face, and it is the one in ticket 8831. A front line that has learned a runbook well starts to see its pattern in tickets it was not written for, and applies it. Pattern-matching is what good technicians do and the runbook taught them the pattern. The defence is the recognition test at the top of every runbook, re-read when the symptom is familiar but the context is not. It also includes the limit line that names what the runbook must never be used for. Praise the technician for seeing the pattern. Then add the sentence to the runbook that says where the pattern stops.

The User Who Should Not Self-Serve

Some people should be given the fix and no link, and the desk should be able to say who without embarrassment on either side. The user who is locked out with a deadline in twenty minutes is not a candidate for an article, however good the article is. They need a person, now, and the article can be mentioned afterwards or not at all. The user who has already tried the article twice and raised a ticket has told the desk that self-service failed for them today. The reply that sends them back to it is a reply that says the desk did not read the ticket. For some users, the steps are physically or practically out of reach because of how they work, where they are or what they can see on the screen. For those users, the fix is the desk's job in full. The clinician mid-shift, the driver at a depot, the person on the phone from a site with no second screen: these are not people who failed to self-serve. They are people for whom the staircase has one fewer step.

The sentence "I'm not technical", said by a requester, is a request for a person. It should be honoured as one, every time, without a sigh that can be heard down the line. The desk's job is to resolve the problem, and self-service is a way of doing that for people who prefer it, which is many people and not all people. A desk that measures its self-service share and tries to push it up by sending links to people who asked for help has confused the measure with the mission. The share goes up when the article answers the question before the person asks. It does not go up, honestly, by declining to answer when they ask anyway.

Write the exceptions down so the front line does not have to invent them under pressure. Say who gets a person first and which situations get a fix and no link. Include the rule that a ticket raised after the article was tried is a ticket, not a deflection. Then count accordingly. A "sent the link" reply is not a resolution and is not a deflected ticket. A desk that counts it as either will have a self-service figure its users would not recognise. The figure is supposed to describe what happened. This is the part of shift-left where the desk's values are visible in its counting rules.

The Honest Trade-Offs

Every move down the staircase buys one thing with another, and the table below names the price beside the purchase, with the sign that the price has become too high. None of the trades is wrong. Each of them has a point past which it is, and the point differs by desk, which is why the sign is the useful column.

Knowing When to Move a Type Back Up

Moving a type back up a step is an ordinary part of the strategy, not a failure of it. A desk that cannot do it will keep a bad move for years because reversing it would mean admitting it. The procedure is short. The type's resolving step on the map goes back up. The runbook gets a line at the top saying "escalate this type until further notice; see ticket number". The front line is told the same day and thanked. The reason is written on the map in one sentence. Then the gap that caused the retreat is worked on, and the type comes back down when it is closed. At Acme the mailbox-rule type went back to the second line for six weeks while the runbook was rewritten for the new client. Nobody minded. The front line had nine other types and one fewer Friday.

Review the limits once a quarter, with the scorecard beside them, and ask three questions of every moved type. Is it still off the stays list, or has something about it changed, a new approval, a new system, a new risk? Does the receiving step still have the hours, now that two more types have landed on it? And do the three numbers for the type, escalations, reopens and satisfaction, still look like a move that worked? A type that fails any question is discussed, and the discussion ends either with an action or with a move back. (It is allowed to end with "we were lucky". It is not allowed to end with nothing.)

Say the limits out loud to whoever reads the shift-left report, so that the next quarter's report can show a type moving back up without it reading as a reversal. A manager who was told "we move types down one step at a time, and some will come back up while we fix the runbook" will read a retreat as the system working. A manager who was shown only the escalation rate falling will read the same retreat as the programme failing. The limits are part of the story, and they are the part that makes the rest believable.

A Short War Story: The Running Batch at Kestrel Payroll

Kestrel Payroll's desk had moved the "payroll batch lock" ticket to the front line. The runbook said to clear the lock file when the batch screen showed the lock error. The lock error almost always meant a batch that had crashed and left its lock behind. The specialist, Nadia, had cleared it that way forty times. On a month-end Thursday a payroll clerk, Omar, raised the ticket because the screen showed the lock error. The front-line technician cleared the lock as the runbook said. The batch that held it was still running on the server and had been for twenty minutes. The batch wrote its second half over a file another process had started. The month's run for about three hundred employees had to be rebuilt by hand over two days. The clerks who did the rebuilding were the same ones who had been waiting for the batch in the first place. The runbook had never said "check that the batch process is not running before you clear the lock". Nadia checked it with a glance she had never described. The runbook had never said that clearing a lock on shared payroll data was a step with no undo. The rewritten runbook stops at the check and escalates if the process is alive. The clearing step has gone back to the second line, where it sits with the other actions on shared data that have no way back. A step that changes shared data with no way back does not move down the staircase, however many times it was harmless.

The Shift-Left Limits List

The list below is one page for the whole desk, not one per type, and it is written before the first move and read at every quarterly review. Section A is the stays list, which applies regardless of volume. Section B is the load rule for the receiving step, with its number. Section C is the three numbers read per moved type and the retreat rule. Section D is the user exceptions, written so that the front line can apply them without a decision. Put it on the knowledge base's page for the desk, beside the shift-left map, and date it; the version with the most crossings-out is the one that has been used.

THE SHIFT-LEFT LIMITS LIST — ONE PAGE FOR THE DESK
Desk: ______________________   Written by: ______________   Reviewed quarterly on: ____________

A. TYPES THAT STAY WITH THE SPECIALISTS OR AN APPROVER, WHATEVER THE VOLUME
   [ ] Anything requiring identity verification: the standard does not move or shorten
   [ ] Anything whose symptom may be a security event: triage flow only, never "harmless, closed"
   [ ] Any change to another person's access, delegation or data: approval on the ticket first
   [ ] Anything irreversible without a backup taken first: restores, wipes, resets, deletions
   [ ] Any change to a shared system, unless pre-approved as standard, in writing, with conditions
   [ ] Any step on shared data with no way back
   [ ] Any fix that is really a decision: exceptions, priority disputes, risk calls
   Desk-specific additions: ______________________________________________________

B. THE LOAD RULE FOR THE RECEIVING STEP
   Front-line load measured before each move: open tickets per person ____  interruptions per day ____
   A type moves down only if: front-line median first response is under ____ and has been for ____ months
   What leaves the front line to make room for the next type: __________________________
   Owner of the load check: ______________

C. THE THREE NUMBERS, PER MOVED TYPE, READ TOGETHER EACH MONTH
   Escalations of the type: falling          Reopens of the type: flat          Satisfaction: flat
   Any of: reopens up / satisfaction down / first response up across the queue  =>  discuss this month
   The retreat: type goes back up one step; runbook marked "escalate until further notice"; front line told
   and thanked the same day; reason written on the map in one sentence; gap worked; type returns when closed
   Moves back up this quarter: ____   Reasons: ___________________________________________

D. USERS WHO GET A PERSON, NOT A LINK
   [ ] Locked out or blocked with a deadline inside the hour
   [ ] Has already tried the article and says so
   [ ] Cannot practically follow the steps where or how they work
   [ ] Says "I'm not technical" or asks for a person
   [ ] Desk-specific: ______________________________________
   Counting rule: a ticket raised after the article was tried is a ticket; "sent the link" is not a resolution

E. SIGNED
   Desk lead: ______________   Specialist(s): ______________   Front line: ______________

Hannah wrote Acme's list on the Monday, with Sol and the specialist, Bart, in the room. The first version had eleven desk-specific additions to section A. Bart had been applying most of them from memory. Sol had never been told those additions. The mailbox delegation type went back to the second line with an approval line added. The mailbox-rule runbook was rewritten for the new client. The load rule in section B came out at a number that said the front line could not take another type until two had moved on to self-service. The next report to the operations director had a type moving back up on it, explained in one sentence. It was the first report she had asked a question about. The question was "what else is on the stays list?", which is the right one.

Frequently Asked Questions