Episode 110: Why You Shouldn’t Be On Call 24/7

Download iTunes

Summary

Nick and Kai push back on Alan Weiss’s advice that consultants should take client calls at any hour. They cover how after-hours requests compound once you answer the first one, how to handle a genuine emergency when it lands, and why setting availability expectations before an engagement starts is cheaper than resetting them mid-project.

Highlights

  • Nick disagrees with Alan Weiss’s recommendation that consultants take calls anytime, including 2 a.m. His standard response to evening messages goes out at 9:01 a.m. the next day.
  • Kai had a client who sent one after-hours Slack ping at 8 p.m., a quick website question, that became multiple weekly evening requests. It ended only after he explicitly reset the terms of the working relationship.
  • Nick had a real emergency: an A/B test that broke on Android but not iPhone, discovered after he had closed his laptop and was five miles from home on a Friday evening. He troubleshot it from his iPhone standing in front of a Walgreens at Diversey and Broadway.
  • Nick’s follow-up to that emergency was a formal postmortem with key stakeholders: what happened, why it happened, how to prevent recurrence, and an explicit note that losing a Friday evening was not acceptable and should not happen again.
  • For consultants in DevOps or infrastructure: define a separate emergency contact, a phone number, not Slack, with a written SOP for when to use it. Abusing it is grounds for ending the engagement.
  • Nick’s position on evening and weekend access: ‘you can’t pay me enough for that.’ His discretionary time with family is the most important thing in his life.
  • Kai recommends putting availability terms in a welcome packet before work begins. If a client expects 24/7 coverage and you don’t provide it, surfacing that mismatch early avoids a harder conversation later.
Read the transcript
Kai

When we were talking about this topic before the episode, you brought up an area in which we disagree with Alan Weiss. So let’s start with that on the top. Please tell us where we disagree with the mister Weiss.

Nick

Alan Weiss is a famous consultant who is generally good at opinions and has helped us out tremendously. And this situation, I most respectfully disagree. He recommends that you be on call all the time. at your job. So if a client calls you at two in the morning and they have feelings, you’re supposed to give quarter to those feelings. And let the client feel good. Um, no, you really aren’t. And you may have noticed, I’ve said this a few times, like at 9. 01 a. m. , I will reply back with, I hope you had a good evening, because I ignored you all evening and I had a good evening doing not consulting work. I think there is a tremendous work life balance issue with talking to clients on evenings and weekends. And it’s a big Like exceeding of what a boundary is with a consultant. Um now, Alan could be right from the like time period he came from doing consulting. Like he’s been consulting for way longer than I have. And it comes from a different sort of business dynamic and a different set of etiquette and a different set of A different set of norms. And that’s not bad. I’m not saying he’s like old and needs to get brushed away, but rather the particular industry I work in, with the particular kind of people I work in, at the particular kind of age I am and work with. Um, I don’t think that plays. I really don’t. I think that there’s um a lot of issues with work-life balance in our particular generation. And if we’re not taking agency and control of those, Nobody else is going to for us, and we’re going to be miserable. It doesn’t allow you to recharge. It doesn’t allow you to practice self-care, which is essential at this point in time, and probably will remain essential for quite some time. I would love that to not be the case. I would love to be able to oblige a client call in the evening or the weekend and have it not be precedent setting. But it is, and I think that’s extremely dangerous.

Kai

Yeah. The precedent setting is, I think. There’s one client relationship I could think of where it was a small, harmless request at first. Like I was in Slack, they were in Slack, they saw I was online. Thing pinged me and said, Hey, 8 p. m. I know it’s outside of normal hours, but we got a quick question on the website. Can you jump on a call? And little did I know, but that was like the first inch I gave in what became A couple times a week at 8 p. m. or 9 p. m. , an email or a DM and a request to get on a call. And exactly as you put it, that work-life balance slipped, the boundaries that we had set were exceeded. And what it took was resetting the expectations around the working relationship to say, hey, I’m available in these times to help you. I’m not available in these times. And that’s the way it has to be.

Nick

