Software Flow Is Not Process Theater
Software flow is not developer busyness. It is valuable change moving through the real delivery system without rottin...
The System Only One Person Understands
4 min read
The Names Everyone Knows
13.08.2026, By Stephan Schwab
A critical release is waiting, production is down, or finance needs an answer. The room says the same name. That person is not merely your best expert. They have become part of the architecture. The company still ships, so the dependency looks manageable. Then a change waits for a flight to land, a vacation quietly freezes a roadmap item, or a new developer spends weeks collecting oral history. Respect for the expert has turned into schedule risk, incident risk, and a quiet veto over change. A documentation drive will not fix this. The missing asset is judgment: why the rule exists, which exception matters, and how to change the system without breaking the business. Judgment moves through shared work. Pair on risky changes. Turn recurring explanations into tests. Make reviews small enough to understand. Let someone else deploy while the expert watches. The expert is usually not hoarding knowledge. They have been rescuing the organization. The CTO's job is not to blame them or replace them. It is to stop every rescue from deepening the dependency. Which critical change in your company still begins with the same person's name?
The Expert Is Usually Not the Problem
The person everyone depends on is usually not hoarding knowledge. They are absorbing organizational debt on behalf of everyone else.
Knowledge concentrates because asking the expert is faster than sharing that judgment. They fix production, explain the billing exception, and rescue the release. Work continues. The dashboard stays green. Every rescue makes the dependency look normal.
The risk usually hides in boring business rules: finance calculations, onboarding exceptions, old processing jobs, migration scripts, integrations, or spreadsheet logic that quietly became infrastructure. If nobody understands the component library, the team will complain and fix it. If nobody understands what customers owe, the company is negotiating with reality using guesswork. Reality is not known for generous payment terms.
Run the Vacation Test
If someone has to interrupt a vacation to keep ordinary operations running, the organization has already received the warning.
Can the person take two weeks off without the team quietly lowering its ambition?
Not “can the company survive.” Survival is a low bar. Ask whether normal work can continue safely:
- Can someone else deploy?
- Can someone else explain and change the critical business rule?
- Can an incident be investigated without oral history?
- Can a new developer work in that area without a personal guide?
If the answer keeps being no, the vacation calendar is part of the architecture. Hiring more people into that maze does not create a map. It creates a longer queue for directions.
Documentation Is Not Judgment
Documentation captures answers. Knowledge transfer builds judgment. That takes longer and is much harder to fake.
You probably need better documentation. You also need to stop pretending it can carry the whole load.
A document can explain that a financial calculation uses a particular rule. It cannot automatically teach someone when that rule is wrong for a migrated customer, why the exception exists, which downstream report will complain, and how much risk the business accepts if the number is corrected later.
That judgment develops while changing the real system. Someone else investigates. The expert explains why, not only what. Together they add a test, guardrail, or clearer design. Then the other person makes the next change with less help.
Move Judgment Through the Work
The useful unit of progress is not a complete knowledge base. It is one fewer hidden dependency.
Start with one critical area where the same name keeps appearing. Make the next risky change a paired change. Let someone other than the expert write the code, investigate, deploy, or recover the system. Turn one recurring explanation into an executable test. Make the review small enough that another person can genuinely understand it.
Pairing, TDD, CI/CD, trunk-based development, and real code review are not decorations here. They are transfer mechanisms. Used pragmatically, they move judgment through daily work and shorten the distance between assumption and evidence. Used ceremonially, they are just more meetings and badges.
In the first pairing session, one risky change becomes the transfer vehicle. One person writes the code, another explains, and others verify. The bug is useful because it forces hidden assumptions into the open.
If the team cannot create that space alone, put a senior person beside the expert and the CTO. The job is to work inside the code, delivery flow, and operations until the dependency shrinks—not to arrive with a documentation program and another framework.
The Quiet Veto Over Change
Knowledge concentration eventually gives old systems a veto. It appears as caution: “Let’s not touch that before quarter-end.” “That area is risky.” “We need to wait until Martin is back.”
The roadmap bends around ignorance.
That is the real cost. The company starts making strategic decisions inside the limits of what a few people still remember. A regulation changes, a key person leaves, or an AI project tries to automate a process nobody can explain—and caution becomes paralysis.
Do not blame the people who kept the system running. Change the system that made rescuing it their permanent job.
Talk It Through
Tell me what is happening. I listen, ask a few practical questions, and reflect back what I see: where the risk may sit, what may be blocking delivery, and what looks worth checking next. No pitch, no obligation. Confidential and direct.
Talk it through. Practical reflection, no pitch.
Start a Conversation
🎭 This Week's Episodes
Telenovelas show what we can't say in client meetings. The drama is heightened, but the patterns are real.
The Horse With Brio
Valentina Sánchez Herrera rides onto Stefan's finca to check on her father's Peruvian Pasos and finds Sophie watching from the fence. Within an hou...
The Aftermath of Expertise
The night after his second firing, Ethan Carter sits in a Cleveland burger bar with two fellow rescue specialists and finally names the trap he wal...
Technical Consultancy
Embedded Delivery Partner
Embedded into your team as an active contributor, reducing delivery friction and helping important work move cleanly.
Technical Advisor
Peer-style technical assessments before far-reaching decisions; reduce architectural and product risk early.
Product & Delivery
Ship working software to real users earlier. Measure impact and adapt based on evidence rather than assumption.
Custom Software Development
High quality, maintainable software. Short-term augmentation that leaves lasting capability in your own team.
Recent Articles
- The System Only One Person Understands (13.08.2026)
- Before You Hire an AI Executive, Stop Treating AI as Magic (08.08.2026)
- Nobody With Delivery Scars Is in the Room (05.08.2026)
- Software Flow Is Not Process Theater (01.08.2026)
- When Vibe Coding Meets a Real Developer (28.07.2026)