Case Study 1 — The Rambling Request, Rewritten to Get a Yes

A note on the example. The emails below are a composite—fictional but realistic, assembled from the patterns that fill real inboxes. No real person, company, or message is depicted. We're illustrating a structural transformation, not transcribing a record.

The situation

Maya is a junior analyst. She needs the platform engineering team to grant her read access to a production database so she can pull metrics for a report her director wants by the end of next week. She doesn't know the platform team well; they're notoriously busy and protective of production access, and they get a dozen requests a day. Maya has one shot to make this easy to say yes to. Here is the email she actually sent—and then the one she should have.

This is the chapter's anchor case (a rambling request rewritten to get a yes), and it turns on the central themes: audience is everything (the platform team is a busy, cautious reader who needs to assess and grant a request fast) and structure serves the reader (the ask, the scope, and the deadline have to be unmissable).

The "before": a request that's easy to defer

❌ Before (rambling, buried ask, no scope, no deadline):

Subject: access?

Hi platform team,

I hope this email finds you all well and that things aren't too crazy on your end! I know you all are super busy keeping everything running so I really appreciate you taking the time to read this. So, I've been working on a project for my director — it's basically a deep-dive into our user engagement metrics, looking at how usage has changed over the last couple of quarters and whether there are any patterns we should be worried about, which has been really interesting actually. The thing is, to do the analysis properly, I think I'm going to need to get at some of the data that lives in the production systems, because the stuff in the analytics warehouse doesn't have everything I need and some of it seems a bit stale. I'm not totally sure exactly which database has what I'm looking for, but I'm guessing someone on your team would know. Anyway, I was wondering if it might be possible to maybe get some kind of access so I can take a look around and find what I need? I know production access is a sensitive thing so I completely understand if there are hoops to jump through. Whenever you get a chance to think about it would be great. Thanks so much in advance, you're all the best!

Read it as the platform team's on-call engineer reads it, between two incidents. What is Maya actually asking for? Some kind of access to some database (she's not sure which) so she can look around and find what she needs. That is the worst possible request to receive about production: it's unbounded ("look around"), unscoped (which data? which database? read or write?), undated (no deadline, so it sinks), and wrapped in so much apology and pleasantry that the actual ask is three lines deep. A cautious engineer can't grant "look around production"—it's a security non-starter—and they don't have time to play twenty questions to figure out what she really needs. So the path of least resistance is to defer it, or to fire back "what exactly do you need?", which costs Maya days. The email failed not because Maya is unreasonable, but because she wrote down her situation instead of her request.

Against the chapter's anatomy, the failures are exact: - Subject line ("access?") — wins no triage; tells the reader nothing about scope or urgency. (§19.3) - No purpose-first opening — the ask is buried under two sentences of pleasantry and a paragraph of project background. (§19.4) - The ask is vague and unbounded — "some kind of access… to look around" is impossible to grant safely. (§19.4) - No scope — which data, which system, read-only, for how long: all missing. The reader has to supply them. - No deadline — nothing to place it on a timeline; it loses to every request that has one. (§19.3) - Apology as friction — "completely understand if there are hoops" and "whenever you get a chance" actively lower the urgency.

The "after": a request engineered for a fast yes

Before she resent it, Maya did the one thing that fixes most bad requests: she figured out exactly what she needed. She talked to a teammate, identified the specific table, confirmed read-only would do, and bounded the time window. Then she wrote this:

✅ After (specific, scoped, deadlined, frictionless):

Subject: Request: read-only access to user_events (prod) for a director report — need by Tue 6/17

Hi platform team,

Could I get read-only access to the user_events table in the production analytics database? I need it to pull engagement metrics for a report my director, Renée Okafor, has asked for, due next Friday — so I'm hoping to have access by Tuesday 6/17.

Scope, to keep this easy to approve: - What: read-only (SELECT) on the user_events table only — no writes, no other tables. - Why this table: the warehouse copy is missing the session_id and event_ts fields I need, which I'm told live here. - Duration: I only need it through end of month; happy to have access revoked after, or time-boxed from the start if that's cleaner.

If there's a standard request process (a ticket, an approval form, a manager sign-off), point me to it and I'll follow it — just let me know what you need from me. And if read-only-to-one-table is still more than you'd grant, I'd take a one-time export of those two fields instead.

Thanks! Maya

Why it's better, point by point:

• The subject line carries the whole request. Read-only, the specific table, the purpose, and the deadline — an engineer can assess the risk from the subject alone and know it's small. (§19.3)
• The ask is the first sentence, and it's specific and bounded: read-only, one named table. That's a request a cautious engineer can actually grant, because Maya bounded the risk for them. (§19.4)
• The scope section pre-answers every question the engineer would have asked — what, why this table, how long — so there's no back-and-forth round-trip eating days. She did the team's risk assessment for them.
• It names a real deadline with a reason (report due Friday → access by Tuesday), so it lands on a timeline instead of in the "later" pile. (§19.3)
• It removes friction in three ways: it offers to follow the standard process, it time-boxes the access proactively (the cautious engineer's exact worry, defused), and it offers an even-lower-risk fallback (a one-time export) so the answer can be a small yes even if full access is a no. (§19.4)
• The apology is gone, replaced by cooperation ("point me to it and I'll follow it"). That reads as competence and respect for their process, not as guilt — and competence gets a faster yes than guilt does.

Notice that the "after" is barely longer than the "before," and arguably shorter once you strip the windup. It isn't more polite in the gushing sense — it's more considerate in the sense that matters: it respects the reader's time, their caution, and their process. Maya moved the work of figuring out the request from the reader's plate to her own, which is precisely the trade that gets requests granted.

The lesson

A request gets a yes when it is easy to grant — and "easy to grant" almost always means specific, scoped, deadlined, and frictionless, with the hard thinking done before you hit send rather than offloaded onto the reader. The "before" email asked the reader to do Maya's job (figure out what she needs, assess the risk, invent a timeline) on top of their own; the "after" handed them a decision they could make in thirty seconds. The deeper move is the chapter's threshold concept in action: Maya stopped writing down everything she knew about her project and started writing down the one thing she needed the reader to do — and made that one thing impossible to misread and trivially easy to approve.

The test, before you send any request: Could the reader say yes to this in thirty seconds, without having to ask me a single follow-up question? If not, you haven't finished writing it.

Related: Chapter 19 §19.4 · Case Study 2 · Exercises