Colonel-turned-civilian James Okafor, now an agency chief data officer, had just finished a brutal year standing up his department's AI governance program. He had solved a hard problem alone, and then discovered, at a conference, that a peer two states over had solved the exact same problem eight months earlier and would happily have shared everything. They had simply never met. Multiply that by every AI leader in government quietly reinventing the same wheel in isolation, and you see the waste a real professional community exists to prevent. James's frustration is the founding emotion of every community of practice: we are all solving the same problems separately, and none of us should have to.

This lesson is about building that community deliberately: a durable network where government AI leaders share what works, mentor the people coming up behind them, and raise the standard of the whole field. We will treat it as a design problem, because a community that just happens rarely lasts, and we will use the challenge of connecting isolated practitioners like James as the thread throughout.

Why a Community, Not a Mailing List

Plenty of professions have email lists and annual conferences. Few have genuine communities. The difference is reciprocity and continuity: in a real community, members give as well as take, relationships persist between events, and newcomers are pulled in and grown rather than left to lurk. For government AI specifically, a community is not a nicety. The field is young, the lessons are expensive, and the people learning them are scattered across agencies and jurisdictions that rarely talk to each other in the ordinary course of work.

The economics are stark once you look at them directly. A government AI leader who works out how to structure a governance board, how to write an evaluation clause into a solicitation, or how to explain a model's limitations to a skeptical legislator has paid for that lesson with months of their own effort and, usually, at least one public mistake. In an isolated field, every leader pays that price separately. A working community turns thousands of isolated, costly individual lessons into shared, cheap collective knowledge. That is the entire value proposition, and everything else in this lesson is machinery for making it happen reliably.

It is worth naming why government makes this harder than it is elsewhere. Practitioners are distributed across agencies with different missions, different authorities and different legal postures. Some material genuinely cannot be shared. Attendance at anything is a budget question. And the professional incentive to publish, which drives knowledge sharing in academia and in parts of industry, mostly does not exist in a career civil service. A government community of practice has to supply its own motivation, which is why the design choices below are load-bearing rather than decorative.

The Five Building Blocks

A durable community of practice rests on five elements. Skip any one and it tends to wither, usually in a predictable way: without governance it drifts, without events it goes quiet, without content it becomes irrelevant between meetings, without mentorship it ages out, and without peer support it never converts an attendee into a member.

• Governance. Who decides things, how members join, what the norms are. Even loose communities need just enough structure to make decisions and resolve conflict.
• Events. The regular rhythm: gatherings that give the community a heartbeat and a reason to maintain relationships between them.
• Content contribution. The flow of shared knowledge, including playbooks, case studies and templates, that makes membership valuable on a Tuesday rather than only at the annual meeting.
• Mentorship networks. The deliberate pairing of experienced members with newcomers, which is how a community reproduces itself.
• Peer support. The everyday channels where a member can ask "has anyone dealt with this?" and get an honest answer fast.

The five interlock, and that is why partial versions disappoint. Events without a content library produce good conversations that leave no trace, so the same question gets asked again next quarter by someone who was not in the room. A content library without events produces a folder nobody opens, because people go looking for documents only after a person has told them the document exists. Mentorship without peer support leaves the newcomer dependent on a single relationship. Peer support without governance has nobody to intervene when the channel turns unhelpful. Build them together, thinly, rather than building one of them well.

Governance: Light but Real

The most common failure is too little structure, not too much. A community with no governance has no way to make decisions, set norms, or handle the inevitable conflict, so it drifts until it dies. The fix is the minimum viable governance: a small steering group, a clear and welcoming membership path, a short written code of conduct, and a transparent way to decide what the community does next. Norms are the real constitution of a community; write down the few that actually matter and leave the rest to develop on their own.

For a government AI community, three norms deserve to be explicit in the code of conduct. Members share lessons including failures, which is the norm that makes the community valuable and the one least likely to survive without being written. Members respect the confidentiality of sensitive agency details, which is the norm that makes participation safe enough for anyone to attempt the first. And members treat newcomers as future contributors rather than as an audience, which is the norm that determines whether the community exists in five years.

