Skip to content
Rituals for hypergrowth: An inside look at how YouTube scaled
Rituals for hypergrowth: An inside look at how YouTube scaled
Planning cadence
Weekly cadence
Implementation
Survey
More
Share
Explore

icon picker
Weekly cadence

Driving healthy execution with four meeting types, bullpen, and a broadcast email.
With a macro strategy in place, let’s turn to the weekly rhythm. We spent a lot of energy trying different patterns for this.
As a reminder from the intro, some core principles we arrived at were:
Define four types of meetings (described below) and structure them accordingly. People will learn the patterns and hygiene for each — how agendas are set, how much prep is required, etc.
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.
Use
Bullpen
⁠
time and broadcast emails to shorten and replace many meetings.
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. This takes getting used to, but is a massive time-saver once it becomes part of the culture. It also meant that almost all of our meetings were 30 minutes (even staff meeting, complicated product reviews, etc), and often ended early.
Framing matters: Rather than jumping to solutions, teams quickly learned how to ask the right “
eigenquestions
⁠
“ and frame discussions in the right way.
Avoid rescheduling: My Chief of Staff drilled this into me. First, he showed me that every time I moved a meeting, it had an enormous butterfly effect on the whole organization as they changed their schedules to match mine and then it cascaded through the team. Second, a team or person’s level of preparedness for a meeting is directly proportional to their expectation that it would actually happen. If I regularly rescheduled a meeting, I should expect that people come less prepared.
Don’t be afraid to cancel: One of the positives of setting up standing forums and having people send materials in advance was that it was generally clear before the meeting whether or not there was reason to meet. We would often send out an agenda by email, resolve the remaining issues, and cancel the meeting.

Before we start, an overall map of the YouTube meetings

The next few sections are going to run through the specific meetings that we held at YouTube (following the “4 types” framework). As an overall map, here’s the summary calendar of our standing forums:

March 2024

Week
Today
Feb 25
Feb 26
Feb 27
Feb 28
Feb 29
Mar 1
Mar 2
9:00 AM
9:30 AM
10:00 AM
10:30 AM
11:00 AM
11:30 AM
12:00 PM
12:30 PM
1:00 PM
1:30 PM
2:00 PM
2:30 PM
3:00 PM
3:30 PM
4:00 PM
4:30 PM
February 26, 2024
Tag-up Admin + ChiefOfStaff Sync
, 9:00 AM
February 26, 2024
YT Tech Staff
, 11:30 AM
February 26, 2024
YT Tech Staff Bullpen
12:00 PM - 1:00 PM
February 26, 2024
Product Review
1:00 PM - 3:00 PM
February 26, 2024
1:1 PM Lead - Ads #1
, 3:00 PM
February 26, 2024
1:1 PM Lead - Creator #1
, 3:30 PM
February 26, 2024
1:1 PM Lead - Ads #2
, 3:00 PM
February 26, 2024
1:1 PM Lead - Creator #2
, 3:30 PM
February 26, 2024
1:1 PM Lead - UX Lead
, 4:00 PM
February 26, 2024
1:1 PM Lead - Viewer
, 4:00 PM
February 27, 2024
Tag-up Big Rock #1
, 9:00 AM
February 27, 2024
Tag-up Big Rock #2
, 9:30 AM
February 27, 2024
Tag-up Big Rock #3
, 10:00 AM
February 27, 2024
Tag-up Big Rock #4
, 10:30 AM
February 27, 2024
Tag-up Big Rock #5
, 11:00 AM
February 27, 2024
Tag-up Big Rock #6
, 11:30 AM
February 27, 2024
Tag-up FA: Ads
12:00 PM - 1:00 PM
February 27, 2024
Tag-up FA: Core Eng
1:00 PM - 2:00 PM
February 27, 2024
Tag-up FA: Creator
2:00 PM - 3:00 PM
February 27, 2024
Tag-up FA: Viewer
3:00 PM - 4:00 PM
February 27, 2024
Salar-Shishir-Robert
4:00 PM - 5:00 PM
February 28, 2024
YT All Hands
9:00 AM - 10:00 AM
February 28, 2024
YT Staff
, 11:30 AM
February 28, 2024
YT Tech All Hands (incl Prep)
9:00 AM - 10:00 AM
February 28, 2024
YT Staff Bullpen
12:00 PM - 1:00 PM
February 28, 2024
YT Eng Review
1:00 PM - 2:00 PM
February 28, 2024
1-1: APAC Lead
, 2:00 PM
February 28, 2024
Eng Lead - Ads
, 2:30 PM
February 28, 2024
1-1: EMEA Lead
, 2:00 PM
February 28, 2024
Eng Lead - Core
, 3:00 PM
February 28, 2024
1:1 AreaTechLead - App
, 2:00 PM
February 28, 2024
Eng Lead - Creator
, 3:00 PM
February 28, 2024
1:1 AreaTechLead - Data
, 2:00 PM
February 28, 2024
Eng Lead - Viewer #1
, 3:30 PM
February 28, 2024
1:1 AreaTechLead - Discovery
, 2:00 PM
February 28, 2024
Eng Lead - Viewer #2
, 3:30 PM
February 28, 2024
1-1: Larry
4:00 PM - 5:00 PM
February 28, 2024
1-1: Salar
, 4:00 PM
February 29, 2024
Tag-up: Finance
, 9:00 AM
February 29, 2024
Tag-up: ATLs
, 9:30 AM
February 29, 2024
Tag-up: Legal
, 9:00 AM
February 29, 2024
Tag-up: Marketing
, 9:30 AM
February 29, 2024
Tag-up: HR / Recruiting
10:00 AM - 11:00 AM
February 29, 2024
YT Eng Leads
, 11:00 AM
February 29, 2024
YT Biz Staff
12:00 PM - 1:00 PM
February 29, 2024
YT Product Leads
, 11:00 AM
February 29, 2024
YTX Deal Review
1:00 PM - 2:00 PM
February 29, 2024
1:1 Ex Creator Platform PM Lead
, 2:00 PM
February 29, 2024
1-1: Exec Advisor-1
, 2:30 PM
February 29, 2024
1:1 Ex Ux Ads Lead
, 2:00 PM
February 29, 2024
1-1: Exec Advisor-2
, 2:30 PM
February 29, 2024
1:1 Ex Ux Viewer Lead
, 2:00 PM
February 29, 2024
1-1: Marketing Lead
, 3:00 PM
February 29, 2024
1:1 Ex Video Delivery Platform Lead
, 2:00 PM
February 29, 2024
1-1: Sales Lead
, 3:00 PM
February 29, 2024
1-1: Content Lead
, 3:30 PM
March 1, 2024
YT Stats
11:00 AM - 12:00 PM
March 1, 2024
Dim Sum
12:00 PM - 1:30 PM
March 1, 2024
1:1 Ex Creator Platform Eng Lead
, 2:00 PM
March 1, 2024
1:1 Flex 1-1s
2:30 PM - 4:30 PM
March 1, 2024
1:1 Ex Data Science Lead
, 2:00 PM
March 1, 2024
1:1 Ex Infra Lead
, 2:00 PM
March 1, 2024
1:1 Ex Test Lead
, 2:00 PM
⁠

