Jason Cohen is the founder of the renowned WordPress hosting company WP Engine. His background in building and scaling successful businesses means he’s not only a serial entrepreneur but also an investor and startup mentor. His journey as a founder includes various undertakings — including co-founding Smart Bear Software — which makes him an expert in growing businesses and organizations.
Jason Cohen is the founder of the renowned WordPress hosting company WP Engine. His background in building and scaling successful businesses means he’s not only a serial entrepreneur but also an investor and startup mentor. His journey as a founder includes various undertakings — including co-founding Smart Bear Software — which makes him an expert in growing businesses and organizations.
This episode is a deep dive into the art of scaling. It explores various topics: the mindset required as a founder, challenges, exhilarating moments, and the struggles along the way. Jason shares invaluable insights and lessons learned through his entrepreneurial journey, shedding light on what it takes to navigate the complexities of scaling a business.
Prepare for a conversation that is enlightening, inspiring, and packed with actionable advice for anyone looking to skyrocket their business.
-----
Thanks to Jason for joining us and providing such valuable advice about the art of scaling a business. Join us next week with Freemius founder and CEO Vova Feldman to learn about mastering the art of mastering software pricing pages.
plugin.fm is brought to you by Freemius, your all-in-one payments, subscriptions, and taxes platform for selling software, plugins, themes, and SaaS. If you enjoyed this episode, head over to plugin.fm to check out previous episodes.
Jason: Small companies like to make fun of big companies for wanting to be predictable and having processes and being, quote unquote, wasteful. In order to buy predictability, I have too many servers, I have too many people, I have all these processes about processes.
Patrick: Today, I'm excited to welcome Jason Cohen, a serial entrepreneur and the founder of the renowned WP Engine.
Jason: I don't have to do any of that. I'm better. Well, you are better 'cause you're not doing all that kind of administrative extra stuff, and in other senses, you're unpredictable.
Patrick: We're going to dive deep into the art of scaling.
Jason: If you've hit product-market fit, sales and marketing isn't the challenge anymore, in which case the challenges of scale are things like, "Is the infrastructure okay?" Often it's in support, you're crushed even though everyone in the company's helping, and then hiring people.
Patrick: We'll explore the mindset required for the founder.
Jason: In code and infrastructure, it's been for decades a mantra in computer science that premature optimization is bad. I'll be prepared for scale and do all kinds of work it takes a lot longer to do, and by the way, when you scale something else will break that you didn't think of because that's how premature optimization works in code generally.
Patrick: The challenges faced and, of course, the moments of struggle along the way. What are the scaling mistakes you've made and how would you prevent those or fix those?
Jason: We tried to both scale the infrastructure and continue to add features, and that was wrong. If you're going to double the number of support tickets in the next 6 months, either you have to prioritize reducing tickets in the software, or you have to hire people at a certain rate. You have to start hiring right this second and a lot.
Patrick: Jason, welcome and thanks for joining us.
Jason: Thank you, that's a great bio, but it also means I'm old if I've done all those things which are true or convert some of that into something useful.
Patrick: Yes, it's wisdom. It's accumulated wisdom. You're like a level 38 fighter or something, yeah.
Jason: It might be, we'll see.
Patrick: All right, well, let's try that. Let's jump into it. So a lot of the people that I've talked with on the show and at events, a lot of their businesses start with a personal problem. "Hey, I was trying to connect software X to software Y, I couldn't do it, so I built an integration or I customized the code to do this thing," or it's like a hobby project. How do you take something that you built for your own purposes and decide even if it's worth scaling and how to scale that and make it a bigger business?
Jason: Yeah, I mean this is how I think a lot of companies start. I had the problem, so I built it with the assumption that other people have the problem and they'll pay me for it, which is almost never true. Now, on the one hand, that's a good place to begin because it is a problem and you had it and you maybe have even some emotional attachment to it or some excitement about it. You certainly have some experience solving it now that you've done it, so that's a good kernel, that's a good spark. But there's so many other hurdles that you have to go through in order for it to be a business, meaning something that makes money. And not even, I mean yes, definitely even at scale, then there's even more hurdles because of the numbers that have to be involved. But even just something where you're going to replace your current salary and have a one-person shop, even that, it's actually quite hard to do, and most people who try it fail, which shows how hard it is because it's not like they're all dumb or something or that they didn't have an itch to scratch, they did. And so there's these hurdles, such as: are there enough other people who do have the problem? And even for a small company, the number has to be a lot because you have to get in front of them, and most of them will never click any link that you have, and most of those will bounce off the homepage, and most of those, and so on, and so you actually need quite a lot at the top of the funnel, a lot, in other words, a lot of people who have the problem even just to get, let's say, 100 customers or over time a thousand customers. So is there enough people that have the problem? And then, do they know that they have the problem? Because they have it and they don't know or don't care, they're not searching and they're not buying. Do they have a budget for it? That's a big question. Maybe a free tool, yes, and with a but, and if it costs money, then no. You often see a 100 to one or a thousand to one drop off between free and money. So again, there's a big issue there. Is it one of their top priorities that they're trying to solve? So in other words, here's this problem a marketing department would have, right? But if it's their seventh priority, they're not buying that and they're not working on that, they're working on whatever the top one to three are.
So it also has to be something important enough, and then why you and not a competitor? And I like going into markets where there's lots of competition because it proves the market exists. That's nice. A lot of times the market doesn't exist. Well, there's a lot of people already making money, people spending money. It answers a lot of the questions I just said: there must be a lot of people, they must have a budget, they must know because here they are. So what nice thing about a big market is the answers to a lot of those questions is yes, yes, great. But then there's a lot of competition. Oh no. So there's another challenge of like why me, how will I get attention in that, you know, in the noise of everybody else? What will I have that's at least special or somewhat different? Does have to be completely unique, but what is my thing and for whom, for which subset of the market am I the best thing? It clearly can't be everyone in the market, "I'm the best thing." There's no product is that. So what is that? So again, all this stuff super important for whether thing is a business and will make money and can operate in a market that is valid, and none of that is proven by the fact that you had a problem and you solved it. So again, good spark, good idea, a place to begin, but all that other stuff that you have to validate and figure out and sort of iterate for, and you may never find it, that's what's necessary to build a company.
Patrick: I'm always inspired when I go to a tech conference, and sometimes I'm so inspired that I will, on the airplane back from the tech conference, I will write a little bit of code. I'll work on a thing that's just exciting to me. Is there still a case for just building it and launching it and see what happens? Or versus like, you know, thinking about the market and how big is the market, do people really, how where is this problem on their list of priorities, you know? Are there some businesses where you'd say just build it and then if it doesn't market, then you have your answer? And are there some businesses where it's like just do, you know, do two months of research to figure out X, Y, and Z before going forward? Is there?
Jason: Don't do too much research because you don't have any data, and you can't do the research. I'm saying do an afternoon of research. Okay, after that, then that's just silly, that's just you not wanting to know the truth. If you want to know all those numbers I just said, you only need to know it to a power of 10, and you won't know because the data typically doesn't exist. So if you can't, powers of 10 to get it to the nearest power 10 is actually almost always easy. So like, how much will they pay per month for this? I don't know, right? But like $10, $100, $1000, which one? Right, that's usually pretty easy, like, "Oh well, if I'm targeting a small business that has a reasonable need then more like 10 to 100 and not a thousand, okay, so call it 50 and move on with the analysis." And you can do that for all these steps that we were just talking about. There's 5 billion people on the planet, so if every single person could be a user, which is not true of anything except for, you know, Netflix or something like that, then there's a billion people that can use it, but it's probably less. If it's businesses, you probably know how many businesses are in your vertical to within a power of 10. Like, "I sold to dentist's offices in America." Okay, well there's not a thousand of them, and there's not a million of them, there's probably 100 thousand of them. I just know that, I didn't even look anything up, but if you looked up any statistics whatsoever, even roughly, you would at least find out roughly what the power of 10 is. So this is what I mean, you can do that, you can be accurate within a power of 10, you can do it in an afternoon, and find out, and at 2 a power of 10, which is not very precise, but what happens is you can end up seeing like, "Oh my gosh, when I multiply all that together and look at it, it would be hard even to make a hundred grand a year." Yeah, or it would be easy it seems to make a million dollars a year if I'm right about this stuff. Oh, that sounds good. So you won't do even that level of analysis. So it just doesn't make any sense at all, is something that you can do. Should you build it and launch it? Well, you said build it in a month, if you can build it in a month and have a real product that people would pay for, that does sound pretty good. I still think you want to do that, take an afternoon to make sure it's viable or plausible, you might say, not viable, but plausible. But then, yeah, I would build it in a month. That's not what people normally do though, and often what you build in a month is not that useful or it's horrible, it has too many bugs. So either you can build that fast, in which case, do it, or it'll take six months before it's reasonable and you feel good charging for it, in which case, that's too long to just sit there and build and never talk to anybody. So then, yeah, you got to call potential customers and ask them about it. Well, how do you call potential customers? It's hard, it's hard to get people on the phone, it's hard to get their attention, yeah, I know, but once you have the product, it's also hard to get, it's equally hard to get them to look at it. So you have to solve that problem regardless, you might as well solve it first, and then actually talk to people and validate some or invalidate some of your hypothesis about what their life is like, what their workflows are like, what they think is important, what language they use, and by the way, what websites do they go to, who do they trust for this kind of stuff, what do they compare it with? Like there's all kinds of quiet things you can find out before you write any code that either gives you more confidence or less confidence in your idea and also tunes all those various parameters so that when you are ready to go out with a real product, like you're way, way better on the right track. And if you can't get people to talk to you at all, again, I would question whether what you have is actually something people want or are interested in. And then you learn that final thing is you said building a Munch and launch, I'm a big anti-proponent of launching, I think it's fine, like you want to do product hunt and do it, that's fine, and of course, you see the people who get to number one or even two on a given day and it's pretty cool, so you're like, "I want that," and of course, that's not what's going to happen to you, you know, 98% of the time, that's not what happens.
So you spend all this effort on launch and you're working worried about it and you have things and you launch and like four people vote for it on Product Hunt and the launch is not helpful and you spend a lot of time and energy and now you're sad for no reason, you know, for no constructive purpose. And anyway, even if the launch is pretty good and you let's say you get 10 customers, 20 customers, where that is nice. I mean, that I'll take that, you know, that's good for the next three years. You're going to have to get customers in some other way than Product Hunt, right? So get to it already. Why don't you start on that part where it's reviews or it's guest things or it's advertisement or it's whatever the hell it is? Why don't you get on that since that's what you're going to have to do for years to build a sustainable company? Again, even if the goal is it's just going to be me and that's great, you still need to do that. So get on with it and as opposed to screwing around with a launch. So there's actually, of course, you've seen really successful launches and really, if there's reason to believe the launch is going to be amazing then I guess that's an exception, but geez, that's almost none of us.
Patrick: My personal belief is customer acquisition is typically the hardest part of business. Is that probably the biggest stumbling block you see with people scaling their businesses is customer acquisition and keeping customer acquisition costs low?
Jason: Well, getting started, it definitely is for the reason you gave at the very beginning because everyone makes a product and then can't sell it. So obviously the marketing and sales is the hard part and the thing that stops most of the companies from succeeding. So it is. Does it stop you from scaling is kind of a funny question if you're already scaling, if you've hit product-market fit and whoa all of a sudden like you're going down the roller coaster and it's going and you almost don't even know why it's happening and just keeping up with the orders is all you can do, which is what product-market fit looks like and feels like if that's what's happening. In a sense, sales and marketing isn't the challenge anymore. Like you may be growing faster than you know what to do with already, in which case the challenge of scale are things like, is the infrastructure okay? Okay, yes, marketing, sales, but more of the scaling part like how do I add sales or how do I manage these marketing campaigns that are getting big? Often it's in support, you're crushed even though everyone in the company's helping, you're crushed and so what do you do about that? And then hiring in people, which is a really hard part of scale and not something you can just snap your fingers and solve. And even if you have all of the best practices and stuff, it's still really hard and it'll be bad for a while because that's how it is, there's no like magic shortcut. So in hiring processes and in people onboarding and then learning stuff and you have no materials because of course you didn't need any and you have no processes because you didn't need them and now, now all of a sudden you're behind. So that's hard to scale.
So sales and marketing, once you hit product-market fit and you're starting to scale, may not be the problem. Now, after you get past this initial hump of right after product-market fit where that happens, let's say a year or two on, you've started to get those things in place so that just hiring people, just these basics of scale, they're not necessarily completely solved but like they're sort of part of how you operate now. Then sales and marketing can in fact come back and be a challenge because probably you've exhausted those initial channels. I don't want to say they were easy, that's kind of the wrong word, but let's say now they're run-of-the-mill for you, etc., but you're doing everything you can. If it's AdWords, you're in all the keywords, you're optimized, you know you have good ads, sure, you're going to continue to optimize, maybe test and like find the keyword. Like it's not that you're going to stop, and maybe you can continue to improve a little, but it's not like you're going to 2X it, or certainly not 10X it, but probably not even 2X it from here because you're sort of plumbing it already. And if you do, it if you are able to 2X, that's because you put a whole lot of effort or expertise or something into it because it's not obvious how to do that there. And then more likely, there might be more channels you need to add or something else that needs to happen, and that's hard and risky because it's not obvious that all channels will work at all. It's certainly not true that all channels will be equally cost-effective, and that's something you'll be figuring out in tuning, and just what are they and what makes sense for you and your customers, what if you sort of run out of the good channels and then what? So it can, once your scaling pace is established with the channels you have and you're breathing a sigh of relief that now you're kind of in the middle of this scaling thing, yeah, then it can come back as like, "Oh, okay, I need to go from one channel that works to multiple. Oh, that's actually a new and different and hard challenge, it's not obvious what's going to work."
You could maybe say the same thing with the software. Okay, now that we're past the infrastructure part and etc., what features do we add? I used to have a very focused small persona, but now at this size, I can think about multiple personas or expanding that, going to something adjacent, and maybe I even need to in order to continue growing or keeping up an accelerated pace of growth if that's your goal. It may not be, by the way, it could be that you want to get to some level of scale and say, "That's fine, I don't want to expand, I want to be profitable as possible rather than growing as fast as possible." So it also depends on your goals, what you're trying to do here, just to be clear. But if your goal is to continue growing and scaling, okay, then there's new challenges that appear.
Patrick: Let me ask you about challenges and scaling, and I think sometimes we use the word scaling as "I'm going to scale my business," and I feel like scaling happens to you. It's like, you know, assuming you have product-market fit, like let's assume you have product-market fit, you're solving a problem that people are willing to pay money for, but I feel like scaling happens to you, like your business will grow until it hits some sort of...
Jason: Carrying capacity is what they call it.
Patrick: Like you don't scale your business, you unblock your business from being, and it maybe sales and marketing is a problem, maybe people, maybe support, maybe infrastructure. I guess sometimes I think the way people talk about scaling is it's an active thing you do, and it feels like it's actually paying attention to where your business is getting stuck, the biggest roadblock for your business, and then removing that roadblock. Is that the right mindset?
Jason: Well, it is at the very beginning of scale when you turn that corner where you hit product-market fit and it goes from every customer is a hard scrabble and everything's really hard and nothing's really working to like, oh my gosh, now it's working. At that moment, yeah, you're in your own way, agreed. Now again, then you get to a point and when, oh, it just depends on the business, depends on all kinds of things, right? But you get to a point where okay, you've unblocked that and now that is at its limit of what it does and if you want to continue scaling, you do have to do it and it's really hard and a very different kind of difficulty than going from nothing to something or going from something to product-market fit or even the early scale, it's different again to that. Again, I think your goals matter. If you're like, "I want a company I love that is not too big where it's profitable rather than maximizing revenue, I want to maximize profit in absolute dollars," then you may not want to take that next scaling journey. You might want to say, "No, this is good, let's optimize this and let's ride it out as long as it goes," which can be fantastic, of course. On the other hand, if the goal is to maximize revenue, then you can't sit back and you absolutely hit a carrying capacity limit, kind of an S-curve thing where it levels off. What one reason is what we said: the marketing channels saturate, whatever you're in that probably happens pretty fast actually. It's just that it's adding enough in absolute numbers that you're fine. But then you get to a scale where those very same absolute numbers are now not that big, right? And so like nothing's changed with the marketing channel perhaps but at this size, that's just not that interesting and that effective anymore. So if your goal is to maximize revenue, then that's not enough. You have to somehow add more in absolute dollars per month there. The other thing that happens in a recurring revenue business is cancellations catch up with you, right? So early on, you don't have any customers so cancellation, even if it's fairly high, may not affect your growth curve that much. But once you have some mass, whatever the cancellation is becomes large in absolute number. So even if it's a nice low number like 3% or 2% per month, that once you have size, that's a real number and since the marketing channel's not getting bigger automatically but your cancellations are getting bigger automatically every month, even if it's very good just as a percentage, if the percentage is steady then the number that is is growing every month and so it catches up and again slows you down to zero growth. And so you can look at a lot of the companies that are successful smaller companies that show their data and I got a blog post where I show some of these graphs from these companies but things like Buffer, for example, right? They grew and then leveled off and never grew again ever like for years and years ever, ever because cancellations caught up and that was that. Marketing never got better and but cancellations grew until growth was zero and then it's it does stay there as a steady state. Same thing happened with SparkToro. There's a lot of examples but there's a couple companies like that where they publish their data so it's especially, you know, especially easy to see it. So this is a very real phenomenon. One answer to that is making cancellations less. A lot of these small companies, the cancellations are bad like 5% or even 7% per month, that's just devastating. So one answer is go solve that and then that will increase that limit. It doesn't solve it completely but it raises it plus there's an even better reason to do that than financially which is if people are canceling, it's because they don't want the product, yeah, that's the reason you should solve it. At least they don't want it at that price or versus a competitor, etc., etc., whatever your value proposition isn't working out.
At the worst case, you promise something in your marketing and sales and the promise was great so here they are but then you didn't fulfill it or it was fulfilled only temporarily or again there could be lots of reasons but when we, another, they're like no even though I was here for the promise I'm no longer here for it and they leave. That's the reason the financial thing is true but it's like a side, it's not a side effect but a knock-on effect, a post-effect. The real issue is the customer doesn't want the product anymore and that should make you feel bad regardless of the finances or your goals with the company 'cause you should want people to want your product like that, that's kind of the idea, right? So that's why you need to hit on retention really always but especially if as a higher priority if it's high and that will also help with the growth but there's always a carrying capacity somewhere even with the best cancellation rate, world-class cancellation rate and so again you need the marketing channels. There's also new products so there could be different tiers of the existing product that people could end up upgrading to and that's growth. There's also new products sometimes in adjacent markets or especially Indie developers like to have a portfolio of random products. These are other ways to increase growth besides more marketing and sales so there, there's different ways. I think you need to really be saturating your target market before you go off and make new products but more like brand new products but uh tiers and features within the current product that's just logical. It'll increase the average revenue of the new person who signs up but also existing people might upgrade and that all can combat the cancellation effect.
Patrick: I was hoping to find some subtle but important signals in this chat with Jason but he made it clear that usually when you need to scale it's glaringly obvious and in his experience there are two things that are highly likely to fail if you're in the process of scaling. We'll cover those in a minute. Let me ask then about are there signs or are there things that people should be paying attention to that make it obvious that some scaling is either needed or possible?
Jason: Again you will, you cannot miss it because you'll be crushed when you turn the corner. You can't keep up with the support tickets, the infrastructure you're on is simply failing, and so forth like the code's failing, like there's just no doubt about it, like you almost don't have a choice but to face it, that's how you know you have to invest in scaling, meaning processes and people and maybe in terms of the code certain kinds of quality and so forth. That's a great answer. Let me ask a better question: What are things you can pay attention to before things start failing? Just because your CSAT drops doesn't mean you have to scale. If your CSAT dropped because the volume of tickets is so high that you can't keep up with it, then that's a scale question, although even the question is, do you need to hire people or does the software need to change so that or the onboarding process, etc., so that it's not generating so many tickets, and so on, like you do need to diagnose what's happening and act accordingly but scale may or may not be the reason for it, you always have to go to the reason. In terms of I don't think you I think it's premature optimization to do things before scale is there. Now in code and infrastructure, there's a little bit of a balance and an art to this because you don't want to just do dumb things and then scale happens you're like, oh it broke, what a surprise. On the other hand, there is definitely such a thing as over-engineering it, oh I'm be prepared for scale and you do all kinds of work it takes a lot longer to do and by the way when you scale something else will break that you didn't think of because that's how premature optimization works in code generally right like same thing with optimizing a function you're like oh I'll rewrite this Loop but that's not the loop actually it's this other thing it's very hard to know so it's it's been for decades and decades a mantra within computer science that premature optimization is bad because you don't actually know where it is and scale is an example of that so but again it is an art because there is like but yeah wouldn't I you I mean shouldn't I use best practices like I'm going to use something like a cloud for formation or some kind of automation for infrastructure so that when I need to change the infrastructure I can do it in some sort of meaningful way yeah of course you should do that rather than scripts or just manually if I decide to use some sort of serverless Cloud thing that auto scales at least some component is autoscaled is that not better yeah that is like that's better.
So yeah, it's a little bit of an art, a little harder to give hard rules about like what is it that's premature optimization versus what is just best practices that you should do, okay it's a little it's a little tough to draw the line clearly but the fact is you'll scale and then something will break and it's okay, like that's if you, the company wouldn't have gotten to this point where it needed to scale if you would spend extra months, you know, premature optimizing things that are probably the wrong things anyway so same thing with support, you supposed to do like hire 10 extra people that are not doing anything? No, so but then what if you grow really fast like right so what this points out is this once you're in the scaling Zone predictability starts to become important and this is why because if you're going to double this number of support tickets in the next six months and then something has to happen right now like either you have to prioritize reducing tickets in the software or you have to hire people at a certain rate and you're going to have to start hiring them now for six months from now because you have to find them and then interview them and then pick some and then it takes them two to four weeks to leave then they're here and then they don't know anything and then they're doing it by osmosis and by the way they're slowing other people down while they learn by osmosis because who else is going to teach him because you don't have materials yet and so it easily takes six months before some between now and someone's here and very productive and support.
So if you know you're going to double support in six months you have to start hiring right this second and a lot, hiring a lot of people right now, which itself is a process, right? So predictability, asking like is that true or do we need 50% more in six sem what do we need because we need to do that now suddenly predictability becomes important early on it wasn't you were trying to figure out what the hell's going on not predicting any in fact you can't predict anything so that's not the thing once you get to scale all of a sudden predictability matters that's an example of why it matters and of course small companies like to make fun of big companies for wanting to be predictable and having processes and and even in a certain sense being quote unquote wasteful in certain ways in order to buy predictability I have too many servers I have too many people I have all these processes about processes like hiring in order to have predictable hiring at a predictable rate and then you know at a smaller company you're like what a huge waste of time and people and I don't have to do any of that I'm better well in a sense you are better because you're not doing all that kind of administrative extra stuff in other sense you're unpredictable and that's fine if you're small and don't need to be totally fine no problem not a judgment you know but if you're scaling you must suddenly it becomes this really important factor of predictability and so oh I got to need projections and figure things out and modeling all of a sudden the stuff matters because you get into this trap where either you've got way too many people in say support or way too few and either one's a problem one's a worse problem you know one hurts customers more than the other but okay they're both problems that you don't want to get too far on the either side of but that requires some kind of predictability not like a five-year plan but you can't see six months ahead or nine months ahead like you're you're in trouble but when you go from this pre-product Market fit unpredictable Zone to the Zone where suddenly it needs to be it's going to suck and that's why but that's okay like that's sort of the problem you're supposed to have and saying like I'm going to invest a lot of time and money and process ahead of it that's wrong you don't you you don't have the time and attention and money to do that and you probably don't really know what to do anyway because it's not predictable anyway and so it's not even clear that whatever you're doing would will help so I feel like it's a transition and a quote problem that you have to go through.
Patrick: The only way past it is through it, right? It's like you just have to go through the hard parts and just accept that there's going to be some failures, some things that go wrong, because that's what you had to do to get to this point, and now you can go ahead and make fix those things and make them better. Yeah, I take that now.
Jason: The good news is that that fact is predictable, like this pattern is predictable. So if that's good because inside the company, it can feel like, "Wow, management doesn't know what they're doing because we're all screwed," as opposed to, "This is what supposed to happen and here's what we're going to do about it," right? Yeah, the code's supposed to do that. What we're going to do about it is only work on infrastructure stuff until it's stable, even if it takes us a year and we don't add any features. And if you get all worried that we're not adding features, just remember, "Why do we need to add features when we're growing so fast from new customers that we can't keep up?" So we're going to, you know, right? Or we're going to only fix bugs or usability issues that reduce support tickets because that's scale and infrastruct, you know, until you, okay, and so on. Or on the support side again, like here's, here's the plan for that, here's what's going on, blah, blah, blah. Yeah, so you can know this and you can make decisions and prioritize things accordingly. Not doing that is bad because you are thrashing around, right? But when you're keeping your priority straight, which is always important at any stage because you never have enough time, attention, so you always have to prioritize well anyway, when you're in this, this sort of early scaling phase, the priorities should be pretty should be clear like that and predictable and that and then it doesn't look like management is flailing, it just says, like, "Yep, that's this is exactly what's supposed to happen, here's the kinds of things we need to be doing, here's our current priorities, we're doing it."
Patrick: When teams are small, it's easy to bend and break the rules, but once you get to a certain size, someone is always getting married, having a baby, or having a death in the family. You have to build your business in a new way, in a way that makes it so no one employee is essential. We're going to dig into these bulk of humanity problems in a few minutes. Quick question, so I think I was introduced to WPengine in 2013 at WordCamp Chicago. How big was WP Engine at that time? Just ballpark, you know.
Jason: 10 people? 100 people?
Patrick: Okay, so a little before that, what, like what are the challenges? And I think a lot of the people who listen to this podcast are, let's say, at a team size of five or less. What are like the biggest scaling challenges between, let's say, five and 20, or five and 100? Like, what are those early scaling and actually, sorry, what are the challenges that you experienced with WP Engine? Let's talk about some specifics, if that's okay.
Jason: Yeah, so first of all, everything we just said, so cross-supply that in, but now let's talk about different things, right? So one thing that changes is the organization as a layer, sometimes too, and that's a lot more different than it may sound like it is. So, in other words, even if you've gotten to 20, then you've experienced the first major organizational shift, which is sure there's a CEO and a this and a that, but it's a big difference when you get to 10 to 15 people and that first manager appears, a person whose job is to manage people, not necessarily the founder where yeah they're still managing people but it doesn't really feel like that, you know? Now there's a person and they manage you and stuff just changes at that moment. It's harder to communicate everywhere even though you know all doing the same stuff, it's just not the same. There's a lot of like, "Oh, for that, go to your manager, you don't go to the CEO for everything," you know? And a manager is a different role, a different kind of person, and no one else was that kind of person. It's a new kind of person, hopefully a culture fit, but culture is a whole separate set of criteria which usually isn't too much in stone yet at that point but nevertheless it's different kind of person just like when salesperson shows up they need to be a company culture fit but their often their personality and everything is different from anyone else who's been at the company before, it's just different. So in that same vein, when you add another layer or two, there's a similar kind of a shift in like, who is that, what does that mean, what does it mean in terms of communication and work and visibility.
The CEO is used to seeing everything. Now, the CEO does not see everything. CEOs are not talking to everybody all the time, doesn't see everything. What do they see? Well, they see the hardest, worst problems because everything else gets solved ahead of time, so that's already kind of hard but appropriate. Also, they see whatever people who report to them want to tell them. That's a mixed bag. You need some kind of filtering to survive and be able to think and not, you know, have every detail, and yet that's not the full picture. So just even what do you do about that and so forth becomes a challenge. Who are you hiring for that? For example, at WP Engine, our biggest single department was support, might still be. So that's got extra layers of management stuff versus other departments. If you have two people in finance and 50 people in support, obviously finance needs one leader and support needs more than one. You know, like, duh. Also, in support, you start getting into stuff like if it's 24/7, then you have three shift different shift leads and you start to have a lot of people and administration and stuff to just manage the fact that that's happening, right? And so especially with that, okay, there's people who aren't awake when the CEO's awake. You really aren't seeing what's going on, you know, and so on. Okay, so it doesn't have to be a time shift like that, it just emphasizes this idea that there's things that are more hidden or less obvious. There's plenty of stuff you can do. I know someone who, up into about 200 people at the company, would have a one-on-one with every single person at the company twice a year, and he called it Fireside Chat. He would go into office, he would put a picture of a fireplace on his monitor, and then he would move his chair away from the behind the desk so that they were like just kind of next to each other more so it felt more like, you know, we're just chatting and there's the fireplace, and he would take it took like one to two months of the year worth of time because, you know, scheduling and after and stuff, right, yeah, but it was a way for him to keep track of what the hell's going on, like really know what's going on, hopefully, really. I mean, even then, are you getting the truth when someone, especially people, you know, employee number 100, are they telling the CEO they feel comfortable telling the CEO anything, ratting on someone else, you know, really, you know? Maybe not. Maybe with enough prompting, who knows? But it's better than not having it at all. Obviously, it doesn't scale forever, but you can, you know, there's things to do. There's obviously all hands, like once a week you bring everyone together and talk about stuff, good and bad stuff. That's important. There's surveys you can do, of course. Those can be stupid and valueless, but they can also be deep and really good, especially if there's a lot of fill-in-the-blank stuff. That can be good. Anonymous things can be good also, again, can have its own problems. So, you know, all these, you know, the whole the Blind Men and the Elephant where there's like eight people and one holds the tail and says it's a snake and one holds the one's touching the leg and says it's a tree and it's an elephant and everyone has a piece of the picture. They're not wrong that they're they have a piece of the picture but the elephant is some kind of synthesis of what they're seeing. So as a CEO, that's what it feels like at the company. So there's all these things you can do, adding these touchpoints, none of which are the truth, the full truth, but all of which are part of the truth. And so that's really hard. But see, that's all different. Everything I just said that's not true when there's 10 people. You still need to talk to people. There's still a little bit of that, right? But like nothing like when there's multiple layers of stuff and like now and trying to talk to everyone now becomes impossible or hard just is too many people to just do that and too many things. So it's just not practical anymore. So also again, the type of people who are now this VP of support who's over 50 people, it is a different kind of person than like I hired that first support person and they're a great leader and great at support and people just want to naturally follow them, right? But that doesn't mean they can hire and fire and manage a team of teams of support people and man you know all that kind of stuff.
Another thing that starts happening, and I would say when I'm about to say is, uh, really kicks in around maybe 100, maybe like it's really obvious at like 200 to 400, but you start seeing it even at like 50 to 100, is just the bulk of humanity starts to become a thing in itself, and I'll explain. At like two to 400 people, all the things that happen to humans rarely are happening all of the time because there's so many people. Like, so even the rare things times a lot of people, that means they're common. So there's always someone getting married, there's always someone getting a divorce, there's always someone having a new baby, there's always someone with a close death in the family. There are employees who commit suicide, there are employees who do other things, there's events that happen at work that where someone gets fired. So whether they're good things or someone's moving, so there could be, you know, how they say like there's good stress like getting married and there's bad stress like a death and but it's all stress in a certain other sense and like on your system. So in that sort of a sense, there's that kind of high emotional content with as the more people you have, that's happening all the time to somebody. And so it's like having to be managed all of the time just the human, like forget process and forget, you know, professional stuff and skills, forget all that, just the humans. But you're still small enough that everybody knows, right? Like at Google, that's happening, but you know, you don't hear about it. It's just like, you know, there's too many people. But you're a small company with 100 people in it. If anyone has a baby, everybody knows that, everyone sees the pictures in Slack, everyone knows that they're out for the next, you know, six months on leave or whatever. If someone has a close death, it's like, "Oh, man, okay, well, got it. They're going to be off for a few days, whatever," and so forth. If there's an event at the office, that's going to be a rumor for two weeks. So I don't think as humans, we're prepared to deal with those things happening all the time. It's a lot, you know? It's just kind of, oh my God, like every time it's like, okay, yeah, there's another, you know, right? Even if it's good, it's just like, okay, you know, just, it's a lot to deal with emotionally, and everyone has it. It's kind of this odd extra thing. So that's something that's not necessarily obvious, although in hindsight, maybe it's clear that's hard to deal with in scaling, and so it's another human thing that happens that we haven't talked about yet, you know, in these other aspects.
Patrick: I believe it's important to decide what your business does and what you value as the founder. Jason has a great guideline about when you need to have these values written down so they can be passed along to all of the new employees. Stay tuned and we'll get into that in just a few minutes.You're basically saying that your staff, your team, your company will always be going through someone will be having a high and someone will be having a low and there's all these life stresses. How does that relate to the founder, the CEO? Do you need to have space for those things? What does that mean on a more practical level or is it about regulating your own emotions and your own humanness?
Jason: Right, so first of all, on the team level, because if the team is in trouble then as any manager, executive, founder, you know, you're worried or diving in on the team level. Another one of the things like predictability and in fact related to predictability is stability, meaning even when something happens, like "The Show Goes On". Again, early on, we ain't got no time for that, you know. So sometimes like co-founders break up early and that's the end of the company because, you know, we don't have any stability, we don't have any safety net, right? That's okay at as you're scaling this becomes one of the things that you have to address. It's not okay anymore when you have 100 people that if one person leaves the company or has a thing or blah blah blah, whether it's good or bad and then like some important part of the company ceases to work, that's just not okay anymore. It makes it less predictable but it also, it's just too hard to manage, right? So all of a sudden there can't be anything where only one person knows it or does it, it has to be a team and so on and so forth. And wait, but doesn't that mean some things will be done worse or slowly or require more coordination or be dependent on stuff? Yes, it means all those things, in other words, it looks less efficient because it is in one sense, but what you're buying with that so-called inefficiency is stability and also that's part of where predictability comes from is that if it's stable then we kind of know what's going on because we've invested in that. So it does cost money and time to do that but at scale, that's worth it whereas before it's not worth it. So that's one thing is you have to build these stable teams that can handle changes. There's always some change that's so big that it rips the team up and okay but like, you know, reasonable change like one person, something happens, like that can't destroy the team so you have to be working to that. If you have then these things aren't quite as impactful of course and so that's part of how you manage it literally.
Okay, so that's on the team level. As a Founder, yeah, or really any executive CEO and not a founder and this is still true or this or maybe the chief operating officer who has most of the company underneath them, you know, like any human being that has many human beings there or again in the case of a smaller company that's kind of anyone in the company could feel this way. Yeah, like managing that is a personal thing. I do think people are different this way so it's hard to give blanket advice for some people being more aloof helps they're just like well I can't be personally engaged in all this stuff other people can be and can compartmentalize it some people can be you know sort of by naming it putting it in a box they can sort of be aware and not let it affect them so much.
I think if you're really sort of naturally empathic and you feel all this all the time, that's going to be a problem and you're gonna have to have some way that that, again, will be personal and like how do I not throw away this great power which is to care about others feel what other people feel understand them because that's probably a great power that makes you very strong in certain ways it's probably great in terms of building teams building a great culture probably engendering loyalty understanding customers understanding employees it's probably a great superpower in many ways and you don't want to just like cut it out. On the other hand, if it's crushing you just if normal life crushes you for it because there's so many people that's obviously a hindrance that you have that you need to deal with. That is true. Hopefully you've also at scale you've gotten managers and Executives who can carry the burden as well. It's a big difference with like there's this manager but like every bad thing just flies up to me as opposed to there's a manager and like something happens and they're like just so you know this person's going through a thing we got it don't worry about it but just so you're aware and maybe like if something happens with them or you see something don't like maybe immediately respond or jump down their throat or what just you know because knowing something's going on like maybe don't do that. And but I got it you don't have to do anything I've got it that should be what the conversation feels like that they're surfacing it to you in the first place you have to find out some other way and that they've got it maybe they give you some instruction about how to act and you're like okay and that helps you be aloof and stay away from that while being aware being ignorant is not good but let someone else share the burden that is another correct way and that scales that actually scales to whatever right.
Patrick: Awesome, I think what I want to ask you here is I think what are the biggest scaling mistakes you've made that's like what are the things that you would do different if you were starting a new venture today what are the scaling mistakes you've made and how would you prevent those or fix those?
Jason: So at WP Engine, when we hit our big growth spurt, which was in 2012, we did hire quickly in support, so that was good, but we tried to both scale the infrastructure and continue to add features, and that was wrong. We should have either done what I suggested in this call, which is to only think about scale, both of service and of infrastructure, which means, you know, make this stuff solid and make changes that reduce support tickets in the first place, and we should have done that to the exclusion really of anything else, to not only to stay more ahead of it because we stayed fairly ahead of it most of the time, but really because of the focus, because really focusing the whole company only on the scale issue, that would have helped, and I think we would have gone further in certain ways or certain projects would have continued rather than starting and stopping and that sort of thing, and that kind of focus would have been better. Maybe we would have hired differently, that's hard to say in retrospect, but if we knew that we were going to focus on this for a year or more, you might have hired people that were more specialized in that or at least had a, let's say, a cultural attitude for it, right, and so forth, so I think we would have organized ourselves differently with that kind of focus. That would have been better rather than feeling like we have to do both or raise more money and in fact do both, but only because you hired enough that you have the bandwidth. So, like, if you really can have dozens of people working on scale and a couple dozen people working on innovation, product innovation, then, okay, right, like, if you really can have enough bandwidth for each thing, then that's fine, but if you don't, then don't try to do both. So either one of those, I think, would have been a better choice in retrospect.
Patrick: Sorry, how big is WP Engine these days? About 1200 people, that's what I thought. Okay, so can you give us a highlight of like what is one scaling thing you've seen once you get to about a thousand plus?
Jason: Well, certainly, people don't fit in a building, like any building, so even just getting together becomes sort of impossible, especially with things like 24/7 support, and running the functions of the company, and that kind of fracturing is really hard. And you can have videos, and you can do things, and you can trade off, and we do, but it's different than being able to actually have everyone in the retreat, like all seven of us are doing the thing, you know, like it's different. We're global, of course, a lot of companies are global, even with three people, but that is hard. And I think people don't appreciate the time zone differences, and especially with distributed teams, there are a lot of advantages to being distributed, so I'm not against it.
On the other hand, there's a certain social aspect and human aspect that you absolutely lose, and even the people who are the most into distributed things like Automatic and Buffer and these companies where, from the beginning, they were distributed in their bones, get GitHub. They insist that people get together periodically throughout the year to renew those social bonds. So, like, I don't think it's controversial or even in question that while distributed work is good, it is not a substitute for being together, and you have to do that sometimes. And yet, I find a lot of companies don't. When they're small, they just don't bother. When they're larger, they don't spend the money or time and invest to do that three, four times a year for a whole week. That ends up being a month, like a month out of the year worth of time is just being together, not even being effective, efficient. You'll, like, you'll work on some strategy thing or whatever is useful to do when you're together because obviously around a whiteboard is better for certain kinds of things, so you do those things, you know when you're together. But mostly it's the social stuff, and to allocate a 12th of your entire work time for that sounds like a lot. It's like, right, it's not that you rep- I mean, is it better than commuting every day, which also takes, you know, like hours out of a day? You could see it either way. You could say no, it's not actually. We should take that penalty in drips every day and have that best experience together, or you could say, yeah, it is better because every day is better. Like, if we're all together, that's more fun. And if we're not, the rest of the days, if we're not commuting and so forth, that's better for our work and our life and so forth. You could say, no, this is better. So that's fine. Like, I'm all for it, but you better do it. And there's a lot of companies that don't get together or not often enough, and that is, I think, that is bad. So I would say if you're in that 20-person phase, you know, like that's a critical thing. But if you're at the thousand-person face, it's really hard to still do that. And how do you- how do you get everyone to do it? You have to decide to do it. Different kinds of teams may want different sorts of things. It just becomes really hard to manage that. And yet, with a thousand people, you're- you're going to be distributed somehow, even if you're in the same city. You can't be in the same, you know, building, so it's still kind of a thing. I think if I'm at the 20-person stage and thinking about what's important, I would say you're at the moment where you have to decide what your culture is and encode that in words. And then actually employ it. Up until that point, you may or may not have stuff written down, but you probably don't even know what it is yet. It's not really till you're in the trenches and you're doing stuff that you start figuring out what it is. You may have a couple of things in your mind like I- we're designers, so design's important. Like, so you may know some things, but there's other things you may not know till you're in the thick of it. And so early on, when you're like encoding it in words and there's only two of you, it's kind of awkward, probably stupid, and what are you going to do with it? Twenty people, though, and as you continue to hire, you have a culture, and the only question is do you decide what it is? And if you haven't written it down, then that means you're not using it in interviews, you're not using it to weed out people, and once they're there, you're not using it for performance management and getting rid of people. And you're certainly not doing it consistently, and people don't know how to do it consistently because it's not written down. They don't know how to bring it into every important decision and make sure that it's compatible with that. In other words, it's not being used. It's not being used as a criteria or for making decisions, and that means it's not real. And so, with 20 people or more, there's no other way to get everyone to be aligned on something than to have it be crisp and written down and so forth. There's just no way. It will be everyone's got the exactly the right things and the same things in their brains and then are using it all the time. It just can't be. And so it's vital that the culture be encoded. So maybe that's something we can do in a future one is like okay, how do I figure out what that is, how do I encode it, how do I then use it? What happens as you scale? How do you keep that up? Like these, that's another hour of stuff. Yeah, but I would say at five, even five, maybe it's too early. Certainly at 20, though, it's time to like, boy, if we don't do it now, we won't have one. Or at least we won't have decided what it is.
Patrick: Love that, thank you for giving us very detailed answers, which is awesome. Yes, I just want to say thank you for A, for coming on the podcast, and B, for going a few minutes over. I really appreciate when people are flexible with that, so thank you.
Jason: Thank you, it was great stuff.
Patrick: And listeners, thank you for listening to this podcast. We hope you found insights and experiences truly valuable. If you enjoyed this episode, we would greatly appreciate it if you could take a moment to like and subscribe to the podcast. By doing so, you'll stay updated with the latest episodes where we bring you the insights, knowledge, and experiences of the leading entrepreneurial voices in the software product marketing world. Also, don't forget to visit our website, plugin.fm, and hit the subscribe button for early bird access. If you found this episode particularly inspiring, we encourage you to share it on all of your social media accounts. By spreading the word, you'll help fellow entrepreneurs on their journeys too. If you're facing challenges in growing your software revenue, we have a special opportunity for you. Reach out to contact@freemius.com to get free advice from Freemius monetization experts. Once again, a big thank you to our wonderful guest, Jason Cohen, and all of our listeners. My name is Patrick Rauland . It has been a pleasure bringing you another episode of plugin.fm. Stay tuned for more inspiring conversations and incredible stories from the world of software product marketing.