Engineering culture is not defined by free food, perks etc, it's the culture which consists of principles, values and practices that everyone in the team follows and contributes to in some way. Most companies look for those values when hiring candidates as they want to make sure the future team member can blend well into the team quickly and easily. Culture comes when there are teams, a single person team cannot really have a culture.
Since the team is the backbone of culture, let's talk about working in teams; what are the benefits and how to work and collaborate efficiently which leads to growth, healthy and friendly environment and helps in building psychological safety.
Benefits of Team
Sharing the top three benefits when you work in a team setting.
One of the biggest benefits is detecting problems early and quickly based on the feedback from the team. When you work and collaborate with a team (if you have a supportive and healthy culture), you get quicker feedback in many forms which helps identifying issues very early in the process. Examples like design documents and code reviews.
Having a team gives ease of mind, like in the absence of someone the team can still perform effectively and efficiently. The idea behind is the number of people needed to get hit by a bus before the project is completely doomed, in ideal team setting the bus factor is low and should not be an issue. Similarly when taking time off, an engineer who works in an isolated environment is likely to either not take time off or be pinged frequently. A great team is only possible when knowledge sharing is part of the culture, we discuss more on that later in the article.
Pace of Progress
Progress pace can vary depending on team size and work, having team members working on the same project an help you with unblocking many blockers, e.g. stuck on a piece of code which might be new to you but someone has already solved it is likely to help you to move forward, another example would be the senior or lead engineer who can unblock from team dependency problems like DevOps.
Working well on Teams
Working well on teams comes with some basic qualities that everyone should have or learn to follow. Some of them are mentioned below:
When it comes to mistakes made by Engineers, it is always a better choice to play it as a team and don't blame on an individual persons, this often happens when a junior engineer made a costly mistake, usually these type of issues are later handled in incident review and postmortem where its the responsibility of leads/senior engineers to make sure that the mistake was done by the team either due to lack of best practice or process.
Respect is the most important trait here. Respecting everyone irrespective of their rank is highly encouraged in healthy teams. Everyone has different experiences and opinions, and listening and understanding them is everyone’s job.
Have shared vision and values
Just as a company has some sort of Goal system which adheres to a common goal and vision, similarly, teams should have a common goal and every member should follow and have faith in that so that discussions when building something are always aligned with that goal, vision or value. Focusing on this greatly reduces the difference in opinions.
Be kind and polite
Never attack someone or judge that someone is attacking you on a personal level. It's all about being kind and polite, this comes when there is judgement involved, example like design document or code reviews. The opinions and suggestions should always be written politely so it does not offend someone, example can be, 'this is wrong, fix it' vs 'I think it can be improved by doing XYZ, can you look into it please?'
Now you know the benefits and ways to work well. Let's discuss how we can take this further by focusing on one of my favourite core values: Learning Continuously, very common across the tech industry.
As emphasized previously the importance of teams, one big challenge that teams face is the efficient way of collaboration, getting feedback and learning new things, in other words knowledge sharing, which is a standard practice that should be followed to have a great team and healthy culture.
Knowledge sharing is a practice where the goal is to make everyone aware of what's going on in the team, organization or a company. This can be achieved in many ways with added benefits.
1 - 1 with Mentor / Buddy
This is part of most onboarding processes in mid to big sized tech companies, where every new engineer is assigned a mentor or a buddy, the goal is to help the hire to have a smooth process in terms of understanding current processes and codebases. This will help initially quite alot in setting up the baseline and going from there. Even after months mentor or buddy can help in finding useful information.
Very common way in every tech company is to use some tool for synchronous communication, Slack is mostly used across the industry. This focuses on solving quick problems, like asking specific questions related to finding something, or a quick update on something, etc.
A broader meeting among engineers from different teams usually known as tech talks. The idea is to share knowledge among different teams by showing what you or your team has been doing on a higher level from design to architecture. This is one of my favourites, it gives you the knowledge that's hard to extract or find and reuse work if possible by collaborating with that team.
Newsletter is more detailed information that is useful in general for everyone at the company, it could be team specific technology, software releases or sales / business related updates divided into separate categories shared via mailing list. Newsletters usually have the option to subscribe and unsubscribe them which comes in handy when you receive too many newsletters.
Documentation is another great way, it comes with many types, some of them are:
This focuses on design related documents that are initiated in the planning phase. This helps understand and share knowledge right at the beginning which can be reviewed by seasoned Engineers to help and resolve issues related to design, thus learning from each other.
A centralized place like Notion or Confluence, mostly related to existing processes involving final design documents, System Architectures, Workflow, Dataflow etc, this helps in many ways, like understanding the system, reusing the component, etc. This is written for a broader audience outside team scope.
Code comments: Code comments are helpful when you are trying to understand code, either for a review or using the function. Sometimes code comments have some usage examples.
Unit Testing: Unit test can be treated as practical documentation, it's the first user of the code and helps with basic understanding of how to use a function.
Tutorials: Each codebase usually has a readme file that is used as a guide/tutorial for new contributors of the codebase, for example like setting up a local environment, using certain functionality, testing in a dev environment etc.
Knowledge sharing via code review is one of the most effective. It's the place not only to review but learn from others their approaches and ideas behind the implementation which may lead you to use that in your project. Same goes the other way, the author can learn from the comments made by the reviewer. (A separate Code Review article is in the queue)
Code search is very useful if you have a massive monolithic repo or many small mini repos. This is one stop shop to search for code that can help prevent duplicate work, optimised code, or better usage of some service etc.
The extent of these depends on various factors, company size, goals and growth. Smaller companies might have less of them compared to big companies.
In this article, we talked about some aspects of the Engineering Culture; team benefits and working well on teams with focus on the knowledge sharing approaches for a healthy and learning environment. If your team is missing something, learn and encourage them to adopt as it has tremendous benefits.