My degrees are in English and Mass Communication. The title on my badge says Senior Director of Operations, and I’ve spent fifteen years running call centers: quality programs, site launches in two countries, several hundred staff.
I’ve also had Claude for about five months, and in that time built five systems that a Fortune 500 program and its client use every day. They’re still running.
Both of those things are true, and I’d rather explain how than have you wonder.
The bottleneck was never typing
For most of my career, operational software worked like this: I described a reporting need, it entered a queue, and somewhere between six weeks and never it came back approximately right. Nobody was incompetent. The person who understood the operation and the person who could build were different people, and the translation between them lost more than anyone wanted to admit.
I knew exactly what needed to exist and could specify it in detail. Producing twenty thousand lines of working application code was the part I couldn’t do.
Agentic tooling removed that constraint. It left the harder one alone. A model will build whatever you specify, quickly, with no opinion about whether it’s the right thing. Sale credit has to come from the dialer rather than from a model. A quality program grading only sales is examining the planes that came back. A calendar month can span two fiscal months. None of that is in any training set. It comes from having sat in the meeting where a client questioned a number.
Knowing what correct meant was always the scarce input, not the code. I already had that. What changed is that I stopped needing to hand it to someone else first.
What the process actually is
I want to be accurate here, because it would be easy to describe this as a methodology I invented and that isn’t what happened.
It usually starts with the data, or with a question about the data. My instinct for wide, many-column datasets came from years of building large spreadsheets to track campaigns by hand, not from anywhere more formal. From there I build one feature at a time, working the problem one question or one dataset at a time. Some of that increment is discipline and some of it is honest ignorance about what was possible.
The starting point is usually a sentence, not a spec. I want a dashboard for every campaign that tracks what I’m already tracking and gives insights back. Then you find out what that actually means by building the first piece of it.
The dated design documents, implementation plans and validation logs in these repositories are a byproduct of the tooling, not a process I designed. But I keep them and I use them, because I learned early that slowing down and planning out exactly what I want produces a better outcome than starting to build and finding out. In six months nobody remembers why a rule exists, including the person who wrote it, and those documents are the reason five systems can be maintained by one person who also has a day job.
How I know it’s right
I test it against what I already know is true. That’s the whole method, and it’s only available to someone who already knows the domain.
For performance reporting the math is the math. I can check it, because I’ve been computing these numbers by other means for years and I know what they should say. Quality scoring has a different useful property: you can run the same call again and again. I stress-tested it and changed models roughly six times before I was satisfied with the output, and the thing I was checking against was my own read of what those calls deserved.
I don’t trust anything blindly. To borrow the ethical hacker Rachel Tobac’s phrase, I’m politely paranoid. I assume I need to verify, and then I verify.
What this doesn’t mean
I would not pass a data-structures interview.
I also shouldn’t be hired as a backend engineer. I don’t have a technical background, and there are people who have spent fifteen years on that craft the way I spent fifteen on operations. The difference shows in the places you’d expect.
I can take an operational problem from “this is broken and costing us” to “this is running in production” without a translation layer. For a lot of organizations, the translation layer is where the value dies.
The evidence I would point at
Not the volume of code. Three things.
I find things by looking at output the way a client would. Contact rates were decaying across every attempt with nothing to substantiate it, and the cause turned out to be a caller-ID rotation that had been visible in the data the whole time. Nothing was erroring. No test would have caught it, because everything was working exactly as written.
I know which decisions aren’t the model’s to make. The scoring pipeline runs a language model and then systematically constrains it. The pass that scores never sees the transcript, so it can’t invent a quote. Deterministic rules overrule it on anything arithmetic. Conversion is read from the dialer’s disposition rather than from anything the model concluded.
I documented it for my replacement. Much of this automation ran from my own workstation, which is the honest shape of tools an operator builds — they existed because they weren’t waiting on anyone. When I was furloughed I wrote a handoff for IT covering the scheduled jobs, where the credentials live, and the traps. Including the one I keep relearning: a job that reports success is not evidence that the work happened.
Where I would want the scrutiny
If you’re evaluating me, don’t evaluate the code volume. Evaluate the judgment.
Ask me why sale credit comes from the disposition, or why the pass that scores a call isn’t allowed to read it. Better, ask what a quality program actually learns from the calls it never had the hours to review.
I have an answer for each of those, and I’d rather be judged on them than on anything in the repositories.