Tomás Herrera had a real problem and a weak document. He runs a six-person internal-tools team, and for three months his team had piloted a deployment platform that cut release time noticeably and reduced failed deploys. The pilot worked. Now he needed budget to expand it to the rest of engineering, and his first draft of the request read like a shrug: "The tool is working well. We should build it out more. It costs about five thousand a month but saves time. Here is the data." His director would have skimmed it and moved on. The thinking behind the request was strong; the writing buried it. This lesson is about closing that gap: using AI to make written communication clear, structured, and persuasive, while keeping the judgment that no tool can supply.

Why Writing Is Where Your Thinking Shows

At this level of management, much of your influence travels through documents you are not in the room to defend. A business case, a recommendation, a proposal for a process change: these are judged when you are not there to explain them. That makes written communication a form of leverage. When a reader understands you easily, they decide faster, trust your judgment more, and can build on your ideas. When the writing is muddy, they assume the thinking is muddy too, and they stall.

It is worth being specific about what is at stake in each kind of writing you do. Business proposals are judged on the clarity of your thinking, not merely the clarity of your sentences. Strategic documents shape direction and where investment goes. Recommendations have to persuade through evidence and logic rather than through your position in the hierarchy. Reports set expectations and quietly establish whether people consider you credible. Even email builds or damages relationships over time. The manager's real difficulty is that writing takes time and most managers are rushed, so you either send something adequate when excellent was possible, or you burn three hours on something that strategic help could have made better in one.

AI is genuinely strong at the mechanical parts of this work: drafting from an outline, organizing complex information, strengthening a flabby argument, polishing grammar and flow, finding the phrasing you were reaching for, and shifting a draft between a formal and a plain register or between one audience and another. What it cannot do is decide what is actually important, judge whether your argument is true, or know what tone serves a particular relationship. The skill at Level 3 is using AI for the mechanics while you own the substance. Done backwards, with AI deciding the substance and you supplying the mechanics, it produces documents that read beautifully and argue nothing.

Start With Architecture, Not Sentences

The biggest mistake managers make is opening a blank document and writing the first sentence. Strong documents are built on a structure decided before the prose. Most persuasive business documents share a backbone:

• Opening or executive summary. What is this about, and what are you recommending? A busy reader should grasp the core in the first paragraph.
• Context or problem. Why does this matter, and what led here?
• Evidence and analysis. What you found, organized logically.
• Argument. What the evidence means and why it supports your conclusion.
• Recommendation or call to action. What you are asking the reader to do or decide.
• Supporting detail or appendix. The depth that interested readers can dig into without slowing everyone else down.

Different documents shift the emphasis. A proposal leads with what you are proposing and what it costs. A recommendation walks through the options you considered before naming your pick, because showing your reasoning is what earns trust. But the backbone is stable, and AI is excellent at helping you stress-test it before you write a single paragraph of prose. Ask it to lay out a structure and, crucially, to list the questions a skeptical reader will ask. That second request is where AI earns its keep, because it surfaces gaps while they are still cheap to fix.

How Each Document Type Shifts the Weight

The same backbone carries different loads depending on what you are writing, and knowing which section has to do the heavy lifting saves you from writing a well-structured document that answers the wrong question.

• Proposals lead with what you are proposing, why it matters, and what it costs. Everything after that exists to support the business case for saying yes.
• Business cases run problem, solution, financials, risks, timeline, with the emphasis squarely on business impact. If a reader cannot find the money in your business case, you have not written one.
• Recommendations run situation, options considered, recommendation, rationale, next steps. The options section is not filler; it is the proof that you thought rather than guessed.
• Strategic documents run opportunity, direction, investment, timeline, success measures. They operate at the level of the big picture, and readers expect to see how you will know whether it worked.
• Reports run what we did, what we learned, what it means. The emphasis belongs on insight, not on activity. A report that lists work performed without saying what it means is a status log, not a report.

The same principle applies to who is reading. A single document sent unchanged to your director, your peers, and your team almost never serves all three well, because each needs a different emphasis. Deciding what to foreground for a given reader is judgment work, and it is one of the easiest things to hand to AI once you have made the call: give it the audience and ask it to reweight the emphasis without changing the facts.

Where This Shows Up in Your Week

