How do I map what changes when my responsibilities shift to a new role?

Start with a list of actual responsibilities, not just job titles or broad areas. For each one, choose a change type:

1. Continues: you remain responsible.
2. Stops: the work ends or is no longer part of your role.
3. Transfers: someone else takes it on.
4. Begins: a new responsibility enters your role.

Then add the current owner, future owner, people or decisions affected, and transition date. Use “proposed” or “not agreed” when a date or owner is still uncertain. That makes the map useful for discussion without presenting assumptions as settled facts.

For example, if you currently prepare a weekly project update and a colleague is expected to take it over, list the update itself as Transfers. Name yourself as current owner, put [receiving colleague] as proposed future owner, note who relies on the update, and write [agreed handover date] rather than making up a date.

For each responsibility, name people by their relationship to that work: who provides an input, makes a decision, receives the output, or depends on its timing. Include a person or team only when the change may alter their action, decision, or expectation.

For instance, a recurring report might affect the person who supplies figures, the manager who reviews it, and the team that uses it to plan. You may not need to list every person who sees it. If you are unsure whether someone is affected, mark that as a question to check rather than treating it as confirmed.

Keep this focused on work and handover needs. The map is not a performance assessment, and it does not need private details about colleagues. A simple “affected by” field is often enough; add a short note when the effect needs explaining.

Separate the target date from the condition that could affect it. Use clear labels such as confirmed, proposed, and open. For a transfer, also note what needs to happen before the new owner can take full responsibility—for example, a walkthrough or approval—without assuming that it has been scheduled.

A compact entry could read:

Responsibility: Prepare weekly project update Change: Transfers Current owner: [your name] Future owner: [receiving colleague—proposed] Affected: [reviewer], [teams using the update] Target date: [date—proposed] Before transfer: Confirm walkthrough and input source Open question: Who covers the update if the date moves?

This shows what is known and what needs a decision. If one change depends on another, name that dependency directly, such as “transfer follows access approval,” and ask the responsible people to confirm both the condition and timing.

Share it as a draft for validation, not as an announcement that every change is final. Ask your manager to confirm the scope and decision owner. Ask each receiving colleague whether the responsibility and proposed timing are realistic, and ask affected partners what they need to avoid a gap.

Work through the entries with unresolved owners, dates, or dependencies first. Record decisions and who will confirm them. If a responsibility has no agreed owner yet, leave it marked open and raise it with the person who can assign ownership. After the discussion, update the map and send the agreed version to the relevant people, using your usual work channel.

Keep the map current through the transition: revise it when an owner, date, or decision changes. It is a coordination aid, not proof that a handover is complete. Confirm completion with the people involved rather than inferring it from a date on the page.