See
YouTube meeting map
⁠
for a deeper dive.
This map is an accurate summary of my regular YT schedule, with names of the actual people and confidential team names replaced with placeholders.
You’ll notice several overlapping meetings. No, I wasn’t in two multiple places at once 😀 ; those are meetings that happen monthly or quarterly, but I’m showing them here on a weekly schedule to paint a holistic picture.
Altogether, I had about
27
⁠
hours of scheduled meetings a week. Because I tried very hard not to add ad-hoc meetings on top of this, and there was plenty of bullpen and flex time, I found that this was an intense but manageable schedule. [As a fun sidenote: according to
HBR
⁠
, the average CEO spends 79% of their time in meetings, so this schedule may actually have been light on a relative basis!]

Four types of meetings

After lots of debate and iteration, we defined the following four types of meetings:
Group information sharing: These meetings could be largish and were primarily used for broadcast and coordination. Most importantly, these forums were NOT decision making forums. Examples included our weekly staff meetings, the stats meeting, and our all-hands meetings.
Bullpen: We often supplemented these with a
Bullpen
⁠
— unstructured time where everyone is required to stay (even if just working on their laptop). We avoided many ad-hoc meetings because people would just say “we’ll chat about it in bullpen.”
Broadcast email: We found ourselves spending too much time in these forums just waiting to hear updates from each other, so we set up a pattern of sending out a few things by broadcast email so these meetings could stay short. For example, I sent an email to yt-tech-staff on Sunday night with a summary of the past week and key things to focus on this week. [see example
here
⁠
]. Then when we got to the Monday morning tech-staff meeting, we could just focus on people’s questions. Our weekly staff meeting was only 30 mins long (!) with a 1 hour bullpen.
Decision-making forums: These meetings were explicitly created for decision making. There would be a very small required group of recurring attendees, and a new relevant audience would be assembled for each meeting — often with a wide list of optional attendees. A write-up describing the decision (and the options under consideration) would be sent in advance via email to make the process smoother. Often decisions were concluded in the email thread before the meeting even took place. [Sidenote: really wish we had
Dory and Pulse
⁠
back then]. Examples include Product Review and Deal Review (called YTX).
Tag-ups: I sometimes referred to these as “group 1-1s.” Tag-ups were created when I noticed that I would have a 1-1 with one person and want to discuss something that really required someone else too. For example, I held a weekly tag-up with each Investment Area leadership team — the PM lead, Eng lead, and UX lead (as well as other relevant cross-functional counterparts) would attend. We used the term tag-up to refer to any meeting where (a) the attendees are fixed (and guests are almost never added), (b) it’s scheduled at a fixed time each week (and not rescheduled), (c) has a “rollover” agenda (there’s a doc with an agenda and action items, and if you run out of time you come back to the rolled-over agenda items and action items in the next meeting). They could often be pretty casual (like 1-1s).
1-1s: Since tag-ups took over any project-specific discussions, this left 1-1s to be entirely coaching centric (in fact, I would regularly defer topics from 1-1s to tag-ups since they required the other attendees). I had a fixed set of 1-1s with a core set of people (basically my directs and one level of indirects) and then kept flex hours for anyone to be able to book time with me as well. [Sidenote: here’s the
best guide to 1-on-1s
⁠
that I’ve found]

Here’s some key advantages of separating meetings into these four categories:
Separating group information sharing from decision-making forums: This was a critical decision because it meant that we didn’t try to make many important decisions in our staff meeting. And this wasn’t just about the attendees being wrong — often the optional attendee list for a decision review meeting would include all of the folks from one of the group info sharing forums (e.g. all of YT-Tech-Staff were optional attendees for product review). But separating the forums was very important since the meeting had a very different tone and expectations. Some implications:
More focused attendance. If you weren’t relevant to a particular decision being made in the decision making forum, you could skip without worry (but for example, regularly skipping staff meetings didn’t really work). So the group of people in the review were generally all very interested in the outcome.
Reducing the “class-system” created by the org structure. In many organizations, decisions escalate up the organization through the org chart, by mechanism of being reviewed by progressively more senior staff meetings. In this case, we sent a clear message that staff meeting were about coordination, broadcast, etc and that your ability to participate in a decision had nothing to do with your inclusion in that staff meeting.
Decision meetings were very focused, generally on picking one of a set of clearly defined options for a clearly articulated problem. Because materials were always sent in advance and there was a group email thread beforehand, having a decision discussion in the decision forum was greatly preferred to doing it in staff.
Separating tag-ups from 1-1s: In a tech organization, most of your teams have a cross-functional set of leaders. If you do project reviews and strategy discussions in 1-1s, you will almost always end up with a game of telephone. The PM lead for an initiative will go back to their eng counterpart and say "Shishir said xyz in our 1-1," and then the eng counterpart would add it to the list to talk to you about in their 1-1 as well.
Having fixed tag-ups instead of ad-hoc meetings: Remember the core goal is to minimize ad-hoc meetings. A very common request was “can we set up a meeting to discuss issue X?” My natural thought process was to first ask if there was a natural tag-up for that topic and suggest that instead. This helped in a number of ways. First, it ensured the right people were assembled for the discussion without needing do a new calendar coordination process. Second, and perhaps more importantly, it caused natural triage — if the topic wasn’t important enough to be discussed in that tag-up, then it likely isn’t important enough for an ad-hoc meeting.

