Jason Cohen Built WP Engine to 1.5 Million Customers, Then Exited

Well, thanks. I love this because so many things, whether it's podcast or writing or whatever, is about either zero to one or maybe it's like stories of what Ford did when he was building stuff, which are all interesting. But what's really rare is to talk about the scaling phase. And it makes sense that it's rare because almost no one's there, right? Few companies do scale or even need to. That's not a value judgment, like most don't need to either, right? But most don't. And then those that do, they're not there that long. Like WP Engine right now is 16 years old. Now, how much of that would you say is a high scaling phase? I'm not sure. But the point is, however old it gets, that scaling phase would have taken that five, eight, maybe you could say 10 years, probably more like seven. And that's it. So there's not many and it doesn't last long. So I guess it's not a good market. But one of the things that's great about both you and I is that we care about sort of quality over quantity, right? Like you only have a few clients, you work really well with them, etc. I only write for people that want to read like in-depth long-form stuff, not tweets. Well, that's not very many people, you know, but the ones that do appreciate if it's really thoughtful and worth their time, then they appreciate it. So it's kind of the same thing. I just prefer that. So I like talking about scale even if it's not as marketable as writing about zero to one or doing a biopic on somebody. And I agree with what you said about these different challenges that you have, of course, because in scale there's going to be challenges of process and people and organization and communication and technology. Of course, how could there not be? It's hard, but how can those not be the kinds of categories? And then the only thing I would say is I would never call it a family. But what's interesting is our employees often do. And I think that's actually ideal. The reason I wouldn't call it a family is because you don't pick who's in your family. You live with them or I guess not or something, but you don't select that. I guess you select married, but your extended family is not your choice. But when you build an organization, of course, it's your choice. You need to pick the right team. And that changes over time. And one of the hard things about scaling, I know you know, is sometimes the people that were right at first are no longer right or the company grows faster than they do or all of that. And also they're not willing to take on a role that's appropriate given that the company's scaling faster than they can sort of do from the title they used to have. So it's just good examples of like, hey, when you field the team, if you're not doing your job on the field, that doesn't mean you're just off the team. Maybe you're on a bench a little bit. Maybe we see if you can improve. Maybe there's a different position on the team where you're strong again. But what we can't have is people who are reliably in a role that they can't do and we need someone on the team to do that role. That's just not going to work. And it's not good for that person either to be struggling and failing in that role. So in that sense, there's compassion. Like you don't do your job, you're off the team. That's the Amazon way. That's the old Microsoft way. That's certainly a culture. That's fine. That's not our culture. But so it's a culture of compassion, but you can't just fail to do your job forever and that's just okay. That's a family. So if we're acting like a team in terms of holding people responsible and accountable and making sure the right people are in the right roles, all that usual stuff people say, but what they feel is that it's like a family because that's how they feel they're being treated, respected, even if people have to leave. Like how does that work? Under what circumstances? What are we doing afterwards to help them? What does that actually look like? So if everyone including the people who leave or the people who stay feel like it's a family, that means we are being compassionate and doing the right thing by humans while also realizing it's a team. So that's a long but specific way of saying why I say team and I'm glad when someone else feels it's a family in the sense that they're feeling like they're being treated well as a human. I think is what they mean by that.

Oh, you're right. So, it's amazing. And by the way, before we started shooting today, you and I had a conversation and I was talking to you about how every company inside of my portfolio at this point has used or is using WP Engine and for I would guess close to at least eight years, maybe a decade for most of the companies. And one of the things that caught my attention, it was obviously my tech guy who forced me to make the change and come over to WP Engine because we weren't, you know, we were a hardcore just plain HTML company. I mean, it's very difficult to get me to make any technical change because I don't understand it. So tech guy drives it.

You don't understand. You don't see a particular benefit like if it's the same website but it's on WordPress. I mean, who cares? It would only make sense if there was some huge benefit. And maybe there is, but yeah, the benefit is that your tech guy is now happy, which is pretty much the only benefit. And it's a big benefit because, you know, number one, he moves much faster. Number two, keeping him happy keeps me happy. Like otherwise he complains too much.

Yeah, always. Yeah.

Yeah. In fact, it's funny. We're so good at our own production for things like videos and photos and stuff that people just assume all the photos and things are actors or even clip art, but everything you see on there we did ourselves like our own employees in different places. They take the pictures and they do the stuff and those are all actually us doing whatever it is doing in our offices that we have. So it is genuine and even it's funny that it might not be obvious or maybe I guess nowadays you assume it's AI. I'm not sure, but it is in fact genuine. So hopefully that comes through, but I don't know. It's hard nowadays, but we're trying. It is genuine.

It's so funny you call it a warehouse. It is our office space. We had gotten the lease and that's what it looked like. And you're right, it looked like a complete disaster. There's like wires hanging from the ceiling. Everything's concrete, right? And it's...

Exactly. And of course, you can imagine the conversation. This is ours, you guys. Like I know it looks like a disaster. It's ours and we're going to build it out like the way we want. You know, it was pretty awesome.

We walked in there and everybody's like, 'Why? Like, what is this? This is much bigger, but this is really an upgrade.' I'm like, 'Yeah, we'll let the construction take care of it. We're not moving in today. We're moving in after it's done. Don't worry.' You know, yeah. And another funny thing is our address in that place is 504 Lavaca. And for the engineers, they're already laughing because 504 is a website error code. So really not the right number to associate with a website host.

Anyway, okay. It worked out. It worked out well.

So, on the one hand, WP Engine had the very common origin story of I had the problem, so I made it. I had a blog already on startups that was already getting on Hacker News and when I got on Hacker News it would crash because of the traffic. And when it wouldn't crash I would get so much traffic on those days that one day would be as much as all the other non-Hacker News days combined for the year. So the fact that it would crash then is pretty damn bad. That's kind of everything. It's almost like Black Friday is the day your website's down, like that's the one day you can't be down. So I would ask other bloggers, what do you do to keep WordPress up when you get a load of traffic? And the answer was always, I don't know, but if you find something, tell me because I need that. Right now, here's the difference between what I did and what a lot of people do. A lot of people assume because quote unquote I had the problem that means so do other people and there's a market and they want to pay for it and this is on their priority list now and they actually are motivated to go buy it today and you can get to them cheaply enough and then they stay a long time. In other words, all the things that are needed for it to be a business. And of course I haven't even listed them all, that's just some of the gates that have to be good enough at least if not some of them pretty good. And so just that you had it yourself actually doesn't say very much about any of the gates, not any of them. And people say, 'Well, yeah, but I'm like my customer.' Of course, you're not like your customer at all. You're quitting your day job to do this full-time and build it because you think it's better. Zero of your customers are like that. Otherwise, they wouldn't have bought it from you. They would go vibe code it or something. So you're kind of like zero of your customers, right? I mean, you can relate to them in some ways. But you know what I mean? You got to take that mindset out and say, 'Okay, that was a spark.' And sparks are very important. That gives you the idea. Awesome. Now you got to go validate whether any of this litany of things are at least vaguely true or directionally could be right or isn't a dealbreaker because they usually are. Most startups fail because one or more of those fail, you might say. And sadly they all have to work enough. It's not an or, it's an and. That's bad because any of them fail and you're done. I mean not that you can't iterate and everything but this is why it's so fragile and why it usually doesn't work. So what I did after that spark is I went and actually interviewed... I really tried to ask 50 and got 40 interviews and I used a specific method for running the interviews to try to validate or invalidate this. And I'd use that same system, which I'm of course happy to relate what it is, on a previous idea and invalidated that idea. It's like, oh, there's some neat ideas. It's not all trash. Of course, it's not. There's something good about your idea. That's why you're excited about it. They can't all be bad, but okay, I just... it's not falling into place. Whereas with WP Engine, pretty quickly, I was able to get to, okay, if it's fast and it scales, it's secure and our tech support is actually good, which is not cheap, right? And tech support about WordPress. Not just saying the server's up, that's now talk to your own tech person, but yeah, WordPress where then people would be willing to spend 10 times as much as they were spending on a shared host that they were likely on at the time. Again, we have to deliver on this stuff and it's not easy, but they're willing to pay for it. So, okay, that's often a good strategy. So with that validation, that's when I started. So that's kind of the origin is the typical kind I had it. But then there's this step which again I had another idea before that which I also was excited about. But this one made sense. So that's kind of the initial like why did I even do it?

