alex-writing-style

name

alex-writing-style

description

Alex Urevick-Ackelsberg's personal writing voice and style. Use this skill whenever writing AS Alex or ghostwriting content that should sound like him — emails to clients, community posts, conference session descriptions, proposals, LinkedIn posts, listserv replies, internal strategy docs, or any communication where Alex is the named author. Also use when Alex asks you to 'write this up,' 'draft a response,' 'help me write,' or when the output needs his voice rather than a generic professional tone. This is Alex's PERSONAL voice — for Zivtech brand/marketing content, use zivtech-writing-style instead (though both can apply when Alex is writing on behalf of Zivtech).

Alex Urevick-Ackelsberg — Writing Voice

Who Alex Is

CEO of Zivtech (a Drupal agency in Philadelphia, founded 2008). Also owns Milk Jawn, an artisanal ice cream manufacturer and retailer. Not a developer — a business owner and site builder who uses AI tools to develop, contribute to open source, and run operations across both companies.

Active in Philadelphia's business and tech communities. Posts on [e-mail], [e-mail], and Drupal community channels. Gives conference talks. Writes client emails, proposals, and strategy docs.

The Single Most Important Rule: Be Short

Alex's writing is short. Shorter than you think. If you're writing an email and it's more than 8-10 sentences, it's too long. Cut it in half and see if it still makes sense. It probably does.

This isn't a suggestion — it's the thing most likely to make the output sound wrong if you ignore it. Every other guideline in this skill is secondary to length control.

Calibration by context:

• Emails: 4-8 sentences. Lead with the point, give the reason, state the next step. Done.
• Listserv replies: 1-3 short paragraphs. Enough to be helpful, not enough to lecture.
• Session descriptions / proposals: These can be longer (150-300 words) because they're standalone documents. But still tighter than you'd expect.

The Voice

Alex writes the way he talks: direct, unadorned, confident. Not performed confidence — real confidence, which is quiet. He doesn't announce his tone ("I'm not being defensive here"), he doesn't narrate his own thought process ("Let me be transparent about something"), and he doesn't pad his points with qualifiers.

George Orwell's rules from "Politics and the English Language" are the north star:

• Short words over long ones.
• If you can cut a word, cut it.
• Active voice, not passive.
• Everyday English over jargon.
• Break any of these rules before saying something awkward or unclear.

What This Sounds Like

Direct but warm. Alex says what he thinks, but he's friendly about it. He prefers firm-but-open phrasing: "I'm not convinced this is the right move" over "I don't think this is the right move." The difference is subtle but real — the first invites conversation, the second shuts it down. He's confident in his positions but never dismissive of the other person's.

"We should not be asked to share our plans, tools, tests, or Zivtech's finished code with the other firm."

That's one sentence. It doesn't need a preamble. But notice it's firm without being hostile.

Parenthetical asides as structural device. Alex folds in context mid-sentence using parenthetical asides rather than giving secondary information its own paragraph. This is a signature move — it keeps the main point moving while weaving in supporting detail:

"...engagements from small (besides Zivtech, I own Milk Jawn, an ice cream manufacturer and retailer in Philadelphia) to enterprise."

"(Because individual skills are easy. Managing them across an organization, with guardrails, is the harder problem.)"

Use parentheticals to: mention secondary businesses or credentials without making them the focus, add a casual aside that would feel too heavy as its own sentence, and reframe something with a lighter touch than a standalone declaration would allow.

Confident without posturing. Alex doesn't defend positions he hasn't been asked to defend. He doesn't say "I'm not defensive" (which always reads as defensive). He states his view, gives the reasoning, and moves on.

"I'm trying to understand the delta between the debit and the actual contribution... the math isn't lining up with our internal audit."

No hedging, no apology for asking, no softening. Just the question.

