Scale Without Scaling

[00:00:00] Rachael Lewis-Krisky: Welcome to ‘Making Work Work,’ the DigitalOcean Podcast, where we explore everything about work - the tech that makes it possible and the people that make it happen. And of course, that’s never as simple as it sounds. I’m your host, Rachael Lewis-Krisky.

Businesses are always looking to expand their footprint or increase their revenue, and of course, to do it all with what they already have, but that requires a deep consideration of their infrastructure and data to hopefully do more with less. On this episode of Making Work Work, I’m speaking to Sam Eaton from Roblox and Crave Cookie, along with our own DigitalOcean Chief Product Officer, Gabe Monroy, about what scaling your business really means. Let’s dive in.

Gabe and Sam, thank you for joining me on ‘Making Work Work.’

[00:01:18] Gabe Monroy: Wonderful to be here.

[00:01:19] Sam Eaton: Yeah. Awesome to be here. I am pumped.

[00:01:21] Rachael Lewis-Krisky: Good. You should be. I wonder if you could each introduce yourselves for our listeners and sort of summarize the experience that informs your perspectives on scaling products, infrastructure, and businesses. Each of you have sort of differing backgrounds that make you uniquely positioned, I think, to talk about that.

So, Gabe, would you like to go first?

[00:01:38] Gabe Monroy: Yeah, sure. Uh, I’m the Chief Product Officer here at Digital Ocean. I look after the product management, uh, design, as well as the customer facing engineering teams. Uh, so you leave it as like, Anything we do to build a customer facing product, uh, here at Digital Ocean. Prior to that though, uh, I worked for five years at Microsoft where I, I was the vice president of the Azure Developer Experience Group, So I was responsible for all the developer services in Azure Kubernetes services, serverless, API management.

I was also responsible for internal systems, uh, inside of Azure too. Uh, but what was interesting. Before that I actually came from, the world of startups. I got to Microsoft because they acquired a company of mine called Deis. and so prior to Microsoft, I actually didn’t have experience working at a company that size.

And so, I’ve had some interesting experiences running the gamut of like really large hyperscaler infrastructure, um, as well as building at startup scale. Uh, and you know, at DigitalOcean. It’s uh, somewhere in between.

[00:02:32] Rachael Lewis-Krisky: And Sam, how about yourself?

[00:02:33] Sam Eaton: yeah, I started at a company called Qualtrics. I was the, uh, founding growth engineer on the team there. and I’ve been at some other startups. One of 'em was in government tech, got acquired and things. And then, uh a few years ago I, I built a, uh, cookie company with my sister called Crave Cookie.

Um, and I’m not working on that full time. Currently I am on. Avatar marketplace team at Roblox. It’s where I put most of my time, but I am, uh, yeah, I’m putting, still putting time into Crave and, the next work that I’m putting towards Crave is really towards like e-commerce and, getting cookies National.

[00:03:02] Rachael Lewis-Krisky: We actually have a great customer story feature on Crave Cookies, which you can find on this episode’s webpage. Um, so it seems that in both of your backgrounds you both had experience with engineering mindsets versus product mindsets. Though I know you both sort of prefer the engineering side of things.

Um, how does growing a business distinguish the times when it’s best to sort of wear that resourceful technical hat or in other cases, a high level leadership hat that lets you see the big picture or even how do you combine.

[00:03:29] Sam Eaton: Hmm. I, I think, uh, this is why I liked hearing that Gabe was an engineer, uh, before he went into product because, I don’t feel like there’s a, solid line between them. , it’s like if you were to talk to someone who I don’t know, Gives dogs, baths, , like they’re, they’re a dog groomer. if, if they’ve been doing that for enough time, when they talk about it, they’re gonna almost sound technical in their, in, in their processes that they, they have for, what they do.

And so I really feel like, the engineering hat really is just that you have enough, subject matter expertise. And that just kind of informs the way you do it. it’s kind of like the how, whereas the product is like the what and who. and I guess more importantly, the why.

It’s like the problem you’re solving, but then the engineering is just kind of informing that. So if you can be both engineering going into product that’s like the.

