Busfactor: The Audit I Run as a Fractional CTO, Now Self-Serve

The Problem: One CTO, About 50 Direct Reports

The question I could not answer was simple: who sees everything? With nobody between me and my people, the honest answer was "nobody, including me." A project would drift for weeks before it reached me. A review queue would grow until it became the reason a release slipped. A knowledge gap would sit quietly until the one person holding it was on holiday.

None of this is exotic. It is what happens to any engineering org when the ratio of people to attention gets too wide. I had seen it at other companies from the outside. Living it from the inside was a different education.

I also did not lack for dashboards. What I lacked was a single read that told me what to fix first, where, and how, and that separated a real problem from noise.

Why I Did Not Just Buy Something

I know this category well. At Deepnote I bought an engineering metrics tool after months of building in-house DORA dashboards, and I recommended Swarmia in public, including in my talk at TechFellows Meetup #4. I loved the idea. The case study is here: cycle time went from 4 days to 45 hours, and the rule that made it work was to measure the system, not the person.

At Finviz the picture was different. The price and the scope of those tools did not fit a founder-led org with a lean structure, and most of them answer one slice of the question. Flow metrics say nothing about where your knowledge is concentrated. A bus factor report says nothing about what your delivery queue costs. I wanted one read across all of it, so I built it. If you are comparing options, the Swarmia alternatives roundup is the honest version of that comparison.

What It Reads and What It Shows

Busfactor connects to the systems an engineering org already runs on, such as GitHub, Linear or Jira, Slack and your incident tooling, and computes everything from that data. The full feature list is long. These are the parts I lean on most:

Bus factor and knowledge concentration: which repositories and areas depend on one or two people, and what happens to the org if they leave. This is the number that started the company name. The free bus factor calculator gives you a rough version in a minute, and the practical guide to reducing it covers the fixes, cheapest first.

Delivery flow: where work waits, from first commit to merge to production. In most orgs I audit, most of the cycle time is waiting, not working. You can see your own split with the PR cycle time calculator.

Money drain: the cost of the delays and the concentrated risk, expressed in your own currency and attributed to the work behind it, not an abstract "productivity loss".

AI spend per merged PR: what your AI coding tools cost against what actually ships. The Claude Code ROI calculator and the Cursor ROI calculator are the lightweight versions of the same question.

A weekly verdict and Slack alerts: the read comes to you. A written weekly verdict with the priorities in order, and alerts in Slack when something crosses a line, so you are not relying on remembering to open a dashboard.

What Makes It Different

Numbers are quoted, never generated. Every figure links to the commit, pull request or ticket behind it. If you disagree with a finding, you click through and argue with the evidence, not with a black box. Run it again tomorrow on the same data and you get the same result.

Roast the system, never the person. This comes straight from Deepnote, where an early measurement program triggered a near revolt and the question "are you spying on us?" Commit counts taught engineers to slice work into meaningless chunks. The rule that fixed it was to measure the system. So every finding in Busfactor carries two readings, a stance on which one is more likely, and receipts. Praise is half the product, because knowing what works is how you protect it.

Receipts over vibes. Names, links and concrete examples, everywhere. A finding that cannot show its evidence does not get to be a finding.

Read-only, always. Connectors read. Nothing you connect is ever written to.

On-prem ready. It runs as our cloud or as a customer-hosted deployment, for teams that cannot send their source metadata anywhere.

How I Use It in Fractional CTO Audits

When a company brings me in as a fractional CTO, the first week is an audit: where the knowledge sits, where delivery stalls, what the team costs against what it ships, and what I would fix first. I used to assemble that from interviews, spreadsheets and a lot of repository archaeology. Now the same tool produces the evidence base, and I spend the week on the part software cannot do, which is talking to people.

The interviews still matter. At Realpad, private skip-level conversations showed that the lead engineer on the number one revenue feature did not think a 90k EUR refactor mattered. The knowledge sat with a few people, and neither fact had surfaced until somebody asked. Busfactor tells me where to point those questions. It does not replace them.

After the first week, the same read becomes the monitoring layer for long-term guidance. Each week I look at the verdict with the team, agree on one or two things to fix, and watch whether the numbers move. The engagement stops being "trust me" and becomes "here is the trend".

Who It Is For

CTOs and engineering leads who run more people than they can personally watch. Founders who need to know whether their engineering spend is going where they think it is. Boards and investors who want a defensible read instead of a status meeting. If you are facing a restructure, the knowledge-risk view is the part I would run before any list is final, as I explain in how to decide who to lay off.

If you would rather have me in the room, that still exists. The fractional CTO engagements are real and I still do them. But you should not have to hire a person to find out where your org is fragile.

Try It on Your Own Repositories

The trial is 14 days, no card, on your real repositories rather than a sandbox. Connect GitHub and you get a first finding before the full analysis finishes. Start here: start the free trial. If you want the longer story of why it exists and who builds it, the about page has it.

Conclusion

I built Busfactor because I was the CTO who could not see his own org, and the tools that could help were not built for that situation. It is the audit I give my fractional CTO clients, now available without a calendar invite. Run it on your repositories, read the verdict, click through to the receipts, and decide what to fix first.