Turning what engineering ships into the communication a company runs on.
app/services/release_notes.rb
changes = MergedPullRequest.customer_visible.this_weekdraft = ReleaseNotes::Writer.new(changes).callChangelog.open_pull_request(draft) if draft.approved?
I review every word
NewChangelog · Shipped
Schedule a report to send on its own
Pick a day and time. It goes out without you.
What the record shows
Verified · GitHub & Linear
Six years at ClickFunnels, five promotions, from a Tier 1 support queue to owning the delivery pipeline for the whole engineering organization. Every figure below comes from a system of record, not a self-assessment.
226
Pull requests authored
95%
Merge rate · 215 of 226
791
Contributions, 12 months
16
Production reverts owned
677→~100
Feature flags, after cleanup
~900
Automated tests in Spout
What changed in 2026
Contribution activity, last 12 months
SepOctNovDecJanFebMarAprMayJunJulAugSep
791 contributions · 85 active daysLess More
16
Aug 2023 – Dec 2025 two and a half years
──▶
210
Jan – Sep 2026 eight months
The first sixteen were almost all production reverts: pulling other teams' shipped code out of the monolith when a release went wrong. The next two hundred were tooling. What changed was not the job, it was picking up AI coding tools and no longer needing to file a ticket for every idea.
Where the code went
226 pull requests, by repository
The Spout162
Monolith, docs & changelog62
Coding agent2
081162 PRs
Built and still ship into a release intelligence platform, while contributing fixes and code review to the company's internal autonomous coding agent.
What I'm good at
Claim · receipt
Six things I'd stand behind in an interview, each with the thing that backs it.
Making the unpopular call
Rolling something back means telling a team their shipped work is coming out today. I've made that call across five product areas, on code I didn't write, without waiting for a meeting to agree with me.
16 production reverts · 2023–2025 · platform monolith
Speaking engineering and customer
I came up through the support queue, so I know what a customer does with a release before it's a release. The same person writes the deploy plan and the changelog entry, which is why they agree with each other.
A gate everyone skips is worse than no gate, and nobody became an engineer to track gates. So I carry it. I wire the tools the team already uses into one workflow that collects the answers on its own, so devs stay on dev work and QA stays on testing instead of chasing status.
Release process encoded in software · eight systems wired into one workflow
Building my way out of the bottleneck
If something needs doing twice, I'd rather build the thing that does it. I don't write code unaided. I'm effective at specifying it, directing AI tooling, reviewing what comes back, and shipping it.
226 pull requests · 95% merged · Rails 8 in production
Finishing what stalled
Two teams tried to standardize the app's empty states and both projects were cancelled; I scoped it and drove it to release in six weeks. Feature-flag cleanup had stalled twice as well, until I made the case for it and built the tooling that kept it moving. This is the kind of thing I get handed.
40+ pages in six weeks · 677 flags down to ~100 · four abandoned attempts between them
Retooling for whatever's next
Six distinct jobs in six years, each a discipline I hadn't done before: support queue, defect triage, QA, release process, then building the hub that connects the tools we already track releases, engineering work and comms in. I inherited the Courses product area in my first week from a departing lead, and I learned the deploy pipeline the same way, by being handed it and needing it to work.
Six roles in six years · Tier 2 training four months after hire
The Spout
Rails 8 · built with Claude Code
A release intelligence platform I specified, built and shipped, now used daily across engineering with three other contributors on it. It watches what the company builds and turns it into the communication that used to be manual, late, or skipped.
Sources it reads → the engine → where it lands
Reads
GitHub — merged PRs
Slack — channels & threads
Linear — issues & updates
Meeting transcripts
Drive & Calendar
LaunchDarkly — flags
The engine
The Spout
Thirteen purpose-built AI writers on AWS Bedrock, one per job. Eleven jobs on a schedule. Nothing reaches a customer without a human approving it first.
Writes
Customer changelog PRs
Help-doc pull requests
Weekly status reports
Engineering standup digest
Community posts
New-project provisioning
Every release, tracked to its gatesMajorOn trackExample33 gates pending
The checklist does not wait to be filled in. Spout reads the release’s pull requests, its Slack channel, its Linear tickets, the notes from its meetings and the live state of its feature flags, answers what it can on its own, and keeps re-answering as things change. A stage does not advance until its gates clear, so what is left on the list is genuinely what still needs a person — not what nobody got around to typing in.
Daily Deploy
Reads every merged PR and sorts customer-visible from internal. The raw feed everything else is built on.
Release Notes
Drafts a week of customer posts tagged New, Improved, Fixed. Edit inline or ask for a rewrite, then dispatch.
Help Docs
A Bedrock matcher reads a release's PRs, finds the articles it affects, and dispatches an agent to open the doc PR.
Ask The Spout
Everything ingested becomes embeddings. Ask what happened with a feature and get a timeline, not a link dump.
The Drain
Tracks every production flag by age, prompts the owning engineer in Slack at 30, 60 and 90 days, and dispatches confirmed removals to an agent.
Project Provisioning
One action creates the Linear project, the Slack channel, the recurring sync, and the notes watcher.
A standalone demo build of the application. Every company, release, person and record in it was invented for the walkthrough.
01
Intake
Every release starts by declaring its shape. Major, minor or internal decides which gates it has to clear, and the rollout mechanism is pre-selected from that choice. Creating it also provisions everything around it: a Slack channel for the project, a matching Linear project, and a recurring Friday sync on the calendar, all set up without anyone filing a request.
02
The checklist answers itself
Answers drafted from what Spout already read, each with a confidence score and the meeting it came from. Anything it can't answer stays open and waits for a person.
03
Meeting notes, matched to the release
Syncs are auto-imported and attached to the project they belong to, which is where a lot of the checklist answers come from.
04
Daily deploy
Every merged pull request sorted customer-visible or internal, with the docs it affects flagged alongside it. The feed everything downstream is built from.
05
Release notes
A week of customer-facing posts drafted from what actually shipped, tagged new, improved or fixed, each citing its source item. Edit inline, then dispatch to the changelog.
06
Doc updates, collecting
Approved doc edits gather through the week. Friday at 8:30 the whole batch goes out as one agent task and one pull request, and it stays editable until then. Japanese translations queue alongside the English edit they belong to and ship in the same PR.
07
Doc updates, shipped
The run history: what went out each week, how many edits across how many articles, which locales, and the one pull request that carried them. Every article links to its diff and back to the ticket that triggered it.
08
Weekly status reports
Per-project status assembled from the Friday sync, Slack and Linear, posted as a canvas. Current status, blockers and decisions are all editable before it posts.
09
Standup digest
The engineering standup turned into a digest from its transcript, so the meeting is captured and shared even for whoever missed it.
10
The Drain
Every production feature flag by age, status and maintainer, with the date its owner gets nudged next. 126 active against 178 tracked, and a cadence column showing how many are overdue.
What I think about before it ships
The questions under each stage
A release isn't a deploy. It's a change to a product somebody is already using, landing in the middle of their workday without being asked for. These are the things I work through before that happens — and why the checklist is tiered, because a major launch and an internal change do not deserve the same scrutiny.
01Intake
02Scoping
03Build
04Pre-Launch Readiness
05Ready to Ship
06Launched
07Post-Launch Monitoring
08Wrap
ScopeWho this is actually for, and who it isn't. Net-new, replacement or enhancement. Which accounts, which plans, and whether we're charging for it. Targeting at the team, user or workspace level, and what happens to everyone outside that line.
TimingWhat else is already in flight. Conflicts with other releases or active split tests, proximity to a major campaign or event, holidays, and whether there's a hard date driving this or somebody just wants it soon.
MeasurementHow we will know whether it worked. The hypothesis stated before launch, primary metrics chosen, sample size and time window that make the read meaningful, a baseline captured from the old experience, and NPS separated across old and new cohorts so the two don't cancel each other out.
RollbackHow we take it back, written before it goes out. The threshold that triggers a pull-back decided in advance rather than argued about at the time, what happens to users who already have the feature, tag cleanup, and what those users get told.
EdgesWhere it breaks that nobody thinks to check. Plans and tiers, trial versus paid, share links and affiliate links, flag latency in signup and onboarding flows, and how this affects our international users — whether they get this release at all, or are deliberately excluded from it until the localization lands.
ReadinessWho needs to be ready before a customer sees it. Support has access before the public does. Help docs exist and the AI knowledge base can answer from them. Marketing is demo-ready. Ambassador and community cohorts get early access. And there is a plan for public complaints, because sometimes there are some.
Close-outWho is left holding it afterwards. Analysis goes to the decision-maker for a continue, release, pull-back or iterate call. The move to 100% is planned rather than drifted into. A retrospective is scheduled. The feature gate comes out once support confirms nothing is coming in, so it doesn't sit in the codebase for two years.
Selected work
2024 – 2026
Release ownershipNamed release owner on founder-escalated severity-high incidents, working alongside the head of QA to triage, fix and ship same-day across multiple repositories on churn-risk accounts.
Platform migrationDRI on bringing both customer-facing surfaces in-house. Help documentation came off Document360 and the changelog off Canny onto internally hosted sites, retiring both vendors. I set the scope and the eight-milestone plan through GDPR export and account closure and coordinated the engineers who carried out the migration, then personally built the part that keeps it maintained: the Spout automation that opens the help-doc pull requests and generates the changelog as work ships.
Cross-app deliveryStandardized empty states across 40+ application pages, delivering in six weeks what two previously canceled attempts had not.
LocalizationOwned content localization for the Japan market launch, a fixed-date release tied to a live event in Tokyo. 185 funnel templates rebuilt in Japanese, and an eight-step workflow the contributors ran on.
Technical debtLaunched the feature-flag reduction program after two earlier attempts stalled. Cleanup had been tried twice and dropped both times. I pushed for it to happen, audited all 677 LaunchDarkly flags via API, scored them by age, activity and targeting to build the removal backlog, and built the lifecycle tooling that routes confirmed removals to a coding agent. 677 flags down to roughly 100.
Where the judgment came from
Support & QA · 2020 – 2024
I didn't arrive at release management from engineering. I got here from the support queue, which is why I care about the things I care about.
2020 – 2022 · Technical Support
Four tiers in two years
Tier 4 is where a ticket lands when nobody below could solve it. I got there in two years on a platform serving hundreds of thousands of customers, and I was picked for Tier 2 training four months after I was hired.
Specialized in domain, DNS, SSL and SMTP deliverability — the failures that look like the product is broken and almost never are.
Ran the company's Social Support program, answering technical questions publicly in the customer Facebook community under the company name.
Took one-to-one video calls walking customers through fixes when a written answer wasn't going to land.
Worked to solve-rate and chat-ratio targets that tightened with every tier, on a queue where the hard tickets are the only ones that reach you.
2022 – 2024 · Software QA
Handed a product area in week one
I moved to QA and inherited the Courses area directly from the lead who was leaving, announced to the team on my first day on it. No ramp, no shadow period.
Owned end-to-end quality for Courses and Community: test plans, regression passes, and feature-gate state matrices.
Wrote TestRail coverage for what breaks quietly — the cases a manual pass skips because nobody thinks to look there.
Started running production deploys in 2023: CI gate, release tag, ArgoCD sync verification, error-monitoring sign-off.
Ran solo hotfix deploys when no other QA was around and something had to go out.
Filed bugs in a fixed shape — steps to reproduce, expected, actual, reproducible scope, and a Loom — which is what got me promoted out of support in the first place.
Most release managers arrive from engineering or program management. I arrived from the queue where the complaints land. That is the difference that matters: when I am deciding whether something is ready to go out, I am not imagining how a customer will take it. I spent two years on the receiving end of releases that went wrong, and I would rather not hand anyone else that afternoon.
Six years, five promotions
ClickFunnels · remote
When I first applied for technical support, I barely knew how to set a <button> to submit.Now every release reaches production through a process I own and software I built.
Jul 2026 →Engineering Release ManagerOwns the pipeline
Jan – Jul 2026Product Release ManagerBuilt The Spout
Nov 2024 – Jan 2026Principal Software QA AnalystRewrote the process
Sep 2022 – Nov 2024Software QA AnalystRollback authority
Mar – Sep 2022Product Support AnalystDefect triage
Mar 2020 – Mar 2022Technical Support SpecialistTier 1 → Tier 4
Before ClickFunnels: technical support for insulin pumps and continuous glucose monitors on a Johnson & Johnson subsidiary contract, on a queue where a misread symptom carried direct patient-safety consequences, trained in emergency escalation up to initiating 911 dispatch.
Get in touch
I don't write code unaided. I'm very good at getting it written.
Everything above was built with AI coding tools, specified, reviewed, debugged and deployed by me. That's the skill, and I'd rather state it plainly than dress it up as something else.