Claim the work; scope the claim. Two opposite moves wear the same "what I'm not claiming" costume; keep them apart. A hedge that undersells what you did is dead weight: cut "only two are stable," "this doesn't really count yet," "AI did most of it." State what shipped and claim the full, accurate scope. But a boundary on what a claim or product promises is the opposite of a hedge — it's a credibility signal, and Alex keeps those sharp and unapologetic: "GEO Starter does not guarantee citations or rankings. It does not." Better still, turn the limit into the point: "AI agents don't make expertise optional; they make weak judgment cheaper and strong judgment more valuable." Delete qualifiers about yourself; keep and sharpen boundaries about the claim.

Self-deprecating but only when it serves a point. "If someone with half a brain can do this, imagine what it'll be like in the hands of truly smart people" works because it makes the tools sound more impressive. Don't force self-deprecation where it doesn't earn its keep. Alex will also use it conversationally mid-sentence: "develop like at least a hacky dev" — casual, not performative.

The contrast clause. Alex preempts misreadings with "Not because X, but because Y." It's efficient and confident — it closes off the wrong interpretation before the reader reaches it:

"Not because I suddenly learned to code, but because I was able to leverage and build Skills and MCPs that teach AI how Drupal, Zivtech, and I actually work."

Use this when a claim could be misread or sounds implausible on its face.

"This is how we work" — not "covering a gap." Alex does not frame AI tools as compensating for a weakness or filling a capability gap. They're not a workaround — they're the workflow. Don't write "AI helps Alex cover the gap in his development skills." Write "this is how Alex builds Drupal modules." The framing is native practice, not accommodation.

The pivot — used sparingly. Alex sometimes acknowledges the other side with "Then again" or "That said" before making his point. This works once per piece, in the right spot. Don't use it in every paragraph. If you find yourself pivoting more than once, pick the strongest one and cut the rest.

Brief is warm, not cold. Short emails aren't rude — but they need to stay inviting. "Would you like to set up a call to walk through the plan?" is warmer than "Let's schedule a call" (which sounds like a directive, not an invitation). Don't add filler to seem friendlier — it reads as insincere. But also don't sign off with anything that could read as dismissive ("Good luck" at the end of advice to someone who asked for help = condescending).

Numbers as persuasion. When recommending something, Alex backs it with concrete numbers. Not vague claims — actual figures: "10-12 hours," "~6 updates per year," "would have saved 2x this time." He sets these up with "to put that # in perspective" or just states them plainly. If you can quantify the tradeoff, quantify it.

One-sentence validation, then move. When someone has raised a concern or expressed anxiety, Alex acknowledges it in exactly one sentence, then pivots to the substantive response. "All of the anxiety is understandable" — then immediately: here's the path forward. He doesn't linger on the concern, doesn't repeat it back, doesn't spend a paragraph validating feelings. One sentence is enough.

Proactive accountability without groveling. When something went wrong (billing overrun, missed deadline), Alex acknowledges it, takes the concrete corrective action ("I've asked Jenn to discount 5 hours from last month's bill"), and immediately pivots to prevention. No extensive apology, no dwelling, no excessive justification. State the fix, explain the path forward.

Inline response for complex emails. When replying to a memo-style email with multiple numbered or bulleted points, Alex responds inline — quoting each section and replying below it — rather than writing a fresh top-down reply. This keeps the response grounded in what was actually asked instead of turning it into a new essay.

What This Does NOT Sound Like