The writing worth investing in is more varied than most managers expect. Across a typical quarter you are likely to write a business proposal arguing that the organization should invest in something, a business case laying out a strategic opportunity with the financial analysis behind it, a strategic recommendation naming a direction and defending it, and a project status report comparing what you said you would do against what actually happened and what you learned. Alongside those sit the problem diagnosis, where you name an issue, show your analysis, and recommend a fix; the policy or process change proposal; the executive summary that distills a complicated situation down to what a decision-maker actually needs; and the client or stakeholder briefing that explains someone's situation, what you have done about it, and what impact it had. Each of these benefits from the same discipline: architecture first, evidence second, polish last.

A Worked Example: Tomás Builds the Business Case

Here is how Tomás turned his weak draft into a document that got approved.

He started with the structure, not the sentences. His prompt named the goal and handed over his raw material:

I am writing a business case to expand an internal deployment platform we piloted. Help me with two things. First, lay out a structure that moves a skeptical reader from doubt to approval. Second, list the questions I will need to answer that a director might raise. Here is what I have: pilot results (deployment time down 40%, failed-deploy rate down 25%); team feedback universally positive; build cost of $80,000 already spent; ongoing maintenance of $5,000 a month; context that competitors offer modern tooling and engineering talent is hard to retain.

The AI returned a clean structure (summary, problem, solution, evidence, investment, return, timeline, risks) and a list of pointed questions: How many engineers does this affect? What is the alternative if you do nothing? How confident are the pilot numbers at larger scale? Is the $5,000 a month sustainable as usage grows? Several of those questions Tomás had not yet answered, which told him exactly where his case was thin.

He did the math the AI could not. The structure was a scaffold; the substance was his. He worked out the return himself. The platform serves 40 engineers. If each saves an average of 30 minutes per week on deployment, that is 20 engineer-hours a week. At a loaded cost of roughly $75 an hour, that is about $1,500 a week, or $6,000 a month in recovered engineering time, set against $5,000 a month in maintenance, with the $80,000 build already a sunk cost. The case now had a concrete payback he could defend, not a vague claim that it "saves time." This number was his to produce, because only he knew the team size and the realistic time saved. The AI would have happily invented a plausible figure if asked; that is exactly why he did not ask it to.

He chose the story. The AI's draft framed the platform as an efficiency tool. Tomás reframed it: the bigger argument was talent. Engineers want to work with modern deployment tooling, and the platform was as much a retention play as a productivity one. That framing was a judgment call rooted in context the AI did not have, and it was the part of the document that actually moved his director.

He used AI to draft each section, then edited hard. With the structure set and the substance decided, he had the AI build out each section from his bullet points, then rewrote the executive summary in his own voice and trimmed two sections the AI had padded. The final business case was three pages: a one-paragraph summary with the recommendation and the payback, a problem statement grounding it in velocity and retention, the evidence from the pilot, the financial case with the $6,000-versus-$5,000 comparison, a phased rollout timeline, and an honest risks section. It read like Tomás wrote it, because in every way that mattered, he did. It was approved in one meeting.

The rollout timeline is worth noting on its own, because a phased plan is itself persuasive. Tomás did not ask for everything at once. He proposed finishing the remaining features and integrating with production systems first, then rolling out to two or three teams and gathering feedback, then expanding across engineering, then iterating on what came back. A reader who is nervous about risk reads a phased plan as evidence that you have thought about failure, which is often the difference between approval and "let us revisit this next quarter."

The pattern to copy: AI structured the document and surfaced the hard questions; Tomás supplied the numbers, chose the framing, and owned the voice. The mechanics were delegated; the substance never was.

A Second Case: Moving Leadership From Interesting to Decided

Some months later Tomás was pulled into a different kind of document. His organization was weighing whether to move into an adjacent market, he had spent weeks on the analysis, and the writing had to carry leadership from "this is interesting" all the way to a decision, in either direction. That is a different job from a budget request, and he prompted for it differently: he told the AI he needed to present the opportunity, the options he had considered including doing nothing, his recommendation, what could go wrong and how he would mitigate it, and the timeline, and he asked what would make the recommendation both persuasive and honest about the trade-offs.

What came back was less a template than a persuasion sequence, and it is a sequence worth remembering. Lead with the opportunity, so the reader is thinking about the prize before they are thinking about the cost. Then show why you specifically can win it, naming your advantages and being straight about your gaps. Then show why the timing argues for moving now rather than later, which usually means naming the cost of waiting. Then address the concerns, so the reader sees you have already been where their doubts are going. Only then move to the ask.

