AI native teams

How organizations make AI use the default rather than the exception — the enablement/adoption lane, distinct from building with AI. Seeded from Luke Pierce’s (Boom Automations, 80+ client companies) full playbook, captured verbatim.

The core diagnosis

Luke Pierce (163❤/20k views; full article in clipping): “every company we talk to now asks for the same thing — they want their team AI native,” and “everyone wants it, very few have a plan for getting there.” The failure mode everyone knows: licenses + one lunch-and-learn → usage spikes a week → back to the old way. What’s missing is an owner — “getting a team AI native is an ongoing function you run, closer to how you run sales training than a one-time software rollout.”

The definition of done: team uses AI in daily work without being told; stays current as tools change; when someone spots a task that eats hours, they build the fix or bring it scoped; leadership uses it out in the open. “You’ll know you’re there when the best ideas start coming from the team instead of the top.”

The playbook (9 steps)

  1. Name a champion — “a curious operator the team already respects, often someone from ops. They don’t have to be the most technical person in the building. In fact, the most technical person tends to build things nobody else can use.” Owns tool-watching, monthly training, use-case logging, first-stop help. Make-or-break: the time is real (written into the job) and they report into leadership (so asks carry weight).
  2. Continuous AI team — champion + one rep per department, biweekly; owns the use-case backlog (ranked by hours saved), the library, the AI policy, the training calendar.
  3. One-page AI use policy — the fear fix: “people don’t know what they’re allowed to put into these tools, so they put in nothing.” Approved tools (company accounts), data boundaries, human-review points, who to ask. “Giving people clear permission is part of enabling them.”
  4. Monthly training on real work — split by level (leadership/power/beginner — “one training for everyone loses half the room”); pick a workflow the team already runs, show the AI version live, have them rebuild it before the call ends, record it.
  5. A library that stays current — recordings + how-tos + prompt library by role; monthly add/keep/cut triage (“if it would confuse someone next quarter, it goes”).
  6. Make it competitive — hackathon (leadership judges, winners get real things), two-week challenge for small teams, a wins channel (“free, and it spreads ideas faster than any training”), five-minute show-and-tells.
  7. Protect the time — weekly AI hour blocked for everyone; champion office hours.
  8. Bake into hiring and onboarding — library + policy in week one; AI in job descriptions; reviews ask “how have you used AI to improve your work this quarter?”; “when the CEO shares how they used AI this week, the team stops wondering whether it’s really expected.”
  9. Measure — active usage, workflows rebuilt, hours saved (timed before/after — “the one that shows up on the P&L”), backlog shipped, attendance.

Where this sits in the vault

  • The champion/library/backlog machinery is Software factory’s pane-of-glass pattern at the human layer — the continuous AI team is the org-side counterpart of factory-as-code.
  • The “curious operator, not the most technical person” champion selection rule rhymes with Career development’s ownership-scope thesis: the role is about translation and trust, not depth.
  • The use-case-backlog-ranked-by-hours-saved is Karwatka’s “review the last ten projects, pick one costly repeated activity” at team scale — the same asset-that-compounds move.
  • Kin: Vibecoding vs AI engineering (who does the building), Swizec’s accountability-first culture field report (what leadership signals mean).

Related: Software factory · Career development · Coding with agents 2026-10-07

Field report: what a 97%-AI codebase does to roles (swizec, 2026-10-08)

swizec at Plasmidsaurus (21-person org, AI writes 97% of the code, hundreds of PRs/week, 16% auto-merged) on what adoption at that depth does to the org — the “everyone got promoted” datapoint this note was missing:

  • Junior roles are gone: “Junior engineers that translate english into code don’t exist and technology experts that assemble into a full-stack team are gone.” Everyone is expected to “talk to customers and stakeholders, understand the impact of their work, own features from concept to production” — beginners own small domains, veterans critical ones; “in effect we all work like staff+ engineers.”
  • Accountability is the substrate: “you’re signing that thing with your phone number” — ship it and you run it. High agency + high accountability is what makes “ship first, ask questions later” survivable rather than chaos.
  • The tail-end economics: the biggest impact isn’t more top-line goals but “the tail-end, the bugs and features that a few years ago nobody would’ve prioritized” — operational efficiency work (goal: exponential users, linear bugs, logarithmic ops burden). And the bar moved: “What counts as an MVP in 2026 would’ve been a polished high production feature with a 6 month roadmap in 2020.”
  • Frustration-driven development as the institution: any repeatedly-answered question or repeated task → @cursor make me a tool; watching stakeholders work finds the friction.

Kin: What matters in AI world (traits this org prices: focus, review, ownership).