Why is culture so important to the success of an engineering team? Well, without a strong culture, the serving infrastructure team at Notion might be overwhelmed by its mission. The nine-person-strong outfit is responsible for ensuring that Notion’s back-end services — there are more than 500 service endpoints — are up and running and built to scale.
Their work directly affects the company’s bottom line, both now and in the future, which is why Chuanying Du, engineering manager, works to cultivate a culture of collaboration with other teams. Du also told Built In San Francisco that given the task at hand, he specifically tries to keep the mood light.
“Infrastructure work is high stakes,” Du said. To counteract this, we incorporate fun into our work, such as emojis, memes and jokes. We share stories about our wild on-call experiences and the worst incidents we’ve encountered in our work, all while making jokes and laughing together.”
Notion provides a single platform for teams to create wikis, work on shared documents and manage projects.
What are three words you’d use to describe your engineering team culture? And what does that look like in action?
Collaboration, reliability and fun! My team, serving infrastructure, consists of only nine engineers and we are responsible for ensuring the reliability and scalability of all Notion back-end services. Notion has more than 500 service endpoints written by hundreds of engineers and it is impossible for one team to know all the details behind them.
We collaborate with other engineers to identify the urgent root causes or optimize performance. And instead of directly owning product features, we enable the product team to do so. This makes us more efficient and increases collaboration. We are an enterprise-facing business and need to provide 99.99 percent uptime reliability for our core functionality. This is not a trivial challenge. Reliability extends not just to our code and architecture but also to our processes and culture. This includes being reliable in following up on tasks, handling customer requests, support tickets and more.
Infrastructure work is high stakes. To counteract this, we incorporate fun into our work, such as emojis, memes and jokes. We share stories about our wild on-call experiences and the worst incidents we’ve encountered in our work, all while making jokes and laughing together.
Every incident is a good opportunity for team-building because everyone is fully aligned on the same goal.”
As a leader, how have you worked to cultivate this type of culture?
Building trust is essential to a strong team culture. I always aim to build trust with team members and really put myself in their shoes and help them shine. It takes time, but people see your effort and know you are truly rooting for them.
Once you gain someone’s trust, doors of opportunity open. You can give them a chance to try new things, mitigate information gaps and more. During our team meeting, we give kudos. We started with only one or two kudos per week and now we give more than 20 per week. This amplifies trust and encourages growth together as a team.
Some other helpful team-building tips I use: Create rotations to give everyone the opportunity to own and drive something, whether it’s asking ice-breaker questions, hosting retrospective meetings or doing a deep dive session. Afterwards, everyone understands a lot more about the task and the person. Also, generate fun! Every incident is a good opportunity for team-building because everyone is fully aligned on the same goal and trying to solve the problem, all while learning a lot of cool hacks and tools along the way.
What are some ways this culture sets the engineers on your team up for success and allows them to grow and thrive in their careers?
As a manager, a common task is to provide an estimation of how many months are needed for a project. Most of the time, managers don’t know all the technical details, so their estimation can be off by a lot. Without trust, the manager may not fully trust the number provided by their team, either. We might spend a lot of time collecting information and coordinating with tech leads before reporting back, which can cause confusion and guesswork. This can result in information lost and energy wasted. The individual contributors did the actual work but never got recognized, and the senior leaders don’t necessarily get all the info they want.
With trust, the manager can give their best estimation and invite ICs to the thread to correct themselves. For example: “Hey, regarding project ‘x,’ I thought two months should be good. ‘Y’ can you chime in to correct me?” ICs jump in with all the context, and with trust, it feels very comfortable to correct what their manager said.