[00:04:13] Gabe Monroy: Yeah. No, Sam, I think that, I think you said the magic words, right? The delineation between the what, , the why, the how, uh, where engineers are, are focused on the how, My background is, as you mentioned, I started as an engineer and when I got to Microsoft, they stamped product manager on my head and sent me off into, into the dungeons there at Microsoft.

Uh, but I was, you know, an engineer by trade, you know, Right. Row codes still do. And really understanding that how, right? Like how do you build systems? How do you scale systems, um, how do you engineer an application? How do you build digital products? The more time I’ve spent in my career, The more I’ve had an affinity for the what and the why, because I’ve had a number of experiences in my career where, I got super obsessed with the how overly obsessed with the how and put a ton of work in, or more importantly, my team put a ton of work in.

And then at the end of the day, it turned out that the what and the why weren’t clear or worse were off in terms of what the customer expectation was and having a pivot engineering teams. In a different direction is something that was super painful. And I’ve lived many of those. In fact, I gave a talk at Saster, just a little while ago, out in your area, uh, Sam, where I talked about, you know, vitamins versus painkillers and lessons I’ve learned in, , product development.

I’ve really try and avoid those pivots now. And so, you know, I spend a lot more time trying to de-risk the product development and, and the engineering side by really understanding the what and why.

[00:05:43] Sam Eaton: Right. Yeah, I think that, I think that Vitamin painkiller example is really good because it, especially for scaling like a big enterprise, it’s less like, how do we get people to take more of, which it’s like, maybe we just need to put out more pharmacies next to these people, and sometimes you just need to like, put things near the users I’m kind of being, uh, abstract,

[00:06:00] Gabe Monroy: Yeah, no, I, I think I get what you’re saying, right? The best engineers, they approach the how very creatively, right? Sometimes the how isn’t writing code. Sometimes the how is talking to you, a user, you know, early on or, or, or building some lightweight process in order to, you know, capture something.

I think the best engineers really understand that not everything is building in the traditional sense. I think the failure mode is when folks get so, wrapped up in cool new technology and they really enjoy the art and the science of software development in particular. The work of writing code and, and engineering software outweighs what’s actually needed for, for end customers.

Right. And, and I think that’s something I’ve lived personally in my experience. I mean, man, I over-engineered some products. I think I spent, uh, about a million dollars over-engineering, uh, startup that, that I had called opt demand and. At the end of me spending a million bucks on this really fancy UI and single page web app and all this really cool backbone js was kind of the hot framework at the time.

All this cool stuff that we built, it turned out that the what and the why wasn’t really clear for my end customers, and we had to throw it all out. And it was such a shame and, and I lost people on my team as a result of having to pivot away from that. So that’s really the thing that, you know, the more I’ve spent time working on product, the more appreciative I’ve become of the value that that can have if, if done correctly.

By the way, product management can be done very poorly, too . So, uh, you know, it isn’t a, a fantasy about.

[00:07:39] Rachael Lewis-Krisky: And it seems like what you’re both sort of touching on too is, um, the nuance of, of scaling, which is sort of one of the focuses of this episode. Um, but that word does have multiple meanings, doesn’t it? You know, for some companies scaling might mean hiring a larger workforce, while startups and smaller businesses might have more of an experience with scaling that’s focused on.

Improving and developing product that serves more customers or in users without having to add a larger team. So Sam, as you and your sister have grown crave cookies, what has scaling sort of looked like for you both?

[00:08:09] Sam Eaton: Mm. Yeah. I think most people think of scaling, especially in the engineering context. Is is like a, We need to max out our database. How do we make it so like we’re charting the database and doing all the other advanced kind of stuff you would in engineering.

But I feel like, uh, one of the kind of lesser discussed aspects of engineering, is operational efficiency. And I feel like, not enough attention or at least resources are given to in for engineers to like really optimize. Internal operations at companies. I feel like that’s where Crave really did well.

'Cause if you think about it, um, baking cookies is not rocket science. it’s one of the oldest, um, things that we’ve had since we’ve had a conventional, oven. So, um, I would say, the way of scaling that is just how can we make more cookies and like map the orders to the people who ordered them.