You can see a detailed breakdown of all meetings in
YouTube meeting map
⁠
. Since the frequency of meetings varied (some weekly, biweekly, monthly, etc), there’s a column that indicates the average time spent per meeting in a given week (e.g. a biweekly 1 hour meeting counts for 30 minutes weekly). Based on that, this is how my time was split between the four meeting types:
Type
Weekly amount (in hrs)
% of Weekly amount
1
Tag-Ups
11
40.5%
2
Decision Forums
4
14.7%
3
Group: Information Sharing
5.9
21.7%
4
Core 1:1
4.5
16.6%
5
Extended 1:1
1.77
6.5%
There are no rows in this table
27.17
Sum
100.0%
Sum
⁠
⁠

Group information sharing (G.I.S.) meetings and bullpen

Our primary G.I.S. meetings were our staff meetings. We had 3 separate “staff” forums:
YT tech staff (and tech staff bullpen)
This was my primary staff meeting, and included all my direct PM, Eng, Ux leaders as well as a few of the critical indirects (e.g. our test and infra leads, our Area Tech Leads, etc). It had ~20 members and this group spent a lot of time together.
The meeting itself was 30mins on Monday morning and was owned by my Chief of Staff.
Before the meeting, usually on Sunday evening, I would send a lengthy and forthright email with my summary for what happened the week before and what I thought the key priorities would be for the following week. That mail was not meant for forwarding, and I was very candid, so people always read it very carefully.
The meeting’s standing agenda items was to review the
launch calendar
⁠
and see what was on track to launch that week and to go through any questions from my weekly email. There were sometimes other agenda items, especially during performance review season, or during H1/H2 planning, but often the formal part of this meeting would end early and we would adjourn into bullpen.
Tech Staff Bullpen came immediately after the staff meeting ended, and was generally very active - the rule was that you had to stick around, even if all you did was work on your laptop. Generally, people would use this time to take care of ad-hoc discussions across teams.
YT biz staff - This was Robert’s corresponding meeting with all of the “business” leaders (esp content, sales, marketing). The agenda was published in advance by Robert’s Chief of Staff, and the meeting generally ran for an hour. Robert and I cross-attended each others meetings to ensure the tech and business sides stayed in sync.
YT staff (and YT staff bullpen)
This was the cross-functional staff meeting that included everyone from tech staff, biz staff, and a few other people.
It was a very large meeting - 60+ people were invited.
The agenda was to go through a staple set of metrics (revenue, viewership, etc) and then go through updates on the launches / events that were upcoming and review the results of some recent launches / events as well. The deck was assembled by a combination of my Chief of Staff and the head of our Data Science team.
The meeting was scheduled for Wednesdays and ran for 30 minutes, though it often ended early. It was followed by a bullpen that followed the same rules as the tech staff bullpen.
There was always a lot of debate about the usefulness of this meeting given it’s size and we tried many variations of it. My view (and a majority but not universal consensus view) was that the meeting served a good purpose if for no other reason than the fact that it forced everyone to get together for YT Staff Bullpen. It was a very useful bullpen since that level of cross-functional interaction is often quite hard to get (e.g. a 2nd level content lead talking to an individual eng lead about a problem).

The other primary G.I.S. meetings were:
All hands: At my level, we held two a quarter - one for just the tech teams (product, eng, ux) and one for all YT employees. We debated holding them more frequently but decided against it because (a) Larry/Sergey did TGIF every Friday and that was well-attended, so adding on another one seemed like a lot, and (b) we wanted to encourage each of the teams (e.g. the Viewer team, the Content team, etc) to do their own, more frequent All Hands. That said, if I were doing this again, I would have held them more often - at least monthly if not weekly (like Google TGIF). One of the costs/sacrifices for being part of the Google company cadence.
YT stats: This was my hands-down favorite meeting at YT.
It was run by our Data Science team for 90 minutes every Friday, and they simply presented a short section of in depth staples, and then a long concatenation of presentations of interesting data findings.
We would regularly get through 100+ slides in 90 minutes (with 4+ graphs per slide), mainly because the data was very well put together and the stories made a lot of sense.
It started as a small group meeting, but gradually more and more people wanted to attend and we eventually started video-conferencing in many rooms around the world to be able to attend. There could often be 100 attendees to the meeting.
Though this wasn’t an official decision forum, it was a “requirement” for large launches to come through this forum. E.g. if you were going to launch something that was going to significantly impact metrics, you brought it to this forum. The team would often walk through a much more in-depth review of the metrics, and do things like “winners / losers” analyzes to see who would be positively vs negatively impacted by the launch.
If there was an issue and it required further discussion, we would generally name the forum where it should be followed up in — e.g. the relevant tag-up, or for more significant issues, a product review.
Dim sum: This was a very fun tradition starting in the early days of YT monetization. About every other week, we would go to a local (very very good)
dim sum restaurant
⁠
. This was not paid for by Google (felt that set the right tone of “you are not at all required to come”), had an open invitation to anyone on the team, and generally about 20-30 people would go. Especially in the early days, we would pick a topic to discuss over lunch — for example, the name
TrueView
⁠
was hatched there.

All together, I spent about
5.9
⁠
hours a week in these forums, but that includes 2 hours of largely ad-hoc bullpen time. Here’s the calendar filtered to the G.I.S. meetings:

March 2024

