Petya went on vacation — and the builds stopped
Three weeks in the life of a company where a critical process ran on one person, and that person went to grill kebabs at the dacha. What I learned, and what I now do with those situations.
It was August, hot, holiday season. A client I'd worked with six months earlier called. "We're in panic," he said in that particular voice people use when the panic is the rest of the business, not just them. "Our prod builds aren't building."
— What happened?
— Petya left.
— Where?
— To the dacha. In Ruza. At his parents'.
— Is there connection?
— There's connection. But Petya's on vacation.
— Can you do it without him?
Pause. Not a telephone pause. An existential one.
Petya at this company was a senior support engineer, strong. In the informal list of his duties was the line "assembles prod builds Friday evening." Petya had assembled them for six years. First — because he was one of seven who knew how. Then — because he was the only one who knew where the certificates lived and in what order they had to be applied. Then — because he'd written a script that automated part of the process. The remainder lived in his head, in the form of "here you wait 30 seconds because otherwise the Apple API doesn't respond."
When Petya went to the dacha at his parents', it turned out he had no documentation. No README. No video. Not even notes in Jira. Because he wasn't planning to hand this part off. It hadn't occurred to him that he'd need to.
He still, by the way, doesn't understand the fuss. "I was reachable," he says. "You could have called." Yes. We could have. But Petya was on vacation. And calling someone at a dacha with a grill is bad management practice, for which the price is usually something non-monetary — like Petya leaving for a competitor six months later.
Over those three August days I did assemble the release — I called Petya twice (he wasn't angry, we brought him a bottle of cognac in September as an apology), and over the phone he dictated the steps. After which I told the client: "We need to fix this before I leave the project. Otherwise in six months to a year this repeats, and I'll be guilty of not having fixed it when we could."
The client agreed. We fixed it. Two weeks.
The fact that your team has a Petya is, as a rule, the result of local optimisation, not a conscious decision.
No one designs a process to depend on one person. It accumulates naturally. Petya did the task faster than anyone. Petya did it again. By the third time, everyone knows it's Petya. By the fourth, it's easier for Petya to just do it than explain. By the fifteenth, it's only possible via Petya, because the steps aren't written down. Not Petya's fault. It's systemic process erosion.
Petyas come in different shapes. Sometimes it's an engineer. Sometimes — an accountant who's the only one who enters things into the local tax system in a way that doesn't produce a fine. Sometimes — the senior salesperson who's the only one holding the pipeline in their format. Sometimes — the founder themselves, who's the only person in the company who understands why the strategy is that way and not another.
If your company has one Petya, that's survivable. Everyone lives with one. Three Petyas is a structural vulnerability. Five — you don't have processes, you have five autonomous people working next to each other and occasionally talking.
Four methods I apply when I find a Petya.
First — minimum runbook. Not "write a hundred-page wiki." No one reads that. Petya won't write it, he's bored. You won't review it, you're busy.
What works is one page. One process — one page. What it does, input, output, key commands, what to do when it breaks. Ten minutes to write. Five to verify.
Verification is simple: a week after writing, give the page to someone who's never done the process and have them follow it. They'll stumble in three places. Add those three places. Now the process is documented.
Second — pairing, two weeks. Petya does the task. Next to him (physically or on Zoom) sits Masha and watches. Doesn't ask questions. Writes down decisions and nuances.
Next week Masha does, Petya watches. Another week — Masha alone, Petya on standby.
After that Petya can get sick, get married, or go to his parents in Ruza — the business doesn't stop. Not because documentation is perfect. Because there's a second context-bearer.
Third — automate what can be automated. If Petya does this process by hand three times a week — it's a script candidate. Even a bad script covering 80% of cases frees 80% of Petya's time. The other 20% really does need the expert.
Conversely: don't automate what's done once a quarter. The cost of writing and maintaining automation exceeds the cost of doing it by hand. I had a client with exactly that — a financial report assembled four times a year. They spent half a year building automation. The automation never went live. Now the report is again assembled by hand, the way it was.
Fourth — rotation. The most painful method and the most effective. Once a quarter someone else takes what Petya does. Petya moves to an adjacent area.
First the team complains. Then Petya complains, because his expertise has been "spread." Then no one complains, because the knowledge is distributed.
Works in teams of four or more. Smaller — rotation doesn't help, no one to hand off to.
What doesn't work:
"Oh, they'll quit — we'll deal with it then." Documentation doesn't appear by magic on resignation day. Usually resignation happens faster than you can react, and Petya takes six years of context with him. I had a client who lost the sales team in a week after one person left, because that one person held the structure of relationships with fifteen key clients in his head. Expensive week.
"Let's hire another Petya." Doubles the resource, but doesn't change the structure. Two Petyas are still Petyas. Systemic fragility persists. It's just halved.
"The human context matters, you can't document it." Sometimes true. More often an excuse for not spending two hours on a runbook. Try spending them. See what happens.
There's an old engineering joke: "the only server without a backup is prod." Apply it to teams: the only process without redundancy is the process you're not prepared to lose.
"Everything rests on Petya" isn't a team virtue. It's an indicator of process immaturity. Petyas are great. The company still has to survive when Petya goes on vacation. Or quits. Or gets tired.
The question isn't what to do with Petya. The question is how to grow out of depending on one Petya. The answer is usually four hours of work and two weeks of pairing.
Petya, by the way, doesn't suffer. If Petya is a good one — he'll in fact be glad to have a vacation without calls.