rvalessandro

Appearance

Clear Communication ​

Principles for saying what you mean without wasting anyone's time.

TL;DR ​

  • Lead with the point (BLUF) - Conclusion first, context second — always
  • Be specific - Numbers, names, dates. No weasel words
  • State your ask - Every message ends with who does what by when
  • Answer the actual question - Match the scope. Kill "it depends"
  • Ask answerable questions - Include context, constraints, and what you've tried
  • Say no clearly - "No" with a reason beats a soft maybe that drags on for weeks
  • Explain for your audience - Start with what they care about, not what you find interesting
  • Deliver bad news fast - The longer you wait, the worse it gets
  • Disagree with a counterproposal - "I disagree" without an alternative is just noise
  • Stop when you've made the point - Every word after the point dilutes the point

1. Lead With the Point (BLUF) ​

Two proven frameworks from military (BLUF — Bottom Line Up Front) and consulting (Minto Pyramid): put the conclusion first.

Structure:

  1. Conclusion first — your main point, recommendation, or ask
  2. Key points second — 2-4 supporting arguments
  3. Details last — evidence, data, context (optional for reader)

Why it works:

  • For the reader: Respects their time. They can stop after line 1 if they get it.
  • For you: Forces you to know your point before you communicate. If you can't state line 1, you don't know what you're trying to say.

Bad:

"Hey, I've been thinking about our Q4 roadmap and noticed a few things. Last quarter we shipped late on 3 features, and I think we might have a similar problem this time. I wanted to discuss if maybe we should consider adjusting our approach. Do you have time to chat?"

Good:

"We need to cut 2 features from Q4 to ship on time.

Why:

  • Current scope: 8 features, 12 weeks
  • Team capacity: 6 features (based on Q3 velocity)
  • Risk: Without cuts, we ship Jan instead of Dec 15

Can we discuss which features to cut in tomorrow's 1:1?"

Don't narrate your thinking ​

We communicate chronologically (the journey) instead of logically (the destination). We want to show our work. Nobody cares about the journey — they care about where you ended up.

How to fix: Write your entire message. Move the last paragraph to the top. Delete the journey.

Bad:

"I analyzed Q3 data. Looked at conversion rates. Compared to Q2. Noticed mobile bounce rate increased. Dug into the numbers. Found that..."

Good:

"Focus Q2 on mobile conversion. Mobile bounce rate increased 15%, costing us $50K/month."

Share information with a point ​

Raw data without a conclusion forces the reader to do your thinking.

Bad:

"I looked at the metrics. Traffic is up 20%. Conversion is down 5%. Mobile bounce rate increased."

Good:

"Recommendation: Focus Q2 on mobile conversion. Traffic is up 20% but mobile bounce rate increased 15%, costing us $50K/month."

Good message structure ​

[Conclusion/Ask in first sentence]

[2-4 key supporting points as bullets]

[Optional: Supporting data/context]

[Clear next step with deadline]

Example:

Subject: Q4 Roadmap — Need decision by Friday

We need to cut 2 features from Q4 to ship on time.

Why:

  • Current scope: 8 features, 12 weeks
  • Team capacity: 6 features (based on Q3 velocity)
  • Risk: Without cuts, we ship in Jan instead of Dec 15

Options:

  1. Cut features C and D (lowest impact, saves 4 weeks)
  2. Push deadline to Jan 15 (affects year-end goals)
  3. Add 2 contractors (cost: $80K, available in 2 weeks)

Recommendation: Option 1. Features C and D can move to Q1.

Next step: Approve by Friday 5pm so we can update sprint planning.

2. Be Specific ​

Vague language is a symptom of vague thinking. If you can't put a number on it, you don't understand it yet.

No weasel words ​

Words that sound meaningful but say nothing:

