How to boost knowledge sharing?

Some efficient ways we follow at Application Platform at Scout24 to spread the knowledge inside our teams.

This article represents my own opinion.

I have worked at several companies from Damascus to Berlin since 2012 and one common concern among all of them is “knowledge sharing between team members” or avoiding “knowledge islands”. Each company tried tackling that in different ways; however, not all were successful.

In the following article, I will write about some efficient ways to boost knowledge sharing inside your team.

What are “Islands of Knowledge” anyway?

Having one or two experienced engineers in the team who “know it all” can be convenient for many managers and sometimes a successful model of getting things done fast. However, it is also risky and creates a single point of failure in the team.

Managers should be aware of their single point of failures before a disaster happens and should encourage and push knowledge sharing between members.

If you are a manager and don’t know if you have that, just imagine how your team will handle work without the most experienced person in your team. If your answer is similar to “the team will collapse”, then you need to start solving this problem now. Keep in mind that knowledge sharing needs alignment between management and co-workers. It takes time and effort from all team members.

Why don’t some people like knowledge sharing?

We live in a competitive world, and in the work atmosphere, competition gets higher across the board globally and more intense as you progress technically. Each person tries to market themselves and prove how unique and great they are. The more competitive your work atmosphere is, the less motivation your employees have for knowledge sharing. In such places knowledge sharing equals giving your own value to other colleagues. No one would like to do that.

Don’t get me wrong, competition is not a bad thing as long as it stays healthy, ethical and within limits. If the company culture promotes only competition regardless of any other values; like empathy, trust, safe environment, collaboration and openness… etc., and if your promotion and evaluation is related only to proving you are better than coworker X and coworker Y, that’s an unhealthy toxic work environment. My friend, you better run away!

On the other hand, it’s not always the competitive atmosphere nor self-importance to be blamed on. It’s very common for individuals to get interested in a specific topic and so become the experts which leads to getting them assigned more frequently to that topic as they are the most efficient ones. Preference is another major reason for producing islands of knowledge.

How can knowledge get shared?

Documentation

I emphasise here on having effective documentation as I encountered many projects which have many pages of infinite but useless text or one very short page which explains nothing.

Generally, documentation of a project should have clear answers to the following questions:

• What problem does this project solve?
• How can the end-user use it?
• How can other developers continue working on it?

Most importantly, for docs to be effective, they need to be owned, maintained just like the code and up-to-date ;)

Different types of documentation

Not all documentations are alike. When writing any doc page, you should keep in mind who will read it later.

• Developer-facing docs

It focuses more on the technical side of the project; what technologies it consists of and how it can be developed further. It should have all the information which empowers other developers to start immediately working on that project.

I’m a big fan of including a “Prerequisites” section at the top of any README; where all needed tools and libraries for running this project are stated. This doesn’t mean duplicating the content of the package manager but simply stating for example: to work on this project you need this main programming language with this specific version (e.g, python3) and maybe an external prerequisite which cannot be installed with a package manager (e.g. AWS account).

Along with that, a visual diagram which shows the architectural design of the project.

Finally, including an Architectural Decision Record (ADR) section is a very useful way to contact history with future developers.

Architectural decision record (ADR)

Team members change during the lifetime of a project and not all decisions are made at the beginning. To avoid the loss of context and in order to keep track of significant architectural decisions that engineers make during the development phase, we adopted ADRs in my team and other teams in the Application Platform at Scout24.

ADRs provide a good framework to capture such decisions, including pros and cons with their context then store them in the same repository of the project. To learn more about it you can read this article.

• User-facing docs

This docs lives separately from the developing-guidance docs. The goal of this doc is to explain the “How to use this product” without getting into too many details of how it was developed or why a specific technology was chosen over another. Furthermore, It should include all information which enables the user to use it efficiently. Ideally, with an example that the user can quickly try and get a feeling of your product or with an online demo.

In the Application Platform at Scout24, we followed this approach by creating one shared place between all Platform Engineering teams for our users where they can learn more about our products and find answers. Adding to that, almost each of our products includes a “Quick Start” section which enables our users to test our products immediately.

• Team guideline docs

Besides documenting your team’s products, it’s also a good idea to have team guidelines where you document your ways of work and team’s standards (e.g. team’s rituals, team’s agreed definition of ready and definition of done, core working hours .. etc. ).

By doing so, your team identity will be transparent to the organisation and to any new team member.

In my team at Scout24, Application Runtime, we created a github repository for that which can be updated easily, viewed and shared by anyone inside Scout24 organisation.

On-boarding

