The Bus Factor Nobody Talks About

1. Introduction

Everything was running smoothly.

The system was stable.

Customers were happy.

New features were being released every week.

Then one developer went on leave.

A production issue appeared.

The team opened the project.

Silence.

Nobody knew where to start.

"It was Alex who built this."

"But Alex isn't here."

The software was available.

The knowledge wasn't.

2. Problem

AI makes it possible for one developer to build an incredible amount of software.

Small teams can now deliver what once required an entire department.

This is a remarkable advantage.

It also creates a hidden risk.

Knowledge becomes concentrated.

One developer understands the prompts.

The architecture.

The design decisions.

The workarounds.

The rest of the team sees working software.

Very few understand how it actually works.

3. Explanation

Every organization depends on shared knowledge.

Not individual heroes.

When important knowledge exists inside one person's mind, the organization becomes fragile.

People resign.

People change teams.

People take leave.

Emergencies happen.

Business continues.

If nobody else understands the system, every incident becomes slower.

Every enhancement becomes riskier.

The issue is not losing a developer.

The issue is losing understanding.

AI can generate software.

Only teams can build organizational knowledge.

4. Practical Example

A SaaS company uses AI extensively to accelerate development.

One senior engineer becomes exceptionally productive.

He delivers authentication, billing, reporting, notifications, and integrations in just a few months.

Everyone is impressed.

Documentation is postponed because development is moving so quickly.

One day, a payment issue affects customers.

The engineer is overseas on annual leave.

Three developers investigate.

The code works.

But nobody understands why several payment rules were implemented.

Support cannot answer customer questions.

Finance cannot explain missing transactions.

Recovery takes two days.

After the incident, the company changes its engineering practices.

Major design decisions are documented.

Architecture reviews become standard.

Knowledge sharing becomes part of every sprint.

The next incident is resolved within an hour.

The software did not become simpler.

The organization became stronger.

5. AxTrace Perspective

Operationally mature organizations approach this differently.

They reduce dependency on individuals by making knowledge explainable and accessible.

Important decisions are documented.

Engineering knowledge is shared.

Traceability extends beyond code to the reasoning behind it.

Trust grows because the organization owns the knowledge—not a single developer.

6. Key Takeaway

Software can be written by one person. Understanding should belong to the whole team.

7. FAQ

1. What is the bus factor?

It measures how dependent a project is on a small number of people. A low bus factor means critical knowledge is concentrated in very few individuals.

2. Does AI increase the bus factor risk?

It can. AI enables individuals to build much more software, making shared knowledge even more important.

3. Why isn't working code enough?

Because software must also be maintained, supported, and improved throughout its lifetime.

4. How can engineering teams reduce this risk?

By documenting decisions, reviewing architecture, sharing knowledge, and ensuring multiple people understand critical systems.

Previous
Previous

Why Production Needs Evidence, Not Confidence

Next
Next

The Most Expensive Words in Software: "We'll Fix It Later"