And so what, what crave, like what we did is like, the customers are my customer, but like to serve them indirectly as an engineer, I kind of needed to serve the business. And so thinking, Hey, can, can I actually make it so um, I’m making it easier for our kitchen staff to map these orders, and then when we give them to the drivers they’re able to fulfill more orders and, and that makes means the cookies are more warm and they’re more fresh and everything. So it really does benefit the customers.

[00:09:25] Rachael Lewis-Krisky: It’s about efficiency for you.

[00:09:26] Sam Eaton: Yeah. So, yeah, I think that’s just one thing, but there’s, there’s a lot of different ways to break down scaling.

[00:09:31] Gabe Monroy: And Sam, I love the point around operational efficiency and operational efficiency of the engineering team too is I think an important dynamic.

It’s hard because a lot of engineers don’t wanna measure their time spent on doing toil or doing writing to features or managing a service and, and yet, if you wanna have a focus on operational efficiency, you do need to understand that, particularly at scale, right? So in the beginning days, As you’re, a small team, you probably have a good sense of where you’re spending your time, as your team grows, you know, it becomes more challenging.

You said something else, Sam, I thought was interesting, which is, you point out how a lot of people think about scaling and they think about database charting. Like building these big ivory tower systems that can scale to the moon and all that stuff. And, um, there is a real failure mode in our industry, I’d argue overall around people building systems for a level of scale that they don’t need right now and they’re likely not going to need in the future.

And I’ll tell you, one of the things I got to do at Azure was I launched Azure’s Kubernetes service, which wound up being the fastest growing service, uh, in the history of Azure, fastest growing compute service in the history of Azure. We rewrote that thing like three or four times, right?

Like, because you don’t know what your scale bottlenecks are always gonna be. And the architecture that you start out with is gonna evolve and change and technology’s changed and your team structure changes and that has impact on what your architecture looks like. And so I always advise folks in this space to.

Build for the scale you have today and what you can reasonably see before the horizon gets blurry on you, right? Like you do need to shoot a little bit ahead of the future, but don’t overshoot on it because you never know. And, and you know, if you’re successful, you’re likely gonna have to rewrite your stack anyway, so you’re better off learning how to rewrite your stack while you have users on it, and, and getting good at swapping out components and doing rapid deploys and changing out your database and managing scheme of migrations and getting good at the velocity part so that you can iterate your way towards, you know, a, a more scalable

[00:11:40] Sam Eaton: Yeah, so it’s, it, it’s not like it’s always about more, more, more, because it’s just more complexity. I think a lot of times scale is just how to refine. Like now that you have all the context because you’re actually growing. You know, how to kind of streamline things and I think that’s where the operational efficiency comes in.

But then there’s also just like how to make the product better. It’s not always making the product more, it’s making it better. And then that gives you more scale as well. Cause as you simplify things, it, it, you get more for less.

[00:12:06] Rachael Lewis-Krisky: For a lot of people there’s probably anxieties, right, about scaling and that’s just a reality of owning and running a business. But, Gabe, you have a particular story that I know you wanted to share, around that that maybe is a good example of, that in practice.

[00:12:19] Gabe Monroy: One of the things that we built at Deis was this product called Deis Workflow, which was a Heroku style PaaS, and it was essentially a Heroku knockoff, for lack of a better word, have a identical Heroku experience and really interesting developer experience. The first version of that experience actually was powered by Chef. And behind the scenes there was all the chef orchestration that was happening and the users didn’t know that, right? 'cause they were using some command line interface and they couldn’t tell that it was Chef happening behind the scenes. But chef was super problematic for the team. So what we ended up doing was re-platforming the whole thing onto another technology called Fleet by CoreOS, which was a different container orchestration system, a different scheduler.

But we were able to do that without changing the developer experience, one bit. So developers using the V1 that was based on Chef or the V2 that was based on this CoreOS technology, could literally not tell the experience. And later we actually had problems with CoreOS Fleet and we moved it to Kubernetes, which at the time is a brand new piece of technology and that’s how I got involved with Kubernetes early on. But again, we refactored and swapped out the underlying tech stack and got to Kubernetes. And again, didn’t change the developer experience at all, or, I mean, we changed it, but it was totally separate from the changes that , we were making under the hood in terms of the tech stack and oh, and as we sort of progressed through those periods, we were able to increase scale, but we were also also able to get a whole bunch of other benefits.

