Breaking the wall between teams
How to share knowledge in a growing organization
I’m walking to the kitchen with one of my engineers. He shares in excitement how he finally solved that annoying problem he was stuck a week on.
While we wait in line for the coffee machine, a Staff Engineer from another team overhears our conversation and offhandedly says:
“Oh I remember that problem! I solved it a couple of months ago too”.
The even more frustrating part? It was not the first time it happened to us.
I’m sure you can relate - ever spent a week building a feature only to find out another team is already working on it? Welcome to the deep mud of knowledge silos.
This is what happens when different teams don’t share information effectively. The 2024 StackOverflow Developer Survey shows how widespread is the problem:
45% of developers report that knowledge silos negatively impact their productivity three or more times a week.
45% of developers say that these silos prevent them from getting their ideas across the organization.
Think about it - almost half of your team is frustrated several times a week because they can’t find the information they need or their ideas are stuck in the same feedback loop.
There is good news though. There are 4 main reasons for knowledge silos, and you are going to read about how to address each:
No horizontal information flow
Ineffective knowledge sharing
Shitty onboarding
“Us vs. Them” thinking
Today’s article is a guest post by , Senior Staff Software Engineer at Outreach and the writer of , a great newsletter about product engineering and tech leadership!
The 4 Root Causes And How to Fix Them
1. No Horizontal Information Flow
Many traditional organizations are hierarchical, where information flows up and down the chain of command but rarely horizontally.
This means knowledge is locked within departments. Engineers feel they have no voice, and valuable knowledge never reaches other teams who could benefit from it.
What can you do about it
The fix for vertical-only information flow is creating horizontal knowledge-sharing pathways across the organization. One of the most effective ways to do this is through Engineering Guilds (sometimes called Chapters).
Anton here: you can start with creating dedicated Slack channels or specific tech-stacks/platforms, and encourage people to ask questions there. It’s better than nothing and can encourage cross-team collaboration.
Guilds (such as frontend guilds, machine learning guilds, and so on) provide a space for engineers to share best practices, discuss technical challenges, create plans for addressing technical debt, and learn from each other.
For over 10 months now, I’ve been driving Frontend Guild at my current company, and there is one major hurdle organizations hit when trying to start successful engineering guilds:
Because guilds do not fall under the hierarchical organizational structures, engineers don’t have allocated time for any guild-related activities.
When this problem is not addressed from the start, guilds degrade to places where engineers vent their frustration and agree that “something” needs to be done. But at the end of the day, no one does anything, and frustration only grows.
That’s why we’ve chosen to approach the guild strategically from the beginning by adhering to three key principles:
All guild’s projects must be tightly related to the company’s strategic goals.
Leadership recognizes the guild as an official entity and provides members time to participate in its projects.
Members have the freedom to choose projects they want to participate in based on their interests and career growth goals.
I recommend reading Mirek Stanek‘s article "20% for tech debt" doesn't work. It is a great deep dive into why you cannot just blindly allocate some predefined amount of time for tech improvements, which is exactly the approach we chose with the guild.
2. Ineffective Knowledge-Sharing
Teams spend too much time reinventing the wheel just because they can’t find existing resources or learnings.
Without dedicated platforms for sharing knowledge, information gets lost in emails, Slack discussions, private chats, or ad-hoc documents.
The base building block for such a platform is an effective documentation culture.
What can you do about it
Sufficient and up-to-date documentation is one of those holy grails that everyone wants to achieve, but no one seems to. It’s important to remember that in the case of documentation, the perfect is the enemy of the good.
So, how do we make documentation more effective? There are two main blockers that need to be addressed:
1. Most of the documentation becomes obsolete quickly, and often no one reads it anyway.
The purpose of writing documentation is NOT to produce a lot of text. It’s to capture the most vital knowledge about the reasoning behind crucial decisions and fundamental principles (architecture, protocols, etc.).
Minimum Viable Documentation focuses on capturing only the essential knowledge people need to perform their jobs effectively. This keeps it relevant and actionable throughout its existence.
Anton here: if you just have a ton of information lying around (like we did), you can easily create an ‘internal ChatGPT’. It works really well for us!
2. Writing documentation is a tedious process. Where and how should I even start?
When everyone uses the same templates and tools for documenting their work, much of the work can be automated. This is what standardized documentation is all about.
Engineers do not need to think about “Where should I create the documentation?” or “I’m not good at writing. How and what should I write?” They generate a predefined skeleton for the document, fill in the blanks, and it becomes part of the searchable shared knowledge.
Architecture Decision Records (ADRs) are a great example of Standardized Minimum Viable Documentation. They embed crucial knowledge directly into the codebase with a shared format and goal.
We’ve been using ADR to capture information, for example, on:
Agreed-upon development patterns and architecture approaches
Recommended testing practices
Evaluation of approved (and rejected) 3rd party packages
Results from Architecture review sessions
By keeping these records close to the source code, developers always have the information they need to understand why specific decisions were made, their impact, and who the contact persons are.
3. Shitty Onboarding
Onboarding is THE time for sharing knowledge. When new employees don’t know where to find the information or who to ask, knowledge silos are created from day one.
What can you do about it
The first step is to have someone experienced guiding them through this process — an onboarding buddy. From my experience, a successful “buddy” guides the new joiner via:
Pair Programming Sessions: I’ve always found pair programming to be the best way to help new hires quickly understand code base and workflows. At the same time, many other topics are discussed, such as historically taken decisions and their reasoning, possible future improvements, tech debt, testing practices, etc.
Product and Architecture Overviews: Context for what the team is building, why it matters, and how the system fits together.
Deep Dives: Focusing on the domain, tools, and processes that are specific to the team.
To make the onboarding even better, you need to introduce the new hire to people from outside your team too:
Other teams’ product overview: It can be by engineering managers or fellow software engineers. In addition to getting to know the company’s product better that way, it’ll help developers know who is responsible for what, giving them ideas for people to consult with.
Social Integration: Introducing new hires to various people across the company, helping them form connections and feel part of the team.
4. “Us vs. Them” Thinking
When teams are too isolated or too specialized, they usually develop their own way of working. This puts their focus on achieving their team’s outputs rather than the organization's goals and real outcomes.
Another reason is a lack of trust. Teams become protective when they fear that sharing knowledge will expose their weaknesses or lead to negative feedback.
In a highly competitive environment where departments compete against each other — for headcount, bonuses, or praise, knowledge remains confined to its original holders.
What can you do about it
The antidote to “us vs. them” thinking is radical transparency. Break down silos by over-communicating and making knowledge-sharing the default.
In my experience, when teams understand the common struggles and complexities brought by difficult domains, constraints, trade-offs, and deadlines, they change their approach from “us vs. them” to “us together vs. the problem.”
I’ve especially seen positive results with two specific methods for knowledge sharing:
Architecture Review Sessions: Open up decision-making to the entire organization. Anyone can join, either to passively learn or to actively influence technical choices. This guarantees everyone has visibility into critical decisions and a chance to contribute their insights.
Meetups: Formal or lightning-style, meetups are great for sharing practical knowledge across teams. They provide opportunities for teams to showcase their expertise and learn from each other.
Whether it’s best database practices, deployment workflows, or other technical know-how, everyone gains a broader perspective. As a bonus, presenters practice presenting in front of others to improve their communication skills.
There is a caveat: knowledge-sharing doesn’t just happen by chance. You need to incentivize it. Embed knowledge-sharing into your organization’s career framework. Reward contributions to cross-team collaboration and recognize those who consistently share knowledge and unblock others.
Final Thoughts
In some organizations, information is treated as a commodity—something that gives power to those who hold it. This culture of control results in employee frustration, high turnover rates, slow speed, and low quality of new feature delivery.
To prevent these outcomes, knowledge sharing must be a fundamental part of your company culture. This is the only proactive approach that works.
Reward active participation in building such a culture and give support and public praise to those who contribute, and you will build an environment that creates 10x engineers.
Thank you for a great article!
What I enjoyed reading this week
 | A guest post by
|
ADRs sound scary! I saw one in my career, and that thing was like 50 pages long! 😃
But I really like this idea of guilds. It often happens that I DM people I know they know because of how the communication is set up in my current company.
The one I worked for as a freelancer before had these front-end and backend channels, and engineers were often encouraging me to ask questions there or even search the channel because someone likely asked that question before me!
Great writing both of you! 👏
We too had this, knowledge sharing session with team and also with other teams. But apparently it all gradually dies and only one person has to keep pushing others to share something. I think at the end we need to invoke the willingness of people, and how to do that is the question