Personal Dev Communication¶
14 cards — 🟢 6 easy | 🟡 6 medium | 🔴 2 hard
🟢 Easy (6)¶
1. What three elements must appear in every professional ask (request message)?
Show answer
(1) Action — what you need the reader to do (e.g., "Approve the RFC"), (2) Context — the minimum background needed to act (e.g., "covers the Postgres upgrade"), (3) Constraint — deadline, scope, or decision boundary (e.g., "need sign-off by Thursday EOD for the maintenance window"). Missing any one causes the reader to ignore the request or guess wrong.2. How is a status update different from an ask, and how should you label message types?
Show answer
A status update is one-way information requiring no action ("Migration dry-run completed, on track"). An ask requires a specific action from the reader ("Need DBA review by Wednesday noon, PR #482"). An FYI is awareness-only with no action needed. Label message type explicitly when ambiguous — "FYI — no action needed" at the top saves the reader from excavating your intent.3. What is the most reliable editing trick for compressing a professional message?
Show answer
Delete the first sentence — it is almost always throat-clearing ("I just wanted to touch base regarding..."). Then move the action or ask to line 1. Cut any sentence that does not serve the message's job. Most professional messages are 40-60% longer than necessary due to hedge stacking, redundant context, and pre-emptive defense of objections nobody has raised.4. What should an incident update contain, and what is the recommended format?
Show answer
Every incident update should include: timestamp, STATUS (investigating/mitigating/resolved), IMPACT (who and how much is affected), CAUSE (hypothesis or confirmed), ACTION (what you are doing now), and NEXT UPDATE (when or what triggers the next one). Update every 5-10 minutes even if nothing changed — silence for 20 minutes is itself bad communication during an incident.5. What is the boundary template for saying no to a work request without being adversarial?
Show answer
I can't take on [X] this sprint because [current commitment]. I could do it [alternative timeline], or [suggest who else could help]. Want me to flag this to [manager] for prioritization? This acknowledges the request, explains the constraint (not a character judgment), and offers alternatives. It communicates capacity limits without implying the request is unreasonable.6. How should you write email subject lines and why do most engineers write them poorly?
Show answer
Effective subject lines contain the message type and key information: "[Action Required] Review PR #482 by Thursday" or "[FYI] Postgres upgrade scheduled March 15." Most engineers write vague subjects ("Quick question," "Update," "Help") that get deprioritized or lost. The subject line is a search index — make it specific enough to find six months later. Include the project name, action verb, and deadline if applicable.🟡 Medium (6)¶
1. When should a chat thread be escalated to a call, and when does a call require a doc first?
Show answer
Escalate chat to a call when back-and-forth exceeds three rounds — sync resolves ambiguity faster than thread tennis. A call requires a doc first when it would exceed 15 minutes — without a pre-read, the first half of the meeting is information transfer that could have been async. Rule: "Could this be an email or doc?" before scheduling any meeting.2. What is the four-step structure for disagreeing productively without triggering defensiveness?
Show answer
(1) Acknowledge the concern: "I understand the concern about deployment speed." (2) State your position: "I think we should keep the canary stage." (3) Give evidence: "Last quarter, canary caught two bad deploys before they hit prod." (4) Propose an alternative: "Can we shorten the canary window to 10 minutes instead of removing it?" Avoid "well, actually", silence followed by non-compliance, and making it personal.3. How should the same incident update be framed differently for your team vs. your manager vs. a customer?
Show answer
To your team: technical details and root cause ("primary DB connection pool exhausted, pgbouncer max_client_conn hit, increasing to 200"). To your manager: status, risk, and timeline ("Payment API had partial outage for 12 minutes, root cause identified, permanent fix in sprint"). To a customer: impact, resolution, and what they should do ("some transactions experienced delays between 2:20-2:32 PM UTC, issue resolved, all transactions processed").4. What is the rule of three for technical presentations and why does it improve audience retention?
Show answer
Structure presentations around exactly three main points. The human brain naturally organizes information in threes (beginning-middle-end, past-present-future). More than three main points overwhelms working memory. Structure: open with the problem (30 seconds), present three key points with evidence and transitions, close with a call to action. Each point follows: claim, evidence, implication. Rehearse to stay under time — going over signals poor preparation and disrespect for the audience's time.5. How should you receive critical feedback constructively even when it feels unfair?
Show answer
Protocol: 1) Listen without interrupting or defending. 2) Ask clarifying questions ("Can you give me a specific example?"). 3) Separate the signal from the delivery — poorly delivered feedback can still contain valid observations. 4) Thank them for the feedback (this is hard but important). 5) Reflect privately before deciding what to act on. 6) Follow up later with what you changed. The trap: rehearsing your rebuttal while they are talking, which means you hear nothing. Even if 80% of the feedback is wrong, the 20% that is right is valuable.6. What are the three most common mistakes in technical writing and how do you fix them?
Show answer
(1) Burying the lead — putting the conclusion at the end instead of the beginning. Fix: state the recommendation in the first paragraph. (2) Assuming shared context — using acronyms or internal terms without defining them. Fix: write for the person who joined the team last month. (3) Passive voice hiding responsibility — "mistakes were made" vs. "we misconfigured the load balancer." Fix: use active voice and name the actor. Bonus mistake: writing for yourself instead of the reader. Always ask "what does the reader need from this document?"🔴 Hard (2)¶
1. What is the inverted pyramid structure for technical documents, and why does it matter?
Show answer
Put the conclusion first (recommendation or decision in the first paragraph). Most readers will not read the full document — if the key finding is buried in section 4, most stakeholders never see it. Structure: (1) Summary/Recommendation, (2) Context, (3) Options considered with tradeoffs, (4) Proposed approach with rationale, (5) Risks and mitigations, (6) Next steps and timeline, (7) Appendix for details.2. How should you structure an RFC (Request for Comments) to drive a decision rather than endless discussion?