Weasel wordReplace with
"Should", "Could", "Might", "Perhaps"A decision: "Do this" or "Don't do this"
"Improve", "Enhance", "Optimize"A metric: "Reduce from 3.2s to <1s"
"Some", "Many", "Several"A number: "3 customers", "47% of users"
"Soon", "Later", "Eventually"A date: "by Friday 5pm", "March 15"
"Someone from the team"A name: "Sarah from sales"

Why we use them: They feel safer. Specifics can be wrong. Vagueness can't be challenged.

The cost: Vague language prevents action.

Bad:

"We should improve the checkout flow soon because some users are having issues and conversion could be better."

Good:

"Reduce checkout time from 45s to <20s by March 15. Increases conversion from 12% to 15% based on A/B test with 500 users."

Quantify uncertainty ​

If you're genuinely uncertain, put a number on it instead of hedging.

  • "I think it might work" → "I'm 80% confident this fixes it"
  • "It could take a while" → "2-3 weeks, depending on the API integration"
  • "We might lose some users" → "Estimated 5-10% churn based on the pricing change"

3. State Your Ask ​

If the reader doesn't know what you want, they can't help you. Every message should end with a clear next step.

Why we struggle: Asking feels aggressive. We hint instead. "Let me know your thoughts" instead of "Approve this by Friday."

The cost: Messages end without action. Reader doesn't know if they need to decide, approve, discuss, or acknowledge.

Include who, what, by when ​

Bad:

"Thought you might want to know about the database migration. Let me know your thoughts."

Good:

"Approve database migration by EOD Thursday. I need your sign-off to proceed. If you have concerns, let's discuss in Slack by Wednesday."

Don't ask permission before stating the ask ​

Bad:

"Hey, got a quick question about our strategy. Do you have 5 minutes?"

Good:

"Need your approval on vendor choice. Option A costs $10K less but ships 2 weeks later. Which do you prefer?"

The first forces two exchanges. The second is answerable in one.

4. Answer the Actual Question ​

Most people answer badly — not because they don't know, but because they bury the answer in context.

Match the scope ​

Look at the question's first word. "Can" → yes/no. "How many" → number. "When" → date. Your first word should match.

"Can we ship by Friday?"

Bad: "Well, there are a few things we need to finish first, and the QA process usually takes..."

Good: "No. QA needs 2 days and we haven't started. Monday is realistic."

"How many users signed up last week?"

Bad: "Signups have been trending upward, and we've been running some new campaigns..."

Good: "1,247. Up 15% from the week before."

Kill "it depends" ​

"It depends" sounds thoughtful. It's a stall. State your default answer, then the exceptions.

Bad:

"Should we use microservices?" "It depends on the scale, the team size, the complexity..."

Good:

"No, not yet. We have 4 engineers and 1 service. Microservices add overhead we can't afford. Revisit at 15+ engineers."

The pattern:

  1. State your answer (the most likely outcome)
  2. State the condition that changes it
  3. State when you'll know

Say what you don't know ​

Not knowing is fine. Guessing wastes time.

Bad:

"I think it's around... well, last time I checked it was somewhere in the range of... maybe $15K-ish?"

Good:

"I don't know. I'll check and reply by 2pm."

"I don't know" + when you'll have the answer. That's it.

The one-sentence test ​

Before answering: can I answer this in one sentence?

QuestionOne-sentence answer
"Should we rewrite the frontend?""No — rewrite costs 6 months we don't have. Refactor incrementally."
"Why is the API slow?""Full table scan on 2M rows — needs an index."
"Can we launch next week?""Yes, if QA finishes by Wednesday."
"Who should lead this project?""Sarah — she shipped the payments rewrite and knows the domain."

If you can't do it in one sentence, you either don't understand the question or don't know the answer.

5. Ask Answerable Questions ​

Bad questions force a back-and-forth that wastes everyone's time. Good questions contain everything the other person needs to respond.

Include what you've tried ​

Bad:

"The deploy isn't working, can someone help?"

Good:

