The work around the code
Software engineering gets talked about as design and code. A large share of the job happens around the code: keeping what shipped running, answering for it when it breaks, getting the next release out, and knowing how it all fits together. Most of that lands on whoever is on rotation that week — and if your team has ten developers, that week comes round every ten weeks; if your team is four, every month. If the load needs two people on the shift, it comes round twice as often.
I never really liked being on-call. The ad hoc work and the stress: overnight pages that turn out to be false alarms, single-customer escalations that would never count as an incident, and a queue that is a good share noisy monitors and wrongly assigned tickets you have to hand on — once you remember which team to hand them to. And everyone wanting everything now.
Some weeks you are not only handling incoming issues but also managing releases: cutting the release branch, triggering the automated tests, deciding whether the results are any good. Often enough the tests are flaky, and you have to remember which errors are real and which are expected. Then people want you to also fix those issues going forward — while your head is already full from the multitasking on every front.
It is striking how easy it is to get software out the door and how hard it is to keep it running once it lands in production. And that is before the constant migrations, the dependencies being deprecated, the security mandates and the cost mandates you have to account for — each of which will occasionally take your service down. In a bigger company, just finding your way is work: who is this person, what does that other team do, my service is broken and I don’t know who to reach out to. In a smaller company the map is smaller, but the shift is the same — and it comes round faster.
Depending on the team and the load, it drags on people’s minds long before and after their week. Taking that shift off the team is a real win: fewer interrupted weeks, less paid-for dread, and engineers who get their heads back.
Little of this is in anyone’s job description. So I wrote one. Petra is a digital duty engineer you hire like a contractor: she takes that shift — morning triage, first response on the page, the release train — starts read-only, and what she learns about your systems stays learned. That is why I’m building her. Your team, plus one.