Episode 12

"My product is the company" - Kevin Fishner on how startups can build better systems

Today's episode is with Kevin Fishner, the first business hire, former VP of Product, and current Chief of Staff at HashiCorp, a cloud infrastructure automation company. Kevin takes us through the most important systems at HashiCorp, including how they run meetings, structure annual planning, and make decisions through writing. His detailed explanations and practical advice will help other startup leaders remix these practices at their own companies.

Read the article that inspired this episode

Photo of Kevin Fishner
Subscribe with your favorite podcast app


Kevin Fishner: [00:00:00] Employees could leave and new in place could come over the course of 30 years to the point where there's none of the same employees there, is it the same company I would argue? Yes. And that's because of the systems that are put in place and gradually refined over time, that becomes a company and companies compete based on if those systems are really strong or they're not 

Brett Berson: [00:00:29] welcome to in depth, a new show that surfaces tactical advice, founders and startup leaders need to grow their teams, their companies, and themselves.

I'm Brett Berson, a partner at first round. And we're a venture capital firm that helps startups like notion, roadblocks, Uber, and square tackle company building firsts through over 400 interviews on the review. We've shared standout company, building advice. The kind that comes from those willing to skip the talking points and go deeper into not just what to do, but how to do it with our new podcast.

In-depth you can listen into these deeper conversations every single week. Learn more and subscribe today@firstround.com

for today's episode of in-depth. I am thrilled to be joined by Kevin Fisher. Kevin works at Hashi Corp and he's worn a lot and hats since he first joined the cloud infrastructure automation company in 2014 as the first business hire, Kevin started the sales solutions, engineering account management and marketing teams.

Later, he spent a few years building the product management and product education groups as the VP of product. But for the last year and a half, he's been in the chief of staff role, he's responsible for refining the company-wide systems like operating cadence, knowledge management and communication frameworks.

As Hashi Corp has grown from a few hundred to over a thousand people, or more simply as Kevin puts it. Now, the company is his product in today's episode, Kevin unpacks, exactly what that entails and shares his thoughts on how other startups can take a similarly thoughtful look at their own internal systems.

In addition to chatting about why the system side of company building doesn't get as much attention we dig into the nitty gritty of how they run meetings, set in track progress towards goals and make decisions through writing at Hashi Corp, from a detailed look at their scorecard system and unique business simulation exercises.

To his thoughts on why companies often struggle with, okay, ours, Kevin takes us through HashiCorp's annual planning process in incredible detail. We also dive into how they write up requests for comments and problem requirement documents, to both capture and come to decisions across the company. Finally, Kevin reflects on why we all need to make more time for practice at work and the importance of being an observer, not a doer as a chief of staff.

What I most appreciate about our conversation today is how Kevin combines the philosophical with the practical. One minute, he's talking about how determinism relates to company building. And then a few minutes later, he's walking us through the exact template and meeting format. Hashi Corp uses in its highly structured annual planning process.

Whether you're eyeing a chief of staff role, or you're a founder hoping to set the right foundation for your company, or you're a manager, just hoping to make your team run a bit more smoothly. I think today's episode is unique chance to really dive into how a company functions and get inspired for your own startup systems.

I hope you enjoy the episode. And now my conversation, Kevin, thanks so much for joining us. And thank you for having me have for the past few weeks. Been really excited about this conversation because I think the way in which companies operate in detail as one of the topics that's not particularly well explored and the product that is the company, I think is something that isn't particularly well understood or often under invested in.

And under-discussed. So I thought we could just sort of start by having you explain how you think about the company as the product and how that relates to people and systems. And then we can start to dive into some of the details after that. 

Kevin Fishner: [00:04:30] I think what you said is right, that a lot of early company advice that you read or listen to podcasts on or about the importance of your people over everything.

And while I definitely agree that people are your most important asset, especially from knowledge economy company, a lot of the thought leadership doesn't talk about the systems. So I've definitely read content about the first hundred employees set the company culture, or a founder has to interview the first a hundred employees.

But what I don't read is how the systems that those people build are the manifestation of the culture, or how, as a founder, you should think about your principles and how you want to manifest those principles as systems. So you should care about your first 10 systems or whatever the equivalent would be.

So that's the way that I like to approach company as product. What are the core systems that are the manifestation of the culture that you want to build? And importantly, this is not an either, or it's not that you invest in those first hundred people or your first 20 systems. It's both. And the comparison I like to draw is the nature versus nurture debate.

And I feel like every time that topic comes up, you start talking about, oh, well, how genes are the most important? I'm like, no, it's the medics. And the environments that you're raised in are the most important. And usually the outcome of that conversation is both, both nature and nurture are highly influential on an individual's outcomes.

So it's my belief that both your people and your systems are highly influential on a company's outcomes, but the system side doesn't get as much attention as it should. So. In my role as chief of staff in thinking about company as product, it really specifically thinking about what are the systems that you want to build improve, and really have ownership over like a product manager to make the company's culture and product activity come to life.


Brett Berson: [00:06:35] how did you land on this? Or what was the evolution to sort of have this crystallized for you? 

Kevin Fishner: [00:06:40] I feel like that deep philosophical question almost about my identity. The reason I feel that way is because I don't think there's such thing as a original idea. I think all concepts and ideas that we create are remixes of other ideas and you can create unique combinations for sure, but the ideas themselves are not unique.

The reason I'm saying that is my beliefs about. People and systems and how systems are just as influential are certainly not my ideas. And I'm trying to find where the origins of that are weirdly. I'm going to go back to in college. So I studied philosophy. My thesis was something like the political and economic impacts of subconscious advertising techniques.

And the basic premise was specifically theories of economics are built on the foundational belief that individuals are rational well-informed and autonomous. But none of those things are true. Like we are certainly have rational sides, but we're also very emotional. We're definitely not fully informed because that would be impossible.

And a lot of the information we consume could potentially be untrue and we're not autonomous because each person influences other people. So in my reading and research for the thesis, I started to come to the belief that freewill is overrated and our belief in the Supreme independence of the individual and our willpower to get things done is overrated.

And we're actually much more influenced by the environments that were put in. These points are really well-made and atomic habits about how, if you want to change something, if you want to eat better exercise, don't rely on your willpower instead, rely on changing some of your environmental influences to lead to those behaviors.

So if you're trying to cut out sugar, don't. Have things that have sugar in your house. So I think that the same is true in company building where you don't have to completely rely on the willpower and independence of all your employees, but you can think about how do I build systems, how do I create an environment where people can do their best work?

