Communication Trade-offs
Every presentation and communication decision at the CTA review board involves trade-offs. The board does not expect perfection — they expect you to make deliberate choices and articulate why. This page covers the major communication trade-offs.
The meta-trade-off
Communication is itself a trade-off domain: time spent on communication artifacts is time not spent on technical design. The best candidates find the right balance and can explain their allocation.
1. Depth vs Breadth in Presentation
The most fundamental presentation trade-off. You have 45 minutes to cover a solution that touches all 7 CTA domains.
| Dimension | Go Deep (2-3 domains) | Go Broad (all 7 domains) |
|---|---|---|
| Impression | Expert in key areas | Comprehensive thinker |
| Risk | Judges see gaps in uncovered domains | Judges see shallow understanding |
| Scoring impact | Strong scores in covered domains, weak in others | Moderate scores across all domains |
| Q&A exposure | Judges will probe uncovered domains hard | Judges may not need to probe basics |
| Time per domain | 12-15 min on deep domains | ~6 min per domain |
| Diagram quality | Detailed diagrams for focus areas | Simpler diagrams, more coverage |
When Each Side Wins
flowchart TD
SC["Analyze scenario"] --> EM{How many domains\ndoes scenario emphasize?}
EM -->|"2-3 clearly\ndominant"| DEEP["Go deep on those\n(10-15 min each)\n+ sweep others"]
EM -->|"Balanced across\nall domains"| BROAD["Go broad\n(~6 min each)\neven coverage"]
EM -->|"Unsure / mixed"| BAL["Balanced approach:\nLead strongest (8-10 min)\nDominant (5-7 min each)\nSweep rest (1-2 min each)"]
DEEP --> SWEEP["Always do 7-domain\nsweep in conclusion"]
BROAD --> SWEEP
BAL --> SWEEP
Go deep when: The scenario clearly emphasizes 2-3 domains (e.g., a heavy integration scenario), and you can briefly touch the others in your conclusion sweep.
Go broad when: The scenario is balanced across domains, or you are less confident in one area and want to show competence everywhere rather than risk zero in a domain.
The balanced approach: Lead with your strongest domain (8-10 min), cover the scenario’s dominant domains (5-7 min each), then do a rapid sweep of remaining domains (1-2 min each) in your conclusion. This gives depth where it matters most and coverage everywhere.
2. Technical vs Business Language
| Dimension | Technical Language | Business Language |
|---|---|---|
| Audience match | Judges are CTAs (technical) | Judges evaluate business justification |
| Credibility | Shows technical depth | Shows business acumen |
| Accessibility | Risk of jargon overload | Risk of appearing too high-level |
| Time efficiency | Technical terms are precise | Business context adds explanation time |
| CTA expectation | Expected for implementation detail | Expected for design justification |
When Each Side Wins
Technical language wins when: Describing implementation specifics — API names, governor limits, pattern names, configuration details. Judges expect technical precision here.
Business language wins when: Justifying architectural decisions — “This approach reduces time-to-market by 40%” is stronger than “This approach uses declarative configuration.”
Best practice: Start each section with a business justification, then dive into technical details. “The business needs real-time order visibility across all channels [business]. I achieve this with a Pub/Sub API integration from the OMS, using Platform Events for internal notification and CDC for external subscribers [technical].“
3. Scripted vs Conversational Delivery
| Dimension | Scripted Delivery | Conversational Delivery |
|---|---|---|
| Consistency | Same every time, reliable | Varies by energy and context |
| Naturalness | Can sound robotic, rehearsed | Sounds authentic, engaging |
| Recovery | Hard to recover if you lose your place | Easy to adapt and recover |
| Time control | Predictable timing | Risk of running long or short |
| Q&A transition | Jarring shift from script to extemporaneous | Smooth transition, same register |
| Preparation effort | High — must memorize or read | Medium — must know the content deeply |
When Each Side Wins
Scripted wins when: You have limited presentation experience, you need precise timing, or you want to ensure you cover all required points.
Conversational wins when: You know the material deeply, you present well extemporaneously, or the presentation platform makes it easy to use notes as prompts rather than scripts.
Recommended approach: Prepare a semi-structured delivery — bullet-point notes for each section with key phrases and transition sentences scripted, but the bulk of the content delivered conversationally. This gives you the safety net of structure with the authenticity of conversation.
Memorization trap
Do not memorize your presentation word-for-word. If a judge interrupts with a question mid-presentation (which happens), a memorized script falls apart. A deeply understood solution can handle any interruption gracefully.
4. Detailed Diagrams vs Readable Diagrams
| Dimension | Detailed Diagrams | Readable Diagrams |
|---|---|---|
| Information density | Shows comprehensive understanding | Shows clear architectural thinking |
| Readability | Hard to read on screen, small text | Easy to parse at a glance |
| Creation time | More time to build | Faster to create |
| Presentation value | Requires walking through every element | Self-explanatory as visual aids |
| Q&A reference | Judges can point to specific details | Judges focus on high-level patterns |
| Professional impression | Can look cluttered | Looks polished and intentional |
When Each Side Wins
Detailed diagrams win when: The specific topic demands precision (e.g., a complex data migration sequence diagram showing all error paths, or a data model ERD for the core business objects).
Readable diagrams win when: The topic is a high-level overview (system landscape, integration topology) or when the diagram supports a verbal explanation rather than standing alone.
The layered approach: Create readable high-level diagrams for your presentation, with a second level of detail available in notes if judges ask to zoom in. This gives you the best of both: clean visuals for presentation and detail for Q&A.
Readability Rules
| Rule | Threshold |
|---|---|
| Maximum boxes per diagram | 10-12 |
| Minimum font size | Readable when shared screen is not fullscreen |
| Arrow labels | Every arrow must have a label |
| Color usage | Maximum 4-5 colors with a legend |
| Whitespace | At least 30% of the diagram should be empty space |
5. Covering All Domains vs Going Deep on Some
| Dimension | Cover All 7 Equally | Deep on Scenario-Critical Domains |
|---|---|---|
| Scoring safety | No zero in any domain | Risk of zero in neglected domains |
| Demonstration of expertise | Jack of all trades impression | Master of the critical areas |
| Time allocation | ~6 min per domain (tight) | 10-15 min on key domains |
| Judge impression | Comprehensive but potentially shallow | Focused but potentially incomplete |
| Q&A preparation | Spread thin across all domains | Deep knowledge where it matters most |
When Each Side Wins
Cover all 7 when: The scenario does not clearly emphasize any subset, you are equally comfortable across all domains, or you want to minimize risk of any single-domain failure.
Go deep when: The scenario clearly signals 2-3 critical domains (heavy integration, complex data migration, regulated industry), and you can touch remaining domains in your conclusion.
The safe strategy: Always cover all 7 domains at minimum surface level. Use the “7-domain sweep” in your conclusion to guarantee every domain gets at least a mention. Then allocate deeper time to the domains the scenario emphasizes most.
Common Mistakes by Trade-off
| Trade-off | Common Mistake | Better Approach |
|---|---|---|
| Depth vs breadth | Spending 20 min on integration and skipping security entirely | Cover all 7, allocate by scenario emphasis |
| Technical vs business | Opening with “I used REST API with OAuth 2.0 JWT bearer flow” | Opening with “The business needs real-time order visibility” |
| Scripted vs conversational | Memorizing a 45-minute script | Bullet-point notes with key transitions scripted |
| Detailed vs readable | 30+ boxes on one diagram with 8pt font | 10-12 boxes, readable at screen-share resolution |
| All domains vs deep | Equal time on all 7 when scenario clearly emphasizes 2-3 | Lead with scenario-critical domains, sweep the rest |
Communication Trade-off Analysis Template
| Step | Question | Application |
|---|---|---|
| 1 | What is the presentation goal? | ”Demonstrate I can architect a complete solution” |
| 2 | What does the scenario emphasize? | ”Integration and data migration are the core challenges” |
| 3 | Where should I spend depth? | ”Integration (D5) and data (D3) — 60% of presentation time” |
| 4 | What do I sacrifice? | ”Less time on governance (D6) and system architecture (D1)“ |
| 5 | How do I mitigate? | ”Brief mentions in conclusion sweep + prepared Q&A notes” |
| 6 | What is my presentation structure? | ”Business context, then deep on D5 + D3, then sweep remaining 5 domains” |
Practice exercise
Take any mock scenario and apply this template. Time yourself making these 6 decisions in under 10 minutes. At the board, you will need to make these choices during the first 20 minutes of your 180-minute prep phase. Speed comes from practice.
Cross-Domain Connections
- Communication Best Practices — tactical guidance for delivery, diagrams, Q&A, and anti-patterns
- Communication Decision Guides — flowcharts for time allocation, diagram priority, Q&A response
- Domains & Scoring — understanding the scoring rubric drives how you allocate presentation time
- System Architecture Trade-offs — the same trade-off thinking applied to technical decisions
Sources
- CTA coaches (Andrew Hart, Mike Gill, Apex Hours panel)
- Ladies Be Architects community guidance
- FlowRepublic CTA coaching framework
- Successful CTA candidates’ retrospectives (2024-2026)
- Nancy Duarte, “Slide:ology” and “Resonate” (presentation design)
- Garr Reynolds, “Presentation Zen” (visual communication principles)