The membership path deserves more thought than it usually gets. A community that anyone can join without introduction fills with vendors and observers, and the practitioners go quiet. A community that requires an invitation from an existing member stays high-trust but excludes exactly the isolated newcomer it should be reaching, which is the James problem in a different form. A workable middle is an open application with a light sponsorship or verification step, plus a visible statement about who the community is for and, just as importantly, who it is not for.

Events That Create Relationships, Not Just Attendance

Events are the heartbeat, but attendance is not the goal, relationship is. A community whose only event is a once-a-year conference goes dormant for eleven months and rebuilds its relationships from scratch each time. A better rhythm layers cadences: a short monthly virtual session where one member presents a real problem and others help, a quarterly deeper workshop, and an annual in-person gathering that cements the relationships the virtual cadence keeps warm through the rest of the year.

The most valuable format is also the simplest: a member brings an unsolved, real problem, and the group works it. That is the exact moment James needed and never got, a standing place to say "here is what I am stuck on" and find the person who already solved it. Notice how much this format asks of the design. Someone has to recruit the presenter, since volunteering a live problem is exposing. Someone has to protect the norm that the session is for working the problem rather than for polished presentation. And the group has to be small enough that silence is uncomfortable.

Two practical rules make the rhythm survive. Keep the monthly session short and hold it on a fixed schedule that never moves, because a recurring commitment that shifts becomes a commitment nobody defends against other meetings. And accept low attendance at individual sessions without treating it as failure. A monthly call where a small share of the membership shows up, but a different share each time and each of them leaves with something, is functioning exactly as intended. Consistency of the slot matters far more than attendance at any given instance.

The annual gathering earns its cost by doing the one thing the virtual cadence cannot, which is producing the informal conversation in a hallway that turns an acquaintance into someone you will call. Design for that rather than for content. Fewer plenary sessions, more time in small groups working real problems, and deliberate introductions between people who should know each other. If your gathering's agenda could be delivered as a webinar without much loss, you have built an expensive webinar and the relationships you were paying for will not form.

Content That Makes Membership Worth It

A community is valuable between events only if knowledge keeps flowing. The aim is a growing shared library: redacted case studies of what agencies actually built, reusable templates and playbooks, and short write-ups of lessons learned. The hard part is not deciding what would be useful. It is getting busy people, whose employer does not reward them for it, to contribute anything at all.

Three moves address that directly. Make contributing easy, because a fifteen-minute template beats a demand for a white paper, and the person with the most useful experience is usually the person with the least spare time. Make it visible, crediting contributors prominently, because recognition is the currency professionals will work for when money is not on the table and their agency will not give them the hours. And seed it, with the founders contributing first and generously, so the norm of giving is established before anyone is asked to follow it.

Redaction is worth treating as a first-class part of the pipeline rather than an afterthought. The single most useful artifact in a government AI community is a case study of something that went badly, and that is also the artifact most likely to be blocked by an agency's communications office or counsel. Making it routine to publish a version with agency identifiers, vendor names and specific figures removed lowers the barrier enormously. A contributor who knows a safe form exists, and knows the community will help them produce it, is far more likely to offer the story at all.

Curation matters as much as volume once the library starts to fill. A large folder with no ordering is functionally empty to a newcomer, who has no way to tell which few items are worth an hour. Someone has to keep a short, opinionated front page saying what to read first and why, and to retire material that has gone stale. This is a small recurring job, it is nobody's favorite, and it is the difference between a library that gets used and a graveyard of good intentions. Assign it explicitly and rotate it like any other role.

Mentorship and Peer Support: How a Community Reproduces

A community that does not grow its newcomers eventually ages out. Mentorship is the mechanism. A simple structured program, pairing an experienced government AI leader with someone earlier in the journey, with a light framework of suggested topics and a recommended cadence, does two things at once: it accelerates the newcomer and it gives the mentor a stake in the community's future. The structure matters more than it seems. Unstructured mentorship pairs meet twice, run out of agenda, and quietly stop, and both people conclude they are bad at mentoring rather than that the design was thin.