Well, growing... I had a chart of literal just signups every day, just as someone signing up. In the early days, it's hard to track. I mean, you do track cancellations, but it often pings around. It flies around because N is so small. So, like a percentage cancellation probably makes no sense early on. But what I would say is exactly because there's so few people, every time one cancels, you can act like an FAA crash where you go like, why did that one? And try to really learn from each one since you don't have stats. And so, it's kind of the typical thing. If you don't have enough N, then you've got to be qualitative and look at each thing. Once you have N, I still think you should be qualitative and look at things because I think you learn a lot more by going in detail. But you start to get like dashboard numbers that you can look at to see like is anything really horribly structurally wrong. You start knowing that from the high level numbers. But I think you have to never stop talking to customers, find out why some cancel, all this kind of stuff. You have to never stop digging in. Even Jeff Bezos after Amazon was its size that it roughly is now would say things like most of our great insights are like something happened once or twice and someone's like what? And they went and investigated once or twice at the scale of Amazon and he's like yeah that's where the insights are. So that just tells you again, I find that even at that scale, that continues to be true. And the metrics kind of settle out as yeah, if a big metric's going sideways obviously that's something you have to act on but still doesn't tell you why. You're still going to have to go do qualitative stuff to find out why anyway. So signups every day for sure. I wasn't tracking things like ARPU very much. I mean, we had ARPU, but I didn't care that much. Because I was just trying to get customers. And gross margins are pretty important for hosting. Like for SaaS companies, you usually just assume it's going to work out, and you're probably right. I think nowadays with AI, that's not true. And so, you have to be maybe more mindful of that. But in hosting, it's not true that gross margins just work out. In fact, the shared hosts often have margins more like 40% or lower. So it's not automatic for that to be the case. So we did look at that and make sure that that made sense and also in support. So we had a lot of support metrics because that's one of our things. I always said for many companies the product is the product and support at best helps you use the product. It's good. It's a support area. It literally supports the customer. But usually it's not the best. Usually it protects the company from having to talk to customers. It's like a shield. That's usually what it is. And then especially when it is that, well, what would you do with that? Well, you wouldn't invest in it. You would want that to cost the least because it's just a shield. It needs to work, but other than working, whatever is the cheapest where it still works is fine.

It's just that our product is 10 times more expensive than usual. And part of that is this customer service, but not by the hour. We're not consultants. And by the way, we don't write code. Like for that we say you got to find a marketing agency. We don't do professional services. Don't bill by the hour. Don't write code. But you know, everything before that we will. And so what do you do if support is part of the product that they're paying premium for? Oh, you got to hire the best people. You got to invest in them. You got to have like as we scaled internal education groups that made curriculum and delivered to test to help people grow, you know, so they can come in the company and then grow and themselves make more money and be better at the company. They don't have to leave to get a promotion because we're helping them get one by getting better. We're helping that happen. These are the kinds of things which as you said kind of in the opening, isn't that incredible for a person to be invested in like that and then be able to make more money and be more capable and it's good for us the company because we hired them and then we were rapidly able to get them to be better and more capable and so that's good for us too. That's efficient, you know, if you want to put on that hat, it's like oh it's very very cost efficient and time efficient way to get good people. Yeah. But that's awesome for them. Like this is the good way. So that's the kind of attitude we'd have for something like that. But I'm kind of drawing it out from this product thing because I think when you think about your strategy, you're having to make decisions like is support something where it's the least cost or is it the reason people buy? Maybe there's other choices, but those are often like two poles of a choice that every company needs to make. Or if there's a third reasonable and very strong choice, not just both or neither, I don't know, that's not a choice, but if there's a very specific opinionated choice, okay fine. And then look at how many things flow out of that for us versus others. That's why it's a strategic choice because it's a choice that when you make it, it affects so many things across the company, whole teams and attitudes and customer promises. And if you're going to have terrible support, you better have better documentation and a product that doesn't need support. Now, all products should do that, but it becomes mandatory because there's no one else to kind of catch. So again, it just goes everywhere of what do these strategic choices mean for us. So, I know I'm kind of getting off on a tangent, but so the metrics we used, we had... that's a long way of saying we had metrics for support. I know I went on a tangent, but hopefully that's generally useful mentality.

Agreed 100%. But you don't know that unless you have good people behind support when you have the cheap people or when you have a system like an AI or a software or...

So a couple of thoughts there. One is just I'll get to the AI because that's interesting but just sticking on the humans for a second. Yeah, relationship is right. Although you get a different human every time. So I do agree with that. But one way I look at it is a brand because brand is what you feel or think when you see the company or think about the company, right? And part of that is stuff like the fonts you pick and the language that is part of it of like you're trying to form a feeling or an experience or something. You know, it's premium or it's cheap or whatever. And there's no doubt to me that support is brand. It might be the... it might be more important. Like very first impression of course is the website. Fair enough. But like the long-term one is maybe support actually. You know what happens when something goes wrong? How was I treated? If I was treated well, I really don't care what the font is. Like I now have a feeling about this company. And to your point, even if they're like, I need a refund and leave...

