When hundreds of support tickets started flooding in one night, we knew we were reaching a breaking point. Engineering had launched a new feature without support knowing, and we scrambled to respond to customer questions the rest of the night.

But it wasn’t just that. For weeks leading into that launch, Product marketing was poking a dozen engineers to fill out the release notes every week. Different teams were running their own status meetings to keep track of the same launch. Collectively, we were wasting a lot of time trying to communicate.

Notion was growing — we had five engineering teams, and multiple projects were progressing in parallel. But few people could understand everything that was shipping, or why. If we couldn’t find a better way to coordinate across teams, we weren’t going to be able to scale our business.

Every startup has these growing pains. I’ve seen this same situation happen on product teams at Twitter, Oculus, Robinhood, and now Notion (we’re not immune either!). So I thought I’d share how we designed a solution for our own team.

In this piece, we’ll walk through the systems and processes we put in place to keep every team updated on our engineering and product work. We’ve included templates, too — so you can immediately apply the best parts to your own team.

When I joined Notion, one of the first things I did was talk to engineers and designers about the ways that they typically built and shipped products. Some teams used formal task and sprint systems, while others kept updates in one big, collaborative doc.

I’d seen this before: As companies grow, different teams develop different habits, making it difficult to coordinate work. That’s ok! Teams should work however works best for them, especially in a remote work world. But we needed to standardize how we communicated about the work our teams were doing.

But how do you know what to standardize if everyone’s doing things their own way? Figure out what everyone is using mostly the same way, and standardize that.

At Notion, our engineering, product and design groups were mostly centered around three concepts: teams, projects and tasks (you can find our definitions for each below). We spent time defining each component, then codified them in a company-wide doc so that everyone was creating projects the same way.

Agreeing on what not to standardize is important, too. For example, we don’t dictate how teams have meetings, or what mockup tools to use. Pick a couple of ground rules, then allow people to work freely.

Identifying and standardizing these components helped us organize all our work across every product and engineering team. But then, we needed to consistently communicate to the rest of the company about this work and in a language they understood.