The AI was also useful for something Tomás would have skipped on his own: naming the objections in advance. Three recur in almost every recommendation of this type. "This is risky" is answered by showing you have quantified the risk and have a mitigation plan rather than by insisting it is safe. "Our hands are already full" is answered by showing the return justifies the focus. "We should wait and learn more" is answered by making the cost of delay concrete, usually in terms of what a competitor gains while you deliberate. Tomás wrote each of those answers into the document rather than saving them for the meeting, and the document did more work as a result.

The sections he ended up with followed the sequence: an executive summary naming the opportunity and his recommendation, the market opportunity itself, why the organization could win it, the alternatives he had weighed and set aside, how entry would actually work, the risks and his honest confidence level, the measures that would tell them whether it was working, and a clear ask. What made it land was that it moved from analysis to a decision instead of recommending more research, showed the alternatives so nobody could accuse him of narrow thinking, acknowledged risk rather than burying it, and stayed confident without tipping into arrogance.

A Third Case: Writing About Direction Change

The hardest written communication Tomás has done was not a request for money. It was a document explaining a shift in direction to people who had spent years building the thing being de-emphasized. High-stakes writing of this kind has to do five things at once: help people understand why the shift is necessary without implying that the previous direction was foolish, paint a clear picture of where you are going, be explicit about what changes and what does not, give people agency by showing how they fit, and build genuine commitment rather than compliance.

Tone is the whole game here, and it is exactly the kind of thing worth thinking through with AI before drafting. The framing that worked was to treat change as continuity rather than rupture: some of what we do will change, some will evolve, some will stay the same, and that is what growth looks like. Alongside that, people need clarity and a role, which means saying where you are heading and how different roles contribute rather than leaving them to guess.

The structure followed from the tone. Start with where you have been, acknowledging the journey and what the team built, because skipping this reads as dismissal. Then what changed in the outside world, whether that is customer needs, competitors, technology, or the market, so the shift looks like a response rather than a whim. Then where you are going, in concrete terms. Then why it matters and how it positions you. Then, crucially, what changes and what does not, because ambiguity here is what generates rumor. Then the roadmap, then what you need from people, then an open invitation to bring questions and concerns. Tomás closed by naming the uncertainty honestly and committing to specifics: that he would be available, that he would keep people informed, that he would follow up with individual conversations about what this meant for each role. That closing was his, not the AI's, and it was the part people quoted back to him.

Persuade With Evidence, Not Polish

Persuasive documents do not win on adjectives. They win on structure, specific evidence, and honesty about trade-offs. "We improved deployment performance by 40%" persuades; "we got much better" does not. Acknowledging a legitimate counterargument persuades; pretending none exists makes a sharp reader suspicious. When Tomás wrote a separate recommendation later about whether to adopt a second vendor tool, the section that did the most work was the one where he named the case against his own recommendation and explained why he still came down where he did. Addressing objections directly is more convincing than ignoring them, and AI is useful here precisely because you can ask it, "What are the strongest objections to this recommendation?" and then answer them in the document.

Two further mechanics matter. The first is explicit reasoning: it is not enough to present evidence and state a conclusion, because the reader has to see why the one supports the other. Leaving that connective work implicit is how strong analysis gets read as assertion. The second is tone, which should land as confidence without arrogance and openness without weakness. Documents that overclaim invite resistance; documents that hedge everything invite delay.

Iteration Is the Work, Not a Sign of Failure

Almost nothing good is right on the first draft, and treating the first draft as nearly finished is the most common way managers waste the advantage AI gives them. The useful discipline is to run distinct passes rather than one vague round of tinkering. Get the ideas out first without judging them. Then do a structural review: does the organization make sense, is anything missing, would a reader get lost? Then an argument review: is the logic sound, is the evidence sufficient for the claims you are making? Then polish, which is where tone and readability get attention. Then a final review with one question in it: am I proud of this, and would I be comfortable sending it to the most senior person who might read it?

AI can help at every one of those stages, but only if you tell it which stage you are in. "Make this better" gets you a diffuse rewrite. "Review only the structure and tell me what is missing or out of order" gets you something you can act on. Tomás runs his important documents through the structural and argument passes with AI and does the polish pass mostly by hand, because that is where his voice lives.

The Traps of Writing With AI