So I think a lot of research in this area about inclusive practices are really great and creating those environments. So I think that's where these ideas came from. And as I said, there, certainly not my own. I've been influenced by lots of philosophy. Reading about there is a mind and freewill and many other books and podcasts and things like that too.

So maybe it's a unique combination of ideas, but certainly not my own. 

Brett Berson: [00:09:31] So if that's the more philosophical, let's talk a little bit more about the practical and really outline when you think about systems. Exactly what you're talking about. And then we can take each one of those tenants in turn and go into some level of detail.

Kevin Fishner: [00:09:44] So first I think each company has their own systems that are really important for their culture. So everything I'm going to talk about are very important for HashiCorp, but I wouldn't say they're generalizable principles. So hopefully people can take them and remix them with their own ideas, but I wouldn't take them as absolute truth.

So for us, our most important systems are how we make decisions through writing as number one, number two is our operating cadence. So how we set goals, track progress towards goals and make improvements along the way. And then the third is how we run meetings and how we run meetings is particularly interesting for us because we are a remote company.

So most of the interpersonal interactions you have day-to-day are through slack and email. So written as well as Google docs. And through meetings. So it's very possible that many employees, their only face-to-face human interaction for the day is through a meeting. And if that meeting is good, then their day is good.

If that meeting is bad, then their day is bad. So meetings become this combination where people come together and the culture is truly seen. So that's why meetings are maybe more important for us as a remote company. Then other companies might treat them. 

Brett Berson: [00:11:07] Let's come back to meetings in a few minutes and start with the idea of operating cadence 


Kevin Fishner: [00:11:11] spend some time there.

So our operating cadence, we like to think of it as three speeds, annual, quarterly, and weekly, but before getting into the speeds themselves, I want to talk about the components and the components are sources of truth and rituals. And I've found that many companies, when they're building an operating cadence, oftentimes you don't hear the word operating, can instill here goal setting or okay.

Ours. And I think they're quite similar, but oftentimes what happens is companies will focus on the source of truth and not the ritual. And I think that's one of the biggest mistakes that you can make. So I think many people have the experience of someone decides that the company needs a goal-setting framework.

And usually that comes about because a team worked on a project that probably was a waste of time, or employees are confused about priorities or overall there's a lack of alignment. So the decision is all right, let's do okay, ours. And so the company goes through this month long process, and one unfortunate individual is usually tasked with making sure every employee has a set of, okay, ours.

And what happens is they go through this long process and the OKR is, are set, but then there's no ritual for reviewing them. So they easily get out of date and then employees start resenting them because the effort to actually create them was kind of a waste of time. So the importance of a ritual is that it keeps the priorities top of mind and keeps folks focused on what's important and forces a conversation about if there's an objective that was written down and it's not important that forces a conversation about that.

And it forces alignment as a result, as our operating cadence focuses on both the source of truth and the ritual. It's really the ritual. That is the most important part of it. So with that in mind, our operating cadence has three principles. The first is federated authority, but central visibility. So we have over a thousand employees.

Now we need to make sure that people closest to the information have authority and ownership over their respective goals, but we want to make sure there's visibility essentially with the exact team. So it can make sure that progress is being made and we can provide support if needed. The second one is reflection, not perfection, which goes back to the emphasis on rituals, where goal setting is a process of reflecting on progress, not trying to get your goals so perfect upfront that you never need to change them.

It's just not possible. Like you're either going to get it wrong because the goal is to hire too low or maybe like one of the goals was completely wrong and that's fine. The process of reflection is the most important. And then the third principle, which again, kind of comes back to rituals is find and enact leverage.

And this is one of the key lessons I've learned in the chief of staff role is leverage is the most important thing you can find. So whether you're doing OKR or QPRs or whatever your goal setting acronym is at the heart of it is trying to find leverage by which I mean, finding the actions that you can take that have the most positive cascading impacts across the company.

So, as an example, renewal rate could be a very important metric for the company. What is the primary action that you can take to improve renewal rate? Because renewal rates are a lagging indicator. It's pretty much set six months ago after the customer is onboarded. So what are the things that you can do, whether that's changing the way you onboard or changing incentives, what is that thing?

Or a group of things that you can do that have the most leverage to make the positive change that you want? So those are the three principles, federated authorities, central visibility, reflection, not perfection and find an act leverage. So as I go through the annual quarterly and weekly speeds, keep those things in mind.

So with that preamble on the annual side, the source of truth is scorecards. And the ritual is our annual planning summit and scorecards are effectively our incarnation of, okay, ours. And I personally don't care what goal-setting framework people use. I think they're all pretty much equivalent. And basically what one of our scorecards looks like is imagine a table with the first column being key results.

And then from there we track progress on those key results quarterly. So the other columns are quarterly snapshots of where we are. So as a very simple example, imagine if I'm just gonna use random numbers. Our revenue goal is a hundred dollars then in Q1, it was 30 Q2, 60, et cetera, et cetera. So you track progress quarterly.

And the format of that forces you to go through the ritual of review. So we do scorecards at really just the highest level of the company. So we do a company scorecard, which sets the overall company priorities for the upcoming year. And then we break that down into what we call our four plans. So a go-to-market scorecard that the sales marketing and customer success executives collaborate on product scorecard, which our product management and engineering executives work on.

And then on people's scorecard and a finance scorecard, which our VP of people and VP of finance work on respectively. Somewhat interesting about the go to market and product scorecard specifically is that they're jointly owned. You oftentimes don't see that in other goal frameworks and that you want to have one directly responsible individual.

It's my opinion. That software is not something that can be broken down into very tiny constituent parts and delegated out. It's more complicated that it's not a assembly line. So we have the company's core card. There was four plans, and then the go-to-market scorecard with them break down by field geography.

So we have Americas, EMEA and APJ. And then the product and engineering scorecard, we break down by our product lines and we have four product lines. So the reason we break them down in those dimensions is because of Simpson's paradox. And if you're not familiar with Simpson's paradox, it's when you take aggregate data and use averages, the actual nuance of what's happening gets lost.

So the famous example is pretty sure it was Berkeley graduate admissions, and they found that women were accepted to graduate programs at a much lower rate than men where they're confused because they did gender blind admissions. So what ended up being was if you break it down by department, so like physics, literature, MBA, it was actually the same.

For men and women, but women were on average applying to harder programs at greater rates. So when you look at the average women's acceptance rate is lower, but if you compare department by department it's equivalent, that's why we want to do the scorecards by product line. So if vault is doing really well and Terraform isn't, we don't look at the average and say like, great, everything's fine.

