note: This document was originally written in 2015 (
), and reflects processes from my time co-leading the YouTube team from 2008-2014. As I left in 2014, I was asked by a number of folks to write down some of the key processes we used as we scaled through that hypergrowth period. Some of the insights here have been taken and applied by many other teams as they have scaled as well. Based on their learnings and a conversation with
, I’m working on an expanded version of this concept (working title is
“Rituals of Great Teams”)
if you have ideas/feedback that you think should be included. In the meantime, enjoy this historical perspective!
I joined YouTube in 2008, soon after the Google acquisition, and started on one of the most incredible roller coaster rides of my life. Much has been written about the
accomplishments of the YouTube team—growing from a
(mostly misunderstood) video sharing property
to the platform for millions of creators to connect with audiences all over the world. Interestingly though, very little has been written about the
workings of YouTube.
When I arrived, the team had grown to a couple hundred employees (~1/3rd pre-acquisition, ~2/3rd post). My initial role was owning the monetization strategy, and over the course of the following years, that scope grew and we settled into a pattern where three of us primarily drove YouTube; I ended up taking on ownership of most of the core tech functions (product, engineering, and UX), Robert Kyncl covered the business functions (content, sales, and marketing), and our boss Salar Kamangar was the CEO. The team we constructed was fairly special and was the key to our success.
Though YouTube was a popular consumer property, it was far from a given that it would be a viable long term business and many critics thought it was likely to be Google’s first failed acquisition.
This meant that most of the team that came on board was “
By the time I left in 2014, the team had grown to over 2,000 employees.
We had many growing pains through the years, but became well known as a high-performing, fast-moving team.
had a few interesting challenges:
tartup / big company melting pot:
The company was acquired early
and had to adapt to being integrated into Google, an iconic company already well known for its rituals. But YouTube had its own distinct culture and challenges, so while we borrowed many best practices, we also recognized that many of
didn’t quite fit.
The period from 2008 to 2014 represented enormous hypergrowth—every metric was breaking records regularly, our
and revenue grew from millions to billions, and our team scaled quickly to keep up. In a phenomenon that Reid Hoffman now describes as “
we had to adapt to the breakneck pace at which we were growing.
An intertwined three-sided marketplace
While some businesses have natural separations, YouTube’s business was very interconnected—changes we made in our product rippled quickly through our creator and advertiser communities. A
djustments we made to our go-to-market model had to be synchronized with key product bets. It was quite common for initiatives to be cross-functionally coordinated with a set of engineers, product managers, content partnership managers, marketing folks, press relations, lawyers, and others.
In the early days, this mostly led to a mess. A few symptoms we saw:
Always planning and replanning:
It felt like we were always planning and replanning as the new shiny effort quickly bumped to the forefront and upset everyone’s plans.
Too top-down, too bottom-up:
Teams complained that the process was either excessively top-down (and didn’t allow for creative freedom), or too bottom-up and lacked coherence / prioritization.
Meetings felt chaotic:
Meetings weren’t well planned, often missing the right people or the right context.
Because everything was important at once, the team struggled to make tradeoffs.
Unclear decision making paths:
With such an intertwined business, it was often hard to know where to go for hard choices.
We slowly constructed a set of rituals and best practices that worked well for us.
Over time the YouTube team went from being known for “controlled chaos” to being known as a well-aligned team that could
simultaneously run a
complex business while taking on meaningful strategic initiatives.
Our culture became a highlight—
something our team held on to as a reason to push through hard challenges, and an attraction to new employees.
I’ll admit, while I was on the roller coaster, I didn’t always appreciate the uniqueness of our rituals. When I left YouTube in 2014, I got asked by a number of other company leaders to help them understand how YouTube works. One person,
(Spotify CEO/Co-Founder), was the most encouraging—he suggested that perhaps I could write down a short summary of our key rituals so others may learn from them. What started as an email reply to Daniel, gradually turned into a few pages of prose and then grew from there.
As this doc has grown, I’ve found that it has three primary levels for different audiences:
For people mostly interested in the historical perspective, this front page should give a good summary of how our cadence worked and some of the tradeoffs.
The cadence architects:
For those readers who are generally in charge of setting up planning and cadence for their teams, I’ve found that the little details often matter more than it might seem. So the drill down pages on
work through how each step of the process worked with some of the color behind the specific tradeoffs.
A few folks want to pick up this method and reimplement it directly. Though it’s hard to transplant a cadence from one team to another, a lot of the basic templates are available in the
page as a starting point.
It’s worth noting that this is now an almost decade-old snapshot. Most of the processes here have since been adapted and adjusted by the current YouTube team. And for my own company Coda, we have kept some of these rituals, but also operate differently in a number of ways (more on that in a separate writeup). But since this was such a special team and time period, I’ve found many readers excited for this historical perspective.
A snapshot of the YouTube cadence
While it didn’t happen overnight, the YouTube cadence gradually settled into this pattern:
: 6-month strategic planning and 6-week
The top two parts of the diagram reflect our planning model. At Google, most teams planned on a
, i.e. a 3-month cycle. We found this awkward—three months was too long to commit to in our fast-moving, hypergrowth mode, but also too short for our big aspirations. This was exacerbated by Google’s traditional “70% OKR rule” where you were only supposed to achieve 70% of your goals. So we divided this into two separate processes:
every 6 months (26 weeks) gave us more time to set and achieve meaningful goals—and include every team in the company along the way.
There were two key outputs: (a) a list of
and (b) the
. The process of achieving these outputs was done both bottoms-up and top-down.
The bottom-up process was done with a review of every team’s
in a compressed (and intense) review cycle.
The top-down process involved brainstorming Big Rocks and then driving alignment through a
, where each of the executive leaders would simulate spreading 100 virtual dollars across a set of candidate initiatives.
output was critical to ensuring we actually had alignment. This not only showed overall headcount allocated to teams and Big Rocks, but it showed the matrix of how resources were mapped between them. This forced tradeoffs to be quite literal and less likely to be “fudged.”
(generally 3 very focused weeks) and was very comprehensive (every team in the company was involved)
. While it was an intense 3 weeks, the output was the backbone of how we operated—most YouTube employees could immediately recite the current stack of Big Rocks and had an idea about how their team contributed to them. The process also served as a key step in keeping the team aware and aligned with each other.
every 6 weeks allowed teams to narrow commitments to what they could realistically get done in that time frame. Instead of Google OKRs, which were aimed at “70% success” criteria, these sprints were meant to be true commitments that other teams could actually depend on. We tried to keep this as lightweight at possible, and tried to timebox it only be a couple of days of alignment. We settled on 6 weeks as the ideal cadence, mostly because it aligned to how our iOS releases were staged, but it turned out to feel about right in terms of overall planning cadence.
Forking from the Google quarterly process was not easy, as we still had to collaborate with many Google teams. But we found that shifting to a 6-month / 6-week split planning model was more appropriate for how our team operated.
our strategic plans in place, we could then focus on driving healthy execution on a weekly basis (the bottom “green” part of the diagram).
We had 4 primary types of meetings, and we defined clear expectations for each:
Meetings explicitly for decision
making, with a very small required group of
and a new relevant audience assembled for
each meeting—often with a wide list of optional attendees. A writeup describing the decision (and the options under consideration) would be sent in advance. Examples include Product Review and Deal Review (a forum called
Group information sharing:
These meetings (often l
e) were primarily used for broadcast and
making forums. Examples include our weekly staff meetings, the stats meeting, and our all-hands.
A unique meeting format that we sometimes referred to as “group 1-1s”. These were generally meetings where (a) the attendees are fixed, (b) it’s scheduled at a fixed time each week (and not rescheduled), (c) has a “rollover” agenda. A bulk of our meeting time was spent in targeted group tag-ups.
Since tag-ups took over any project-specific discussions, this left 1-1s to be entirely
(in fact, I would regularly defer topics from 1-1s to Tag-ups since they required the other attendees).
Our weekly cadence was based on several
Avoid ad-hoc meetings.
Definitely the most controversial, but our process was designed to avoid the “just in time” ad-hoc meetings. We found that the trap of ad-hoc meetings had a lot of downsides. First, each one requires schedule coordination of attendees, so it can push discussions out (”can I get 15 mins to chat about X” ends up happening 2 weeks later). But even more importantly, the lack of a clear structure can often lead to unproductive meetings - people don’t know if it’s an information sharing meeting or a decision-making meeting, and it’s not clear what level of prep, etc is required. So a key litmus test for us was minimizing ad-hoc meetings by creating the right regular forums with enough time and the right attendees. Our approach to “tag-ups” turned into a unique way to handle this.
A creative experiment that turned into a hallmark of our process. Many of our meetings included a long “bullpen” period. The time was intentionally unstructured and without any agenda, where the only rule was that you had to stay present. This would lead to many “multi-threaded” discussions happening in parallel, and if you didn’t have anyone to talk to, you could just keep working on your own. Many of these discussions would have naturally become ad-hoc meetings, and instead got handled in a timely manner. It also led to a much tighter leadership team since the list of interested parties in a topic was often different than might have been originally imagined.
Replace read-outs / meetings with broadcast emails:
There were a handful of key regular broadcast emails that the team relied on, including my Sunday night email to the team. We recovered a lot of meeting time this way.
Pre-reads (”Come prepared and expect others to be prepared”).
We almost never “presented” anything in meetings. Materials were always sent in advance, and people were expected to pre-read. Almost all of our meetings were scheduled to be 30 minutes and
often ended early
Rather than jumping to solutions, teams quickly learned how to ask the right “
“ and frame discussions in the right way.
Every time a meeting is moved, it has an enormous butterfly effect on the whole organization as they changed their schedules to match. Also, the level of preparedness for a meeting is directly proportional to the expectation that it will actually happen.
Don’t be afraid to cancel.
With standing forums and materials sent in advance, it’s generally clear
the meeting whether or not there was reason to meet. We often sent out an agenda, resolved the remaining issues, and canceled the meeting.
Many readers will find the above summary sufficient to the spirit of how YouTube operated.
But if you’re responsible for your team cadence or looking to implement these processes, the next few pages go into a lot of detail about how each of these processes worked and include some templates for how to apply these techniques.
A huge round of thanks to the following folks
for reviewing and contributing to this doc. Their comments have made it immensely better (and any remaining shortfall is entirely my fault!): Zach Abrams, Gene Alston, Prabhu Balasubramanian, Clay Bavor, Henry Benjamin, Monica Caso, Nikhil Chandhok, Aparna Chennapragada, Joe Dimento, Andrey Doronichev, Rushabh Doshi, Henrique Dubugras, Ea Due, Daniel Ek, Phil Farhi, Larissa Fontaine, Wade Foster, Dean Gilbert, Cristos Goodrow, Dan Greene, Manik Gupta, Deeksha Habbar, Nina Hammarstrom, John Harding, Matt Hudson, Nundu Janikaram, Ambarish Kenghe, Andrey Khusid, Gabor Kiss, Curtis Lee, Matthew Liu, Noam Lovinsky, Aagya Mathur, Apoorva Mehta, Kavin Bharti Mittal, Hosain Rahman, Shiva Rajaraman, Peeyush Ranjan, Vivek Ravisankar, Sam Rogoway, Jonathan Rosenberg, Satyajeet Salgar, Naren Shaam, Lane Shackleton, Evan Sharp, Dror Shimshowitz, Ben Silbermann, Jonny Simkin, Angad Singh, Baljeet Singh, Shan Sinha, Shantanu Sinha, Oskar Stal, Hemant Taneja, Hunter Walk, Andy Wilson, Hans Yang, Tamar Yehoshua, Michelle Beaver, and Irvin Zhan.
At the bottom of each section you’ll see an FAQ with commonly-asked questions I’ve received over the years. If you want to contribute more comments / thoughts, feel free to click here to see the
P.S. To see other docs from Shishir, check out