Mapping People and Teams

Mapping people and teams answers a simple question: when this service breaks, who does what, and who steps in if that person is unavailable? A service map that lists systems but not people is half finished, because systems do not make decisions, approve workarounds, or call a supplier at an awkward moment. People do. The people layer should name the operating team, the supporting teams, the decision maker during a disruption, and the cover for each critical role. It should also record how each person or team is reached through the incident route, not merely through an ordinary office directory that may itself be affected.

Start with the roles that touch the service in normal operation and in recovery. That usually includes the team that runs the service day to day, the technology team that supports its systems, the operations team that handles customer impact, and the manager who can authorise a workaround or a change of plan. It may also include specialists whose knowledge is rarely needed but decisive when it is, such as the person who understands a legacy integration or a particular supplier contract. Naming a team is often enough for routine work, but for decisions and for rare knowledge, a named role with a named deputy is safer than a generic team mailbox that nobody owns.

Cover fails quietly. A map may show a capable owner for every part of a service, yet still collapse if that owner is on leave, unwell, or already dealing with another incident. Good people mapping therefore records a deputy for each critical role and checks that the deputy can actually do the work, not merely that a name exists on a chart. That check matters most for roles that are held by one person, for night and weekend cover, and for roles that require access rights or supplier contacts that a deputy may not yet hold. If the deputy cannot act without the absent owner, the map has recorded an intention rather than a capability.

People should be tied to the parts of the service they own, not listed in a separate directory. A team that owns a payment processing system should appear next to that system on the map, with its escalation route noted alongside. A team that owns a manual workaround should appear next to that workaround, with a note on when it is authorised to act. This linkage is what makes the map usable in an incident. Responders do not want to cross-reference three documents to learn who owns a failing component. They want the owner, the deputy, and the contact route in the same place as the component itself, so action can start without a search.

Reorganisations, departures, and new hires change the people layer faster than any other part of a map. A team may be renamed, split, or merged, and the map may still show the old structure long after everyone else has moved on. The remedy is to treat people changes as map changes. When a role moves, the map should move with it, and the outgoing owner should hand over not only tasks but also the knowledge of why a dependency exists and what has gone wrong before. Exit and handover checklists help here, provided they are treated as part of the map rather than as a separate administrative chore that is easy to skip.

Test the people layer by removing names, not by adding them. In a tabletop walk, announce that the usual owner is unavailable and ask the deputy to describe the next steps, the workaround, and the supplier to call. If the deputy hesitates, the gap is real, however complete the chart looked. Repeat the exercise for different roles and at different times, because cover that works on a weekday may fail at a weekend. Also check that contact routes work when the usual tools are down. A contact list stored only in a system that the incident has taken offline is not a contact list at all, and the test should expose that before a real disruption does.