Work
Three jobs. Each one: the constraint, the decision, the option I rejected and why, and the outcome.
Qualtrics — the two who pushed back were right
Manager, CAHPS Data Analyst Team · Qualtrics · Oct 2021 – Feb 2024
Two of my five analysts resisted — my two strongest coders, who believed they could produce better output themselves. I didn't argue. I had them run the same task with and without AI and read their own results. Then I fixed the actual problem, which wasn't the tool: we'd been applying a production-quality bar to exploratory and patching code, where deliberate, scoped technical debt was the right call. I set the resulting output level as an explicit expectation, and weekly mentorship sessions made the practice shared instead of individual.
The constraint. Every quarter, my team submitted patient-experience data to CMS. Getting it wrong isn't a bad sprint — it's a regulatory submission. The team existed because I'd already built the capability the company had sold before it existed. When I founded it, quality review was manual: eyes-on review of submissions. That worked at 16 CCNs — a CCN being roughly one hospital, or a group of hospitals reporting as one. It did not survive growth: at 100-plus CCNs across five survey programs, eyes-on review was simply impossible. And this is regulated healthcare data, so whatever we automated had to respect that first.
The decision. We built the review pipeline in stages. Data-quality checks written in Python — with LLM assistance to speed development, in 2021–22, before good coding agents existed. Data was de-identified per CAHPS requirements before any model saw it; then, under Qualtrics' enterprise agreement, it went to an OpenAI model for anomaly detection against prior submissions. The model triaged. A person adjudicated every flagged item. Nothing was auto-decided.
The part I'd defend in any room: we didn't trust it blind. First quarter, humans spot-checked 50%. It earned its way down to 10%, rounded up — and the checks were risk-weighted toward the reporting groups with known data-quality problems, not sampled uniformly.
The option I rejected: automating the final CMS upload. I declined it because I'd found the submission platform returned success signals on uploads that had actually failed. A false “submitted” on a regulatory deadline is the most expensive kind of quiet. The upload stayed human.
The outcome. Two people covering 16 CCNs and one program became five covering 100-plus across five — roughly six times the volume on two and a half times the headcount. The pipeline became the cornerstone of the quarterly CMS submission process.
Coverage grew about six times; the team grew about two and a half
Growth against the 2021 starting point, where 1× is the starting point itself.
Reporting groups covered
People on the team
| Measure | Point | Value | Multiple of baseline |
|---|---|---|---|
| Reporting groups covered | 2021 | 16 CCNs | 1× |
| Reporting groups covered | 2024 | 100+ CCNs | 6.25× |
| People on the team | 2021 | 2 analysts | 1× |
| People on the team | 2024 | 5 analysts | 2.5× |
What I'd change now: I'd escalate the false-success bug to the CMS submission platform instead of only routing around it.
Python · OpenAI (enterprise agreement, de-identified data only) · CMS submission tooling.
Campworks — the first build was the baseline
Co-owner and Chief Operating Officer · Campworks · Jan 2024 – Mar 2025
I found Campworks the way its customers did: I ordered a trailer and it didn't arrive. The company had stalled — zero revenue, an undelivered backlog, one person left. It built the NS-1, a high-end, all-electric, off-grid teardrop trailer. I believed the product was good and the problem was operational, which was my background: manufacturing engineering, Lean, Six Sigma.
The constraint. Cash set every constraint. Cost of goods on a trailer exceeded the customer deposit, so every sale opened a cash-flow hole before delivery. I built mechanisms to manage that; it never stopped being a constraint. I had no authority to hire freely, and headcount stayed at three partly by design — slow growth meant contractors covered the rest.
The decision. We ran the first build unchanged, as a baseline: roughly three months. Then we re-sequenced the line so the heavy, multi-person steps ran early and plumbing and electrical ran late — which meant redesigning the plumbing, the electrical, and the kitchen to allow it. The kitchen was the worst component on the line: the most complex, the most expensive, the slowest, with long-term reliability concerns. We rebuilt it before delivering any backlog or selling anything new — welded construction became fully fastener-assembled bent metal. That delayed revenue and fixed the unit economics: roughly two weeks of high-skilled labor became roughly six hours.
The system changed with the floor. Kanban ran subassemblies and purchasing; procurement fell from about a day per trailer to one to two hours. CRM, procurement and pricing tools were built in Coda, wired to the website and to live cost tracking, so pricing followed actual cost. The back office ran on the AI available at the time — early ChatGPT, then custom GPTs built for repeat tasks — to keep cash burn low; this was before Claude Code existed.
The option I rejected: building the whole trailer in-house. The founder wanted the full build in-house. I rejected that: contract-based assembly protected cash flow while sales grew. It was the biggest disagreement between us. Trailer manufacturing and base assembly moved to a contract facility in Lamar, Colorado, and that call is what made the throughput gain possible.
The outcome. Build time went from roughly three months to four weeks, with two units in parallel instead of one — roughly a 6× throughput improvement. Output went from zero to one to two trailers a month, with headcount at three.
Not everything held. A change to rack installation was meant to cut build time; the process couldn't hold the tolerances and the gain was a wash. We reverted to the original method, which also had better long-term durability. And we tried multiple pricing schemes without landing one.
What I'd change now: I'd prove the rack-install change could hold tolerance off the line before running it in production.
Coda · ChatGPT and custom GPTs · Kanban · Lean and Six Sigma · contract assembly, Lamar, CO.
Arda Systems — infrastructure, not enthusiasm
Head of Operations and Customer Success · Arda Systems Limited · Dec 2024 – Oct 2026
I was Arda's fifth customer before I was its fifth employee. I had run Kanban procurement on the product at Campworks. I joined as a contractor in December 2024, before the company's first round had closed, went full-time in March 2025, and stayed through the priced seed in early 2026. Arda builds Kanban-based real-time inventory replenishment for small manufacturers and industrial supply chains.
The constraint. Seed-stage capital. As part of the exec team I argued the money should go elsewhere, not into post-sale headcount. That meant the function had to run on systems instead of people. Two problems sat underneath it. AI adoption at a seed-stage company fails in a predictable way: people build AI skills individually and never share them, different people burn tokens solving the same problem, and nobody's lessons carry to the next run. And a low-ACV book has far more accounts than anyone can touch evenly — deciding where the team spends its time is the job.
The decision: infrastructure, not enthusiasm.
- A Git repo and training program teaching non-developers the core concepts — GitHub, cloning a repository, setting up a workspace, and why any of it matters.
- Shared skills, memory systems and automated documentation, designed to stop duplicated token spend on repeat tasks.
- A pull-based work-in-progress system applying Kanban and Lean WIP limits to knowledge work. I kept what DevOps, Agile and Scrum had to teach and deliberately dropped the ceremony. Built in Coda, migrated to Linear with custom dashboards.
- Traceability from company strategy to OKRs to projects to tasks, so everyone could see how their work connected to the goal. Standups surfaced WIP overload — people challenged each other openly.
- A support function built from zero: Pylon, rotating triage where every non-developer takes a shift, escalation to three designated support people and then the dev team.
- A redefinition of the PM role under AI. An idea and user stories are no longer enough; the expectation became building a prototype and getting the easy work across the line, so developers have no open questions or assumptions.
The option I rejected: early customer-success and support headcount. The conventional move is to hire; I argued against it and built tooling instead. Rotating triage over a dedicated support hire spread product knowledge across the company and kept cost down. We later grew to two CS people, and I shifted to building the tools they ran on — including a Streamlit reporting layer on internal APIs and PostHog: executive and board dashboards, plus the daily views CSMs used to decide which accounts got their time.
The outcome. Customers grew from 24 to 72. I helped drive the shift from weekly releases to multiple per day — helped; the DevOps pipeline wasn't mine. The systems outlasted me, and that cuts both ways: the tooling made the function runnable by a smaller, lower-cost team — which is what it was built for — and when Arda put its remaining runway into top-of-funnel in 2026, mine was one of the positions that came out. I'd have made the same call. The tools still run the function today.
What I'd change now: I'd add the lower-priced, lighter-onboarding tier sooner.
Coda · Linear · Streamlit · PostHog · Pylon · Python · Git and GitHub · custom integrations with Xero, Shopify, QuickBooks, HubSpot, Shop Monkey, Repair Shopr and Udu.