Communicating with non-technical stakeholders

The translation problem

Infrastructure work has technical depth that non-technical stakeholders don’t (and shouldn’t) have. Your job in communication is to translate — to surface what matters for their decisions without dragging them through what doesn’t.

This lesson covers the common communication patterns: status updates, capacity reports, scope pushback, and incident comms.

Know your audience

Every audience has different needs:

Executives (CFO, CEO, board)

• Cares about: cost, risk, business outcomes
• Doesn’t care about: technology choices, implementation details
• Format: 1-page summaries, slide decks, decisions framed as yes/no

Product managers

• Cares about: features delivered, timelines, blockers
• Doesn’t care about: which database, which hypervisor
• Format: weekly status, sprint reviews, roadmap docs

Customers (internal or external)

• Cares about: is the service working, when will it be back
• Doesn’t care about: root cause, post-mortem details
• Format: status pages, short email updates

Peers (other engineers)

• Cares about: technical correctness, design trade-offs
• Doesn’t care about: business justification (assume it’s good)
• Format: design docs, Slack threads, code reviews

Same project, four different communication styles.

Status updates

A good status update is short, structured, and actionable.

Format

**Status**: green / yellow / red
**This week**:
- Shipped: PBS offsite sync
- In progress: 3-node cluster build
**Next week**:
- Complete cluster build
- Begin Ceph pilot
**Blockers**:
- None / [specific ask]

Three sections: status (single word), what happened, what’s next. Optional blockers section.

What “green/yellow/red” means

• Green: on track, no concerns
• Yellow: some risk, needs awareness
• Red: off track, needs intervention

Avoid:

• Status updates without “what’s next” (no forward motion)
• Status updates without “blockers” (problems hidden)
• Status updates longer than 200 words (readers tune out)

Capacity reports

A capacity report says: “Here’s where we are, here’s where we’re going, here’s what we need to do about it”.

Sections:

1. Current state: utilisation today (CPU, RAM, storage, network)
2. Forecast: 3-6 months projection based on current growth
3. Risks: where the forecast crosses thresholds
4. Recommendations: what to do (add capacity, optimise, etc.)

Example table:

Recommendation: “Procure 200 TB additional storage by end of Q3; defer CPU expansion until Q4 unless VM count exceeds forecast.”

For non-technical readers, replace technical terms with business impact:

• “Storage at 85%” → “Backup capacity will be exhausted by mid-Q4, risking our 7-day retention SLA”
• “RAM at 70%” → “Workload growth will exceed capacity by year-end”

Pushing back on scope

When stakeholders ask for things you can’t or shouldn’t do:

1. Acknowledge the goal: “I understand you need X by date Y”
2. State the constraint: “The current capacity is Z, which won’t support X without…”
3. Offer alternatives: “We can either reduce scope, add capacity, or push the date”
4. Recommend a choice: “I’d recommend option A because…”

This pattern works because it’s:

• Collaborative, not adversarial
• Data-driven, not opinion-driven
• Decision-ready, not just problem-reporting

Specific phrases that work

• “To do that, we’d need to [cost/timeline/capacity]. Is that within scope?”
• “I can deliver that in [timeframe] if we cut [scope]. Want me to?”
• “Here’s what would have to slip: [list]. Which would you prefer?”
• “I think this approach has [risk]. Here’s a safer alternative: [B].”

Incident communications

Three audiences during incidents:

Internal team (Slack channel)

• Technical detail, hypotheses, runbook links
• Already covered in another lesson

Stakeholders (executives, PMs)

• Business impact (which customers, which services)
• ETA to resolution
• Confidence level
• “We are aware of issue X affecting Y customers. ETA to fix: 2 hours. Confidence: medium.”

Customers (status page)

• Plain language, no internal jargon
• What they should do (or not do)
• “We are investigating an issue affecting file uploads. Some users may experience delays. We will update at HH:MM.”

Common communication pitfalls

“Burying the lede”

The most important fact is in paragraph 4. Executives don’t read paragraph 4. Lead with the conclusion:

❌ “We evaluated three options for the backup storage upgrade, considering factors including cost, reliability, and operational complexity. After analysis, we recommend option B…”

✅ “We recommend option B for backup storage. It costs $X, takes Y weeks, and reduces risk of Z. Options A and C are [summary].”

“Hedging”

“We might be able to possibly perhaps consider” sounds weak. Be specific and confident:

❌ “It might be possible to look at adding capacity if needed”

✅ “We can add capacity in 4 weeks for $10K”

“No news is good news”

Silence during incidents or project delays erodes trust. If you have no new information, post a status update saying so. The update itself is the message.

“Jargon”

“Fibre channel replication RPO is 4 hours with async journal” means nothing to a CFO. “Backup data is 4 hours old in the worst case” is clear.

“Apologising for technical reality”

Saying “sorry, our infra doesn’t support that” sounds weak. Reframe: “To support that, we need X. Here’s what that costs.”

Building a communication muscle

Practice:

• Write status updates weekly, even when no one asks
• Volunteer to present at all-hands or team meetings
• Translate one technical concept per week into a non-technical explanation
• Ask for feedback on your written updates

The best communicators are made, not born. It’s a skill like any other.

Key takeaways

• Match your communication to the audience; engineers ≠ executives ≠ customers
• Status updates: short, structured, action-oriented
• Capacity reports: current state, forecast, risks, recommendations
• Pushing back on scope: acknowledge, state constraint, offer alternatives, recommend
• Lead with the conclusion; bury nothing

Knowledge check