Pair mentorship with always-on peer support: a channel where a member can post a real question and reasonably expect a real answer within a day. That responsiveness is what converts a passive member into an active one. The first time someone gets unstuck because a peer answered fast, they are a member for life, and the second time they are usually the one answering. Protecting that response time is a founder's job in the early months, because a channel where questions go unanswered teaches everyone watching that asking is pointless, and that lesson is very hard to unteach.

Onboarding the Newcomer

The gap between joining a community and belonging to it is where most members are lost, and it is almost never closed by the newcomer's own initiative. Someone who has just joined does not know which questions are welcome, whether the channel is for beginners, who the people answering actually are, or whether the shared folder is worth reading. Left alone with those uncertainties, the rational move is to lurk, and a lurker gradually stops opening the channel at all. The community never learns it lost them, because the membership count does not move.

Closing that gap takes deliberate work by someone whose job it is. A short introduction from an existing member, a pointer to the two or three artifacts in the library that are most worth reading first, and a nudge to post one question, however small, in the first week or two. The point of the first question is not the answer. It is to establish that asking is normal and that answers arrive, which is the belief that determines whether the member ever asks a second time. James's own frustration is instructive here. He was not excluded from anything. He simply never had a reason to believe that a group of strangers would help him, and nobody gave him one.

Onboarding also has a governance function that is easy to miss. It is the moment when the norms are actually transmitted, far more effectively than by a document nobody reads at signup. A member who is told in their first week that this community shares failures, protects agency detail, and expects them eventually to contribute has been given a role rather than a subscription. That framing is the difference between a community that grows and one that accumulates names.

What a Peer's Answer Is and Is Not

This is the point in the design where a government community differs sharply from a professional community anywhere else, and it is worth stating plainly to members rather than assuming they will infer it. A peer's answer is evidence. It is not authorization, and it is not a legal opinion. "Another agency structured their governance board this way" tells you a workable structure exists and someone survived building it. It tells you nothing about whether your authorities, your appropriations, your records obligations or your general counsel permit the same thing in your agency.

The failure mode is subtle because it feels like diligence. A member asks the community, gets three consistent answers from experienced practitioners, and proceeds feeling they have done their homework. What they have actually done is gather useful precedent. The decision, and the accountability for it, still sits entirely with their own agency, and the people who have to sign it off, counsel, the privacy official, the records officer, the authorizing official, have not been consulted. Consultation with peers informs a decision your agency still owns.

Build this into the norms rather than leaving it to individual judgment. Encourage answers that name the jurisdiction and authority they rest on, so that the reader can see what would have to be true for the answer to transfer. Encourage the phrase "check this with your own counsel" as a routine courtesy rather than a defensive disclaimer. And keep the confidentiality norm tight in the same breath, because the same channel that makes it easy to share a useful precedent makes it easy to share a detail that should not have left the building.

Sustaining It Past the Founders

Communities built on the energy of one or two founders collapse when those people burn out, and in government they also collapse when those people are reassigned, promoted out of the domain, or caught by a change of administration. Designing for durability means three things from the start, not as a later maturity phase.

• Distribute the work. Rotate event hosting, content curation and onboarding across many members so that no one is indispensable and burnout does not become collapse.
• Grow leaders deliberately. Identify active members and pull them into running things, so that leadership renews itself rather than depending on the founders forever.
• Measure the right health signals. Track active contributors, newcomer retention and questions answered, not just total headcount. A community of 2,000 names where forty people do everything is fragile; a community of 300 where a third contribute is alive.

That last comparison is the one to argue with your sponsors about, because headcount is the number they will ask for. The larger community in the example has many times the members and a tiny fraction of the participation, and it will feel healthy right up until the forty active people get busy. The smaller one has roughly a hundred people doing the work of the community, a figure that follows from a third of three hundred, which means it can lose several without noticing. When you report on the community, lead with contributors and retention and put headcount last, or headcount will quietly become the goal you optimize for.