You're not going to track that though. Like one of the things I like to say is not every important thing is a metric. And some things that are aren't trackable. So number of people who would have left a bad review but didn't because you treated them right is a metric but not trackable. Let's just say roughly speaking isn't. And yet that doesn't mean we shouldn't try to maximize that number. You know even if we don't know if we are but we can make choices that are in that direction and just say like okay we can't. This is not one of those things where we can measure it and improve in a loop. But that doesn't mean it's not important and we shouldn't at least intend to do that. Or maybe there's a proxy metric that helps us directionally know if it's like getting better or worse and that's good enough because we can't measure it. So there's all these ways you can back into a better way to think of it. Some things like differentiation is super important and not a metric. That's okay. We can still say product wants to be differentiated. There's different ways to qualitatively talk about that. It's okay, right? I have a lot of opinions about metrics by the way. So in support, metrics are harder than I think people give it credit for. A lot of times they're like metrics are hard for software developers because you can't look at things like lines of code written because what you know and points because that's supposed to be something else. So it's like really hard to measure. Not like sales and support where it's easy. Well, I would say maybe in sales maybe, but in support it's not so easy. It looks easy, but I'm not so sure. So, for example, let's say you have a person in support. They're only doing a couple of tickets a day. It's taking them forever. There's a lot of back and forth with a customer. Customers are still unhappy half the time. So, is this a terrible support agent? I mean, by the metrics, everything I said was bad. They're cost ineffective. Customers are only... Yeah. But now what if I told you this is your best technical engineering-minded support rep and he gets the worst hardest problems and that's why it's like that. So is this a bad rep or is this actually fantastic? And the answer is well we don't know by the metrics, right? We have to know some other way. But it just goes to show how all those are the metrics we used to run support but that's not necessarily right at least on an individual basis. Maybe you could argue something about the overall team or something like this or trends like that. Maybe segments by customers that could be interesting. So it's not that it's useless. Of course it's not useless. But I think when you start taking metrics and bring it down to something like a person, they are meaningful like it's facts. Facts are useful. Facts are inputs but you got to take on board all the other context about the person about the human and the situation to understand like quote unquote is this okay or is this good or is this bad? So, another one that's interesting is CSAT or NPS or whatever the heck you use to measure that. Again, there's a lot of interesting stuff about how NPS, transactional NPS is almost for sure crap and that's not a way to measure things. There's some actually decent data about the happy face, neutral face, unhappy face thing, and that's why they do it at like Heathrow Airport. That's actually not too bad, and people kind of know what to do with that. Another interesting thing is is the customer saying the person on the other end was good to me and seemed to be competent or is the person saying here's how I feel right now was my problem resolved. These are not the same things and it's not entirely clear even if you ask it well what they're answering. So you got to be careful again of like what are you saying. Like this great engineering rep may do great work and in fact the customer might agree that the person did great work and the customer is still unhappy. That's important but are you sure you're getting that because those are different kinds of metrics. You have to be careful about things like CSAT and certainly NPS. Another thing that's interesting in support that's really hard to track is what's called the XY problem, which is customer... and you can look that up on Wikipedia, but customer comes up and says I can't... I don't know, I can't make let's say for us I can't make a new site. We're like oh let me help you out like click here. They're like oh okay thanks great bye. And then like 30 minutes later they're back. Hey, I can't, you know, whatever. Upload a file, whatever it is. And this goes on back and forth like this. Now, if you ask the customer, how satisfied were you with this interaction, let's just suppose they're super happy. Oh my god, they answered. Let's even say it's a phone. They answered the phone on the first ring. They were super nice. We resolved it quickly. Like, oh my god, your support is amazing. But the fact that they had to call back 11 times is actually quite bad. And maybe it's bad from a product perspective, but it's also not good from a support perspective. That kind of bouncing is not only inefficient for everybody, but it actually leads to customers churning. And there's data on this. There's a really neat book with data about this. I'm just now blanking on the name. I'll think of it. But it's about customer loyalty. And customer loyalty is not correlated with NPS. Let that settle in for a second. Customer loyalty is not correlated with NPS, but it is correlated with a few things. And one of them is this back and forthness as opposed to saying, 'I can't make a site.' And they're like, 'Oh, okay. Well, what are you really trying to do? I'm trying to migrate a site or whatever.' Oh, well, let me stay on the phone with you and let's do the whole thing. Now, again, support metrics might look terrible. You were on the phone for them for an hour, right? And yet by having one longer call and the customer actually got accomplished what they wanted instead of this ping ponging with good metrics quote unquote, way better and loyalty goes up which is what you really want. That's an investment. Now support is investing in LTV, dude. Right? Like listen up this is valuable growth. Not just answering the question but that requires knowing about the XY problem, valuing solving the full problem. Understanding that support metrics, what does that mean? It means the metrics are going to look different from what you might think of how many tickets per day and how satisfied.

I mean satisfied maybe, but you know, so these are all metrics and this is all part of great support and data back. So hopefully that is answering your question about support metrics. Yeah, the other thing is AI and what I would say about that is I'm a sort of AI neutralist, meaning I'm not a maximalist or I'm not against it. I feel like at any given time AI in any context because obviously AI quote unquote means a lot of things in different kind of... at any given time there's some things it's actually quite good at and impressive and good for customers and then other things where it's not. And so if we don't use AI for its good things, the customers are not getting as good service as they could. And if we overuse it, then it's bad for everyone. There's fewer jobs. We're not respecting people. Customers are getting worse things. It's actually worse for everybody. So while difficult and not maybe objective, I think the vision statement is we should be trying to use AI for what it's actually good at and not beyond that. And while of course that's going to be very difficult, that is the right mode. So, for example, in support, what's good about AI is it's 24/7 immediate and let's just call it 40 languages. So, they can chat in their own language. That is really really good for customers. A Norwegian can just come in and chat in Norwegian even though we don't know Norwegian. Dude, why is that not good for the customer? And in any time zone. On the other hand, of course, AI, one of the problems with AI is it's usually wrong. It's often wrong. It's wrong too much for a lot of these things. Well, then you can't use it like you can't be giving customers wrong stuff even efficiently. That's not acceptable. So there's one problem and then of course some AI can't do everything. So if you could say all right look there's got to be like 10 or 20 FAQs that AI can do in any language and quickly and accurately. Implementing that is good for everybody. I mean support reps don't want to tell you how to reset your password either, right? Not interesting. So how do we do that and how do we get to a human otherwise so that the customer is always having an amazing experience and it is efficient for the company and even the support reps. Oh look, their tickets per day will go down because they're not doing stupid stuff. They're really helping customers with harder things or just like you say building the relationship. When I want to reset my password, I don't know how, I don't want to build a relationship. I want to know how to do that. But when it's like, 'Oh man, help me set up my Shopify store. I have so many questions.' Then if a human being's answering, how cool is that? So now you may not agree with my exact way of looking at how to categorize these things, but that's how I would look at it. In what way is this tool genuinely better for everybody? Let's do that. Let's not not do that because we're scared. But on the other hand, if we overapply, it's bad, too. So that's my AI sort of view on everything, but in support particularly.

Yeah.

Exactly. Yeah.

Yeah. Yeah. I mean this to me is the right kind of way. So just always asking AI is brilliant at some things and still pretty bad at things like worse than a lot of people give it credit for. So how can we take the current mixture that it currently is and not talk about what it's like in 5 years because nobody knows and it doesn't really matter right now. So what, you're going to give terrible support now because maybe in 5 years it'll be better. Like that's not good. Yeah. Yeah.

And why just as strategy or other business process have to evolve right? And a lot of times people don't have a framework in mind of how to think about metrics so they don't know how to think about what metrics are the right ones. And so also I would say metrics, you should be metrics informed, not metrics driven.