"Deploy fails at the Docker build step with Error: EACCES permission denied. Tried clearing the cache and rebuilding. Running on Node 18, Docker 24.0. Anyone seen this?"

The first generates "what error?", "what did you try?", "what version?" The second is answerable immediately.

Narrow the scope ​

Bad:

"What do you think about our architecture?"

Good:

"Should we add a message queue between the API and the payment service? Payments take 3s and users are waiting. I'm thinking RabbitMQ but open to alternatives."

Broad questions get broad (useless) answers. Narrow questions get actionable ones.

Offer options when asking for a decision ​

Bad:

"How should we handle the migration?"

Good:

"Two options for the migration: (A) Big bang over the weekend — 4 hours downtime, done in one shot. (B) Rolling migration over 2 weeks — zero downtime, higher complexity. I recommend A — our traffic drops 90% on weekends. Which do you prefer?"

Decision-makers don't want to design the solution. They want to pick from options you've already thought through.

6. Say No Clearly ​

A vague "maybe" is worse than a clear "no." People can plan around a no. They can't plan around ambiguity.

No + reason + alternative ​

Bad:

"Hmm, that's tricky... let me think about it... I mean, we could try, but I'm not sure we have the bandwidth..."

Good:

"No, we can't add that to this sprint — we're at capacity. I can slot it into next sprint starting March 3, or we drop feature X to make room. Which do you prefer?"

Don't over-explain ​

Your reason should be one sentence. If you need 3 paragraphs to justify a no, you're either not sure it's a no, or you're afraid of the reaction.

Bad:

"So the thing is, we've been really stretched lately, and the team has been working extra hours, and I've been thinking about workload balance..."

Good:

"No. The team is at capacity through March. Here's what we can do instead: [option]."

"Not yet" is better than a fake yes ​

Bad:

"Yeah, sure, we'll get to it." (Then it never happens and trust erodes.)

Good:

"Not this quarter. We'll revisit in Q3 planning — I'll add it to the backlog with your context so it doesn't get lost."

7. Explain for Your Audience ​

The curse of knowledge: once you understand something, you forget what it's like not to understand it.

Start with what they care about ​

To an engineer:

"We need to add an index on users.email — the login query does a full table scan on 2M rows. Takes 800ms, should be <10ms."

To a PM:

"Login is slow — 800ms. Fix takes 1 hour, no user-facing changes. Can I ship it today?"

To a VP:

"Login is 8x slower than our target. Fix is ready, shipping today. No cost, no risk."

Same fact, three framings. Start with what they need to make their decision.

Use analogies for non-experts, specifics for experts ​

To a non-technical stakeholder:

"The database is like a library with no catalog. Every search means checking every book. Adding an index is like adding a catalog — you go straight to the right shelf."

To an engineer:

"Add a B-tree index on users.email. Current query plan shows Seq Scan, 800ms. Index Scan drops it to 2ms."

Don't use analogies with experts (condescending). Don't use jargon with non-experts (exclusionary).

One level of "why" ​

Explain one level deeper than the ask, not three.

"Why did the deploy fail?"

Bad: Starts with the history of Docker, container networking, Linux kernel namespaces...

Good: "The Docker registry credentials expired. Renewed them, deploy works now. Adding credential rotation to prevent recurrence."

8. Deliver Bad News Fast ​

Bad news doesn't age well. Every hour you delay, the problem gets bigger and the trust hit gets worse.

Lead with the impact, then the plan ​

Bad:

"So, funny story... remember that migration we were working on? Well, there were some unexpected complications..."

Good:

"The migration failed. Production data is safe — no data loss. We rolled back at 3am. Root cause: schema mismatch on 12 legacy columns. Fix is ready, re-running tonight with Carlos monitoring."

The structure:

  1. What happened (one sentence)
  2. What's the impact (data loss? downtime? revenue?)
  3. What you're doing about it (actions, owners, timeline)