We look at vault and Terraform specifically and manage accordingly. So those are the source of truth from the annual perspective. And then the annual ritual is our annual planning summit, where we bring basically the top 70 senior leaders of the company together. And we run a business simulation. We work with a firm called VTS where we'd take a simplified view of the company, build a, essentially a game board and break folks up into teams of six.

And they are CEO or the executive team for the two days that we do the simulation. So they can not only understand what the priorities are for the year, but kind of feel them in the simulation itself, which is a cool experience. Can 

Brett Berson: [00:19:02] you explain that? That's obviously, I think quite a unique thing that you do.

Can you explain more about how the simulation works and then how that ladders into the outputs, which are these annual 

Kevin Fishner: [00:19:14] scorecards. Yes, definitely. First we start with the company, scorecard comes first and that's where the executive team determines usually the three executive focuses for the upcoming year.

So last year it was focused on one of our product lines, which was console a focus on defining a segmentation model for our customer base. So grouping the largest 500 companies, then the next two, 2000 companies, et cetera. And then the third one was cloud-first orientation for our products. So we had historically provided our software as downloadable software, but this year we've been providing them as cloud services.

So those are the three focuses and then we build the simulation basically. So 

Brett Berson: [00:19:57] before the annual planning offsite, the executive team comes up with these three focus areas. Yes, exactly. And then that is sort of what. Guides the sort of overarching simulation. And then how does that foot with we're going to get this number in terms of net retention or revenue or whatever, sort of might be considered more classical high-level goals that everything kind of ladders off of.

Kevin Fishner: [00:20:22] So we have three north star goals that don't change, but they change in magnitude each year. So our three north star goals are to win the practitioner and that's, that's measured as a monthly active user account. Our second goal is to enable the customer, which is measured through ARR. And the third is to grow the ecosystem, which is measured as a percentage of revenue attributed to our ecosystem partners.

So like what percentage of our revenue comes from opportunities through our cloud partners or our systems integrator partners. So each year we set specific goals for those three north stars. So last year, again, these are random numbers. So let's say our ARR target was 50. And our goal of this upcoming year is a hundred, whatever that might be.

So we take those and then our finance team builds a long range plan, which is a five-year financial model that takes those north star goals and builds derivative financial metrics. So that's what you were talking about around renewal rate, net retention rate, operating margin, everything that you would expect in a financial statement effectively.

So together we have this rich five-year financial model, as well as the three executive focus areas, which are really the leverage points that we as an executive team think will have the most positive impact on reaching that five-year long range plan. And then we build the simulation around the simplified version of the financial model and the executive focuses that are coming up.

So the game board is effectively the financial model, and then you play in rounds where each round your team gets to determine what initiatives to invest in. And we also have what the BTS folks call wobblers, which are events that come up that probably throw you off track. And you have to make a decision about how to adjust.

So behind the scenes, the game mechanics are built so that if you invest along the same lines as what the executive focuses are, the financial model and the game board itself, the game mechanic you'll have better results. So that's how the interplay of our financial model and the executive focuses come together through a business simulation.

Does that make sense? 

Brett Berson: [00:22:36] It does. And so if you weren't able to have the company create this simulation. Are there simple versions of this that would get the benefit of that part of the annual planning process? 

Kevin Fishner: [00:22:48] I'm sure. I think it also depends on the size of your company. And I think this is a really good example of what works for HashiCorp certainly might not work for other companies.

So if you think about what the essence of this is, you might be able to build it up in a different context. And the essence of this is the notion of practice. This is something that I think about a lot and I grew up playing competitive soccer and. We probably practiced four or five times a week for club soccer.

And then you played games on Saturdays or Sundays, but basically you spend 90% of your time practicing and 10% of your time actually having to perform. And this is true for plays and people who were playing instruments and many things growing up, you spend so much time practicing, but then when you get into a work environment, that notion of practice kind of gets lost.

So the essence of the simulation is it's a practice and it's a time to make mistakes and that's completely okay. And learn from those mistakes. So if you were to create a simplified version of this and maybe not build a simulation. I would build it around the notion of practice and that could look like a smaller group offsite, where you're sitting in a different person's shoes and going through one of their day to day activities, whether it's like answering support tickets or something like that.

And it's a notion of practice, practice, and empathy for what other people are going through in the company and the problems that they're dealing with. I know that wasn't a very direct answer, but hopefully that idea of what is the essence. And can you rebuild that essence in a different context is helpful.

Brett Berson: [00:24:23] I liked that. One of the things I read recently was this piece that Tyler Cowen put out, he basically said one of his favorite questions recently is. What is it you do to train that is comparable to a pianist, practicing scales, and that sort of exactly what you're getting at it. I think it's a super interesting question for whatever you do for work, continuing to build, hold on the annual piece.

What else happens at the annual planning summit? And then how does that lead to this annual scorecard? And then we can talk about 

Kevin Fishner: [00:24:49] quarterly, a monthly. So, as I mentioned, the company scorecard comes first, then the four executive scorecards, the go to Michael one product, people in finance come after and they usually get refined leading up to the annual planning summit.

We build our company's core card, the first draft of it by the end of September, then the finance team and myself, we work on. Both the resource allocations and scorecards for the executives. So we give the executives a scorecard template and say, fill out your goals. And we also give them budget and headcount allocations and determine your organizational structure and budget to reach those goals.

And then that goes from mid October to mid December. And then the first week of December is when we do our annual planning summit, which was where we bring the 70 senior leaders in the company. And after that is when the field geography and product line scorecards start after that, the other things that happen at the annual planning summit, our CEO will give a presentation that reflects on the previous year and then projects on the next year, which is largely focused on what the three executive focus areas will be for the upcoming year.

And that's the details on the company scorecard. And those are the things that you simulate out in the business simulation itself. So this year, it's all remote. Last year, we did it in person in San Francisco. It's two days and it's four to five hours per day. So not too crazy. But the other important thing about this is for this year, at least we normally do an in-person all company conference.

We call it hex, the HashiCorp exchange, but for this upcoming year, we're doing it remotely because of COVID. And what we're going to do is do the business simulation for all employees this year. So the annual planning summit is a way to get senior leaders comfortable with it and refine the simulation itself.

And then they kind of become guides or proctors for the rest of the company when we do it in the first week of March. And we do a few other things around the employee conference there too, but that's really the heart of the planning 

Brett Berson: [00:27:01] summit. Can you talk about the different voting systems you use to discuss and debate the different objectives?

Kevin Fishner: [00:27:08] So this is for the company scorecard itself. And this actually, we might touch on this later with how we run meetings. The process that we use to figure out the executive focuses is through a fairly well-structured brainstorming. And there's a few studies that the Harvard business review published around how brainstorming, when you just bring people together and ask them to put stickies up on a wall.