Rotation is harder in practice than it sounds, because handing a job to someone who will do it less well than you is genuinely worse in the short run. Accept that. The founder who insists on the quality of every session is optimizing the wrong variable, since a community that runs at a slightly lower standard across five different hosts is far more likely to exist in three years than one that runs beautifully under a single host who eventually stops. Hand over the smallest job first, hosting one monthly session, and hand over the next one before the first handover feels comfortable.

Starting Absurdly Small

When James helped charter a community of practice for AI leaders across his region, he started absurdly small: a monthly call where someone brought a real problem, a shared folder of templates seeded with his own governance playbook, and a code of conduct fitting on one page. There was no platform decision, no branding exercise and no membership drive, all of which are the things founders reach for first and which reliably consume the energy the community needs for its first year of actual practice.

Within a year, a new chief data officer in a neighboring agency stood up a governance program in a fraction of the time it had taken James, because she started from his playbook and a mentor's phone number instead of from scratch. That single transfer paid for the whole community. It is also the right thing to measure and report: not how many people joined, but how many times someone's hard-won lesson became someone else's starting point.

A community-design starter kit

• Governance. A small steering group, a welcoming membership path with a light verification step, and a one-page code of conduct covering sharing failures, confidentiality of agency detail, and welcoming newcomers.
• Event rhythm. A short monthly problem-solving call on a fixed slot that never moves, a quarterly workshop, and an annual in-person gathering.
• Content library. Easy-to-contribute templates and redacted case studies, with a routine redaction path, contributors visibly credited, and founders seeding first.
• Mentorship program. Structured pairings with suggested topics and a recommended cadence, so pairs do not run out of agenda and quit.
• Peer-support channel. An always-on place to ask real questions and get answers within a day, with founders protecting the response time early.
• A stated norm on authority. Peer precedent informs decisions your agency still owns; answers name their jurisdiction, and "check with your own counsel" is routine.
• Sustainability plan. Rotated responsibilities, deliberately grown leaders, and health metrics that count contributors and retention rather than raw headcount.

Anti-Patterns

• The mailing list that calls itself a community. Broadcast is not reciprocity. A channel where the organizers post and everyone else receives will show healthy subscriber numbers and produce almost none of the value described here, because no lesson ever travels from a member to a member. The diagnostic is simple: in the last month, how many messages came from someone other than an organizer, and how many of those were answered?
• Headcount as the health metric. Membership totals are the easiest number to grow and the least informative one to hold. They rise when you run a recruitment push and never fall when people disengage, which makes them a ratchet that always points up regardless of what is happening. Report active contributors, newcomer retention and questions answered instead, and expect to have to defend that choice to whoever funds you.
• Treating a peer answer as clearance. Three experienced practitioners agreeing that an approach worked in their agencies is genuinely valuable and is not permission. Authorities, appropriations, records obligations and legal posture differ, and the accountability for the decision never leaves your agency. A community that does not say this out loud will eventually produce a member who cites the community as their justification, which helps nobody.
• The community as a back channel for sensitive detail. The same informality that makes peer support fast makes it easy to paste something that should not have left the building: an unreleased evaluation result, a vendor's confidential pricing, a detail about a specific case. Write the confidentiality norm down, build a routine redaction path so the safe version is the easy version, and moderate for it deliberately rather than trusting good intentions.
• Founder dependence disguised as founder commitment. A founder who hosts every session, curates every artifact and onboards every newcomer is not demonstrating dedication, they are creating a single point of failure and, incidentally, blocking anyone else from developing the standing to take over. Rotate roles while the community is small enough that a handover is low-stakes, not after the founder is exhausted.
• Success-only sharing. A library of case studies in which every project went well is worse than an empty one, because it is actively misleading about what this work is like and it quietly signals that admitting a failure here is unsafe. The failures are the expensive lessons and therefore the valuable ones. If nobody has contributed a failure, the founders should go first, publicly, with one of their own.

