/
RSS Feed
Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about some tactics for minimizing disruptions to your vacation. Sometimes, it’s really tough to feel like you can unplug as an entrepreneur, especially if you’re running a SaaS. The guys breakdown some things you should do for your next vacation.
Items mentioned in this episode:
Mike: In this episode of Startups For The Rest Of Us, Rob and I are going to be talking about tactics for minimizing disruptions to your vacation. This is Startups For The Rest Of Us episode 402.
Welcome to Startups For The Rest Of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products. Whether you’ve built your first product or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: We’re here to share our experiences to help you avoid the same mistakes we’ve made. How are you doing this week, Rob?
Rob: I’m doing okay. I’m a little tired. We landed back from California. Landed in Minneapolis last night around midnight, hopped a lift with the kids, and got home, and in bed around 1:00 AM. I’m on Pacific time so I had a couple of hour times change this morning trying to get up. It’s a little slow getting going but overall, really enjoyed our time in California.
I had talked about previously that we’re going to spend some time with my family in the Bay Area. Our kids had a music camp in San Francisco and then we went and saw Sherry’s folks up in far north California.
Overall, it was good vacation; some vacation, some kind of work stuff. The camp isn’t exactly vacation because it’s pretty intense music practice for the boys. Each day we have to be present and stuff. It wasn’t like we could just kick back and sip martinis or whatever.
Mike: You don’t get to send them for the day?
Rob: No. That would have been ideal. It’s less at camp. It’s actually called an institute, the Suzuki institute. You go and it’s five or six hours a day of them playing instruments, and the parents have to be involved to a certain extent, so you’re sitting in there with them. That’s where I was like, it’s some vacation and it’s some not-vacation. It’s fun in the afternoons and evenings when we took the boys and did stuff but otherwise, got there and back unscathe, which is good when five people are traveling and we lug a cello with us on the airplane. In true chaotic fashion we were back, like I said, landed last night at midnight and then we close on our new house tomorrow in Minneapolis. We show up and sign papers in the morning.
Mike: Stick around for a while then, huh?
Rob: I know, yeah. That was the decision. We really evaluated it after I left the Drip a couple of months ago. It was a decision point like, “Okay, we’ve been in Minneapolis a little less than two years and we can move anywhere. That always sounds great in theory but when you have no real ties anywhere for work—we have family in California—but there’s no reason for us to live in any particular city. I shouldn’t say no reason. There’s no requirement that we live in any particular city; becomes a very difficult thing to tackle. It’s a paradox of choice, it’s almost too much choice.
We evaluated going overseas, and then we evaluated all these cities on them, basically the west coast, even Austin, Denver, Colorado Springs, and Sherry threw Hawaii or Maui. Actually, all these sound great but then you look at what it’s actually like to live there. You look at the days of sun per year, you look at the cost of living, you look what the traffic is like, and you read on Quora. You say, “What’s it like to live in insert city?” You can start to get a feel for what it might actually be like and certain ones just right off the bat are just removed from the list. There are just deal breakers that come up.
I love the Bay Area, I grew up there, and it’s the tech hub of the world, so to speak. But the cost of living there is outrageous. It always has been but it’s catastrophic, basically, and the traffic, I couldn’t deal with them. I would like to live in parts of LA but the traffic there is–you know, it’s just on and on and on there. There’s just things that knock it off.
It was a long and detailed conversation but eventually we got to the point where we decided that staying here was the best option of all of them. But it was a good exercise to go through, to arrive at a decision, and feel good about it, and then be like, “We’re going to buy a house.” We figured that this is a 10-year decision. We have kids that are basically 7, 8, and 10. In 10 years, they’ll pretty much all be gone from the house. At that point we will very likely either keep the house and get a second one somewhere sunny or we’ll sell the house and completely relocate.
Mike: I would have completely lost the pool on any bets that might have been placed about where you’re going to live after your time at Drip is over. There’s no way I would have picked you sticking around in Minneapolis, like there is no chance.
Rob: I think a lot of people wouldn’t have thought that and told us that, and frankly, I probably would have lost the pool as well. I would have imagined we would probably move back somewhere in California but there, at a certain point, quality of life and other things factor in. We lived in a lot of places. We visited a ton and we’ve lived in a lot.
Every once in awhile, you find a place where it’s like, “Wow, this is a world class city with world class amenities, but without so many of the problems of other cities that we’ve lived in,” including location, cost of living, crime, good schools, you just go on a list of all the things, access to airport, delta hub, all the stuff. As we looked at all the other cities, it was just so hard to even think about giving up each of the things that we have here. I wouldn’t have called it from the start, either. I think Sherry might have. She knew it was a pretty cool city here. I had no idea before we moved here.
That is the story. We close tomorrow and then we basically move over the weekend. The nice part is the house, it’s only a block away so it’s an easy move. I can move my own guitars and expensive stuff without worrying about movers trucking a dent truck.
Mike: Yeah, I think that would have been the deciding factor for me, it was that I wouldn’t have had to move my stuff. That’s why I would have just stayed there.
Rob: Totally. No, I know. I’ll admit that we used to play factor but at this point, we’ve done it enough that’s it’s like, “You know what, it’s a temporary pain. If I want to make it a 10-year decision, I’m going to make the right 10-year decision. Even if stuff gets broken or even if I have to pay more money to have someone move it. Let’s make the right decision for long term.” How about you? What’s going on?
Mike: I have some potentially good news here. The contract is finally signed for MicroConf Europe. That took forever. I saw it in an announcement a couple of weeks ago and I talked about it on the podcast. We hadn’t had signed paperwork in place yet and the problem that we ran into is we actually had to switch hotels in the meantime. It really sucked to have to start this process completely over which is why things stall for so long. We do have the signed paperwork, was sent over this morning, everything should be good to go. MicroConf Europe will be in Dubrovnik, Croatia this year and it will be from the 21st to the 23rd. That’s Sunday, Monday, Tuesday of October.
Rob: Looking forward to it. It’s going to be fun. Buy your tickets now. Oh wait, tickets aren’t even on sale yet. When do tickets go on sale?
Mike: Within the next week or two. I’m probably going to be sending an announcement over the next couple of days and then give people a little bit of time just to make sure that they can check their plans or whatever. I don’t want to drop it on people say, “Hey, here’s the date. By the way, here’s the link to buy tickets.” So give people at least a little heads-up.
Rob: Cool, that’s exciting. Glad to have that locked in. Looking forward to seeing folks there in a few months.
Mike: You had asked for an update on the local meetup that I did?
Rob: That’s right.
Mike: I think there were five of us who showed up? There were a dozen people or so that I invited. Some of them just couldn’t make it because either the day of the week or it was just a little bit too far based on the location. I try to picked something that was central to everybody but obviously, it’s going to be farther for some people than others. For some of them, it will end up being a two-hour drive and it wasn’t going to happen.
But like I said, five or six of us got together and it was a good time. Everybody was just chatting about what was going on in their business, how they were doing things, and what sort of markets they were going after. I think two of them were there who had previously purchased my book and then the other two had come in. They were both at MicroConf. It was nice to see a little mix of those guys and both of the guys who bought my book, I think were also in FounderCafe as well.
Rob: Oh, cool. That’s always fun, man. Glad to hear it went well. What’s going on today?
Mike: Today, we’re going to be talking about tactics for minimizing disruptions to your vacation. The idea for this topic came up because there was a thread inside FounderCafe that was posted for somebody who was asking, “How does everybody else take vacation because I’m worried about things like DDoS attacks or servers going down and this and that.” I thought what we do is we spend an episode looking at different ways that you can mitigate the risks to any of the things that could go on that could just end up disrupting your vacation and make it more stressful to go on vacation than to actually be on vacation.
Rob: That makes sense. I think this is obviously a concern of a lot of founders and I think in the early days it’s hard to even know how to approach it. I do hear this question now and again. This is from a FounderCafe thread that someone posted in and there was some pretty end-up discussion about it. I think we’ve talked about this before in like a Q&A episode, probably 100-200 episodes ago and I think this warrants rethinking and refreshing everyone’s mind about how to pull this off every so often.
Mike: To dive right in, we’ve broken this up into several different areas of what your business is. I think the first place to start with is the place where you probably get a lot of headaches that come out of it which is support request from either your existing customers or from prospective customers. Because you don’t want those things to go unanswered for too long and you just want to make sure that you’re responsive to people so that they don’t say, “Hey, what’s going on? Why is this business that I’ve trusted for so long with my data and my application, why are they not responding to me?”
Ideally, what you would do is you outsource and then empower your support people to do things for you. The problem is that not everybody is in the position where they even have support people and that’s, I think, is the most common situation. If you’re one person and you got your business running, it’s a SaaS application or something like that, how do you respond to those support request while you’re on vacation? You don’t want to be on a ferris wheel or something like that or just about to get on a roller-coaster and suddenly, you check your email and there’s these support requests that seem like they’re emergencies, and you got to deal with them.
Ideally, you outsource that stuff, but at the same time, you can also just do some time boxing here. If you block off a little bit of time in the morning and then again in the evening to handle some of those support cases, you can prioritize them. If it’s something that’s pressing or an emergency of some kind—obviously, there’s varying degrees of that—but if it’s something where it’s a feature request or some data that needs to be added, you can stall for time a little bit, say, “Oh, I can get to that tomorrow or the day after, or give me a couple of days. That’s probably the most common phrase that I use if I’m on vacations. “Give me a couple of days and I’ll get to that.” And then if it stretches from a couple of days to four or five, it’s not usually a big deal especially if it’s early on in your vacation.
Rob: The first piece of advice that I give a lot of folks once they get a business to the point where it’s making any kind of money is outsource your support. This is relevant to vacationing but it’s more so relevant to the other 45 weeks of the year. That depends on how much vacation you take. This is one of the biggest stumbling blocks I see is, founders hanging onto frontline support for too long. It’s always the, “Well, it’s only half hour a day or it’s an hour a day and no one can do it because my product’s really technical.”
It’s the same objections every time and every time once that exact person—I’ve seen this over and over and over—finds the right support person, doesn’t mean you just can hire anybody off the street, you may need to hire someone with a little bit of specialization, you may need to hire someone with prior WordPress knowledge, you may need to hire someone who, I don’t know, is an audio engineer on the side, and then knows audio stuff on the side if you have audio plugins. There are ways to troubleshoot this.
Entrepreneurs don’t say can’t as much as other people, and there are always objections and there are always hurdles, but once I see founders outsourcing this, it’s always the same realization at the end of, “Oh my gosh, I’ve should’ve done that six months sooner. I’ve should’ve done that a year ago.” If you get nothing else from this episode, if you’re still doing support, find someone to do it and then that, of course, will carry over into times like this when you go on vacation. It will be so much easier for you to do it.
Mike: The next one isn’t so much as a full-blown section. It’s just a word of advice and caution, which is learn from wisdom of having done this exact same thing. Do not push new code within a week or two of going on vacation. Just do not do it. It almost doesn’t matter what the code is because I’ve seen code that I push live a couple of weeks before going on vacation. This happened this past year with Big Snow Tiny Conf where I pushed it out, everything looked fine, waited a week, everything was still good, went on vacation, and the very first day of vacation something came up. It wasn’t actually that code. It was code that was even further back from that and the situation did not come up where that bug ended up surfacing to the point where something bad happened and I had to deal with it. The longer you wait between the time you go on vacation and the time where you’ve pushed that new code, the more likely you are identifying any problems with it and be able to fix them.
Rob: You mean I shouldn’t push new code and then hop on a 12-hour plane flight with no internet?
Mike: If you have no customers it’s probably not a big deal. You can get away with it with certain apps. If they’re not logging in very often, if it’s something where it sends them a weekly report or it’s batched, that stuff’s not as big a deal. But if it’s something they’re logging into and they rely on it for their business, depending on how critical it is in their business, it can be a really big deal and you don’t want to screw with other people’s business.
Rob: That’s the thing. If you have a team that is able to monitor and fix things, then you can, I’ll say, break this rule or bend this rule. You can push code a couple of days before you head off for vacation.
We had an informal rule at Drip almost from the start where we would not push code after—it got earlier and earlier in the day—but I would say, it was around 2:00 PM, so we’d really try to push stuff right around lunch or right after lunch. We had several hours to really see them in production. That was after it was fully tested, heavily unit tested, and all that stuff. Then we really tried not to push stuff on Friday. If we’re going to push it on Friday, we would push it in the morning like it was a 10:00 AM stop.
It always varies. If it’s s typo fix or it’s one little Javascript thing on one screen that could potentially break some minor feature, we’re obviously more loose with it. But if it was some major thing about rerouting the email sending through this different pipeline or if it was modifications to the scheduling, email scheduler, like really big, big deals that could really impact someone’s business. Those things we took with a lot of caution.
It wasn’t again, it wasn’t just about vacation but it was just about having sanity check on. If you have a team that can fix it, you have a little more leeway. But especially if you’re a single founder operating on your own, you need to be very cognizant of not breaking your app.
Mike: With BlueTick, most of the activity and usage is during the week and on the weekends it really drops down quite a bit. Like any major changes, I’m typically pushing them on a weekend because it’s going to impact a much lower number of people. During the week, it’s a bigger deal. I can push something over the weekend and monitor it.
As long as I’m not seeing anything major go wrong with like the smaller number of emails are being sent, it’s not as big a deal. But otherwise, other major changes will go live 8:00, 10:00 o’clock at night, and then I just watch it a couple of hours to make sure that nothing major is going on and check it first thing in the morning to make sure nothing else happened. But everyone’s app is different, so you have to take that into account.
The next category to look at is sales and presales. If you are doing demos of any kind—typically you have some sort of a way for people to schedule those—the first thing you should do is just block off your calendar so that people can’t book sales demos with you while you’re on vacation. There’s times where that’s absolutely necessary or where you may need to do a demo for somebody.
I actually have on my calendar, there are certain unlisted links that you can use that will essentially ignore everything and it doesn’t matter. I use those specifically for situations where I really want to talk to somebody or it’s a high-profile customer, I think that it’s going to be a good fit or I’ve been working on for a long time—those I want to give a little bit more priority to. I’m more lenient with those especially in terms of the time of day and things like that. But you don’t want to just let anybody sign up for your sales demos if you’re not going to be around because then you’re still subjecting yourself to the mercy of whoever is putting themselves on your calendar.
Another thing is using an out-of-office responder. Now, I think this is a judgment call. I’ve gone on vacations without putting those in there just because I didn’t want to having sending out messages that says, “Hey, I’m on vacation,” but at the same time, you may want to do that so that it does set expectations. It depends on how much email you get and what types of people you’re getting that email from.
The next thing you can do to help minimize some of the disruptions to your vacation is to hire somebody who is technical to be on-call. This could probably be a lot less expensive than you might think because you’re not actually paying them if they’re not working. You may say, “Hey look, I’ll give you a couple of hundred dollars to be on-call and if there’s issues I’ll send them your way.”
If you’re going to do something like this, obviously you want it to be somebody you can trust. Either a friend, a colleague, a mastermind group member. Those are all great people to turn to. Or if you have a DBA who’s been helping you manage your database, those are all people who are probably going to be at least somewhat familiar with you and the technologies you use. But you can provide them with at least minimal documentation and training on how things are architected, and what would need to be done or what things impact other things in the environment that they may need to look at if there is a problem. Obviously, you need to give them credentials to be able to login and get access to stuff.
Another thing you can look at is having any sort of a hosted infrastructure can be really helpful in this. If you’re using AWS, a lot of those things are generally taken cared of for you. But if you have your own virtual machines, maybe hosted on Rackspace or something like that, those types of companies do have their own support people where you can say, “Hey, let me turn this over to them,” and then they may require an on-going support contract but that might also be something you look at for a much longer period of time and on an ongoing basis.
Rob: This one’s tough. I think if there’s network connectivity issues or if there’s server issues, and you’re on AWS—some of them assume most people are probably on some type of PaaS, Platform as a Service, like AWS or Azure—then you can hand that over to them. But so much of this stuff winds up being application code. That’s a thing that’s changing constantly. That’s a thing that is vulnerable.
I think getting someone up to speed just for a two-week vacation is going to be really, really tough, even if you provide docs and all that stuff. You know how it is. It is such a jungle when you haven’t been working on an app for at least a couple of months and have some exposure. I can imagine if you had a junior developer who you’d ramp up a couple of months. He or she could handle 20% or 30% of the stuff that came up and then escalate to you as needed.
But try to get someone up to speed, just drop them into an app and be like, “Alright, if these things go wrong, try to do this and try to troubleshoot that,” I think this is a really tough approach. I haven’t heard of anyone doing this, I guess, successfully that hasn’t already have that developer doing it on an ongoing basis, whether it’s a contractor who’s worked on the code from now and again.
I like your idea of the DBA. The Drip DBA who worked with us for years and is still the DBA there. He’s a contractor but he would have been able to dip into the application code a little bit because he had enough knowledge of the app just digging around in there.
Mike: I think there’s a difference between having somebody who is technical enough, is the sysadmin, at the sysadmin level versus somebody who, like, “Hey, I need you to go look into this bug,” stuff like that. I’m thinking probably be pushed off to the side for the most part, especially if you’ve done the due diligence to say, “Okay, we’re not going to push any new application code for a week or two.”
Those things should have ironed themselves out for the most part, but then when you get into things like network connectivity issues or the database isn’t responding, things like that, most technical people, I think, should be able to handle that stuff. If you have somebody who’s a DBA or a systems engineer, they can look at that stuff and start troubleshooting them. They’re not so much looking at the application itself. They’re looking at how do all these moving parts touch each other and why are they not working well together. It’s being able to at least identify that type of stuff.
That leads us into the next section which is using third-party monitoring services. Most of us, I think, have our own logging mechanisms of some kind that are either built into the application or are taking those logs and putting them off onto a third-party service. But there’s lots of other third-party monitoring tools that you can use like Pingdom and uptime.com. Rob, you had a […] in here I’d never used or heard of that one, but—
Rob: That’s Laura Roeders’ new startup.
Mike: Ah, okay. Cool. There’s also PagerDuty and Uptime Robot. There’s another service that I use called Datadog, which allows you to essentially constantly monitor what’s going on your servers and get detailed information about performance metrics of the system’s various aspects of it, whether it’s the database, or the application, or just different processes that are running. I use just that because there’s lots of different things that need to be monitored but conjunction of all these things is that, you can use those to figure out what needs to be escalated. If there’s certain things that cross a certain threshold for you to actually pay attention to it, then those are the things that you would need to escalate to either the technical person that you have, or a support person, or even maybe ends up going to you at some point.
Rob: Our next tactic is to turn off your phone and email during the day. Basically, automate any major escalations to SMS and ignore everything else so, ignore your email. Essentially ignore your support queues based on what we’re saying above is to try to get to the point where you can vacation, enjoy, and be present with yourself, or with your family, or whoever you’re on vacation with, and not feel the need to be checking inboxes all day, and not feel like something’s going to slip through and you’re going to miss it, or not to get a ping, a notification on your phone every time an email arrives.
Because of that, it’s catastrophic for enjoying your vacation. I think it’s a big thing. I’m someone who does not get notifications when emails arrive anyways. I think that’s a pretty bad idea for your productivity but if you do that when you’re not vacationing, then you need to turn that off when you are.
Mike: I turn pretty much all notifications on my phone off. The only one that would end up coming up and surfacing for the most part is certain things coming from the server logs, they pop-up on my phone, and then text messages. That’s basically it. Obviously, phone calls will come through but other than that, nothing is pushed to me in an interruptive way.
The last thing to take a look at is do some technical preparation, create a checklist, and use that checklist to look for potential upcoming issues. On this check list you would want to put things like, “Are my SSL certificates going to expire anytime soon? Does the system have enough space? Does it look like it might run out sometime in the near future? What is the CPU usage look like? Do I need to do any sort of upgrades, or give it additional disk space, or plan for more resource capacity in the meantime that would help me get through that and help mitigate any potential problems that would result from, maybe you get an influx of traffic, you get a bunch of sign-ups and your server gets bogged down?” If you upgrade the infrastructure a little bit, then that would help take care of it.
The other thing you have to look at is things that are completely beyond your control. For example, a DDoS attack. What happens if your application or your website suffers a DDoS attack? There’s other things out there, there’s services like Cloudflare that can help you out with that. You can also build redundancy into the application or into the website itself. But again, these are types of things that could come up but they’re also typically lower risk, unless you have a large enough footprint. Early on, these aren’t the things that you probably going to have to worry about too much but even in the case of a DDoS attack, your customers are probably going to be pretty understanding. It’s not like you did something wrong.
Rob: Yeah and these are things that you want to do anyways. This is stuff that helps if you have it during your vacation but any of these things can happen at any time. I’ve had SSL certs expire on me. I think it’s only been once and it was when I acquired an app, and of course, the contact email for the SSL cert expiring went to the old owner, like their personal email, so I didn’t get any emails. Suddenly, boom on a Sunday afternoon—it was HitTail—the Sunday afternoon, the site isn’t SSL anymore, isn’t secure, and Google Chrome has a conniption when that happen.
I remember calling GoDaddy on the phone, Sunday afternoon at 3:00, I’m thinking, “There’s just no chance. This is going to be a 24 hours or something and man, […] help me right away.” I’m assuming this happens to a lot of people because I think it was within 30 minutes they issued a new cert and I was able to get it.
That would be terrible to happen on your vacation. Like you said, you’re out on, what was the example that you used earlier?
Mike: Like on a roller coaster or like on a Ferris wheel.
Rob: Yeah, or I’m thinking we were snorkeling a few weeks ago in Florida, or you’re out on some safari, or you’re doing something where either you have almost no cell service or you just don’t have the headspace or connectivity to handle this well. It’ll be a stressor and kind of ruin that part of your vacation.
These are the kinds of things to have that check list that you’re probably thinking about on an ongoing basis but really revisit before you head off the grid.
Mike: One thing I found a little bit helpful for things like expiring SSL certificates or even domain name renewals is I actually add them into my calendar and create it as a recurring task that needs to be addressed at some point. That way, I actually use Teamwork for that piece of it but all of them are in there, so that I know that even if I don’t get a notification from whoever that is, I still see it as a task that needs to be taken cared of. If I renew for two years, it’s not a big deal. I can just mark them off. But at least that way, I have my own internal notification that serves as something of a backup.
Rob: That’s a nice way to do it.
Mike: Helps you avoid lost domain names, too, because I’ve had that happen which is why I have that system in place now.
Rob: Totally. Email is mostly reliable and that non-mostly part, the part that is outside of them, the most mostly circle can be pretty bad for domain names, SSL certs, and all that. I think that about wraps it up for today.
If you have a question for us, call our voice mail at 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Out of Control by MoOt, used under Creative Commons. Subscribe to us on iTunes by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening. We’ll see you next time.
Welcome to Startups For The Rest Of Us, the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products. Whether you’ve built your first product or you’re just thinking about it. I’m Mike.
Rob: And I’m Rob.
Mike: We’re here to share our experiences to help you avoid the same mistakes we’ve made. How are you doing this week, Rob?
Rob: I’m doing okay. I’m a little tired. We landed back from California. Landed in Minneapolis last night around midnight, hopped a lift with the kids, and got home, and in bed around 1:00 AM. I’m on Pacific time so I had a couple of hour times change this morning trying to get up. It’s a little slow getting going but overall, really enjoyed our time in California.
I had talked about previously that we’re going to spend some time with my family in the Bay Area. Our kids had a music camp in San Francisco and then we went and saw Sherry’s folks up in far north California.
Overall, it was good vacation; some vacation, some kind of work stuff. The camp isn’t exactly vacation because it’s pretty intense music practice for the boys. Each day we have to be present and stuff. It wasn’t like we could just kick back and sip martinis or whatever.
Mike: You don’t get to send them for the day?
Rob: No. That would have been ideal. It’s less at camp. It’s actually called an institute, the Suzuki institute. You go and it’s five or six hours a day of them playing instruments, and the parents have to be involved to a certain extent, so you’re sitting in there with them. That’s where I was like, it’s some vacation and it’s some not-vacation. It’s fun in the afternoons and evenings when we took the boys and did stuff but otherwise, got there and back unscathe, which is good when five people are traveling and we lug a cello with us on the airplane. In true chaotic fashion we were back, like I said, landed last night at midnight and then we close on our new house tomorrow in Minneapolis. We show up and sign papers in the morning.
Mike: Stick around for a while then, huh?
Rob: I know, yeah. That was the decision. We really evaluated it after I left the Drip a couple of months ago. It was a decision point like, “Okay, we’ve been in Minneapolis a little less than two years and we can move anywhere. That always sounds great in theory but when you have no real ties anywhere for work—we have family in California—but there’s no reason for us to live in any particular city. I shouldn’t say no reason. There’s no requirement that we live in any particular city; becomes a very difficult thing to tackle. It’s a paradox of choice, it’s almost too much choice.
We evaluated going overseas, and then we evaluated all these cities on them, basically the west coast, even Austin, Denver, Colorado Springs, and Sherry threw Hawaii or Maui. Actually, all these sound great but then you look at what it’s actually like to live there. You look at the days of sun per year, you look at the cost of living, you look what the traffic is like, and you read on Quora. You say, “What’s it like to live in insert city?” You can start to get a feel for what it might actually be like and certain ones just right off the bat are just removed from the list. There are just deal breakers that come up.
I love the Bay Area, I grew up there, and it’s the tech hub of the world, so to speak. But the cost of living there is outrageous. It always has been but it’s catastrophic, basically, and the traffic, I couldn’t deal with them. I would like to live in parts of LA but the traffic there is–you know, it’s just on and on and on there. There’s just things that knock it off.
It was a long and detailed conversation but eventually we got to the point where we decided that staying here was the best option of all of them. But it was a good exercise to go through, to arrive at a decision, and feel good about it, and then be like, “We’re going to buy a house.” We figured that this is a 10-year decision. We have kids that are basically 7, 8, and 10. In 10 years, they’ll pretty much all be gone from the house. At that point we will very likely either keep the house and get a second one somewhere sunny or we’ll sell the house and completely relocate.
Mike: I would have completely lost the pool on any bets that might have been placed about where you’re going to live after your time at Drip is over. There’s no way I would have picked you sticking around in Minneapolis, like there is no chance.
Rob: I think a lot of people wouldn’t have thought that and told us that, and frankly, I probably would have lost the pool as well. I would have imagined we would probably move back somewhere in California but there, at a certain point, quality of life and other things factor in. We lived in a lot of places. We visited a ton and we’ve lived in a lot.
Every once in awhile, you find a place where it’s like, “Wow, this is a world class city with world class amenities, but without so many of the problems of other cities that we’ve lived in,” including location, cost of living, crime, good schools, you just go on a list of all the things, access to airport, delta hub, all the stuff. As we looked at all the other cities, it was just so hard to even think about giving up each of the things that we have here. I wouldn’t have called it from the start, either. I think Sherry might have. She knew it was a pretty cool city here. I had no idea before we moved here.
That is the story. We close tomorrow and then we basically move over the weekend. The nice part is the house, it’s only a block away so it’s an easy move. I can move my own guitars and expensive stuff without worrying about movers trucking a dent truck.
Mike: Yeah, I think that would have been the deciding factor for me, it was that I wouldn’t have had to move my stuff. That’s why I would have just stayed there.
Rob: Totally. No, I know. I’ll admit that we used to play factor but at this point, we’ve done it enough that’s it’s like, “You know what, it’s a temporary pain. If I want to make it a 10-year decision, I’m going to make the right 10-year decision. Even if stuff gets broken or even if I have to pay more money to have someone move it. Let’s make the right decision for long term.” How about you? What’s going on?
Mike: I have some potentially good news here. The contract is finally signed for MicroConf Europe. That took forever. I saw it in an announcement a couple of weeks ago and I talked about it on the podcast. We hadn’t had signed paperwork in place yet and the problem that we ran into is we actually had to switch hotels in the meantime. It really sucked to have to start this process completely over which is why things stall for so long. We do have the signed paperwork, was sent over this morning, everything should be good to go. MicroConf Europe will be in Dubrovnik, Croatia this year and it will be from the 21st to the 23rd. That’s Sunday, Monday, Tuesday of October.
Rob: Looking forward to it. It’s going to be fun. Buy your tickets now. Oh wait, tickets aren’t even on sale yet. When do tickets go on sale?
Mike: Within the next week or two. I’m probably going to be sending an announcement over the next couple of days and then give people a little bit of time just to make sure that they can check their plans or whatever. I don’t want to drop it on people say, “Hey, here’s the date. By the way, here’s the link to buy tickets.” So give people at least a little heads-up.
Rob: Cool, that’s exciting. Glad to have that locked in. Looking forward to seeing folks there in a few months.
Mike: You had asked for an update on the local meetup that I did?
Rob: That’s right.
Mike: I think there were five of us who showed up? There were a dozen people or so that I invited. Some of them just couldn’t make it because either the day of the week or it was just a little bit too far based on the location. I try to picked something that was central to everybody but obviously, it’s going to be farther for some people than others. For some of them, it will end up being a two-hour drive and it wasn’t going to happen.
But like I said, five or six of us got together and it was a good time. Everybody was just chatting about what was going on in their business, how they were doing things, and what sort of markets they were going after. I think two of them were there who had previously purchased my book and then the other two had come in. They were both at MicroConf. It was nice to see a little mix of those guys and both of the guys who bought my book, I think were also in FounderCafe as well.
Rob: Oh, cool. That’s always fun, man. Glad to hear it went well. What’s going on today?
Mike: Today, we’re going to be talking about tactics for minimizing disruptions to your vacation. The idea for this topic came up because there was a thread inside FounderCafe that was posted for somebody who was asking, “How does everybody else take vacation because I’m worried about things like DDoS attacks or servers going down and this and that.” I thought what we do is we spend an episode looking at different ways that you can mitigate the risks to any of the things that could go on that could just end up disrupting your vacation and make it more stressful to go on vacation than to actually be on vacation.
Rob: That makes sense. I think this is obviously a concern of a lot of founders and I think in the early days it’s hard to even know how to approach it. I do hear this question now and again. This is from a FounderCafe thread that someone posted in and there was some pretty end-up discussion about it. I think we’ve talked about this before in like a Q&A episode, probably 100-200 episodes ago and I think this warrants rethinking and refreshing everyone’s mind about how to pull this off every so often.
Mike: To dive right in, we’ve broken this up into several different areas of what your business is. I think the first place to start with is the place where you probably get a lot of headaches that come out of it which is support request from either your existing customers or from prospective customers. Because you don’t want those things to go unanswered for too long and you just want to make sure that you’re responsive to people so that they don’t say, “Hey, what’s going on? Why is this business that I’ve trusted for so long with my data and my application, why are they not responding to me?”
Ideally, what you would do is you outsource and then empower your support people to do things for you. The problem is that not everybody is in the position where they even have support people and that’s, I think, is the most common situation. If you’re one person and you got your business running, it’s a SaaS application or something like that, how do you respond to those support request while you’re on vacation? You don’t want to be on a ferris wheel or something like that or just about to get on a roller-coaster and suddenly, you check your email and there’s these support requests that seem like they’re emergencies, and you got to deal with them.
Ideally, you outsource that stuff, but at the same time, you can also just do some time boxing here. If you block off a little bit of time in the morning and then again in the evening to handle some of those support cases, you can prioritize them. If it’s something that’s pressing or an emergency of some kind—obviously, there’s varying degrees of that—but if it’s something where it’s a feature request or some data that needs to be added, you can stall for time a little bit, say, “Oh, I can get to that tomorrow or the day after, or give me a couple of days. That’s probably the most common phrase that I use if I’m on vacations. “Give me a couple of days and I’ll get to that.” And then if it stretches from a couple of days to four or five, it’s not usually a big deal especially if it’s early on in your vacation.
Rob: The first piece of advice that I give a lot of folks once they get a business to the point where it’s making any kind of money is outsource your support. This is relevant to vacationing but it’s more so relevant to the other 45 weeks of the year. That depends on how much vacation you take. This is one of the biggest stumbling blocks I see is, founders hanging onto frontline support for too long. It’s always the, “Well, it’s only half hour a day or it’s an hour a day and no one can do it because my product’s really technical.”
It’s the same objections every time and every time once that exact person—I’ve seen this over and over and over—finds the right support person, doesn’t mean you just can hire anybody off the street, you may need to hire someone with a little bit of specialization, you may need to hire someone with prior WordPress knowledge, you may need to hire someone who, I don’t know, is an audio engineer on the side, and then knows audio stuff on the side if you have audio plugins. There are ways to troubleshoot this.
Entrepreneurs don’t say can’t as much as other people, and there are always objections and there are always hurdles, but once I see founders outsourcing this, it’s always the same realization at the end of, “Oh my gosh, I’ve should’ve done that six months sooner. I’ve should’ve done that a year ago.” If you get nothing else from this episode, if you’re still doing support, find someone to do it and then that, of course, will carry over into times like this when you go on vacation. It will be so much easier for you to do it.
Mike: The next one isn’t so much as a full-blown section. It’s just a word of advice and caution, which is learn from wisdom of having done this exact same thing. Do not push new code within a week or two of going on vacation. Just do not do it. It almost doesn’t matter what the code is because I’ve seen code that I push live a couple of weeks before going on vacation. This happened this past year with Big Snow Tiny Conf where I pushed it out, everything looked fine, waited a week, everything was still good, went on vacation, and the very first day of vacation something came up. It wasn’t actually that code. It was code that was even further back from that and the situation did not come up where that bug ended up surfacing to the point where something bad happened and I had to deal with it. The longer you wait between the time you go on vacation and the time where you’ve pushed that new code, the more likely you are identifying any problems with it and be able to fix them.
Rob: You mean I shouldn’t push new code and then hop on a 12-hour plane flight with no internet?
Mike: If you have no customers it’s probably not a big deal. You can get away with it with certain apps. If they’re not logging in very often, if it’s something where it sends them a weekly report or it’s batched, that stuff’s not as big a deal. But if it’s something they’re logging into and they rely on it for their business, depending on how critical it is in their business, it can be a really big deal and you don’t want to screw with other people’s business.
Rob: That’s the thing. If you have a team that is able to monitor and fix things, then you can, I’ll say, break this rule or bend this rule. You can push code a couple of days before you head off for vacation.
We had an informal rule at Drip almost from the start where we would not push code after—it got earlier and earlier in the day—but I would say, it was around 2:00 PM, so we’d really try to push stuff right around lunch or right after lunch. We had several hours to really see them in production. That was after it was fully tested, heavily unit tested, and all that stuff. Then we really tried not to push stuff on Friday. If we’re going to push it on Friday, we would push it in the morning like it was a 10:00 AM stop.
It always varies. If it’s s typo fix or it’s one little Javascript thing on one screen that could potentially break some minor feature, we’re obviously more loose with it. But if it was some major thing about rerouting the email sending through this different pipeline or if it was modifications to the scheduling, email scheduler, like really big, big deals that could really impact someone’s business. Those things we took with a lot of caution.
It wasn’t again, it wasn’t just about vacation but it was just about having sanity check on. If you have a team that can fix it, you have a little more leeway. But especially if you’re a single founder operating on your own, you need to be very cognizant of not breaking your app.
Mike: With BlueTick, most of the activity and usage is during the week and on the weekends it really drops down quite a bit. Like any major changes, I’m typically pushing them on a weekend because it’s going to impact a much lower number of people. During the week, it’s a bigger deal. I can push something over the weekend and monitor it.
As long as I’m not seeing anything major go wrong with like the smaller number of emails are being sent, it’s not as big a deal. But otherwise, other major changes will go live 8:00, 10:00 o’clock at night, and then I just watch it a couple of hours to make sure that nothing major is going on and check it first thing in the morning to make sure nothing else happened. But everyone’s app is different, so you have to take that into account.
The next category to look at is sales and presales. If you are doing demos of any kind—typically you have some sort of a way for people to schedule those—the first thing you should do is just block off your calendar so that people can’t book sales demos with you while you’re on vacation. There’s times where that’s absolutely necessary or where you may need to do a demo for somebody.
I actually have on my calendar, there are certain unlisted links that you can use that will essentially ignore everything and it doesn’t matter. I use those specifically for situations where I really want to talk to somebody or it’s a high-profile customer, I think that it’s going to be a good fit or I’ve been working on for a long time—those I want to give a little bit more priority to. I’m more lenient with those especially in terms of the time of day and things like that. But you don’t want to just let anybody sign up for your sales demos if you’re not going to be around because then you’re still subjecting yourself to the mercy of whoever is putting themselves on your calendar.
Another thing is using an out-of-office responder. Now, I think this is a judgment call. I’ve gone on vacations without putting those in there just because I didn’t want to having sending out messages that says, “Hey, I’m on vacation,” but at the same time, you may want to do that so that it does set expectations. It depends on how much email you get and what types of people you’re getting that email from.
The next thing you can do to help minimize some of the disruptions to your vacation is to hire somebody who is technical to be on-call. This could probably be a lot less expensive than you might think because you’re not actually paying them if they’re not working. You may say, “Hey look, I’ll give you a couple of hundred dollars to be on-call and if there’s issues I’ll send them your way.”
If you’re going to do something like this, obviously you want it to be somebody you can trust. Either a friend, a colleague, a mastermind group member. Those are all great people to turn to. Or if you have a DBA who’s been helping you manage your database, those are all people who are probably going to be at least somewhat familiar with you and the technologies you use. But you can provide them with at least minimal documentation and training on how things are architected, and what would need to be done or what things impact other things in the environment that they may need to look at if there is a problem. Obviously, you need to give them credentials to be able to login and get access to stuff.
Another thing you can look at is having any sort of a hosted infrastructure can be really helpful in this. If you’re using AWS, a lot of those things are generally taken cared of for you. But if you have your own virtual machines, maybe hosted on Rackspace or something like that, those types of companies do have their own support people where you can say, “Hey, let me turn this over to them,” and then they may require an on-going support contract but that might also be something you look at for a much longer period of time and on an ongoing basis.
Rob: This one’s tough. I think if there’s network connectivity issues or if there’s server issues, and you’re on AWS—some of them assume most people are probably on some type of PaaS, Platform as a Service, like AWS or Azure—then you can hand that over to them. But so much of this stuff winds up being application code. That’s a thing that’s changing constantly. That’s a thing that is vulnerable.
I think getting someone up to speed just for a two-week vacation is going to be really, really tough, even if you provide docs and all that stuff. You know how it is. It is such a jungle when you haven’t been working on an app for at least a couple of months and have some exposure. I can imagine if you had a junior developer who you’d ramp up a couple of months. He or she could handle 20% or 30% of the stuff that came up and then escalate to you as needed.
But try to get someone up to speed, just drop them into an app and be like, “Alright, if these things go wrong, try to do this and try to troubleshoot that,” I think this is a really tough approach. I haven’t heard of anyone doing this, I guess, successfully that hasn’t already have that developer doing it on an ongoing basis, whether it’s a contractor who’s worked on the code from now and again.
I like your idea of the DBA. The Drip DBA who worked with us for years and is still the DBA there. He’s a contractor but he would have been able to dip into the application code a little bit because he had enough knowledge of the app just digging around in there.
Mike: I think there’s a difference between having somebody who is technical enough, is the sysadmin, at the sysadmin level versus somebody who, like, “Hey, I need you to go look into this bug,” stuff like that. I’m thinking probably be pushed off to the side for the most part, especially if you’ve done the due diligence to say, “Okay, we’re not going to push any new application code for a week or two.”
Those things should have ironed themselves out for the most part, but then when you get into things like network connectivity issues or the database isn’t responding, things like that, most technical people, I think, should be able to handle that stuff. If you have somebody who’s a DBA or a systems engineer, they can look at that stuff and start troubleshooting them. They’re not so much looking at the application itself. They’re looking at how do all these moving parts touch each other and why are they not working well together. It’s being able to at least identify that type of stuff.
That leads us into the next section which is using third-party monitoring services. Most of us, I think, have our own logging mechanisms of some kind that are either built into the application or are taking those logs and putting them off onto a third-party service. But there’s lots of other third-party monitoring tools that you can use like Pingdom and uptime.com. Rob, you had a […] in here I’d never used or heard of that one, but—
Rob: That’s Laura Roeders’ new startup.
Mike: Ah, okay. Cool. There’s also PagerDuty and Uptime Robot. There’s another service that I use called Datadog, which allows you to essentially constantly monitor what’s going on your servers and get detailed information about performance metrics of the system’s various aspects of it, whether it’s the database, or the application, or just different processes that are running. I use just that because there’s lots of different things that need to be monitored but conjunction of all these things is that, you can use those to figure out what needs to be escalated. If there’s certain things that cross a certain threshold for you to actually pay attention to it, then those are the things that you would need to escalate to either the technical person that you have, or a support person, or even maybe ends up going to you at some point.
Rob: Our next tactic is to turn off your phone and email during the day. Basically, automate any major escalations to SMS and ignore everything else so, ignore your email. Essentially ignore your support queues based on what we’re saying above is to try to get to the point where you can vacation, enjoy, and be present with yourself, or with your family, or whoever you’re on vacation with, and not feel the need to be checking inboxes all day, and not feel like something’s going to slip through and you’re going to miss it, or not to get a ping, a notification on your phone every time an email arrives.
Because of that, it’s catastrophic for enjoying your vacation. I think it’s a big thing. I’m someone who does not get notifications when emails arrive anyways. I think that’s a pretty bad idea for your productivity but if you do that when you’re not vacationing, then you need to turn that off when you are.
Mike: I turn pretty much all notifications on my phone off. The only one that would end up coming up and surfacing for the most part is certain things coming from the server logs, they pop-up on my phone, and then text messages. That’s basically it. Obviously, phone calls will come through but other than that, nothing is pushed to me in an interruptive way.
The last thing to take a look at is do some technical preparation, create a checklist, and use that checklist to look for potential upcoming issues. On this check list you would want to put things like, “Are my SSL certificates going to expire anytime soon? Does the system have enough space? Does it look like it might run out sometime in the near future? What is the CPU usage look like? Do I need to do any sort of upgrades, or give it additional disk space, or plan for more resource capacity in the meantime that would help me get through that and help mitigate any potential problems that would result from, maybe you get an influx of traffic, you get a bunch of sign-ups and your server gets bogged down?” If you upgrade the infrastructure a little bit, then that would help take care of it.
The other thing you have to look at is things that are completely beyond your control. For example, a DDoS attack. What happens if your application or your website suffers a DDoS attack? There’s other things out there, there’s services like Cloudflare that can help you out with that. You can also build redundancy into the application or into the website itself. But again, these are types of things that could come up but they’re also typically lower risk, unless you have a large enough footprint. Early on, these aren’t the things that you probably going to have to worry about too much but even in the case of a DDoS attack, your customers are probably going to be pretty understanding. It’s not like you did something wrong.
Rob: Yeah and these are things that you want to do anyways. This is stuff that helps if you have it during your vacation but any of these things can happen at any time. I’ve had SSL certs expire on me. I think it’s only been once and it was when I acquired an app, and of course, the contact email for the SSL cert expiring went to the old owner, like their personal email, so I didn’t get any emails. Suddenly, boom on a Sunday afternoon—it was HitTail—the Sunday afternoon, the site isn’t SSL anymore, isn’t secure, and Google Chrome has a conniption when that happen.
I remember calling GoDaddy on the phone, Sunday afternoon at 3:00, I’m thinking, “There’s just no chance. This is going to be a 24 hours or something and man, […] help me right away.” I’m assuming this happens to a lot of people because I think it was within 30 minutes they issued a new cert and I was able to get it.
That would be terrible to happen on your vacation. Like you said, you’re out on, what was the example that you used earlier?
Mike: Like on a roller coaster or like on a Ferris wheel.
Rob: Yeah, or I’m thinking we were snorkeling a few weeks ago in Florida, or you’re out on some safari, or you’re doing something where either you have almost no cell service or you just don’t have the headspace or connectivity to handle this well. It’ll be a stressor and kind of ruin that part of your vacation.
These are the kinds of things to have that check list that you’re probably thinking about on an ongoing basis but really revisit before you head off the grid.
Mike: One thing I found a little bit helpful for things like expiring SSL certificates or even domain name renewals is I actually add them into my calendar and create it as a recurring task that needs to be addressed at some point. That way, I actually use Teamwork for that piece of it but all of them are in there, so that I know that even if I don’t get a notification from whoever that is, I still see it as a task that needs to be taken cared of. If I renew for two years, it’s not a big deal. I can just mark them off. But at least that way, I have my own internal notification that serves as something of a backup.
Rob: That’s a nice way to do it.
Mike: Helps you avoid lost domain names, too, because I’ve had that happen which is why I have that system in place now.
Rob: Totally. Email is mostly reliable and that non-mostly part, the part that is outside of them, the most mostly circle can be pretty bad for domain names, SSL certs, and all that. I think that about wraps it up for today.
If you have a question for us, call our voice mail at 888-801-9690 or email us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Out of Control by MoOt, used under Creative Commons. Subscribe to us on iTunes by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening. We’ll see you next time.
