Knowledge Sharing: A Sneak Peek into Facebook’s Engineering Teams

Knowledge Sharing: A Sneak Peek into Facebook’s Engineering Teams - Interview with Balázs Balázs (ex-Engineering Manager at Facebook)

Knowledge sharing is a crucial activity for every software developer team.

It plays an important part when you onboard engineers to your project or the company. You need to develop junior engineers to senior level, and keep everyone up to date with the latest technologies.

As a team leader, you need to figure out the most effective knowledge sharing methods for your team. You also need to make sure the team has time and energy for it, and encourage your engineers to participate actively.

How do you do all that?

Get some great tips from the front line via Balázs Balázs, former engineering manager at Facebook. His years of management experience give him insight into how one of the most widely-known software companies makes knowledge sharing work in its engineering teams. Interviewed by the lovely Karolina Toth on the Level-up Engineering podcast.

We’re covering:

• Picking the right methods for sharing knowledge in your team
• The best knowledge sharing methods in engineering teams
• Build the culture
• Use documentation
• The rules of using documentation
• Analyze the context
• Key things to document
• Examples from Facebook
• The best methods to help junior engineers grow
• Let them work
• Code reviews in-person
• Design reviews in-person
• Pair programming
• Mentoring
• Onboarding software engineers to your team
• Have new joiners write documentation
• Architecture reviews
• Bonus tip from Facebook
• Making time for knowledge sharing
• Tools for knowledge sharing in engineering teams
• Encouraging engineers to partake in knowledge sharing
• Reward it
• Make it fun
• Make it attractive
• Lead by example
• The key to Facebook's success in sharing knowledge
• High transparency
• Focus on communication
• About Balázs Balázs

How do you pick the best knowledge sharing methods for your engineering team?

Specify the scope

Different methods work best at different levels when sharing knowledge. You can focus on a developer team with six to eight people, where your goal is to have everyone know everything about the system you’re building. Or you can look at it on a wider scale like a department, or the entire company.

Every level requires different methods and different types of information, but communication is essential. In this interview, I’ll mostly focus on sharing knowledge on a smaller scale, within the bounds of an engineering team.

I use two principles to evaluate knowledge sharing methods:

1. Active and passive knowledge sharing

I prefer active knowledge sharing over passive. I value human interaction more than using passive methods.

For example, documentation is a passive method. Documenting something isn’t the same as sharing it.

An active way of sharing may be multiple people interacting with a piece of information. Human interaction gives you additional benefits like learning more about your teammates, and gaining mutual respect while learning from each other. This builds the team and the community as well.

2. Be pragmatic

Being pragmatic is a rule I apply to everything, not only knowledge sharing.

Any kind of knowledge sharing has a price. You need to evaluate how much effort you put into it, and how much value you get out of it. This varies from one team to the other, so there are no universal rules for everyone.

Analyze your specific circumstances, evaluate the cost and the value, and pick your methods deliberately.

What are the best methods of knowledge sharing in an engineering team?

1. Build the culture

The most important aspect is to create an environment where asking questions is encouraged. Build psychological safety in your team where everyone asks questions and there are no stupid questions. No one should be afraid to admit that they don’t know something.

This makes your knowledge sharing system cheaper, because people will ask for the information they need. Running a team where the teammates do this reduces the cost of communication.

The right engineering culture facilitates every possible active knowledge sharing method.

2. Documentation

You can’t ignore documentation. It’s an obvious way to share knowledge in the software world, but I think it’s overrated. I consider documentation expensive.

Most people don't think about its cost; they just feel an obligation to document everything. Maintaining up-to-date documentation takes a lot of effort. On top of that, it's a passive sharing method, so it doesn’t encourage human interaction.

There is value in documentation, and there are a lot of instances where you need it. Yet, most of the time you can get away with writing less documentation than you might think.

What’s your rule for using documentation?

You can use different forms of written documentation depending on your situation.

Analyze the context

You need to consider a few aspects to decide what level of documentation you need to maintain.

• What kind of system are you working on?
• Who are your customers?
• How many people will work with your code?

Things that should be documented

Every project needs a certain level of documentation. Here is a list of what you need to capture regardless of the context:

• Architecture principles
• All research related to the project
• The decisions you make
• The logic behind your decisions

It doesn't have to be a detailed design document, but this is all essential information you can’t read from the code. This doesn't even have to be a formal document. You can put it in the code, or you can have a designated spot for this in your internal communication tool, like Facebook Workplace at Facebook.

You almost always need API documentation, but you can often get away without creating guides, tutorials, examples and wiki pages for your code.

Examples from Facebook

When you don’t need documentation

One of the first teams I worked with at Facebook was developing an internal system that virtually no one was ever going to touch. There were only a handful of internal customers, and most of my teammates had been there for 3-5 years at that point. I was the first newcomer for a long time.

The lack of detail in the documentation made my onboarding experience difficult. Looking back now, I realize that maintaining a great documentation there would have been a waste of effort. I had a more difficult time onboarding, but the entire team saved a lot of time and effort over the years.