It doesn't work that well. The preference is if you allow people to think independently beforehand, this has two benefits. One is they will approach it from more unique perspectives rather than getting stuck in group. Think if you do it all together. And the second is usually there are more folks who are more thoughtful when they just have more time and there's not as much urgency.

So that's what we do is we give executives two weeks before we do an exec offsite where each executive writes down what they think the three focuses should be for the upcoming year. And then each exact gets five minutes to talk through their suggestions. And then we'll usually debate some of them or discuss them along the way.

But what this does is it gives every executive, an equal opportunity to have their voice. There's no person who's talking over another or anything like that. So at the end, we do do the suggestions. Oftentimes there's a lot of overlap, which is very good. And then we put them into a list there's usually about 15 and then each executive can rank five initiatives, five being the most important one, being the least.

And then we just do a sorted ranking from there. So what happens is usually we'll have three very clear priorities and then maybe one or two below that, that we discuss. And then those three or a combination of those three become the executive focuses for the upcoming year. And it's surprisingly not very controversial.

I think through a different approach. If you had 13, strongly been an executives in a room, trying to figure out what the three focuses should be, there would be a lot of controversy and people would get more tied to their suggestions rather than collective ideas. So that's the way we do a structured brainstorming and then a way to voting and then distill it down to the top three from there.

And it works very 

Brett Berson: [00:29:26] well when we move on to quarterly. Can you, re-establish the different steps along the way before and after the annual planning summit, just cause it's a little bit confusing about rituals that go into the summit, then what happens? And then what happens after the 

Kevin Fishner: [00:29:39] annual summit? The annual process has the source of truth, which is the scorecards.

And then the annual planning summit, which is the ritual and leading up to the annual planning summit. The way that we build scorecards starts with a exec offsite or virtual session in September, where we do a structured brainstorming around what the top three executive focuses should be. And then those get refined for a few weeks to determine those focuses and then also build quantifiable measures for them that we put into the scorecard.

And then that's done by late September, early October. And then from there, the finance team and myself, we distribute the scorecards for the executives, which is a go to market scorecard, product scorecard, finance scorecard, and people scorecard as well as their resource allocation. So how much head count and budget they get for their respective functions.

And then those executive scorecards get built from usually mid-October to mid December. And they're pretty much done by early December, which is when the annual planning summit is. And then once annual planning seminar is done, we do the remaining scorecards, which are the field geography ones. So north America, EMEA APJ, and then the four product lines that we have.

Brett Berson: [00:30:54] And so if over those few months you're getting more and more granular and these are kind of different stops along the way. And you're kind of going top down in that fast. 

Kevin Fishner: [00:31:02] Yep, exactly. But importantly, we don't force it further than the field geographies and the product. 

Brett Berson: [00:31:10] So if I were to look at a field geography scorecard, can you give a sense of like what the altitude is flying at?


Kevin Fishner: [00:31:16] So the Americas scorecard, as an example, first to give you an order of magnitude, there's probably about 150 people. So sales folks support customer success, sales, engineering, field marketing, dedicated to the Americas. So it's a pretty large group of people. And then their metrics are around things like.

Top line revenue, renewal rate expansion rate, and then leading indicators like pipeline, generation, pipeline, coverage, things like that. So that is the altitude that we focus on. We don't try to cascade it down into individual regions like New York, Metro, or Texas or things like that. That is a responsibility of the Americas leadership.

Brett Berson: [00:31:59] Let's move on and talk about what happens on a quarterly basis. 

Kevin Fishner: [00:32:02] So just like annual quarterly has a source of truth and a ritual. And the source of truth is the scorecard. Plus what we call war table it's w a R and that's an acronym for wins action items and requests for support. And I'll explain those in more detail.

And then the ritual is a quarterly business review QBR, and we do a QBR for each one of the scorecards. So in total there's 12 scorecards. So we do 12 QBR. It's each one's a half an hour where they review their progress on the scorecard itself and their reflections on the scorecard. So that's the source of truth.

Going back to what I described earlier, the scorecard document is the scorecard table, which has a list of key results that we track and measure progress on, on a quarterly basis. And then it's reflections on that. So what are the wins? What are the things that based on the score card are great accomplishments that we should celebrate and keep moving forward on the second are what are the challenges and, and importantly, the action items on it.

So what areas of the scorecard are your metrics not tracking towards the goal? So as an example, for one of our products, Terraform, the activation rate. So the percentage of users who become a monthly active user divided by the signups was low last quarter. So that becomes a challenge. And the action items are the group.

Uh, the set of changes that the Terraform leadership team will make to improve on that, that we'll follow up on the following quarter. And then the third area of reflection is requests for support. So what are the areas that you need help either from the executive team or from a peer function that will help the group reach their, their goals?

So in the QBR, we go through that set of reflection in a document. So they get usually about 15 minutes to the reflections themselves. And then the other 15 minutes are for conversation and just discussion about areas that might need improvement. The important thing about this is the ritual keeps us focused on what we decided was important earlier in the year.

It's again, kind of that notion of practice of continuously reflecting and refining on the way that we go about accomplishing our goals. We don't think it's going to be perfect from day one, but if we keep reflecting and improving, it will get better over time. It's also very much a system of accountability.

So rather than me personally, holding owners effectively accountable for their goals, which I wouldn't be able to do because as a chief of staff, you really have no authority. I also wouldn't have the time to do that. The ritual is what creates accountability because the owners of the scorecards know that every quarter they will review their progress to the executive team and they will also review what they said they would accomplish last quarter.

So the Terraform team this quarter, they know that they're going to review the activation rate and the changes that they said that they would do. And if they didn't do them, it would be very, very obvious to the executive team. And we want to hold them accountable for that through a group dynamic rather than really just individual dynamic.

Brett Berson: [00:35:16] And then how does that have scaled to monthly and 

Kevin Fishner: [00:35:19] weekly? The weekly cadence is the same as a source of truth and a ritual where the source of truth is a, we call it the corporate reporting pack. It's really a set of key performance indicators. That is a superset of the scorecards. So it tracks lots of different things.

Everything from our current quarter sales forecast, renewal forecast, renewal, leading indicators, sales, leading indicators, broken down by product and field geography. As well as things like progress towards our hiring goals. So it's an attempt to have as close as possible as to like a company cockpit where you can see it leading and lagging indicators of how the company is flying effectively.

And there's a cross-functional group that compiles that set of metrics every week. And it's really important that it's cross-functional because that ensures that it is truly one source of truth. And there's a clear definition of things that you would think are very clear, but like, what is our sales forecast?