And that's part of why metrics can change because if that's not what we need to know to do what we think is right, then we should get the things we need to know. And again, like we were just saying, so many things are well, it's a proxy for that or we can't. That's right. So that's okay. We there's still a metric. We just know how to think about it. So here's a framework I've used at many teams at WP Engine. People seem to like it and even teams that have never done metrics, this is a way to get them to start thinking about it because you can just have them pick one metric from this framework. That's what I would do. But we also had dozens of metrics that also across the company that fit this framework, too. So, it works kind of there. And this is in an article of mine. I think you could probably search for something like product KPI and find it. And I say that I'm not of course not here to like promote articles and also I don't have ads. I have no courses. I don't sell anything. So like it really is just out there for anybody. But anyway, so here's how I think about it. I think of this not a two by two but a two axis thing and I'm imagining a team. It could be a human but I often think about metrics as a team thing. I know you can bring it down but whatever. And so I think of the center column as the team. Okay. And then from top to bottom at the very top is stuff that's at the customer. At the very bottom is the stuff that only the team knows. So at the very very top is stuff that's actually happening at the customer and not even with us but it relates to this team. Then it's stuff that the customer, maybe activity the customer is doing on our site or in our product. Let's say it's a product team. And then like maybe just below the line it's the stuff we're doing. So that activity might be things like artifacts that they created with us, downloads, usage, right? That's the customer, right? Kind of above the line that it's still the customer doing it and the product team is like this is our product, so we need to know if they're using it. Above that would be stuff like and is the customer achieving the value they wanted or something like that, right? All right. So, just below the line is what is the team doing, stuff that the customer will see. So, this is stuff like features, bug fixes, surfacing data, documentation, right? This is all stuff the product team is going to do and the customer will see it. So it's still nudged up there by the customer but the customer is not doing it, we're doing it and it's those kind of metrics. And then as you go lower it's stuff again like the next one down I call health. So it's stuff like is our product working as promised. So this is more operational. The customer may experience this if it's not good they may not. So things like uptime, latency, scale, meantime to recovery, test coverage in the code. So like the customer can't see test coverage, but they could see bugs. Uptime they could definitely tell. I don't get all wrapped around the axle about exactly where all these go. That's not the point. The point is just conceptual. Not trying to get crazy about that. It's a little further away from them and it's operational as opposed to the product. And then all the way at the bottom is the stuff that the team knows like are we updating our security patches? Do we need to update a library?

Is there a refactoring? Like all this kind of stuff that's like maybe costs. So there's all this stuff down here that the customer definitely doesn't know about. And in fact other teams at the company, it's they don't know because it's a secret. It's not a secret. It's just they don't even care. And like how much stuff can a person know? Like we don't need to know how you patch your stuff. Like just do it, right? So it's down there. Now all this is true and all these have metrics like you might have a goal like no security patch that needs to be done is hanging around for longer than 30 days. You know that's our security policy and you have a metric of how many patches are there and how are any overdue and like you know you have all these operational metrics around that all the way up to the top. So all these are metrics remember now what's nice about this column is it's all true and it's all in the team's control. I mean, okay, what the customer does, okay, but it's the team's direct behavior that causes that they use that feature or not. If they don't use it, the team built the wrong thing, and that's the team's fault, isn't it? You know, so like this is all the team, but this is nice. This is like this is your stuff. You can't blame sales for this, you know? Like you can't, right? This is your world, which is nice because one of the things I hate about or that can be very bad about metrics is when you're responsible for some metric that you don't control or they only partially control and it's so aggravating. So one of the nice things about this column is this is your stuff and you can't say that you do control it. Isn't that nice? This is why you might want to start here because it's reasonable to say like your own uptime is something you probably should monitor because you care about your product or your latency. Say you care that your own product that you're building isn't slow and you should measure it, not someone else. And you should have your own goals and whatever you want. Like you're a self-managed team. You should have pride in your thing maybe it's fine and there's nothing to do or maybe it's not fine. You're working on it or it's fine but you're just going to watch it in case it goes bad then you're going to act otherwise you won't like that's all on you but like this is your metrics like right so this column it's easier to get there it's immediately measurable now you don't have to wait a year right so it's immediate it's the team's own and all this kind of stuff and single cause it's your fault it's the product so that's the middle column and from customer down to internal.

So then when you go left on the chart I guess that's this way whatever then you get into the metrics that feed into your team. So for product that could be things like where sales are coming from or I don't know like you know that kind of thing and even before that there could be marketing. Now that's not the team's job. The product's team the product's job is not to I don't know do marketing or something. But it's useful to know what are these metrics that come first. So like if this were say a sales team, obviously upstream metrics would be stuff like leads but lead quality and you'd have all these kind of metrics that are upstream of me. Now I know that on the one hand I don't control it. On the other hand it affects me and we're really one team. So we don't want to have like me versus you. This is one world but we have different responsibilities and that helps paint that picture accurately. So then it's like well are we closing the ones we have or what's the sales quality? Okay. So now what you're doing is starting to talk about what metrics you may need to understand what's going on so everyone knows what to improve or right if leads go down it makes sense that sales go down also these things to the left that feed in they're leading metrics if number of leads per month is decreasing number of sales per month in three months will decrease right so they're also leading in time but they're also not in the team's control so there's like this interesting it's leading it's potential it's probably multiffactor probably lots of reasons it's not in team's control and it's early So that's interesting for the team to know, right? Because it's related to them even if it's not them. And it keeps us clear as leaders especially that we're not like sort of assigning the wrong or asking the wrong questions to the wrong team or whatever. And then of course to the right there's the downstream metrics. And so immediate downstream might be things like customer satisfaction or collaboration with other teams. Like we have teams at WP Engine where they measure whether other teams at WP Engine are happy with them. Now that's a lagging metric like you know today like that's not necessarily like a today metric. It's a little lagging. Not too lagging. It could be like a couple weeks right not too lagging but it's a little lagging. It's a little multiffactor. It's not completely in the team's control but mostly you know like there's things like that. So it's a little bit lagging. Cost sometimes costs are like that. Customers overall satisfaction is like that. Okay.

Oh by the way you still have top to bottom here. So notice when I said lagging I said customer satisfaction. That's on the top and to the right because it's customers. Then there's other teams and how they feel. That's a little that's under the line. Then way at the bottom there's my costs for my team. Still lagging. So it goes to the right but it's me but like and it's the customer can't tell. So it's far away from the customer. So you still have customers on top all the way to internal as you go left and right. And then finally all the way on the right you have the corporate metrics revenue cancellations gross margin you know because of course aren't those the most important. Well yes but you can't look at one product team like we have something like 75 product teams. You can't look at one of them and say that what about our revenue you know of course they do flow into the revenue but it's such a huge multiffactor thing you can't like hold them responsible for corporate revenue.

