Most of a manager's week is writing, reading and sorting: status updates, long threads, planning documents, feedback, notes from meetings you half-remember. That is exactly the work an AI assistant is good at, and it is also the work that quietly eats the hours you wanted for people and decisions.
This post is a practical starting point. It covers six tasks where an assistant earns its place, a prompt shape that works for each, and a short list of things to keep for yourself. It deliberately names no products; the habits matter more than the tool.
The mental model: a fast, eager junior colleague
Andy Grove's idea in High Output Management is that a manager's output is the output of their team, so your job is to raise the leverage of every hour. An assistant is one more source of leverage, as long as you treat it like a capable new colleague who:
- writes a decent first draft in seconds,
- knows nothing about your team unless you tell it,
- sounds confident whether or not it is right,
- never carries the accountability. You do.
That last point decides everything below. Let the assistant produce drafts, options and questions. You keep the judgment, the relationships and the signature. The same rule applies as in delegating to people: be clear about the outcome, give context, and review the result before it goes out under your name.
Six places it pays off
1. Turning a messy thread into a decision summary
Long design discussions and incident threads bury the actual decision. Paste the thread and ask:
Summarize this discussion in four parts: decisions made, decisions still open, who owns each next step, and the strongest unresolved disagreement. Quote the person's own words for the disagreement. Don't add anything that isn't in the text.
The last sentence matters. Skim the result against the thread once; you'll learn quickly how far to trust it for this kind of material.
2. Preparing for a hard conversation
This is the most underrated use. Describe the situation (without names or sensitive details) and ask the assistant to play the other person:
I need to tell an engineer their project is being cancelled after four months of work. Play that engineer. Be disappointed and a little defensive. I'll open the conversation; respond as they might, and stay in character until I say stop.
Run it twice. Then ask for what you did well and where you hedged. You rehearse the first ninety seconds, which is the part that usually goes wrong. It is no substitute for the real conversation, but it lowers the stakes of the first attempt.
3. Sharpening your writing
Plans, proposals, promotion cases and stakeholder updates all benefit from a second reader. Try:
Here is my draft update for a VP who has two minutes. What is the one thing they should take away? Does my first paragraph say it? List anything vague, and anything they would ask me in the meeting.
Asking for questions the reader would raise is more useful than asking it to "improve" the text, which tends to produce smooth, generic prose that no longer sounds like you.
4. Planning and breaking down work
Give it a goal and your constraints, and ask it to find what's missing:
Our team of five has six weeks to migrate the reporting service. Two people are on call every other week. List the work items, the dependencies between them, the three riskiest assumptions, and what we could cut if we're a week behind.
Treat the output as a prompt for your team's discussion, not as the plan. The value is in the risks and omissions you hadn't listed. Your engineers will correct the estimates, and they should. For a refresher on estimating with a team, see the Practitioner study guide.
5. Drafting the routine documents
Job descriptions, interview question banks, onboarding checklists, meeting agendas, retro formats, runbook outlines. These are documents where a reasonable template exists and your work is to adapt it. Give the assistant your team's context and ask for a draft; edit it by deleting what doesn't apply and adding what only you know.
A useful pattern: keep a short "team context" paragraph (what the team owns, its size, how you work, your current priorities) and paste it at the start of every request. You'll get far more specific output for ten seconds of effort.
6. Looking at your own patterns
Once a quarter, paste in your own anonymized notes from one-on-ones or your last three status updates and ask:
What topics do I raise repeatedly without resolving? What do I avoid mentioning? What questions do I never ask?
You are using it as a mirror. Whatever it says is a hypothesis to test, not a finding.
Where it fits in your week
Occasional use saves little. The gains come from attaching it to things you already do on a schedule:
| When | What to ask for |
|---|---|
| Monday planning | "Here are my priorities and my calendar. Where am I overcommitted, and what should move?" |
| Before each 1:1 | "From my last notes, what did I promise to follow up on, and what did they raise that I never answered?" |
| After a meeting | Rough notes in, decisions, owners and dates out, ready to send while people still remember |
| Before a proposal | "Argue against this. What would a skeptical peer team say?" |
| Friday | Bullet notes in, a weekly update out, using the prompt below |
Pick two rows to start with, not five. A habit you keep beats a system you abandon in week three.
A prompt structure you can reuse
Most weak results come from weak requests. Four parts cover nearly every case:
| Part | What to give | Example |
|---|---|---|
| Role and audience | Who it's writing as, and for whom | "You're helping an engineering manager write to a non-technical director." |
| Context | The facts it can't know | Team size, goal, constraints, deadline |
| Task | One specific job, and the format you want | "Give me five bullets, then one recommendation." |
| Guardrails | What not to do | "Don't invent numbers. Flag anything you're unsure of." |
Here is the difference in practice, for a weekly update:
Weak: Write a status update for my project.
Strong: You're helping an engineering manager write a weekly update for a director who reads it on their phone. This week: payment retries shipped Tuesday; the ledger migration slipped a week because the vendor changed their API; we need a decision on dropping CSV export from scope. Write three bullets (shipped, at risk, decision needed), each under 25 words, then a one-line ask. Don't soften the slip and don't add anything I haven't told you.
The first gets you a page of confident filler. The second gets something you can send after a two-minute check, because every fact in it came from you.
When the first answer misses, don't start over. Say what's wrong ("too formal", "you ignored the on-call constraint") and ask again. Iterating is cheaper than perfecting the first prompt.
What to keep for yourself
Some tasks should not be handed over, however good the draft looks.
- Performance judgments. An assistant can help you check that your feedback is specific, but it must not decide a rating, and it has not seen your engineer's work. A rating you can't explain in your own words is a rating you haven't earned the right to give.
- Confidential material. Know your company's policy on what may leave the building before you paste anything. If there isn't one, assume personal data about employees, unreleased plans and customer information stay out, and ask your security or legal contact. Anonymize by default.
- Anything that goes out unread. Every message under your name is yours. Read it, including the parts that sound plausible. Models can state wrong things fluently, so check names, dates, numbers and anything described as a fact.
- The human moments. Congratulations, condolences, an apology. People can tell, and it costs you more trust than the time you saved.
- Surveillance. Using AI to monitor individual activity or score people on indirect signals is a trust problem before it is a technology question. Your team will find out, and they will behave accordingly.
Be open with your team
Say how you use it. A short note such as "I use an assistant to draft agendas and tidy my writing; I don't put personal information into it, and I read everything before it goes out" does two things: it sets the norm for the team, and it makes it safe for engineers to tell you how they use it.
That second part is where the larger opportunity is. Your team is likely already experimenting. Ask in your next team meeting what's working, what has burned them, and where they'd like a shared approach: review expectations for generated code, what can be pasted into which tools, how to credit and verify. You don't need to be the expert. You need to make the conversation normal and set the standard that people stay accountable for what they ship.
Try this week
Pick one task you do weekly and dread slightly. Spend 20 minutes doing it with an assistant, using the four-part prompt above. Afterwards, write down three things:
- How long did it take compared to usual?
- What did you have to fix?
- Would you have been comfortable showing the whole exchange to your team?
If the answers are "less time", "a few facts" and "yes", make it a habit. If the third answer is "no", you've learned where your own line is, which is worth knowing before anyone else asks.
The managers who get the most from these tools aren't the ones who automate the most. They're the ones who use the hours they get back for the parts of the job only they can do: listening, deciding and developing people. The Practitioner certification is built around those skills for the same reason.