Transcription
We're live!
Yeah, usually how I like to kick this off is by doing a brief bio on our speaker to set the stage, and then we can take it from there.
Fure started his career as a founder. He ran his company for about two years, and then after that, he moved to Microsoft, where he was a director of product. He worked on Windows, Office, and other very well-known products. After six years there, he moved to Google, where he became the CPO and CTO at YouTube. He played a key role in growing YouTube, which became one of the fastest-growing businesses in the Google portfolio. I believe when he took over the company, it was making hundreds of millions in revenue, and by the time he left, it was probably printing billions of dollars in revenue, which is amazing.
We were at 30 million when I joined.
Wow, almost entirely ad networks! So you definitely added a bunch of zeros to that number.
After six years at YouTube and growing the business there, he decided to start Koda, which is an all-in-one doc platform for teams. We actually use Koda to run our entire Supra member portal, and we absolutely love it.
I also want to take a quick moment to thank Koda. They've been extremely generous to the community since the beginning. We couldn't run any of our in-person events without them, and we're super grateful for the partnership.
In terms of a quick agenda for today, Shir will kick us off with Asher Pressa. For the last couple of years, he's been meeting with some incredible founders, CEOs, and leaders because he's writing a book to capture the rituals of high-performing teams. He'll talk a little bit about that, and then after that, we'll move to the Q&A.
So, without further ado, I'll pass it on to you, Shir.
---
Great to be here! I'm very excited to get a chance to chat with you.
I prepped a little presentation, and if you want to follow along, I'll drop this link into the chat. It's got a few other links in it and so on that you can check out as well.
I plan to cover four topics primarily: great people, great decisions, great culture, and great productivity. Each one is a bit of a thought starter on a topic, and I sort of picked off things that I felt were interesting to product leaders across a wide spectrum of ideas.
So, with that, I'll jump in. Feel free to ask any questions you like.
I'm going to start by talking about this framework, PSH, in particular on this topic of how to think about great people.
To rewind time a little bit, in 2010-2011, Larry Page took over as CEO of Google. He did a whole bunch of different things at the time, one of which was reorganizing us into business units. That might seem a little bit crazy; we were, I think, 25,000 people at the time, and we still had functional reporting structures with product sales, all reporting into the CEO.
He created eight business units: YouTube, search, ads, Chrome, Android, and so on. That was mostly very positive. One of the downsides of moving from a functional structure to a business unit structure is that you lose functional identity. So, what is a product? What is a good PM? What is a good product team? You kind of lose that a little bit.
So, a group of the product leaders got together and said, "We need to do some things together." We decided to coordinate on one set of activities. We actually ran an election, so we picked one of us every year to become the glue for the function. I did the first two years, and we had a lot of different topics, but the main one was calibration.
We had to come up with a way to judge what was a great product manager and what was not so great. I had this meeting, got everybody together, and said, "Before we do calibration," and calibration at Google was a little different than a lot of other companies. Your boss didn't give you your rating and your promotion decision; a committee did. It was a committee that supposedly didn't know anything about you, and they would read a packet.
We all sat in a set of hotel rooms at the Marriott by the SFO airport. Before this all started, at the beginning of the day, someone would have to come give a speech about what makes a great product manager, what we're looking for this year, what's changed since last year, and so on.
It used to be Jonathan Rosenberg, who ran product at that point through that transition. He retired, so I got to do that. I got the group together, and in prep for this calibration, which was coming about a month away, I said, "Hey, we need to come to some agreement on any changes we want to make."
Everybody had a bunch of reflections and complaints, and we started talking about our ladder guide. Like every other company, we had a document that laid out what a PM level three, four, five, and so on was. It turned out nobody had read it; nobody really understood it. It was kind of an irrelevant document.
I said, "Let's just test something." I took the document, cut it into little strips of paper, one per level, and cut off the title and the number. I handed out different job descriptions or level descriptions to different people and said, "Can you reverse identify the level that's sitting in front of you?" Of course, nobody could do it.
There's a good reason for that. This level guide was at that point probably 15 years old. It had been entirely grown additively, so we just kept adding things to it. Whatever incentive we wanted to create for product managers got added to this thing, and it was full of all sorts of mostly irrelevant stuff.
It would say things like, "This person can manage a medium-sized project and always sends out the trip report on time when they come back from a trip and interviews at least three people a week." Just whatever we were trying to incentivize was built into this guide. There was no way you could reverse identify what level that was.
If you took all of these little sheets of paper and laid them out side by side, you could order them, and you could order them on exactly one axis, and that's what got covered at the bottom of this chart here: scope. Every one of them had some signal on scope: medium-sized project, large-sized project, and so on.
We said, "Okay, if we're all going to calibrate across our different divisions without having to work together all the time, we at least have to agree on scope." So we came up with this set of definitions. We're going to define scope as, for a product manager, you manage a feature, then a group of features, then a sub-area of product, then multiple sub-areas of product, then a whole product, then multiple products in a product line.
That seemed pretty good. If nothing else, let's at least be aligned on that. Now go calibrate. We go away, and two weeks later, everybody comes back. We have another discussion, and everybody's upset. "That didn't work at all! What happened?"
I said, "Well, first off, the Google search team starts complaining that, hey, you said product is up here, but the Google ads team has defined product to be like the hundreds of different SKUs of stuff you can buy from Google ads. So all my folks want to move to Google ads because it's clear that we're going to promote them faster over there."
Another person said, "Hey, this feels weird. It's a little bit of an input, not an output. We're finding ourselves in these calibration discussions saying, 'Hey, you should promote this person; they manage a whole sub-area of the product,' and you look at the manager and say, 'Wait, but you gave them that scope, so they have to do something with it. Just having it can't possibly be enough.'"
Then the last issue was there were a set of people that said, "Hey, our best and most talented people are working on things that are super risky, and we don't know yet whether it's going to be a feature or the future of artificial intelligence." Judging them on the current scope of their offering seems unfair as well.
That didn't work particularly well. Lots of discussion. We came up with another axis. This is called PSH. It stands for Problem, Solution, How.
I'll say up front, I've tried for years to come up with a better acronym that spells a catchy word or something like that, and I haven't been able to come up with one, so we're stuck with PSH. That's how you're going to remember it: PSH.
So how does it work? You're a junior PM. We hand you a problem, we hand you a solution, we hand you a how. We tell you this is exactly what you need to do: write this doc, talk to this team, hold this meeting, attend this conference, whatever it is, and your job is just to execute on those instructions.
Then we hand you a problem, we hand you a solution, and you have to come up with the how. You have to figure out how the team should operate, what the milestones are, and what the cadences are.
At some point, we hand you a problem, and you have to come up with the solution to that problem. Then at some point, you get to the top of this pyramid, and we hand you a space, and you tell us the problems. You say, "Hey, I know you told me to go work on activation, but actually, I think retention is a problem," or "I know you told me to work on brand, but actually, I think our delivery quality is a problem," or whatever it is. It's your job to come back and tell us the problem.
This was pretty sticky. People seemed to like it. They went off and recalibrated. One particular leader, she was running the product team for infrastructure at Google. She went and did it kind of mathematically and slotted every person on her team on both dimensions, and then she fit a curve to it.
That's this black line here. She came back with this really interesting surprise. She said, "When I look at my team across these two dimensions, it turns out there's a bit of an S-curve. Early in PM careers, they tend to mostly be handed a problem, a solution, and a how, and they just execute on bigger and bigger problems. In their careers, they seem to, you know, once you run a product, we just hand them more and more products to run or bigger and bigger products to run. But in the middle, everything seems to invert."
She drew this big circle around it and called it the "trough of disillusionment."
So what is the trough of disillusionment? Well, this is when the rules change. If you're an employee, you look at this and say, "What the hell? This whole time you told me it was about scope. You told me it was about the number of interfaces I manage, the number of users, the amount of revenue," and all of a sudden, you're changing the rules on me.
From the perspective of a manager or a calibrator, the rules have also changed. We had to give the speech that said the difference between a level three and a level five product manager may not be the job they do; it's how they do the job. It kind of changed how we think about evaluating people.
I told this whole story from the perspective of product managers, but it turns out it has nothing to do with product managers. I came back; I was managing the engineering team, design team, and so on. We went and applied the exact same method for those teams as well.
You want to know who the best engineer on your team is? It's the one who can see around the corners. That's P.
It turned out we could do the same thing with all our business functions as well. We started judging marketing that way, judging finance that way. The sales team was the trickiest. For the sales team, we said, "Hey, this is how we're going to calibrate." The sales team said, "No, no, no, we got this figured out. For sales teams, we have a quota. All we need to know is percentage attainment against your quota. No reason to do anything else."
So we went and talked to a few of the different salespeople and said, "Hey, so-and-so is at 400% of their quota. Aren't they the best salesperson?" They would snicker a little bit and say, "No, no, that's silly. They're not the best salesperson; they just got handed a super easy region."
Then you go and say, "Okay, so who's the best salesperson?" They say, "Well, you know, so-and-so, she's definitely the best." You ask, "Why?" They say, "Well, she can do anything. She can take any product; it can be good, it can be bad, it can be in a market that's growing, a market that's shrinking, a big customer, a small customer, a churning customer, a growing customer, whatever. She will identify what the opportunities and problems are, find solutions to them, find a way to do that repeatably, and execute on it and deliver."
That's your best salesperson.
So I've gradually come to the realization that for me, my best definition of great people is entirely captured in this axis: PSH.
That was topic number one.
Happy to take a quick follow-up there.
Say someone tells you, "Hey, you have to grow the revenue of X." Is that a known problem or is that an unknown problem in this model? Would that fit in?
Great question!
It depends on the context of the situation. One way to ask this question isn't, "Is that a known problem or an unknown problem?" It's, "Was that the responsibility of knowing whether it's a known problem or unknown problem that person's responsibility?"
If you told them that is the problem and you gave them no agency to look otherwise, and they never bothered to look otherwise, then no, they're not operating at a P level.
On the other hand, if you told them something totally different and you said, "Hey, I think it's grow activation or grow users," and they come back and say, "You know what? You're wrong; it's all about growing revenue," it seems unlikely in that scenario.
If they said, "No, no, you told me not to worry about revenue, but I actually think the thing we need to worry about is revenue," then it might be the type of person where you think about them as a P.
But the test is not really any individual statement. I used to call this the training wheels axis. You have a person; what is the biggest space with the least definition that you can hand this person with no training wheels? What are the types of training wheels you need to give them?
You might say, "I've got to constantly remind them what the biggest priorities are," that's up here. Or, "I have to solve all their hardest problems," or "They seem to be okay with the problems and solutions that are handed to them, but I keep having to tell them how to actually deliver on them."
What I'm sort of in the weeds of is how they run their team. Each of these can depend on the person. Would you feel comfortable handing them a problem and letting them figure out the rest, or handing them a space and letting them figure out the problems?
That's one answer to your question.
Thanks, Jos, that makes sense.
Maybe we'll do one more before we move to the next one. Amal, do you want to ask your question?
Yeah, sure, thanks!
The question was, how did you standardize this across various teams? Because this isn't like a checkbox exercise that you described earlier. We can't just say, "Oh yeah, this person's managing three projects, good, got it." It's not like that.
So across a range of business functions, which are very different and probably changing quite dynamically, how did you kind of say, "Okay, this is the same level here or there, the same pie, use the same key here?"
Oh, what a great question!
So a couple of things. I just realized this link doesn't have it.
We agreed on a list of questions for each of these stages, which I, if you remind me after, I'll dig them out for you. They're actually phrased as reference check questions.
The way they're phrased is not, "What did they do?" It's, "If you were to call one of their peers or so and ask them this question, what would they say?"
So that was the way. So first, how do you collect the input of what does it mean to be a P? For example, for P, you would call someone, and if I called someone randomly on the team and I said, "Who was most responsible for identifying the problems to be solved by the team? Whose name pops to the top?"
Ideally, you want to do the reference check not asking about a specific person. You want to ask a person on the team and say, "Who does this?" You want to know if that name comes back.
So that's how you get the data.
How do you calibrate them? That's probably a larger topic.
I have a lot of opinions on calibration. What I'll do is, if we have time, I'll come back to it. But if you search for calibration, you'll probably find a doc I wrote about six ways to do calibration.
So maybe if we have time, I'll come back to calibration.
Sounds great!
I'll leave that in the chat as well.
Alright, let me go to topic number two.
Oh, and I should say, the next three topics I picked are basically we're going to move down this axis.
So we're going to focus up here, then here, then here.
If we think about the P and the S phase, I want to talk about another idea I call "Iing questions," since I refer to it as a ritual, which I'll tell you more about in a moment.
So actually, just as a quick show of hands, who here has heard the term "Iing questions" before?
A handful.
Okay, I can't tell for the people that are not on, so we're going to...
I will give a very quick background on Iing questions, and then we can chat more about questions on this topic as well.
So very quick background on Iing questions: rewind time again to 2008. I am now just starting off at YouTube, and if you came to a regular YouTube staff meeting, the question you would probably hear us asking more than anything else was something we call the "Modern Family question."
This is kind of an odd question; I'll tell you more about the question in a minute. But as a reminder, in 2008, YouTube was far from an obvious success. We were, as Mark mentioned, doing about $30 million in revenue, losing hundreds of millions of dollars a year, rounding up to a billion. We were known for grainy videos, we were known for really crappy lawsuits, and we were far from a sure thing.
Yet, if you wanted to know what topic was on our list every single week, it was Modern Family.
So let me tell you what the Modern Family question is. At the time, YouTube was the second largest search engine on the planet behind Google, our parent company. Every week, we'd have a list of search queries that we would go look at, and in 2008, one of the top five queries every single week was Modern Family.
That's probably not that surprising because Modern Family was the number one show on TV at the time, by far the number one show. The problem was we didn't have Modern Family on YouTube, so we gave really, really crappy results to this question.
The question, so the Modern Family question was, "How should we respond when somebody types Modern Family into YouTube?"
The company divided in half. Half the company, mostly the product and design engineering folks, said we should link people to abc.com. It turned out ABC was uploading every episode of Modern Family online for free.
That probably doesn't seem like a big deal today, but in those days, that was not common. So that half of the company said, "We're now owned by Google; our job is to do right by the user. We should just send people to abc.com."
The other half of the company, the sales team, the marketing team, and especially the content partnerships team, said that would be a total disaster. "If you link people off to abc.com, we will never host good content on YouTube. We will be left only with the things that aren't deserving of being hosted elsewhere."
So totally split. Every week, we get together; we try to make a decision. No decision got made; it got rolled over to the next meeting.
After weeks and weeks of doing this, we decided we have to make a call on this topic. We decided to hold an offsite, and we're going to spend all day just on this one question: the Modern Family question.
I got asked to go prepare the discussion, to go collect the data, collect the input, and do whatever it takes to frame this so we can come out with a decision.
The night before, I'm sitting there trying to figure out what I'm going to do. This is like an impossible task because everybody's already dug in; everybody already has a viewpoint on what they think about Modern Family.
I got to come up with some way to break the pattern. At the time, there was another research paper being floated around Google done by the Google shopping team. They got a bunch of user research trying to figure out why they were getting their butts kicked by Amazon.
They were approaching users and asking this question: "Why would you pick Amazon over Google shopping?" To them, it seemed like an IQ test; it seemed nonsensical. "Why would anybody pick Amazon?"
The way they would ask the question is, "You can go to Amazon, but if you go to Google shopping, we've indexed all of Amazon and the rest of the internet, so we were clearly the much more comprehensive answer. Why would you ever go to Amazon?"
What the users kept coming back with was, "Well, we go to Amazon because we prefer consistency over comprehensiveness. I go to Amazon because I know how the reviews work, I know how the pricing works, I know how shipping works. I would rather have a smaller catalog and a consistent experience than have everything but a lot of inconsistency."
To start this offsite to talk about the Modern Family question, I decided that rather than ask about Modern Family, we were going to do our first discussion with a different prompt.
We said, "In 10 years, will the world of online video be more about consistency or comprehensiveness?"
This turned out to be a really interesting discussion that everybody could have evenly, and it only took about an hour. We all came to a conclusion: clearly, the online video market is going to be about consistency, not comprehensiveness.
By the way, we're now 16 years later, and I'm pretty sure we were right. The online video market is obviously huge, and there is no one property that is all of online video; it almost doesn't make sense.
At that moment, we decided we are going to be more about consistency than comprehensiveness, and we made a bunch of downstream decisions from that.
We decided we are not going to link off to abc.com. YouTube still doesn't do that. We also decided we're not going to host third-party players. At the time, we were hosting all these third-party Flash players, and Flash was still a thing.
One of the most consequential decisions we made was about our iOS app. When the first iPhone came out, there was no app store; they really wanted YouTube on the phone. So the Apple team built the YouTube app, and years later, they were still building the YouTube app.
They weren't able to keep up with what our team was up to; almost half the catalog didn't play back. So I went down to Cupertino and said, "Hey, we're going to take back control of the app."
They said, "Well, you're welcome to do that, but you're going to have to start from zero in terms of distribution. You're not going to be default installed on every iPhone anymore."
I said, "Yeah, that's okay. We have this value: consistency more than comprehensiveness. We'd rather be on fewer devices with a consistent experience than on all devices with an inconsistent experience."
This process got a name. We started calling this "Iing questions."
For people that don't know, the reference is a made-up word, but it builds on a concept from linear algebra called "Iing vectors," which is the most important vector in a multi-dimensional space, commonly used in linear algebra and machine learning.
Doesn't matter; the name's made up. The easy way to think about it is the I question is a question where, if answered, it likely answers the subsequent questions as well.
Now, if you can picture the method, you sit down, and you have 10 different questions to get through. How are they ordered? Sometimes they're ordered by severity; sometimes they're ordered by recency, urgency.
Why was this called a Modern Family question? Well, because we were trying to do a deal with abc.com, and so that was urgent, so that was at the top of the list.
But if you scan this list, sometimes at position number six is the Iing question—the question that, if answered, will answer all the other questions as well.
One of the things you have to do as you're leading teams is figure out how to shift from spending your time on getting to the right answer to getting to the right question.
So that's the idea of Iing questions.
Alright, that's topic number two.
Maybe one quick follow-up there.
I think it was super interesting that when you joined YouTube, a lot of people probably thought you were a bit crazy for doing that. It was a company that was losing billions or close to a billion, right? A lot of lawsuits, crappy videos.
I know the press was saying, "Hey, maybe this was Google's first mistake or bad acquisition." I'm curious: what did you see that others missed?
To make it more applicable to the audience, for product leaders looking for their next opportunity, what advice would you give them to identify those hidden opportunities?
Oh, that's a much harder question.
I don't know that I have lots of thoughts on how to make career decisions. I think that all of my methods are advice that I've mostly ignored.
I've mostly run towards problems I find interesting, and in this particular case, I just thought YouTube could be more than what it was. I could picture it, and it didn't seem like everybody else could picture it.
It just seemed like a travesty to me that this product might not exist if we didn't sort of fix it. It was definitely a turnaround situation, which is not easy. Running towards a turnaround situation is really hard, but it just seemed really obvious to me.
Same when I started Koda. I could picture what I thought the product could look like, what I thought the world could look like with it, and I just got obsessed with it.
For me, it's mostly been that. If you find yourself, you can't stop thinking about it, then you run towards it.
I probably have a more methodical framework I'm happy to give you later, but that's my answer on how I picked.
Yeah, that makes sense.
Is there anything that you do to build conviction as you get more curious? Is there anything like, "Okay, if I do these things, I feel good enough about taking the leap?"
Let me give you a slightly longer answer.
Whenever I'm talking to people about their career decisions, I generally ask them two questions.
One I call the "investor test," and the other I call the "would I pay to work there test."
I'll give you both.
The investor test is pretty simple. The analogy here is if you're going to be the big fish in a small pond or the small fish in a big pond. If you're going to be the small fish in a big pond, then you worry about the size of the fish. You worry about, "Am I going to join Google or Microsoft?"
So on, like the pond is what it is. You have to worry about the size of the fish. So will I get promoted? Will I get, you know, will the fish get bigger?
That's never attracted me that much, so I've never really thought about things that way. If you're going to join a small pond, you worry about the size of the pond. If the pond gets bigger, everybody gets bigger.
So who judges the size of ponds? Well, investors judge the size of ponds, right?
So employees actually do a pretty poor job judging the size of ponds.
The first question I always ask people when they're making a career decision is, "Pretend you weren't joining; would you invest?"
Sometimes it's impractical, like I couldn't really invest in YouTube, but the "would I invest" was very clear.
So that's the first question: would you invest? It's kind of a dispassionate, you don't get to work on it; would you invest?
The second question is the exact opposite: would you pay to work there?
That question sounds a little ridiculous because it is. A lot of people ask, "Why would I pay to work anywhere?"
I say, "Well, look, sometimes people go back to school; they go get an MBA; they pay to do that. I've heard people say, 'I would pay to work on the first iPhone team with Steve Jobs.' I personally would have paid to work on the team I did at YouTube. I got paid reasonably well for it, but I think I would have paid for that experience."
Why do people pay to work on things? Why would you do that?
Well, sometimes it's a skill you're trying to develop; it's just like going to school. So I'm trying to learn everything about space; I want to go work at SpaceX.
Sometimes it's a network; it's a group of people. You say, "This group of people is so important that I want to be with them and be part of their journey for years and years from here."
And then the other reason why people say they would pay to work on something is they care about the mission. This is a mission I care so much about; I would volunteer to do it.
So you take these two questions and answer them separately. I think it's kind of important not to mix them.
I'll hear people mix them together all the time: "Oh, this is a people, this is a group of people I like to work with, and I would kind of invest, and yeah," and then they kind of get this middling answer.
When you find yourself answering yes on both questions, that's when you should jump in, sort of both feet.
If you find yourself missing one, then you should question it. Sometimes you do it anyway, but those are the two questions I ask: would you invest and would you pay to work there?
They kind of diverge from there.
As Nathan said in the chat, not all investors judge the pond size well, but at least they think about it.
I just talked to someone today who was giving her career advice, and I asked about the business. She's about to accept an offer to a place, and she knew nothing about the business.
I said, "How could you do that?" She said, "Well, I'm not joining; I'm not investing." I said, "No, no, no, you're investing your time. Your time's way more valuable than your money. Your investment is binary; you have to commit."
I find that to be a very helpful question to ask people.
Amazing!
Maybe we'll do one or two more rituals, and then we also have some time for the audience to ask open questions.
Let me cut this short a little bit.
As we work down the spectrum, PSH, let's get to H.
So you've sort of worked out you can identify the right problems, find good solutions, and now you're ready to run a great team.
As Mark mentioned earlier, I've been working on this topic for a while. It's kind of become a little obsession for me. I have a lot of normal hobbies as well, but this has become my... as my kids would say, I probably spent as much time on this as anything else.
My journey on this process started with a conversation with this person, Bing Gordon. If you don't know him, he's the chief creative officer, or was the chief creative officer at Electronic Arts. He's now an investor at Kleiner Perkins, been involved with a lot of famous companies: Amazon, Zynga, many others.
I sat on a board with Bing, and one day he started harassing the CEO. He said, "What are your golden rituals?" At the time, nobody understood what he meant.
So I asked him, "What's a golden ritual?" He said, "Oh, every company has a small list of golden rituals. There are three criteria: number one, they're named; number two, every employee knows them by their first Friday; and number three, they're templated."
He started rattling off his list of golden rituals. Amazon has six pages; Google has OKRs; Salesforce has V2MOM. These are all well-known golden rituals.
I got pretty excited about it. I started talking to different people about their rituals. People started sending me theirs. I started running a dinner series. For the past three-ish years, I've hosted a dinner basically every two weeks. I've gotten to thousands of people now, where the format's very simple: everybody shares a ritual.
I learned lots of things. I learned that people like to share their rituals; people like to learn from other people's rituals. But probably the most interesting thing I learned was from Dharmesh.
Dharmesh, the founder of HubSpot, shared a ritual called "flashtag," which I'm happy to tell you more about as well. But his observation was interesting. He said, "We build two products in our companies: one is for our customers, and one is for our employees. The latter one we call culture."
If you ask people to describe it, they'll describe it as manifested as rituals. A lot of time, people will describe these rituals and say, "That's just the way we run," or "That's our company operating system." But actually, they're a two-way mirror of company culture, which is the second main product we build as leaders.
That got me very motivated to spend more time on it. I decided to turn it into a book. If you want to follow along, go to ritualsofgreatteams.com. I'm trying to publish a chapter at a time, and it's open for a group of people to help me co-edit it.
I'd love your help; I'd love your contributions.
I have a bunch of examples here; I'll just give one. If you were to ask an average Koda employee what our golden ritual is, they would almost certainly tell you about something we do called "two-way write-ups."
The background here is this is a comic strip that got developed between our chief product officer at Koda, a guy named Lane Shackleton, and someone named Colin Breyer. Colin wrote the book "Working Backwards." He was Jeff Bezos's chief of staff at Amazon.
The two of them, Lane and Colin, came up with this idea that our meetings have evolved through three phases that have roughly corresponded with major technological innovations.
In 1987, PowerPoint came out, and we all had the next 30-40 years of meetings that looked something like this. You could build the slide deck, and you point at it, and you have no idea whether people are paying attention or falling asleep or whatever they might be doing.
In 2004, two things changed at once—total happenstance of history. Two things happened in 2004.
So number one, Jeff Bezos wrote a really famous memo called "No More PowerPoint." It turns out Colin was telling the story; Colin was actually one of the drafts of this memo. He had Jeff send it out to the company. Neither of them thought it was going to be that big a deal, but of course, this is the memo that's been heard around the world.
Almost every company I've talked to has either adopted the Amazon method or they've anti-adopted the Amazon method and said, "That's not for us." But every single company has an opinion on whether that is a good thing for them or not.
So what first thing that happens with the memo? The second thing that happened the same year is the first version of Google Docs came out. It was called Writely at the time, and all of a sudden, it gave a collaborative surface for everybody to write together, and they could comment together on one write-up.
All of a sudden, every meeting turned into something that looks like this. We call this one-way write-ups.
This is a huge step forward from the presentation world, but it also had some downsides.
So what are the downsides of this method? A few things. First off, what does it mean if you don't comment? I'm sure you've all had the situation where you send out a write-up, and then you watch the avatars at the top, and at some point, you see the CEO's avatar come through, and then they poke around a little bit and then leave.
Then what the hell does that mean? They didn't leave a comment; they didn't say anything. What does that mean?
The second thing that happens is you get to the review, and then you're working your way into the review, and of course, what do you do? You go in order of the comments. It's the most logical thing to do.
The first comment says, "Hey, you made a typo in this first paragraph." This one says, "That was a grammar mistake." This one says, "Your project sucks; it should get canceled." This one points out another grammar mistake, and you kind of work through these things in clearly the wrong order to have your discussion.
Finally, what do all these faces behind here mean? Every review is framed as what I call "Jeopardy-style reviews." Every opinion has to be stated as a question.
So the most famous ritual at Koda is something we do called "two-way write-ups." Sometimes it gets shortened to "Dory Pulse."
This is the way it works. You'll often see this in a Koda meeting. We'll call these decision docs. You'll write your write-up, and we'll have this little button that says, "I'm done reading."
That's a way to say, "I've acknowledged that what you've written, so you know that I was here and I processed what you came up with." At the bottom is this thing we call "Dory." Dory is named for the fish who asks all the questions.
So everybody adds their topics here, and you vote them up and down, and we go through them in order of that voting.
Finally, in the middle is the most important part: this thing we call "Pulse." This is the two-way write-up. We expect everybody to write back, "What is your viewpoint on this decision? Should we launch this feature? Should we buy this company? Should we hire this person? Should we pivot this product?"
You write what you feel, give a sentiment, and one of the key things we do is we hide everybody else's sentiments until everybody's done writing.
This is our most commonly cited golden ritual. If you were to ask a Koda employee on their first Friday, they would almost certainly tell you about this ritual because they probably saw it 20 times that week.
It would be weird to come to a Koda meeting and not have a two-way write-up, not have Dory Pulse.
But the reason they'll talk about it isn't because they're meeting rituals; they'll talk about it because it's reflective of the culture.
I'll hear them bragging to their friends. They'll say, "Hey, I was in this meeting at Koda." I just say, "How's it going at Koda?" They say, "What's going great! They have this code as its value that great ideas can come from anywhere, and they really mean it. I was in this meeting, and I added a question and outvoted the CEO."
Or, "I was in this meeting, and everybody's opinion was asked for, and I got to write my opinion in a meaningful way. It was actually read and incorporated into the decision-making process."
I think it's a good example of a ritual that is a two-way mirror to our company culture.
I'm going to skip the other ones. I'll let you go through and read if you like.
One thing I might point out here is the Dory Pulse ritual is probably the most commonly copied ritual from the Koda team.
I went and cataloged 14 different ways that people have adapted it to solve slightly different problems. I'd highly recommend that Ariana has a great ritual on how to think about resetting how a team is thinking. It's a great ritual here from how Square runs one-on-ones.
I know we're going to run out of time, so I'll probably skip topic number four as well and let you think more about it.
But I'll just give you the teaser. This ritual came from Des Trainer, and it's sort of this is in the PSH framework. This is right at the E part.
He said, "Think about productivity's tools. Your email is what others think you should work on. Your to-do list is what you think you should work on, and your calendar is usually what you actually work on."
If you click through his doc, you're going to see a very interesting method that he came up with for how to do this.
I'll forewarn that the method he came up with is not for everybody. Some people are going to love it; some people are going to hate it. That's okay.
The more interesting thing is he came and presented this at one of our dinners, and I asked him, "The book is called Rituals of Great Teams. Why are you presenting a personal ritual?"
He had this interesting observation. He said, "Your team's productivity is upper-bounded by yours. What's your system?"
If you want to be able to be good at all four levels of PSH and E, you have to recognize that as leaders, you're leading a team where their productivity is upper-bounded by yours. You have to stay on top of your stuff.
I thought this was a very interesting one to share.
Last thing I was going to say is if you're interested in these topics, I'm happy to include you.
We do a lot of work with different people in this community with Supra, of course. Shir runs a great community; Lenny runs a great community.
There's a forum at the end of this. Drop me your info, and I'll make sure we keep you on the list for various activities we do in this community.
Alright, those were my four topics. Sorry, Mark, that took a little longer than I expected, but with some good questions in between.
Let's...
Yeah, no, this is great! Thanks so much.
I know Pratique had a question. Pratique, do you want to ask your question about Iing questions?
Yeah, for sure!
So I've read your article previously, and I really love the framework. But anytime I've tried to apply it to a problem area, I always struggled with, like, how do I even get started? You know, how do I come up with the Iing question?
Well, I'll give you...
Since you read the article, you probably already have this reference, but for others, I'll just give this reference quickly of an example of an exercise I like to run, and I'll try to answer your question on some ways to practice this.
When I think about a different way to phrase this question, I get asked a lot, "Can I learn this technique? Can people get better at this technique? Can I evaluate based on this technique?" I think all of those, the answer is yes.
So let me start with evaluate, and I'll get back to how you can get better at it.
So evaluate: for years, this was my go-to interview question, and I can't ask it anymore because now I've published it.
But the way I would ask it is, "A group of scientists have invented a teleportation device. They've come to you and asked for your assistance in bringing it to market. What do you do?"
Generally, the candidate would start asking questions. Good candidates are inquisitive, and they would say things like, "How big is it? How does a receiver work? Is there a transmitter?" They would ask all these different questions.
I would keep a list of them and say, "It turns out the scientists are introverts, and they are not at all enjoying your questions. They decided that they will only answer two questions, and from that, they expect you to give a clear go-to-market plan. What are the two questions you would like to ask?"
Some candidates would fall over, and others would find some way to identify the Iing questions in this set.
Just to give you an example, there's no right answer to this question, obviously, but this is one of my favorite examples.
This person said, "If I could only ask two questions, I'd ask these two: how safe is the device?" All I really want to know is binary: is it safe enough for humans or not safe enough for humans?
The second is, "Is the device more costly to purchase or to operate?"
If it's more OPEX heavy but CAPEX light, it's very cheap to deploy these, but costly to operate, and safe enough for humans, they would put them everywhere.
We're going to make them human fax machines; we're going to put them in every corner of every office, and we're just going to have them everywhere.
But on the other hand, if they're really expensive to produce but very cheap to operate, then we have to be very careful about where we put them.
We're probably going to put them pretty close to where we put airports, and you kind of work your way around, and you find lots of different go-to-market plans for each of these directions.
So I thought this was a really interesting example of how you evaluate.
It's also an interesting example of how to train. I used to use a very similar question to do a training exercise I ran with my teams.
I have a library of a few others. If you're really interested, ping me; I'll give you a library of them.
But what I learned was to get good at Iing questions, I tell you, I heard people ask this question all the time. They'll say, "How do I get better at this?" They say, "I tried it at work."
I'll say, "Oh, that's probably the mistake. Don't try it at work."
Here's the reason I feel that way: imagine we were trying to learn a sport or we're trying to learn an instrument, and imagine the only time you got to play the instrument or play the sport was in a live game or in a big concert recital.
How good a pianist would you be? How good a basketball player would you be?
The whole point of these sports is you get this safe space where I can go try it out with no risk.
The problem with learning a technique like Iing questions is I'll see someone read the article and say, "I tried it last week on this big discussion with the CEO. He disagreed with the Iing question, and the whole thing went sideways."
I say, "Don't start it in that framework. Start it with really simple questions. Do it with your kids; do it with a friend; do it with some business that isn't your business. Do it with something completely made up, like a teleportation device, and see if you can get better."
Have you and your friend both try it. See what techniques work for you.
You'll also learn in that process what is your technique.
Interestingly, this article, the page structure here is the opposite of what it actually is. I was first asked to write this third page.
This company, Miro, was launching a new feature with us, and they said, "Hey, can you use this whiteboarding technique a lot? Can you go and write an article about how you whiteboard in Miro?"
So I wrote this page, and I said, "Oh, actually, just to describe this idea, it's actually called Iing questions."
To motivate Iing questions, I'm going to start with this fun story about Modern Family, but actually, it turns out that the whole thing was written from the perspective of my secret.
I write, and in particular, I have this coloring of my pens that really helps me with framing problems.
It took me a while to figure this out. Black is question, blue is options, gray is example, purple is call-out, green is benefit, red is problem, and orange is selected option.
If you catch me with a... I'll often have a box of pens in my bag. I have all my whiteboards have these markers, and when I use Miro or use an online digital whiteboard, I use the same colors.
So my advice would be practice and watch your technique. Watch what works for you.
There are other people; they do it in lists. I make a list of six questions, and I rank them. You can even do it mechanically, like I'm going to do a dependency tree.
But for me, I find it much easier to think in terms of a diagram in order to do it.
So anyway, I do think that technique can be learned. I think that you should practice with non-critical topics, and then watch your own personal method. Everybody's a little bit different.
If you want to make mine, it's all there, so you can certainly try mine.
Amazing! Thanks so much, Shir.
I'll pass it on to you.
Yeah, thank you so much for walking through these ones.
I had a question about the golden ritual side. You're specifically thinking through how to implement them. Product-wise, it makes sense; you talked about it a lot.
But any learnings you have had when you're implementing them with product and engineering and design, like different functions that we work with, especially business teams?
Because, I mean, we have a lot of those. I work at Walmart's Sam's Club division, leading product teams there. Between the product teams, we have an amazing culture around a lot of our golden rituals.
But as soon as you start to do one step out, two steps out, and especially to the business teams, it becomes really challenging.
So any learnings over the years you have had would be awesome to hear about.
Yeah, let me grab a reference.
Okay, so if you were to ask me to recommend a book, if I could recommend five books, this book would take two spots.
The book is called "Switch." It's written by the Heath brothers, Chip and Dan Heath. The subtitle is "How to Change Things When Change is Hard."
Let me describe why that's important to this discussion.
I'll describe "Switch" first. I highly recommend reading the book; it's a very good book. I try to reread it every year if I can.
But it's a very simple idea. The book has a simple analogy that when you're trying to cause change, you can either direct the rider, motivate the elephant, or shape the path.
So you can do one of three things: you can direct the rider, you can motivate the elephant, or you can shape the path.
So the direct rider means you tell the person what to do. Motivate the elephant is you get them moving. You're not exactly sure where the elephant is going to move, but once they're moving, they're going to move somewhere.
Shape the path is you set up guardrails that sort of prevent them from doing anything else.
These three techniques are very important, and when you read the book, I would highly recommend making a list of things you're trying to change.
Pick something in your personal life, pick something in your team, pick something in your company, pick something in your industry, pick something in your community.
As you go through these three techniques, they're then broken down into three or four sub-techniques. Just check off which ones you tried.
Build a little matrix for each of these things you're trying to change. Which of these have you tried?
What you'll discover is that we each have go-to techniques for how we try to cause change, and everybody's a little bit different in how they do it.
But you'll learn what your go-to techniques are and how you try to cause change.
The other reason I think that is so helpful is if you go back and think about Bing's three tests.
Bing has these three tests for rituals: they're named, every employee knows them by their first Friday, and they're templated.
What each of these corresponds to is the same three things out of the book.
Why is it important that we name things? Naming things causes... it's a motivate the elephant technique.
We call it Dory Pulse; we don't call it question voting, and I don't know, private sentiment gathering, or something really boring. We call it something that can cause identity; it causes pride. Naming is very important.
It's amazing how many times somebody will tell me, "But we do this ritual." I'll say, "What's it called?" They'll say, "I don't know; it's just the thing we do."
I say, "No, no, go name it. It's very important."
So this is about motivating the elephant.
The second one, "Every employee knows them by the first Friday." Why do you do that? You direct the rider. You tell people in your first week, "We're going to teach you how to do this. Iing questions is an important technique for us."
We make it part of our onboarding.
Then they are templated. Why do we template things? We shape the path. We try to make it hard to do things a different way.
We just set it up that way.
I think when I see people struggling with, "I'm trying to change a ritual," it's often they've missed something in that, whether you think it was a switch framework or these three tests.
They've missed something in that framework.
These three tests are simplistic. I mean, I think that I find the book better that way because you'll find that, "Hey, I'm trying to get the sales team motivated to do this thing with the product team, but they don't want to."
It means you need to motivate the elephant.
They can't; they find it too hard. It means you need to shape the path.
They don't know how; you need to direct the rider.
You have to find the right ways to do each thing, and the book does a very nice job of breaking out different techniques for it.
So that's my way of thinking about how do you map rituals, especially in cases of friction.
Amazing! Thank you!
Good question.
And yeah, maybe another question for you.
So many of our Supra members are considering becoming founders. Actually, "future founders" is one of our most popular Slack channels at the moment.
I'm curious: what questions would you be asking yourself if you were in their shoes to assess whether being a founder is the right path for them?
I know we talked a little bit about spotting opportunities, but maybe talk a little bit more about the lifestyle or how your life changed from being a product leader to a founder.
What are some of those questions that you would be asking yourself?
I have lots of advice on this topic.
The probably the first one I'd start with is I wouldn't frame... I wouldn't start with the frame of "I'm trying to start a company."
I give a version of this talk; I just went through it. They gave a version of this at Stanford, and I like to start the talk by asking that room, "Who here has a list of startup ideas?"
At Stanford, every single kid raises their hand. That's just how the place works.
I'll say, "Okay, please take out your list or take out your phone, wherever your list is, and please retitle it from 'startup ideas' to 'things I'd like to see different in the world.'"
The reason that is so important is I think people start companies for the wrong reasons.
They'll often start them with a viewpoint of something about lifestyle. Sometimes, you know, it's greed, it's fame, it's fortune, whatever it is, and they misunderstand the choice.
They sort of make it seem like it's just a thing they're trying to see different in the world, but actually, that's not what's happening.
What they're doing is playing out, "I have to be the boss," or playing out, "I have to own x% of the company," or so on.
They also end up with enormous adverse selection.
I'll see founders come to me all the time and say, "Hey, I want to start a company, and here's my idea."
I'll say, "Oh, that idea seems so similar to what so-and-so is working on. Did you go talk to them?"
They'll say, "No, no, I can't talk to them. I'm me; I'm going to be a competitor."
I say, "Well, that's terrible! What are your chances of being successful in the space if you can't talk to the people who actually know the most about the space?"
So go retitle it to "things I'd like to see different in the world."
Go talk to the person, and maybe they'll convince you to join them, or maybe they'll convince you that the space sucks, or maybe they'll convince you that they've completely got it backwards, and you should compete with them, and you've got a different idea of how to go after it.
But go talk to them.
You won't feel bad if you tell them, "This is the thing I want to see different in the world."
I want to see if your way of doing it is the same as mine.
One of the reasons this is so important is I think in a world of two-way door decisions and one-way door decisions, starting a company is about the most extreme one-way door decision you can come up with.
I gave you my two tests earlier when you're joining a company: "Would I invest? Would I pay to work there?"
These are all somewhat two-way door decisions. You can join the company, and you can leave.
You start a company; you're not allowed to leave.
This is going to be... I'll often ask people, "Is this something that you feel so strongly about, a thing you want to see different in the world, that you want to work on it for 20 years?"
Because that's the good case.
The not-so-good case is you only get to work on it for a few months, but the good case is you get to work on it for 20, 30, 40 years.
I mean, you look at the successful founders; you better love this problem. You better think it is the most interesting thing to work on.
People will come and they'll say, "I found this gap in the market, and I think the gap is only going to exist for three months, and I'm going to get this thing out, and then it's going to be great."
I'll say, "But what's going to happen in year 10?"
They'll say, "I don't know; I'll be doing something different."
I say, "No, you won't. You'll be in that same spot. That gap will close, and you'll be in that same spot."
And that's what you're aspiring for.
So first thing, the first piece of advice I give people is retitle it "things I'd like to see different in the world."
After that, I think think like a real investor.
Take yourself out of the idea and say, "If I... would I invest if someone else were doing it? Would I invest?"
It's often a good test to say, "Would I join someone else?"
I often... one way I ask that question is, "Would you invest, or would you be willing to be employee number 10 for that idea?"
How strongly do you feel about that's a thing I want to see different in the world?
Interestingly, it's like not really... I started Koda with both the companies I started were... it was the last resort way to get this idea to market.
I tried every other way I could to try to get it to market. When that didn't happen, I couldn't let go of the idea. I was cursed to have to start the company.
I feel like starting a company should feel like that. It should feel like it's the curse. You feel stuck; you're taking one for the team. This has to be the only way I can do it.
So that's how I think about it.
Amazing!
I know we're at time. This has been incredible.
Thanks again so much for your time.
The question we like to ask at the end is, is there any way we can... the community can be helpful to you?
Oh, it's easy! Please join the Rituals of Great Teams Brain Trust.
Ritualsofgreatteams.com. Please read and comment on what I've written so far. Please contribute.
If you have a ritual that you think is great or an idea that you think is great, please add it to the list.
Feel free to add thoughts on things you're trying to fix, and we can see if there's something there that may help you.
I'd love your contributions.
Amazing! Thanks so much, Shir.
This has been incredible.
Thanks, everyone!
Great! Thank you!