You know, and yet they can't be ignorant about corporate revenue and their impact on it, can they? So, this to me this framework helps. It's like that's right, since it's way on the right, it's very laggy. It's multiffactor. There's many reasons for it, but you influence it. And you're not like wholly responsible for it, but you influence it. So, I'm going to hold your team accountable to the things in your column, but you've got to be trying to move the metrics to the right even though it's multiffactor laggy and we all agree on that. So, this is my I know I've gone on, but I think you like metrics. This is my way of thinking about this all these kind of typical things of like but some are leading and some are lagging and some are the customers some are not and some about me and some so in a sense it places the team in metrics context with customers with ops and with before and other teams and also the overall company metrics at the right so that we so teams because the teams if you just say hey you're responsible for revenue they're like but that's not me so this allows them to say yes I am but it's way over here so it allows people to go take a breath, understand this is all related to me, but I'm not getting confused anymore and neither is my management getting confused about like ownership and like you know and so now I can see that. So I'll go to a team and I'll say like maybe you're missing some of these even some downstream that you know we all agree without having to discuss it is not like your responsibility but you kind of need to know or hey look you have all these metrics about ops you have all this below the line metrics so you're like managing yourself pretty well you have no idea what the customers are doing with your own product maybe next quarter our goal should be yeah let's like get some usage metrics or even one usage metric in one way you pick for the full quarter, but like let's just start looking at what the customers are doing in a metrics or formal way, right? Like you could have those kind of conversations because you can see on the chart or vice versa. Y'all are incredible in design. You're doing stuff, but oh my gosh, like our we're just not paying attention to quality. We're not paying attention to security. We need to like what if we just looked at, you know, we already have a companywide policy and we're SOC 2 and whatever about security patches. Let's just make sure we're doing it. Let's just do that this quarter. Next quarter we'll pick up another one. You know, again, it can be very easy. Or one of the things I love is I like to put at the very top right so laggy as hell not in our control and customer the most is the customer getting the benefit to their company that they always wanted all along and why we're here. So like you know we make website or we host the website but I want to know does our e-commerce customer is their store growing in transactions. Now do we as the host control whether they can go get customers and set the right prices and sell? Of course not. Of course we're a piece of that because if the site's faster the data are from even Amazon and everything. If the site's faster people will buy more always. You know if the site goes down on Black Friday it's bad. We do have a role to play and we don't need to like make equations. That's not what this is about. We clearly have a role to play in that. But if ultimately that e-commerce store is not getting people to come in and buy, they're going to go out of business and churn. It won't be because our product failed. But that's what's going to happen. And anyway, why are we all here? Just to make a server go or because we want people to have e-commerce stores that succeed, right? Just on a human level, right? So, I love having that box way over there. The fact that it's way over there quote unquote keeps clear like it's not like we just can control that but we've got to keep it in mind don't we because even when you're just thinking about prioritizing features you kind of want that as a vision statement as kind of a you know in the back of your mind and I like that and are we measuring that are we measuring whether their stores are growing how cool would that be actually would you ask people whose stores are growing certain questions people whose stores aren't growing different questions if you're on the product team so you can help them better yeah what can we actually do? I'm not sure. I'm pretty sure we'd want to ask that. Well, how would we even know? Because we're measuring that thing even though it's not our control and it informs our product. So, the metrics can directly inform our product even though we don't like quote unquote control it. So, again, I'm just trying to emphasize like why this is so useful and this simple like I just have boxes. I don't even have numbers on them. There's no arrows, you know? I'm not trying to draw lines. I'm not trying to make equations. There's no rubrics. None of that crap. This is just like just putting sticky notes on a thing to help us think and talk about metrics better, looking for little gaps, looking for holes, maybe informing some stuff. That's its purpose. And so that people can sort of get behind. So I'll go to a team that doesn't do metrics. I'll be like, here's your column. Pick anything from the column. I don't care if it's customer or you. I don't care if it's the simplest, easiest thing or it's something you're just like, dude, I want to know that. Can we just do that? I want to know that. Great. Like I don't care if it has a value to the whole company. I don't care because you're just trying to get them used to metrics at all. Right? I just anything that they're excited about that they feel useful to them. Good. Then maybe they'll do it and that'll start building a habit of metrics. What's the next one? And so because I feel like if you just try to like throw a framework on people that doesn't work, they just reject it. The body rejects the organ. It doesn't work. So you have to, you know, it takes more time, but then people can get used to it and be like, yeah, yeah, actually now we're feeling bad. It's sort of like unit tests. At first you're like, what? I don't need to do that. And then after you do it, you realize like, oh my gosh, this whole file has no unit test. I feel like I'm so scared like I've got to write unit test, you know, you just kind of like, so metrics can be like that if you can get people going on it, right? And with something that's practical and not confusing or confused what the metrics should be like. So I know I went on and on, but only because I feel like you like metrics and talking about like specific frameworks and stuff and I've used this many times with success.

Yeah. So this is why I hate the phrase, don't come to me with a problem unless you have a solution. I hate that because one, it only takes one person to notice, hey, this is wrong. I'm not proud of this. This is bad. We could do better. It only takes one person to notice that. But all of us could help solve it. Are you saying that one person by themselves needs to come up with the best solution before just raising a flag? How terrible is your organization going to be as a result? Are you kidding? Like, there's problems with teams. Communication's hard. Working with people's hard, things are slower. Like there's lots of things about teams that are hard. One of the great advantages is we've got all these brains we could put on this to come up with the best solution. And you're saying that's you're going to give that up. Like why do we have this team? Like you know to get a little more done per day I guess but like you're not taking advantage of one of the main advantages of having a team because like don't come to me no please come to me with a problem when you have no idea what the solution is or if there even exists one so we can all work on it are you kidding me crazy town yeah so but you're right like it's very important as managers that every time there's something wrong with the team and that could be metrics like on the board but it could be other things this team member you know all kinds of that if we wig out about the problem like all that does is cause people to want to not surface problems or wait till they have a solution so they can look like right it should always just be like oh yeah well you know yeah that makes sense that we have that problem that's the kind of problems teams have sometimes what do you think we should do right yeah we should do this and that okay well I guess so we're doing that now yeah okay well like in two weeks like let me know or if you need more support because they might say, I don't know. Like again, we have this problem. I don't know what to do. I need help. Perfect. That should be celebrated. Celebrated when a leader even says, I got this problem with the team. I know I'm supposed to do that because I'm a VP or a director. I know this is my preview. I get it. I'm not sure what to do though. I need help. That to me should be lauded. Now, if a VP needs help with everything for 6 months, you know, like, okay, they're in the wrong seat. That's okay, right? Like, all right. But I expect there to be problems, different kinds of problems surfacing and being fixed all over the place all the time. I expect that. So if the VP says there's no problems, I know they're not doing their job or they're ignorant and bad at their job or they're lying to me. Like there's no good possibility if the VP says no problems. Now, silence like that is a major red flag, right? Anybody who doesn't have challenges.