Oftentimes the finance team and the sales team have different views on that. But if you can get to one source of truth that aligns people much better. So the cross-functional team, which is a sales operations set of folks, finance, a go to market systems, team, and myself review the metrics and the corporate reporting pack.

And then we pull out insights. So areas that are trending red, that we need to take action on. And then the executive team reviews that every Monday and takes action if necessary. So it becomes a more fine Grande review of what's important for the company and how we're progressing. And I think this is another area that I wish I did differently when building the operating cadence, where I've spent a lot of time building the QBR quarterly business review cadence at first, but it was hard to get it done because there wasn't consensus on how we are measuring some of the key performance indicators.

And it kind of forced a group of us to define those KPIs and the corporate reporting pack. And it became more of a foundation. 

Brett Berson: [00:37:30] So one question I had, and you touched on this a little bit between. Weekly reporting at executive team and then quarterly business review is how do you keep it from getting too in the weeds and to locust on various specific numbers on a weekly basis.

And then you kind of snap back to a more strategic level on a quarterly basis. And it seems like you could kind of be over rotating towards small movements and numbers and then say, oh yeah, we have these objectives. And we got to focus on those. Is there any balance or a way to make sure you're not kind of pushing these little numbers on a weekly basis and forgetting about your quarterly yearly and five-year vision.

Kevin Fishner: [00:38:07] This is one of the art, not science aspects, I think, but I guess some science answers first is your weekly KPI deck should cover. The metrics in your scorecards. So that way it's a positive reinforcing loop, not something that's detracting or distracting from it. So ours are probably 80% overlap and it's an area we need to get better at actually is making sure that they're as consistent as possible.

And the other thing is surprisingly is it allows us as an executive team to be more focused and not track or hunt things down. That could be a distraction. So by saying, these are the most important metrics that we'll use to operate the company. It allows us to stay focused on that without being like, oh, this different leading indicator is acting up and we need to take action.

Then we don't think that's very important for the health of the company. So it doesn't need to be saying we focus on. So the science of it is the making sure your weekly reporting pack is. Truly representative of the most important metrics of the company. And it's taken us five years, probably because it builds up from the company north star goals.

But the nice thing is the weekly ritual. That's a lot of practice every single week. We're practicing are these the right metrics? Is this completely accurate? So it's a really great practice and a very limited percentage of it is performance. And by performance, I mean, taking action on indicators that are not doing well.

So in a, maybe a paradoxical way, it allows us to not get distracted and keep us focused on the annual and quarterly. Objectives that we set are 

Brett Berson: [00:39:53] important. And in that weekly executive team meeting, if I was a fly on the wall, watching what was going on, can you give a little bit more fidelity in terms of like, what is happening in the executive team meeting?

Kevin Fishner: [00:40:05] Yeah, so it's Monday afternoons and it's an hour. And what we basically do is break it up into four 15 minute time slots. And the first 15 minutes we review any insights from the corporate reporting pack that we need to discuss. As well as any company level action items we took from the previous QBR. So one of the positive outcomes of the QPRs is as an executive team, we get really great visibility across all dimensions of the company.

And we're able to identify key problem areas and thus identify what actions we need to take to improve on those. So we usually have a list of about 20 things, which sounds like a lot, but you delegate it out to other folks in the company. And we review those in those weekly meetings. So the first 15 minutes is, as I said, the insights from the corporate reporting pack and then the other three 15 minutes slots, we usually have a guest speaker, I guess, come in.

And present on one of those action items that we took from the previous set of QPRs. So this is yet another level of accountability to make sure that for the challenges that we surfaced in the QBR is are we following up on it? And are we making sure that we have the right people following up on it too?

So it allows people outside the executive team to have ownership and accountability and influence on key company outcomes. And it also reduces some pressure on executives to take care of everything. So 

Brett Berson: [00:41:37] that's kind of chapter one, talking about operating cadence. Let's move on chapter two, which is making decisions through writing, which is kind of one of my favorite topics and would love to spend some time talking about 

Kevin Fishner: [00:41:48] that.

Like all other things and origin story is the best way to start and quick background on Hashi Corp. Uh, we are a remote. Company with employees all over the world. I think we have 1,050 ish employees right now, I think over 13 countries and 40 states within the United States. And I like to think of, oftentimes I would say many remote companies define themselves as a remote company, and that is one of the major influences on their culture for us.

I like to take one step back and describe us as a open source company. And remote is an aspect of open source. And the reason why I think that's important is because a lot of the practices that we have are born out of more open source culture than remote culture. And it's a subtle difference that I find interesting, where when you're working on open source software projects, there's a ton of written collaboration on GitHub.

So it's the way that open source engineers are used to collaborating. So for us, our writing origin comes from that open source ethos as well, the philosophy and principles of the early employees. So especially Mitchell Hashimoto's and the company's named after him because growing up and in college, he would take a notebook with him everywhere.

And whenever he would have ideas for software projects, he would be really, really diligent about writing them down first. So when he and Armand started working on the open source projects, they would really write. Painstaking designed documents and documentation before writing a line of code. So that idea of writing the design before implementation became a core part of the company and specifically on the engineering side and the first 45 out of 50 employees are engineers.

And then it's been gradually adopted by the rest of the company. So our finance team writes lots of RFCs about what our expense system will be or the long range plan. So it's become a way for us to document decisions and get buy-in before actually moving into implementation. And it's kind of become a superpower for the company.

Brett Berson: [00:44:09] And so can you go a level deeper and talk about the different types of documents and what they look like and how they're 

Kevin Fishner: [00:44:15] used. Yeah, definitely. So we have two core documents. The first is a RFC, which is a request for comment. And that's basically your solution or design document that proposes, Hey, here's the implementation that we're going to do.

Let's get approval before we start. And then the second document is a PRD, which is in most companies, a product requirement document, but we've tweaked it a little bit to be a problem requirement document. So that is oftentimes a precursor to an RFC that defines the problem before going into the solution stage.

Not every RFC will have a PRD. The product management team definitely writes PRDs a lot. And we have found that for some of the more ambiguous challenges that we're facing, it's helpful to write up Yardi first to make sure everybody's in agreement on what problem are we actually solving before going into the RFC stage?

Brett Berson: [00:45:09] To go a little bit deeper on the PRD. If I'm reading one, can you kind of give the outline of what I would see and then the same thing for the RFC? 

Kevin Fishner: [00:45:16] So for the PRD, there's probably four core sections. So it's the background context is number one. The second one is a very clear problem. Statement. Three is a list of personas and how they experienced those problems statements.

