Building Knowledge in Teams: Main Mistakes and Strategies

The topic of knowledge management in teams is largely overlooked by IT leaders. There is a silent assumption that it happens automatically. To some extent, it does, as programmers are accustomed to constantly learning to stay ahead. However, this is not sufficient. It’s not enough for everyone (or realistically, half) to learn individually. If the team is to be effective, cohesive and up-to-date knowledge is needed. Knowledge of new technologies or solutions holds limited value compared to this.

The Importance of Intentional Knowledge Development

Dear leader, consciously guiding the development of knowledge within your team is important. Often, this task is pushed aside or ignored as it is not coding-related, difficult to schedule, and people seem to manage somehow. However, the devil is in the details, and this “somehow” makes a big difference. The best-functioning teams I’ve encountered have well-developed knowledge management practices.

Common Pitfalls and Effective Heuristics

Here are common issues and successful heuristics:

1. Lack of Architectural Documentation
   Yes, we all believe we’re Agile now, so documentation is deemed unnecessary. This excuse needs to end. High-level documentation, such as diagrams that provide an overview of the system — context diagrams, component diagrams, architectural mantras, and diagrams of main frameworks — is essential. Without these, discussions about solutions, system changes, or onboarding new people become particularly difficult due to the lack of a shared point of reference.

2. Lack of Onboarding Strategies for Newcomers
   Sometimes there is a strategy, but it’s often poorly executed — usually just a few chaotic days mainly covering organizational matters like company procedures, setting up environments, etc. Newcomers learn systems through the code. This process is several times (often an order of magnitude) longer than if mentored by a team member. This local optimization leads to inefficiency during the first months of work.

3. Lack of Knowledge of the System/Code
   This issue is a natural consequence of the above two. Poor orientation in the system leads to fragmented knowledge, resulting in significant time spent searching and frequently asking others for information. Consequently, learning happens “live,” often replicating undesirable solutions.

4. Lack of Consistent Rules
   A unified coding standard has become standard practice, but that’s not enough. Many factors influence code readability or architectural cleanliness, which should be unified — for instance, clean code principles and architectural mantras. If not established and monitored, these lead to architectural erosion through inconsistent solutions.

5. Lack of Knowledge Exchange Within and Between Teams
   Often there is no time or money for training, but leaders often underestimate the most valuable asset they have — the knowledge and experience of their own team members. Create an environment for knowledge exchange. Encourage good solutions during reviews, build a repository of code examples, stimulate internal training, and facilitate pair programming.

6. Lack of System Knowledge Updates
   Systems change faster than we expect and often in unforeseen directions, necessitating updates to architecture agreements, libraries, and mechanisms. Leaders frequently forget to ensure that changes are implemented and maintained by the whole team, not just known by leaders and (lead) architects.

7. Lack of Space for Acquiring New Knowledge
   Many companies expect self-taught learning. However, this approach has drawbacks. Self-learning often limits context and makes identifying genuinely novel or transformative solutions harder. Self-teaching typically results in fragmented knowledge accumulation without integration into a coherent whole.

Building a continuous learning environment should be one of your main goals as a leader. You will have motivated, effective people creating cohesive solutions.

Failure to organize such a process will lead to knowledge and motivation lapses, increased staff turnover, and decreased team expertise and project quality.

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)