But you still do like I just don't believe that there's no challenges and then I'm going to find out on the sideways whatever. And now I'm going to come back like did you not know this? Oh no, but I was working on it, you know, like it just this is all bad, right? So no. You've got to know. But on the other hand, when they say, okay, now I'm having a challenge here, and now I'm a challenge there, or I need help with this. I'm not sure what to do, or I can't do it by myself. I then need to say, oh, great. Yeah, let me help. Or, oh, let's see who else could help or oh man, should we put together like a little team for literally 4 days just to like together help solve this or get to a conclusion like how can I help? How can we help? Right? Because otherwise you have to meet that like I want them to say great well you have to meet that with the right attitude and the right response and now we're cooking so I call that being in command I want my teams to be in command not have no problems not be you know in command so in command doesn't mean there's no problems it means you know what they are and you're either surface everything we just said just means that right or it means it doesn't mean all the metrics are green it means you have metrics and you're like oh look see these are red these are yellow and I'm working on this one red one now and here's why we can't work on the next red one. So, as much as I hate it, you have to come back next month. And I'll go, okay, so you're in command. Not that you're in command of what's happening, it doesn't mean the product has no bugs. It means you know what they are and you're working on two of them that you have some rationale which I don't even need to know, but you have some rationale for why these are the next two. I don't even need to nitpick your rationale, but like you just you and your team decided, you thought about it. Wasn't random. That's all I need to hear. That means you're in command of what's going on. So I have a whole list of these as well about being what I mean by being in command which I wrote because as each time I would work with a new team or especially if I was on top of let's say 50 teams I need to easily say what I mean by this you know what my expectations my attitude as a manager. So I wrote up that in command. You can see that as well if you want to see that what that means to me. But that to me is the right way of saying the team has to be in control in command or that's my word in control have a lot of autonomy etc. But like what quote unquote self-managed but like obviously my job is to take a look and see like are we aligned as a whole company and are things going well? But here's to me this is the right interface to say I've got to check in. I've got to see what's going on, but like I don't want to micromanage and you don't want me to micromanage. But I got to know that you are doing it. You are in command, you know, like and so to me this is my interface where I feel it's healthy where I'm doing just enough. I have just the right expectations, right? And just right amount of communication and the team is maximum autonomy given that we're in a big company that we are working together, you know. So to me this is my way or my intention anyway. So listen metrics too many things and metrics are one of them.

Yeah, for sure. I mean, obviously deciding what to do is the most important thing for the reasons you gave. I don't know if you know this, but I spend one day every week, and I've been doing this for the last 15 years, helping other entrepreneurs to grow. And I'm not talking about companies that I own or the companies that I invest in. Every year, I work with 28 other companies using the same strategies that we use to grow companies inside of my personal portfolio. They grow their revenue, they grow their brand exposure, they grow their team. Some of them come because they want to sell for a big exit. Some of them want to buy other companies. All of which could happen for the ones who qualify and get into this program with me and it's called Club 28. Now, if that sounds like something you feel like you're fit for, then the way it would look is that you and I would work together closely. And that could mean me opening up relationships that I've built. It could be showing you the frameworks that we currently use, or it might just mean you tapping into the experience that I've accumulated over the past 30 years of growing companies. But this is limited because like I said before, I only do this one day a week because every other day I'm working with the companies and the teams that are inside of my portfolio. And it's not cheap because it's one-on-one with me. But if you could handle more growth and you want help from somebody who knows what it's like behind eight and nine figure brands and how to get there smoothly, then I encourage you to apply for the next opening. Just go to chrisgrero.com and apply to be part of club 28. I'll try to put a link inside of the description here, but if not, then just go to my website and apply to be part of club 28. And if you get in, I really look forward to meeting you.

So, I have a system for this, too, as you can imagine. I've been doing it for a long time. So, you know, and remember what I said at the top, too. I don't believe that every framework just automatically works for everyone. I don't believe that. And I also don't believe if you just make a team do a framework that it'll work. It usually doesn't. It just happens that they like it. So, I'm not saying, oh, I know how to do everything right. Just do everything I say. It'll work. It worked for us, therefore it'll work for you. I'm saying none of those things. All I can do is relate what did work for us in case that helps. You could take some, you know, you could try it on for size and maybe change 30% so it works right for you or just reject it of course all together. Another thing I find is like even just saying here's why this will never work here is useful because it helps point the way to well then what might you know like it actually can help that. So anyway, with that sort of attitude, I'll pretend like I'm a genius and all this stuff will work everywhere rhetorically, but just no, that's not how I actually what I actually believe. So this is a system that we honed over time. So like we did this every quarter with one and then two and then three and then more teams quarter by quarter and continue to sort of meta hone the system like hey how could the system be better with all those teams? So this is a pretty I don't want to say streamlined but like for us and our culture this worked really well. So this not coming out of GPT or something. In fact we did this before there was that. So anyway the inspiration I had for the original thing here was there was let's see the I think Biden yes Biden had just won the presidency and hadn't taken office yet. And the Free Software Foundation was like, hey, these are the things we think the Biden administration should pay attention to in tech. So, there were certain things about crypto and there were certain things about copyright law. There were certain, you know, they had like these certain issues that they cared about and it was written so well and I remember reading this thing like why is this so good? Like I have to understand why because these topics were really far-ranging and yet they would summarize the puzzle in like one paragraph. They would summarize what they think should be done in one paragraph. They may have one or two little action points they believe and somehow they distill these very complex topics so easily I mean it was surely hard for them but I mean in the document so easy to understand you were like oh yeah oh that's good yeah that's a good example oh I see why you're saying we should do that yeah that seems very reasonable to me oh that's something we could do now or a metric we could look at or something well how did they do this so well because that's what I want for my teams and even me like me myself I'm not this clear. Our teams are not this clear. And if you can do this with something as complicated as free speech, you know, talk about a complicated, right? Then surely we can do it for you know the admin screen on this portal like you know like what are you talking about? Of course we can so what the hell's going on? So that was my motivation. So that turned into this the first version of this framework. Of course, I'm just gonna skip to the end because you don't want to see iterations, but it was that so the reason I'm saying all that I mean the history of it kind of would be boring except the lesson I learned from the history of it was so often we're like it's complex so we can't say it in one paragraph and I'm just like no you're wrong it's complex and you don't understand it well enough to know which things are important so you don't know how to put it in a paragraph that's what's going on it's a warning sign that like it's time to analyze it so that you can or decide it's okay that you don't know for now. That's okay. But like no, it's not that it's impossible. That's cope. That's not the right answer. Right. Anyway, so okay. So here's what we do. This was again a team exercise. I as you can tell I constantly think it's better to go a little more slowly but involve the whole team because then at the end of it the whole team is completely aligned and bought in. So, of course, you could just decide what the team priority is and tell them and I guess they'd have to do it. But if you take an extra week or two, like what happened with this is the first time it took us like four to six weeks because it was so hard to get our stuff together. Like there's so much stuff that hadn't been done yet. But the team loved it. They're like, oh my gosh, this is so fun. We're getting our strategy together. We're figuring out what's important. Like, this is so neat. It then got to be it would take like one to two weeks tops to do the whole thing and part-time. I mean, this is not one or two weeks, I just mean of wall clock time of part work and it was just like bam because the team was so used to it right so the first thing is okay what are the objectives for this team by so like what are we trying to do guiding questions would be things like what's happening right now with the team what do we want to have happen what happens if we don't get it and here's my favorite question here because those are sort of generic questions I admit If we weren't encumbered by roadblocks, no distractions, no other team interrupted us, no manager came in with a thing, there were no security patches to do, there was no nothing like that happened, how would we best advance the strategy of the company and so do you have a strategy of the company? If not, that's another problem. But okay, if we know like here's generally our strategy, here's our goals for the year, blah blah blah. If we weren't encumbered by anything, how would we do it? Notice I didn't say estimate amount of time or any of that stuff That's not the question. Just what would this team do that would be strategic? Never mind your maintenance operations. I know that half or even 70% of your time has to be your own stuff and maintenance. I know that we're not doing capacity planning. Okay. I'm asking you how could you be incredibly strategic for the company. That's a fun question. Unless you don't have a strategy, then it's a confusing one. But then everyone's going to be confused, aren't they? And misalign because like I don't know how are they supposed to know and how are they supposed to be an independent team if they don't know which way we're going.