Week
Today
Feb 25
Feb 26
Feb 27
Feb 28
Feb 29
Mar 1
Mar 2
9:00 AM
9:30 AM
10:00 AM
10:30 AM
11:00 AM
11:30 AM
12:00 PM
12:30 PM
1:00 PM
1:30 PM
2:00 PM
2:30 PM
3:00 PM
3:30 PM
4:00 PM
4:30 PM
5:00 PM
5:30 PM
February 26, 2024
YT Tech Staff
, 11:30 AM
February 26, 2024
YT Tech Staff Bullpen
12:00 PM - 1:00 PM
February 28, 2024
YT All Hands
9:00 AM - 10:00 AM
February 28, 2024
YT Staff
, 11:30 AM
February 28, 2024
YT Tech All Hands (incl Prep)
9:00 AM - 10:00 AM
February 28, 2024
YT Staff Bullpen
12:00 PM - 1:00 PM
February 29, 2024
YT Biz Staff
12:00 PM - 1:00 PM
March 1, 2024
YT Stats
11:00 AM - 12:00 PM
March 1, 2024
Dim Sum
12:00 PM - 1:30 PM
⁠

Decision-making forums

First a couple notes on how these forums ran:
Come prepared and expect others to be prepared: As I mentioned above, we almost never “presented” anything in these meetings. I once had a newcomer start presenting in a meeting and one of my senior engineers leaned over and said to me “are you going to let him get away with that?” :)
Options, option, options: Anyone who has read
Decisive
⁠
will identify with this philosophy — we believed strongly that making tough decisions required outlining options. If you came to a forum with a decision with only one option, you would generally learn that that’s not how we made decisions, and likely one of your peers would explain to you how it works.
Key construct:
Eigenquestions
⁠
— Everyone on the team quickly got good at realizing that generating options was fruitless if you asked the wrong question. The eigenquestions write-up walks through some fun stories of this in action.
Corollary pet peeve: The New Option Generator — I have a pet peeve when leaders go through a review and then in the end say “I don’t think you should do options A, B, and C that you outlined, I think you should do D which I just made up right now.” Since materials were always sent in advance, if I felt the options weren’t complete, then I would respond to the email and the team would react before the meeting and not be surprised.

There were 3 primary decision-making forums:
Product review: For tech issues
This was owned by me and covered basically any “tech” issue [non-tech issues went to YTX, see next forum]. For tech issues, this forum was the final decision making forum and people expected a conclusion from these reviews.
The attendee list was always custom generated by the team asking for the review, but anyone on yt-tech-staff was always an optional attendee
The meetings were held on Mondays (there was a morning, EMEA-friendly slot, as well as an afternoon slot). My first Chief of Staff (Matt) actually convinced me to hold these meetings on Mondays (instead of the more classic Friday scheduling) — his philosophy was “set the tone for the week by making some decisions first thing in the week”. I came to totally agree with this philosophy - nothing made a week feel better than a good product review to kick it off.
They were generally 30mins long, though sometimes people asked for longer. They often ended early though - especially if the mail thread had mostly reached a decision already.
The deck for the review would go out on Thursday by email. A very wide group of people was cc’d - including every YT PM, every tech lead, etc - well over 100 people would see the mail. People would reply and comment throughout Friday and the weekend. On Sunday night, I would generally read through the deck as well as everyone’s comments and send out my summary. My summary would generally become the agenda for the actual meeting - we would assume that everyone has read the deck and has followed the mail thread, and then go through the points I asked for more discussion on.
We always left with a decision - even if that decision was an explicit “we are not going to make this decision until {X data is collected, Y prototype is constructed, etc}”.
YTX deal review: For business issues
This was owned by Robert and covered any “business” issue.
It was generally dominated by deal reviews - content deals with new partners, sales pricing/discounts, etc. There was a compliance person assigned, and an escalation process (for larger deals) to go to the Google-wide deal review forum.
It followed a similar model of sending decks a couple days in advance, and not spending the time in the meeting with someone presenting.
Different from Product Review, this forum was scheduled with a fixed set of required attendees, and a much narrower invite list. This was due both to the compliance nature of the review, as well as (frankly) a difference in my style and Robert’s style.
The forum worked very well and we always left with a decision, often with good healthy debate.
YT eng review: For more detailed tech issues
This was owned by our senior eng “architect” (we referred to the role as “Area Tech Lead”)
It covered tech implementation issues that were generally too specific for product review. Often this forum would happen after product review (product review set the direction, and then eng review reviewed the particular implementation choices), and sometimes would happen before (during an eng review, we would determine that an issue affects the product more broadly and it would get escalated).
There was a core group of eng leads that were optional attendees.
The meeting followed the same pattern as product review in terms of early publishing of write-ups and lengthy email discussion before the review.

Overall, I spent about
4
⁠
hours a week in these forums, though some weeks it could be a little less if we resolved the issues over email, etc. Here’s the calendar filtered to the decision making forums:

March 2024

Week
Today
Feb 25
Feb 26
Feb 27
Feb 28
Feb 29
Mar 1
Mar 2
9:00 AM
9:30 AM
10:00 AM
10:30 AM
11:00 AM
11:30 AM
12:00 PM
12:30 PM
1:00 PM
1:30 PM
2:00 PM
2:30 PM
3:00 PM
3:30 PM
4:00 PM
4:30 PM
5:00 PM
5:30 PM
February 26, 2024
Product Review
1:00 PM - 3:00 PM
February 28, 2024
YT Eng Review
1:00 PM - 2:00 PM
February 29, 2024
YTX Deal Review
1:00 PM - 2:00 PM
⁠

Tag-ups

