2026-11-10 · ~5 min
Our CTO Said Move Bugs to the Left. My Tech Lead Built the Tool.
Matt's standing rule is that a wrong assumption gets cheaper the earlier you catch it. Kercwin turned that rule into an epic checker that reads every ticket and pull request against the plan before the drift sets in.
An epic at Career Team has a lot of hands on it: the plan owner, product, leads from potentially more than one team, and the developers doing the work. Decisions change while the work is moving, and the code written last sprint can quietly drift from the decision made this sprint. Nobody notices until review, or testing, or a customer.
Kercwin, the tech lead on my team, built the thing that notices first. This note is about that tool and the rule it came from. How it started, with a demo of my own dashboards, is in I Showed My Team a Dashboard. Two Weeks Later They Showed Me Theirs.
Matt's rule
The idea underneath it is not his or mine. It comes from Matt, our CTO, and it is his standing rule:
Move bugs as far to the left in the process as possible. My interpretation, from what I remember of a knowledge-sharing session by Matt Monroe, CTO at Career Team. Not his exact words.
A wrong assumption caught on a ticket is cheaper than one caught in review, which is cheaper than one caught in production. The epic checker is that rule turned into a tool.
Matt's rule, drawn. Every step right costs more than the one before it.
Kercwin credits it the same way. At the team's engineering knowledge-sharing session, he opened his presentation about his skill and dashboard with his own reading of what Matt said, and then put the job in his own terms: preventative and proactive measures, tracking and auditing to steer technical direction, and bridging delivery between product, leads and developers, in any order the cycle runs.
Who built it
Full credit goes to Kercwin. He went from developer to tech lead in about a year, which is fast for anyone. I pushed him into the role because I saw something in him before he did, which is a feeling I know from the other side. A lot of my job with him is the stuff nobody puts on a ticket: the inner voice in your head that says you are not ready, learning to hand work off instead of carrying it, getting him to see in himself what the rest of us already see. He is doing a great job, and he is still working out what kind of leader he wants to be, which is the correct amount of figured out for anyone.
Before he built anything, he showed the team how he makes Claude talk to him. Tables, diagrams, specific wording, a format his brain reads fast. I laughed, because mine went the opposite way. Every rule I have written is about how the AI should sound when it writes as me. His is about how it should sound when it writes to him. Same tool, opposite direction, and both of them right.
How the epic checker works
Inspired by my review board, he built the epic checker. It keeps an epic's code and tickets aligned with its architecture plan, so he can stay on top of technical decisions while they are still moving.
The plan stays the source of truth. The checker only ever points at where the work and the plan disagree.
That matters more than it sounds, because of all those hands from the opening. With that many people, alignment is the hard part, and his checker is the thing that keeps everyone reading the same page. Two of its choices started as my advice, and I like that he kept them. Confluence is the source of truth, so decisions live where everyone already reads them instead of inside a tool only one person opens. And the run logs are shared, so anyone can see what the checker did, when, and on whose run.
The checker does not decide anything. It puts the decision in front of the person who owns it, with a recommendation and three buttons, and a person picks one. That is the rule I hold the whole team to: the tool is allowed to type, and someone with their name on it signs.
What came back to me
I helped him plan it, and then I did the most flattering thing a manager can do to a teammate's project: I started using it and sending commits. As a snapshot, the history has about 81 commits from him and 14 from me. Mine are mostly plumbing, a daily refresh routine for every epic on the index, a run log and stats view on the board, workday-only scheduling, and the hook that lets my review kit fold the epic check's decided deviations into its verdict.
His tool now makes my reviews smarter. I did not plan that, and I like it a lot. It is the part of this project I would point at first: a tool built for one tech lead's epics ended up improving a reviewer that runs on every pull request the team opens. My reviews now know which deviations from an epic were decided on purpose, so a deliberate change no longer gets flagged like a mistake.
One person's tool made another person's tool better. When one of us shares what helps them, the whole team gets the benefit, and that is the lesson I would keep from this project.
What my reviewer already learned the hard way
My review kit has been through this road, and the story of it is in Seven Hundred Commits to Teach a Reviewer It Was Wrong. Three of its lessons carry straight over to an epic checker, and I have been passing them to Kercwin.
The same three lessons, carried from one tool to the other.
The first is to keep score. My reviewer only got good once every comment it left was graded by what happened next: fixed, answered, closed without a change, or ignored. A flag on the epic board can be graded the same way. A decision that got accepted, changed or rejected is a result, and a flag nobody ever touched is a result too, just a less flattering one.
The second is to read the scores per topic, never as one average. My reviewer can be sharp on database changes and noisy on frontend speed, and the mean of those two looks fine. A checker can be right about conflicts between pull requests and wrong about what counts as a new decision, and only a split by kind of flag shows which.
The third is that a miss is worth more than a hit. When my reviewer lets something through, the fix to its lens is replayed on the exact commit it missed before the fix counts. The epic checker's version of that is a decision that surfaced in review or in testing instead of on the ticket. Every one of those is a test the next run should pass.
None of that replaces the person with the buttons. It only tells them, with a record rather than a feeling, how much the flags are worth reading.
What the board says so far
Everything the checker produces lands in Confluence and Jira, so the numbers are easy to count. As a snapshot on Nov 10, about ten days after the Epic Alignment space was set up:
| What | Count |
|---|---|
| Architecture plans the checker reads against | 16 |
| Conflict pages it has opened | about 19 |
| Conflicts already closed | 7 |
| Follow-up tickets it drafted, labeled epic-review | 48 |
| Of those, already done | 28 |
These numbers do not say whether a flag was right. A closed conflict can mean two pull requests merged cleanly or that someone decided it was not a conflict at all, and the board does not grade that yet. That is the first lesson above, waiting to be applied.
What I have not earned yet
It is a few weeks old. I do not know yet whether it still gets opened in three months, or whether the leads on other teams come to trust its flags enough to act on them without double-checking. The cheaper-to-the-left curve is Matt's rule and a well-worn one, but I have no number of my own yet for bugs it caught early. What I can say is smaller: when the checker flags a drift, it flags it on the ticket or the open pull request, in front of the person who owns the decision, which is exactly where Matt said it belongs.
The judgment is human. The typing, by design, is not.