But the key through that was, The customer experience didn’t change overall. The developer experience was identical and, you know, I learned a lot through that, uh, exercise. Um, and I have to say, it hasn’t been the first time I swapped out tech stacks on, on products that are in market before.

It’s, uh, it’s a, it’s a penchant of, of mine, I guess.

[00:14:08] Rachael Lewis-Krisky: If a startup isn’t ready to scale, um, in the full sense in all senses, is there a way to still semi future-proof systems? Um, for instance, I am particularly interested in, tech debt. It is, uh, something that can , exponentially become problematic for an organization and especially if they’re thinking long term about growing, um, that can, you know, be something that they’ll have to face down the road.

So, Do organizations and products really suffer if they give the green light to code that they’ll have to revisit or does fast albeit hacky code actually help an organization compete, making it worth the problems that they’ll face later on.

[00:14:45] Sam Eaton: Yeah. I, I was thinking, uh, I feel like, uh, if you really want to kind of invest early in, in, in kind of like navigating the technical debt or kind of addressing it before it happens. you better have some kind of serious strategic reason to do that. Like if there’s something that’s gonna give you a competitive advantage down the road and that’s kind of like what you’re betting the farm on, um, then that makes a whole lot of sense.

Otherwise, if you have time to even do that, then you’re, you don’t have enough demand yet. You should be underwater a little bit. Yeah, I guess there’s some kind of spectrum of how underwater am I versus like, uh, how much, you know, will, will me kind of optimizing this really kind of allow me to tread water.

Then uh, I feel like you probably don’t want to over optimize on that.

[00:15:29] Gabe Monroy: I, Sam, I, I, I couldn’t agree. There’s another phrase for tech debt. Uh, I like to use code, right? Like any code that I write in a year is gonna look like tech debt, right? . And, and that’s gonna be true for, I don’t care how good a programmer you are. Uh, and, and so you gotta think of it as sunk cost, right?

Like You’ll go revisit it if it causes you pain and suffering. And if it doesn’t cause you pain and suffering, you need to be working on what’s gonna help you grow the business. And I love your point, Sam, around like if you’re finding cycles to like go back and refactor, refactor, refactor to like clear out tech debt, you’re probably not experiencing enough growth on your product.

And that’s actually the thing you should be more worried about is, is making sure you’ve got the product market fit in order to, you know, get you focused on how you can grow the business versus, you know, continual set of refactors. And it’s hard because, we all, struggle I think as engineers to see how things can be improved and test coverage can be improved.

And, you know, hey, that code I wrote isn’t idiomatic for the language and you know, or I’m using the old library or blah, blah, blah. And it’s like, yeah, you could go change that stuff, but like, is that really where your time is best spent? Probably not. Uh, it’s probably best spent elsewhere. Uh, but the pull is, is real, right?

Like the, the pull back into the code base is real. And so, you know, if you’re gonna do those things, my advice is just make sure you understand what’s the acceptance criteria. Like, what’s the metric or the, outcome that you’re looking to achieve by going back in and doing that refactor.

If it’s not really clear the business impact of that exercise, you probably shouldn’t be doing.

[00:17:08] Sam Eaton: Yeah, it’s the, the, the quote comes to mind, especially when you’re saying like, you’re probably not experiencing enough growth is, uh, the devil loves, idle minds or, uh, just, it loves people when, when they’re, looking for something to do. Um, and you’ll look for any excuse to like, make something faster or more streamlined.

But I feel like, if it really does improve like, efficiency or operations, then I feel like that’s not addressing technical debt, that’s innovation. If you are, just trying to make something easier to navigate in the code for engineers, um, unless it’s like making deployment faster or whatever, it’s, it’s kind of a vanity project.

[00:17:43] Rachael Lewis-Krisky: What kind of future proofing is good for small businesses, but not for larger companies?

[00:17:48] Gabe Monroy: I would say the, the biggest thing that engineers at small companies and frankly big companies, Can do is make sure you’re able to deliver code and changes quickly. Cause you never know where your tech stack is gonna evolve to. You never know when you’re gonna have some emergency growth event or some outage being able to.

