gtmjosh
Carry the Work Across
Chapters
  1. 01 · Map the Teams and Systems
  2. 02 · Define What Each Handoff Carries
  3. 03 · Track Waiting, Running, Completed, and Failed
  4. 04 · Handle Temporary and Permanent Failures
  5. 05 · Reconcile Systems That Disagree
  6. 06 · Notify and Escalate to the Right Owner
  7. 07 · Confirm the Business Outcome
  8. 08 · Capstone: Follow One Record End to End
Guide overview →

12 min · Interactive exercise

Chapter 1 of 80 complete

Map the Teams and Systems

Name every system and team, give each an owner, and say which system is right when they disagree.

The architectural move that makes everything else in this guide possible is small and easy to skip: keep your own copy of what the other system thinks is true.

Your interface reads local records. One client owns outbound requests to the other system. One component is the only thing permitted to change remote state. That is the whole pattern, and it does three things at once. It removes the remote system's semantics from your interface. It creates one place for retries, correlation, and audit. And it gives you something to compare against, which is what Chapter 5 needs.

Without it, every screen is a live call to somebody else's API, every failure is a blank panel, and there is no way to ask what changed since yesterday because nothing was ever recorded.

One owner per system, and one authority per fact

Every system on the map gets a named owner. The map is not a diagram of boxes and arrows, it is a list of things that can go wrong and the people who will be asked about them.

Then the harder question: for each fact the workflow depends on, which system is authoritative? Not which systems hold it, because all of them hold it. Which one is right when they disagree.

A fact with two authorities is not a fact, it is a future incident. And the answer is often counter-intuitive: the system that displays a value most prominently is frequently not the one that should own it.

Observation without mutation is a real mode

A system can appear on your map in observe-only mode: read, reported on, and never written to. That is not a lesser state or a stepping stone you are embarrassed about. It is how a system earns the right to write.

In a working sequence-orchestration setup, the audiences the system manages and the audiences it merely observes appear on the same board, side by side. Hand-built lists are visible, counted, and reported on, with mutation switched off. That visibility is worth having on its own, and it is also what lets you find out what your writes would have done before they do it.

GTM Lab

Saved locally
Cross-System Operating Plan · 0 of 8 sections started

Saved locally to your browser.

Draw the map

Four systems carry this workflow. Give each an owner, then answer the harder question: which one is right when they disagree?

Sample situation

A dashboard with no memory

FIXTURE-LIVE-API-EVERYWHERE
Every panel
A live call to somebody else’s API
When the provider is slow
The page is slow
When the provider is down
The page is blank
"What changed since yesterday?"
Unanswerable, because nothing was recorded
What is missing
A local copy of what the other system thinks is true
Resets every run.
How should ownership be assigned across the four systems?
Which system is authoritative for cadence membership?
Chapter 1 of 80 complete