Now the thing that sucks about this is that like sometimes there are emergency things. And so when it comes to enforcing that boundary You just have to convey very firmly that what is happening is not normal or okay, and it’s never going to be normal or okay. So what happened, there was a here’s an example of it. Oh gosh, six or seven months ago, I Made a few changes to an AB test, and it was a Friday afternoon, and I checked them on the website, and they looked okay, and did a couple other things. Closed my laptop and I went to Lincoln Park to run a few errands in advance of a friend’s party. And so I’m at like Diversine Broadway, like five miles away from my house. And I only have my iPhone on me, and it’s like 5:30 p. m. So draft is closed. And normally this is not a problem. I can go to Lincoln Park any time I want, and it’s all right. And there’s not a problem. And uh It turned out that the test broke very badly for everybody on Android and not on iPhone. And I use Apple stuff and I test on like, you know like Android emulators and stuff. But I didn’t think to do that with this test because it was not the kind of test that would normally mandate that sort of QA process. Backfired, fine. So I’m on my iPhone trying to troubleshoot an Android issue without seeing an Android phone sitting in the client’s Slack. They emailed me off Slack, told me that there was an emergency, that there was like a severe thing, they were leaking money. That’s an emergency. That sucks. I’m literally sitting against the Walgreens on Diversity and Broadway doing this. And if you’ve ever been anywhere where I’m talking about, you know that that’s a hell mouth anyway. And I’m all stressed out about the client, and it fucking sucked. I didn’t get my errands done. I got to the friends thing and I proceeded to have my weekend. Terrible end of my week, right? But it was necessary. Like there was an emergency and I stepped up and it was great. When I got back into work on Monday, I treated it like it was like a major outage, right? Like if you’re a DevOps or something like that and like you know, you take down it it’s like if you’re in United Airlines and you a glitch takes down the entire flight booking system for a day and it gets in the front page. Treat it like that, right? This was bad. We can’t unmake it from happening because we don’t have a time machine. There were some human errors that occurred. How do we keep it from happening? And in that postmortem, which involves the top people in the company, you want to make sure that they’re at the table. And if they’re not, you need to write up a document that summarizes everything that happens in this meeting. What happened, why it happened, what you’re going to do to keep it from happening again, overall lessons for the development methodology that happened here. There’s always a broader lesson to be taken away when human error is involved. And what happened that caused the scope to get blown, and why that’s bad and won’t happen again. And you do it in that order. And then the last thing is basically like, I took time out of my Friday night, and that’s fucked up and not okay. I should have been at the Duke of Perth drinking Springbank 10 like I deserve, but I was not doing that. It got fixed and that’s fine. But it’s the normal course of events is Duke of Perth Spring Bank 10. So let’s try and encourage that sort of thing to happen more often. website being down thing to happen less often. And then everybody’s going to be happy because I’ll have space to have my Spring Bank 10 at the Duke of Perth. And you’ll have space to do whatever it is you want with your loved ones. And we’ll all be happy, and the website will continue running and generating money for the business. The end So that’s a long story, but I think there’s a lot of interesting lessons within that. I think there are.

Kai

One question that comes to mind on my side is For situations or for consultants where we aren’t in, say, the backup industry or the DevOps industry, where we aren’t working on the core machines critical to the business. And if we unplug a thing, everything’s going to die. How do you balance the need to be present or almost omnipresent in DevOps or backups or a similar industry with The role we occupy, where it’s not necessary for us to be around. And when something does go down, it is really a rarity when there is a SEV zero incident for something that we work on. Hey, the site won’t load on Android right now. isn’t a normal day-to-day experience in either of our lives. But if you’re doing DevOps, if you’re doing backups, you might be touching core pieces of the infrastructure And you need to be on call at those times. So, if there’s consultants or freelancers in the audience in those industries, I guess, what would our advice be for them? How would we balance The need to enforce those boundaries with the need to be present because this is the specialization you have. You’re working on something that’s mission critical.

Nick

Aaron Powell, well, provide hours and then provide specific things you’ll do in those sorts of situations. Like, does the website go down? Great. Now you get paged. Here’s a specific operating procedure for it. Did the client have feelings and want to wake you up about his feelings? Fuck him. Right? That’s not within the process. And you can’t boy you cried Wolfett either and be like, the website’s down. By the way, what do you think about this cool blog post I saw? Like, that’s not okay. Right. And that’s the sort of thing that is like a harbinger of enthusiasm and you should be grateful for it, but also like not okay. Mm-hmm. Mm-hmm.