Move quickly with small incremental changes is a muscle you want build like an athlete who’s, you know, on the track, doing hurdles and you you’re trying to move quicker and, and you make sure that, you know, they’re able to win the race, right? Like you wanna, you wanna build that muscle over anything, particularly in the early days.

It’s optimizing for that velocity and that agility that I think is, you know, gonna set folks apart. And, you know, in larger companies, that’s really difficult because larger companies tend to have a lot of process, particularly around deployments or security policy or anything like that, that tends to slow them down.

Just by nature of the weight of the, of those processes, smaller companies don’t have as much of that burden and, and so when you’re a small company, you gotta realize that’s your biggest advantage. Is your ability to move quickly, your ability to innovate with speed and with purpose. And so that should be your focus is, is working that muscle and becoming that, that performance athlete.

Uh, you’ll, you’ll pick up the processes when you need 'em down the line and, and, uh, hopefully you can keep the speed when you get

[00:19:16] Sam Eaton: Yeah, I think process debt is, is more chronic than, uh, technical debt actually. 'cause if you just look for technical debt, you’re not really trying to refine processes, then uh, you are gonna be slow. and if you’re in the wrong direction, you’re going slow the wrong way.

So it’s like, lining yourself up so you’re delivering code quickly and making sure that that scales as you grow. I think that is a, uh, evergreen strategy.

[00:19:37] Gabe Monroy: This idea around process debt being more, more chronic than, than technical debt. I definitely agree with that. It’s funny in, in. Enterprise culture. There was, you know, with DevOps was becoming popular. There’s a lot of folks running around going, Hey, DevOps is about like the dev teams and the ops teams just kind of getting on the same page and working together and let’s all grab some pizza and beer and let’s hang out.

Ugh, Laf, right? Like, come on, that’s not, you know, that there’s still all the same process bloat and inefficiencies that you would have in that model. And so really for me, I’m all about codifying in software. What those processes should be, right? So if you have approval gates, right, where someone needs to go check an approval and you know, approve a deployment, right?

Which is a thing small companies don’t have to deal with, but in a larger company you gotta approve that you’re deploying code into some sensitive government region like we had to do in Azure, right? Yeah. There’s oh, a process. But the more software you can put around those processes, the more automation you can put, the better prepared you’re gonna be to move quickly and the less processed debt, uh, you know, Sam, I’m gonna steal that from you.

I, I, I think that’s a great, a great term. The less processed debt you’re gonna have overall. And, and again, velocity and speed is, is the key no matter what size of the company.

[00:20:53] Sam Eaton: Yeah. And then you mentioned before the. kind of like elite athlete analogy there, and I think that can be applied to the business. Like I’m 31 years old, I’m in my prime. But you can do that same thing in on the company level. Is my company an elite athlete? Is my company in its prime or is that, is it at an old folks home?

A care home and are we feeding it all of these kind of like pills? Is it, do you have all these kind of security things, all these audits, all these kind of like QA processes that like as you’re trying to get code out, it’s just like I’m on some kind of strict regimen that like I’m just, not moving quick enough and that’s, that’s end of life.

Get your company fit I think is, is way more important.

[00:21:33] Gabe Monroy: Yeah, totally. And, and, and it’s interesting, right, because when you think about how fast the company is growing, right? Companies that are growing fast, like the business is growing fast, you’re gonna need to be evolving the tech stack putting out new features, you know, improving reliability and, and supportability and all that stuff really quickly.

If the business is, you know, maybe just like reach to, it’s growing maybe, let’s say, but it’s reached to plateau. You probably don’t need to be changing the features in the tech stack that much. Right. And, and though your job may be an engineer or a product person in the organization, you know, you may wanna be mindful of the market that you’re in and whether there’s a lot more work to do on a product because if you keep adding stuff to a product that’s actually in a good spot and, and it’s, you know, there’s maybe just not more growth in the overall market, you’ll end up bloating the product and you’ll end up, you know, moving away from the simplicity that might have gotten you the customers and, and the growth that you got to begin with. Um, so you gotta be really careful around understanding how much growth is still there. Um, are you on a rocket ship? Are you on a paddle boat in, in, in the ocean, Right?

