The Ultimate Coda Handbook for Engineering Teams

Explore

The Ultimate Coda Handbook for Engineering Teams

1. Team Hubs

A single source of truth for your team's status and progress.

How much of your engineering team’s time is spent tracking down the right information, copy-pasting between tools, or sending out manual updates instead of producing code?

More likely than not, you’re in the same boat as hundreds of other engineering teams I’ve worked with—you constantly wish your engineers had more time for execution. It’s not an oversimplification to say that the primary job of an engineering leader is to make your engineers more productive, saving them time and energy to put back into designing and coding.

Working across data silos makes it harder to balance competing priorities like bugs, tasks, or on-call duty for the team. And simply knowing where to find meeting notes, architecture diagrams, or the latest versions of documents can become a daily struggle.

The most valuable resource of any engineering team, time, is often squandered because crucial information is spread across countless documents, spreadsheets, dashboards, and rogue applications. Engineering leaders have to go looking, and the data and docs they find are often duplicative or outdated.

One of the key things that convinced me to join the team at Coda was seeing how Coda was designed to minimize informational sprawl. In Coda, teams build interconnected and dynamic team hubs that act as a single source of truth. They are home to your strategy notes, design docs, tasks, meeting notes, and everything in between. Perhaps most importantly, they bring tools and teams together, pulling in your bugs from Jira, embedding your mocks from Figma, and so much more.

In addition to team hubs for each team, create a functional hub for the entire Engineering org. Similar in principle to a wiki at first glance, this functional hub is much more. It contains key information that is shared across all engineering teams - your architecture, toolstack, processes & guidelines.

⁠

Why the best engineering teams choose Coda for team hubs.

In this section, I hope to demonstrate how an effective team hub connects or replaces dozens of tools—while increasing alignment and execution.

1. One link per team. Standup notes, design docs, tasks, and dashboards, all together.

If Hollywood made a modern spoof on today’s workplace, surely “Where’s the link?” would be the running joke.

How often do you hear that question each day? It’s pervasive across meetings, Slack, email, and in person, too. When your team is responsible for hundreds of documents, sheets, diagrams, and more, all with varying degrees of accessibility, link sprawl is inevitable.

As your team’s single destination, Coda consolidates tens or hundreds of links into the single link your team needs. Standup notes, writeups, tasks, design docs, dashboards, and more are all organized inside one place—your team hub—that reduces ambiguity and eliminates the “Wait, where are we?” interruptions.

At Coda, we believe that teams should design tools to fit them, not be constrained by one-size-fits-all apps. Need a new place to take notes? Create a new page. Need a shared launch checklist? Add a table. Coda is designed to evolve with your team as you move through the entire product development lifecycle, from ideation to launch and beyond.

2. Hubs offer better organization and flexibility compared to traditional wikis.

Have you ever noticed that smaller companies tend to reference wikis and larger companies refer to documents? Lifting an example from one of our customers, Meesho, a prominent resale platform operating in India, originally consolidated their small team’s knowledge in a wiki called Meeshopedia. But, as Meesho hit hypergrowth, the platform encountered limitations with their wiki’s structure.

As Meesho experienced, teams quickly outgrow the limiting structure of wikis. The “pile of pages” model starts easy but quickly grows out of control, making it nearly impossible to keep information up to date and easily discoverable by your team.

I’ve found that the team hub model better suits companies of any size, especially when used as a network of connected hubs. The team hub model is explained in-depth in

The Ultimate Confluence vs. Coda Evaluation Guide in 2023⁠

, but here’s an excerpt:

Coda’s workspace home provides simpler organization: Since each team and project can have its own separate doc, and you can group them together with folders, it is often much easier to way-find. For example, if I’m looking for my team’s standup and I’m an engineer, I might go into the engineering folder which contains all of the engineering team’s docs, find my team’s doc, and then with a much smaller subset of pages be able to easily find the standup page.

Multi-homing gives you flexibility for where information lives: A subtle, but important difference here is that content can live in multiple places in Coda––this means that the same table (say our company OKRs), or the same page (say our travel policy) can be included in multiple docs. This means that I don’t need to leave my team’s doc to review our OKRs or find our travel policy. Both can be included within our, and every other team’s, doc. And when each team member updates our OKRs or the HR team updates the travel policy, everything seamlessly updates across docs.