These were probably our most unique category of meetings. As I described above, we treated these like Group 1-1s, and created them for any group that we felt needed consistent coordination. They fell into a few natural categories:
Focus Area tag ups: The YT tech teams were divided into 4 Focus Areas (Viewer, Creator, Ads, Core Eng). Each one of them had a one hour weekly block. The attendees were generally the PM, Eng, and Ux lead for that FA, and in some cases, their cross-functional counterparts (e.g. the Sales lead came to the Ads tagup). The template for the meeting had 4 parts:
People - They would outline any new additions or departures from their team, any reorganizations / reassignments, and any emerging people issues
Launches and decisions - Then they would quickly run through any important decisions they’d made as a team and walk me through upcoming launches as well as recaps of recent launches. These teams were very large and so this list could be very long, so the granularity was up to the team and most were very good at filtering down to the launches and decisions that either needed feedback from me or where they felt that I just needed to understand.
Metrics - A quick walkthrough of the relevant metrics for the area (generally quick since I watched the dashboards pretty regularly on my own).
Discussion topics - The teams would pick a set of topics to walk through. Often these were casual and not yet well-formed, and they were looking for directional feedback. Sometimes they were just brainstorming and we would whiteboard together. And occasionally, there were decision topics that were smaller and didn’t require a product review (but this was the exception not the rule).
Big Rock Tag Ups: We also set up a weekly forum for every Big Rock. These had a very similar template to the FA Tag-ups, and the leaders of each big rock would prep updates on People, Launches/Decisions, Metrics, and Discussion Topics. The Rock Managers would determine the attendees for the tag-ups, and we tried to keep it small (ideally <5 people, and occasionally <10).
Cross-Functional Tag Ups: I had a few functions that I found needed regular time to discuss topics:
HR / Recruiting - I would go through candidate packet review for everyone we were making offers to, coordinate the performance review process, discuss people issues, etc.
Legal - There was always a list of topics where the legal team needed a dedicated forum to discuss. They would also often ask for my background on an issue that they were tracking down but where they were lacking context.
Finance - This is where we handled budget issues, looking at financial forecasts, etc.
Marketing - We’d review and triage marketing priorities, review campaigns, etc.
Functional leadership Tag Ups: I tended to run most meetings across functions (PM, Eng, Ux) so we needed a couple forums that were function specific:
Eng Leads - We would go through eng-specific topics like the push process, codebase and tools choices, etc.
PM Leads - This was mainly about coordinating the assignment of PMs to projects and the addition (and removal) of PMs to the team.
ATL Tag-up - I created a role called Area Tech Leads. These were very senior individual contributor engineers who I trusted to run a lot of the technical decision making across the teams. I had 3 of them (covering data, discovery, and the overall “app”) and we would get together to coordinate where they should focus.
My Admin + Chief of Staff Tag Up: Once a week, the 3 of us would sit down to triage the week. More on this in the FAQ below.
Exec Tag Up: And one last one was the Salar-Shishir-Robert tag-up. The three of us ran YT as a trio and so we would make sure we sync’d at least once a week. We often did this over dinner and walked through the tough issues that weren’t getting resolved, etc.

Process-wise, every Tag Up had a standing, shared Google doc and all the attendees would regularly add topics to it. We even built a spreadsheet extractor that lined this up with my calendar, but that’s for a different discussion :)
One scheduling note for Tag-ups: we set a schedule for the Tag Ups and we tried very very hard to never move them. My Chief of Staff would insist that if there were conflicts, we would cancel rather than move. See Core Principles at the top of this schedule for a longer description of why.
Overall, Tag Ups occupied the largest section of my time at ~
11
⁠
hours a week (
40%
⁠
of my scheduled time). I found these meetings to be incredibly useful and productive. Here’s the calendar filtered to Tag-ups:

March 2024

Week
Today
Feb 25
Feb 26
Feb 27
Feb 28
Feb 29
Mar 1
Mar 2
9:00 AM
9:30 AM
10:00 AM
10:30 AM
11:00 AM
11:30 AM
12:00 PM
12:30 PM
1:00 PM
1:30 PM
2:00 PM
2:30 PM
3:00 PM
3:30 PM
4:00 PM
4:30 PM
5:00 PM
5:30 PM
February 26, 2024
Tag-up Admin + ChiefOfStaff Sync
, 9:00 AM
February 27, 2024
Tag-up Big Rock #1
, 9:00 AM
February 27, 2024
Tag-up Big Rock #2
, 9:30 AM
February 27, 2024
Tag-up Big Rock #3
, 10:00 AM
February 27, 2024
Tag-up Big Rock #4
, 10:30 AM
February 27, 2024
Tag-up Big Rock #5
, 11:00 AM
February 27, 2024
Tag-up Big Rock #6
, 11:30 AM
February 27, 2024
Tag-up FA: Ads
12:00 PM - 1:00 PM
February 27, 2024
Tag-up FA: Core Eng
1:00 PM - 2:00 PM
February 27, 2024
Tag-up FA: Creator
2:00 PM - 3:00 PM
February 27, 2024
Tag-up FA: Viewer
3:00 PM - 4:00 PM
February 27, 2024
Salar-Shishir-Robert
4:00 PM - 5:00 PM
February 29, 2024
Tag-up: Finance
, 9:00 AM
February 29, 2024
Tag-up: ATLs
, 9:30 AM
February 29, 2024
Tag-up: Legal
, 9:00 AM
February 29, 2024
Tag-up: Marketing
, 9:30 AM
February 29, 2024
Tag-up: HR / Recruiting
10:00 AM - 11:00 AM
February 29, 2024
YT Eng Leads
, 11:00 AM
February 29, 2024
YT Product Leads
, 11:00 AM
⁠

1-1s

The last category of meetings was 1-1s (
see template
⁠
). As I mentioned above, we created Tag Ups as a way to move product/strategy discussions out of 1-1s and into Tag Ups. So this meant that 1-1s were generally focused on career coaching and individual problem solving. I let the person control the agenda - though we kept a standing, shared Google doc for each 1-1 just like we did for Tag Ups. Some representative coaching topics would be things like:
My report, XYZ, is struggling to learn how to handle situation ABC. What can I tell them to help them through it?
I’m struggling to manage my time, how can I improve?
I can’t seem to get along with my peer counterpart {eng, pm, ux} lead. What can I do different?
People seem to talk over me in meetings, how can I get past that?
etc

