This piece, originally published on Medium by Camille Fournier and republished here with permission, argues that as companies roll out AI tools, leaders often focus on security, compliance, or cost controls but neglect how team members should use AI in ways that respect colleagues’ time and expertise.
Fournier’s central point is that individual productivity gains from AI (i.e., producing more outputs) can harm overall team productivity if leaders don’t set expectations about quality, review, and communication. Policies should go beyond a binary approved/forbidden list and specify what respectful AI use looks like in day-to-day work.
Key elements of respectful AI use
-
Don’t ask someone to review work you haven’t reviewed yourself.
A common frustration on AI-heavy teams is people submitting AI-generated code or documents without even reading or understanding them. That shifts the validation burden to reviewers, who must trust both the prompt and the AI’s grasp of context. While iterative flows like AI code generation → AI review → AI fixes → human review can work well, the human initiating that loop still needs to verify outputs before passing them on.
Documents are an especially strong temptation because AI tends to be verbose and many people dislike writing or editing. Skimming an AI answer and then forwarding a generated document can miss gaps in framing or context that only the author knows. If you can’t explain the core ideas in the document or discuss them with others, you shouldn’t forward it without a clear caveat such as “This is AI-generated and I don’t fully understand this area—please help.” Many colleagues will refuse to read materials that the author clearly didn’t write or review themselves.
-
Shorter is better.
AI outputs often come out overly long. Generated code can look like tutorial examples with extra verbosity, and one-shot large changes can produce sprawling, thousand-line pull requests. Documents that should be three pages become ten or twenty. Long AI-generated chat messages or emails can also clutter communication. Fournier calls this impolite: even if you think you edited a large PR or document, you may still be asking far more of your reviewers than you invested.
Practical tests: if this change broke at 3:00 a.m. and none of the AI tools were available, could you read the PR and debug it? If not, it’s probably too large. For long documents, include a clear upfront summary so readers get the main points quickly. And when you find yourself crafting long, painstaking messages via AI to explain something, consider whether a meeting or call would be a better use of time—long text threads have always signaled the need for direct conversation.
-
AI is not an excuse to switch off your brain or your heart.
Signs of disengaged AI use include not reviewing AI-generated outputs, skipping human editing, failing to chunk changes, and avoiding real conversations by leaning on AI-mediated text. Respect for colleagues’ time and skills means handing over work you can stand behind and explain—using AI to make the result simpler, more reliable, or better tested, not merely to increase volume. If you’re mindlessly prompting and accepting output without thought, that’s a warning to change your process. Fournier references Vicki Boykis’s advice on adding friction to development workflows (or the equivalent for other roles) as a useful countermeasure.
Framing these guidelines
When creating AI use policies, connect them to your company’s existing values. Abstract points such as “shorter is better” resonate more when tied to an organizational principle. Fournier suggests that, hypothetically at Amazon, she might link the brevity guideline to the leadership principle Invent and Simplify.
Conclusion
Leaders should set clear, team-focused expectations for AI use: verify your own outputs, keep things concise, break work into reviewable chunks, and preserve human judgment and empathy in communication. Framing such guidelines with company values can help adoption. The author’s other writings include The Manager’s Path and Platform Engineering: A Guide for Technical, Product, and People Leaders.
Author and source
Camille Fournier — originally published on Medium and republished here with permission. Vicki Boykis is cited in the article as a recommended source of practical advice.
