Knowledge Sharing #

In a growing engineering team, there’s a danger invisible in the codebase and monitoring dashboards: knowledge locked inside one person’s head. When that engineer is on leave, resigns, or simply unreachable, the team suddenly can’t make decisions that should be routine. This isn’t just an operational problem — it’s a Single Point of Failure at the human level. The Knowledge Sharing Session (KSS) is the simplest and most cost-effective mechanism for solving it: turning knowledge locked in individuals into a collective team asset.

What Is a Knowledge Sharing Session? #

A Knowledge Sharing Session is a structured forum — formal or informal — where an engineer or team shares knowledge, learnings, or experience with other organization members. The goal is converting tacit knowledge (knowledge in someone’s head) into explicit knowledge (knowledge others can access, learn, and use).

A KSS differs from training or onboarding in one important way: it runs two-way. The presenter shares, the audience responds, and the greatest value often emerges from the discussion after the presentation — not from the slides themselves.

flowchart LR
    subgraph BeforeKSS
        A1["Engineer A\nknows query optimization"]
        B1["Engineer B\ndoesn't know"]
        C1["Engineer C\ndoesn't know"]
        D1["Engineer D\ndoesn't know"]
    end

    subgraph AfterKSS
        A2[Engineer A]
        B2[Engineer B]
        C2[Engineer C]
        D2[Engineer D]
        K["Knowledge about\nquery optimization"]
        K --- A2
        K --- B2
        K --- C2
        K --- D2
    end

    BeforeKSS --> |"Knowledge Sharing Session"| AfterKSS

KSS formats can vary widely, and don’t always have to be formal presentations with slides:

Why Is Knowledge Sharing Important? #

Knowledge Silos Are Invisible Technical Debt #

The easiest technical debt to identify is bad code. But there’s a more dangerous form of technical debt because it’s invisible: knowledge that exists only in one person’s head.

// The familiar knowledge silo scenario
Senior engineer A is the only one who understands the legacy payment system.

Scenario 1: A takes 2 weeks of leave
→ The team can't fix bugs in the payment system
→ The team waits or guesses at the implementation

Scenario 2: A resigns
→ The team loses all knowledge about that system
→ Onboarding a new engineer takes 2-3 months just for this system
→ The same bug gets solved differently every time

Scenario 3: A falls ill suddenly during a production incident
→ On-call can't make decisions
→ The incident lasts longer than it should

// All these scenarios are avoidable if knowledge is already distributed

Knowledge Sharing Is the Cheapest Investment #

Compared to the alternatives — documentation that takes time to write, expensive formal training, or long onboarding — one good KSS session can transfer knowledge to the whole team in 45 minutes.

Cost of one KSS:
  Presenter preparation: 1-3 hours
  Audience time: 45 minutes × N people

Benefits produced:
  ✓ N engineers understand the topic
  ✓ SPOF risk reduced
  ✓ The team can make better decisions on the topic
  ✓ Recordings / documentation can be used for onboarding future engineers
  ✓ Discussion produces new insights not found in any documentation

Naturally Driving Continuous Improvement #

Regular KSS creates a healthy feedback loop within the team. When an engineer presents the approach they used, other engineers offer different perspectives, question assumptions, or suggest alternatives. This is code review at the knowledge level — and the result is continuously rising collective technical quality.