Deciding who to have 1-1s with was a constant battle. Everyone saw having a standing 1-1 as a sign of access and a sign of status, but too many 1-1s can absolutely kill your productivity. Having the standing Tag Ups definitely helped since across those 11 hours of Tag Ups, I probably interacted with 50 unique people in intimate settings on a weekly basis.
I had a core group of frequent 1-1s structured as follows:
Direct reports: 30 mins every other week
Key Indirect Reports: I generally limited this to the same group that attended Tech Staff (just as a way to draw a consistent line) and kept these meetings at a monthly or quarterly cadence.
Key cross-functional leads (content, marketing, sales, APAC/EMEA Leads, etc) - 30 mins every other week

I then held a separate forum to deal with all the 1-1s that I couldn’t keep on a regular schedule:
Flex 1-1s: I left 2 hours of flex time each week, divided into 6 20 min blocks. People could book themselves and they generally were booked up. When people asked for a regular 1-1 with me, I would generally tell them to use flex 1-1s for first and most people gradually complied.

I also had a set of 1-1s where I was the “recipient” of the coaching / feedback:
My Bosses: Salar and I met for 30 mins every other per week (but we were in constant contact). We also had a joint 1-1 with Larry every other week.
My Advisors: I kept a couple key advisors that I made sure I met regularly.
Bill Campbell
⁠
was the most important one.

Overall, I spent almost
~6
⁠
hours / week in 1-1s (including the 2 hrs of flex time), so this was a meaningful time investment as well. Here’s the calendar filtered to 1-1s:

March 2024

Week
Today
Feb 25
Feb 26
Feb 27
Feb 28
Feb 29
Mar 1
Mar 2
9:00 AM
9:30 AM
10:00 AM
10:30 AM
11:00 AM
11:30 AM
12:00 PM
12:30 PM
1:00 PM
1:30 PM
2:00 PM
2:30 PM
3:00 PM
3:30 PM
4:00 PM
4:30 PM
5:00 PM
5:30 PM
February 26, 2024
1:1 PM Lead - Ads #1
, 3:00 PM
February 26, 2024
1:1 PM Lead - Creator #1
, 3:30 PM
February 26, 2024
1:1 PM Lead - Ads #2
, 3:00 PM
February 26, 2024
1:1 PM Lead - Creator #2
, 3:30 PM
February 26, 2024
1:1 PM Lead - UX Lead
, 4:00 PM
February 26, 2024
1:1 PM Lead - Viewer
, 4:00 PM
February 28, 2024
1-1: APAC Lead
, 2:00 PM
February 28, 2024
Eng Lead - Ads
, 2:30 PM
February 28, 2024
1-1: EMEA Lead
, 2:00 PM
February 28, 2024
Eng Lead - Core
, 3:00 PM
February 28, 2024
1:1 AreaTechLead - App
, 2:00 PM
February 28, 2024
Eng Lead - Creator
, 3:00 PM
February 28, 2024
1:1 AreaTechLead - Data
, 2:00 PM
February 28, 2024
Eng Lead - Viewer #1
, 3:30 PM
February 28, 2024
1:1 AreaTechLead - Discovery
, 2:00 PM
February 28, 2024
Eng Lead - Viewer #2
, 3:30 PM
February 28, 2024
1-1: Larry
4:00 PM - 5:00 PM
February 28, 2024
1-1: Salar
, 4:00 PM
February 29, 2024
1:1 Ex Creator Platform PM Lead
, 2:00 PM
February 29, 2024
1-1: Exec Advisor-1
, 2:30 PM
February 29, 2024
1:1 Ex Ux Ads Lead
, 2:00 PM
February 29, 2024
1-1: Exec Advisor-2
, 2:30 PM
February 29, 2024
1:1 Ex Ux Viewer Lead
, 2:00 PM
February 29, 2024
1-1: Marketing Lead
, 3:00 PM
February 29, 2024
1:1 Ex Video Delivery Platform Lead
, 2:00 PM
February 29, 2024
1-1: Sales Lead
, 3:00 PM
February 29, 2024
1-1: Content Lead
, 3:30 PM
March 1, 2024
1:1 Ex Creator Platform Eng Lead
, 2:00 PM
March 1, 2024
1:1 Flex 1-1s
2:30 PM - 4:30 PM
March 1, 2024
1:1 Ex Data Science Lead
, 2:00 PM
March 1, 2024
1:1 Ex Infra Lead
, 2:00 PM
March 1, 2024
1:1 Ex Test Lead
, 2:00 PM
⁠


FAQ

If you want to contribute comments / thoughts, feel free to
click here
⁠
to see the comment-enabled version of this doc.
Why avoid ad-hoc meetings? Wouldn’t it be better to just leave more empty time and meet when needed?
This is certainly the most commonly asked question about this cadence.
Just to give the “before” picture: Before implementing this cadence, “ad-hoc meetings” were the norm. We would try to leave open space on our calendars, and whenever we needed to chat, we would try to quickly schedule time. A few things would happen:
Scheduling was much harder than we thought: We tried to leave our calendars open, but inevitably they would fill up. So finding a 30 minute slot with 5 key attendees would often take a week+. This meant the latency to get together was a week+ anyways. And worse yet, these meetings were often the first to get rescheduled as people’s calendars changed. One simple rule of thumb: the more times a meeting is rescheduled, the less likely it is to reach its goal.
When the meeting happened, format and expectations weren’t clear: Meetings are like relationships — through each iteration they grow and blossom, develop patterns. Everyone understood how Product Reviews worked: when the writeup was due, how the agenda was set, even small things like where the typical decision makers sat. In ad-hoc meetings, it wasn’t even clear whether the meeting was a decision making meeting, a G.I.S. meeting, or something else. Often an attendee would be forgotten, the agenda wouldn’t be well set, etc. So we would inevitably get together and... have to schedule a follow-up meeting.