Practice Prompts

• Map your own isolation. List the three hardest problems you solved in the last year. For each, write down who else in government almost certainly faced the same problem, and whether you had any way of finding them at the time. That list is both the case for a community and the recruiting list for one.
• Draft the one-page code of conduct. Write it now, before you have members, covering sharing failures, confidentiality of agency detail, and treating newcomers as future contributors. Keep it to a page. Then ask two people who are not in your field to read it and tell you what it actually forbids.
• Design the monthly session. Specify the slot, the length, the format, who recruits the presenter, and what the group is explicitly not for. Then schedule the first three and recruit the first presenter yourself, because the first one will be the hardest and it should not fall to someone with less standing than you.
• Seed the library before you open it. Contribute two artifacts of your own, one template and one honest account of something that did not work. Redact them as if they were someone else's. Note how long the redaction took, because that time is the barrier every future contributor will face.
• Write the authority norm in your own words. Draft the two or three sentences you would post when a member asks whether they can do what another agency did. Aim for something that is genuinely helpful about the precedent and unambiguous about who owns the decision, and that does not read as a legal disclaimer nobody finishes.
• Pick your health metrics and set a baseline. Choose active contributors, newcomer retention and questions answered within a day. Define each one precisely enough that a successor could compute it the same way, record the starting values, and put the review on the calendar for six months out.

Reflection

Think about the last hard problem you solved at work, and about how you solved it. How much of your approach came from a document, how much from a vendor, and how much from a person you happened to know? For most government AI leaders the honest answer is that the decisive input came from a person, and that whether they had access to that person was largely accidental. A community is an attempt to make that access deliberate rather than lucky. Ask yourself who is currently outside your accidental network and would benefit most from being inside it.

Then ask the harder question about your own contribution. Most people in this field consume more from their informal networks than they return, not out of selfishness but because contributing is unrewarded work that competes with a full job. What would have to change for you to give as much as you take? A lower bar for what counts as a contribution? Visible credit? Permission from your own leadership? Whatever your answer is, it is almost certainly the same answer for everyone else you are trying to recruit, which makes it the first thing your community should be designed around.

Glossary

• Community of practice. A durable network of practitioners in a shared domain who exchange knowledge, develop each other and raise the standard of the field, distinguished from a distribution list by reciprocity and continuity.
• Reciprocity. The norm that members give as well as take, without which a community becomes a broadcast channel with an engaged organizer and a passive audience.
• Code of conduct. The short written statement of a community's binding norms, covering what members share, what they protect, and how they treat newcomers.
• Peer support channel. An always-on place where a member can post a real problem and expect a substantive answer quickly, and the mechanism that most reliably converts a passive member into an active one.
• Redaction path. A routine, supported process for stripping agency identifiers, vendor names and sensitive figures from a case study so that the shareable version is easy rather than exceptional.
• Structured mentorship. Deliberate pairing of an experienced practitioner with a newer one, supported by suggested topics and a recommended cadence so that pairs do not stall once the initial agenda is exhausted.
• Active contributor. A member who has given something to the community in a defined recent period, used as a health metric in preference to total membership.
• Founder dependence. The condition in which a community's operation rests on one or two people, producing collapse when those people burn out, move on or are reassigned.

Related Lessons

• Defining the Profession of Government AI Leadership sets out what this community is a community of, which is the question a code of conduct and a membership path both depend on.
• Mentoring Next-Generation Leaders goes much deeper on the mentorship element sketched here, including how to structure pairings so they last.
• Building Institutional Knowledge covers the same knowledge-loss problem inside a single agency, and its artifacts are exactly what a community library should be full of.
• Academic and Research Collaboration addresses partnerships with universities and research organizations, which extend a practitioner community's reach and technical depth.
• Cross-Agency AI Coordination deals with the formal interagency mechanisms that sit alongside an informal community and often benefit from one existing.
• Communicating AI Success Stories is useful for the content pipeline, particularly the problem of getting a compelling account past a communications office.