Polish hiding a weak argument. This is the central risk at this level. AI will make a shaky case read beautifully, and a beautiful-reading shaky case is more dangerous than an ugly one, because it gets approved. Before you ask AI to polish anything, make sure the underlying argument is sound. Use AI to strengthen weak logic by surfacing its gaps, never to paper over it.

Losing your voice. An executive summary can be technically perfect and still read like an algorithm wrote it. Readers who know you will notice, and the mismatch quietly costs you credibility. Read every important document aloud. If a colleague would not recognize it as yours, rewrite it until they would.

False confidence. AI tends toward authoritative phrasing. If your analysis is preliminary, say "our analysis suggests," not "this will." Hiding uncertainty inside confident prose is a trust violation that surfaces the moment your prediction misses.

Over-length. Ask AI to expand and it will cheerfully turn a tight three-page recommendation into a twelve-page tome. Longer is not stronger. Keep the main document readable in one sitting and push supporting detail to an appendix.

Skipping the real edit. The most common shortcut is accepting a decent AI draft, tweaking two sentences, and sending it. A genuine editing pass, reading the document as if a stranger wrote it and asking what is fuzzy and what is missing, is usually what separates an adequate document from an excellent one. Build the time in.

Processing feedback without understanding it. This one is specific to AI-assisted writing and easy to miss. Someone comments on your draft, you paste the comment into the tool, it rewrites the section, and now the document is different but not actually better, because nobody diagnosed what the feedback meant. "Make this more compelling" and "this is dishonest" are not the same note and do not have the same fix. Understand what a reviewer is actually telling you before you let a tool act on it, then use AI to incorporate the real feedback while keeping your voice.

Judgment Checkpoints Before You Send

For any document that carries real weight, walk through these before it leaves your hands:

• Argument soundness. Before any polishing, is the core argument actually strong? State it in three sentences and see if it holds.
• Voice authenticity. Does this sound like you, or like a generic corporate document?
• Completeness. What is essential to understanding, and is anything important missing? What is padding that should be cut or moved to an appendix?
• Tone calibration. Does the document carry the right level of confidence, urgency, and openness for this situation, or has it drifted toward a register that will read as pushy or as tentative?
• Honesty about certainty. Are you stating as fact anything the evidence only suggests? Are your assumptions named?
• Audience fit. Does this document actually work for the people who will read it, or does it assume context they do not have and skip what they most need to know?
• Fairness. If you compare yourself to an alternative, are you fair about its strengths? Do you address the real counterarguments?
• Final read. If you sent this tomorrow and someone challenged it, would you be proud to defend every line?

Writing Responsibly With AI

Four responsibilities sit on you rather than on the tool, and each one has a practice attached.

Authenticity and trust. Documents that are overly polished or that carry an unmistakable machine cadence erode trust once readers sense the inauthenticity, and that erosion is hard to reverse. Protect your voice through the polishing stage rather than letting polish flatten it. For anything important, let the draft sit and come back to it with fresh eyes. The simplest test is the one Tomás uses: if someone asked "did you write this," would you be comfortable saying yes?

Argument integrity. Because AI can make a weak argument sound compelling, the order of operations is a matter of integrity and not just craft. Strengthen the argument first and polish second. If something feels off about your logic, do not cover it with better prose; fix the logic. And when you present evidence, be honest about its limitations, including how small the sample was or how short the timeframe.

Honesty about certainty. If your analysis is preliminary, say so. If you are relying on assumptions, state them where the reader can see them. If there is data you do not have, acknowledge the gap rather than writing around it. Acknowledging what you do not know is what makes people trust you on what you do.

Fairness in presentation. It is entirely possible to present evidence in a way that never lies and still leaves a false impression. If you are comparing your approach to a competitor's or to an alternative you rejected, be fair about its genuine strengths. If you are making a case, name the legitimate counterarguments rather than hoping nobody raises them. Strong documents address objections; weak ones route around them.

Terms Worth Knowing

• Document architecture. The structural organization of a document: its sections, its flow, and the logic that connects them.
• Argument soundness. Whether the logic actually holds, meaning the premises support the conclusion and the evidence is sufficient for the claim.
• Evidence hierarchy. Organizing your evidence so the most important material is the most prominent, rather than presenting everything at equal weight and letting the reader sort it out.
• Prose clarity. How easily a reader understands what you are saying. Clear prose is usually shorter and more concrete than the alternative.
• Tone calibration. Matching the register of a document to its audience and situation, whether that means formal or conversational, urgent or steady.
• Executive summary. A distillation of the key points so a busy reader understands the main idea without reading the whole document.
• Call to action. The clear ask or next step at the end of the document, so the reader knows what you want them to decide or do.

