The trap of being useful

A large ARR drop showed up in one of our dashboards. A data analyst in the FP&A team caught it on a Saturday. I'd shown him our new triage skill three days earlier.

He ran /triage on the issue and posted a full root cause analysis. Evidence, root cause, category, the most likely explanations. It showed the source data had stopped extracting: hourly records normal, then a sharp drop, then near zero.

I didn't see any of it until Sunday morning. I was packing for the airport, a company offsite in Croatia starting that day. Nobody on my team was around. So instead of waiting, he took the first step himself.

At the airport, over lunch, fighting a dying laptop battery, I copied his root cause analysis into Claude Code. I asked it to investigate further and open a PR for the fix. I merged it that day.

I only learned afterwards that he'd had the same fix in mind. He'd asked Cursor to draft the PR. He just didn't feel confident enough to ship it.

He had the knowledge. The skill gave him that. What he didn't have was the authority to merge it, or the appetite to own it if it broke. The method had transferred. The mandate to act on it, and the responsibility for getting it wrong, had not. That's the part I never thought to package, maybe because I'm not sure it packages at all.

My first reaction was: this works. My second, honestly, was disappointment that he didn't just ship it.

What I want is to wake up to "I found the problem, here's the fix," review it, and have it done. I don't need to own every fix. But handing someone the method is not the same as handing them the authority and the confidence to use it.

I could have written these skills earlier.

The reason I didn't is uncomfortable. When a messy data issue shows up, people ask me, and I can usually figure it out.

I've been around long enough to know where the weirdness hides. Late sources. Models that oversimplify reality. Definitions that changed three times. Tables people trust too quickly. I move fast because I have the muscle memory: find the issue in aggregate, drill down to the lowest useful granularity, fix it there, repeat until the remaining movement is explained.

Not everybody has that, and that's fine. Some people are stronger architecturally. Others are better at solving a problem once it's scoped. What I'm good at is the scoping, the part where you haven't yet figured out what kind of problem you're looking at.

It feels useful because it is useful. The next issue comes in, it looks different enough that someone asks again, I answer again, and the work moves.

AI changed that. You can distribute a skill like this far more easily than before. The knowledge was never secret. The problem was that I was still the easiest way to get to it. I was the interface. Now there's a realistic path to packaging what I do into something people can invoke without me in the room.

That's a strange thing to do. You take something that lived in your head and make it usable without you. Your shortcuts, your checks, your feel for when something is probably fine versus when you need to keep digging.

Part of me wants to call that progress. Another part knows that when you're the person everyone asks, your value is obvious. You know the weird edge cases, which source to distrust, what normal looks like. That's expertise. It's also status. Writing the skill means the next person gets further before you show up. In the best case, you're not needed at all.

You built the road. People drive on it. Nobody thanks the road.

That's the job, though. At least it should be.

But the skill didn't remove the bottleneck. It moved it. The analyst got all the way to the fix and still didn't ship. What stopped him wasn't knowledge. It was that the fix wasn't yet his to make.

The second story showed me the other half of it.

A billing issue came back, one we thought we'd fixed. It landed in the evening and I picked it up around ten the next morning. We were mid-migration between billing systems, and the complexity sat in the gap between them.

I had the triage skill, so I used it. I ran it, it didn't find it, I told it to look harder. Go deeper. Continue. There were so many factors in play that it never figured it out.

It narrowed things down. I got a CSV of where the issue might be. I handed it to a colleague for a fresh pair of eyes and asked them to go deeper. They're an AI skeptic, more of a data artisan. They took the manual route and found it.

The skill narrowed the search space. The last step still needed someone who distrusted the answer enough to keep looking.

Here's the part I'm not proud of. My gut said it didn't add up. The explanation we landed on would have implicated every monthly run, and the last few had been clean. I shipped the fix anyway because I was out of time. The skill scaled the diagnosis. It couldn't make the judgment call, and under pressure my judgment lost to the calendar.

Two problems, two different gaps. The analyst had the diagnosis but not the authority to act on it. I had the authority and let a deadline overrule my own judgment.

Packaging what I knew didn't make me unnecessary. It pulled apart what had always been bundled in one person: the knowledge, the judgment to know when an answer is wrong, the authority to act when it's right, and the responsibility for what happens next. The skill could carry the knowledge. The rest defaulted to one person. To me. Again.

So the job isn't answering more questions. It's moving the judgment, the authority, and the responsibility toward the people who hit the problem first. That's slower and less satisfying than writing a skill, and it's the actual work.

You don't stop being the bottleneck. You just move it. The work is making sure the same decisions don't keep routing back through you behind a new interface.