The worst week I have managed through started on a Tuesday morning with a message from my director: the company was cutting a neighboring team that afternoon, my team would inherit their system, and I could not say anything until the announcement at two.

By ten, my team knew something was happening. People on the other team had gone quiet. Two of mine came to ask me directly. I said I could not talk about it yet, which was true, and which also confirmed everything.

What I did in the four hours after the announcement mattered more than anything I did that quarter.

Say what you know, say what you do not, say when

The first rule I follow in a bad situation is to speak early, even when I have very little. Silence gets filled, and it gets filled with the worst version. So at 2:15 I had the whole team in a room.

I told them what had happened and why, as far as I understood it. I told them what it meant for us: we were taking on the system, nobody on our team was affected, and I did not yet know what it meant for the roadmap. I told them when they would hear more: Thursday, from me, whether or not I had answers by then.

Three things: what I know, what I do not know, when you will hear from me next. That structure has held up through layoffs, cancelled projects, a security incident, and a reorganization. It works because it is honest about uncertainty without leaving people alone in it.

Do not perform calm. Be specific instead

There is a version of leadership in a crisis that is mostly tone: steady voice, reassuring phrases, a lot of "we will get through this." Teams see through it, and it costs credibility when the reassurance turns out to be empty.

What steadies people is specificity. Not "we will figure it out" but "here is what we are doing tomorrow morning: Ana and I are meeting the other team's lead to get the runbooks, and by Friday we will know what is on fire in that system." Concrete next steps are calming in a way that reassurance never is, because they prove someone is actually driving.

The individual conversations

After the group meeting, the real work is one person at a time. Everyone processes a bad week differently, and the group setting only reaches the people who talk in groups.

I moved every 1:1 that week to within two days of the announcement. Some people wanted to talk about the friends who had been let go. Some wanted to know whether they were next, and I gave them the honest answer, which was that I had no indication of it and would tell them the moment that changed. One wanted to know whether this meant the company was in trouble, and I told him what I knew about the numbers, which was more than he expected me to share.

The person I worried about most said he was fine and wanted to get back to work. I checked on him again a week later, and he was not fine, and that second conversation was the one that mattered.

Protect the work without pretending

A bad week is not the moment for a new initiative or a deadline push. It is also not the moment to let everything stop, because work is stabilizing for most engineers and a team with nothing to do stews.

I cut the sprint in half, kept the parts people were already deep in, and made it explicit that the other half was gone because of the week, not because of them. Then I took the inherited system's incident load onto myself and one volunteer for the first two weeks, so the rest of the team was not learning a stranger's codebase at three in the morning while also grieving colleagues.

What people remember

A year later, when I asked people on that team what they remembered about that week, nobody mentioned the roadmap. They mentioned that they heard from me before the rumor mill got to them, that I said "I do not know" out loud, and that the Thursday update came on Thursday.

The bad week is going to happen. The only decision you get is whether the team comes out of it trusting you more or less. That decision gets made in the first hour, and then confirmed every time you said you would follow up and did.