Plenty has been written about why operations teams should prepare for AI-assisted operations. Far less about what, specifically, to do on Monday. This list closes that gap. Nine moves, in rough order, each one concrete enough to put on a sprint board. No philosophy, minimal theory — just the actions that separate teams who end up supervising intelligent automation from teams who end up as cautionary tales in someone’s conference talk.
1. Run a two-week drudgery audit
Before anything else, measure the problem. Have every team member tally time spent on recurring operational chores — scheduled health checks, post-deploy alert sifting, ritual service restarts, capacity eyeballing, status reporting. Use a shared sheet, keep categories crude, and resist the urge to fix anything yet. The output is a single number: hours per week of repeatable work. That number funds everything that follows, both politically and literally. Teams routinely discover the equivalent of a full-time engineer dissolved into chores nobody chose.
2. Tag each chore as pattern-shaped or judgement-shaped
Go through the audit line by line and ask: does this task follow a detectable pattern (candidate for machine help), or does it require context a machine lacks (keep it human)? Restarting a service with a known failure signature: pattern. Deciding whether a traffic spike is a marketing win or an attack: judgement — at least initially. Expect roughly half your list to land in the pattern column. That half is your automation backlog, pre-prioritised by the hours attached to each line.
3. Baseline your alert precision today
Pick a recent fortnight and compute: of all the alerts the team received, what fraction led to action? Most teams score depressingly low, and that score is your before photo. Intelligent monitoring earns its keep partly by raising this number, but you can only prove it if you measured the baseline while things were still noisy. Thirty minutes of log archaeology now saves you an unwinnable ROI argument later.
4. Nominate two people for deep training — never one
One trained person is a bus-factor problem wearing a certificate. Pick two: ideally one senior engineer who knows your estate’s folklore and one hungry mid-level who will do the homework. Formal, sequenced study beats tutorial roulette here, because the skill set — teaching software what normal looks like, judging statistical deviations, bounding automatic repairs — hangs together as a discipline. A dedicated provider such as AIOps School structures it as a climbable credential ladder that starts at Foundation level and tops out at Architect; the practical sweet spot for your two nominees is the engineering tier, a six-to-seven-week commitment that covers building detection models, wiring up monitoring stacks and scripting contained self-repair, practised in sandboxed labs rather than on your production estate. The knowledge-gap problem is real and well documented — we mapped its contours in our practical guide to the knowledge gaps students must fill — and structured curricula exist precisely because scattered self-study keeps failing to close it.
5. Put the training hours on the actual schedule
The most common failure mode is not bad training; it is phantom training — approved in principle, erased in practice by the on-call rota. Treat study blocks like production incidents: visible on the calendar, protected, rescheduled only with the same ceremony you’d apply to skipping a postmortem. A dozen hours a week for the deeper track is the honest requirement. If your team genuinely cannot find them, you have just discovered your drudgery audit’s first use case: that is exactly the time the automation will eventually return.
6. Deploy in listen-only mode while they study
Parallelise. Stand up monitoring across five to ten services with every action feature disabled. The system needs weeks to learn your rhythms anyway — release days, batch windows, the Monday-morning login surge — and your trainees will graduate into a system that already has baselines worth tuning. Zero risk, meaningful head start, and the early curiosities it surfaces (there is always a forgotten cron job nobody can explain) make excellent show-and-tell for sceptics.
7. Institute a weekly flag-grading ritual
Once baselines exist, convene thirty minutes a week where the team grades every machine-raised flag: genuine, benign or noise. This single meeting does triple duty — it tunes sensitivity with human judgement, it spreads literacy beyond your two specialists, and it builds trust at a measurable rate instead of demanding it by decree. Credentials certify knowledge, but this ritual is where knowledge becomes shared team judgement; the distinction matters for careers too, as we argued in our assessment of what certifications are really worth in tech careers.
8. Graduate automatic fixes one at a time, with a named auditor
When a flag type has proven reliable and its fix is boring — restart this, clear that, re-run the other — promote it to unattended execution. Rules: one promotion at a time, written limits on scope and frequency, automatic escalation when limits are hit, and a named human who reviews its log weekly. The first unattended fix firing quietly at 2 a.m. is the milestone that converts your remaining sceptics; the discipline of bounding it well is diagnostic reasoning applied to automation, close kin to the skills in our guide to building critical-thinking muscle for operations problem-solving.
9. Re-run the drudgery audit each quarter and publish the delta
Close the loop. Every quarter, repeat move one and publish three numbers side by side: repetitive hours per week, alert precision, and count of incidents caused by automation (target: zero, tracked honestly). The trend line is your programme’s report card, your budget defence, and — not least — the recruiting pitch that your team supervises machines rather than competing with them. Engineers read trend lines like these when deciding where to work next.
What all nine moves have in common
Scan back through the list and notice what it never says: pick a vendor. That omission is the point. Tooling decisions fall out naturally around move six, made by people who by then know what they are choosing and why. Everything load-bearing on this list is about people and measurement — audit, classify, train, protect the time, grade together, bound carefully, measure again. Teams that execute these nine moves report the same quiet outcome: within two or three quarters, the 3 a.m. page has become a log entry, the chore hours have halved, and the team’s scarcest resource — attention — is finally pointed at problems worthy of it. Monday awaits.