In this case, writing little documentation was a good trade-off from the team’s perspective.

When you need documentation

Recently, I’ve been on teams developing libraries, and we had thousands of internal users working with our code daily. Some of this was even open source. In this case, the team has to spend a lot of time creating a great documentation.

We often spent 50-60% of our time supporting systems, answering questions and trying to solve problems for others. A highly detailed documentation makes dealing with this easier for the team.

What are the best knowledge sharing methods to help junior engineers grow?

Based on my experience as an engineering manager at Facebook, the junior engineers I met were brilliant and ambitious. The last thing they wanted was advice. You could advise them, but they wanted to make their own mistakes.

Let them code

My advice is to let them work. Support them as much as you can, so the code they write will be useful.

A way to do this is to give them less risky projects. You don’t have to make their assignments easy, however. For example, you can give them tasks that don’t require much research.

Code reviews

Code reviews are a valuable tool to develop the skills of junior software engineers. My advice is to do code reviews in person whenever possible. Sit down with them and go through the code together.

Let them explain the code and the design process behind it. During the review, focus on the reasons they picked the path they did, and discuss with them why they didn’t consider a different method that may be beneficial. Using real code as an example, you can teach them tricks you couldn’t efficiently explain otherwise.

This helps them to develop the attitude for code reviews as well. Submitting your code for review the first time is a scary experience, because you know you’re going to get criticism. When you do a code review face to face, it’s less likely that they will misunderstand your intentions behind giving constructive feedback.

Design reviews

Design reviews are a great way to help junior engineers develop, especially if you don’t make them too formal. You don’t need to have them write a design document. Go to a whiteboard with them for 10 minutes instead, and let them explain their solution before they start writing code.

This is an opportunity to give them a lot of input, and they won’t feel like it’s unsolicited advice.

Pair programming

Pair programming is a great way to learn; I always enjoyed it as a software engineer. For some reason, I could never advocate pair programming properly as an engineering manager. There was always resistance from my team of engineers.

Solving problems with another engineer can speed up a junior engineer’s development. You learn a lot by sitting next to someone and by seeing their screen, how they use tools and how they work. Try to do it with different people, so you can pick up as many useful tricks as possible.

Mentoring

Mentoring developers is another great way to help inexperienced engineers grow. Finding a good mentor and developing a great relationship with that person makes the learning process easier. Once you have a respectful relationship, it’s easier to ask for advice, and it’s more likely the junior engineer will take the advice too.

What’s the best way to onboard engineers to your project or company?

Onboarding is tricky, but it's also an opportunity to integrate the new person into the team. I always remind myself of that. I design the onboarding of a new engineer in a way that they have to interact with the team as much as possible.

Have them write documentation

This is my favorite trick.

Have the new joiner write documentation or update it for the project you’re working on. This seems counterintuitive because the new engineer isn’t familiar with the context yet.

It works well, because it requires preparation. The new person has to interact with the team members to learn about the project. This way the new engineer gathers a deep understanding of the project, everyone on the team will know this because they all share their knowledge, and they can check the documentation afterwards to be sure.

When someone is joining a new team, they’re often hesitant to talk to the other team members, because the new person doesn't know them yet, and they don’t want to bother them. This task is the perfect excuse to connect with the team. Everyone knows it’s their job, that they’re doing it for the team, so the existing team members won’t mind making time for the new joiner.

Hold architecture reviews

You can hold small architecture reviews with multiple people from the team. You don’t have to make it a polished meeting. The point is to keep it conversational, draw on a whiteboard and explain the thought process while every team member jumps in with details and shares opinions.

This shows the new engineers that their questions are relevant too. They get a chance to join the discussion. The meeting isn’t all about knowledge sharing; it’s also about bringing the team closer together.

Tip from Facebook

A standard practice engineering managers use at Facebook is to let any new engineer know that you expect them to question everything. It’s not only about asking questions, but about questioning decisions and assumptions as well. A fresh set of eyes can be powerful.

Either you get great input, or they learn a lot about the team's decision-making process by questioning past decisions, because you explain how the team made it. Even if they don’t agree with a decision, this is great insight into the thinking of the team.

How do you clear time for knowledge sharing in an engineering team?

Make it part of the routine

In my experience, when you have to clear time for knowledge sharing, it's not going to work. When the deadline is coming up, and you need to choose between writing documentation or shipping a feature, you’ll focus on shipping. The right way to go about it is to make it a part of your engineering culture.

Knowledge sharing in your engineering team shouldn’t be an extra task but something everyone does naturally. This way you pay its price upfront. Decide how much time to spend sharing knowledge, what methods to use, and make that a part of your culture.

Sharing sessions

We used to have sharing sessions at the weekly team meeting. People shared things like what they learned from the codebase, or how they fixed a bug and what they learned from that. The point was to share anything that they learned.

The idea is to make it regular with a low cost. Make it a part of the schedule, so people don’t have to sign up for it, or commit to it; it’s table stakes.

Documentation

It’s the same with documentation. If you leave it to the last minute, you will likely skip it. If you make it a part of your process, you continuously update it.

