Selected work

Work you can judge. No titles. No customer names.

Escalation bot + time-to-resolve board

Product escalations used to live in chat. Whoever was free grabbed them. You couldn't see how old a case was, who owned it, or whether we were getting faster. Developers sat on first-line as a rotation. That looked like support. It was a staffing problem.

I pulled developers off first-line and put QA there. To make the call stick I shipped support automation: a Google Chat bot for escalation intake, plus a Sheet and Firestore time-to-resolve board that gives the case a shared clock. Support starts the escalation in Google Chat by filling a dialog form that captures what developers need to get started. The time-to-resolve board picks up the case so age and owner stay visible to the org, including the director. Developers only come in when QA needs them.

The bot is live. The board is in use. Tier 2 support tickets are down about 75% after the escalation path and related support tooling landed. I made the staffing call and shipped the system that measures it.

Wrenchy, an AI code reviewer

We didn't have automated code review, and our tooling didn't give us one. So I took it on. I was the product owner for Wrenchy and built it with AI coding tools.

It's a Python app backed by Google Gemini. When a ticket moves to Ready for Review, Wrenchy pulls only the changed code from the pull request, reviews it, and posts what it finds in Google Chat. Every PR that's ready for review gets that pass.

Then I opened it to Support. They paste in an error message and Wrenchy traces through the code to what's likely causing it. Support gets a starting point instead of waiting on a developer to know where to look.

Day-0 incident writeup

A customer lost documents after a mobile add path. That night, the first move was another backup. Root cause took days. We didn't have a short written page early: what's broken, two ways it could be true, one check that picks the path, a named owner, and a next step with a time.

I went back and wrote the page we should have had that night. Only what was knowable from the escalation: product version, repro path, what support had already tried. The check was to upload a new document and see if the failure is old data or the new write path. Next action had a morning deadline. "Look for a bug" was not the plan.

I didn't invent root cause that night, and I didn't claim files came back if they didn't. The blank version of that page is here: day-0 incident page.

Equipment360's first performance test

A large enterprise customer was coming onto Equipment360, and we had never performance tested the product. We needed to know what their volume would do to the server and the database before go-live.

I started Equipment360's first performance testing phase with the QI team. We ran it together in JMeter. My piece of the test data was a SQL script simulating 3,000 work orders. What came out was Azure server sizing recommendations for the customer and the places in the database that could use indexes.

Later, with the senior developer, I scoped and validated a multi-instance server setup for large enterprise customers. We proved it with test builds on a performance test environment. In QA I also automated our API regression tests with a Postman collection that runs in the CI pipeline.

GitHub Enterprise cutover

Repos and secrets were scattered. After a half-done move, people could keep pushing to the old place forever.

I set one cutoff date. Comms first. Then the CLI move, new URLs, workflows, and branches for the repos in scope. I owned it end to end. About 40 repositories moved under that plan. Tokens and env that had been spread around got centralized.

Scope was the repos I owned, not the whole company. The work was the cutoff and the follow-through.