And the fourth is a list of requirements and phases, more of the traditional product management PRD that you would expect where it's a list of requirements that the engineering RFC should satisfy. And then the RFC is really two core sections, the background, and then the proposal itself. And the proposal is where there's a bunch of subsections about different aspects of the implementation effectively.

And then there's a third optional section called the abandoned ideas. This was one of the evolutions of the RFC where we found that there were really good debates that were happening in the RFCs. And rather than only leaving what the outcome of those debates were, is putting the alternative ideas into the abandoned ideas section.

So that way readers would understand like, oh, the writer or the group of writers also explore these other two options. And those weren't good because of these reasons. So it gives a more holistic picture 

Brett Berson: [00:46:27] level of problem or potential project warrants, documentation like this. Like if you're in an office and you wanted to change what snacks the company was having, is that something that is too granular and somebody just goes and does that.

Kevin Fishner: [00:46:40] I would love to see us snacks, RFC. That would be amazing. All the different problem, statements and solutions for snacks. I actually do think, yeah, there would be a snacks RFC, potentially the guiding principle that we use for whether or not you should write an RFC or not is if the time it takes to make the change is faster than writing the document itself.

You can usually get away with not writing an RFC in from the engineering side. If you're making a pretty simple change to the code base that is not highly controversial. That's okay. But if it's a change that would take a few days then yeah, you should be writing RFC. 

Brett Berson: [00:47:20] And this is a tool used across the company regardless of functional area.

So if I'm changing something in our sales ops, or I have a problem, I think should be solved in the way that we handle a piece of customer success. Customer success lead is going through the same process. 

Kevin Fishner: [00:47:34] Yeah. And some groups are certainly better than others. I mean, engineering, since the RFC process was born, they're very, very diligent and great at writing.

RFCs the sales operations team has started to write RFCs more deliberately and for those changes and it's been hugely helpful for collaborating on cross-functional systems. So like marketing operations systems, sales, operation systems are highly intertwined. So having a document says, here's what we're going to do.

It has been amazing help. There are areas of the company that don't use RFCs as religiously, I suppose, I would say within the sales field, we wouldn't expect necessarily for sales reps to be writing RFCs, but they're also not really changing core systems that have a pretty dramatic effect over the rest of the company.

So it's okay in that regard, but over time, more and more groups have picked it up and adopted it and diligently use RFCs, but it's certainly a work in progress in some areas. 

Brett Berson: [00:48:31] And I guess the sort of last thing on this theme, if I were to be joining your company or joining your team, and you had a bit of time to sort of teach me about.

Potential pitfalls or issues or things I should know about writing in the context of your company, what are the types of things that you would be teaching or explaining 

Kevin Fishner: [00:48:48] to me? Fortunately, we do have funny enough, a RFC for how to write RFCs as well as an RFC template that everybody follows. But specifically, what tips will we give first?

If this is your first time writing an RFC is to work through it with a buddy. So someone who's written an RFC before, someone that you can sound ideas off of the second is really make sure you do read the hotter NRFC document and follow the template that we've learned a lot over the past six, seven years on these written documents.

And there's good reasons for why the template is the way it is and why we recommend the processes followed the way it is. And then from there, I personally. Recommend before starting writing your document is to seek diverse perspectives first, because usually when you're working on an RFC, you have some idea of what the solution is, but it's good to get diverse points of view before you only go in that direction, because your view is only one perspective.

So diversity perspectives can be other engineers on your team, or if you're in marketing, seek out the other people that the RFC will influence before you start writing it, because you'll hear their perspective and build a better solution as a result. And almost as important as you'll have much better buy-in on the RFC because the people will see their words in your words and be bought into the solution because it's partially there.

So there'll be joint ownership. The second is oftentimes when we're taught to write, it's very linear. So you write your introduction, your body paragraphs, and the conclusion. But if you start inside out, if you start with the outline and then build around it and kind of end with writing your introduction and your conclusion, it can be a more holistic way to write.

So that's my approach is I start with the essence that outline and then build outside of it. And then the last part is getting feedback. So you share the RFC with relevant stakeholders that would be effected by the document or the solution proposed in the document and they give feedback. And this is a really important process.

One to just make sure that the solution is appropriate and takes in the necessary perspectives, but two it's a cultural practice. And the way you give feedback on RFCs is one of the predominant ways we give feedback in the company. So making sure that you're giving feedback on the document itself, not the person.

So changing the way that you get feedback to not overly use the word you. So like, why did you write this rather than saying like, can this point be clarified or why is this aspect of the solution the right way to go? So it removes the idea of the necessarily the person and the idea. So you can give feedback on the idea and not directly on the person.

Brett Berson: [00:51:39] Can you think of one or two that you read at some point in the past few months and kind of explain at a high level, what are the contents of it? 

Kevin Fishner: [00:51:48] So for the finance long range planning, RFC, it's broken down into the background, which explains the finance planning cycles. So there is the long range plan, which is done every year and has a five-year view on our core company financials.

Then there's the annual plan, which takes the upcoming year aspect of the five-year plan. And that's how we build our top level goals. So revenue goals being the most obvious ones and then head count budget, et cetera. And then we update forecasts the finance team updates forecasts quarterly. So that's the overall context.

And then the proposal itself is what actually is the long range plan and the considerations that they list there's five. So one is produce long range plan that arrives at our north star metrics within the state of timeframe, which is fiscal year 26 for us, which has calendar 2025. Number two is create the guardrail cost structure for our gross margins and then our cost allocations to sales and marketing R and D G and a that's what you would expect on a financial statement.

And then the third is build a clear path towards EBITDA profitability. Fourth set the guard rails to not violate a magic number of one. And those from familiar magic number is the current year revenue divided by last year sales and marketing cost. So if it's over one, that means for every dollar you're putting in, you're getting more than a dollar out.

And then the fifth consideration for us personally is set the near term. So the next year and mid term, next two to three years for what our financial statement will look like as more of our software is a cloud service. So that's the overall consideration. And then they break down what are the exact components of the long range plan?

So it starts with our total addressable market income statement, balance sheet statement of cash flows, our non-gap air table, and a bunch of other stuff. So it goes into pretty clear detail on what are the exact components of a long range plan. And then the last piece is who are the constituents that approve and give feedback into the long range plan itself.

And so 

Brett Berson: [00:54:06] then anybody that wants, can basically provide comments or feedback on that basic plan, and then it gets approved and gets implemented 

