How We Cut Process and Drove Growth at Synthesia

I’m an engineering lead at Synthesia. This calendar is a pretty good representation of how many meetings I have in a week.

‎And I’m not an outlier. Here’s a calendar from one of my reports.

‎At Synthesia, we try to keep processes to an absolute minimum. That includes meetings, project management ceremonies, standups, and deadlines. We only have one meeting a week—a 15-minute sync on Monday afternoons—and we’re thinking about cutting it because it’s redundant.

Synthesia is doubling its traffic every year, and we attribute a lot of our success so far to this low-process culture. Ultimately, we don’t instil and reinforce this culture because we like it (though we do) but because we think this culture is a driver of effective engineering.

To show why we think so, I’m going to walk through how we deliver projects, how we hire engineers that fit our culture, and what you might need to build a similar culture. But first: The why behind the how.

The values behind our low process culture

The way we run Synthesia emerges from particular principles, and the processes that result feed back into and reinforce these principles.

• Ownership: We assign ICs a huge amount of responsibility, including testing, planning, and analysis. Our low process culture frees ICs to focus on their work instead of endless meetings, but we expect them to handle much more than just coding.
• Outcome-based effectiveness: We focus on impact and outcome above all else. ICs are never given tasks and commanded to execute; instead, each IC sets goals, creates plans, and builds metrics that they build toward.
• Peer-based collaboration: We don’t emphasize hierarchy between juniors and seniors. Instead, we hire primarily seniors, treat them as peers, and build trust between them as colleagues. We collaborate, but we respect autonomy. The way we work emerges from these principles, and ideally, each project reinforces them. When we deviate, we know how to figure out why or how our system might need to be improved.

How we deliver projects

When I give the elevator pitch on low process, the first question I always get is, “How do you deliver projects?” Many people – understandably, after years of heavyweight Agile and Scrum processes – don’t quite realize how unhelpful all those ceremonies, meetings, and rituals can be.

The more we’ve turned the process dial down over time, the more we find the work actually benefits from fewer interruptions. This doesn’t mean, of course, that we just let our engineers run wild and hope for the best.

We set our objectives based on company strategy, give engineers a lot of autonomy, and trust them to radiate the information we need without us having to drag it out of them.

1. Strategic alignment

Before we touch a line of code, we plan. No one starts working until we build a PRD (Product Requirements Document), and each PRD depends on strategic alignment. Here, we’re focused on finding ways to move the company in advantageous directions, and we include engineers, leads, and product managers in these discussions.

The resulting ideas can be ambitious (a good problem to have!), so oftentimes, a PRD will extend beyond what can be achieved in a typical project cycle. As we build out these initiatives, we also analyze the market and our competitors.

Take a new feature of ours, a video player, as an example. As part of Synthesia 2.0, we're developing a video player to enable interactive, personalized, and fun video experiences. The grand vision is to reinvent every step of the video production pipeline so that we can help entire businesses transition to a video-first world. With that essential vision established, we adopt it as a strategic direction that new projects can move us toward.

From this thesis, we start identifying potential projects, and product managers start formalizing these ideas into PRDs. A few projects that have already contributed to this vision, for example, include a design upgrade to the player, content translation, chapters, and thumbnail previews. Each supports the big picture idea, and the usage of each feature verifies the theory that betting on the player is a good idea.

At this stage, the PRDs describe the vision for a given product that includes everything we’d like to implement. We don’t set any timeline limits because we’re focusing, first and foremost, on identifying a business goal and determining which metrics we’ll try to move as a result.

From here, we put our money where our mouth is and make a bet. By allocating a certain number of engineers to the initiative for the quarter, we see to what extent they're able to move the needle.

2. Project planning

In the “project management triangle,” most teams fix timelines and scope. The thinking is usually a result of processes that assume timelines have to be predicted ahead of time and that the feature in question needs to do exactly what they planned it to do.

As a result, teams can only dial in resources by hiring more engineers or burning out the ones they already have.

We make a different tradeoff by fixing timelines and resources and leaving the scope of each project up to the engineers to determine.

This part is crucial: If the scope isn’t flexible, process will inevitably leak back into the company as engineers and PMs try to pre-plan. The analogy we lean on is betting. Each project relies on a bet that says, given X resources and Y timeline, we can probably get Z project done. We’ll bet, say, three engineers and three months on a project, but we won’t predict the scope of the work that will be done. We’re betting on the project as a whole and the metrics that the project will move, but we don't detail exactly what the project itself will include.

In the video player example from before, the engineers and PMs will receive the PRD and know from the start that they have, say, six weeks to work on the project. Again, before an engineer touches a code editor, we think through the work. Working with the PM, the engineer(s) in charge of the project will draft an RFC (Request For Comments). Here, the engineers and PM will work to understand the problem and figure out the first thing they can ship to users that will contribute to the business objective at hand.