Understanding where your business is at is gonna be key to making sure you’re dialing your engineering investment level accordingly.

[00:22:48] Rachael Lewis-Krisky: Do either of you have any great tips for listeners who need to evaluate the scalability of their infrastructure or who are considering leveling up from their minimum viable product?

[00:22:59] Sam Eaton: Um, yeah, I think it’s just putting your product hat on 'cause, uh, with product market fit, the, uh, market moves and so I don’t know if it’s, if it’s always moving forward, but it is moving, so, um, you need to be nimble. Um, as far as scaling the infra, I think you don’t wanna make it too complex 'cause, uh, you’re building from the, the primitives, like you have your database and all these things and it, it’s, it’s pretty easy to, to transition that into other use cases.

If you start really crazy, super specific, um, kind of contextual things, like, Oh, we’re gonna put a database in the browser and we’re gonna do all this kind of stuff. then there’s just so many moving pieces that you’re, you, uh, yeah, it’s hard to move, but I, I would say if you are at the, uh, MVP stage and you’re scaling to the next, inflection point, it’s almost like you’ll know it when you see it, I feel like. Um, so like, I don’t know what, what the best advice is. It’s, it’s, uh, I guess you as a founder or as an employee, you are a customer of your infrastructure and so you have pain too. And so I guess solving your pain is kind of putting your product hat on internally.

Just like you wouldn’t want to over-engineer for your customers, you don’t wanna over- engineer for yourself, but you do wanna solve your own problems. Um, yeah.

[00:24:19] Gabe Monroy: Running databases in the browser. Sam, uh, I dunno if you’ve seen some of new web assembly stuff you, but there’s some real cool in database now

[00:24:26] Sam Eaton: Don’t get me going on the new web GPU stuff, man. That, that’s gonna be crazy.

[00:24:32] Gabe Monroy: I, but I agree, it’s, it’s probably not the best use of time. You know, when I, when I think about scalability and, and sort of advice for folks on this, I, I think it’s important to understand what are you solving for? And so for me, there’s classically three things that I, I can solve for with a team.

The first is scalability focused on cost so that my cost scale with my usage. That’s one area.

The second is scaling for load events. Right? And I think that’s what people classically think of as, as scalability is like, how much load can I handle?

But the third area is also scalability of the engineering team that’s working on it and, and scalability of discreet components that might be managed by different parts of the engineering team.

That last problem, by the way, is something that, you know, at, at hyperscalers it be, and even at Digital Ocean, it becomes really important to understand how you can actually grow different parts of the tech stack and scale different parts of this tech stack, the teams that are working on them separately from the, the load that they’re performing.

But, but you know, I think you said the magic word, Sam, which is product market fit. Because if, you know, a lot of folks will look. These issues and they’ll go, Oh, you know, I really need to focus on scalability and, and it’s like, well, no, Like you should probably just make sure that you got really delighted customers and they understand, you know, you understand what their outcome is.

You know, they’re hiring your product to do a job. They could have hired some other product and, you know, they chose your product. Right? And, and that’s happening over and over again. That’s a good sign that you can even start to think about the scalability issues.

And I would say the first one you wanna think about is understanding your costs. Uh, you know, unless you’re in a really bursty, you know, product where, I don’t know. Yeah. I’ve worked on some businesses where it’s like, there’s a commercial that’s gonna air at the Super Bowl and you’re gonna have a, you know, million people going and hitting your website, Right?

Those kind of things. Obviously you gotta look at the scalability of the overall system, but that’s not most businesses. Most businesses are gonna be more focused on scaling costs as revenue grows.

Um, but it’s really important to do the analysis on that because at the end of the day, running some droplets on DO statically provisioning-- there’s no auto scaling or anything like that-- what’s the actual cost to you to just keep your infra running versus build this fancy auto scaling up and down system? Like go analyze the costs of just doing something simple versus doing something, you know, auto scaling. Uh, you’re gonna find, in a lot of cases, it’s gonna be a lot cheaper for you to not tackle that scalability issue for a while.

[00:27:09] Rachael Lewis-Krisky: And Gabe data driven decision making is key to that, right?