Don't soften, don't blame ​

Bad:

"Unfortunately, due to circumstances beyond our control and some challenges with third-party integrations, we've experienced a slight delay..."

Good:

"We'll miss the March 1 deadline by 2 weeks. The Stripe integration took longer than estimated — my estimate was wrong. New date: March 15. No scope change needed."

Own it. State the new plan. Move on.

Bad news + no plan = panic. Bad news + plan = trust. ​

Never deliver bad news without a next step.

9. Disagree With a Counterproposal ​

Saying "I disagree" without an alternative contributes nothing. You've blocked progress without moving it forward.

Disagree + reason + alternative ​

Bad:

"I don't think that's a good idea."

Good:

"I wouldn't use Redis for this. Our data is relational and we need ACID transactions. Postgres with connection pooling handles our load and we already run it."

"Yes, and" or "No, but" ​

Bad:

"That won't work."

Good (no, but):

"Caching won't fix this — the bottleneck is the write path, not reads. But we can batch the writes: instead of 1,000 individual inserts, one bulk insert. Cuts write time from 30s to 2s."

Good (yes, and):

"Agreed on adding monitoring. And we should add alerting too — monitoring without alerts means nobody sees the dashboard until it's too late. PagerDuty threshold at >500ms p99."

Disagree on facts, not preferences ​

Bad:

"I just don't like microservices."

Good:

"Microservices add 3 months to the timeline and require infra we don't have (service mesh, distributed tracing, separate CI pipelines). With 4 engineers, the coordination cost outweighs the benefit. Monolith until we hit 15+ engineers."

If your disagreement is a preference, say so: "Personal preference, but..." That lets the team weigh it appropriately.

10. Stop When You've Made the Point ​

The biggest communication mistake isn't saying too little. It's not knowing when to stop.

Say it once ​

Bad:

"We should use Postgres. It's reliable, it handles our use case, and it's what the team knows. Really, I think Postgres is the best choice here. The reason I say that is because it's been proven in production environments similar to ours..."

Good:

"Use Postgres. Team knows it, handles our queries, and we already run it in production."

You made the point. Stop. If they have questions, they'll ask.

Don't preemptively answer objections nobody raised ​

Bad:

"We should use Postgres. And before you say 'what about MongoDB' — Mongo doesn't support joins. And I know some people like DynamoDB but..."

Good:

"Use Postgres." → [wait for actual objections] → address those.

Preemptive objection-handling makes you sound defensive and buries your point.

Silence is fine ​

You answered. Nobody is responding. That's okay. Resist the urge to keep talking to fill the gap. The pause after you speak is where the other person thinks. Let them.

Anti-Patterns Quick Reference ​

Anti-patternWhat it sounds likeFix
The Rambler2 minutes of backstory before the pointLead with your last sentence
The Hedger"I think maybe we could potentially consider..."Drop hedge words. Say it flat
The PoliticianLots of words, zero commitmentName an action, owner, and date
The RedirectorAnswers a different questionRepeat the question before answering
The Disclaimer Machine3 caveats before the answerAnswer first, caveats only if material
The RepeaterSame point 3 times, 3 waysSay it once. Trust that people heard you
The Soft No"Maybe", "let me think about it", then silenceSay no with a reason and an alternative
The Hinter"Let me know your thoughts"State your ask: who, what, by when
The Permission Seeker"Do you have 5 minutes?"State the ask with context — skip the preamble

Checklist ​

Before communicating, check:

  • [ ] Point is in sentence one — not buried in paragraph 3
  • [ ] No weasel words — numbers, names, dates instead
  • [ ] Ask is explicit — who does what by when
  • [ ] Scope matches — yes/no → yes/no, number → number, date → date
  • [ ] No visible thinking — destination, not the journey
  • [ ] Unknowns are explicit — "I don't know, will confirm by [time]"
  • [ ] Audience-appropriate — right level of detail for the reader

References ​