Kai

Now I’m very much of the same mind of view. Whenever I onboard a new client, be it a coaching student or somebody I’m working with one-on-one and providing services to, Step one is establishing those boundaries and saying, hey, these are the days I work. These are the hours I work. This is my side and how I’ll respond to your communication. This is my expectations of you. And you know what? We’re both human. So sometimes. things will go a little bit sideways. And that’s okay. And similar to how you, I think, very, very effectively broke down, like, hey, let’s treat it as a severe incident report, a severe downtime. Let’s break down what happened, why it happened, and how we avoided it happening. In those instances where some human element happens, and yeah, you’ve established office hours, you’ve established that you’re available from 9 a. m. to 5 p. m. , but some emergency comes up or something happens, I typically I typically view it as: hey, sometimes these human events happen. You’re laid on a thing. I’m laid on a thing. This thing went sideways for an unknown reason. Shrug humans.

Nick

Shrug humans. Another thing you can do is enforce a difference between emergency off-business hours access and the kind of access they should expect to get during business hours. So you’ll be on Slack between 9 a. and 5 p. m. Central Time and then after that time, here’s a phone number you call when everything is pear shaped, right? Like and you only that’s the red button. You only press the red button at this point. And enforcing it very clearly as the red button and creating an SOP around what happens when you mash the red button. If people abuse the red button. That’s an interesting question.

Kai

I mean, that almost becomes after the start of the engagement, Brown Eminem. It’s it’s

Nick

Oh, yeah, it’s a fireable offense. Like, that’s a you very firmly express what the fuck the purpose of the thing is, right? Like. It’s not okay.

Kai

But yeah, yeah. Yeah. Now, I completely agree with you. And having a couple of friends who work in DevOps, who work in backups, who work in security, who are on PagerDuty. I can’t speak from first-hand experience, but I can speak from very strong second-hand experience of being out on a Saturday night with a friend, you know, at a bar, hanging out. And they get paged because something has gone wrong. And they’re like, weekend’s over. I’m headed to the office. And it sucks that sort of intrusion in your personal life. To jump back to the start of the episode. Really does suck. And unless it’s one of those, we have to mash the red button. Hey, Sev Zero, we need a fix now. We need somebody on this now. Unless it’s one of those types of situations. I think you need to enforce those boundaries with the client. You need to take that proactive step and say, these are the days and hours I’m available. This is what communication looks like. I’m not on call 24-7. And in the situation, exactly as you put it, here’s a standard operating procedure for if and when everything just is on fire and it’s a crisis. This is how you reach me outside of the boundaries that I have set. And I think there’s a sort of a melding of the minds or a I’m blanking on the word here. A process of discussing this with a client and saying, like, hey, does this meet your expectations? Since maybe the client has the expectation that they need somebody on call 24/7 Better to find that out earlier rather than later and say, oh, hey, I do not work in that way. I will not be able to meet that need. And once you say, hey, I can’t meet that need, move forward into figuring out if there’s an alternative need you can meet. Or if that just kiboshes the entire prospect of working together. But raising it earlier rather than later, setting those expectations, letting the client know what those boundaries are, welcome packets are great for this. is, in my experience, a great way to avoid the sort of scope creep that could happen when you haven’t defined your hours or your availability. And that just leaves a client in the position of saying, well, I guess if they haven’t said anything, why not reach out to them, you know, 3 p. m. on a Saturday if I have a question? And then you’re down that rabbit hole.

Nick

Right, right, right. Yes, and I mean, this is a common trope for us is to like set expectations before the engagement begins and set firm boundaries in the middle of the engagement and convey to people that it’s not okay. I think, you know, that’s a common theme you hear on this podcast, but it matters here as well. And it’s If you have evening and weekend access, like you can’t pay me enough for that because the most important thing in my life is the discretionary time that I spend with my family. And I’d have to have firm boundaries around that. And that matters a lot to me.

Notes

 
← Episode 109 · Episode 111 →