flowchart TD
    KSS[Knowledge Sharing Session] --> D[Discussion & questions from the audience]
    D --> I[New insights that didn't exist before]
    I --> A[Action items to follow up]
    A --> P[Better practices applied]
    P --> K[New KSS topics emerge]
    K --> KSS

Types of Knowledge Sharing Sessions #

Technical Deep Dive #

A session covering one technical topic in depth — architecture, design patterns, optimization, or technology choices. This is the most common format in engineering teams.

Examples of topics suited for a technical deep dive:
  ✓ "How distributed tracing works in our system"
  ✓ "Why we chose event-driven for notifications instead of polling"
  ✓ "Analyzing the queries that caused last month's database spike"
  ✓ "Optimistic vs pessimistic locking approaches in our system's context"
  ✓ "How we implemented a circuit breaker in the payment service"

Recommended format:
  - Start from the *why* — why this topic matters to the team
  - System context — how this applies to our codebase
  - Demo or real examples — not just theory
  - Trade-offs and decisions made
  - Q&A and discussion

Incident Review / Postmortem #

A session discussing incidents or failures that already happened — not to blame, but to learn together. This is one of the most valuable KSS formats because it’s based on real experience.

// Blameless postmortem principles in KSS
Focus on systems and processes, not individuals:
  ✗ "Dev A wrote the bug that caused the outage"
  ✓ "There's a gap in the code review process that let a bug like this through"

An effective postmortem structure:
  1. Timeline of events — what happened, when, in clear order
  2. Root cause analysis — not just symptoms, but the underlying cause
  3. Impact — quantitative if possible (downtime duration, affected users, revenue impact)
  4. Factors that lengthened or shortened the incident
  5. Concrete action items — what will change so it doesn't recur
  6. Lessons generalizable to other systems or processes

A good postmortem produces concrete action items that get followed up, not just an archived document. If no one works on a postmortem’s action items, the team loses trust in the process.

Demo of New Workflows or Tools #

A short session showing how to use a new tool, library, or workflow that can boost team productivity. This format is most effective when done live — not slides about a tool, but directly showing its usage.

Examples of suitable topics:
  ✓ Demo of using a newly set-up observability tool
  ✓ Showing a new workflow for faster debugging
  ✓ Introducing a library that simplifies boilerplate
  ✓ Demo of creating a load test for a new service

Tips for effectiveness:
  ✓ Use examples from the real codebase, not irrelevant hello worlds
  ✓ Prepare the demo environment beforehand — don't set up in front of the audience
  ✓ Show the problem first, then the solution
  ✓ Let the audience try it hands-on if possible

Brown Bag / Lightning Talk #

An informal, short session (15-20 minutes) covering any relevant topic — from trending technical topics, interesting articles, to conference experiences. This format is easy for anyone to contribute to, including junior engineers.

Characteristics of an effective brown bag:
  ✓ No perfect slides needed — a whiteboard or screen share suffices
  ✓ The goal is sharing a new perspective, not becoming an expert on the topic
  ✓ Discussion matters more than the presentation
  ✓ Good for: newly explored topics, experiment results, interesting articles

// Example brown bag format

"I just tried using tool X for profiling in our service —
here's what I found, and here are the questions still unanswered.
Has anyone tried a different approach?"
→ Not an expert presentation, but exploration sharing

How to Choose the Right Topic #

The best KSS topics aren’t the “coolest” or most academic — they’re the most relevant and immediately applicable for the audience.

flowchart TD
    Q1{"Has the team\nexperienced this problem?"} -- Yes --> GOOD[Good topic candidate]
    Q1 -- No --> Q2
    Q2{"Is this a technical decision\naffecting many services?"} -- Yes --> GOOD
    Q2 -- No --> Q3
    Q3{"Is there an engineer who\ndoesn't know this yet\nand needs to?"} -- Yes --> GOOD
    Q3 -- No --> Q4{"Is this something the\npresenter truly understands\nand can discuss?"} -- Yes --> CONSIDER[Consider carefully]
    Q4 -- No --> SKIP[Find another topic]
    GOOD --> PRIORITY[Prioritize for the next KSS]

The richest topic sources for engineering team KSS:

From direct experience:
  ✓ A recent production incident
  ✓ A major technical decision just made (an RFC finished implementing)
  ✓ A performance bottleneck just found and solved
  ✓ An interesting bug that needed deep investigation before fixing

From exploration:
  ✓ New tools or libraries just tried and proven useful
  ✓ Topics repeatedly coming up in code reviews
  ✓ Patterns or anti-patterns frequently found in the codebase

From team needs:
  ✓ Areas understood by only one person (identified knowledge silos)
  ✓ Technologies or services many engineers will soon work on
  ✓ Newly agreed standard or best practice changes

The Structure of an Effective KSS #

Use Storytelling, Not Slide Dumps #

Technical material delivered as a story is far easier to remember than a sequence of bullet points. The human brain is designed to remember narratives, not fact lists.

// ✗ A boring, easily forgotten structure
Slide 1: Definition of distributed tracing
Slide 2: How spans and traces work
Slide 3: Tracing components
Slide 4: How to implement
Slide 5: Conclusion

// ✓ An engaging storytelling structure

"Two months ago we had an incident where checkout requests suddenly became slow.
In our logs we only saw timeout errors, but didn't know where the time was actually spent."
[problem]


"I tried manual tracing by adding logs in every service — it took 3 hours
just to find that the bottleneck was in the external payment API."
[impact and urgency]


"Now we've set up distributed tracing. If the same incident happened today,
we could see it directly on the dashboard within 30 seconds."
[solution and real results]


"Here's how it works, and here's how we can use it for daily debugging."
[technical explanation in a context the audience already understands]

Emphasize the Why and Trade-offs, Not Just the How #

An audience that only knows the how will be confused when the situation differs slightly. An audience that understands the why and existing trade-offs can adapt that knowledge to different contexts.

// ✗ Only explaining how

"For rate limiting implementation, we use Redis with the sliding window algorithm.
Here's how: set a key with TTL, increment on every request, reject if the limit is exceeded."

// ✓ Explaining why and trade-offs

"We need rate limiting to prevent abuse on the public API.
There are several approaches:
  - Fixed window: easy to implement but exploitable at window boundaries
  - Sliding window: more accurate but needs more Redis storage
  - Token bucket: smoothest but more complex

We chose sliding window because our public API is very sensitive to bursts
at boundaries, and the storage cost is still within acceptable limits.
But for internal APIs, fixed window might be enough since the traffic pattern differs."

Leave Enough Time for Discussion #

A session leaving only 5 minutes for Q&A loses the most valuable opportunity of a KSS. Discussion is where new insights emerge, assumptions get questioned, and different perspectives are shared.

// Recommended time distribution for a 45-minute KSS
  Presentation: 25-30 minutes
  Q&A and discussion: 15-20 minutes

// How to encourage active discussion
End the presentation with open questions:
  ✓ "Are there situations in your systems that could use a different approach?"
  ✓ "What trade-offs do you think I haven't considered?"
  ✓ "Who has faced a similar problem? How did you solve it?"

Not questions easily answered with yes or no:
  ✗ "Any questions?" [silence]
  ✗ "Is everything clear?"

Documentation: So Knowledge Isn’t Lost Again #

An undocumented KSS only transfers knowledge to the people present — and loses it again when they forget. Documentation is what turns a KSS from an event into an asset.

// Outputs every KSS should ideally produce
Minimum:
  □ A written summary: key points, discussed decisions, insights from discussion
  □ Links to materials (slides, diagrams, example code)
  □ Action items if any, with owners and deadlines

Ideal:
  □ Video recording (very useful for onboarding new engineers)
  □ An internal article more complete than the summary
  □ References to related documentation (RFCs, ADRs, runbooks)

Stored in:
  □ A centralized, easily searchable repository (internal wiki, Notion, Confluence)
  □ Relevant Slack or team communication channels
  □ Indexed with consistent tags or categories

A new engineer joining 6 months after a KSS took place should be able to find and understand its contents without anyone’s help. That’s the measure of good KSS documentation.

Building a Knowledge Sharing Culture #

Speaker Rotation — Not Just Seniors #

One of the most damaging patterns to KSS culture is making it an exclusive domain of seniors or tech leads. A healthy KSS involves all levels.

// ✗ KSS that's only seniors
  The Tech Lead presents every session
  → Juniors feel the KSS isn't "for them"
  → Seniors burn out from presenting constantly
  → No regeneration of topics and perspectives

// ✓ KSS with speaker rotation
  Junior: "I just learned about Go channels this week — here's what I found"
  Mid-level: "I explored a new profiling tool — here's the comparison"
  Senior: "Here's an architecture decision we made and why"
  → Every level contributes and learns from different perspectives

Consistent Frequency Matters More Than Perfect Quality #

A regular KSS with “good enough” quality is far more valuable than a perfect KSS that rarely happens.

// Realistic frequency targets
  Small team (5-10 people): bi-weekly or monthly
  Medium team (10-20 people): bi-weekly
  Large team (20+ people): weekly or bi-weekly with sub-team rotation

// Signs of wrong frequency
  ✗ "We'll have a KSS when someone wants to present" → never happens consistently
  ✗ "We have a KSS every week" but a 5-person team → presenters run out of ideas fast
  ✓ A fixed realistic schedule, with a planned topic pipeline

Psychological Safety Is a Prerequisite #

Knowledge sharing won’t happen naturally if engineers fear looking “ignorant” or fear criticism when sharing imperfect ideas.

Signals of low psychological safety in KSS:
  ✗ Nobody volunteers to present
  ✗ Presentations are always too polished and nobody shares "work in progress"
  ✗ No critical questions in Q&A — everyone agrees with everything presented
  ✗ Only the same people always speak

How to build psychological safety for KSS:
  ✓ Managers or tech leads are willing to be the first speaker about things they don't know
  ✓ "Stupid" questions are appreciated, not avoided
  ✓ Presenters are allowed to not have all the answers — "I don't know" is a valid response
  ✓ No personal criticism — discussion focuses on ideas and systems

Knowledge Sharing Anti-Patterns #

// ✗ KSS as show-off, not genuine sharing
The presenter picks a topic that makes them look smart,
not the topic most useful for the team
→ The audience can't apply anything
// ✓ Topics chosen by team relevance, not the presenter's personal agenda

// ✗ Sessions too long without clear structure
90 minutes of presentation without breaks, topic sprawling everywhere
→ The audience loses focus, nothing is truly absorbed
// ✓ Limit 45-60 minutes per session, focus on one main topic

// ✗ No documentation after the session
KSS happens, discussion runs, insights emerge — but nothing is recorded
3 months later, everyone has forgotten
// ✓ Every KSS produces at least a searchable written summary

// ✗ KSS without follow-up action items

"Great sharing" — done, back to each person's work
→ Nothing changes after the session
// ✓ At the session's end, ask: "What will we do differently after this?"

// ✗ KSS only happening when someone takes the initiative

"We'll have a KSS when someone wants to share"
→ Never scheduled because everyone waits for someone else
// ✓ A fixed schedule and a planned topic pipeline exist

// ✗ KSS without discussion — fully one-way
The presenter talks for 60 minutes, no interaction, 2-minute Q&A
→ Loses the greatest KSS value: insights from discussion
// ✓ At least 30% of time for discussion and Q&A

Effective KSS Checklist #

BEFORE THE SESSION:
  □ Topic chosen by real team relevance, not just presenter interest
  □ Presenter prepares examples from the actual system context (not toy examples)
  □ Duration set and realistic for the topic
  □ Schedule communicated to all participants with enough notice
  □ Demo environment prepared and tested if there's a live demo

DURING THE SESSION:
  □ Session starts with the *why* context — why this topic matters to the team
  □ Real examples or demos exist, not just abstract theory
  □ Trade-offs and considered alternatives explained
  □ Discussion and Q&A time available (min 30% of total duration)
  □ Audience questions appreciated, not dismissed

AFTER THE SESSION:
  □ Written summary sent to the relevant channel within 24 hours
  □ Links to materials (slides, code, diagrams) included
  □ Action items (if any) recorded with owners and deadlines
  □ Materials archived in an easily searchable central repository
  □ Recording saved if available (and communicated to those who couldn't attend)

FOR THE TEAM'S KSS PROGRAM:
  □ A fixed schedule (bi-weekly / monthly) that isn't easily skipped
  □ A topic pipeline planned 1-2 months ahead
  □ Presenters rotated — not just seniors or the same people
  □ A mechanism for proposing topics from anyone on the team
  □ Session effectiveness evaluated periodically (still useful?)

Summary #

• Knowledge silos are technical debt at the human level — knowledge locked in one person is an SPOF invisible in the codebase but felt whenever that person is absent.
• KSS is the most cost-effective investment — one good session can transfer critical knowledge to the whole team in 45 minutes.
• Storytelling beats slide dumps — start with a real problem, not definitions. Audiences remember narratives, not fact lists.
• Emphasize the why and trade-offs, not just the how — audiences who understand the reasoning behind decisions can adapt them, not just imitate them.
• Discussion is where the greatest value emerges — leave at least 30% of time for Q&A and open with open questions, not “any questions?”.
• Document every session — an undocumented KSS only helps those present at the time, and fades within months.
• Speaker rotation builds ownership — a KSS presented only by seniors becomes their domain, not team culture.
• Consistent frequency matters more than perfect quality — an ordinary bi-weekly KSS is far more valuable than a perfect quarterly one.
• Psychological safety is a prerequisite — engineers won’t share if they fear looking incompetent or fear criticism.

← Previous: 1-on-1   Next: Postmortem →