Subscribe
Share
Share
Embed
Developers building a software business on our own terms.
Ben: So John, I want you to tell me everything you know about falconry.
John: A lot more than I did five weeks ago. So yeah, I—
Will: I need to hear this story. That's like birds, right?
John: Yes, yep. We randomly did a falconry thing at the Biltmore when we were in Asheville. And I was like, “Yeah, whatever”. I mean, it might be cool. Birds. I've seen birds. And my wife was like, no, this is my destiny. And so they only had one ticket available.
So she went and I was able to observe. And then one of the guys who went randomly was, like, I think a little bit creeped out by the birds. And he only did, like, one of his and he was like, “Hey, do you want to do my other turn?” And I was like, “Yes!” So I got to have a falcon land on—I was holding a little piece of, I don't know, squirrel meat or something. And it landed and ate it and I passed it off to the other guy. It was pretty cool.
Ben: Nice. So good vacation?
John: Yes. Very good vacation, and falconry was definitely probably a top 10 animal experience for me. I would highly recommend it. If anyone gets a chance—it sounds weird, but it was really cool, so.
Will: Well, if you hadn't noticed by all the gear in Auburn, eagles are a very big part of our tradition. So, the start of every football game, the big—the eagle flies around the stadium, like 10 feet above the crowd, does a big loop and then dive bombs into the middle. So I believe you 100 percent on how awesome it was being the person actually catching a bird on your hand to eat something off of it. That's wild.
John: I've never thought about that with Auburn. Like I know that, but for some reason it never connected that they would just have an eagle at the game.
Will: It's one of those things where like you don't really notice it on TV, but when you're there, it's like pretty electric in the stadium. Everyone just gets really into it, the things that sports brings to communities—you just get really super into very niche, weird things where everyone just thinks the bird flying around and landing on a field is just the greatest thing ever. And it is when you're there. That's for sure.
John: Yeah. There's definitely this—learning how they actually accomplish that because birds are birds, and what that eagle wants to do is it wants to eat the most tasty thing that it can eat. And so to actually make it happen, I guarantee they have to keep that eagle pretty hungry for it to go exactly where they want and stuff like that. So I learned a little bit about that now.
Ben: Well, that's a—that’s a bit more cool than the LSU mascot. You know, with Mike the tiger. he's great, but he's just hanging out in a cage.
Will: Never been to a LSU game, do they bring a live tiger out onto—
Ben: No, they do not bring a live tiger out into the field, unfortunately.
Will: We don't want that one eating the tastiest thing.
Ben: All right. Yeah. You don't want to keep that guy hungry. Well, in case you're curious about the voices you hear today, we have John Nunemaker rejoining us. Welcome back, John, from your vacation. And we have Will King, a new guest on the episode.
So Will's at Crunchy Data, and we're going to be talking today about some stuff that Will's been doing. And, in case you don't know about college football in the United States, Will went to Auburn. I went to LSU. We're both Alabama natives, we just discovered that we had that connection, so it's fun.
Will: It's okay. I'm not the crazy fan so I don't hold it against you.
John: It's okay. I actually dislike both of you now because I'm a Notre Dame fan. So it's all, it’s—
Will: Oh, well, it's okay, because everybody else dislikes you.
John: Yeah. Yup. We're all used to it.
Ben: Well, Notre Dame lost their coach to LSU, so I can understand why you might have some animosity there.
John: You know that we were actually pretty happy about, but—
Ben: ha ha.
John: We’re happy with Marcus Freeman now, so.
Ben: Nice. I have to admit, I'm still pretty bitter about the whole Nick Saban thing, because he left LSU to go to Alabama, but, You can't blame the man, but still, I still like blaming the man.
Will: It's okay, you can blame him. Nobody likes Alabama.
Ben: So, I was actually reading an article this week. It's talking about Nick Saban. He popped up in the news again and talking about how it was called the Nick Saban butterfly effect. And he moves on from Alabama and then it affects all these other programs because coaches are shuffling to fill in the Alabama spot and then filling in whatever spot they left, down even to the high school level. I think that's pretty wild.
Will: Oh man, that is wild. And not to—I mean, and then you think about if Saban left, he had been curating a bunch of pretty high level coaches who are probably also getting offers to like different programs and then they get moved around. Man, I can only imagine. That's crazy to think about. With development there's such a huge industry of businesses and such a large pool of available workers that there's not really tectonic shifts like that. But in like college sports there's only so many D1 teams and D1 worthy coaching. So I can imagine the butterfly effect that would cause for sure.
Ben: Yeah.
John: Now all I can think about is that Ashton Kutcher movie.
Will: Ah, yep, yep, yep.
John: That’s—that's taking—that’s going way back.
Will: When I was younger, it was like, you know, back when you would just flip through the channels, and just see what was on, and then you, that would come on, and I just remember being like maybe 13 or 14, and just being like, “This is the trippiest thing I think I might have ever seen in my life”. And, man.
Ben: So John, Notre Dame, going all the way this year?
John: I don't know. I just choose not to believe it. I believe that, like every team that I cheer for, it's just like, they got a knack for losing, like LeBron with the Cavs, going down 3-1 and coming back. That's the pinnacle for me. It won't ever happen again. That was my only chance to really be a part of a run.
So I don't think anything's going to happen with it. My favorite TV shows always get ended. It's just, it—I just expect it to not happen. So if they do great, that'd be fantastic.
Will: You and my wife would get along very well. My wife is very much the “Let's just assume nothing good is coming from this and we'll just plan for the worst”, whereas I'm the opposite where it's like, “Well, sure we can be ready for the worst, but let's assume everything great is going to happen to us.”
John: Yeah. I'm only that way in like sports and TV. That's it. Everything else. I'm like very optimistic, but in sports, I'm just like, "Nope, I've been burned too many times”. So, we'll see. We've always got a good crew up here and people love football and it's a lot of fun. I had season tickets when we were 12, and then got smoked by Alabama, so I think after that, it just left a little bit of a burnt taste in my mouth. And so I try not to get it too into it.
Ben: If you want to get used to the feeling of being smoked by Alabama, just become an LSU fan because it happens to us all the time.
Will: Be anywhere in the SEC.
Ben: Well, we're not actually talking about football today. Today, we're talking about shipping software, because that's what we do at our respective companies. So Will, you at Crunchy Data, what do you do over there and what does Crunchy Data do?
Will: So, I am a design engineer. I work on the front end team and do a lot of front end development, but I also manage a lot of the design that goes into our product, specifically for our dashboard interface. But at Crunchy, we are a managed Postgres provider, my boss, Craig, who's very, very well known in the Postgres world, his favorite thing to say is , we're just Postgres, but we just do it really good.
Our main priority is enabling the best out of the box configuration that you don't have to worry about, and then pairing that with Rockstar support, that is, probably a part of this, that I will dive into as we start kind of start talking about shipping. That just is such a superpower at Crunchy, is we have maybe some of the most knowledgeable support members on our team and it is just so much fun working with them because I am, as I mentioned, a design engineer.
I'm painfully, like, on the front side of most of the technology stack. I've dove a little into the backend and definitely more into the database now having worked at Crunchy, but, like, my knowledge there is just very shallow compared to my other expertise and having being able to pair with really expert support, just is such a superpower at our company and not being afraid to just pull on that support and they're very willing to jump in on just about any problem and like excited to do it. So, it's really fun place to work.
Ben: Yeah, we're big fans of Crunchy at Honey Badger. We've used them for a while now, I think about a couple of years at least. And yeah, big fan of Craig, even though he's always wearing his Alabama cap, that's still, I guess I forgive him for that.
Will: When I was interviewing—I think I joined about two and a half years ago—when I was interviewing and I got on the call and I was wearing my Auburn gear, he was like, that's it. Canceled it. Cancel it. You're out. You know, the big rivalry and then, you know, later on, he's just like, “Actually, when I saw that, I was very excited”, because he's an Alabama boy originally.
And he lives in San Francisco. He’s like, “I've never worked with anyone from Alabama before, much less a rival fan, so this is going to be lots of fun”. And he just, it's just all the time, especially in football season. He's not afraid to just give you a hard time in slack, making fun of your team for losing. So it's a pretty fun place to work.
Ben: Craig is solid. And I think CrunchyData support is fantastic. We've had good interactions with them. We've had times, like, hopping on zoom calls and debugging an issue together. It's been fantastic. And, you know, we feel strongly about that, at Honeybadger, about providing great support to our customers. And so it feels good to be partnered with a company that feels the same way. John, yo use Crunchy, didn't you?
John: We currently don't, we use Heroku Postgres just because we're super lazy. I've been looking at Crunchy a lot, mostly.
Will: First of all, how dare you? Just kidding.
John: So again, that just historically—you know, we've used it for, like, I don't know how many years, and so we just haven’t moved off of it. But I looked at Crunchy quite a bit because there's a lot more opportunity for like extensions and other things. I feel like you guys support like hyper log log and some of that stuff. And I've been wanting to use that again, because I used it back when I was at GitHub and I haven't in a while. And so now that I've been doing some analytics again, I've been thinking about that. So it probably—it’s definitely something we've been looking at a lot.
Will: If you're looking into analytics then, we actually just recently dropped an analytics focused Postgres cluster, that is, like, specifically—they’re doing some stuff with DuckDB and Iceberg format and all sorts of stuff where it's just Postgres. You can query using Postgres, but it's just Postgres.
It's super fast under the hood. I'm not—I don’t—I'm not the expert, even though I built some of the stuff on the—in the UI. So definitely reach out to our support and they can definitely give you the rundown. They love talking about it, but.
John: That's cool. And it makes a lot of sense.
Will: If you want to migrate from Heroku, we may or may not have actually written a migrator that does it automatically for you.
John: Oh man. I've moved so many services on all kinds of different things. And it gives me like the shudders every time. I totally understand people and like how they’re selling a dev tool also, it's like people are slow sometimes to switch—but it's like, you know, you switch. A lot. And anytime you migrate, there's always, like, little things that surprise you.
My current thing that I will never switch again is support tools. I am just like, “I will use the same support tool for the rest of my life”. I've switched so many times and then it's like a chaotic disaster because this help doc didn't work or this other thing, or now they can't access this, you know, URL history or that kind of stuff.
But yeah, it's funny how that works out. I was thinking though, when you were talking about support, how great it is to have—I feel like it's required the deeper in the stack you go. And when you get to the point of hosting your own hosting state, you know, that's the most critical spot in anybody's stack. And so having, like, really technical support in that area makes complete sense to me. That's a very long term focused thing, to make that part really good.
Will: And it's such an interesting area, too. Like, when you think about these type of infrastructure-y type tools, there are some dev tools where it's like, “Hey, we make this, like, very standard thing just easier for you, so you don't have to think about it”. But then there's like this layer of tooling, like you mentioned, where it's like, “We're with you on a journey, you may have become our customer when you were smaller”, and I'm sure you are very familiar with this Ben, like, you may only be getting a few, like, reporting cases from a customer, and then they're with you for five years, and you're getting like, hundreds of thousands or something.
And same with like databases and stuff where it’s, like, customers scale with you. And you learn just as much about their business, being part of their growth, and supporting their infrastructure. And you get a different view on their company. Like, you get a view on how much they're getting used, like, where they're running into bottlenecks, what places, and so in general. Like, our support team gets to talk to us a lot about that, where it’s—like, you see this unique perspective of oh, well, they're continuing to run into bottlenecks here and here.
And when you share that with them—like, we've got very product focused support team as well. So like, they'll share that with customers when they're talking to them at times. One of Craig's favorite things to say to me and the rest of the front end team is we're the ideal customer—not front end developers, but like, people who don't know that much about databases.
We want to bring people on who don't have to be DBAs to be able to be good at having a good database supporting their product. And it shows in kind of the people that they hire and the way the support team approaches their work. I work at a place where I get to be the dumbest person in just about every room. And I would—that’s like the best thing that I could possibly hope for.
Ben: Yeah, it's awesome to be able to—to learn from others and get exposed to things that aren't necessarily your bread and butter.
Will: Yes, which brings me to, like, why I was excited about this topic and to talk with y'all specifically about it because, I mean, both of y'all have been shipping, and I'm a lot more familiar with, you know, Honeybadger, but, what is it? Y'all started in 2013? 2012?
Ben: 2012.
Will: So like, you're on 12 years of shipping product and, like, I've formulated, from the article clearly, like, some opinions on how I ship and how I like to maintain product velocity, but there's just this narrow scope in which the type of companies that I've worked at and, like, the length of my career.
I just thought it'd be super interesting to just get your take on having shipped for as long as y'all have, like, how much of that resonates, like what's different, what might be missing, and also just talk about like my take as well, because it is working at Crunchy Bridge and there's like nuggets of it that I think are true no matter how long your company's been around, but I feel like there's definitely areas where things can change depending on the stage that your company is at.
Ben: Yeah, yeah. And this is a topic that I think we discussed recently on the podcast about when you're thinking about minimum viable products, what exactly constitutes a minimum? You know, because for us, like you said, talking things change over time—when we first launched, right, the minimum viable product was “Okay, it's got to be able to record an exception, put it in a database and show it to the user.”
Like, that was pretty much it. It's like, “Oh, let's do what Airbrake is doing, but better”, right? So, that was pretty straightforward and simple, but fast forward 12 years and it's like, “kay, we want to launch this new insights thing.” Well, uh, that's a bit more involved now than it was 12 years ago. We can't just throw it out on one server and hope for the best, like we did back then, but now we have to actually—people expect us to have a certain resiliency story and a certain capacity story. And we can't just let everybody in and hope for the best.
We have to plan for, you know, a certain amount of support and a certain amount of doneness. So the minimum bar goes up, I think, as you get longer into it. John, you're nodding your head. So tell me what you're thinking.
John: Nodding my head because I'm thinking, do we—this is something I've been thinking about a lot lately is, do we actually have to do that? Or is there ways to go back to the beginning and just ship stuff really quick? That's this thing, I feel. Sometimes I feel like we're going through sludge on Flipper and it's just moving slow and we’re, like, operating like we're GitHub and we're not.
We're like, we're at the very beginning, but I have BoxedOut, which is the opposite. And it's been around a long time and stuff like that. But I think about it the same way on both of them is like, how do you pick up the pace? It's like, how do you increase the velocity? It's been like this thing that's really been in my head a lot.
I think there's ways to like not drop the quality too much and still move faster. When you were talking about that, what I was thinking about right away and why I was nodding my head is basically like, “Well, what could you have done to do that path with insights?”
Like, could you have shipped it to like the first customer, and then let them hit some issues and then ship it to, like, let five more in and then let five more in, like do a more of a controlled release. And would that have made it easier? Knowing that, like, at some number of customers, we're definitely going to have to rewrite it, but I don't know what I'm curious about, I guess, is this point is like, is it because we get more experienced over time that we demand more of ourselves or do our customers demand more or do we just think that they demand more? And I don't know what the right answer is, but that's been in my head a lot the last, like two months.
Ben: Yeah. Yeah. I think it's all the above actually.
John: Yeah.
Will: Yeah.
John: Yeah, that's definitely true.
Will: I think it just—it snowballs and I've not been in a product that, like, Crunchy has been around for a long time, but I've not been on a team—I think the long I was in on a team for seven years when I was a very early developer. So, I didn't have a lot of opinions. I didn't know how to think through these kinds of things, but as I've gotten more experienced, I've spent two to three years at a company at a time, so there's not just this like huge timeline that I've built these things up at, but what I've noticed with crunchy, what we do different is, it’s a top down culture, you know, like Craig is Mr. Velocity.
Like h— he finds shipping and shipping quickly to be an important quality. And I think a lot of times, one of those factors that can break that down is when you have bureaucracy as the culture, or when you have perfectionism as the culture, or you have, like, there's something about the culture that pushes back on, and some of that, Craig talked—we talked about this for a while when I was writing this article originally, where he talks about, it's like, some of it's just: people are scared.
They're scared to mess up. They're scared to get something wrong. Business people are scared for numbers to not look as good as they could have. People aren't as connected to their customer. They're connected to metrics. And they're so concerned about those things that they don't experiment.
And when you kind of lose that, that process of experimentation, so the—in the article, I talk about shipping and layers, and it matches exactly what you were talking about, where I think with every problem and I think the greatest—one of my favorite articles of all time written on the SmartBear blog, SLC, which I think everybody has probably read that is in products at this point, small, lovable, complete, that's talking about like products as a whole, like there's this concept of an MVP, but there's also this concept of something that's small, lovable, and complete, like there's this core problem that if you just solve it in a complete and well done way, you can get what a customer needed out of your business and you build on it from there.
I think that concept applies to, like, everything that comes across my desk as a engineer, designer, a builder for this company. Like, everything that comes across my desk as a task to use can be broken down to some small provable foundation that's like, this is why we think this feature is valuable, and this is the thing that proves that.
Where, a lot of times if you plan out this feature, and as a business you're like, this is exactly what it needs to be, it's got these bells and whistles because customers are gonna love it, and you do this thing and you make sure it's perfect, and it's got this nice little bow on it, and you ship it, and you realize what the customer actually wanted was just like slightly different up here, or like very different up here.
But when you open yourself up to those integration points, what you realize is, oh, I'm like slightly off trajectory, like, they like this part of it, but they need this instead of what we thought, so we change that here. Oh, we overcorrected. Let's change it back this way. And like you, you give yourself more chances to course correct to actually land where the customer wants you, than where you thought the customer wanted.
Ben: Yeah. Have you seen that image, that comic image of the tree swing? And like, what customers wanted and what project management described and what developers understood and what finally got delivered. You haven't seen that. It's awesome.
Will: I haven't, but it sounds like a very classic.
Ben: Yeah, I'll put it in the show notes. It's, it is, it is a classic, but basically it ends up with like a tree cut in half and the swing is right in the middle in the gap there. And yeah, it's just, it's great, but you described something that I've thought of and building—a way of building broad then deep, like I've done a lot of like zero to one, helping an entrepreneur build go from idea to something.
And so often I think developers, we want to dive in deep to a thing and “Let's make this awesome”, like you said, like everything from soup to nuts and put this big bow on top. But I find that, if you actually do the broad thing first, like let's hit all of the basics, right?
And let's not dive deep on anything yet. And then, okay. Once we feel like, "Hey, this is kind of working.” Then we come in and start to embellish, start to add on—we did a very similar kind of thing with Insights, like we just, “kay, now you can query your data. Okay. Now you can visualize your data. Okay. Now you can interact with this pop up tool tip thing.” Which is super cool.
But if we had focused on that particular use case from zero, then we probably never would have gotten around to some of the more critical things. And even today, like, we don't have alarms yet, and that's kind of important for a bunch of data coming in, right?
So that's the next thing we're working on that’s going to be layered on top of what we have, but people can still get benefit out of being able to run the queries if they don't have visualization. They get benefit out of the visualization, even if they don't have alarms yet, right? So I think being a broad base and then building deep into that on top of that is the way to go for sure.
John: Yeah. It's the same thing on Flipper—we recently did analytics just so you can see how many checks were happening and the true-false counts and stuff. And it was like—to start, I literally just built, like, okay, first it's just every single check event is going to get shipped up and then we're going to batch process them and store these perfect things.
And then I was like, oh, that's a lot of throughput. Okay, let's just slim it down to, like, minute summaries, you know, of true-false feature name things like that, to reduce the throughput to us. And again, you lose some of the raw data. It's fine to get—but we got that all working and then we got it working for ourselves, we let a couple of customers have it and literally it's just integrated in a couple of spots.
Like, the first thing was “when was this feature last accessed in this environment”. So you can see this feature hasn't been accessed in production for three months, so you can probably delete it. It's fine. And so, that started going into the delete form and then it started going into the edit form.
And then it was like, oh, well, you want to see it over time, to see if it's generally rolling things out the way you expect. So I added, like, a last 24 hours, Heroku-metric-style graph, and then it was like, oh yeah, okay, this kind of works. Let's just turn it on for everybody.
So we turned it on, on the client side, you know, and then it was like within a month or so.—it was like, nope, I did not aggregate enough. I needed like hourly aggregations, and again, I knew I was going to need hourly aggregations, but I was like, yeah, maybe I can go for a while like this. And the nice thing is if you do know you're going to need those, you know exactly how to fix it.
So it's like a few hours or whatever, and you're done. But yeah, it's like that same kind of—layered is really a good way to describe it—approach where you start with like, well, the basics are we just did. Some events coming in, then we need some reports on those events. And then we need more efficient on the way in, then we need more efficient on the way out.
And you just keep—and it's like, well, we need more timeframes. And so it's natural, just like you're talking about with Insights and with the other thing, to layer them like that. And then you actually feel like you're making a good amount of progress each time as well. It's not like you're not biting off this massive amount and not getting it actually shipped until, all of those things are done. And then that stuff lives in your head for like a month or two and you have this huge PR and you put it out and everybody just says, thumbs up. It looks good because it's too much to even look at, you know?
Will: There we go. That's the hidden cost. Yeah.
John: So yeah.
Will: When you say it the way you just said it, there are two things that popped out while you were talking. The first one being: the layered approach also gives you insight into if it's being used, you know, like there may have been six things that you thought had to be included or six things that a product manager or somebody who is helping with the feature thinks needs to exist.
And if you're shipping them in layers, you get feedback from customers and realize, oh, like nobody is even using this. Like, before you wasted all that time and effort that could be spent somewhere more valuable, you find out a lot sooner. Oh, this isn't even being used. We thought this was a great idea, and so we built it, and they aren't even using it.
You find that out a lot sooner, and that got me thinking about it because you’re—it sounds like you've got something that is super valuable just built into your own product to dog food, where you can see very specifically where things are being used and things are not being used.
And we get that too, where it's like, you know, oh, we haven't heard any bugs about this thing we launched a month ago. Like, not even one. So we've not heard—if we've not even heard one bug, like, we're all pretty good developers, but we're not that good, you know, so like, okay, this must not be used too much yet.
If it's not being used too much yet, like, well, let's focus our efforts somewhere else until we do start hearing more chatter about it. That kind of thing. And then the other one was, when you're saying all of that, like, well, you add this on and then we needed to do this. And they're like, well, if we're doing that, then we got to do this.
Like, you can see how if the culture is not to ship things, to push things to production, you can see how that gets brought up in some meeting by someone along the way. And everyone just agrees, oh, you're right. We need to do that before we can do, push anything out. And it's very understandable to see how teams can get lost.
And that's what Craig told me, like, he feels so strongly about it now. It’s—he would just watch teams, when he was at Heroku, just grind to a halt because of that. They would just get so concerned that everything that got brought up that sounded important and sounded like it needed to be taken care of, it did need to be taken care of, but it didn't have to be taken care of for anything to be shipped of value.
John: Yeah. The last year or so I’ve—my quote that I've been trying to live by is bias towards action. There's this great—have you guys ever read Fighting a Hydra or—it’s something like that. It's like one of my favorite—like the creative journey books ever. I think it's like How to Fight a Hydra is the name.
And basically the first half of it is a fiction story about a knight who tries to take on a hydra, which is like, what, seven, eight headed—some kind of mythical creature. I'm not real again—real great at fiction, and then the second half of it, they apply what the knight did. And like, how the knight approached it and that's how they were, you know, I'm not going to hashtag spoiler alert—kill the hydra.
But it's a great book. And one of the things that's in the book is , the night just like tries to get farther and farther and closer to the hydra each day slowly—at first he tries to go all the way in and take on the Hydra and he almost dies, you know, and it's that kind of stuff.
And so, one of the quotes was like, rumination—basically like the root of all evil. Only action shows you what needs to happen next. That book was probably three or four years ago for me, but I have it on a Yeti. I, like, took the quote and I put it on a Yeti.
So every morning when I would drink my coffee, I would see it. There's some brand placement. We've got to deal with Yeti today, but that—that quote really hit me, but then I didn't really live it out for a while, I feel like, but now just, really the last year on both BoxOut and Flipper, I've been thinking about that a lot, like this bias towards action.
Because it's very easy when you get a group of people where just—if just one person is kind of eh, then everybody else is like, well, maybe we shouldn't do it. And so, like lately it's just more, like, whenever I feel like something needs to be done, I'm just like, I'll just do it. Worst case scenario. I say I'm sorry. And somehow repair, if it's wrong, but, like, biasing towards just doing something gives you more data than thinking about it.
Will: There's this newsletter called Register Spill written by Thorsten, uh, Bell? Thurston, Thurston Ball? Um, he works at Zedd, and he just wrote this one recently where it was—the whole point of the newsletter was this concept of if you're doing something and it feels hard, it's because you haven't done it enough.
And it’s, like, very applicable to this. Shipping feels really hard when you don't do it that often. And it's very scary. You're worried about what people are going to think about the code that you write or the feature that you've built. But like, if you can break it down to do something more often than And then, Kayla Porzio, it's I feel like this is just, I guess on a lot of people's minds or I'm just, like, looking for it more, because I've been writing about it. He like makes live wire for the Laravel language, and he just had this, episode of this show called, Notes from Work, where he talked about the journey back is always shorter. It's harder the first time you're doing stuff, but when you're coming back, you've been down the path before. It's the exact same distance, but because you know what to expect, it feels shorter, it feels easier.
John: Yeah.
Will: So yeah, very applicable concepts. And I just love that—like that mentality, but it's hard sometimes in a job where especially at a place like Crunchy, if I was—my wife tells me like, Will, you are overwhelmingly confident for no reason. You're like, you are confident about a lot of stuff that you have no reason to be confident about. I have it very luckily built into my personality traits to just be confident and just do stuff regardless of what other people think. And it's very lucky that's the case.
Because at crunchy there are way smarter engineers and you're always just, you can easily get in your head when working in an environment with really smart people in engineering that like, oh, is what I'm doing as good as what they're doing? Are they going to think what I did was good? And that is also something that can surface a lot of times in a role if you've got a culture of that, or even sometimes the culture may not even be that way, but you may just personally struggle with that where it's just like you're worried about what others are going to think too.
So like a lot of shipping velocity is just, like, encouraging people to do it and letting them know it's okay. And like the way you react when things do go wrong is not going to discourage them from doing it that way again, but is going to guide them into, like, maybe there are processes, maybe there's like something, whatever the issue was, like—you don't have to put that blame on them so that they're scared to do it the next time.
Ben: Yeah, I think developing that shipping muscle is definitely something you can overcome that fear of it's not good enough or it's not ready yet. And it's like, oh, you just put it out there, with—especially with using feature flags, right. And you put it out there. If it's not good enough, then you can just turn it off easily right?
It's not a big problem. I think having the bias for action is something that we should definitely encourage, because I think a lot of engineers are, “it’s not perfect yet. I need to polish it some more". And it's like, no, just ship it. It's fine. It's if it breaks, it's fine. Like, you know, of course, Honeynadger, we make money from people shipping stuff that's broken, right?
So you should, you should definitely ship more stuff that's broken. But I think that, you know—but just aside, I think getting stuff out there sooner rather than later, even if it is somewhat broken is okay. Like your customers hopefully love you, right? They're going to give you some grace, right?
And if things are really, really broken, you can just turn it off with your feature flag and go fix it up. But I think one of the dangers of being,—you can, of course, take that too far, right? The bias for action can get you in trouble if you're just like, Oh, I'm just gonna throw some stuff out there.
I'm not even gonna think about exactly where I'm going. This article that you linked from Jason Cohen about the the simple lovable thing is great, except that I have an issue with he—he uses the very famous image from the—from Spotify. I think it was the modes of transportation.
Like, you know, this is not a minimum viable product with the one tire and then two tires and then the body frame. He says, you should instead make it a skateboard and then a scooter and then a bike and then a motorcycle and then a car. And I have problems with that because I like to ride motorcycles. I like to drive my car. I like to ride on my one wheel and I like to ride on my bike. And those are very different things. Very different experiences, like if you're setting out to deliver a car, it's not acceptable to me to deliver a skateboard first, like that's, I don't want a skateboard. I want a car, right?
And so I think maybe a better image would be like, okay, give me a soapbox derby car, right? And then give me a go kart and then give me a car, right? I think having a vision for what you want to deliver and then delivering on that vision. It's just as important as having that bias reaction and actually delivering something. And don't say, okay, well, we've got a login form so we can ship it.
Well, no, you got to have something there, right? And it's gotta be something along the lines of what you plan to get to eventually. So, having that person on your team, at least who's like thinking six steps ahead or six versions ahead. Okay, we want to get here and we don't have to launch there, but we want to get there. So let's, what's the V1 going to be, look like, to get us to the V6, which is our actual destination.
Will: The, the importance of I saw it on Twitter, I guess it was a couple weeks ago, but , it was that exact pushback, which was just this concept of , everybody has gotten so caught up in the lean startup or the MVP or like shipping things that are small that they're shipping things that are bad.
Like, just because you're shipping quicker or you're trying to ship things in smaller increments doesn't mean you have to ship things that are worse. Like you can still ship things that are good. I liked the word that you use, vision. We have somebody on our team who is very much the—I call him the sweeper, because he is very good about like coming back behind us, specifically me. As you can tell, I'm very much biased towards action, sometimes too much as I'm sure my teammates could tell you at times, but he always comes back and he can clean up.
Ben: On our team, Kevin is really the deep thinker, the one who's like, okay, here are all the things we want to do. And I'm more of the shipper. And so I'm like, okay, Kevin, we can, we need to ship. And he's like, but wait, but wait, you know?
And it's a good—I think it's a good friction to have on a team, to have someone who's really thinking a few steps ahead and making sure you go in the right direction. And then somebody was also like, okay, now let's actually take a step. Yeah.
John: I would say the same for us on Flipper. Like, Garrett is more of the deep thinker. Like, he goes all the way through and crosses every T and dots every I, and I'm like, let's just get it out. Like worst case scenario, you know, if X number of customers complain or have problems, we can help them.
And then we get to talk to them. I almost like when problems happen and customers, actually communicate with you because—customer as a developer, they're typically very quiet. Like they don't say a lot unless something's wrong. And so it's kind of good. Then when you get them on the horn, you can ask them other things.
I've started even doing that on a Flipper repo. Like, when people submit an issue, I'll be like, oh yeah, I'll fix it up. And then I'll be like, also, if you have time to tell me about flipper in general and how it's working for you and how it's not, and all this, you can email me here, blah, blah, blah, just because , it's like, oh, I actually got a touch point with a person, And got some feedback.
So, we had the same thing with a pricing version thing where he was like, well, we want to allow people to opt into the new pricing. We don't want to force it on them and then allow this. And I was like, this is just for like, X number of customers who already exist, right? And he's like, yeah.
And I was like, I'll do them by hand if I have to, we’ll just put an email box there. And he's like, okay, yep, I can do that. He's like, I wouldn't naturally want to do that from the beginning. He wants to like, make it work all the right way and stuff.
But I'm like, when you're just trying to figure it out or if there's numbers are at a scale where you can do that, you can definitely shrink it back and just make it a manual thing. And I love the concept of a sweeper because I have been a sweeper like my whole life.
And I actually really enjoy sweeping. It's one of my favorite things to come in and clean things up at the end. So, I was glad that you mentioned that even for a second, Will , because I think sweeping again, since I love it, I think it's a very important role in every organization, so.
Ben: This has been a fun chat. Thanks for taking time—I enjoyed getting to meet you Will, and John's always a pleasure to hang out with you and get your insights. Cool. All right. Well, this has been another fantastic episode of FounderQuest. Glad you're here to join us, and hopefully you'll join us again next time. See ya.