Chapter 9 — System Landscape Identification¶

Before you invent a system, you should map the systems already operating in the space.

This chapter is about a specific decision:

Should we adopt an existing system, adapt one, or design a new one?

Most organizations skip this step. They either:

copy what peers are doing, or
invent something new without realizing they are duplicating existing logic.

System Landscape Identification prevents both.

The Failure This Chapter Prevents¶

Observable failure: organizations accumulate overlapping frameworks that optimize different decisions and create conflict, drift, and compliance theater.

Symptoms:

multiple “sources of truth” for priorities
different teams using different definitions for the same concept
governance expands because no system is trusted
teams spend time translating between frameworks
new initiatives add process rather than removing it

Root cause:

systems are introduced without a landscape view of what already exists and what decisions are already “owned.”

What “Landscape Identification” Does¶

Landscape identification is not “research frameworks.” It is an operational diagnostic.

It answers:

What systems are currently shaping decisions? (official or unofficial)
What decision types do they optimize?
Where do they overlap or conflict?
What failures are not addressed by any system?
What should be removed before adding anything new?

The output is a map you can use to make rational choices about adoption and design.

Inputs Required¶

You need only three things:

an observable failure statement (Chapter 4)
the unit of analysis (Chapter 6)
the decision type that keeps failing (Chapter 2)

Everything else can be discovered during mapping.

Step-by-Step Method¶

Step 1: List the systems actually in play¶

Include:

formal frameworks (OKRs, Scrum, ITIL, SAFe, DDD, etc.)
governance mechanisms (architecture reviews, change approval boards)
planning cadences (quarterly planning, weekly exec review)
tooling-driven systems (ticket workflows, deployment gates)
cultural default systems (“everything must be consensus”, “ship first, fix later”)

A “system” counts if it changes how decisions get made.

If people change behavior because it exists, it’s in the landscape.

Step 2: Classify each system by decision type¶

For each system, force one primary decision type:

priority
scope
ownership
sequencing
investment
diagnosis
repair

If you can’t assign a decision type, the system may be:

pure reporting (legibility system)
a vocabulary (naming system)
a ritual (coordination habit)

Those still matter because they consume attention and shape behavior.

Step 3: Locate each system in the lifecycle¶

Where does it primarily operate?

strategy
discovery
delivery
cooperation
evolution / scaling

This prevents “everything everywhere” descriptions.

Step 4: Identify the primary object(s) of control¶

For each system, write 1–2:

goals
work items
interfaces
domains
constraints
incentives
information flow

This reveals hidden conflicts (e.g., two systems both controlling work item priority with different rules).

Step 5: Map overlaps and collisions¶

Look for:

two systems optimizing the same decision differently (collision)
one decision optimized by no system (gap)
a system producing an artifact that another system ignores (disconnect)
a system that requires authority another system undermines (enforcement conflict)

Typical collision examples:

OKRs (goals/investment) vs roadmap commitments (scope/sequencing)
Agile team autonomy vs centralized architecture review vetoes (ownership/authority)
Platform interface ownership vs product team “move fast” incentives (interfaces/incentives)

Blind spots are recurring failures with no supporting system.

Common blind spots:

ownership of cross-team interfaces
repair capacity allocation (always sacrificed to features)
decision logging (no learning loop)
kill criteria for initiatives (nothing dies)
standards lifecycle (everything is permanently “recommended”)

Your landscape map should make at least one blind spot obvious.

The Primary Artifact: The Landscape Matrix¶

Create a matrix with one row per system:

System name
Decision type optimized (primary)
Lifecycle location (strategy/discovery/delivery/cooperation/evolution)
Unit of analysis
Object(s) of control
Artifact produced
Constraint/enforcement mechanism
Known misuse/failure mode

You do not need perfect accuracy. You need enough clarity to see overlaps and gaps.

What “Good” Looks Like in a Landscape¶

A healthy landscape tends to have:

clear ownership of the major recurring decisions
minimal overlap (or explicit precedence rules)
one primary artifact per decision domain
explicit defaults when decisions are not made
visible review points where systems can be modified or retired

A sick landscape tends to have:

many artifacts, few decisions
many cadences, little enforcement
unclear precedence (“which system wins?”)
“special cases” that become the majority

Decision Outcomes From Landscape Identification¶

At the end, you should be able to choose one of three actions:

Action A: Adopt an existing system¶

Choose this when:

the failure matches the system’s intent
the unit of analysis matches
enforcement is feasible
the misuse model is acceptable

Action B: Adapt an existing system¶

Choose this when:

the core logic fits, but
object of control or constraints need adjustment, or
the system must be made compatible with existing systems

Action C: Design a new system¶

Choose this only when:

no system in the landscape optimizes the failing decision, or
existing systems are structurally incompatible with your constraints, or
the failure requires a new artifact/constraint combination

New system design is expensive. The map helps you justify the cost.

Misuse Model: How Landscape Identification Gets Misapplied¶

Misuse 1: Treating it as a literature review¶

You don’t need to know every framework. You need to know what is operating in your environment.

Correction: map reality first, then research only as needed.

Misuse 2: Using it to attack existing systems¶

People use the map to blame teams (“your system is bad”).

Correction: the map is diagnostic, not a weapon. Focus on collisions and gaps.

Misuse 3: Over-mapping¶

Teams spend weeks perfecting the map.

Correction: timebox the map. If it doesn’t reveal collisions and gaps quickly, you’re missing the right level of abstraction.

The Non-Negotiable Rule Introduced Here¶

You may not add a new system until you can answer:

What existing system should be removed, weakened, or subordinated?
Which decision will the new system own that is currently unowned or poorly owned?
What artifact will become the source of truth for that decision?

If you can’t answer these, the new system will become “one more layer.”

Exit Condition for This Chapter¶

Produce a first-pass landscape matrix that includes:

The top 5–15 systems actually shaping decisions
Each system’s primary decision type
At least two collisions and one blind spot
A preliminary choice: adopt / adapt / design new