In the video player example, the chapters feature had the potential to range from simple to complex. The smallest version only allowed users to define chapter titles and timestamps, but numerous other features, including nested chapters, automatically suggested chapters, etc., could further enhance the experience but could also overload a single project.

In the RFC, the engineer and PM crystallize the work to eliminate the risk of detours, determine the metrics that will measure success, and uncover any technical hurdles. RFCs are open to the entire company, so anyone can ask questions or point out potential problems. Other engineers and PMs are typically the most common commenters, but anyone can contribute a thought or ask a question.

3. Execution

With the RFC documented and the comments addressed, the engineer begins to execute. This is when project managers I’ve talked to start to get nervous: How do you know they’re doing the work? How do you know they’re doing the right work? How can you make sure they’re not blocked? The temptation is to poke, prod, and interrupt, but we learned from our friends at Basecamp to reverse that instinct.

Instead, we ask engineers to “radiate information” so that interested parties can "subscribe" to updates as necessary. This is where we really cut the process down: We do not want anyone in the company to have to pull information from anyone else. Ever. To do this, engineers publish three types of updates on a regular cadence:

Every day

Engineers write brief, async standups for other engineers and their team lead. These updates take 5-10 minutes to write and give the engineer time to organize their own work for the day and allow the rest of the team to see what they’re working on so they can provide input where useful.

Every week

Engineers publish a PPP or Plans, Progress, and Problems update for PMs, designers, senior leadership, and engineers from other teams. This update tells us about their progress so far, their plans for the next week, any problems they’re facing, and any opportunities for input – allowing everyone to stay updated asynchronously.

Every month

The PM and engineering lead write a workstream review to communicate major updates to company leadership. This document focuses on what we shipped, what we learned from building a project, and how the completion of a project will affect future work.

Throughout, engineers focus on doing justice to the bet we made at the beginning of the project. The six-week bet (our most common timeline) gives us enough time for the project to stand a chance but not so much time that we end up overinvesting in the wrong projects or assuming a project won’t deliver from hasty assumptions. Along the way, the updates above flag any obvious issues that would otherwise be out of sight.

Let’s walk through another project example: Implementing global search. Some of our customers have thousands of videos on our platform, so in the second stage, we would develop an RFC that identifies two ways to solve the problem. There’s a small solution that searches video titles and descriptions and a large version that also searches video data.

In stage three, we make a six-week bet to implement and test the small version. We dedicate enough resources to fulfill the bet—even if the scope shifts during implementation—and the timeline gives us enough space to assess the project once it’s done.

Our metrics might show that the work we're doing is adding significant value for our customers, so we'll continue to iterate until we see diminishing returns.

Alternatively, our metrics might show that the feature isn't as impactful as we hoped, in which case we'll find a way to wrap the project up neatly and move on. Thanks to the bet we took on the small version, we can make an informed decision on whether to move on or invest further and bet on another version.

How we hire for low process fit

After explaining how we deliver projects, the second question we always get is, “How do you find people you can trust to work with so little process?” We incorporate the low culture process into every step of the hiring process to ensure we fit the candidate and the candidate fits us.

Throughout, we return to one theme, one differentiator that distinguishes the candidates who fit from the candidates who don’t: Awareness of impact.

Below, I’ll walk through how we find candidates, how we filter initial candidates, and how we check whether the remaining candidates have both the technical acumen and cultural fit. (Note that there are other steps in our hiring process, including a take-home exercise and an interview with the department lead, but the steps below are the most relevant for finding candidates that fit our low process culture).

1. Finding the right candidates (and helping the right candidates find us)

We focus almost exclusively on hiring engineers who already have deep technical experience.

In a typical FAANG company seniority structure, these companies would usually be deemed senior engineers. Beyond sheer seniority, however, we look for flexible engineers who can be thrown onto projects as necessary and make an impact wherever they land.

The ideal engineer can work through the full technology stack (from frontend to backend) and the full problem stack (from working with PMs, designers, infrastructure, and security to proactively planning and communicating their own work).

For inbound hiring, we try to attract these types of candidates by writing blog posts (like the one you’re reading now!) and using the hiring manager call in the next step to filter good candidates from bad ones.

The call only takes thirty minutes, so once we identify a foundational level of suitability, it can efficiently sort candidates.

For outbound recruiting, we tend to look for engineers who have already worked for companies with similar cultures and working styles. We also look for engineers with CVs that focus on project delivery and project impact.

2. Call with the hiring manager

Once we have a candidate, we schedule a thirty-minute call between the candidate and the hiring manager. The primary goal of this thirty-minute call is to determine to what degree a given candidate is aware of project impact and how much experience the candidate has with owning project delivery.

