Appendix A - The Two Maps: A Working Diagnostic Tool

The output map and the execution map are not theoretical constructs. They are practical instruments — and the gap between them, when made visible, is one of the most useful diagnostics available to a CTO.

What follows is a structured illustration of both maps, built from the fintech transaction processing example in Chapter 2. They are presented not as a template to be copied, but as a pattern to be adapted. The categories, the level of granularity, and the ownership model will vary by organization. What should not vary is the discipline of maintaining both maps — and the practice of examining the distance between them.

MAP 1 — THE OUTPUT MAP

The output map answers a single question: what does the organization deliver?

It is organized by output domain — the discrete areas of value the technology organization is responsible for producing. Each domain has a named owner, a description of what it produces, and the primary measure of whether it is performing.

OUTPUT DOMAIN	WHAT IT DELIVERS	OWNER	PRIMARY MEASURE
Transaction Processing	Fast, reliable processing of customer transactions	VP Engineering, Core Platform	Processing latency, success rate
Fraud Detection	Real-time identification and blocking of fraudulent transactions	Head of Risk Engineering	False positive rate, detection rate
Compliance	Automated regulatory checks on all transactions	Head of Engineering, Compliance Systems	Pass rate, audit findings
Customer API	External-facing API layer for product integrations	Engineering Manager, API Platform	Uptime, error rate, latency
Risk Scoring	Real-time risk signals informing transaction approval	Head of Data Engineering	Signal accuracy, coverage
Monitoring & Alerting	Operational visibility across all systems	Platform Engineering Lead	Mean time to detect, alert fidelity

This map is familiar. Most CTOs have a version of it — in a roadmap, an OKR framework, or a team charter structure. It is the surface the business sees and evaluates.

MAP 2 — THE EXECUTION MAP

The execution map answers a different question: what actually runs in order to produce those outputs?

It is organized by the same output domains, but maps every executor in the chain — human, system, automated, and AI. For each executor, it identifies the execution type, the current owner, and the governance status.

The purpose of this map is not completeness on day one. It is visibility. Most organizations will discover unowned execution before they can fully document it.

Governance status has three values: Governed — actively owned, monitored, and included in operational cadences. Partially governed — owned in principle, but monitoring or review cadences are incomplete. Ungoverned — no active owner, no monitoring, or owner no longer exists.

EXECUTOR	EXECUTION TYPE	OWNER	GOVERNANCE STATUS
Transaction Processing
Core processing engineers	Human	VP Engineering, Core Platform	Governed
CI/CD pipeline	Automation	Platform Engineering Lead	Governed
Automated test suite (4,200 tests)	Automation	Engineering Manager, Core Platform	Governed
Banking partner integration layer	System	Engineering Manager, Integrations	Partially governed
Deployment infrastructure (cloud)	System	Platform Engineering Lead	Governed
Fraud Detection
Fraud rules engine	Automation	Head of Risk Engineering	Governed
ML fraud detection model (v2.3)	AI Agent	Unassigned	Ungoverned
Model retraining pipeline	Automation	Unassigned	Ungoverned
Human review queue (edge cases)	Human	Fraud Operations Lead	Governed
Compliance
Automated compliance checks	Automation	Previous team — reorganized	Ungoverned
Ruleset (last updated 14 months ago)	System	Unassigned	Ungoverned
External regulatory feed (vendor)	System	Head of Engineering, Compliance	Partially governed
Customer API
API engineering team	Human	Engineering Manager, API Platform	Governed
Rate limiting automation	Automation	Platform Engineering Lead	Governed
API gateway (third-party)	System	Engineering Manager, API Platform	Governed

HOW TO USE THESE MAPS

1. Build the output map. Usually straightforward — most organizations have the inputs already, distributed across roadmaps, team charters, and OKR structures. The work is consolidation and normalization, not discovery.

2. Build the execution map. This is harder, and deliberately so. It requires asking every team lead to account not just for their human work, but for every system, automation, and AI agent that executes within their domain. In most organizations, this exercise surfaces ungoverned executors that nobody had formally acknowledged.

3. Compare the two maps and name every governance gap. Not to fix everything immediately — but to make the gaps visible, assign interim ownership, and include the ungoverned execution surface in the CTO's operational cadences.

The maps are not a one-time exercise. They are a living instrument. The execution surface changes continuously — through new tooling, new automation, new AI adoption, new vendor relationships. The maps need to be maintained with the same discipline as the output surface they support.

A CTO who maintains both maps is governing the organization they actually have. A CTO who maintains only the output map is governing a simplified version of it.