Having new team members on-board is a great opportunity to revisit your documentation and keep it up-to-date. New joiners have the privilege of a fresh set of eyes; they look into your docs and try to grasp the information such that they can take off and start working. They want to know the what, why and how.

It’s highly recommended to assign a “buddy” to the new joiner, whom they can ask if they struggle with their first tasks. Another idea is to organise sessions where old members explain the products to the new members. By doing so, your team can catch the gaps in the docs and improve it.

This applies also to switching teams at the same company. In the beginning of this year 2020, we restructured the Application Platform in Scout24 where people were assigned to new teams and new topics. Inside each team, we started organising those on-boarding sessions for each other and it went just great.

Pair programming

Pairing is about sharing. It is another great practice to establish in your team that helps in spreading the knowledge naturally. You can read more about it in my other article “Pairing or no Pairing?”.

Code reviews

Code reviews help developers to improve their coding skills, as well as learn new technologies and techniques to tackle problems. It focuses on identifying possible bugs, fixing small coding errors and smells, performance, testing, ensuing conventions, consistency, maintainability, etc. and finally meeting the feature requirements and making sure the code actually works.

However, code reviews alone are not enough to grow knowledge on higher-levels like architecture and design as it focuses mainly on code level and it holds the risk to become a superficial “rubber stamp” which provides no benefit, either to the learner if it’s done without pairing or being heavily involved with development. In my opinion, it is a great approach but should be combined with other practices to gain a bigger impact.

Code walkthrough

My former team at Scout24 was split between Barcelona and Berlin and we followed “Kanban”. We adopted pair programming in 80% of our work. As a result, we were always working in pairs. Before considering a story as “Done”, the pair who worked on a story did a code-walkthrough with the rest of team members so they can review, challenge and check new changes to the codebase which they will be working on soon.

This helped in transferring the learnings, the mistakes, the obstacles and the decisions context.

I like Code-Walkthroughs in spite of the extra time it adds to close a story. I’d recommend following it especially in the case where your team has many topics and involving all team members in code reviews is not possible. In addition, code-walkthrough is also good, if you work heavily in the pairing mode and whenever important decisions are made by the pair (or the individual) which would affect the team in the future (e.g. new system setup, new library introduced, new learning, etc.).

Sprint Review

The sprint review (sprint demo) is another great opportunity to learn about each other’s work. However, since the audience includes people from other teams as well as team members with non-engineering responsibilities, the type of the shared knowledge will be more high level and focus on meeting the acceptance criteria of a story and fulfilling the requirements of the stakeholder. The sprint demo is more focused on the outcome provided to the user rather than the way the work was done.

Combining it with other practices (e.g. code reviews) would make it very valuable.

Show and Tell

For the past two years, we have been hosting a 30 minutes meeting each Friday at Application Platform; it was our former Head of Tech’s idea; all of our three teams including engineers and managers attend and share their interesting learnings from last week.

The demos could be a new feature you added to your product, a new way to tackle a specific problem, a new library you found valuable .. etc. The demo should be useful, short and visual.

I found it really helpful to learn from other teams and stay up-to-date with what they are doing.

Meetups and Conferences

Attending meetups or conferences can be very inspiring and motivating. You learn from external parties about issues which might be related to what you do. Besides that, sharing your learning and reflections on them after attending a conference/meetup can be a great way to spread the knowledge.

Adding to that, hosting meetups in-house or participating in other companies meetups are yet another kind of knowledge sharing with an external audience. Platform Engineering hosted a couple of meetups at the Scout24 office. Engineers and managers participated in larger events like AWS Summit, AWS Loft, AWS “This is My Architecture”, Chemnitzer Linuxtage, Jenkins World Europe, DevOpsCon, etc.

Final Thoughts …

Yay, you made it! Thanks for reading until the end..

As you can see, there are many different options available to share knowledge across teams. It’s true that while approaches like pair programming (seemingly binding two engineers for “the same” outcome), writing documentation (instead of building features that bring in money), etc. need more time and reduce the team’s short term gains; however, it also vastly decreases engineering effort in the future and secures the business against the potentially extreme costs of regaining lost knowledge. It’s actually an investment which pays off later.

Moreover, your team will be more experienced and efficient at tackling different types of problems. In fact, time estimating will get better, ownership and accountability in the team will get higher, trust and confidence within the team will grow and on-boarding new team members will be way easier and faster than before.

I’d recommend you to mix and match the approaches presented in this article based on your team setup and preferences. Whatever options you choose, it’s essential you keep the communication loop within your team. If an approach is not agreed on and followed by all team members, then you need to stop, reflect and work on improving it or replace it with another more suitable approach.