#1 - How we increased execution by 10x at Coda | Oliver Heckmann - Head of Engineering at Coda
One feature a day, keeps the doctor away.
Hey there,
This is the first article of the rest of our lives here at Plato. Joke aside, we decided to invest in co-redacting insightful posts with our community members. We decided to launch this using the keynotes from Elevate and Oliver was the first one to say yes so here it is :)
We’re still getting the hang of Substack, and I know it might take time before we find a format that suits you. Every comment, suggestion, or story you share will help us shape this newsletter into a useful, community-driven resource.
So, let us know what you think, what you would like to see more of, how we bring you more value, and what you hate as well => 1-click feedback available at the bottom.
To receive every new post in your inbox directly, simply subscribe below, it‘s free!
With that out of the way, let’s go!
There has been a Pre-Coda and Post-Coda era at Plato. We run on Coda. And to be honest, it is even hard to fathom how we would do without today. Customer Success, Sales, Content Management, 1-1s, Board Meetings, Event logistics… EVERYTHING at Plato starts with (and often remains on) a Coda doc.
On top of that, we’ve always been amazed at the pace they ship new features:
One thing to note at Coda is we have a reputation for shipping thoughtful things quickly. […] For example, we shipped well over 100 features this year already.
- Oliver Heckmann, Head of Engineering at Coda
It’s usually harder to move the needle when a company grows, so how can a company with 200 employees ship that fast?
It was only natural for us to have Oliver Heckmann, Coda’s Head of Engineering join us on stage at Elevate in November 2023 to share with us the secret sauce for Coda’s high execution pace.
I am now excited to share this first article of our brand new Substack. Oliver’s Elevate talk (above) was the starting point of this article and was brought to new heights thanks to community questions and requested deep dives.
For more from Oliver, follow him on LinkedIn. I would also recommend downloading his FREE Handbook for Engineering Teams and Handbook for Planning & OKRs.
How we increased execution by 10x at Coda
Hi, I’m Oliver. I’ve been the Head of Engineering at Coda since 2021. Before that, I spent 14 years as a VP of Engineering at Google, where I ran the YouTube Creator team and the Google Travel & Shopping teams. Along the way, I built a litany of products like Google Flights, Google Shopping Ads, YouTube Content ID, Gmail Frontend, and many more. For the last 25 years, I’ve had the opportunity to lead planning at many different companies, from Pan-European R&D projects to a variety of global engineering teams at Google, to Coda where I lead the company-wide planning process. At Coda, I’ve also been able to learn from and advise many companies on their planning processes.
At Coda, we have a reputation for delivering well-thought-out, complex features with high velocity. In this article, I want to share three ways that helped us boost our execution speed.
A quick aside: A planning primer
It’s worth noting that, for the sake of this post, planning includes various dimensions and altitudes, such as roadmap planning, yearly planning, and quarterly planning. You will need to revisit the structure and output of your planning regularly, as your needs will change over time.
You should decide what frequency is right for you based on the size and priorities of your organization and the strengths and weaknesses of your team. I typically recommend that teams revisit this at least annually. And of course, it’s crucial that your tooling provides flexibility for you to customize and scale your processes for years to come.
Product releases and execution planning are not within the scope. At Coda, we separate our releases from feature launches. We run a daily release train; PRs are included on the release train when it’s ready. Features are gated behind flags. Once the feature is QA’ed and determined as ready, we then enable the feature on Prod. The separation of releases from feature launches reduces the need for release planning.
Insight 1: Follow the Golden Rule of Planning.
I’ll write it big because it’s important:
“Thou shalt spend no more than 10% of your time planning.”
You can print and frame that rule, as it’s one of the key takeaways of this article.
When I arrived at Coda, everything was being planned for the whole quarter: two weeks of planning and the rest for executing. At one point, some teams complained that the resulting plans weren’t good enough, and asked for a third week to prepare better plans. But that would have taken them 25-30% of the time to plan (which is typical in most companies).
What we did instead, was the exact opposite: we cut the planning time in half—just one week per quarter. Some worried that this was an insufficient amount of time and would result in lower-quality plans, jeopardizing execution. But it turned out that the exact opposite was true. After a brief trial, I asked teams to give feedback. They rated the shorter process as more effective while also yielding higher-quality results. By the end of the quarter, KR completion rates were noticeably increased, confirming that the resulting plan was also more realistic. But, most importantly, we got an additional week back so we could focus on building new features, driving more sales, etc.
So the questions are: Why did it work? And, how do you replicate this in your company? This comes down to 3 factors:
Drive focus
Optimize your planning process
Make good use of the right tools
Let’s start with focus: If you spend a long time planning, say two to three weeks for a quarterly plan, you will inevitably have to do your regular day job and also drive planning in parallel—lacking focus on planning.
When you shorten the time for planning to a very short window, it (1) forces everyone to cancel everything else and really focus on planning and (2), more importantly, it will actually ALLOW everyone to do just that. My engineers cannot stop fixing bugs during planning if it takes two to three weeks. But if we condense their part in planning to two to three days, they can ignore all non-P0 bugs for that time and focus 100% on planning.
This becomes self-reinforcing. Focusing your entire time and energy on planning will also lead to higher quality, faster response times, etc., and all of that will lead to planning finishing in less time.
In parallel, you need to run a clear intentional planning process—at every point in time it needs to be clear what every person in the company is supposed to do. Our process is M-shaped, and every step has clear owners, clear deadlines, and a clear page in our OKR document with exact instructions.
Reflection: In the reflection phase, teams write up what they did last quarter, what failed, and what needs to change. This is kept short and shared for offline reading (not meetings).
Top-down guidance: The leadership team then provides short guidance to the teams—providing direction but no details.
Bottom-up planning: The bulk of the time (three of five days) is spent in this phase when teams are drafting their OKRs and adding details. What helps us be efficient in this phase is good tooling to manage dependencies between teams.
Integration: This is a critical phase that some companies forget about—we spend one and a half days on it. During the integration phase, leaders review all the plans, resolve any prioritization or resourcing conflicts, and often work through a large number of open questions. What helps us be efficient in this phase is good tooling and rituals, in particular our bullpen-style meetings for which everyone in the company has to block time in their calendar.
Last but not least, and I’ve touched on it already, is making good use of tools at every step. For example, $100 voting helps teams make better decisions, and they use idea gardens to start planning week with a garden full of cultivated ideas.
The most impactful aspect is how we track planning dependencies. A planning dependency is when one team needs something significant from a different team to be able to execute their OKR. This was a big time sink for me at Google, where our OKR tool did not track planning dependencies so our PMs and engineering managers had to run a shadow process (read: spend a huge amount of time trying to talk to all related teams trying to keep their plans in sync). At Coda, our OKR tool solves this for us. As teams write their OKRs, they add what they need from other teams to achieve this OKR. Those teams get notified immediately and can set aside time for the request (and acknowledge this in the tool), or reject it, or mark it for discussion. I estimate that this tool removes 80% of the meeting time needed for planning dependencies and, equally important, minimizes the chances of some uncaptured dependency ruining your plan before you even start executing it.
So, to conclude, cutting down planning time—if done right—not only gives you time back, it also forces better methods and leads to higher-quality plans.
Insight 2. Integrate Planning and Execution.
“The most important part of planning? Execution.”
In my opinion, the most important part of planning is the execution. The best plans are worthless if you cannot execute them. But in reality, driving great execution is often surprisingly hard.
Many reasons could hinder execution. Here are a few:
Leaders lack insights into how the execution is tracking against their plan. For example, Pinterest was using 100s of Google Docs and Sheets for their OKR planning and execution. They would run these super expensive quarterly business reviews where ops teams would spend 500 hours on average collecting all the artifacts, summarizing, and putting them into a slide deck to present to the team. A once-a-quarter insight into how things are tracking wasn’t enough to course correct, so they moved over into Coda to do monthly progress tracking and having living OKRs.
Plans don’t survive contact with reality. Without a ritual of bubbling up wins/roadblocks and adjusting, Figma’s product team would lay out its roadmap and each story team would move forward on their own. When their progress tracking & coordination meeting moved into Coda alongside their roadmap, they elevated the most important roadmap items and were able to discuss adjustments that they could make to ensure things stayed or got back on track...and give some ❣️ love to fellow teammates doing a great job.
Teams get caught up in one part of their plan (and forget the rest) when tasks become the goal and the actual impact goal gets lost. In a transformational year in repositioning themselves as an AI chat solution, Intercom moved their OKRs into Coda alongside their yearly roadmap and built a cadence around metric tracking along with task progress. With goals right next to how to move them, they were able to move forward with their ambitious plan and keep all the balls rolling forward.
There’s no accountability for teams and goals that were set. Each of the stories above has examples where a ritual—usually weekly or monthly—can help teams hold each other more accountable when the process, tracking, and data is all connected.
I believe one of the main causes of these hiccups is the Planning-Execution Canyon.
The Planning-Execution Canyon.
The following image summarizes the issue.
After doing some research, I figured out that in the average startup, if you put together all the pieces produced during the planning phase, you can quickly reach 200 different documents (including business plans, sales forecasts, user research reports, PRDs, organization roadmaps, etc.).
At the same time, the average number of apps used during the execution phase is 254. That makes it a gigantic matrix of variables that must be taken into account, creating what I call the planning-execution canyon.
Bridging the gap
In most teams, the planning-execution canyon is bridged in manual and expensive ways: intense copy-pasting, tedious reporting, continuous reminders to update documents, etc. Here are a few simple tactics to flip the canyon into a mountain of insights:
Reduce the total number of sources of truth.
Coda solved part of their issue by reducing the number of sources of truth.
What we've done at Coda, first of all, is to make sure we don’t have 200 planning documents. That's crazy. We have one Coda document with all the up-to-date information in it by automatically pulling data from other data sources. We built Coda as a platform that can house your organization’s work from planning through execution, meaning you can integrate your OKRs neatly into your day-to-day without copy-pasting or added manual effort.
Synchronize OKRs with both planning and execution documents.
Then we make sure the execution documents/trackers are updated in real-time depending on the execution progress: planning, OKRs, updates, meetings, and execution, all in one place and interconnected.
A synchronized view of OKRs in both company plans and day-to-day docs bridges the gap between planning and execution and creates synergy and accountability.
OKRs are a great way to align planning and execution: they represent action-oriented objectives on the one hand and a metric-driven execution on the other end.
Most organizations keep their OKRs in a spreadsheet or a dedicated OKR app while their team’s daily execution lives in an array of other tools. When you silo these phases across different tools, you’re creating a disconnect for your team that diminishes the advantages of OKRs. If you embed your OKRs in your day-to-day tasks, it makes it easy for teams to update and adjust them, track progress, and create more transparency. When your OKRs live in the same tool as your daily execution, you can easily create views of your team’s plans for more effective conversations on what’s next, progress, and blockers for each initiative.
Communicate with people where they live.
To gain even more time, the documents become a central app that synchronizes other data sources such as Github, Jira, etc.—and a way to notify teams when changes arise.
I quickly figured that engineers were unresponsive by emails, but very reactive on Slack. We thus made sure documents were integrated with Slack. This applies to other functions, such as GTM.
When a new issue is raised, an OKR is updated or a date is due, engineers receive an automated message on Slack and can act on it quickly. It creates a seamless experience and an equal level of information for all teammates.
Continuously update KRs.
Plans change!!! Instead of fighting against the inevitable, I believe in baking in the need to course-correct due to changes in conditions. This requires OKRs to be updated early and often, but many companies—even Google—only update their OKRs once in the middle of the quarter. This makes it difficult for leaders to track progress against plans, identify roadblocks, and invest the appropriate resources to help their teams progress.
I’ve experimented with this throughout my career, and my rule of thumb is that drivers should ideally update their OKR progress on a weekly, or at minimum bi-weekly, basis. Visibility into OKR progress is vital to support plan adjustment due to ad hoc requests and operational issues. Particularly in the early innings of the quarter, seeing weekly updates, even if the updates are small, allows me to see around corners and get a sense of where we might run into trouble later on. This will also enable the adjustment of OKRs due to ad hoc requests or operational issues and accommodate for disruptions due to changes in conditions (such as a big customer, change in economy, etc).
This requires making OKRs easy to update, thus allowing leadership to stay close to OKR progression. This is achieved by integrating these multiple views so that updates can be made once at the task tracking level and passed through to the OKR view.
But then, more importantly, Coda teams work in team hubs.
Insight 3: Centralize Work in Team Hubs.
To avoid what I call the information graveyard, one of the most impactful changes we implemented was the creation of Team Hubs.
Team hubs are central documents that contain all the info, staffing, and resources of each team. At Coda, teams use a single document in which they organize and maintain all their important information: roadmaps, tasks, product requirements, or design documents.
The centralization allows for a unified platform that becomes a single source of truth: all team members can access, update, and discuss project-related matters.
Team hubs reduce information silos, ensuring that everyone is on the same page and can work towards common goals. Coda allows you to automate the importing and syncing of data from other sources of truth so that team hubs stay organized and you don’t have to worry about outdated information and pages. Here are some great framing and examples; the garden analogy is a favorite.
Or, in Aragorn’s words: one doc to rule them all.
Wrapping it up: Plan more effectively in Coda.
Let’s recap. If you want to 10x your execution, follow these three insights:
No more than 10% of your time is spent on planning.
Bridge the gap between planning and execution through interconnected planning and execution documents: OKRs must live in both strategic plans and day-to-day tasks. Reduce the total number of documents and communicate with people where they live.
Create team hubs to have one single, transparent source of truth for each team. Connect your external tools if needed.
By now, it’s probably evident that planning is never simple. It takes careful consideration from the beginning and requires buy-in across the organization. As part of my journey in strategic planning, I have seen many common issues and patterns of success. Perhaps the most important insight I’ve learned is that it is tremendously important to have a powerful but flexible tool to run your planning process; limitations and inflexibility in tooling directly impact the quality of your plans and the resulting execution.
So, I set out to document the most impactful planning insights I’ve learned—and detail why Coda is the perfect choice for running your planning process. You can connect Coda to 600+ tools through our Packs ecosystem, reducing the amount of manual work your team has to do and assisting in scaling beyond the OKRs of their immediate team. Coda also offers teams flexibility, transparency, and value that specialized apps can’t. With Coda, you can run the whole planning process in a single doc. Coda joins strategy and execution into one place so drivers can easily update their progress from where they’re getting their work done. This gives collaborators and leaders visibility into where they can offer support, and where they’re ahead of target.
Make sure to check my full handbooks on Planning/OKRs and Engineering teams to create your own team hubs and simplify your planning process! I’m hoping both will be helpful for anyone looking to optimize their existing planning process or create a new one from scratch.
Let us know what you thought of this first in-depth article! Was it too long? Too short? Did it bring you value? Do you like the format? Was it actionable enough? What can we improve? We’re all ears 👇
Thanks in advance for the feedback!
Quang, Cofounder at Plato, on behalf of the Plato team
PS: the more, the merrier! If you found value in this edition of the Leader’s Digest, you can share this post in just one click: