I've worked in software quality for more than twenty years and led QA teams since 2012, mostly on products people lean on when it counts: law-enforcement data at Thomson Reuters, clinical decision support, and most recently a platform where nurses and other credentialed healthcare providers pick up per diem shifts at hospitals. My last team was up to twelve people across seven countries and nine time zones.
I'm a QA manager who writes code. Most of what's on this site started as a question Jira couldn't answer, so I built the thing that could. AI agents write most of that code now, and I spend my time on the part I'm best at: deciding what it has to prove before I trust it.
Twenty-plus years counts from 2002. QA management roles since July 2012.
Where I've worked
ShiftMed2021 to 2026
Sharecare2021
Oncology Analytics2020 to 2021
Thomson Reuters2010 to 2019
AT&T2009 to 2010
ChoicePoint2006 to 2008
Sprint Intelligence
A scoring system that told me whether a sprint's target release date was still viable, based on every metric it tracked.
Three times a day, morning, early afternoon and evening, it pulled the data from Jira and Xray through seven extractors: story points by status, time in status, test plan progress, defect arrival rate, impact analysis, test coverage and QA activity. It compared each snapshot with the one before, had an AI model write up what changed, and rolled each sprint into a score: green, yellow, orange or red. I used it to tell every team where its sprint stood and to bring evidence to retros instead of impressions.
It ran three times a day for seven months and grew to 21 dashboard pages, about 290 test files and more than 2,100 commits.
Commits counted from git history, February to September 2026. The code stays private; nothing here links to it.
Team Orion 4.1 | Calendar Sync (Partner Integration)
Higher means more trouble. Every rule that fired, and what it added.
94 ptsCritical
Rule
Factor
Detail
Points
1b
Limited runway
1.9d left, FCC 69.23%
+25
2
Defect trend accelerating
trend 6
+15
2b
Bug load
6 bugs in dev
+10
4
QA throughput blocked
16 pts in QIP, no QAC movement
+12
5c
IA has no test cases (critical tier)
1.9d remaining
+10
5d
Deployment plan (critical tier)
Deployment plan not Dev Complete (ORN-412 Code Review), 1.9 business days remaining
+10
8
Flagged items (silent tier)
4 flags
+4
10
Test failure rate
12.5% (2/16)
+8
One snapshot of one sprint, with the team, sprint and ticket renamed. Each rule that fired adds its points; the total sets the color.
How a day's data moves
Jira and XrayStories, tests, defects and change history
Seven extractorsOne question each, from points by status to QA activity
Three snapshots a dayMorning, early afternoon and evening, each saved next to the last
AssessmentAn AI write-up of what changed, with its arithmetic checked
Sprint historyA rolling record of every sprint's trajectory
DashboardThe score, the color and the reasons behind them
The real one ran on company data, so the code stays private. The demo here runs on a made-up company's sprints.
Selected work
Six problems, what I did about them, and what changed.
The problem
Up to eight product tracks and twelve sprints running at once, shipping to production about three times a week, with one QA team covering all of it.
What I did
Planned coverage off the release calendar. Used defect arrival rate to decide whether a track's developers could move to the next sprint or needed to stay and stabilize. Wrote sprint guides so testers could switch product lines without a long ramp-up. Gated every release on the team's readiness checklist.
What changed
More than 700 production releases from late 2021 into 2026 without a single revenue-impacting defect.
About three releases a week over roughly 250 weeks. Revenue-impacting means an outage of shift claiming, clock in and out, or the app itself. Smaller bugs did reach production.
The problem
Burn-down charts climbed before they came down. Sprints were starting before all stories were refined and pointed.
What I did
Measured it. On one board over twelve sprints, scope three business days in was 308 points; by sprint end it was 559. One sprint went from 4 points to 121. I took the numbers to the dev leads, the director of engineering and the PM leads and proposed refining and pointing before a sprint starts.
What changed
Adopted across teams. Burn-downs started coming down much earlier in the sprint.
Growth measured from a scope freeze three business days in. A story's points only burn when it reaches QA Complete, so no burn-down drops on day one.
The problem
Developers started tagging AI-assisted work in Jira and leadership wanted to know if it was faster. Raw velocity couldn't say, because team sizes varied.
What I did
Designed a developer-normalized velocity metric, story points per developer-day. Built a baseline from 43 closed sprints, audited the AI tag, and disclosed the one attribution error I corrected.
What changed
Seven AI-assisted sprints across four teams ran at about four times the baseline, 2.61 versus 0.63 points per developer-day.
Baseline: 1,680 points over 2,673 developer-days. Development throughput only. QA was measured separately.
The problem
A developer showed a sprint's worth of code finished in about sixteen hours with AI. QA couldn't keep that pace, and the team was wary of what an AI plan would mean for them.
What I did
Asked the team first. All nine answered a survey and time study: about 714 QA hours a sprint, 69% of it in test execution and test-data setup. I wrote the strategy and an operating model around one rule: AI assists, people decide, and nothing signs off a release automatically. Then ran a pilot where an agent drafts test cases into Xray and a QA engineer reviews every one.
What changed
A plan the team helped write, and a set of prompts product, development and QA used to turn sprint context into impact analyses and sprint guides.
714 hours scaled from six of nine responses. The pilot ran; a full rollout was still pending.
The problem
Sprints ran late and every team blamed a different phase. Jira showed ticket counts, not where the time went.
What I did
Built a calculation that rebuilds each ticket's workflow history from Jira's change log and counts business days per status. When one number looked wrong (13.77 days for a ticket that joined the sprint late, where the real figure was 4.69), I changed the rule so the clock starts when a ticket joins the sprint, then re-checked all 131 past scope additions across 35 sprints. Added detection for skipped workflow steps and about 115 automated tests.
What changed
The company canceled the paid Jira plugin this replaced. Sprint reviews moved from opinion to data, and QA wait time finally showed up separately from active testing.
The old rule had charged up to 19 extra business days to sprints that received carried-over tickets.
The problem
Payroll weeks run Saturday to Friday. A hospital's billing week can start on a different day. Overtime owed to a provider and overtime billable to the hospital stop lining up, and spreadsheets weren't getting product, development and QA to the same picture.
What I did
Built, with AI-assisted coding, a one-page browser tool that lays the two cycles over each other, lets you drop shifts onto them, and shows how much overtime can't be billed.
What changed
The edge cases surfaced before any code was written. I later used it with Finance and an account manager to show where billing-week offsets cause revenue leakage.
Demo coming: a clean rebuild on made-up shifts.
How I build with AI
AI agents write most of my code. I don't take any of it on faith.
Loaded into every agent session
CLAUDE.mdRules I write. Codex reads its counterpart, AGENTS.md.
MEMORY.mdNotes Claude keeps on my coding conventions and test guidance.
Claude and Codexplan and write code
I work in Claude Code Desktop. It lays out a plan and waits for my approval. Codex works its own branches, and each second-guesses the other.
WebStormread the code
Where the code lands. I pull what the agents wrote and read it, and when I want to understand how something was built, I step through it in the debugger.
GitNexusmap the blast radius
Before an edit, the agent reports what depends on the code it's about to change and how risky that is.
No edit without an impact check
Docker and PostgreSQLrun it locally
Apps run the same on my machine as anywhere else, database included.
GitHubopen the pull request
Every change lands through a pull request, with automated checks on each one.
Scope check before commit, CI before merge
CodeRabbitreviews the PR
An AI reviewer posts a walkthrough with a sequence diagram of the changed flow, then line-level comments.
Unit Test Skilltests from the diagram
A skill I wrote reads that diagram like an adversarial test designer and writes the spec and the tests.
New and existing tests pass before a push
Review skillclose every comment
A second skill works each review comment: fix it or decline it with a reason, and fix the root cause too.
Every comment gets a posted reply
Netlifypreview, then ship
Each pull request gets its own preview link. Merging publishes to production.
When review turns up a root cause, the fix goes back into CLAUDE.md, MEMORY.md or a skill, so the next change starts from better rules.
Across seven repos that's 454 merged pull requests, roughly 5,600 automated tests and 35 diagram-driven test specs.
On one CSV import, a four-arrow diagram became 79 tests that found nine bugs already in the code. All nine were fixed in the same pull request.
This site is built the same way.
Counted from git history and test files on October 8, 2026. Two-thirds of non-merge commits in the four main repos carry an AI co-author line.
Projects on this route
Sprint IntelligenceScores whether each sprint is on track to release on time.
Release calendarCalendar, roadmap and Gantt views for leadership release reviews, with role-based access.
Nonprofit portalWebsite and volunteer portal for a disaster-relief nonprofit.
Billing-week simulatorShows where payroll and billing weeks fall out of line and what overtime can't be billed.
What people say
When there's an issue, you're not racing the clock, you're racing Mason, who is already deep into discovery and probably has a solution.
Megan Puckett, Senior Product Manager
He never made the team feel blamed when bugs slipped through and proactively worked to find out why they did and immediately implemented mitigation strategies.
Matthew Abbott, Product Leader
He has elevated my understanding of what Quality Assurance is about, encouraging me to think outside the box, think bigger and deeper.
Nadiia Diachok, QA Engineer
And as any QA leader should, he stayed curious.
William Yarrington, Senior QA
He took ownership of quality and made sure every release was handled with care and attention to detail.
Carolina Spengler, QA Engineer
A strong QA leader and an even better people manager.
Measure before you automate.The AI plan started with a time study, not a tool.
AI assists, people decide.Nothing signs off a release automatically.
A bug report carries its own evidence.Steps, environment, expected and actual results, and the linked test and acceptance criteria.
Ask questions in the team channel.A quiet engineering channel is a warning sign, not a good one.
Treat a metric like a product.Define the rule, test it, and re-check old data when the rule changes.
When a bug gets out, find out why. Not who.Then change the process so it can't get out the same way twice.
Off the clock
Photography
Most of these came out of a Canon EOS R5 and got finished in Lightroom. A couple are iPhone shots I didn't want to miss. Nothing here is stock.
Hiking
Mostly around Atlanta, with trips to the Smokies and the North Georgia mountains, and a week on the Great Glen Way in Scotland this past June. The camera comes along.
Disaster response
I volunteer with D.A.R.E. on disaster response, and I built and maintain its website and volunteer portal, with sign-in, coordinator approvals and a photo inbox.