Kevin Fishner: [00:54:14] in some way. Yep. Exactly. So I skipped probably a interesting part, which is there's a heading at the top of it, which explains a very quick one sentence summary it's status, whether it's work in progress in review approved or obsolete, the owner, which in our case is Ananda, who is our director of FP and a contributors, which other people who've worked on, the document, other stakeholders, which are reviewers and then the approver, which in our case is Yvonne.

Who's our VP of finance. And then this is all in a Google doc. So people can give comments, ask for clarity, all the good stuff. I think that's what's one of the people is that I am a devout follower of Google docs and Google sheets. But the thing that I find so interesting about them is it is a source of truth that everybody improves.

So one of the issues with things like. Versioned documents getting passed around is you're not really continuously improving one thing. You're creating forks of that thing. So you start to diverge rather than converge. So 

Brett Berson: [00:55:17] let's talk about the sort of last pillar, which is how you run meetings. 

Kevin Fishner: [00:55:21] Before getting into the details.

I would say this is the area that we have the least definition and the most area of improvement, just like all the other areas. We break down a large topic into smaller topics. So there's many different types of meetings, not just one. So we break it down into structured brainstorming number one, project kickoff, number two, weekly team meetings.

Number three. One-on-ones. This is number four and ad hoc discussions, number five, and each one of them are of course different. And the way you approach them should be different as well. So going through those structured brainstormings I talked about this earlier with the way that we did our executive planning for the upcoming year.

So the principles of the structured brainstorming are first and foremost inclusion. So making sure that everybody has a chance to be heard and heard without interruption. And the second is thoughtfulness. So giving people a chance to write down their ideas without being influenced by other people's points of view, the second and third, which are project kickoff and weekly team or project meetings, I'm going to talk about those together because they follow a very similar.

Flow, which is similar to what we talked about, which is source of truth and a ritual. So ideally your weekly team meetings or a project meeting should have a clear source of truth, which would be the project plan or the key metrics. And then the ritual is reviewing that same piece of information every single week.

And this does what we talked about before. Is it sets expectations for what is expected? What does success look like? What are people responsible for? And then it's a constant process of reflection. Are these, the right goals is the project on track, et cetera. And it also makes it so every meeting people come in knowing what's going to happen, it's not like you're working on the meeting itself.

You're just working on the content that the meeting holds. The fourth is one-on-ones. So there's two types of one-on-ones. The first is with a manager and a report. And the second is a peer one-on-one. The manager and report, I think is pretty clear. The peer one-on-one is like the VP of product has a one-on-one with our VP of engineering.

So it's those pure relationships where you have shared work and the goal of those one-on-ones. I mean, there's lots of goals, but the way I like to think about it is. It's more about cultivating a relationship than asking for transactional deliverables. So, as we talked about in the beginning, meetings are some of the few.

Directly personal interactions employees have in a remote company every day. So it's important in the one, the ones where it is really a one on one person connection that you use it to build and cultivate a relationship of trust. So not just talking about the action items that you all need to work on together, but getting to know them, checking in, seeing how they're doing outside of work.

So that's one-on-ones and then ad hoc discussions. This is kind of the catchall, every other type of meeting, but oftentimes these ad hoc discussions are founded upon an artifact. So a written artifact specifically. So it really helps if you are working with someone. On a project. And that project is grounded in an RFC because you can get a view into each side's thinking and then have a conversation about the proposal and the RFC.

And once that conversation is over it, you can actually documented in the RFC itself. So the outcome of the discussion is clearly documented for both of the people involved in that discussion, but also anybody who wasn't involved as well. And that's really important for us because of time zones. There's people who work in California and France and Australia.

So you can't really get those people in one meeting. So when those ad hoc discussions come up, it's important to document the outcome, ideally in an RFC. So other people can be heard as well. 

Brett Berson: [00:59:49] So zooming all the way out. Are there other parts of your system, or are there parts you're thinking about adding or are there other pillars or parts that you've removed over time?

Kevin Fishner: [01:00:01] So I'll start with the other areas that we're thinking about. There's two, the first system is internal communications and we've gotten to the size where it's hard to keep a thousand people informed. And it's an interesting question of how do you get the right message to the right person at the right time?

And an interesting parallel here is this is largely what marketing organizations are tasked with for prospective. Users and customers is how to get the right message to the right user of the right time and they use systems. So I'm very curious to see if a similar system can be built for internal communications, where if you treat all of your employees like a user, how do you get the right message to the right user at the right time?

So if an employee is looking at the company scorecard, for example, should you send them a message about like, Hey, I noticed you're looking at the company score card, also check out some of our key performance indicators, whatever that might be. And I think that's interesting from a top-down perspective, as well as a bottom up perspective.

So some teams send a weekly updates to the company, some teams don't. The teams that do they're all in a different format. So we do have the seedlings of grassroots communication, but there could be a structure that makes it much more impactful for the rest of the employees who are reading that content.

So it's an area that we're definitely interested in exploring and the key problems statement of how do you get the right message to the right employee at the right time. So 

Brett Berson: [01:01:36] if I were to come to you and I'm a chief of staff at a 200 person company, and I came to you and said, Hey, I listened and read a lot of what you wrote about building systems and the power of them.

And I want to do that at my company. What advice would you give me? Or how would you coach me to increase the odds that I land on something that's really powerful? I think you sort of did a great job framing the start of the conversation, which is this isn't necessarily something that you can copy and paste.

And I'm curious in an open source context, do you think I can take this and fork it and customize it or do I go back to first principles? And so for all the folks that are thinking about becoming more intentional in this area, 

Kevin Fishner: [01:02:15] what perspective can you share? I'll talk about first principles that I think apply almost everywhere and then some things that could be forked, which is a good metaphor.

So the first principles that I operate on are lessons learned from my mistakes. And the first one is be an observer, not a doer. And this was a good lesson learned when I just stepped into the chief of staff role. You get an interesting perspective on a company because you kind of get the CEO's lens.

You get to see not only how specific functions are operating, but how functions are collaborating with each other. And you get to see the scene is between them. And it becomes really easy to be like, oh, wow, that is a problem between sales and marketing or between sales and customer success or product and sales, whatever it might be.

Let me go fix that. But the problem is as the chief of staff, you could be responsible for proposing the solution. So in our case, writing an RFC and building the source of truth, but you will never be responsible for the ritual. And the ritual is where change happens. So as a specific example, when I first stepped into the role, 15 months ago, we had a discrepancy between the way that sales, marketing, and customer success were segmenting our users.

They all had a slightly different model. Which led to, in some cases not great customer experience. So I was like, cool, well, if I just define a customer segmentation model, they'll all use it. And while we were able to get to a shared customer segmentation model that we all agreed on because I wasn't in those seats, running those meetings and building the rituals, it was never adopted.