[00:27:12] Gabe Monroy: Yeah. Although I think data driven decision making people think about like, you know, some big massive Excel table and you know, know some data science and all this, like this is pretty basic stuff. It’s like, alright, for us to build an auto scaling system, it’s gonna cost three engineers six months to go build that, right? It’s probably reasonable estimate, right?

Versus if we just run the infrastructure statically provisioned, what is it gonna cost us an excess infrastructure to keep that going? For most businesses who don’t have those massive load events, you’re almost always gonna be better statically deploying infrastructure and not worrying about the scalability. They’re an engineering trap because people get really interested in the how of it and they get super excited about that stuff. And you know, the truth is the business doesn’t really demand it.

[00:27:59] Sam Eaton: Yeah, I’m not a big fan of data driven as a concept. I kind of feel like you want data kind of compatible decisions, and you want to use your intuition as a product leader to kind of still drive something forward. You just don’t want to be, you know, um, To go against all the data and to be a totally dumb decision.

But if you, if you’re purely driven by the data, then why not just let lawyers or accountants run the company? Um, and uh,

[00:28:23] Rachael Lewis-Krisky: Gotcha, so we should all just forget about data then, right?

[00:28:25] Sam Eaton: No, but I’m just saying No, I’m just saying like, I feel like, uh, I feel like that everyone just always falls back to the data 'cause it’s safe. But, uh, you do want to be innovative and the data doesn’t have, future states. You gotta create those and then that will become historical data. Yeah, I do feel like you want data compatible uh, but, yeah.

Also, when you’re talking there before I was thinking, um, there’s typically the horizontal versus vertical scaling, and I think I crave, um, I’ve chosen option C, um, which is neither, and I’ve actually most open source tools, if you actually start learning them, like I read the documentation for Postgres, like the actual online stuff, like four times and there’s, there’s so many optimizations you can do if you just get really down into like how to index properly and do all that stuff.

And even like SQLite and things, I was using that too, and I feel like, um, you can get to a lot of traffic on the kind of basic things 'cause a lot of these tools are heavily optimized. They have some of the best computer scientists working on them. So if you just kind of use them, kind of geek out a little bit and optimize them, you can save a lot of money for the business and, uh, really get more value and more scale out of what you already have.

[00:29:39] Gabe Monroy: Totally agree, Sam. I, I think it get gets down to this issue around sometimes engineers are really interested in the how building scalable systems and, and that pulls them into, Over engineering, frankly, you know, systems that, as you said, I think rightfully so, you can tune the L out of a single droplet running Postgres with some web front end on, on, you know, even on the same machine.

If you want, you’d be shocked. And how much throughput you can get from a well tuned, um, machine. And again, your business probably, you know, if, if it’s a CRUD application or some software as a service application or even some API end point, how much scale do you really need for that thing, right? Like that’s a, you know, most people, uh, don’t actually need all that much.

And, and it might be easier to say, Hey look, this is good enough tech debt and all scalability issues and all. I’m gonna document the disaster recovery and business continuity plan and the ops for this thing. How we do CI/CD, how we do our security for it. Move on to the next thing, right? And, and that might be the best, best approach.

[00:30:40] Sam Eaton: Yeah, Yeah. On the, uh, crave customer page on Digital Ocean, there’s a, uh, a little diagram that shows how we just have a SQLite, um, database file that lives on the same droplet as the, uh, the service itself. And that thing is just sinking every 30 minutes to a uh space And the the cool thing is when I’m doing development, I can just pull that thing down and develop on the kind of production data. it’s just so simple. And it just scales. I built this before. Before there’s a, before SQLite was kind of like getting a lot of attention.

Now there’s all kinds of ways to do distributed SQLite. So like, I don’t think there’s a reason to, um, use like the heavy, heavy stuff. Like if you wanna use like Cookhouse, which is like one of the best kind of distributed like, you know, kind of big data things. There’s no reason to use that when you’re getting started.

Even if you’re just past the MVP stage and you’re getting some demand. Maybe if you wanna, I dunno, build some big, uh, telemetry thing, but I don’t know why you would do that.

