Priya joined a small analytics team the same week their first machine learning model went live. By Friday she understood something nobody had mentioned in her interview: someone has to look after the model once it is running, and that someone was always the same person, Dev, who answered every late message and fixed every odd prediction. This primer follows Priya’s first year to explain AIOps, short for artificial intelligence for IT operations, and why the healthiest teams rotate the hard jobs around AIOps instead of leaving them with one hero.
If you are new to the field, do not worry. Each term gets a plain definition as it appears, and a mini-glossary at the end pulls them together.
What AIOps means in everyday terms
AIOps is the practice of using data and learning systems to help people run technology: spotting unusual behaviour, grouping related problems and suggesting where to look first. It is not a robot that takes over the data centre. Think of it as an assistant that reads a mountain of signals and says, “this cluster of events looks related, start here.” A human still decides what to do.
That last sentence is where the story turns. Because a human still decides, a human also has to be available when the system raises something at an inconvenient hour. In Priya’s team that human was Dev, and Dev was tired.
The three hard jobs hiding behind every model
Priya started a list on her second week. Three tasks kept coming up, and each had the same flaw: the person who did them well was rewarded with more of them.
- The watch. Someone has to be the first responder when a model starts behaving strangely or an automated alert fires. This is the on-call duty.
- The tidy-up. Data feeding a model gets messy. Labels go missing, formats change, and somebody needs to clean and check it. Nobody volunteers for this.
- The awkward conversation. When a model’s output upsets a colleague in sales or support, someone has to explain, patiently, what the system can and cannot do.
Dev did all three because he was good at all three. That is how a person becomes the team’s bottleneck without anyone intending it.
How the burnout showed up
It never arrives as a dramatic collapse. It arrives as shorter answers, as jokes that sound slightly bitter, as a quiet refusal to take leave. When Dev finally went on holiday, a prediction drifted, and for two days nobody noticed because nobody else knew what normal looked like. The team had confused a reliable person with a reliable process.
This is the heart of the idea. Knowledge that lives in one head is fragile. If the team had shared the watch, the tidy-up and the awkward conversations, they would all have known what normal looked like.
The rotation Priya proposed
Priya was new, so she kept her proposal modest. She asked for a one-month trial with a simple schedule and no new tools.
- A visible rota. Each week one person held the watch. The name was written on the team’s shared calendar, not kept in anyone’s memory.
- A shadow. The person next in line followed along for a week before taking their own turn. They saw the alerts, asked questions and made no decisions alone.
- A fair weighting. Rough weeks counted double, so whoever caught a bad one did not draw the next heavy slot.
- A short note at the end. The outgoing person wrote a few lines on what felt odd, what they changed and what was left half-done.
The first month was clumsy. Dev found it hard to let go, and twice he quietly fixed something before the person on the watch could. The team agreed on a light rule: if you step in, you tell the group afterwards, so the learning stays visible.
What the team learned by sharing
By the third month, something pleasant happened. The people who had never touched the awkward conversations discovered they were good at them. Meena, who had worked mostly on data cleaning, had a gift for explaining model limits in ordinary language. Sam, who disliked the pager, found he liked the tidy-up because it felt like a puzzle. When duties spread, people found the ones that suited them, and the team’s overall energy improved.
The knowledge spread too. Anyone could now explain why a particular score drifted in autumn, or which upstream table tended to arrive late. If you enjoy the plain-language approach to topics like this, our guide to the ways learning systems support business decisions each day is a good companion, because the people making those decisions rely on the same sort of steady, shared care.
Where the wider industry fits
Operations groups in software have used this approach for a long time. A published on-call rota, a shadow week and a written handover are standard practice in many engineering teams. A company like DevOpsSupport, which provides DevOps and cloud operations consulting and support, helps organisations set up exactly this kind of shared duty so that the people who keep systems running are not the same few every time.
Applying the same idea to other AI work
The pattern does not stop at models. Consider an AI tool in a factory. As described in a beginner’s walk through using learning systems to tune production, these tools sit close to physical processes, which means the person watching them needs context about machines as well as data. If only one engineer holds that context, a shift change becomes a risk. Rotation, with real shadowing, spreads the context before it is urgently needed.
The same holds for image systems. Anyone curious about how such a tool sorts pictures can browse a gentle explanation of how computers label what they see. Behind every working classifier is somebody who knows what a bad batch of photographs looks like, and that knowledge is better held by several people than by one.
A simple starter plan
Say you would like a trial run with your colleagues, whether there are two of you or ten. A gentle way to begin follows, and it needs nothing but a calendar and some honesty.
- Write down the three most disliked recurring jobs. Ask each person for their honest top pick.
- Choose a single job and sketch, in a few sentences, what a calm and well-handled stretch of it would feel like.
- Name the first two people and the order, and put it somewhere everyone can see.
- Agree that the outgoing person writes a short note, and the incoming person reads it.
- After one month, hold a short chat about what felt unfair and adjust.
Resist the temptation to automate the rota first. A shared spreadsheet is enough to learn what you need to know. Tools can come later, once the habit exists.
Mini-glossary for beginners
- AIOps: using data analysis and learning systems to help people monitor and run technology services.
- On-call: being the named person who responds first if something goes wrong outside normal hours.
- Rotation: a published schedule that moves a duty between people in a fair order.
- Shadowing: following an experienced colleague through a duty before doing it yourself.
- Drift: when a model’s predictions slowly become less accurate because the real world has changed from the data it learned from.
- Handover note: a short written message from the person finishing a duty to the person starting it.
- Burnout: lasting exhaustion that comes from carrying too heavy a load for too long.
Priya’s year, in short
At her one-year review, Priya was asked what she was proudest of. She did not mention a model. She said it was that Dev took a week’s holiday in the spring and nobody sent him a single message. The team had not become faster; they had become sturdier. The hard jobs belonged to everyone now, which meant they belonged to no one in a way that could break.
If you are starting out in AI and operations, remember her lesson. Learn the tools, certainly, but also learn how teams share the difficult parts of the work. The most valuable colleague is rarely the person who does everything. It is the person who makes sure everyone can.