Touching a codebase you did not write can be reasonable when the customer impact is urgent, the change is reversible, and you can prove the affected path before deployment. If those conditions are missing, contain the incident first and wait for the engineer who understands the system.
At 8:17 on Tuesday morning, I opened an urgent customer ticket. Our only engineer was offline on unexpected leave.
The repository was available. I could read the code. I could also deploy it. Access, however, answered only the administrative question. It said nothing about whether I understood the consequences well enough to act.
In 1983, Soviet duty officer Stanislav Petrov faced a decision with far higher stakes. The early-warning system at Serpukhov-15 reported that the United States had launched a missile. Then it reported more launches. Petrov had minutes to decide whether to pass the warning up the chain as a real attack.
The system was doing what it had been built to do: produce an alert. Petrov still had to decide whether the alert deserved belief.
Access is weaker than understanding
Petrov judged the warning inconsistent with the attack he expected to see. A small number of reported missiles made little strategic sense, and the available ground radar had not confirmed them. He reported a system malfunction rather than an attack.
The warning was false. Sunlight reflected from high-altitude clouds had confused the satellite system. The Association of World Citizens later documented Petrov’s decision when it presented him with its World Citizen Award in 2004.
The useful part of this story is smaller than the stakes surrounding it. A system can present a clear signal while hiding uncertainty underneath. The person at the console still needs an independent reason to trust what the system says.
My customer ticket was also a signal. Urgent was a label applied inside a support system. It did not tell me which users were affected, whether data was at risk, or whether the failure sat in our code, a dependency, configuration, or the customer’s own environment.
Opening the repository before answering those questions would have converted customer pressure into engineering risk.
The first job is to reduce uncertainty
I needed to separate the incident from the proposed fix.
First, I had to reproduce the failure or find direct evidence of it. A screenshot, an error message, and a customer description could narrow the search, but none proved where the fault lived.
Second, I had to identify the smallest affected surface. Was one customer blocked? Was one workflow failing? Could we disable that path, restore a previous configuration, or give the customer a temporary manual route?
Third, I needed a stopping rule. If the change touched authentication, payments, stored customer data, migrations, or shared infrastructure, I would wait. Those systems carry consequences that can remain hidden after the original ticket appears resolved.
This resembles the decision in Should I Approve an AI Agent’s Code Change While the Specialist Sleeps?. The source of the proposed edit changes, but the founder’s obligation remains the same: understand the failure, bound the blast radius, and preserve a clean way back.
A safe change must earn deployment
Reading unfamiliar code is different from changing it. Changing it is different from deploying it. I treat those as three separate permissions.
A change earns deployment when I can explain what caused the failure, why the edit addresses that cause, and what evidence would show that I am wrong. I also need a rollback path I can execute without the absent engineer.
That standard rules out the most tempting kind of founder intervention: editing the line closest to the visible error and hoping the test suite catches everything else. Tests cover what someone anticipated. The urgent ticket may have arrived precisely because the team missed a condition.
A contained workaround can be the stronger technical decision. It may involve more customer communication and less code. That can feel unsatisfying when the repository is open and the fix looks close, but restoring service without creating a second incident is the actual job.
The same principle appears in Technical Debt and Runway: What a Failed Deployment Rehearsal Taught Kojo: the ability to reverse a change matters before production gives you a reason to need it.
The engineer’s absence exposes the company’s design
An urgent ticket should not require one person’s memory to become understandable. If I cannot trace the affected path, run the relevant checks, or find deployment and rollback instructions, the morning has revealed an operating problem beyond the customer incident.
The next step after containment is therefore specific. Record the evidence used, the paths inspected, the decision made, and the conditions that would justify reopening it. When the engineer returns, review that record together and turn the missing knowledge into a runbook, test, alert, or safer deployment control.
Petrov did not treat the alert as meaningless. He compared it with independent evidence and acted within uncertainty. That is the standard I want at 8:17 on a Tuesday: neither blind trust in the ticket nor confidence borrowed from repository access.
The code can wait until the decision has earned the risk.
Comments
No comments yet.