So if that's the case, by the way, and you're a team, what you do is you just take your best guess at what you think would be strategic. Now, obviously that's not very good, but what else are you going to do? Like you need to manage your own team and be in command, don't you? So you have to like push upwards. Hey, you guys need a strategy and meanwhile where you're at, you got to say, all right, what is our Okay, so anyway, that's the question. How do we be strategic? So then you say, okay, next one is obstacles. It could be just one by the way. Maybe you have a couple, but it could be just one thing like because it's right now. It could be like, well, in general there's 14 things, but today it's this or something like that, right? Okay, but then obstacles stand in our path of doing that. Like, okay, we just said if you weren't encumbered by then this is how we'd be strategic. Well, obviously if we could of course we should be strategic and do that thing. Of course, like that's right. But of stuff or it's hard, it's slow. It's hard. We can't like just various obstacles. So, what's standing in the way of what we just said we would do? What makes it difficult to achieve that or what prevents it altogether? Well, we get interrupted by this. Oh, you know, well, this part of the code's not refactored, so like doing anything there's so scary. We can't, and if we do, it takes forever. Or yeah, I'd love to, but marketing said needed this and like the CEO came in and said, well, we have to do this for marketing even though it has nothing to do with us. And actually, we're happy to do it to be honest. Like it's actually really cool work and we agree it's really valuable. So like well it's not about our objectives as a team per se. So in that sense it's an obstacle to what we you know it's actually like we don't mind so it's an obstacle to the objective. It could be good it could be bad like there's various obstacles. So again there we need to figure out like well which of these are like really crucial. I mean there's many but like which of these are you're going to surface. Okay. So this is what we would do but here's what's standing in our way. So now we're going to decide what we're going to do. Now we're going to decide the actions. So the question is how do we overcome these obstacles while advancing the objectives with the people and capabilities and strengths that we currently have because it's what we're nearing now.

So again like we're so the whole point is to do the strategic thing. So like how do we do that anyway now? But if this obstacle is in our way, we need to also work on eliminating the obstacle. Of course, now you're not going to eliminate every obstacle and do every that's not going to happen. Well, this is where the team is discussing and making judgment calls that involve what do we think we can do? What is our capacity? What are our actual humans that we could actually put to work this month or quarter? That's going to determine some of these things we can do. So, for example, we could say, yeah, we have this we're supposed to grow. We honestly don't know how. Like our obstacle is we literally don't know how. So we don't know what to do. Like there's no action. But how do we overcome that? Yeah, you're right. What we need is a chunk of work to figure out how that could mean product work. This maybe not even engineers or maybe it is engineers because we need to try something or we need external I mean who knows what it is but it's like a chunk of work that we're talking about this quarter that we're planning this quarter which is oh my god the biggest obstacle to us being strategic is something we don't know how to solve that's the actual so solving the meta thing is actually the act then we'll find out what we're actually doing you know on the other hand sometimes we do have a good idea and of course we should do it so how do we reduce these obstacles so that we're doing the damn strategic thing we just said now once again are there background stuff we need to do the metrics below that fold like I say right like we need to work on that yeah of course so there's going to be some of that now how do you allocate your time that's going to be based on the team there's some teams that are moving fast and innovative in which case they should be doing almost no maintenance there's other teams who may be working on mature areas of the codebase where it is more important to maintain high quality than it is to have new features or it's under some governance or compliance. Fine. That then for that team, this is why it's per team for that team. They're like, oh yeah. So we're only going to do this one thing, but we're going to do it really well and you know, I don't know, whatever. Right? So how do we both change the like because if next quarter we have the same obstacles, isn't that terrible? Because then we'll never get to the strategy. We just said it's stopping us from being strategic. We'll never be strategic, but okay. So, we have to move the obstacles. We have to try to do some of that strategy. Or you could say, it's going to be so hard to move this obstacle. We can't work on the strategy. But you know what? We're going to destroy it. So, let me take a quarter to completely take out this tumor. And the next quarter, we're not going to have that tumor and we're going to be strategic as hell. Okay, that's a plan. Now, we're back to good again, right? You're back to in command. So, sometime, so again, so contextual, so I don't want to say quote unquote, it depends. I'm giving examples of good things that sound good to me because it sounds like the team analyzed this and had a reason. That's what I'm looking for. So, I'm giving examples of what those could be, right? Another one is, yeah, there's some obstacles, but you know what? Screw it. We're just going to like plow through and get back to that next quarter because we really want to ship this thing this quarter. So, we're writing down those obstacles. We're saying, I know, I see that. I'm choosing not to fix it because it's not too bad and I think we can just press and get this strategic thing done before our annual customer event. After the customer event, we're going to come back to the obstacles. Maybe we're going to switch up a little, right? We're going to just fix the bugs in the things we just shipped and actually work on some of these obstacles then next quarter. That sounds again that sounds pretty good to me. So there could be many things that are reasonable and has to do with capacity and so on. It's not unusual for a team to realize our obstacles are so overwhelming. We literally should do nothing but fix them for like six months and just the rest of the companies just have to know. We're not shipping anything except bug fixes. But we're going to come out the other end like screaming. So, Amazon did this, right? They famously said, oh my god, the code's too interconnected, so we've all ground to a halt anyway. And so everyone's going to stop. No features are allowed. We're going to turn everything into API only and API first. And they took months and months and months. I think it might have been nine months. I forget what it is. Then they emerge the other side as they are now modular and API driven. And now you look at the cloud and you're like, oh yeah, I can see that. So again like this isn't just me saying this. This is it could be that that's the right thing to do even in a hyperscaled thing like Amazon. After all, if you're scaling really fast, it means people like the product the way it is. It might make sense to pause new features or at least some teams do blah blah blah blah in order to get really healthy and really unblocked and doing strategic things next that could be smart. Okay so actions then there's measures which is what the one you like how will we know that these actions are working how will we know the obstacles are going away how will we know you know this goes back to my chart of course in my case but okay and then another one I like if we're thinking strategically because on a quarterly level we should be thinking somewhat how will our company be different after this it's nice little question about measuring things okay and then finally I have a section what are we not doing. This is important because everyone else looks at the thing including other people on the team and outside the team. But what about this? Well, we've been complaining about this for when they see that the team puts it in the not doing the team. That's the team saying I heard you. We processed it. What this means is we felt the things above here were more urgent or important or something or other where that's blocked. There's maybe you give reasons, maybe you don't, but okay, we thought about it. It's not we didn't forget. We didn't not listen to you. If you want to chat with the team, we can say why. Or maybe you want to put why in the doc. If you want a big old doc, you can say why in the doc. That's nice. But if it's just bullet points, that's cool. They can ask you, but they can see right away. The conversation isn't, dude, you didn't listen to me. The conversation is why did you not choose to do mine? See, very different conversation. Oh, yeah. Because we need Simon to work on that. Simon's already doing this and that and we just can't this quarter, right? Or something like that, right? So, that's the full thing. What's the objective, the strategic objective that we really would do, but we can't or we're significantly hampered because obstacles. So, here's what we're doing to reduce the obstacles, get some of that done anyway, or not. Maybe like whatever kind of thing you decided. Here's how we'll know that measures. Here's what we're not doing, which may be pulled in the next quarter, may not. That's okay. I like that as a sort of high-level team level backlog that is ordered. Not fully ordered like number 17, number 18. I mean, come on, who cares? But maybe the top three to five and the bottom 10, like, you know, maybe that level of ordering as a backlog. That's nice. It's just communicating a little bit. And you're totally allowed to just completely change your mind on that at any time, right? That's not a commitment. That's just kind of writing stuff down.

