Consulting and Executive Communication
Executive view
Demand an explicit ask, visible trade-offs and labelled uncertainty—not confidence theatre.
Decision required: What must you approve, defer or stop—and by when?
Technical view
Put architecture and model detail in the appendix; front page holds the decision narrative.
Name next steps and owners; label assumptions that still need validation.
Communicate in decision structure
Senior stakeholders need:
- What is happening?
- Why does it matter?
- What are the options?
- What do you recommend?
- What decision is required?
- What happens next?
Executive update structure
Situation
Describe the current context.
Complication
Explain the problem, constraint or risk.
Recommendation
State the proposed action.
Impact
Explain value, cost, risk and timing.
Decision required
Make the ask explicit.
Example
Situation: Customer-service demand has increased while response times have deteriorated.
Complication: Agents spend significant time searching across fragmented knowledge sources, producing inconsistent responses.
Recommendation: Implement a retrieval-augmented AI assistant integrated with the existing service platform.
Impact: The proposed solution should reduce search time, improve consistency and provide auditable sources.
Decision required: Approve a six-week discovery and prototype phase.
Solution narrative
A strong solution narrative should cover:
- Business problem
- Current-state limitation
- Target outcome
- Proposed capability
- Architecture
- Security and governance
- Delivery approach
- Commercial model
- Expected value
- Decision required
Communicating trade-offs
Do not hide uncertainty. Use language such as:
- The main trade-off is…
- The preferred option is…
- This assumption requires validation…
- The risk can be reduced by…
- The decision is reversible if…
- The downside scenario is…
Case study: financial-services assistant
Executive ask is not “approve generative AI.” It is “approve a six-week discovery and prototype with defined evaluation gates, DPIA start, and a go/modify/stop decision.” Architecture and model details stay in the appendix until the decision is framed.
Common failure modes
- Technology tours instead of decisions
- Hiding uncertainty to sound confident
- No explicit ask
- Mixing status updates with recommendations
- Overloading slides with architecture before the problem
Solution Engineer checklist
Solution Engineer checklist
- Update follows situation → complication → recommendation → impact → ask
- Options and trade-offs visible
- Uncertainty labelled
- Next steps and owners named
- Appendix holds depth; front page holds the decision
Practical exercise
Rewrite your last status email as a half-page SCRID memo. Delete every sentence that does not help the decision.
Discussion
Comments
Share feedback or questions about this page. No account required.
Loading comments…