Closing

The case for a professional community in government AI is not sentimental. It is that this field is young enough that most of its knowledge exists only in the heads of people who learned it the hard way, and scattered enough that those people mostly cannot find each other. Every month that stays true, another James spends a year solving a problem that someone two states over already solved. The waste is not dramatic and nobody reports it, which is exactly why it persists.

What makes a community work is unglamorous and mostly consists of showing up: the fixed monthly slot, the answered question, the template someone bothered to upload, the newcomer someone bothered to introduce. None of it requires a platform decision or a budget line to begin. It requires a few people who decide that the isolation is not acceptable and who are willing to give first, before there is any evidence that giving will be reciprocated. That is the founding act, and everything in this lesson is just a way of making it survive the founders.

Key Takeaways

• Communities prevent expensive isolation. Government AI leaders scattered across agencies relearn the same costly lessons alone; a real community makes one person's hard-won lesson everyone's starting point.
• Reciprocity and continuity define it. A mailing list broadcasts; a community gives in both directions, persists between events, and grows newcomers into contributors.
• Govern lightly but really. The common failure is too little structure. A small steering group, a membership path and a one-page code of conduct give a community the means to decide, set norms and handle conflict.
• Design events for relationships. Layer monthly, quarterly and annual cadences around real-problem sessions, hold the monthly slot fixed, and judge it by whether people leave with something rather than by attendance.
• Make contributing easy and visible. A fifteen-minute template beats a white paper, recognition is the currency that motivates busy professionals, founders must seed the giving norm first, and a routine redaction path unlocks the most valuable artifacts.
• Mentorship is how a community reproduces. Structured pairings accelerate newcomers and give mentors a stake in the future, while fast peer support converts passive members into active ones.
• A peer's answer is evidence, not authorization. Precedent from another agency informs a decision your own agency still owns, and the norm should say so explicitly rather than leaving it to individual judgment.
• Build to outlast the founders. Rotate responsibilities early, grow new leaders deliberately, and measure active contributors and retention rather than raw headcount.

Frequently Asked Questions

How small can a community be and still work? Small enough that the monthly problem-solving session has an uncomfortable silence when nobody speaks, which is a feature rather than a defect. The example in this lesson began with a monthly call, a shared folder and a one-page code of conduct, and its first measurable success was a single knowledge transfer to one neighboring agency. Size is not the constraint. What a community needs at the start is a fixed rhythm, someone willing to contribute before anyone else does, and enough members that a question posted has somebody who can answer it.

How do we handle the fact that some of our work cannot be shared? Treat it as a design constraint rather than a reason not to try. Write the confidentiality norm into the code of conduct so members know the boundary before they are tempted to cross it, and build a routine redaction path so that producing a shareable version of a case study is normal work rather than a special favor. The genuinely unshareable material is usually a smaller fraction than people assume. Most of what makes a case study useful is the structure of the problem and the reasoning, not the identifying detail.

Should vendors be members? That is a governance decision, and the important thing is to make it explicitly and state it publicly rather than letting it resolve itself. An open community with no membership step tends to fill with vendors and observers, and the practitioners go quiet, which destroys the peer support that is the community's main asset. Whatever you decide, be clear in your public description about who the community is for, and give members a way to raise it when the balance starts to shift.

What do we do when the founders move on? Ideally nothing, because you rotated hosting, curation and onboarding long before it became urgent. If you did not, the recovery is to name a successor group rather than a successor individual, hand over the operational jobs separately, and accept a quiet period while the new people find their footing. The signal to watch is whether questions still get answered within a day. If that holds through the handover, the community survived it.

Our leadership wants to know the return on this. What do we tell them? Tell them the story of a transfer. The most persuasive evidence is a specific instance of one member's work saving another member substantial time or preventing a specific mistake, described concretely with both parties named. Aggregate participation metrics are worth reporting as a health check, but they do not persuade anyone who is not already convinced. Keep a running record of transfers as they happen, because reconstructing them later is difficult and they are exactly what you will be asked for.