When the Team Disappears But the Work Doesn't

Field Note #08: When the Team Disappears But the Work Doesn't

The day the guides left the mountain

When the public announcement came down that all commodity IT needed to be handled by another external agency, we recognized that meant us. We just didn't realize we would be the first, nor did we understand the full extent of the impact.

This was our IT team. Fourteen people who handled our workstations, network, printers, phones, mobile devices -all of it. And not all of their functions were being transferred to the new agency, which meant we lost our people but kept a significant portion of the work they'd been doing.

These weren't contractors or temporary staff. This was staff who'd been with us for over a decade or more. They'd been managing our infrastructure for years. Every workstation build, every network change, every new phone activation, it ran through them.

And none of that work was going away. The workstations still needed to be received, set up, and configured. The network still needed to be managed. The printers still jammed. The phones still needed to be activated and handed out. Every service they owned still had to happen. It just had to happen without them. And it had to happen now, because the mandate didn't come with a grace period.

What this kind of change usually looks like

I've been through 2 reorganizations before. I've watched teams get restructured, responsibilities shuffled, headcount reduced. And in almost every case, the pattern is the same. Leadership announces the change. People scramble. Maybe there's a handoff document, thrown together in the last two weeks before the deadline. And the receiving members show up, sit down at their new workstation with no real idea what they're walking into.

Requests go unanswered. Things that used to take a day now take a week because nobody knows the steps and nobody owns the process. And months later, leadership is still wondering why there are problems. People adapt and find their way. The chaos eventually smooths out, but not without churn.

It's not a people problem. It's what happens when the work lives in the team instead of in a system. When the guides leave and there's no map, everyone's lost.

What was different this time

The IT team was deeply integrated into many of our processes. Their work wasn't isolated to a few tickets -it was woven through services across the organization. Workstation setup touched Asset Management. Network changes touched Security. Phone activations touched HR onboarding. Pulling them out wasn't a clean cut. It was more like removing a load-bearing wall and figuring out what needed to be shored up on either side.

What saved us was that the work was already documented in the system. Every service they touched was defined. Every task was documented. Every ticket they'd ever run was sitting in Everstep, intact. We didn't need to reverse-engineer what they did or ask the outgoing team to write up a summary before their last day. We already knew exactly what they owned and exactly how it was done.

The trail was marked. We just needed new people to walk it.

Updating the map, not redrawing it

The transition came down to a few hours of focused work, not weeks of chaos. We went through each service template and updated the team assignments. Workstation setup, which had always routed to the IT team, now routed to our Asset Manager. Network management went to the Network Team. Phones and mobile devices became other duties assigned to staff.

It wasn't a redesign. The steps didn't change. The process didn't change. The work was the same work it had always been. We just updated who was responsible for each piece of it. In a system without structured services, that would have meant rewriting everything from scratch, documenting steps nobody had ever written down, figuring out who was capable of owning what, training new staff, and hoping nothing fell through the cracks in the meantime.

Instead, it meant opening a service template, changing a team assignment, and saving it. The next ticket that came in routed correctly. The new team saw their tasks. The work kept moving.

When the work is in the system and not in the people, losing the people doesn't mean losing the work.

How the receiving teams experienced it

Not going to lie. It was chaotic. Most services transitioned fine, but the disruption was real and the teams that inherited new responsibilities hadn't asked for them. What they did have, though, was the full history of how the work had been done. They didn't start from nothing. They started from a defined process with every prior ticket intact.

That matters more than people realize. When a team inherits work they didn't ask for, the hardest part isn't usually the work itself. It's the uncertainty. What exactly are we responsible for? What does done look like? What did the last team do that we don't know about? Those questions create anxiety, slow things down, and erode confidence before a single task is completed.

When the answers are already in the system, the uncertainty goes away. The team can focus on doing the work instead of figuring out what the work is.

What change management actually requires

There's a whole industry built around change management. Consultants, frameworks, playbooks. And a lot of it is genuinely useful. But I've come to believe that the single most important factor in whether a transition goes smoothly isn't the communication plan or the org chart or the rollout timeline.

It's whether the work was ever structured in the first place.

If the work is structured, if it exists as defined services with clear steps and assigned owners, then change is an update. You change the owner. You adjust a step. You redirect the routing. The process itself remains intact, and the people stepping into new roles have something concrete to grab onto.

If the work isn't structured, if it lives in habits, inboxes, and institutional memory, then change is a disaster. You're not transitioning the work. You're starting over. And starting over while the organization still expects everything to keep running is exactly as hard as it sounds.

The guides left. The trail stayed.

It was amazing to me that we were able to shift all that work around and no one really blinked an eye. Without Everstep, adding steps to a process was a major undertaking that took months before staff fully adopted. In Everstep, we made changes all the time to keep up with new policy, new direction, new security requirements. The staff just accepted it. It became part of their routine.

That's the test of a good system. Not how it performs when everything is stable, but how it holds up when something changes without warning. When a team dissolves. When a mandate comes down. When the people who knew how things worked are suddenly gone.

The guides left. But the trail was marked. And the people who came after them could follow it from the first day.