I so we make one of these every quarter. Okay. And that's why I keep saying quarter. It's a quarterly process. And again the first time it's like what yeah what is the strategy for this team or how does this team do? How are we doing? And it takes a long time but a lot of times the team is like yeah what is our like we have this mission statement we wrote three years ago. It didn't even mean anything then you know like maybe it's time to be specific about what the hell we do and what we you know. So that's good though. That's like that's good cleaning up your house stuff, right? So the first time probably takes a little bit then they're just not used to doing this and so on. There's a lot of argument about what they are and what's important. But then what happens is like the third time that they're just like okay well you know what a third of the stuff from last time we're still doing so that's just going to come over. The obstacles you know some of these haven't even changed our objective certainly hasn't changed like how we contribute to the I mean we should ask quickly did it change but probably the answer is no and that's a one

Minute conversation, but like you said, you need to ask every time. Yeah. Cool. Ask, you know, but probably not, because it's a slow-moving sort of a thing typically. And then yeah, there's a couple of actions from last time we just got to pull over, but we have time for two more. That's what we're going to discuss.

And just you're so used to it, right? The metrics. We already have them. Maybe you add one, maybe not. But even if so, you're just used to it. You're like, 'Yeah, we're going to need one more metric. So just throw that in action as we're going to add this one metric.' So this quarter we won't know what it should be because we're not measuring it. So this time the goal is just to have it. Next quarter we'll have some kind of goal or whatever. Be that simple, right? Like, I mean, in the document, I mean, doing it is not simple, but the document can be that simple. And it should be just because otherwise it's hard to consume. And so yeah, like every quarter, but it's quick now. I say quarter.

It's not. I do think that every 90 or 100 days or so, there's a certain rhythm, human rhythm that happens. And the way I like to say it is if you do have a remote team and you bring them all together and you have like this amazing week, it's all social. You realize like, oh my god, this is what we're missing being remote. And that's right. That doesn't mean you shouldn't be remote. Maybe it does, but maybe it just means you need to get together. But how often? I think if you watch your own team interactions over Zoom and Slack or whatever, like the next week, it's so cool. Like you still have it like 100%. And then it degrades somehow. I don't even know what the curve looks like. I don't know how exactly long, but in my experience, just very, very, very roughly, I would say like 90, 100 days is when you sort of lost it all and it's time to recharge the batteries. So, does that mean you should get together three times a year, four times a year to try to keep that going? Yeah, that's what I think and that's kind of why this is all gut feel, right? I don't have data or anything. I'm just, you know, that's how I feel. In that same sense, but it's how you feel after, you know, over a decade of doing it.

Yeah. And but it's also personal. Like maybe some people like in three weeks they're like, 'I got to, I feel so alone,' you know. So I realize it's personal, but that's just my personal feeling with that same attitude. I just think this 90 or 100 days is a certain kind of a time frame where certain kinds of things sort of run out. So if you did what I just said every month or every sprint, that would obviously be ridiculous, right? But if you only did it once a year, I just do feel like, you know, four months in, you sort of run out of like, are we still on track? You know, do we need it?

So, I say quarterly, but what I really mean is I feel like there's this 100-day period where you probably want to check back in even if it's quick, right? In fact, some teams did that. They would have like, we're going to have a two-hour meeting for this because since we've done it a few times, if everyone comes prepared and we generally agree, it will only take us two hours to be fully aligned in the next three months. If we don't fully agree, we'll find out, we'll get everything we do agree on done, and we'll find out what the things are where we do need to spend some more time. It could be two hours a quarter to make sure you're on track and change course. It's just everyone's kind of seeing it because you're talking all the time, right? It's not like you're never like you. So you can see how efficient this can be. I do not think you should be spending weeks and weeks every time, right? It's crazy. Anyway, so that's how I feel. And so because I feel it's about the time frame and not the calendar quarter, the fiscal quarter. I actually don't like planning around the fiscal quarter unless the team really does have a tie to the fiscal quarter. Finance teams have a tie to the fiscal quarter. So it makes sense for finance teams to be planning around the fiscal quarter. That's logical. For sales teams, for the same reason probably so, because the finance teams, right? It's like tied that way. But that's not how support works. There's nothing about the financial year that has anything to do with support or product, but other things do.

So what I like is for teams to pick a rhythm. I call it an organic or natural rhythm that whatever makes sense for them is the right rhythm. For example, on a product team, what are you shipping in December? Like brand new stuff, nothing, because no one's seeing, you know, you're not doing that. Well, what a good time then to work on your plan for the next year instead of shipping stuff, you know, right? So a product team may want to say, 'Oh, we're going to do our quarterly plan. We're going to do a quarterly planning in December anytime.' So that in January when we come back we're like bam we already know what we're doing and we may even get all the way through April with that, like all the way through spring break and a little bit of April because you know conference season or something. Because we can just be heads down and plow. But then at the end of April, right before the kids are about to be out of school and everyone gets distracted, we're going to do another, quote unquote, quarterly, because that was four months, another planning meeting that's going to get us through summer. Because here's the thing, when September hits, our sales spike because people are, because like Europe's back and Americans are back from vacation. And so we've got to have stuff shipped by August so that in September the sales people are crushing it. So this is going to be our May to August plan. For the whole point is to ship some stuff. And but that's why, see, I had reasons. Now my reasons may not be your reasons, but you see what I mean. I'm finding things that are real, the flows of people's energy, of other teams, of when we sell, right? I'm finding signposts around the year that are real and then I'm combining that with about 100 days. It could be four months though. It could be two, three, right? I'm trying to combine that to find like a couple of humps. So maybe it's three, maybe it's four. I don't want six months to pass though, right? Two months is probably too fast. I'm just wasting time with too much planning. That's no good. So this, yes, it's an art. Okay, fine. But you see, I'm trying to get reality signposts in from the year and then this kind of like 100-day rough thing I made up. I have no data to back it up, you know, and just like that should be our planning style. And now again, it feels good. It's like, yeah, yeah, yeah, because we're planning in a rhythm that feels good with a rationale that feels useful and right. Now it's not just like it's the beginning of the quarter, time to plan. It's like I'm in the middle of this, like, right? Doesn't that feel artificial? And yet doing nothing is obviously bad. So that's my way of trying to be organic with the team, right? Trying to like respect reality, you know, but not just say never plan and you know, so that's my whole thing.

Yeah.

Wait, wait. Okay. Wait. Say those. Say those. Which ones? Sale better. Wait, which ones again?