Most organizations treat prompt engineering as something individuals pick up on their own — a video here, a cheat sheet there. It's the same mistake companies made with spreadsheets in the 1990s: assuming a skill will spread through the organization by osmosis, one curious employee at a time.
It doesn't spread that way. What spreads instead is inconsistency. One person gets useful, structured output from the exact same tool the person next to them is using. That second person gets vague summaries, tries twice, and quietly gives up. Both are using the "same" AI assistant. Neither one knows why their results are so different — and because nobody's ever compared notes, nobody finds out.
The skill nobody's teaching
Individually, prompt engineering usually means: know a few tricks, iterate by trial and error, keep what works in a personal notes file nobody else sees. That's a hobby, not a capability — genuinely useful to the one person who built it, and worth nothing to the rest of the team the day that person changes roles or leaves.
Treated as a team skill, it means something different:
- Shared prompt patterns for recurring tasks — the team's actual weekly report, not a generic example pulled from a tutorial. A pattern that works for one person's version of the weekly summary works, with minor tweaks, for everyone else writing a version of the same document.
- A common vocabulary for describing what went wrong when output is bad, so feedback is specific instead of "this isn't very good." "It's missing the context about last quarter's numbers" is fixable. "This isn't very good" isn't.
- Review, the same way code gets reviewed. A prompt that produces inconsistent results on real inputs is a bug, not a personal quirk — and like any other bug, it's worth someone else looking at it rather than the original author quietly working around it alone.
Why this compounds
When one person gets better at prompting, you get one better set of outputs, for as long as that person is the one doing the task. When a team gets better together, the good patterns spread immediately — because they're written down, shared, and refined by more than one person's trial and error, rather than sitting in one inbox.
We've watched this play out inside client teams directly: two people doing the same job, one producing usable first drafts every time and one requiring three redos every time, and the entire difference was that nobody had ever compared notes. Once they did — a twenty-minute conversation, not a training program — the gap closed almost immediately, because it was never a skill gap in the first place. It was a knowledge-sharing gap that happened to be about AI.
What actually goes wrong without this
The visible symptom is inconsistent output quality across a team doing ostensibly the same work. The less visible symptom, and the more expensive one, is that the organization can't tell whether its AI investment is working at all — because "it depends who's using it" is not a measurable outcome. A tool with wildly variable results, person to person, looks like a tool that doesn't work reliably, even when the actual capability was there the whole time, unevenly distributed.
What this looks like in practice
It isn't a policy document, and it doesn't need executive sponsorship to start. It's closer to a shared, living reference: three or four solid prompt patterns for the tasks your team actually repeats, updated whenever someone finds something that works better, reviewed the way you'd review any other piece of internal tooling — a short standing agenda item, not a new committee.
That's a two-hour conversation to set up, and it outperforms months of individual trial and error, precisely because it stops each person from independently re-discovering the same lessons the person next to them already learned and never mentioned.
If your team's AI output still varies wildly from person to person, that's not an AI skills gap. It's a knowledge-sharing gap that happens to be about AI — and it's fixable a lot faster than a skills gap would be.