You can make it a rule that the team won’t accept commits without API documentation. That makes writing documentation a part of the process, so everyone will calculate it when taking their tasks.

Sharing is part of Facebook’s engineering culture. Facebook Workplace helps with this, because whenever you achieve something or make a decision, you can post about it. Others see it, like it, you get street credit, and your name as a software engineer grows.

What tools do you use for knowledge sharing in an engineering team?

Internal chat tool

An internal chat tool like Slack is a must. It's good for morale and provides a channel for different discussions between colleagues.

Internal wiki

You also should have an internal wiki. A wiki or collaborative documents are the best tools to handle your formal documentation.

Internal social tool

Facebook Workplace is a great tool. You have an internal newsfeed, groups and all the other features Facebook has.

It’s a company-wide communication tool, which expands the scope, because you get to learn about what other teams are doing. Teams usually have their own private groups. These groups are a perfect place to document the decisions you make for your project.

Writing a post is low cost. Just put in your thoughts about a design decision you’re about to make, what options you’re considering, and you can have a discussion in the comments. You can follow up the conversation with a post about the decision you ended up making.

It’s also searchable, which helps new joiners catch up. When they want to know how and why a decision was made, they can search the group and read the entire conversation. You even get to see details like who was for a decision and against it.

Having these conversations in a newsfeed also helps with managing different time zones in a remote engineering team. This asynchronous element makes it possible for remote team members on the other side of the earth to keep up with the discussion and share their opinions.

It has many more functions beyond this. For example, we used it at Facebook the way developers generally use Stack Overflow. Most teams have their own Q&A groups where people post their support requests and help each other.

How do you encourage engineers who are reluctant to take part in knowledge sharing?

My philosophy is to play the long game. Pressuring your team members to share more is a bad way to go about it. I try to make sharing knowledge a more explicit part of the culture, so that person ends up sharing more in a few months.

Here are some tips to build a knowledge sharing culture.

Reward it

The obvious way to encourage knowledge sharing is to reward it. Money is far from being the only reward you can use.

For example, Facebook Workplace rewards posting with likes, or you can publicly call out someone who puts a lot of effort into knowledge sharing. These rewards make a big difference.

Make it fun

The second trick is to make knowledge sharing fun. Writing documentation is boring, and preparing for a presentation is a lot of work. Try to make it easy and fun.

Story from Facebook

Facebook has offices all over the world and employees get to travel to other offices for free with business reasons. As it turns out, software engineers are very innovative when it comes to figuring out business reasons for free travel.

My team was based in London, and we worked with a team in New York for a while. We were struggling with effectively analyzing data. One of my engineers came up with the idea to fly our team to New York, and hold a data week, where the two teams analyze data together.

I'm pretty sure that the motivation was to get a free week in New York. Still, it was the most productive week we’d had for a long time. It took a lot of preparation, but people didn’t mind, because the traveling made it fun.

This is just an example; there are far more affordable ways to make knowledge sharing fun.

Make it attractive

Make sharing knowledge in your engineering team more attractive. Try to connect it with the goals of your team members.

For example, improving one’s English could be a goal. You can easily tie that to public speaking, which can be used to share knowledge within your engineering team. Practicing with colleagues is helpful, because there are no consequences if it doesn’t go perfectly, and you can encourage them to move to bigger audiences as they get better.

Lead by example

Leading by example is essential to leadership at all levels. Don’t just talk about the importance of knowledge sharing, but show your team members why it’s essential for them to take part in it. Make sure they understand what is there to gain for them and for everyone else.

What made knowledge sharing successful at Facebook?

The success of knowledge sharing always comes down to your engineering culture. Facebook’s culture is based on the company values. They focus on scaling up the culture, and making sure that everyone lives and breathes it within the company.

High transparency

They’ve built an extremely open and transparent environment. It takes some adjustment on the part of new joiners. For example, most engineers aren’t used to people coming up to them and telling them they messed something up, but it’s okay.

Management also works in a transparent way. The main reason behind the controversies around the company not affecting morale negatively is that employees always know what's happening internally. This streamlines everything within the company.

Focus on communication

Facebook’s culture is based on communication. As a company grows, you need to use more documentation, because talking to everyone isn’t scalable. They still manage to keep communication and human interaction as the backbone of it all.

It boosts knowledge sharing and does much more. It also helps everyone to get to know new people and build relationships, which creates more collaboration and more ideas.

Facebook works in a pragmatic way. They don’t have company-wide prescribed processes; they let each engineering team figure out the way they work for themselves. The motto is, “Hire smart people, give them a mission, and get out of their way.”

About Balázs Balázs

He started programming at six years old and has been in love with software engineering ever since. His professional career started on the server-side. Later he moved to mobile development because of the first iPhone’s release. This has remained his focus ever since.

He has worked at 10 different startups, and he’s still in love with the atmosphere these companies have.

He joined Facebook, where he spent more than five years as an engineering manager. He plans to spend the next 10 years of his career focusing on climate change. His current goal is to build a more sustainable and more livable world.