In Parallel works because it uses a small set of concepts consistently. Once these click, everything else (meetings, reports, decisions, tasks) feels obvious.
In this article
Execution scopes (the container for accountability)
The living execution plan (the truth surface)
Snapshots (“what changed” made explicit)
Execution signals (what the system captures)
How these fit together in practice
Execution scopes
An execution scope is the unit of accountability in In Parallel. Everything lives inside a scope.
Examples of scopes:
a team (“Platform Team”)
a project (“Platform Migration”)
a program (“Q2 Growth Program”)
a portfolio (“Enterprise Expansion Portfolio”)
an account (“Customer X”)
a business area (“Revenue Operations”)
Why scopes exist
Scopes keep the system calm and legible:
they prevent “one giant plan for everything”
they make ownership explicit
they keep meetings and decisions connected to the right work
A simple test: is your scope the right size?
A scope is usually right when:
one person is accountable for outcomes (even if others execute)
decisions happen regularly (often via a recurring meeting)
priorities can be ranked without debate
A scope is usually too broad when:
you can’t rank priorities because “everything matters”
updates feel noisy or contradictory
multiple unrelated cadences are mixed together
Tip: If a scope feels noisy, split by ownership or cadence.
The living execution plan
Each scope has one living execution plan. This is the main “truth surface” of In Parallel.
What’s in the plan
A plan typically includes:
goals and commitments
ranked priorities
tasks and milestones
risks and dependencies
explicit ownership
recent changes
What makes it “living”
The plan stays current because it updates from:
meetings (where decisions are made)
connected system changes (where progress shows up)
and your review/confirmation (so trust stays high)
This is why In Parallel isn’t “a document you rewrite.” It’s a system that keeps execution reality coherent as reality moves.
Snapshots (“what changed”)
Every meaningful plan update creates a snapshot, so change is explicit and reviewable.
Think of snapshots as:
a visible “version history” of execution reality
a built-in answer to “what changed since last time?”
an audit trail you can trust
Why snapshots matter
Most teams lose time by reconstructing:
what changed
when it changed
why it changed
who agreed to it
Snapshots reduce that to a quick review:
here’s what changed
here’s the context (meeting/report)
here’s what the plan looks like now
Tip: Start every recurring meeting with “What changed since the last snapshot?” That’s the fastest way to orient the room.
Execution signals (what In Parallel captures)
In Parallel treats meetings as execution events. It can:
join recurring meetings connected to a scope
transcribe in real time
identify decisions, actions, ownership changes, risks, unresolved topics
link signals to the right scope
These aren’t stored as “notes.” They’re interpreted as execution signals that drive reports and plan updates.
How these concepts work together (the mental model)
Here’s the simplest model to keep in mind:
Scope = “what we’re accountable for”
Plan = “what execution reality looks like right now”
Meeting = “where execution reality changes”
Report = “what we captured + what we’re proposing”
Snapshot = “what changed, made explicit”
When you use the system consistently, clarity compounds.
Common mistakes (and how to avoid them)
Mistake: Making scopes mirror org charts
Scopes should map to accountability + cadence, not hierarchy. If a scope exists “because we have that team,” it often becomes noisy.
Fix: Create scopes where decisions happen and outcomes are owned.
Mistake: Treating the plan like a task list
The plan includes tasks/milestones, but it’s not where you manage every subtask. Delivery detail belongs in Jira/Asana/etc.
Fix: Keep the plan at the execution-reality level: priorities, commitments, risks, ownership, decisions.
Mistake: Not using snapshots
If you don’t review “what changed,” meetings slide back into status updates.
Fix: Use snapshots as your default review surface.
Related articles
What belongs in In Parallel (and what doesn’t)
Create an execution scope
Understand the living execution plan
What are snapshots?
Before & after meetings: pre-reads and reports