Knowledge Sharing and Team Enablement Questions

Direct answer

A community of practice (also called a guild) is a voluntary group of people from different teams who share a craft or problem area, such as reliability, data modelling or testing, and meet regularly to learn from one another and improve shared practice. Teams deliver work, documents record decisions, and a community of practice spreads and refines how people do the work across teams. I would start one when several teams face the same problem, nobody owns it, and the knowledge is tacit (in people's heads), not something a document alone can carry.

What it typically looks like

• Purpose: share patterns, avoid duplicated solutions, raise the bar on a skill, and give practitioners a peer group beyond their own team.
• Membership: voluntary and open to anyone with the interest, with a few champions (enthusiastic volunteers who organise the meetings and keep it going).
• Cadence: about monthly for 45 to 60 minutes, plus an asynchronous chat channel for the time in between.
• Activities: show-and-tell of real problems, reviews of shared patterns, agreeing a recommended approach.
• Authority: advisory. It proposes and recommends but does not approve or block work.

Compared with the alternatives

When to start one, with an example

Tacit versus writable: the API endpoint list is writable and belongs in a document. Knowing which retry settings actually worked during the last outage is tacit, learned by doing.

Four backend teams each wrote their own retry-and-timeout logic for calling other services, and outages followed from four different mistakes. No team owns "service calls". A guild would let the four teams compare approaches monthly and agree on one recommended pattern. A data equivalent: analysts on five teams each compute "active customer" slightly differently, and a data guild compares definitions and recommends one.

When not to

• A single team could own the problem, so give it to them.
• A one-time decision or checklist would do, so write a document.
• You need enforcement or a binding standard. Use a platform team (a team that owns shared tools and standards for other teams and can require them) or an architecture review (a scheduled meeting where designated senior engineers approve or reject significant designs), since a guild cannot mandate anything.
• No one is willing to champion it. Without a couple of committed organisers it fades in a few months.

Pitfalls

It can become a talking shop with no output, so ask each session to end with one concrete action.

Direct answer

I treat continuous learning as a system of small, protected habits with owners, not a slogan. I would protect a fixed learning slot, make learning visible in the way the team does work (reviews, rotations, mentoring), remove the obstacles (budget, permission, access), and model it myself. To tell whether it is real rather than a poster, I track evidence that learning changes work: who teaches, what practices changed, and whether knowledge is spread across more people. I do not treat attendance as proof.

Initiatives I would start (pick a few, not all)

• Protected time. A fixed weekly slot (say, two hours) that is defended when deadlines press.
• Mentorship and pairing. Each person has a learning partner outside their day-to-day area.
• Rotations. Short, focused moves (a few weeks) onto another system or onto on-call (being the person responsible for fixing a system when it breaks, including out of hours; for analysts or scientists, the equivalent is owning the fixes for a pipeline or dashboard) so knowledge spreads. For a stable but stagnant team, this plus peer review of each other's work is the fastest way to break routine.
• Brown-bags. Informal lunchtime talks, given by team members, not by managers.
• Guilds. Cross-team interest groups (a guild or lunch-and-learn series) for topics several teams share.
• Learning budget and a learning repository. Money for courses and books, and one place where talk notes and recordings live.
• Modelling. I share what I am learning and what failed.

What I track (vanity versus real signal)

A vanity measure counts activity and looks good whether or not anything changed. A leading indicator moves early and predicts that real change is coming (for example, practices adopted before quality improves).

Worked example (a stable but stagnant team of 8)

Setup (illustrative numbers): 5 systems, and today 2 of them have only one person able to run on-call. "Capable" here means the person has shadowed one on-call shift and has resolved a drill or real incident using the runbook (a step-by-step operating guide). In the first 90 days: start a weekly slot, pair each of those two experts with a learner, add one-week rotations, and require a second reviewer from a different sub-area on changes.

Measure at day 90: systems with fewer than two capable people should go from 2 to 0 (the metric is "capable people per system", which is a knowledge-spreading measure). Also count practices adopted, such as one new testing habit or one runbook rewritten by someone who learned it. Reading a result: suppose at day 90 the count is 1 instead of 0. Progress happened (one of the two single-person systems now has a second capable person), but the other is still a risk, so I would keep that pairing going, not declare success. If attendance is high but capable-people-per-system and adopted practices do not move, it was a poster.

Trade-offs and pitfalls

• Mandatory learning becomes box-ticking. Voluntary learning is skipped when deadlines hit unless time is protected.
• Measure with care: any number you reward will be gamed (counting talks encourages trivial talks).
• If the culture punishes visible ignorance, no initiative works. Fix psychological safety first (people feeling safe to admit they do not know something or made a mistake without being mocked or penalised).

Direct answer

I would launch small around a real, shared pain, govern it with a one-page charter and advisory authority, and hold it accountable for outputs instead of meetings. To prevent a talking shop, every session ends with a logged action and the group tracks reuse. To prevent bureaucracy, it has no approval power, minimal process, and a sunset rule. Lastly, I would decide up front when to retire it.

Launch (first 60 to 90 days)

• Find the pain first. Ask team leads what they rebuilt or re-debugged in the last quarter. Pick the top two themes, for example retry patterns (how code waits and tries again when a call to another service fails) and incident learnings.
• Recruit three to five champions (volunteers who organise it) across teams, plus one senior sponsor (a senior leader who removes blockers and gives people time, but does not run it).
• A one-page charter (a short founding document): purpose, non-goals, who can join, cadence, how decisions are made, how it ends. A sample: Purpose: cut duplicated retry code across teams. Non-goals: we do not approve or block anyone's design. Who: any engineer, five champions. Cadence: monthly, 45 minutes. Decisions: recommendation by consensus, facilitator breaks ties. Ends: reviewed after two quarters; closed under the sunset rule below (no new shared asset for two consecutive quarters and fewer than 5 regulars), or merged into a platform team.
• Cadence: monthly 45-minute session plus an asynchronous channel. Early sessions solve a real problem brought by a team. A first-session agenda: 5 minutes on the charter, 25 minutes where one team presents its retry problem and the room compares approaches, 10 minutes to agree one action and owner ("Team B drafts a one-page pattern by next month"), 5 minutes to pick next month's problem.

Governance without bureaucracy

• Decision rights: advisory. It recommends a pattern, teams choose, but they explain deviations.
• Rotating facilitator each month, so it is not one person's job.
• Shared assets (runbooks, meaning step-by-step operating guides; postmortems, meaning written reviews of incidents; pattern write-ups, a shared library) each have a named owner and a lightweight review: two members read before publishing. No committee approval.
• Only for teams sharing code: a shared library gets an owner, a contribution guide and a changelog (a dated list of what changed in each version), so reuse is safer than copying.
• Only if members include AI teams (skip otherwise): add a track for model risk (ways the model could cause harm or wrong decisions) and reliability: evaluation results (test scores on held-out examples), drift (the model's inputs or performance changing over time), fallback behaviour when the model is wrong or unavailable.

Keeping it useful, not a talking shop

What I would track (worked example)

Suppose today 3 teams maintain separate retry code. Target after two quarters: 1 shared library adopted by at least 3 teams, with 2 postmortem write-ups reused as runbook changes. The measure is distinct duplicate implementations (3 down to 1), assets reused, and the share of members who contributed anything, not attendance.

When to retire it

Sunset rule agreed in the charter: if for two consecutive quarters no new shared asset is produced and attendance falls below a floor the members set (for example, fewer than 5 regulars), either merge it into a platform team (a team that owns shared tools and standards for others) that can own the work or close it. Closing a group is a success if the practice is now embedded.

What would change my call

If people need binding standards, I would use an architecture review (a meeting where designated seniors approve significant designs) or a platform team, not a guild.

Direct answer

A shared library, pattern or contract (an agreed interface, such as an API shape or data schema, that teams code against) only pays off if other teams use it. First find out why teams are not adopting, because "no adoption" has several different causes and each needs a different fix. Then make the shared thing easy to try, easy to migrate to, and clearly worth it, using templates, migration automation, hands-on help and a couple of champion teams, and measure adoption and time to first working integration.

Step 1: diagnose (a week)

Interview four to six non-adopting teams: Did they know it exists? Does it fit their needs? Do they trust it (support, stability)? Is migration too costly? Is there no reason to change? Findings split into awareness, fit, trust, cost and incentive. If you cannot interview anyone yet, start with the cheapest fix that helps most causes: a quick-start template plus a short announcement in the channels teams already read, then interview the first teams that try it and stall.

Step 2: enablement matched to the cause

Mapping: awareness -> announcement, demo, champions; fit -> fix the library or document supported use cases; trust -> support commitment, versioning policy, champion results; cost -> template, codemod, pairing; incentive -> paved road, deprecation date, team goals.

• Quick-start template: a working example integrating in under half an hour, so trying it costs little.
• Migration automation: a codemod (a script that rewrites code automatically) or a bot that opens the migration pull requests for teams, plus a lint rule (an automated check that flags the old pattern) so new code uses the shared one. For example, the codemod rewrites http.get(url, retries=3) to shared_client.get(url) (this is safe only because the shared client retries three times by default; if it did not, the codemod would have to carry the setting across as an argument, or teams would silently lose their retries), and the lint rule says "use shared_client instead of raw http calls" when someone writes the old form.
• Coaching: a workshop, office hours, and pairing on the first integration.
• Champions: start with one or two friendly teams, publish their results, then expand.
• Incentives: make it the easiest path (the paved road: the supported, pre-built route that needs the least effort), align with each team's own goals, and set a deprecation date (a published date after which the old approach is no longer supported or maintained) rather than mandating first. Champions are early-adopter teams or individuals who vouch for it to their peers.

Step 3: what to measure

Worked example (illustrative): 12 eligible teams, 3 adopted, so adoption is 3/12 = 25 percent. After the template, codemod and two champions, suppose 9 have adopted: 9/12 = 75 percent, and median time to first integration falls from weeks to days. Confirm the direction with real data, not the numbers here.

For a newly formed team joining the shared standards (90 days)

This is the same enablement idea applied to one team arriving fresh: onboarding here means the time from the team's start until it works to the standard without help. Days 1 to 30: training and a mentor; days 31 to 60: first deliverable using the standards with review; days 61 to 90: they own a small improvement. Measure onboarding time and satisfaction the same way.

Pitfalls

• Counting installs as adoption. Count teams actively using the current version.
• Mandating without fixing the friction, which breeds workarounds.
• Ignoring maintainability: adoption without support collapses trust.

Direct answer

Pitch it as a business problem with a measured baseline (opening line, for example: "We lose about 60 senior-engineer hours a month to escalations; a $22,000 pilot aims to recover a third of that, and I will show you the result at 90 days"), not as "training is good". Claim a modest, defensible return tied to a metric executives already track, state the assumptions, and make a specific ask: an amount, protected time, a named sponsor, a decision date, and a pilot with stop criteria.

Structured elaboration

1. Frame. One sentence of problem in business terms ("senior engineers spend a large share of their week answering escalations from newer engineers, and on-call recovery is slow"), backed by evidence you can show: incident counts, escalation counts, onboarding time.

2. Objectives and outcomes. Two or three measurable objectives, such as reduced MTTR (mean time to restore service, the average time from detection to recovery) and fewer escalations to senior staff.

3. The return claim. Say how you will measure it, and claim a range rather than a promise. Convert the effect into time or money using stated assumptions.

4. The ask and line items. Money (materials, sandbox environments, external courses), resourcing (instructor hours), and protected participant time. Give a pilot size and a decision point.

5. Risks. Attribution (other causes may improve things), knowledge decay, attendance under delivery pressure, and what you do if the pilot misses.

Worked example

Baseline: 30 escalations a month, each taking about 2 hours of a senior engineer. Target: cut escalations by one third, so 10 fewer a month, saving 10 x 2 = 20 hours a month, or 240 hours a year. Assumption (illustrative): a loaded cost (salary plus overhead such as benefits and equipment, not just pay) of $100 an hour, so about $24,000 a year in senior time recovered. Cost: 10 engineers x 16 hours of training = 160 hours = $16,000 of time, plus $6,000 for materials and a sandbox, total $22,000. On this single measure it roughly breaks even in year one, so I would say exactly that, then note that the same programme aims to lower MTTR, which I did not price because I lack the baseline. The ask: approve a $22,000 pilot for one team for two quarters, with a review at 90 days and a stop if escalations have not fallen from 30 to 24 or fewer a month (at least a 20 percent cut) by then.

Attribution example (illustrative): compare with a similar team that did not train. The pilot team falls from 30 to 21 escalations a month, the comparison team from 30 to 28. The comparison team's 2-point drop is what happens anyway, so about 9 - 2 = 7 escalations a month of the pilot's improvement is credibly due to training. Claiming all 9 would overstate it.

Trade-offs & pitfalls

• Inflated return on investment (ROI) figures get challenged and ruin credibility. Show the arithmetic and assumptions.
• Vague asks ("support for learning") are easy to defer. Ask for a number, a date and a decision.
• No baseline means no proof later. Capture it before the pilot starts.
• Pitching features (courses) instead of outcomes. Executives fund results.