3. All your tools are integrated into one place. Coda connects to your engineering tool belt.

I’ve found that in a world of isolated spreadsheets and documents, knowledge becomes outdated as soon as it’s shared. This means that your team is forced into and endless search for the right data as they try to keep track of updates across 10s or 100s or docs, sheets, and apps.

Great engineering teams, by contrast, avoid sharing stale data and eliminate duplicating efforts by centralizing reports and documentation in a central hub. When everything lives in a single doc, you can:

2. Embed and sync content from anywhere:

As engineers, we typically require information from multiple different tools to make decisions effectively. And often, integrating different sources is a manual task. Great engineering teams centralize their information into a single surface that allows for more informed decisions—without cobbling together the most recent snapshot from ten different sources and hoping there’s enough data to make an accurate decision.

When engineering teams first start using Coda, they often do so alongside their existing tool stack. But after working with many teams over the years at Coda, I’ve discovered that there’s an inflection point where many team realize they can actually replace many costly and imperfect tools. And often it’s the simple things: Do you really need a dedicated tool for meeting polls during Zoom? Or to build a better dashboard from your Jira data? The list goes on. Because Coda’s building blocks—text, tables, buttons, automations, and more—can be configured and connected in endless combinations, you can leverage Coda in place of your bug tracker, wiki, knowledge management system, etc. You can also save thousands of dollars per year and countless overhead costs.

4. Automations and AI remove busywork. Send updates, summarize notes, and run workflows.

When you rely on your team to close the loop—manually circulating meeting notes, sending Slack reminders, or changing task statuses—you either waste valuable resources or fail to share updates broadly. Neither are favorable outcomes but there isn’t an easy way to get around this. Your options are mostly to find a program manager to support, find a free intern, or set up some messy Tray/Workato connections.

Finally, Coda AI allows teams to ask questions about their document, delegate repetitive tasks, reconsider content creation, and obtain insights quickly. For example, instead of fully writing out my thoughts in a writeup, I can give Coda AI a few bullets and ask it to elaborate in prose to create my first draft. Instead of searching for the answer to a question in your engineering knowledge base, for example, you can ask Coda AI a question and get an answer sourced from across your docs. We’re still in the early stages, but it’s made an immediate impact on my work, just from not manually searching for insights and information.

⁠

How to get started.

You’ve made it this far and are interested in giving the team hubs model a try—great! I recommend that most engineering leaders start by creating two different types of hubs for their organization.

Get started with a team hub.

A central place that becomes the home for a specific team. Contains their docs, writeups, tasks, OKRs, roadmaps, meeting notes, and more.

⁠

Create my team hub

⁠

Get started with a department hub.

A hub for information shared across teams, like onboarding, training, architecture, coding guidelines, and more.

⁠

Create my department hub

⁠

What’s the difference between the two? Team hubs are the places where your teams work day-in and day-out. They house information about a specific team or project, and because they are living, breathing hubs, the information changes as the project progresses. Over time, these can be archived as projects are completed or reach the later stages.

Department hubs, on the other hand, are similar to traditional knowledge bases in that the information changes less often, but the information needs to be referenced frequently by new hires and other stakeholders. Think of this as the single link you’d hand a new hire to get them acquainted with your team.

Want more details on what to expect and how to get started? Read on!

1. Create your team hub for an individual team or project.

Here’s a quick overview of what you’ll find when you

create your own team hub⁠

About us & Team pages

Features & roadmap

OKRs & planning

Weekly kickoff

2. Add a central department hub to connect across teams.

Here’s a quick overview of what you’ll find when you

create your own team hub⁠

Department hub

Onboarding & Learning

Using AI to streamline information gathering.

3. Import your data from other sources.

Your new team hub becomes a single source of truth as it centralizes and connects to all of your data sources. I’ll briefly go over the different ways to bring data into Coda, and I’ll link out where necessary for more detailed instructions.

⁠

4. Automate your hubs so they run themselves.

Last but not least, now that you’ve set up your teams and brought in your data, it’s time to create your first workflows.

Reminder, you can make these as simple or complex as you wish, from sending a simple Slack reminder, to updating tasks in Jira, and more. See this

how-to video⁠

from the Coda team to set up your first automation.

Automatically send a Slack message reminder to update OKRs or to warn if a bug threshold is crossed.

⁠