The hiring manager is one of the engineering leads, and the call revolves around one major question: “What was the most impactful thing you’ve delivered as an IC?” The most common mistake we see is that candidates will try to answer this question by explaining the most technically complex project they’ve ever done. That’s not what we’re looking for, but because many companies are, we redirect.

We want them to walk us through a project they ran that had a big impact on the business. In so doing, we want them to be able to explain the importance of the impact, too. In the conversation, we’ll cover numerous other questions that tie back to that main question, such as:

• How did the project come about?
• Whose ideas was it?
• What problem were you trying to solve?
• How were you aware of the problem?
• What kind of business strategy were you trying to implement?

After we understand the context, we’ll ask them to walk us through the project lifecycle to see how they managed the execution of this project. We’ll ask, for example, “How did you link the work back to the metric you were trying to move?” And if they lack a strong sense of metrics, we’ll ask, "What did you learn from using [X technology] instead of [Y technology]?".

You’d be surprised how many engineers—even ones already vetted as seniors—don’t know why they do the work they do. Some candidates understand our low-process culture immediately because they’ve thrived in this kind of environment before. Others haven’t had this experience but show a strong instinct for impact, measurement, and adaptability. These are the candidates that tend to excel at Synthesia.

3. Technical interview

Despite this stage being a “technical” interview, we don’t break out the whiteboards – this call, too, focuses on impact and asks technical questions that inherently involve users and metrics.

In this interview, the hiring manager and another engineer roleplay a project – a realistic scenario that we really did face. The context: After GPT3’s viral success, Synthesia experienced a surge in traffic, which made our manual moderation process a bottleneck in turning people from visitors to users.

We present candidates with the challenge and ask questions about what they would have done if faced with the same situation, such as:

• How would you scale moderation?
• How do you make this team of moderators more effective?
• How do you help them moderate more quickly?
• How do you provide them with the tooling to review all the content that needs to be reviewed faster?

These questions lead us to another major question and the ensuing conversation: Given three months, how would you progress the project? Here, we're looking for evidence that candidates can evaluate solutions against metrics.

In this example, we're trying to improve response time—that’s the key metric. Ultimately, all we really care about is: Do these solutions solve that? And how do you quickly evaluate that?

By walking through the lifetime of the project from this perspective, we can differentiate people who think about metrics from people who plan by instinct. Along the way, we get a deeper sense of their technical skill, experience, and how they use what they know.

Low culture prerequisites

If you want to build a culture similar to ours, you can’t just cut the meetings and expect a low-process culture to take over. There are some necessary ingredients, and not all companies have them.

• Willingness to hire specifically: We’ve been intentionally specific in which kinds of candidates we hire, which has resulted in a hiring speed that can sometimes feel scary, given the size of our roadmap and the growth we anticipate. But with very specific hiring, we can prioritize company/candidate fit and minimize drag.
• Strong product and product team: Low process and project ownership don’t work if ICs don’t have the opportunity to make an impact. Strong PMs are necessary to help engineers make smart bets and figure out what work will get the company from A to B.
• High engineer-engineer trust: Engineers need to trust each other because every engineer runs independent projects. We run PRs, but they help engineers collaborate instead of being bottlenecks. Because we require PRDs and RFCs before coding begins, contentious points arising during PRs are rare.
• High engineer-non-engineer trust: Engineers need to feel comfortable sharing early work with non-engineers and know that those teams also understand iteration.
• Organizational buy-in: This is not a reactive way of working. The sales person can’t expect to burst through the door and rework the schedule to get a new feature that will close a sale – and leadership can’t want or enable that. We think the ingredients are necessary for a low-process culture and that a low-process culture is the best way to build an effective engineering team that drives startup growth.

Startup = (Opinionated) Growth

In 1975, Fred Brooks taught us in The Mythical Man-month that throwing more bodies at a problem will not solve it faster. In 2012, Paul Graham explained in “Startup = Growth” that the primary differentiator for startups vs. other businesses is the ability to grow rapidly.

Despite these canonical lessons, many startups today still try to model themselves after companies much larger than them. They’ll cargo cult the systems Google built for scalability even though they’ll likely never reach that state or measure their growth rate against established companies even though Google, AWS, Meta, etc., are fundamentally different than any given startup. (We're doubling our traffic every year, for example, and Google is growing much more slowly).

Similarly, small, focused, potentially nimble startups will adopt project management methodologies built for enterprises and developed by people who now recommend abandoning them. Too many engineers end up attending daily standup meetings without knowing why, presenting to project managers who also don’t know why so many meetings are seemingly necessary.

If startups want to grow, they need to be opinionated about how they’ll grow, and that opinion needs to extend from the product out there in the market back inside to the team that’s building it.

We know our culture isn’t for everyone, but for growth and individual impact, we don't know of a more effective methodology.

Even still, we know some people won’t apply because they saw this post, and we know some will. Good. Our growth depends on it.