Knowledge Sharing

Knowledge Sharing

Before Starting

Check for EM context first. If .agents/em-context.md exists, read it.

If .agents/em-context.md does not exist, ask for a minimal manager profile first and save it before giving detailed advice: role/title, team size, team mission or ownership area, and current challenge or priority.

If a specific person is central to the conversation and .agents/reports/[name].md does not exist, ask for a minimal profile for that person first and save it before giving detailed advice: title/level, tenure, strengths, and current challenge or growth area.

If the conversation reveals durable new context later, update .agents/em-context.md or .agents/reports/[name].md automatically. Save stable facts and patterns, not guesses, transient frustration, or unresolved interpretations.

Response Style

Keep the first answer concise and useful. Do not dump the whole framework unless the user asks for depth.

Default to:

• State the likely diagnosis or recommendation first
• Ask at most 2-3 targeted questions only if the missing context changes the advice
• Give the next concrete action and, when useful, exact wording the manager can use
• Mention the relevant framework briefly, but do not explain every part of it
• Offer a deeper version only after the direct answer

---

How to Use This Skill

• Teams are building things others already built / knowledge stays within teams → No Horizontal Information Flow (Guilds)
• Documentation is absent, stale, or ignored → Ineffective Knowledge Sharing (ADRs)
• New hires take too long to ramp up → Poor Onboarding
• Teams protect information or compete rather than collaborate → "Us vs. Them" Thinking
• Cross-team request is sitting in limbo → The 3 Paths for Cross-Team Requests

---

Default Response Shape

When helping with knowledge sharing, diagnose the flow problem before prescribing documentation:

1. Primary silo cause: horizontal flow, documentation, onboarding, or us-vs-them.
2. Evidence: what behavior shows the knowledge is not moving.
3. Smallest useful mechanism: guild, ADR, onboarding buddy, rotation, office hours, or request path.
4. Owner and cadence: who maintains the mechanism and how often it runs.
5. Failure mode: how this could become stale bureaucracy and how to prevent it.

Prefer lightweight mechanisms that create repeated behavior over large documentation projects.

---

Why Silos Form

In many organizations, 45% of developers report that knowledge silos negatively impact their productivity multiple times a week. They spend time building something that another team already built. They can't find information that exists somewhere. They don't know who to ask.

There are 4 root causes — and each has a different fix.

---

1. No Horizontal Information Flow

Traditional hierarchies move information up and down, not sideways. Knowledge stays locked within teams.

The fix: Engineering Guilds (also called Chapters) — cross-team groups organized around a domain (frontend guild, ML guild, platform guild, etc.).

What makes guilds work vs. fail: guilds fail when they're informal gatherings with no allocated time and no real output. Engineers vent, agree "something should be done," then return to their team backlogs. To work, guilds need three things:

1. Strategic alignment — guild projects must tie to company goals, not just engineering preferences
2. Official recognition — leadership acknowledges the guild and gives members time to participate
3. Member freedom — engineers choose what to work on based on their interests and career goals

A lighter version if guilds aren't feasible: dedicated Slack channels by tech domain. Encourage questions, cross-team problem-solving, and sharing solutions there.

---

2. Ineffective Knowledge Sharing

Without a documentation culture, knowledge lives in people's heads, in Slack threads, in undiscoverable emails. When those people leave or are unavailable, the knowledge disappears.

The fix: Minimum Viable Documentation + ADRs

Documentation fails for two reasons:

• It becomes obsolete quickly and nobody reads it anyway
• Writing it is tedious, so nobody does it consistently

The principle: don't document everything — document what people actually need to do their jobs. Focus on:

• The reasoning behind critical decisions (why, not just what)
• Fundamental architectural principles and protocols
• Agreed-upon patterns and approved third-party packages

Architecture Decision Records (ADRs) are the best practical implementation. Stored directly in the codebase, with a shared template, they capture: the decision, the context, the alternatives considered, and who to contact. Developers always know where to look and why things are the way they are.

Standardized templates are the key to documentation actually getting written — engineers don't have to think about format, just fill in the blanks.

---