Tideline
Insights
Florida ITSM Meetup · June 2026 (Virtual)
1 / 21▾
How IT teams stop reacting and start improving — without adding headcount.
If your hand went up on any of those — that pattern has a name. And today you're going to leave with a way to break it.
It has a name: The Continual Improvement Gap.
Not a talent problem. Not a budget problem.
A missing operating practice.
Not methodology problems. Organizational problems.
"Everyone's accountable" means no one is. Without a named owner, improvement gets talked about but never happens.
Teams at 100% utilization — all reactive, all the time — have no slack to improve anything. The queue always wins.
47 dashboards, zero consensus on which numbers actually tell you whether things are getting better.
Items go in. Nothing comes out. Your team stops suggesting improvements — because why would they?
These aren't excuses. They're real. But ignoring them has a cost.
Same ticket. Different number. Every week. No visible path to more meaningful work. No reason to stay.
Talented people leave for organizations that have time to build. You backfill constantly. Recruiting becomes the job.
Budget grows. Outcomes don't. Eventually IT stops getting invited to the table — decisions get made without you.
The organizations beating you on IT aren't smarter.
They just built in time to improve.
That's the whole secret.
A structured habit of asking "what can be better?" — and actually doing something about it. On a schedule. With an owner. With a measurement.
ITIL 4 formalizes this as the Continual Improvement Management Practice — one of 34 named practices.
Your team already does this informally.
CI just makes it systematic.
So what does that system actually look like?
W. Edwards Deming's cycle — adopted directly by ITIL 4. Most organizations do Plan and Do — then stop. Everything that makes CI stick lives in Check and Act.
One process. One owner. 30-day target. Measure the baseline before you touch anything.
Execute. Document as you go. Small enough to finish beats ambitious enough to stall every time.
Compare to your baseline. Did the metric move? This is why the baseline wasn't optional — no baseline, no proof.
If it worked: standardize it. If it didn't: revise and run the cycle again. Either outcome is correct. Skip ACT and nothing ever sticks.
In my experience, most teams execute and move on. They never go back to measure whether it worked. Plan and Do get the budget. Check and Act get the results.
Not what you'll fix or how. Why it matters to the business. Align every improvement to the bigger vision.
Data, not assumptions. Measure where you are today so you can prove you improved.
Pick a number. Pick a date. That's your target.
Build the plan. One improvement, one owner, one timeline. Keep it small enough to finish.
Runbooks, value streams, processes, automation — whatever moves the number. Track progress as you go.
Compare to Step 2. Did the number move? Document either way.
Update the register. What did you learn? Loop back to Step 1.
Seven steps. Most teams only do four of them. Let's talk about the ones they skip.
Teams jump straight to measuring. Leadership sees activity but no results — and stops funding it.
Teams assume they know the current state. They don't. No baseline = Step 6 is guesswork.
The plan finishes. Everyone moves on. Old behavior returns within weeks. Without a register, the improvement undoes itself.
Step 7 feeds directly back into Step 1. The output of one cycle is the input of the next. That loop is the practice. Without it, you ran a project — not a CI program. So where does all of this live? That's next.
ITIL 4 names this the Continual Improvement Register (CIR) — a named artifact with one job: make improvement accountable. Most teams have a list. A CIR has six non-negotiables in every entry. Miss one and it becomes a graveyard.
✗ "Reduce our incidents"
✓ 35 open P2 incidents
✓ No escalation path
✓ No vendor SLA tracking
✗ "Better service"
✓ CSF: no P2 open beyond SLA
✓ Ops consumed by firefighting
✓ CSAT 2.4 — contracts at risk
✗ "The IT team"
✓ Service Delivery Manager
✓ Escalation path + comms template
✗ Unranked list of 30 items
✓ High: escalation path (11 P2s unowned)
✓ Medium: vendor SLA tracking
✓ Low: engineer onboarding
✗ "As soon as possible"
✓ P2 backlog under 30 by end of month
✓ Reviewed at monthly backlog review
✗ "We'll know when it's better"
✓ P2 backlog: 35 → 28
✓ Resolution time down 22%
✓ Vendor SLA violations exposed
The register is the tool. But a tool nobody opens doesn't help. It needs a rhythm.
Not a separate initiative. A recurring ritual. Calendar events — not ad hoc conversations.
15 minutes
The CI owner runs a 15-minute standup.
What keeps breaking? What tickets keep repeating? Flag it in the register.
30 minutes
The IT manager reviews the backlog with the CI owner.
Are improvements moving the metric? Reprioritize what's stalled. Remove what's blocked.
60 minutes
The IT director presents results to business leadership.
Before and after. What improved, by how much. This is how IT earns trust and budget.
Half day
Leadership and IT sit down together.
Review the full portfolio. Reset priorities to match next year's strategy.
The weekly standup is the most important. It's the signal that improvement is real — not aspirational.
That's the rhythm. Now let's put one cycle on a calendar.
Monday morning: 35 open P2 incidents. Here's what the Service Delivery Manager does.
Monday to Monday. One loop closed. Now zoom out — what does this look like for a full year?
52 standups. 12 backlog reviews. 4 QBRs. 1 vision to measurements. Now here's what you show leadership at the end of one cycle.
One cycle. Real numbers. The question is — can you do this with a lean team?
You do not need:
You do need:
"The constraint isn't resources. It's the habit."
You have everything you need to start. The question isn't whether you can — it's what changes when you do.
When you commit to the habit, three things start to shift.
When you walk into a budget meeting with before-and-after data, the conversation changes. You're not justifying costs — you're proving value.
Leadership stops seeing IT as a cost center. When you consistently show improvement, you become the team they invite to the table.
The same problems stop coming back. The firefighting drops. People have time to think instead of just react. That's when your best people decide to stay.
That's the destination. The path there has always had one constraint — and it just got smaller.
Time to read what your tickets are trying to tell you.
Every closed ticket is a clue — a pattern, a CI candidate. But nobody has the hours to re-read a quarter of resolved tickets looking for what connects them. So the register stays thin, and the same problems keep coming back.
AI doesn't replace the habit. It removes the excuse not to start. Step 3 of the CI model — gather data — just collapsed from days to minutes. The judgment is still yours. The reading just got done for you.
Let's run it on a real service desk.
Forty closed tickets. Six weeks. One service desk. Resolved. Closed. Moved on. Watch AI find the pattern no single ticket reveals.
A lean IT team. Six weeks of closed tickets — Printing, Email, VPN, Performance, Hardware, Apps. Every one of them resolved and moved on. No new tools. No new data. Just a better question.
The Service Evolution Prompt
Practice-aware. 40 tickets. AI surfaces the hidden Problem.
Practice-aware report
Six artifacts. Six ITIL Practice Owners. One paste.
Not a tool change. A question change.
Export the last quarter of your closed incidents. Paste this prompt into the AI you already have. Open the Problem record AI surfaces for you.
You'll have what you need by lunch.
tidelineinsights.com / blog / service-evolution-prompts
Linked from the same page · save as PDF
Bring the report. We'll map what's next.
By August: come back with what you found. Good or bad — that's the community.
That's the whole framework on one slide. Take a photo. Now let's talk about what happens next.
You just watched AI surface one hidden Problem from forty closed tickets. That's the unlock. You now have the framework, the prompt, and a sample report — Wednesday morning is the starting line.