How to Get Your Engineers Engaged in Knowledge Sharing

If you’ve ever tried to encourage engineers to share knowledge, you know it’s not easy.

In theory, everyone benefits when teams document their insights, share solutions, and help each other avoid reinventing the wheel. But in practice, knowledge often stays locked away in silos, shared only in passing conversations or buried in one-off Slack threads.

Some engineers hesitate because they don’t think their insights are valuable enough. Others feel too busy. And some just don’t know where to start.

So how do you change that? How do you build a culture where engineers feel comfortable - and even excited - to share what they know?

It doesn’t happen overnight, but with the right approach, you can make knowledge sharing feel natural rather than forced. Here’s how.

Lower the Barrier to Entry

Most people assume that sharing knowledge means writing a formal blog post or giving a presentation. That’s intimidating - even for experienced engineers.

Instead, make it easy by encouraging small, low-effort contributions:

? Posting quick insights in internal Slack or Teams channels.

? Commenting on someone else’s post with additional context.

? Adding an emoji reaction to acknowledge useful information.

These small actions build momentum. Once engineers see that knowledge-sharing isn’t about writing perfectly polished essays, they’ll be more likely to contribute.

Another overlooked tactic? Make documentation effortless. If your company uses a wiki like Confluence or Notion, set up a lightweight space where engineers can jot down notes without worrying about structure or formatting. Even a rough, informal post is better than knowledge being lost entirely.

At Spotify, engineers use a system called "Backstage" that makes documentation part of the development workflow rather than a separate activity. They've found that integrating knowledge sharing directly into existing tools dramatically increases participation.

Recognise and Reward Contributions

Sharing knowledge often goes unnoticed. If an engineer spends an hour documenting a tricky issue they solved, but no one acknowledges it, they won’t feel motivated to do it again.

Recognition doesn’t have to be formal - just a small nod can make a big difference:

? Call out useful contributions in team meetings.

? Pin valuable internal posts so they’re easy to find.

? Encourage managers to highlight knowledge-sharing efforts in performance reviews.

Some companies even bake knowledge sharing into OKRs - for example, requiring each engineer to contribute one post per quarter. It doesn’t have to be rigid, but when sharing knowledge is seen as part of the job, rather than extra work, engagement improves.

Atlassian measures the "value" of internal documentation by tracking how often posts are referenced in issue discussions or linked from other documents. They use these metrics to highlight the most impactful knowledge contributors each quarter.

Lead by Example

If leaders don’t share, why would the rest of the team?

As an engineering leader, you set the tone. If you regularly share your own insights - whether it’s lessons from a past project, a technical deep dive, or even mistakes you’ve made - it signals to your team that this is something worth doing.

More importantly, it creates a culture of psychological safety. Engineers are often hesitant to share because they don’t want to be wrong or seem uninformed. But when leaders openly discuss challenges and lessons learned, it normalizes the idea that knowledge sharing isn’t about proving expertise - it’s about helping each other grow.

At GitLab, whose 1,500+ employees work 100% remotely, leadership demonstrates commitment by writing "public thinking" documents that showcase not just conclusions but the messy process of working through complex problems. This transparency signals that sharing incomplete knowledge is valuable.

Make It Useful, Not Just Performative

People won’t engage with knowledge sharing if it feels like busywork. It needs to be practical.

Encourage engineers to share things that will actually save their teammates time:

? Onboarding tips. New hires struggle with the same things - why not document what helped?

? Solutions to common problems. If one engineer figured out a tricky API integration, others will probably need that info later.

? Technical deep dives. Even niche topics have value - someone in the org will need that knowledge at some point.

? Micro-documentation: Simple Slack threads that solve a specific problem can be copied into a central wiki with minimal editing.

One of my most-read internal posts wasn’t even particularly technical - it was just a text version of a PDF document containing our company’s core values. People needed to reference it often, and copying from a PDF was a hassle. That post got tons of engagement simply because it solved a small but annoying problem.

The takeaway? Knowledge sharing doesn’t have to be groundbreaking - it just has to be useful.

Remove the “Writing” Barrier with AI

One big reason engineers hesitate to share knowledge? Writing is hard.

Many engineers think, I have great ideas, but I don’t have time to structure them into a well-written article.

This is where AI tools (like ChatGPT) can help:

? Turning rough bullet points into a structured post.

? Summarizing Slack discussions into a wiki entry.

? Refining a first draft into something clear and engaging.

AI won’t replace human expertise, but it can remove friction and make the process of sharing knowledge far easier.

Build a Progressive Sharing Pipeline

Knowledge sharing shouldn't be binary - internal vs. external. Create a progression that allows engineers to gradually increase their comfort and reach:

• Team-level sharing: Start with documentation that only needs to reach immediate teammates.
• Cross-team exchanges: Facilitate knowledge sharing between related teams through joint tech talks or documentation exchanges.
• Company-wide visibility: Highlight the best team-level content for broader internal audiences.
• External contributions: Support engineers ready to share insights through company blogs, conference talks, or open source contributions.

Shopify built this pipeline explicitly, with internal wiki posts that gain traction being developed into engineering blog posts, which sometimes evolve into conference presentations. This creates a natural progression that meets engineers where they are.

Final Thought: Start Small, but Start Now

Knowledge sharing isn’t about forcing engineers to become bloggers overnight. It’s about creating an environment where sharing useful insights is easy, valued, and recognized.

Encourage small contributions. Recognize those who participate. Lead by example.

And most importantly - just start.

Even a single post, comment, or Slack message can be the first step toward building a culture where knowledge flows freely.

So here’s a challenge: What’s one small way you can encourage knowledge sharing in your team this week?