**00:00:02 — Maya:** Welcome to Development Radio. I'm Maya, here with Alex. Today we're talking about invisible engineering work—the quiet work that helps other engineers move, and why it can be hard to describe. Alex, do you keep a little list of things you did that weren't on your actual list?

**00:00:20 — Alex:** Yes. It lives on the back of the first list. Very official system. I know the afternoon went somewhere, but the page just says, “Talked to three people.”

**00:00:30 — Maya:** Mine says, “Found the right person.” Which sounds absurdly small until I remember how long it took to find them.

**00:00:37 — Alex:** I'd keep that one. I'd also want to know what happened after you found them. Otherwise the list makes you look like a very dedicated phone book.

**00:00:45 — Maya:** Fair. I don't want a trophy for forwarding a message. I do want to know whether the conversation helped. That's hard to write down while the day is moving.

**00:00:54 — Alex:** My end-of-week account is written by a slightly optimistic stranger. He remembers the clean finish and forgets the middle.

**00:01:01 — Maya:** I know that stranger. She has excellent handwriting and very few details. On Friday that annoys me. On Tuesday I'm grateful for the scraps. At least they remind me what to ask about. Not everything happens in neat tickets.

**00:01:15 — Alex:** Then let's keep one beside us today. We can decide later which line deserves the space.

**00:01:20 — Maya:** All right. Here's the release team I want us to follow. One engineer repairs their merge check and somehow remains the person every release waits for. Can the next release move without her holding the handoff, and can her work still count?

**00:01:34 — Alex:** Start with the one we can point to.

**00:01:36 — Maya:** Their protected branch requires an integration check before changes can merge. Two integration tests were changing the same shared fixture. Depending on timing, the check failed and held up a merge. An engineer found the collision and separated the test data. After the fix, both tests ran, and the required integration check passed on the change they want to merge.

**00:01:58 — Alex:** GitHub's documentation for a branch configured that way says “all required status checks must pass” before a merge. This required check passed on their change, so it no longer blocks that merge. That's a repair you can name. What happens after the merge?

**00:02:14 — Maya:** There's a separate team step before the release. The named on-call engineer needs the rollback instructions for this release and has to acknowledge receiving them. Until now, the engineer who fixed the test has been the person who gets that answer. The merge check works. The release still waits for her handoff knowledge.

**00:02:32 — Alex:** Right. The passing check clears one merge obstacle. The team itself is waiting for another answer. What does she do for them after the merge? Is she just sending a link?

**00:02:43 — Maya:** She knows which instructions apply to this release. She sends them to the named on-call engineer and stays with the request until on-call acknowledges receipt. That reply doesn't prove a rollback would work. It tells the team on-call has the instructions before they decide to release.

**00:03:00 — Alex:** And she's the one who remembers to ask, then comes back for the reply. I can see why the team waits for her, even with a perfectly good document somewhere.

**00:03:08 — Maya:** I can too. My first instinct is to stop making her the default. Put the release lead on this handoff now. She fixed the integration check and is trying to get back to test and service work. Every surprise request takes another piece of that day.

**00:03:23 — Alex:** I want to give her the time back. Let's put the lead at the release sheet. They can find the on-call name and send a message. Where do they get the instructions that apply to this release?

**00:03:33 — Maya:** From her, at least this time. I wouldn't pretend a new name on the sheet transfers what she knows. I'd ask her in a planned overlap, then have the lead own the message and the wait. That's different from people interrupting her whenever they're nervous.

**00:03:46 — Alex:** It is. But say the release decision arrives with no reply from on-call. Do we call her back because she usually knows how to chase it?

**00:03:55 — Maya:** No. The lead follows up. If the acknowledgement still isn't there, the team pauses the release. That's the cost of taking its own handoff seriously. A passing merge check doesn't turn silence into a confirmation.

**00:04:08 — Alex:** I agree with the pause. I also know what the release lead would say to me: “I have a feature change due. You want me to find the right instructions, send them, and stay on the unanswered message. Where does that time come from?”

**00:04:20 — Maya:** I'd probably have said, “It's one release message.” Then I'd hear myself. The message is easy to count. Remembering to come back until someone answers—that's why everyone has relied on her. Put that wait on the lead's evening and we've only changed a name.

**00:04:35 — Alex:** That's the part a calendar invite can't solve. There are two people whose planned work has to move: the lead who will take the handoff and the engineer who will teach it. Would you still take her off the surprise requests before the transfer is done?

**00:04:49 — Maya:** Yes. I want a boundary today. But I wouldn't tell her to disappear while this release has no other owner. I'd ask the manager to move both feature assignments out of the release window and reserve overlap as release work. If the team won't make that room, we postpone the release rather than quietly make her the fallback again.

**00:05:08 — Alex:** Then there's her review. It already says her delivery is hard to see. If she spends this release teaching the lead, what will her manager say that time produced?

**00:05:18 — Maya:** That's the part I don't want to leave to Friday memory. She repaired the fixture and kept these handoffs moving. Teaching the lead may be right for the team. Before asking for more of her time, I want the manager to agree that this work goes into the review conversation.

**00:05:33 — Alex:** Tanya Reilly has a name for work that keeps other people moving: glue. In *Being Glue*, she argues that teams should allocate it deliberately, make it visible, and give people a choice about where it takes their careers. That doesn't make this engineer's choice for her. Has anyone asked what she wants?

**00:05:51 — Maya:** They did. She says she wants to return to test and service work, not stay the standing release coordinator. She'll teach this handoff if the time is reserved and the contribution is recorded. I like that answer. Her competence isn't the team's permission to use all her time.

**00:06:06 — Alex:** So the manager agrees to both halves. The two feature assignments move out of this release window, and her fixture repair, the earlier handoffs and this teaching go into the review conversation. It has to be both. Credit without a handoff keeps the team leaning on her. And a handoff without credit makes her pay for the move.

**00:06:25 — Maya:** That's exactly what she asked for. In their reserved time, she shows the lead which rollback instructions apply to this release. They walk through who is on call and what acknowledgement the team needs. She is there to teach. The lead will own the live message and the wait.

**00:06:40 — Alex:** So they made room, have the instructions, and agreed to record the work. But on-call has not acknowledged anything yet. Knowing what to send did not finish the handoff.

**00:06:50 — Maya:** Right. The lead sends the instructions to the named on-call engineer and asks for an acknowledgement. No reply arrives at first.

**00:06:58 — Alex:** That's the old moment. Someone would glance at the unanswered message, then ping her: “Could you just take this?”

**00:07:04 — Maya:** That's the moment I'd expect somebody to ping her. But the lead follows up. The on-call engineer replies, “I have the rollback instructions for this release.” The lead records it. She taught the handoff. She didn't have to chase this acknowledgement.

**00:07:18 — Alex:** The lead stayed for the answer. That's the handoff. Not sending the message—staying until the answer.

**00:07:24 — Maya:** Yes. It's one step on one release. We haven't tested a rollback or seen a deployment. But this time, the release didn't wait for her.

**00:07:33 — Alex:** Then I'd put three lines on her scrap: the fixture repair, the handoffs she kept carrying, and the teaching that let the lead do this without her. The manager agreed to record all three. How the review ends, we don't know.

**00:07:46 — Maya:** So here's one thing to try this week. Ask what would stop if one person took a week off. If it's a handoff that lives in their head, sit down with them and their manager. Name the next owner, clear time for the teacher and the new owner, and write down who did the teaching.

**00:08:02 — Alex:** I think your optimistic Friday stranger could write that down.

**00:08:05 — Maya:** She could. I'd still keep the messy scrap beside it. Thanks for listening to Development Radio.