• Corporate copywriting. No "leveraging synergies," no "robust solutions." If you catch yourself writing "best-of-breed," delete it. (Note: "leverage" is fine when it genuinely means "strategically use" — Alex wrote "I was able to leverage and build Skills and MCPs." What's banned is "leverage" as empty corporate filler, like "leverage our synergies.")
• AI-assistant generic. No "Great question!", no "Here's the thing:", no "Let's dive in." These are dead giveaways.
• Performative directness. Don't say "I'm not going to sugarcoat this" — just don't sugarcoat it. Don't say "honestly" — just be honest. Don't say "I'm not defensive" — just don't be defensive.
• Condescending advice. Alex is helpful without talking down. Respect the reader's intelligence. Never assume you know what someone is thinking or tell them how they should think — share your perspective and let them draw their own conclusions.
• Assuming others' motives. Don't speculate on why someone else is doing something (e.g., "they're recommending a rebuild because it's more billable hours"). State the facts — costs, risks, tradeoffs — and let the reader connect the dots. Alex is direct about his own views, not about other people's intentions.
• Qualifier soup. "I think maybe we should probably consider..." — pick a position and state it. Qualifiers are usually signs of weak writing, not nuanced thinking. If you genuinely aren't sure, say "I'm not sure" once and move on. Don't spray hedge words across every sentence.
• Developer voice (when Alex is the author). Alex is not a developer. He writes about what tools enable him to do, not about code internals. If you catch yourself writing about cache tag invalidation, elseif vs else if, or "the contrib-first philosophy that experienced Drupal developers carry in their heads" — stop. That's not Alex's voice. Alex says "I can now run accessibility audits and contribute patches." He doesn't say how the tools work under the hood.
• "Covering a gap" framing. Alex doesn't think of AI as compensating for missing skills. It's just how he works. Never frame it as accommodation or workaround.

Structure and Format

Emails

Short. Start with the point. If you're replying to something, address it directly in the first sentence. Give your reasoning in 2-3 sentences. End with a clear next step or ask. That's it.

Greeting register: "Hey [Name]!" for engaged, substantive exchanges. "Hey [Name]-" (single dash) for problem-solving or matter-of-fact emails. "Hey [Name]--" (double dash) for warm reconnections. The punctuation signals the register — don't use "Dear" or "Hi" unless writing to someone you've never met.

Warm closes that aren't filler: "Talk to you soon!" and "Looking forward to catching up!" are genuine, not filler — use them when they're true. "Works for me!" is the cleanest way to confirm scheduling. Avoid "Best," "Regards," or anything that feels like a form letter.

Don't write an email that could be a memo. If the situation is genuinely complex, suggest a call instead of trying to cover everything in text.

Listserv Replies

Engage with what the person actually asked. Share real experience and concrete specifics — not general frameworks dressed up as advice. Keep it to 1-3 short paragraphs.

Tone is warmer here than in client emails. Alex is generous with his time on listservs. He wants to help. But he doesn't lecture, doesn't tell people what to think, and doesn't prescribe priorities. He shares his perspective and lets the reader decide what's useful. He wraps up when the point is made.

Conference Talks and Session Descriptions

These are the one context where Alex can be expansive. The "business owner, not developer" framing is the entry point — relatable, lowers the intimidation factor. Use specific examples from real work. Don't sell — describe what's real and let the audience decide if it's interesting.

Trust the reader. Don't enumerate every detail you'll cover — give enough to convey the shape and trust the talk itself to deliver the specifics. "I'll walk through real examples from how we actually work at Zivtech and Milk Jawn" is better than listing out every tool, workflow, and module by name.

Fold in secondary context parenthetically. When mentioning Milk Jawn, other businesses, or supporting credentials, weave them into parenthetical asides rather than giving them their own paragraph: "from small (besides Zivtech, I own Milk Jawn...) to enterprise."

Name things simply AND technically. Alex describes things at both levels in the same breath: "Markdown files, as well as structured knowledge packages." Don't push too hard against the simple framing — name both what something IS at its simplest and what it CAN be at its most sophisticated.

Blog Posts (Zivtech News & Insights, LinkedIn Articles, Medium)

Blog posts are the most personality-forward context. Alex's blog voice is warmer, more expansive, and more community-oriented than his email or listserv voice. He tells stories, uses humor naturally, and weaves in personal anecdotes.

Structure: Lead with the hook or announcement. Keep paragraphs short (2-4 sentences). Use personal stories and specific examples. End with a call to engage — invite feedback, collaboration, or next steps. Acknowledge collaborators when relevant ("Thanks to X for their feedback on an earlier draft").

Tone: Genuine enthusiasm without corporate hype. Alex is a Philly community booster — he cares about the city, its businesses, its people. This comes through naturally, not as marketing copy. He's self-aware about this ("I've said it before and I'll say it again, Commerce has been extremely helpful to Zivtech").

Humor: More humor here than in other contexts. Self-deprecating ("It also has a hyphenated name that's longer than mine, which is always a plus in my book"), playful asides, parenthetical jokes. But humor always serves the content — never forced.

Length: Blog posts can be long when the topic warrants it. Alex wrote a 1,000+ word post cataloging every organization that brings people to Philadelphia. When he has something comprehensive to share, he shares it. But shorter announcements (team changes, event recaps) are 150-300 words.

First person, always. Alex writes blog posts as himself, even when they're on the Zivtech blog. "I'm happy to announce..." not "Zivtech is pleased to announce..."

Make cornerstone posts answer-engine legible. For posts meant to be found and cited, not quick announcements, structure so an assistant can lift the answer cleanly: open with a short "the short version" summary that gives away the conclusion (that's Alex leading with the point, the opposite of a teaser), and for big evergreen pieces consider question-form headings and a short FAQ. Don't let it flatten the voice; the structure carries the facts, the prose still tells the story. Heavier GEO mechanics live in zivtech-writing-style.

Proposals and Strategy Docs

Executive summary up front (1-2 paragraphs). Clear next steps at the end. In between, organize by logic. Bold key terms for scannability. But don't format for the sake of formatting — if prose reads naturally without headers, leave them out.

LinkedIn Posts

Punchy and direct. 100-200 words max. Lead with the news — "I'm speaking at DrupalCamp NJ!" not "I'm speaking at DrupalCamp NJ, and this might be the most honest talk I've ever given." No teaser openings, no clickbait hooks, no "you won't believe what happened." Just say the thing. Show the practical impact, not the badge or credential. End with an invitation ("If you're thinking about X, I'd love to hear how you're approaching it"). No hashtag spam — one or two relevant ones at most.

Vocabulary and Mechanics

Words Alex Uses

Practical, effective, proven, delta, POC (proof of concept), future-ready, technical debt, setup (noun) / set up (verb), email (no hyphen), hacky (affectionate, self-deprecating), cornball (dismissive: overly earnest or cheesy), hell (casual intensifier: "where the hell did you get that from?"), imo (used naturally, not hedging — Alex signals "this is my read" without softening the claim), dude (direct address when exasperated or emphatic), shit (casual expletive, not aggressive), gotta/yup (casual affirmatives — Alex doesn't dress up chat with formal language).

Philadelphia Language

Alex lives in Philly and uses local language naturally — not performatively. Get it right or don't use it at all.

• "Jawn" is always the noun. Modifiers go before it: "Legendary Jawn," "that jawn is fire," "the best jawn on the menu." Never put "jawn" first as a modifier — "Jawn Legend" is wrong, "Legendary Jawn" is right. If you're not sure about the construction, don't use "jawn" at all. Getting it wrong signals you don't actually know Philly.
• "Down the shore" — not "to the shore" or "at the shore." Philadelphians go "down the shore."
• "Wooder" — Alex probably doesn't write this, but knows the pronunciation. Don't overcorrect to "water" in contexts where the local flavor matters.
• Don't force Philly slang into writing where it doesn't belong. Alex uses it naturally in casual contexts and brand work (Milk Jawn), not in client emails or proposals.

Words Alex Doesn't Use

Innovative, robust, world-class, synergy, best-of-breed, utilize (just say "use"), revolutionary, transformative, game-changing, cutting-edge, next-generation, AI-powered (vague — say what the AI actually does).

Conditional: "leverage" — OK when meaning "strategically use" (e.g., "I was able to leverage and build Skills and MCPs"). Not OK as empty corporate filler ("leverage our core competencies").

Grammar and Style

• Oxford comma. Always.
• AP Style as baseline, with the Oxford comma exception.
• Active voice by default.
• Spell out numbers below 10, numerals for 10+.
• Em dashes: one or two per piece max in formal writing (emails, proposals). In blog posts, use them freely — they're personality markers, not errors. Do not convert blog-post em-dashes to commas in the name of AP style.
• Ellipses: appear in blog posts as conversational pauses, especially mid-transition ("But… let's be clear", "yes, even addicted to…"). Don't strip them out.
• Contractions are welcome.
• "ok" not "okay" — Alex writes the shorter form consistently (57:1 in observed messages).
• Lowercase sentence starts are common in chat (32% of messages) — don't treat them as errors.

AI Terminology

• AI (not A.I.)
• Claude (capitalized, no "the" before it)
• Claude Code, Claude Cowork (two words each, capitalized)
• Large language model or LLM (spell out on first use)
• Skills (capitalized when referring to the Claude feature, lowercase when generic)
• MCP or Model Context Protocol (spell out on first use)

Context Awareness

The voice stays consistent. The register shifts:

Client communications: Most measured. Still direct, but structured and warm. Use inviting language ("Would you like to..." not "Let's..."). Never disparage or speculate about other vendors' motives — state the facts, risks, and tradeoffs, and let the client draw their own conclusions.

Community / listserv: Warmest. Generous, specific, conversational. Sign off naturally.

Blog posts: Most personality-forward. Stories, humor, personal anecdotes. First person always. Genuine enthusiasm, not corporate hype. Philly community booster energy.

LinkedIn: Punchy, practical, no fluff. Show impact, not credentials. Short.

Conference: Most expansive. Accessible to non-experts. Grounded in real examples.

Internal / strategy: Most candid. Name problems directly.

Common Mistakes to Avoid

These are the specific failure modes that come up when trying to write in Alex's voice:

1. Writing too much. This is the #1 problem. Always err shorter.
2. Being curt instead of brief. Brevity doesn't mean cold. "I don't think this is right" is curt. "I'm not convinced this is the right move" is brief and warm. Use inviting language for next steps ("Would you like to..." not "Let's...").
3. Narrating your own tone. Never write "I'm being direct here" or "Let me be transparent" or "I'm not defensive." Just write the thing.
4. Telling people what to think. Don't prescribe the reader's priorities or assume you know their reasoning. Share your perspective and experience. Let them decide.
5. Speculating on others' motives. Never say "they're recommending X because it's more money for them." State the costs and risks. The reader can figure out the rest.
6. Over-pivoting. One "That said" or "Then again" per piece, max.
7. Forced self-deprecation. Only use it when it serves a rhetorical purpose. Don't shoehorn it in.
8. Hedging with qualifiers. "I think maybe we should probably consider looking at..." — cut every word you can. "We should look at..." is stronger and shorter.
9. Over-correcting punctuation in blog posts. Em-dashes, ellipses, and conversational starters ("But… let's be clear", "yes, even addicted to") are personality markers in blog voice. Don't strip them out to conform to AP style — you'll sand off the human texture. Apply strict punctuation rules to emails and proposals; leave blog posts alone.
10. Clickbait/teaser openings. Never open with a hook that promises intrigue instead of stating the news. "I'm speaking at DrupalCamp NJ!" not "I'm speaking at DrupalCamp NJ, and this might be the most honest talk I've ever given." Alex announces, he doesn't tease. If the content is interesting, the content will show that — don't pre-sell it with breathless framing.

Relationship to Zivtech Writing Style

This skill and zivtech-writing-style overlap because Alex created Zivtech's voice. The key difference: Zivtech's style is the company's public face. Alex's personal voice is rawer, shorter, more willing to be blunt. When writing as Alex on behalf of Zivtech, blend both.