A Weak Claim to Being Valuable

On one third-party platform, run for a regulated financial-services client, every production alert used to start the same way. Somebody opened a dashboard, laid the logs side by side and guessed at a cause, while the service agreement gave some priority classes as little as four hours to close out the root cause. Part of that first read was my own review work. In 2025, we started a pilot to hand it to a machine.

Before any of that, there was a question I ask of every recurring task, including the ones that are mine.

Should It Exist at All?

Whether it should exist at all. Automating something nobody needs just produces waste faster.

Peter Drucker made the point in 1963, in "Managing for Business Effectiveness" in the Harvard Business Review, when he warned against "doing with great efficiency what should not be done at all". The alerts passed that test without argument: nobody was going to tell a regulated client that a four-hour clock could wait. So the question moved on. Did the first read of every alert have to be a person's?

Simplify, Automate, Document, Hand Over

If a task does need to exist, the order can be: simplify, automate, document, hand over. Skip the first step and you automate the clutter along with the work. Skip the third and the handover only moves the knowledge somewhere new to hide.

I have written that a runbook living only in someone's head is a hope with your name on it. A handover without the writing is the same hope with a colleague's name on it instead.

Met, or Not Met

What we built for the alerts was never one clever prompt. It was three layers of context: the business domain; the vendor's user documentation in full, because the platform is third-party software and its own manual is the ground truth; and a technical layer describing what a root-cause analysis looks like as a method. A persona on top weighed priority against the service agreement. Alerts arrived on a dedicated mailing list read by its own service account, so an analysis started the moment an alert landed, with nobody forwarding anything by hand.

Writing those layers down was the document step. The rubric was the other half of it. Every analysis the system produced was reviewed against a checklist before anyone trusted it, item by item: met, met, not met. Never a gut call. The score went back in as feedback, so the specific gaps it was caught on were closed deliberately instead of repeated.

By the summer of 2026 the analyses scored between 70 and 80 percent against that rubric, and the number rose with each round. That is an honest pilot number, and it is exactly why the review step stayed where it was. I would rather show you a rubric and a 70 than a claim of 100 percent I cannot defend.

So the handover in this story was half done, on purpose. The first read moved to the machine. The judgement of whether that read was right stayed with people, for as long as the evidence said it should.

Finding Their Buttons

I did the same to testing on that platform. There was no API-level access to test against, so the interface a real user touches was the only seam reliable enough, and the vendor's front end did not keep its element IDs stable. A script recorded today could fail tomorrow for no better reason than the framework renumbering its own components.

I recorded the eight to ten user journeys that matter most with k6 Studio, and each recording became a script. The recorder solved half the problem. For the other half I designed five or six alternative ways to find each element on the page, plus one fallback guaranteed to match, and Claude hardened and extended the scripts on top. From there it was k6's own load model, ramping virtual users toward 200 concurrent sessions, with the results read from the same Grafana dashboards we used for production, so the numbers meant the same thing in both places.

I could not test their code, so I made sure I could always find their buttons.

What It Costs You

I will be honest about the visibility, because it is a real cost and I would feel it. A task you do every week is easy to point at when somebody asks what you do.

In Beyond the Codebase I wrote that the visibility and sponsorship to put a skill to work is the part most technical people neglect. Holding on to a recurring task is the cheapest way to buy it, and the weakest.

Google's site reliability engineers gave the work in question a name. In the SRE book's chapter on eliminating toil, Vivek Rau describes toil as manual, repetitive, automatable work with no enduring value that grows as the service grows, and reports Google's goal of keeping it below half of each SRE's time. I read that goal as a team deciding in advance that carrying toil will not count as the contribution.

Not every place rewards the trade. I have worked in places where invisible work is simply absorbed, and whoever takes a task off everyone's plate is handed more work and less of the story.

That is a fault in what the culture celebrates, and the celebrate list is where it shows first: this is the hardest kind of contribution to reward, because it looks, on paper, like someone doing less.

When Someone Does It to You

The harder test runs the other way. Someone else takes a task off my plate by automating it, and the credit, rightly, goes to them. My first feeling, honestly, is gratitude: they spent their own time taking work off my plate, and I would feel a bit indebted for that.

There would be a short sting too, and it would not be about the credit. It would be aimed at myself.

I owned that, and I didn't see it.

After that, my instinct is to build on it. If they have automated it, I want to see how, understand it, and probably push it further.