Running on a “minimize ad-hoc meetings” culture sounds a bit crazy but is actually quite freeing. Whenever a topic comes up, the first thing to ask is: “which forum does this naturally belong in?”. Often times, it would be Tag-ups, but sometimes it would cross team boundaries and end up in one of our Decision Making forums. And when those agendas filled up, it was a natural prioritization function — “is this topic more important than the 3 topics already scheduled for that Tag-up?”
Our release valve on this was our 2 hours of Bullpen time per week. It was quite common to stack up ad-hoc topics there and handle them at a time when everyone was guaranteed to be free.
How is bullpen different than just putting this on the agenda item or tag-ups? Seems ad-hoc meeting would become agenda items?
⁠
Bullpen
⁠
was one of our most useful techniques. So useful that I often joked that the goal of our staff meeting was just to make sure people showed up for bullpen.
The big difference with bullpen is that it was small groups. I found that if you had 15 people in a meeting, and you put items on the agenda that required ~3-4 of those people, then that left 11 people sitting around listening to something that they didn't really have to participate in. Repeat that through 4-5 agenda items, and for most of the meeting, most of the room is disengaged. That didn't feel productive.
In bullpen, those 3-4 people would group together in one area of the room and have their chat. It was fluid, so if they realized they needed person 5 and 6, they would just call them over and include them in the discussion.
The other big difference was that these group discussions were generally between people who didn't come together regularly for some reason, e.g. a lawyer, a marketing person, and an engineering lead. There may not be a tag-up that has those set of people, and scheduling an ad-hoc meeting for the would be a lot of overhead. Instead, they would just wait for bullpen and spend 15 minutes discussing whatever the issue was.
Running this well took some getting used to. At first, people found it awkward to just sit in a room together. But we set a clear rule - “you don’t have to talk to anyone, you can just sit and work. But you can’t leave - just in case someone else has a topic for you”.
Was “Come prepared and expect others to be prepared” always a part of the culture, or did it change to this? Did you have to implement some sort of reward / punishment scheme (eg A16Z's $100 tip jar for being late to a meeting with an entrepreneur)?
It changed to this. And no, we didn't do a reward/punishment. I think the primary thing that changed was doing it by example (see section 3 on implementation thoughts). I'd say that once people saw that I was prepared and that the deck wouldn't be presented, they learned quickly. Also note that in most cases, this wasn't just pre-reading, it was also pre-commenting - people generally replied to the agenda mail with their synopsis thoughts so everyone's biases were on the table before the meeting started.
[Sidenote: at Coda this has evolved into
Dory and Pulse
⁠
]
How did the rest of the team know about how the Big Rocks were doing? Also, was there a standard mechanism/cadence that all other teams (not covered in Big Rocks) shared an update with the broader team?
There's a whole separate write-up to be done on this, but a few things:
I wrote a yt-all mail every Sunday night (still do the same at Coda). That was meant to cover my main thoughts, and also included updates from all areas.
There was a yt-team-notes alias that all meeting notes were supposed to be sent to (and generally were). At Coda, we've taken this further to a "public by default" email system but it has a similar principle.
As part of planning (both the 6 and 26 week cycles), there was time built-in for the resulting plans to be shared out.
Each Big Rock team would develop its own communication cadence on top of this. For some of them, coordination was a key element, so they would communicate even more frequently. But for others, just updates in my yt-all communication and during planning cycles was sufficient.

How much of the staff meeting was your own agenda vs curated from team members within your org who rolled-up? And in what shape or form did own by Chief of staff - agenda, or running the meeting?
Probably 80-90% of the agenda was mine, and 10-20% others. But remember that the staff meeting was only 30 minutes long - most of the interesting discussion happened in Bullpen and that was ad-hoc / driven by everyone.
The Chief of Staff definitely set agenda. In terms of running the meeting, I'd say that they ran the "standing" part of the meeting (the launch review, etc), but I would run the rest. Given that it was so short, this wasn't a huge deal.
Why hold Big Rock tag-ups each week?
For YouTube, these efforts were often quite large and had many interconnected parts so they didn't struggle to fill the time appropriately.
But the main principle here is "avoid ad hoc meetings". By their very nature, a Big Rock often involved groups from various disciplines and so getting that group together on an ad hoc basis has all the worst parts of ad-hocs meetings (hard to schedule so they aren't timely, no fixed format so meeting expectations are inconsistent leading to underpreperation, etc). It was better to have the time reserved and cancel if there were no topics than to try to leave it less frequently and inevitably end up with ad hoc meetings with a similar group.
The other thing that was helpful was that it was a show of my personal time commitment to a project. I.e. if it's important enough to be a Big Rock, then it's important enough for me to block time for it and help the team in whatever way they needed. Note that is bidirectional. Of course I wanted to keep a pulse on our most important projects, but it also made clear to the team that if they have any issues, they should never wait more than a week to ask for my help with it (decision to make, resource alignment, etc).
Why keep decision making forums open to the company?
From one of the YouTube team leaders: “in addition to reducing the class system, including people of all levels in decision making meetings helped folks throughout the organization understand how decisions were made (particularly the rigor and care), what factors were discussed, which helps those decisions stick because the other people can reinforce them and even use them as models for future decisions”
Can this pattern work for everyone?
No, it depends a lot on the leader’s style. I think this deserves a quick comment on style. Leaders all have different styles and their cadence usually reflects that - so some of my suggestions here won’t work well for different people.
Note that when I say “style”, I mean characteristics, not necessarily strengths or weaknesses.
In particular, the following elements of my style greatly influenced our process, and may not apply to others:
Prefer large meetings: You’ll notice that a lot of our group information sharing meetings and decision review meetings have large attendee groups (note: tag-ups were kept very small though).
I’ve found that some leaders find large group meetings to be very frustrating. For example, Larry Page once conjectured that you can have no more than 7 attendees in a productive meeting. For me, this didn’t work well - I liked having all the relevant people present. Product reviews regularly had 40 people in them, YT stats had 100+, etc.
One corollary of this approach is that it requires diligent meeting stewardship - you have to watch carefully to make sure the right people are the ones speaking / participating, call out people when they look like they have something to say but are being reluctant, etc. One mechanism I would use to do this, for example in Product Reviews, is that in the pre-meeting mail thread, I would include a named list of opinions I’d like to hear in the meeting (“When we get together tomorrow let’s make sure Person X gives an opinion on topic A, and Person Y gives their opinion on topic B”). Another approach was to use the wisdom of the crowds (“How many people here think we should do Option A” or “Here’s a group spreadsheet, everyone take 100 points and distribute them among your choices for this question”). It takes work, but the pro of this approach is that you usually got answers directly from the most relevant person - it wasn’t translated and passed up through layers of managers like a game of telephone.
Critics of this approach would say that it was a substitute for delegation - more on this below, I think there’s a fair argument there.
Comfortable with pre-reading and prep: Our style of “come prepared and help others be prepared” required a lot of time in advance of meetings with pre-reading.
For this to work, the leader has to set the example - if they occasionally miss doing the pre-reading, or they don’t really meaningfully digest it, then others will gradually slip too. For example, for the two-pager reviews in H1/H2 planning, this was generally a stack of ~300-400 pages of reading (70 teams * ~4-6 pages per team).
The key for me to make this work was my admin - we coordinated so we knew when I would have lots of reading to do, she would block time, and then print everything for me to read (generally 4 pages to a side, double sided so 8 pages fit on one sheet of paper). I would take notes on those sheets as I read, and then go back and write a quick summary of my thoughts at the top of the page. And for things like product reviews, I would email my thoughts before the meeting, so everyone had a chance to digest and react.
There are a few reasons why this technique was important.
It helped avoid “The New Option Generator” pattern I described earlier - if I thought they didn’t have enough options, then I would tell them and they would either add it or tell me (thoughtfully) why that option isn’t viable.
It forced me to think deeply about the issue. Generally if an issue was important enough to bring to me, then I thought it was bit overconfident to think that I could listen to the issue for the first time at the beginning of a 30 minute meeting and have a decision by the end. If it was important, it required thought, and this forced me to think about the issue before reacting.
It forced me to write down my opinion. More on this next.
Critics of this approach would say that it was a crutch for the team to keep them from synthesizing - i.e. because people would read a long write-up, they could get away with less synthesis. In my view, I generally saw the opposite - forcing writing things down helped people clarify their thoughts rather than rest on their in-person debating ability.
Willing to write down an opinion and a thought process: For me, the process of writing is much more rigorous than of talking - there are leaps of reasoning that people will accept in a meeting setting that you would never accept in a written document. (See
Jeff Bezos’s argument for the value of writing
⁠
)
So part of the reason I sent out my thoughts in advance was to make sure (a) I had really thought something through properly and (b) to help people see the thought process not just the decision.
The second part was particularly important. My view was that the good decisions were ones that “stuck” (i.e. stood the test of time), and the absolute best decisions were the ones that clarified a philosophy such that the next 10 decisions became much easier. So writing down the the thought process for a decision was really important.
Critics… I don’t think there were many critics of this one.
Like being questioned, and wanting debate: Much of our process was designed to bring out debate - publishing pre-reading materials very broadly, etc. And writing down my own thought process could feel very exposing - since it invited debate as well. For me, this was good - people around me learned that I was at my best when debating something, it’s the way I understood an issue. Critics would call this time-consuming and over-kill, so this was always a balance.
Prefer context switching to singular focus: As you can tell from my schedule, I would have many days where I was switching between 8-10 entirely different topics. For some leaders, this greatly reduces their performance, but for me, it kept my energy level high (probably indicative of some level of ADD). Critics would probably say that more focus is probably better, and I definitely saw some “tunnel vision” leaders who were very effective at picking a single topic for a day (or sometimes even a week or a month) and staying very deep on that, but that was not my style.
Tentacles Everywhere vs Delegation: This is probably the most important characteristic and I do think it’s a true trade-off. Most of my team would likely describe me as deeply involved in many areas of the business. This had some very positive characteristics - it could keep teams motivated since most people had some connection to me, it allowed me to see opportunities across teams that other people might miss, it made it much harder to “bullshit” me on things that could or couldn’t be done, etc. But it also had a bad side-effect in that it could feel disempowering to some of my leaders. In my case, my team generally liked this style - they found that I could more easily reinforce messages with them and help them steer the teams, and also felt confident that I could help resolve conflicts and make decisions in ways that were likely to stick. And many of them repeated these patterns with their own team. But ensuring my leaders felt empowered was definitely something I had constant focus on.

How much should you invest in your admin and/or Chief of Staff?
There are very few things that can be a bigger force multiplier than having the right admin and Chief of Staff.
For your admin: There are many ways for them to help reinforce these processes.
Coloring your calendar
⁠
, verifying you have put in a goal for every meeting, printing pre-reading, etc. Also, I found it useful to explicitly empower my admin to be my EQ watchdog as well - i.e. she would tell me if people were upset, feeling neglected, etc - things that are hard to figure out in a structured review.

For your Chief of Staff: First off pick carefully. I’m a big believer in it being a part-time job (i.e. someone who has a day job within your organization). It allows them to stay relevant / plugged in, but most importantly, it prevents the classic adverse selection - picking a Chief of Staff that isn’t being successful in your org already.
I generally structured the job in 3 parts: (1) running the organization processes (e.g. the weekly cadence, H1/H2 planning, etc), (2) handling communications (drafting speeches, broadcast mails, and presentations for me), and (3) being my stand-in. The 3rd one is the hardest. One tactic I used was that , I would ask my Chief of Staff to take my task list for the week and take one item completely off of my task list and pull it completely onto theirs.


⁠
👉 Next:
Implementation
⁠
⁠
⁠
Before we start, an overall map of the YouTube meetings
Four types of meetings
Group information sharing (G.I.S.) meetings and bullpen
Decision-making forums
Tag-ups
1-1s
FAQ
Want to print your doc?
This is not the way.
Try clicking the ⋯ next to your doc name or using a keyboard shortcut (
CtrlP
) instead.