Engineering on Simple Enough Blog

Testing Your Bus Factor: The Muted Expert Exercise

Mon, 20 Jul 2026 17:00:00 +0200

Throughout this series, we’ve seen how to pass knowledge on: in real time, in writing, through organization. One question remains, and it’s the one we carefully avoid: does it actually work? You believe a team is robust because it documents and pairs — until the day a departure reveals the gaps. This article suggests not waiting for that day, and measuring your vulnerability while there’s still time.

I. What is the bus factor?

The bus factor answers a blunt question: how many people would have to disappear for a project to grind to a halt? The name comes from a deliberately crude image — how many team members could be hit by a bus before the work becomes impossible.

The Setups That Make Knowledge Circulate: Rotation, Game Days and Guilds

Mon, 20 Jul 2026 16:00:00 +0200

In the guide to collaboration modes, we saw how to pass knowledge on in real time (the tacit) and in writing (the explicit). But a team can master all these practices and still watch its knowledge concentrate in a few people. The reason is structural: without a setup that forces it, knowledge follows the natural slope of specialization. This article deals with the organizational layer — not how we work together, but how we arrange things so that knowledge circulates by default.

Sharing Knowledge Asynchronously: Code Review, ADRs and Docs-as-Code

Mon, 20 Jul 2026 15:00:00 +0200

In the guide to collaboration modes, we set out a rule: explicit knowledge travels asynchronously. Where synchronous modes pass on intuition through contact, asynchronous modes capture what can be written down — and produce a trace that survives departures. But you still have to avoid the classic trap: documentation that no one reads and no one keeps up to date. This article details the practices that work, and why.

I. The strength and the limit of writing

Writing has an advantage no synchronous mode matches: it depends on no one. It can be read at three in the morning during an incident, six months after its author has left, by someone who wasn’t there when the decision was made. It’s the bedrock of a team’s memory.

Working Together in Real Time: Pair, Mob, Shadowing and Swarming

Mon, 20 Jul 2026 14:00:00 +0200

In the guide to collaboration modes, we set out a rule: tacit knowledge travels only through contact. Synchronous modes are therefore irreplaceable — but they come at a cost, and that cost is scary. “Two people on a single task means halving productivity.” This article proves the opposite and details the four main ways of working together in real time, with their variants and their pitfalls.

I. Why synchronous work is irreplaceable

An expert diagnosing an outage isn’t following a procedure: they eliminate hypotheses at a speed they couldn’t even describe themselves. Ask them to write down their method and they’ll hand you an impoverished list. That knowledge — the order in which you look at things, what triggers a suspicion — exists only in action.

Sharing Knowledge in a Tech Team: A Guide to Collaboration Modes

Mon, 20 Jul 2026 13:00:00 +0200

In “When the last expert disappears,” we saw why a team’s memory is an invisible form of technical debt. What remains is how to fix it. Pair programming, mob, shadowing, code review, ADRs, on-call rotation: there is no shortage of practices, and that is precisely the problem — you don’t know which one to pick. This guide maps them out and gives a simple rule for deciding.

I. Two kinds of knowledge: tacit and explicit

Before choosing a practice, you need to know what you are passing on. All team knowledge falls into two families, and they don’t obey the same laws.

When the Last Expert Leaves

Mon, 20 Jul 2026 12:00:00 +0200

In almost every organization there is a system people talk about in hushed tones. It has been running for ten years, it is critical, and exactly one person truly knows how it works. The day that person leaves — retirement, resignation, transfer — it isn’t just a colleague walking out: it’s an entire library closing down without ever having been copied. That lost knowledge is a form of technical debt, the most insidious of all, because it shows up on no dashboard.

DevOps Cycle or a Misunderstanding of the Role?

Tue, 17 Mar 2026 11:00:00 +0100

Introduction

The term DevOps is frequently used to describe a heterogeneous set of topics: CI/CD, cloud, Kubernetes, security, observability, incident management, cost management, and more. This breadth of meanings creates a recurring confusion: an organization expresses a need for “DevOps” without specifying the expected value, the associated responsibilities, or the target operating model.

The outcome is well known: a succession of urgent periods, followed by automation initiatives, and then a gradual return to the same difficulties. This is often described as the “DevOps cycle.” In many cases, this cycle is not intrinsic to DevOps itself, but rather the indicator of a misunderstanding of the role: DevOps is used as a compensating function (support, firefighting, implicit ownership of production) instead of as a structuring organizational capability.

ADR (Architecture Decision Record): documenting decisions that matter

Tue, 10 Mar 2026 11:00:00 +0100

Engineering teams spend a lot of time discussing, arbitrating, choosing… and then forgetting why they made certain decisions.
The outcome is familiar:

the same debates come back every three months,
decisions get challenged without the original context,
onboarding depends on “the people who know,”
and unnecessary migrations are born from a simple loss of memory.

An ADR (Architecture Decision Record) exists to avoid that. It’s not a “big architecture doc,” nor a requirements spec: it’s a short note that captures an important decision, with just enough context to keep it understandable and reusable.