Presenting to Executives
Decision first, cost, risk, and what happens if we do nothing.
5 to work through
-
intermediate
A payments platform has had a significant outage. An architect must brief the executive team. What should the brief contain, and what is the most common mistake?
2 min answer -
intermediate
How should an architect present a technical risk or an investment case to executives so that it competes successfully for funding?
2 min answer -
advanced
An architect must explain to executives why a two-year platform investment is needed. What should the communication contain, and what must be excluded?
2 min answer -
advanced
Two hours into a major outage an executive asks for a restoration time. The team's honest position is "probably three hours, unless the data is inconsistent, in which case a day." What happens if you give the three-hour number, and what should you say instead?
2 min answer -
advanced
You must get approval for a costly architectural change from a board that includes the CFO, the CISO and two engineering leads who disagree with your approach. How do you prepare?
3 min answer
3 terms in this topic
Executive Communication
Presenting technical matters to an audience that owns outcomes and money, in a form that supports a decision within their attention span.
practiceExecutive Summary Discipline
Leading with the recommendation and its business consequence, compressed to what an executive audience can act on in a few minutes.
practiceUpdate Cadence Commitment
Promising when the next update will arrive rather than when the problem will be fixed, so the one commitment made during an incident is one the team …
Neighbouring topics
Architecture Communication
General material on communicating architecture.
Architecture Diagrams
Choosing an audience and refusing to mix levels of abstraction.
C4 Model
Context, container, component and code as four separate diagrams.
Context Diagrams
The system as one box, with its users and external systems.
Sequence Diagrams
Ordered message exchange, and walking the failure of each arrow.
Data-Flow Diagrams
Following the data across trust boundaries rather than the calls.
Deployment Diagrams
What runs where, in which zone, behind which boundary.
Communicating Threat Models
Making risk legible to people who will fund or accept it.
Writing Decision Records
Context, alternatives and consequences, written once and never edited.
Technical Proposals
A written argument circulated before the decision feels made.
Architecture Reviews
Reviewing early enough to influence rather than to veto.
Presenting to Engineers
Mechanism, alternatives rejected, and what you are unsure about.
Explaining Trade-offs
Naming what was given up, and the condition that would change it.
Handling Disagreement
Arguing from consequences, and escalating in the room.
Negotiation
Trading on interests rather than positions, with priced options.
Documentation Practice
Keeping documents close to the code and honest about staleness.
Presentation Skills
Structure, pacing and the slide that carries the decision.
Written Communication
Writing that survives being read without you in the room.
Facilitation
Running a design session that reaches a decision.