[00:31:34] Rachael Lewis-Krisky: So for the last question, and I know it’s sad to come to a close here, um, I have something that I like to ask all our guests on ‘Making Work Work’ which is that, um, aside from work, we do so much in our lives that still informs our work. Other things that are disparate but yet still guide kind of our creativity, our brainstorming, our kind of decision making internal processes.

So I wanna know, if for both of you, if you could share something that you’ve either read or watched or listened to that later helped you in your work, even if it’s Game of Thrones and has nothing to do with with developer work.

[00:32:08] Gabe Monroy: I’m gonna, I’m gonna let you go frist.

[00:32:09] Sam Eaton: All right. okay. So I am an odd duck. My working habit is that I code or do I get whatever work I have to do for about an hour and a half to two hours, and then I take a walk and I, I walk about 25 to 30 miles a week. And when I’m doing that, I am always listening to audiobooks and podcasts. And one of the, the, um, kind of themes I’ve been on recently was, um, 3D graphics.

And so I was listening to like, Pixars, there’s all kinds of other stuff. And I feel like, uh, one of the big inspirations recently was, um, how to really wow people by making something that’s just so much elbow grease and attention, which really went into the experience.

And I feel like as a growth engineer where most of my work is around like how to optimize the business by optimizing the experience and that moves metrics and everything. But like by hearing how all these kind of computer scientists really had this dream of, uh, just really making something that people saw and they just couldn’t stop watching because it was just so different, um, that, that really stuck out to me.

So, yeah, I feel like, uh, um, that really made me think of, in today’s kind of economy, I feel like optimizing experience, um, is really a differentiator. Um, and you know, that’s, that’s why, you know, someone would still pay a premium to go to a Disney theme park versus like a, a non Disney theme park. It’s, there’s more to it than just rides.

[00:33:45] Gabe Monroy: So I live on a farm, uh, and yeah, I got a bunch of animals on the farm, goats and chickens and livestock dogs and all this stuff. And so I spent a lot of time out on the farm and I find it. Helpful for my mental state. And it also just kind of, I clears my brain and helps me focus on work. Uh, and so recently I was trying to build a goat proof chicken feeder, which I’ll tell you what, I built a lot of stuff in an IDE in my day, like a developer environment like coding and whatnot.

This was far away the hardest engineering project I’ve ever done. I’m on like version four of like a ground up rewrite of, you know, again replacing the text stack for, for this, in this case, a goat proof chicken feeder. Uh, and so by the way, I think I finally cracked it this time around, but I’m out here hammering steaks and like nailing in like all this stuff and sitting up buckets and as I’m out there, you know, shoveling. Stuff out of the goat shed, uh, Work stuff pops into my head. I’ll just get a random idea about, you know, "Oh wow, I, I didn’t think about this that way," right?

And, you know, I think for me the takeaway is, brain space, right? We work, I work, you know, executive at a public company. It’s a lot of work, right? I put in a lot of hours, uh. But I’m a big believer in finding space to give your brain a rest because when you give your, when you’re working hard and you’re grinding day in, day out, you lose perspective. You’re so focused on what’s in front of you and the challenges that you don’t really have those aha moments or those insights.

And so when I’m on the farm and, um, you know, cleaning out the chicken coops and doing all that stuff, that’s where I have a lot of my aha moments. So, uh, any, anyone wanna have some aha moments with me, I got some dirty go sheds that could use some cleaning, so you’re welcome to come on over.

[00:35:33] Rachael Lewis-Krisky: We’ll have many volunteers for that, Gabe .

Well, thank you both so much, I really enjoyed learning about the how, what and when of scale without scaling. Um, so thank you both for your insights and for a really great discussion.

[00:35:46] Gabe Monroy: Thanks, Rae.

[00:35:47] Sam Eaton: Yeah, Thanks for inviting me. This is, this was great.

[00:35:48] Rachael Lewis-Krisky: This has been ‘Making Work Work.’ Whether you’re a listener or a customer, the work we do wouldn’t be possible without you.

Special thanks to all the people that make my work work, my DigitalOcean colleagues and friends.

Our music is composed by Mirco Altenbach.

Check out do.co/makingworkwork for more info. Until next time, I’m Rachael Lewis-Krisky. Keep swimming friends.