Write the One-Page AI Stance That Kills Ambiguity Before It Breeds Shadow AI

Workflow area: Policy & Governance · Tier: Advanced · Hands-on time: ~35 minutes

Every engineering org is currently broadcasting an AI stance whether it wrote one or not. If leadership says nothing, the team assembles a stance from fragments: the CFO's earnings-call comment about efficiency, a competitor's layoff coverage, the unexplained purchase of five hundred Copilot seats. The assembled version is usually darker than the truth — "they're measuring us secretly, and the tools are the layoff rehearsal" — and it drives exactly the behaviors that sink transformations: quiet tool avoidance, gamed metrics, and shadow AI used off the record where no policy reaches. DORA's research on AI capabilities keeps landing on the same point: a clear, communicated organizational stance is itself a performance-predicting capability. This document is thirty-five minutes of work and it is the cheapest trust you will ever buy.

When to use — and when not to

• Use it at the start of any serious AI investmentbefore the rollout (pb-43), alongside the policy (pb-25), so the tools arrive with their "why" attached.
• Use it when the fear is audiblequestions like "is this about headcount?" in all-hands or skip-levels mean the invented stance is already circulating; a written one is your only counter.
• Use it when leaders disagree in privatewriting one page forces the leadership team to reconcile "AI replaces work" and "AI augments engineers" into one story before the team hears both versions in different meetings.
• Skip it if you won't say anything truea stance written to soothe, which dodges the headcount question entirely or promises what leadership won't honor, is worse than silence once tested; if the honest answers aren't speakable yet, fix that first — it's a leadership problem no document solves.
• Skip making it a vision essayone page, four sections, declarative sentences; the moment it needs a table of contents it has become strategy theater nobody reads at the moment of doubt.

The recipe

1. 1.

   Answer the four questions in rough, honest bullets first. Before any drafting: Why are we doing this — what specifically do we expect AI to change for us, in our business? Where do we deliberately not use it — the no-AI zones and why they exist? How will we know it's working — what we measure (pb-37) and what we refuse to measure? What do we promise the team — about telemetry, about jobs, about training? Write the uncomfortable bullets too; they're the ones the document exists for.

2. 2.

   Draft the one-pager from your bullets.

   Copy

   Draft a one-page "Our AI stance" document for my engineering
   org, from my notes. Four sections, ~4 sentences each:
   
   1. WHY WE USE AI — our specific reasons, tied to our
      business, not industry hype. [NOTES]
   2. WHERE WE DON'T — our no-AI zones and the reasoning, so
      the boundaries read as judgment, not fear. [NOTES]
   3. HOW WE MEASURE — what we track (team-level, published),
      and what we explicitly refuse to track (per-person
      telemetry rankings). [NOTES]
   4. WHAT WE PROMISE — training and time to learn; measurement
      transparency; and our honest position on jobs. [NOTES]
   
   Rules: declarative sentences, first person plural, no
   hedging fog ("we may explore leveraging...") and no hype
   ("revolutionary transformation"). Every claim must be one
   my team can test against my future behavior. If any of my
   notes are evasive on the jobs question, say so instead of
   papering over it.
   

3. 3.

   Pressure-test it against the hard reader. Same conversation: "Read this as a skeptical senior engineer who suspects the AI push is pre-layoff efficiency math. Which sentences would they disbelieve, and what would make each testable?" Good output is uncomfortable:

   Copy

   DISBELIEVED: "AI lets us do more with the team we have."
   As written, this is unfalsifiable comfort. Testable version:
   "Our 2026 plan holds engineering headcount flat while we
   take on the payments migration we couldn't previously
   staff. If that intent changes, this document changes
   first, and we'll say so."
   
   DISBELIEVED: "We measure adoption to improve support."
   Testable version: name the metrics, the aggregation floor,
   and where the team can see the same dashboard leadership
   sees (your pb-38 rules).
   

   Rewrite until the skeptic's list is short. A stance is exactly as strong as its most disbelieved sentence.

4. 4.

   Reconcile it with leadership before publishing. The document commits your management chain, not just you — walk it past your leadership peers and your boss, and resolve the disagreements it surfaces now, in a meeting, rather than later, in contradictory answers at two different all-hands. If the org has a DORA-style capabilities assessment or AI council (pb-52), file the stance there too; it's the artifact those bodies keep asking for.

5. 5.

   Publish it where doubt lives, and re-test it quarterly. Post it in the team handbook, walk it in an all-hands with live Q&A, and link it from the AI policy — the policy says what, this says why, and they should cite each other. Then treat it as a standing commitment: every quarter, check each promise against what actually happened (was training time protected? did any per-person dashboard appear?), and update the document visibly when reality changes. A stance revised in the open builds trust; a stance quietly contradicted converts every future document you publish into noise.

Make it yours

• Small team or startup: the stance might be five sentences in the README and a founder saying it out loud at Friday demo — but the jobs sentence still matters most, because at a ten-person company "AI efficiency" and "we're not raising the next round" sound identical without it.
• Large org or GCC: your stance must nest inside the parent org's narrative without lying — where the parent's messaging is hype, write the site-level truth ("here is what it means for this site, this year") rather than amplifying. GCC-specific: address the outsourcing-anxiety layer directly — offshore teams hear "AI efficiency" as "repatriation risk," and only a named, testable commitment about the site's charter answers it.
• Post-layoff or mid-restructure orgs: you've lost the benefit of the doubt, so every sentence must be testable and the jobs section must reference what already happened — "after January, we understand why this document reads as spin; here's what we're committing to, in writing, and here's the review date." Credibility here is rebuilt in quarterly increments of kept promises, and this document is the ledger.

Quality check

• All four questions have real answersa stance that skips "where we don't" is marketing; one that skips the jobs promise is evasion; the skeptic reads the omissions first.
• Every promise is testablefor each commitment, name the observable behavior that would prove or break it; unfalsifiable warmth fails the document's whole purpose.
• It fits on one pagecount the words; past ~500 it stops being the thing people reread at the moment of doubt and becomes the thing nobody read.
• Leadership actually agreesthe stance survived a leadership review where the disagreements got argued out loud; a one-pager contradicted by your VP's next skip-level is negative trust.
• The quarterly re-test happenscalendar it; a stance that's never re-checked against behavior converges with the invented one it replaced.