So it's important as chief of staff that you can observe these challenges, but you're not really the person to solve them. It needs to be solved by the respective executives or stakeholders that will build the ritual itself. And the second lesson is the idea of finding and enacting leverage. Because as a chief of staff, you are a supporting function to the executive team.

It is your job to make sure that the executive team. Is aligned on what are the most impactful decisions that we can make as a group? And how can we execute on them? So when I first started working on the operating cadence, I kind of lost sight of the purpose. And as I've done it more, I realized that the purpose is about finding leverage points.

And you do that by creating a system of observation where you can understand what's going on in different parts of the company, see where the soft spots are and really doggedly hold folks to fixing the soft spots that could have the most dramatic improvement on the company itself. And that's really what the operating cadence system is about.

It's about setting goals. So you have a context for how to measure performance, then it's tracking performance through a ritual, and then it is identifying and holding folks accountable for working on those improvement areas. So as a chief of staff, the way that you would. Find an enact leverage is probably different in different companies.

I described the way that we do it here, that might not be true for others. So those are the first principles. And then I think for things to potentially fork and remix with your own company and DNA is the exercise of the corporate reporting pack was an excellent forcing function to drive alignment companies usually go about that process through okay, ours, but because the ritual of OKR is often not followed through on and the effort to cascade them down into every individual is usually not worth the time.

If you focus just to start at least on what are the core KPIs, the company needs to track and improve to be successful as a company overall. And you build in the ritual of reviewing that as an executive team every week, a lot of good things will. Happened from that you'll get better. Executive alignment.

You'll create good constructive conflicts about like, why do we think this metric is important or that metrics not right? Because finance has a different view than sales. It forces good collisions. And then you can start to build the other parts of your operating cadence, whether that's your QPRs or an annual cycle on top of this notion of what are the most important metrics for us as a company.

So if you're looking for a place to start, that is where I would recommend starting. Are there 

Brett Berson: [01:06:53] systems and companies that you studied that sort of have most inspired your work? What are the things that you've learned from them? 

Kevin Fishner: [01:07:02] So I have done a good amount of research on other companies, the ones that are most influential on us, which is probably true for many companies are Amazon and Microsoft.

And specifically with Amazon, the writing culture is inspiring and it's not like we took any of that from Amazon, but it's good validation that it works and it can work at very, very large scale. And the second is the scorecard concept is definitely a Microsoft thing before OKR is balanced. Scorecards were the preferred process, and that is something that Microsoft is kind of the best example.

I would say overall though, the influences on this people in systems framework is more from philosophy and psychology and biology, then specifically company building. And so if you were to 

Brett Berson: [01:07:51] look at Amazon sort of famous writing culture and the way that they do short form memos, why didn't it work just to say.

We're going to move to a memo process and a memo system. And that's how we're gonna handle new projects, do ideas, product planning, initiatives, et cetera. 

Kevin Fishner: [01:08:10] So I think this is one of the most interesting aspects of systems is, and it kind of goes to your points about when do you rely on first principles and when you rely on forking, these systems are very much cultural artifacts.

This has been really apparent to me. As companies have been forced to adopt remote work over the past six, seven months, and I've joined a lot of groups and they always ask, like, what are your recommended remote practices? And the one I lead with is always writing. And I walked through a few of our RFCs and the process overall, 99% of the reaction is this is great.

It will never work at our company. And this is why I think building systems early in the company life cycle and treating your core systems with just as much gravitas as your early employees is so important. The systems build the culture from the early days, and it becomes really hard to adopt systems later in a company's life cycle.

So if we were to say like, Hey, we're done with these RFCs we're going to adopt these memos. Instead, it would take so much organizational learning to get people used to that different system where now. 80% of the employees in the company. No RFCs and probably a written on an RFC. So when a new employee comes in and is like, what the heck is this RFC thing?

You have six people on your team who can be like, oh, this is why we do it. It's really great. It's one of our preferred practices within the company. So the system is what allows people to have shared norms and even makes some of the implicit norms and implicit culture quite explicit, which makes it easier for people to adopt systems need to be organic to the company itself.

And you can take inspiration from other companies, but it's really just inspiration. You need to remix it with things that are your own and let go of the idea that you're creating new, innovative ideas, but rather you're creating new unique combinations of existing ideas for that work for the setting that you're in.

Brett Berson: [01:10:16] And you were talking about a minute ago, that philosophy and psychology has influenced a lot of the ways that you think about these internal systems. What are the things that have had the biggest impact, the things that you've read or ideas, and maybe give an example of this concept in philosophy translated to thing X, uh, 

Kevin Fishner: [01:10:35] in our company.

I think the main philosophical concept debates within philosophy of mind about does freewill exist, if not what drives our behavior. And there was one concept specifically in this debate called determinism, which is the idea that where we are today or where you are as an individual, is the result of all the causal events leading up to that.

So me sitting in my chair here in Austin is because I moved here because my girlfriend lives in Austin and I came here for her. And the reason I met her is because of my friend in college. And like, you can keep going back and back and back until the point where I'm here because I was born and I was born because of the start of the universe.

And does. That leave room for free will. At what point am I making a decision about my outcomes? And it's my belief, at least that freewill has a much smaller effect on where we are today than most people believe. I think our genetics and our environment. So our genes and memes are the things that lead us to where we are.

And I have more of a determinist worldview and it doesn't leave too much room for the notion of free will, which I think is both scary and liberating. It's scary in the sense that people don't like being out of control, but it's liberating in the sense that not everything is your success or your failure.

It can be the result of millions and billions of events that have happened outside of your control. So taking this idea and applying it to companies where there is so much talk about the people side of a company and Elon Musk has a quote that gets repeated all the time of a company is nothing more than a collection of individuals or a collection of people working towards a common mission.

And I think that loses a big part, that a company is a collection of people and it's systems. You could theoretically replace every individual in a company, and it's still the same company. And there's a cool thought experiment called a ship of thesis, which is, imagine you have a big wooden pirate ship and over a hundred years, you replace each piece of wood on the pirate ship.

At the end of that process, is it the same ship? I don't know, there's no clear answer to it, but you can think of a company. Similarly, employees could leave and new employees could come over the course of 30 years to the point where there's none of the same employees there. Is it the same company I would argue?

Yes. And it's because of the systems that are put in place and gradually refined over time, that becomes the company and companies compete based on if those systems are really strong or if they're not. 

Brett Berson: [01:13:24] Well, thank you. Thank you. Thank you. This was fantastic. Thanks for having me.