Clear The Fog
Four years of backlog. Four ticket systems. No unified process. No visibility across the business. Here is how I turned that chaos into one measurable operating model and scaled output without a single extra hire.
The House, M.D. problem
The situation
A PE-backed software company running multiple products across multiple development partners, each with their own tools, processes, and habits. Four different work tracking systems, zero shared visibility.
Tickets aged for years. Nobody knew what was critical and what was noise. Development partners worked without any shared standards. Different branching strategies, no code review requirements, no testing hierarchy, no release process. Every partner doing their own thing.
The team was capable. The infrastructure around them was broken. Everyone was treating symptoms, moving fast, putting out fires. Nobody had stopped to ask what was actually wrong.
Starting state
The approach
Step 1: Centralize everything
First move: own all communication. Even when I did not have the answer, I needed to know what was happening. That single change gave enough signal to start seeing patterns across products and partners that nobody else was tracking.
Then I manually dug through years of ticket history across all four systems. Identified what was genuinely open, what was abandoned, and what was noise. Built a triage framework with clear priority and severity rules. If everything is a priority, nothing is a priority. Urgency is a planning failure, not a severity level.
Incoming
Years of mixed history, four systems, no clear priority.
Triage funnel
- Prioritized
- Closed
- Actionable
Clear priority and severity rules. If everything is a priority, nothing is.
Actionable backlog
Triaged. Prioritized. Clear.
The goal was never to close tickets for the sake of numbers. It was to build a framework that could handle both the existing backlog and everything coming after it, managed together with clear priorities driving every decision.
See what a broken operating model looks like up close
A 30-person team, daily incidents, no documentation, then a ransomware attack. Everything that went wrong and exactly how it got fixed.
Read Build What Lasts →Step 2: Roll out development standards to all partners
Every development partner was operating independently. The output quality reflected that. I designed and rolled out a unified development standards framework across all tech partners, covering five areas: branching discipline, code quality, commit clarity, pull request rigor, and testing depth.
1
Branching
Controlled merge flow, protected branches, naming conventions.
2
Code quality
Duplication, dead code, exceptions, logging, formatting.
3
Commits
Every commit tells a clear story. No branch names as messages.
4
Pull requests
Mandatory reviewer approval and senior engineer sign-off.
5
Testing
Unit tests after every PR. API coverage above 90%. Automated regression.
6
Release
Semantic versioning, tagged artifacts, release notes, health checks.
Partners pushed back initially. Standards always create friction at the start. Within the first two delivery cycles with each partner, the friction was gone, and the rework that had been causing it had gone with it.
Step 3: Scale output without scaling headcount
Once visibility existed and standards were in place, the real question was scope. The team was debugging across .NET, Java, JavaScript, and PHP, reading source code daily, proposing fixes, and managing accountability across multiple development partners. That is an engineering function, not a support function, and it was running at capacity.
Instead of requesting more headcount, I built the case for scope expansion through leverage: structured workstreams, automated Jira workflows, and an internal triage tool I led from concept to delivery with Claude Code that absorbed the extra load. Same team, more output, broader coverage.
Throughput per headcount
Output doubled quarter over quarter. Headcount unchanged.
Upstream impact
Fixes adopted, issues prevented before reaching customers.
Coverage breadth
15-person L3 team across multiple products, 5 partners, one operating map.
Same team. More output. Broader scope.
The business case was built around three numbers that mattered to leadership, and once those were on the table, the conversation shifted from per-brand updates to holding company-wide patterns.
Throughput per headcount: tickets triaged and fix recommendations issued doubled quarter over quarter, headcount unchanged.
Upstream impact: fix recommendations accepted and findings that prevented customer-facing issues, including a joint Product/QE retriage of a large stale bug backlog that cleared over half as non-reproducible and refocused Engineering's roadmap on confirmed revenue-impacting issues.
Coverage breadth: a 15-person cross-functional L3 team across multiple products and brands and 5 development partners, under one lead and one operating map, with support extended to Sales (prospects, trials, forums).
How vendor accountability ties into this
When your team comes from the partners you are holding accountable, you cannot manage by trust alone. The governance model behind that is covered here.
Read Hold The Line →How AI multiplied the output
Pushing output up without adding people eventually needs leverage beyond effort. The AI triage layer that absorbs the repetitive load, while a person still owns every customer outcome, is covered here.
Read The Pivot Point →Step 4: Apply the model beyond the original scope
Centralize
Unified visibility
across all work
Standardize
Common workflows
& processes
Scale
Enterprise growth
& value generation
By this point, clearing the fog was a reflex, not a one-off cleanup. The same move (map what no one else had mapped, build the framework, make the call) kept getting pointed at problems that had nothing to do with tickets. Two of them:
Marketplace expansion
The company was already on a few marketplaces but invisible across plenty of others it should have owned. Too many options, no framework to choose between them, and no one had volunteered to build one. So I did: a structured assessment of 35 marketplaces, input from marketing, a competitive read, and a shortlist of 10. Within six months we entered 4.
Acquisition assessment
The company was evaluating a mid-six-figure acquisition: an AI-powered test automation platform. On paper it looked like a smart move. I went deeper and assessed three things:
Service contracts: obligations that would transfer with the acquisition and constrain what we could do with the product.
Tech stack: the actual build quality underneath the pitch deck.
Client base: interviewed key personnel to understand what was holding the revenue together.
What I found was a product we could build ourselves for a fraction of the price, without the contract and tech-debt liabilities buried under the pitch deck. I made the case, the exec team agreed, and the deal was voted down in favor of building in-house.
The cost case behind the scope expansion
Scaling output without headcount is one side of the equation. The other is removing the spend that was not delivering. Both happened in parallel.
Read Stop The Bleed →The results
Avg Triage Time
190 → 13
Days. 93% faster over 2 years.
Active Backlog
485 → 57
Tickets. 88% cleared.
Output
2×
QoQ throughput. No new hires.
Automations Built
20
Jira workflows. Handoffs gone.
Partner Onboarding
1 week
From zero to fully operational.
Reporting
1 view
Holding-company visibility.
The output doubled without a single extra hire, and the years of backlog did not build back up. Four fragmented ticket systems became one measurable process, and the reporting layer finally gave the holding company a single view across all of it.
Halt and Catch Fire edition
What made it hard
None of this was one clean pass. Each fog I cleared exposed the next one behind it, so the housekeeping was never the warm-up to the work. It was the work, and every pass turned up the next thing to fix.
Getting multiple stakeholders to agree on what mattered when everyone had their own version of priority was the first obstacle. The triage framework only worked once I had enough data to make the conversation objective rather than political.
External partners treated standardization as overreach. Some agreed in meetings and carried on as before. The only thing that changed behavior consistently was enforcement through PR reviews and release gates. Agreement without consequence is just a conversation.
The scope of the role was easy to underestimate from the outside. It looked like support on paper. The work was closer to hands-on engineering accountability across multiple stacks and partner teams. Closing that gap between label and reality took time and a reporting structure that made the breadth visible to leadership.
The acquisition was the highest-stakes fog to clear. Arguing against a deal the exec team already wanted meant a watertight case and the willingness to be wrong in the open. Build-versus-buy only held because the diligence was thorough enough to survive scrutiny.
Recognize this situation?
Let's talk about what is broken and how to fix it.