Practice and Reflection

These are worth doing on real documents rather than as exercises, because the value comes from the friction of your actual work.

• Read it aloud. Take a document you are writing this week, draft it with AI support, then read the result out loud. Does it sound like you? Would a colleague recognize your voice in it? Wherever the answer is no, rewrite for authenticity.
• Test the argument in three sentences. Before you draft, write your main argument in three sentences and see whether it holds up on its own or has visible gaps. Then draft the full document with AI support and check whether the finished version strengthens that core argument or quietly dilutes it.
• Integrate feedback deliberately. Get feedback on a document in progress. Before you act on any of it, work out what the feedback is really saying. Then use AI to incorporate it while keeping your voice intact.
• Edit for structure. Take a longer document you have already written and outline its structure after the fact. Is the order logical? Is anything out of place? Would a reader get lost partway through? Restructure based on what you find.
• Calibrate the tone on purpose. Decide what tone your document actually needs, whether authoritative, open, urgent, or steady. Read your draft against that decision. Where it does not match, revise until it does.
• Look backward once. Spend two minutes on your past week and find one task, decision, or piece of writing where these ideas would have changed your approach. What would you have done differently, and what would the outcome have been? Writing that connection down is where the concept becomes practice.

Related Lessons

• Complex Stakeholder Communications covers the same persuasion problem across channels rather than on the page. Written documents are one channel among several, and the principles about framing, evidence, and honest trade-offs carry directly.
• Presentation and Narrative Building is the closest sibling to this lesson. Narrative structure works the same way whether you are writing it or speaking it, and the architecture discipline here is the written form of the same skill.
• Structuring Complex Decisions matters because the decisions you structure are usually communicated through written documents. A well-structured decision is far easier to write up, and a muddled one resists every attempt at clear prose.
• Recommendation Development is the analytical work that sits behind the recommendation documents in this lesson. Developing a sound recommendation and writing it persuasively are separate skills, and doing the second well depends on having done the first properly.

Key Takeaways

• Use AI for the mechanics, own the substance. AI drafts, organizes, and polishes well. It cannot decide what is important, judge whether your argument is true, or know what tone serves a relationship. Reverse that division and you get documents that read beautifully and argue nothing.
• Decide the architecture before you write prose. Strong documents are built on a structure chosen up front. Ask AI to propose a structure and, more valuably, to list the questions a skeptical reader will raise, which surfaces gaps while they are cheap to fix.
• Supply the numbers and the framing yourself. Tomás worked out the $6,000-versus-$5,000 payback and chose to frame the platform as a retention play. Both required context the AI did not have; both are what won approval.
• Persuade with specific evidence and honest trade-offs. "40% faster" beats "much better," and naming the counterargument beats pretending it does not exist.
• Never let polish hide a weak argument. AI makes shaky cases read well, which makes them more dangerous, not less. Strengthen the logic first; polish second.
• Protect your voice and your honesty. Read important documents aloud, rewrite anything that does not sound like you, and never bury uncertainty inside confident prose.
• Edit for real. A genuine editing pass, reading the draft as a stranger would, is usually what turns an adequate document into an excellent one.

Frequently Asked Questions

If AI writes most of the draft, is the document still mine? Yes, in the way that matters. Authorship of a business document is about the argument, the evidence, the framing, and the accountability, not about who typed the connective sentences. When you decide the structure, supply the real numbers, choose the story, and verify every claim, the document is yours regardless of how the first draft was assembled. If someone asks "did you write this," you should be able to say yes without hesitation.

How do I stop AI from making my draft too long? Tell it the length up front and resist its tendency to expand. A useful instruction is "keep the main document under three pages and put any supporting detail in a separate appendix section." Then, in your edit, treat every sentence as guilty until proven necessary. Length is added by accretion; it has to be removed deliberately.

What is the single highest-value way to use AI on an important document? Ask it for the objections. Before you write, prompt it with "What are the strongest reasons a skeptical reader would reject this recommendation?" Answering those objections inside the document is what turns a draft that merely states a position into one that actually persuades.