Resilience in Action is a podcast about all things resilience, from SRE to software engineering, to how it affects our personal lives, and more. Resilience in Action is hosted by Blameless Staff SRE Amy Tobey. Amy has been an SRE and DevOps practitioner since before those names existed. She cares deeply about her community of SREs and wants to take what she’s learned over the 20+ years of her career to help others.

In our very first episode, Amy chats with Netflix software engineer Lorin Hochstein. Lorin is uniquely focused on deep incident analysis and narratives, and was drawn into the storytelling approach due to his fascination with how complex systems fail or behave in unexpected ways.

He realized that the valuable data from Netflix’s complex systems was being under-utilized due to shallow post-incident retrospectives and lack of reporting on non-streaming incidents. To combat this, Lorin pioneered the “Oops” write-ups, fostering continuous learning within the organization and creating a deeper level of psychological safety by focusing on the individual incident participant’s narrative of what happened.

See the full transcript of their conversation below, which has been lightly edited for length and clarity.

Amy Tobey:My guest today is Lorin Hochstein, an active member of the resilience engineering community and engineer at Netflix. Welcome, Lorin. How is social distancing treating you?

Lorin Hochstein:You know, we’re making the best of it. My wife and kids are here at home with me and we’re all sort of locked in for the duration. Everyone is right now on Zoom just like I am.

Amy Tobey:Oh, gosh. Well, I hope you have a great internet connection.

Lorin Hochstein: Fingers crossed.

Amy Tobey: To get right into it, you’ve had an exciting change in your career in the last couple of months and you moved back to software engineering. I’m really interested in how all of the work you’ve been doing (the reading and studying and talking about resilience engineering) and how it feeds back into that.

Lorin Hochstein: It’s been really different. About a month ago now I switched from the CORE team. It’s funny because this is the team you used to be on, and it’s now called critical operations and reliability engineering, which I think was the backronym they agreed upon.

Amy Tobey: Gosh, that’s a mouthful.

Lorin Hochstein: Yeah. It’s still called CORE, but they had to figure out what it stood for. I switched from CORE to a software engineering and delivery orchestration team. For about a year, I was doing no software engineering at all, just incident analysis and on-call, and now I’m heads down doing a lot of coding and it’s really different.

On the one hand, in some ways it’s much easier. You have a focus or feature that you’re working on and you just go heads down and turn it out, whereas when you’re analyzing incidents, it’s much more complex and open-ended, in terms of how you talk to people and ask the right questions and write things up. It’s been a very, very big mindset shift for me.

I will say one thing that was kind of nice is … Like I said, the team I’m on is called delivery orchestration. We’re working on a new thing inside of Netflix called managed delivery, around declarative delivery deployment. The service is in alpha right now internally. It’s not critical, but we do have some alpha adopters, and a couple of weeks ago there was a problem with the service.

The manager was like, “Well, let’s do a review.” I was like, “I’ll lead that” and so even though I was involved—I was the one who ended up deploying the code to prod that was problematic—and even though you’re not supposed to be involved if you’re doing these sorts of reviews, it was still really useful. The team got a lot out of it, and it was fun to be able to do that inside a team rather than from outside. Typically, when I’ve engaged with teams around incidents, I’ve been an outsider or on a different team. Here I was inside the team.

Amy Tobey: Seems like you’d have a lot more context for that discussion.

Lorin Hochstein: On the one hand I did. I had a lot more context. I knew more. I could ask smarter questions whereas, typically, coming in from the outside, I’m often like, “Well, what even is this service? What does it do?”

I’ll say one challenge I’ve had going into an incident review meeting, is that they’ll be talking about stuff and I’ll have no idea. I don’t know what that service does, I don’t know what that thing is that you’re talking about, but here, when you’re on the team, you don’t have those problems.

Amy Tobey: It sounds like you’ve shifted the kind of work you do every day quite drastically because you mentioned doing interviews and incident analysis— which is a lot of social and emotional work—  to something that’s kind of more throughput, hard cerebral work. Do you feel that shift in your outside life?

Lorin Hochstein: It’s very different in terms of how I experience the work. I have to say, I found doing incident analysis stuff very draining.

Amy Tobey: You’re kind of like a doom bringer, right? You’re always looking at stuff that’s gone sideways.

Lorin Hochstein: You know, that part I don’t mind. One of the things that attracted me to that kind of work is that I’m really, really fascinated by complex systems failing or behaving in unexpected ways. The part where I get to learn about that stuff was always great and I love 1-1 interviews. I can knock those out. I’m really comfortable talking to people, asking questions like, “What were you thinking at this time?”

But the hard part to me was always, “All right, now I’ve collected all this data. There’s a lot of stuff in my head. How do I like to synthesize that? How do I write it in a document and share that out?” That to me was always really challenging to do.

One of the things that attracted me to that kind of work is that I’m really, really fascinated by complex systems failing or behaving in unexpected ways.

Amy Tobey: Back in my day I found that part of the phase, right? Figuring out what happened and getting all the details loaded into my head was really fun and engaging and went pretty quickly. But then you need to write the report. Did you develop any techniques or approaches that helped you to brain dump what you’d loaded out into something for others to consume?

Lorin Hochstein: What I found that was helpful to me as I went on— and this evolved for me over time since I was on the CORE team —  I would first interview a number of people that were involved in some way in the incident. Then, for each person that I interviewed, I would write up their story from their perspective. Then, if I talked to, say, 15 people, I would have 15 different narratives. Writing each of them separately, I found to be much, much easier for me than starting with, “All right. I need to write the whole thing. I have all these different sources, how do I pull them in together?”

What I would typically do when I would write it up towards the end, is I would stay with one person at a time. Like this one person got paged and then they would be engaged for a while, so I would jump to someone else’s perspective. There was a logical chunk that I could do and I found that to be much easier to work with than trying to just pull them all, integrate multiple peoples’ stories together in one go. Getting them out individually first I found helpful. Those don’t get shared directly with people, just the synthesis does, but I found that I could knock out an individual person’s story but bringing different things together was really hard.

Amy Tobey: Basically your nervous system is acting as the great merge of all the narratives. You have a process where you write each narrative independently to kind of refine that and then later you go write the public document, or within-Netflix-public document, by synthesizing all those.

Lorin Hochstein: Yep, that’s right. First, I’ll start with the sort of synthesized narrative and then after that we’ll pull out things like what were the contributors, what were the mitigators, the risks, but to me the narrative was always like the prime thing. That was the most interesting thing because things that I would pull out are going to be different than things someone else reading it will pull out. Different people will learn different things from it, but getting the narrative right to me was the hardest part but the most valuable part.

Amy Tobey: Do you have any quick examples of how that focus on the narrative helps people get engaged with incident reports and maybe helps grow people or educate them about things that could happen in complex systems?

Lorin Hochstein: That’s a really good question and it’s hard for me to really say for sure, because I don’t know. I haven’t had people come up to me and say, “Hey, you know, Lorin, I really loved the narrative part” because some people will just not even read it. They’re like, “Oh I want to see the summary. I don’t want to read 15 pages of a story.”

But I will say that what I tend to do is to try to pull people into these. There’s a channel that I have in Slack where I’ll excerpt a little part of a narrative and paste it in there and get people engaged. You do see people commenting more around the narrative part than around the contributors and risks and stuff. I may be projecting onto other people, but for me, the story is the most interesting thing, right? Humans are wired for stories.

Amy Tobey: To a fault sometimes.

Lorin Hochstein: We make sense of the world through stories and some of those stories are overly simplistic, like morality tales. Like, you didn’t do the right thing and that’s why you got punished. Definitely we are, for better and for worse, very susceptible to stories.

I’ve always thought that, because humans are wired for stories, that’s the more effective way of transmitting those kinds of learning stuff than through bullet points. We all hate bullet points.

Amy Tobey: Nobody learns from bullet points. You might learn something about the person who wrote the bullet points, but probably not something from the bullet points themselves.

Lorin Hochstein: You’re going to learn, but not what the person who wrote it wanted to teach you.

Amy Tobey: The other thing your approach made me think of was a lot of the science fiction and fantasy I read, especially some of the recent stuff, which kind of takes that same approach, right? Where the author writes the narratives of the characters and then interweaves them as they put the whole story together. Did you ever look to fiction or other storytelling traditions to help inform your style?

Lorin Hochstein: I can’t say how explicitly I thought of that, but I’m a big fan of narrative nonfiction. If you read really good long form magazine articles where they will tell a story about something real that happened, that’s explicitly my kind of inspiration. There’s a good book called “Story Craft,” which is written by a guy I think who was an editor at the Oregonian, which is a magazine I hadn’t heard of until I read the book. But it’s basically like, how do you more effectively use the narrative approach to tell a nonfiction story. It’s a really great book.

Amy Tobey: I need to read that.

Lorin Hochstein: Yeah. I recommend it.

Amy Tobey: Very cool. Another thing I’m really curious about is back when I parted from Netflix, the CORE SRE team was pretty focused on sustainability, taking care of incidents that were coming in and reporting on as many as possible. Since then, it’s become the real dream team for resilience engineering in terms of incident command, incident management, and analysis. I don’t know of another company that’s got such a roster on board. Can you tell me a little bit about how that came to fruition?

Lorin Hochstein: One of the challenges is sort of a gap between when you left and when I joined the team. In that gap, the team when I got onto it was very good at the incident management part compared to when I started at Netflix, which was like in 2015.

Amy Tobey: We started around the same time, right?

Lorin Hochstein: Yeah, I think so. I think I beat you by a few months. I can’t really speak to how they got better incident management. It was probably just experience. When I got on there, they were really, really good at it.

My interest was always the analysis part, and I can say being on what was called the chaos team at the time, I would look over be like, “Oh, all this interesting stuff is happening in incidents, but that’s not what I’m working on.”

I would start in my spare time to dig into it in more detail. I started out by looking through the history of incidents, inc tickets, which we keep in JIRA and reading them through and trying to find patterns. Then I found there was a lot of detail missing. I had a lot of questions I didn’t have answers to. Then I started to see that for some incidents that were passing me by that, “Wait, there’s some questions that aren’t being asked here.” The team was very focused on the incident starting when the alert goes off. It ends when things are resolved.

Amy Tobey: That’s pretty common. Yeah.

Lorin Hochstein: That’s the focus. That’s what an incident is, right? An incident is when there’s an impact to the business until the impact is done. That was their charter and focus. But I was interested in how it got there. How did the system get into that state?

I’ve been reading stuff John Allspaw has been writing on Twitter and his blogs and all that stuff. You couldn’t not be aware of him, right?

An incident is when there’s an impact to the business until the impact is done. That was their charter and focus. But I was interested in how it got there. How did the system get into that state?

Amy Tobey: Right. I think you and I had some conversations about it.

Lorin Hochstein: I think we did. I had read Sidney Dekker’s book “Drift Into Failure,” which I was very influenced by at the time.

Amy Tobey: It’s that one and “The Field Guide To Human Error” that I tell just everybody who asks me “How do I get into SRE? I’m a software engineer” to go read. Read “The Field Guide to Human Error” and then let’s talk, but that will give you most of what you’re going to need to make that next step.

Lorin Hochstein: When I moved onto CORE about a month later, Nora Jones, who was my teammate on the chaos team, also moved onto CORE because her interests had come into the same area. She basically just bought everyone on the team paper copies, like, “Here’s ‘The Field Guide.’” You can find in the bullpen physical copies of the field guide.

Amy Tobey: Did you notice a difference in how people talked and how the incident analysis went after people started reading those?

Lorin Hochstein: Some people are more receptive to it than others. I think change happened, but it happened over time, slowly.

Amy Tobey: As it always does.

Lorin Hochstein: As it always does, right? Lots of root cause jokes happened, but it did change over time. One of the challenges I find with this is like, you can explain the concepts to people and they may even say, “I understand and get it,” but it takes a really long time to internalize a change in the way of thinking and it happens to all of us. I don’t know about you, but for me it took me a lot of really long time.

Amy Tobey: It really did. I remember having discussions with some of the team there about, “Hey, maybe we should be looking at some of this like blameless stuff.” We didn’t have a lot of bandwidth to really dig into that. It was one of those things that, even then, I was still at the very beginning of understanding. Today I feel like I sort of understand it well enough to talk about it and not make a complete butt of myself.

Lorin Hochstein: I think one thing that changed on the team is that … It’s not necessarily just with the team itself. Overall, Netflix has fewer big incidents today than it did when I started. That gave the CORE team a little bit more bandwidth. They went from firefighting to, “Actually, we can expand and be a little more proactive.”

That was sort of a change of the entire organization whereas once upon a time you could say, “Oh, it’s this service that’s always breaking”, and now it’s not like that anymore. It’s not like there’s a problem child. The problems are much more complex and they come from all different places. Of course, CORE got very good at diagnosing smaller issues. They’re good at managing the larger incidents, but because there are fewer fires, they have more bandwidth to do more interesting things.

Amy Tobey: You mentioned that there’s been a broader shift at Netflix. We were just saying how some of this change takes a really long time to soak, so do you have any feeling of how that change progressed? Was some of the analysis work driving that? Was it largely technological changes? I know there were some leadership changes, but the culture is still largely the culture that most people know from Netflix: freedom and responsibility. What do you think shifted in the system at the macro scale?

Lorin Hochstein: I don’t want to give people the impression that the entire company has bought in on thinking in terms of resilience engineering. I don’t think it’s like that. There are still people who talk about doing root cause analysis and things like that. There’s not a huge change and we’re done. There are still lots of hearts and minds to win over inside of the company.

I definitely think there’s been changes in leadership that have affected our ability to do some of this work. Dave Hahn, when he took over the CORE team, was very, very supportive of this kind of work in a way that I think other people would not have been. I don’t think I could have done the work I did if Dave wasn’t around to enable that. Also, higher up in the food chain there was support for this kind of work. When I started, I had to be on-call to do this work, and then at one point I wasn’t any more, but to be able to invest in people solely focused on incident analysis who are not doing other work, that’s a big ask.

Amy Tobey: It’s huge. I point it out to people all the time. There’s a lot that we can learn from Netflix or Google or the other large companies that have this ability to invest deeply into specialties that maybe smaller companies, like the 40 person company I’m at, probably can’t.

Then there’s that impact of organizational change over time. In a lot of organizations, I don’t think you would get the patience to have Lorin sit there for however many months or years doing just analysis and cranking out these reports that don’t have direct business value. How do you sell that to your leadership change, the value of it, to the organization or does it kind of sell itself?

Lorin Hochstein: This is a question I hear a lot. I was very lucky to have worked at Netflix and I don’t know where else I could have pulled this off. I was comfortable changing teams now because there are two people full time, well two or three depending how you count full time, doing this stuff still that I’m not doing anymore. We hired J. Paul Reed and Jessica Devita who are doing this full time.

Amy Tobey: Amazing hires.

Lorin Hochstein: Yeah, and Ryan Kitchens who is straddling, doing on-call work and this stuff. It’s fantastic we’ve been able to have people like this here.

I think it’d be too hard for a company to say, “Let’s go hire someone to do this.” I think you need to show incremental value. I started out on a totally different team and I saw something that was not even considered an incident from Netflix’s perspective. It was a failure of a system where it wasn’t critical to streaming, fallback would work correctly, but I was like, “Oh, but it sounded really interesting.”

I started to talk to people and I wrote out the first “Oops,” which was not called “Oops” at the time. It was called non-streaming incidents.

Amy Tobey: What’s an “Oops”?

Lorin Hochstein: An “Oops” is an operational surprise. Traditionally, at Netflix there’s an inc, an incident. That is the thing that the CORE team would get involved in when there’s significant business impact. But there are all sorts of things that are happening that are interesting and we could learn from but don’t have real business impact. They’re close calls or a failure of a subsystem that’s not critical, but you can still learn a lot.

Amy Tobey: Situation normal.

Lorin Hochstein: The stuff that’s happening all the time, the incidents that are not happening, but still something surprising happened in operations. One of the things I did at Netflix is I started a project called “Oops,” where people self-report these. There isn’t the bandwidth for the CORE team to investigate these, but we encourage people to write them up themselves. Submit an “Oops” ticket and say, “Here’s my narrative of what happened.”

Amy Tobey: How do you get people to do that, though? Did you give them cookies or stickers or something?

Lorin Hochstein: What did I do? There was interest from other people saying, “Hey, what happened here?” Sometimes people wanted to learn from other people’s stuff. One of the ways I started was a team would write an email like, “Hey, we had an outage in our batch processing system here.” When I first started out it was like, “I just want somewhere to reference that.” Because now it’s in an email somewhere and it’s gone. I’m like, “Is it okay if I just create an “Oops” ticket and paste it in there?” They’re like, “Yeah, that’s fine.”

Teams own some service, and if the service has a problem they’ll typically communicate it out in some way. Initially it was just like, “Well, can you just put it here?” Here’s a canonical location for it. And so that really wasn’t too much additional work.

Amy Tobey: It sounds already like a success story for autonomy.

Lorin Hochstein: That’s a nice way to put it. I like that. Then I wrote up an internal doc page, like, “It’s good to learn from surprise. Here’s what we recommend you use. I would recommend you do it.” Sometimes I would ping people, “Hey, can you write an ‘Oops’ for that?” Some people were like, “No, I’m too busy.” I think we only get a tiny, tiny fraction of what’s actually happening because things are happening like all the time. But I’m not looking for completeness because that’s not possible.

What I wanted to happen is people to see value in writing them and people to see value in reading them. It’s still a work in progress, but I think it’s still happening enough that there’s enough success and it still keeps going. One thing I tried to do is give people positive feedback when they submit it to show them that at least I’m reading them.

Amy Tobey: That’s super powerful.

Lorin Hochstein: When I came into my new team, I wrote an “Oops.” I just submitted it today for the one thing that happened a couple of weeks ago.

Amy Tobey: You said you have to get what you can. Netflix is an absolutely massive system, thousands and thousands of components all working in orchestration and connected somehow. Even in smaller systems that we’ve worked on, there’s always something happening that could be interesting if we cared or had time to look. I like that idea of getting the energy that people have to give, as opposed to making it mandatory or this slog where you get these terrible reports that are people just writing what they have to write, instead of writing a narrative that shows off some of the function or the abilities and capabilities of their team.

Lorin Hochstein: I think if you required it as a process it would be much, much less useful. I don’t want people to just fill in a form. I think the only way to succeed in this kind of work is to do it incrementally with people who see the value in doing it initially.

The way to bring it into an organization is to find a few champions. People who are like, “Yeah this is valuable. I wish we would do it,” and enable them to spend a little bit of their time producing some kind of learning artifact based on looking at incidents and sharing that out in a way that other people can read it, see value for it, and ask for it more.

What eventually happened is someone would ask, “Hey, is someone going to write an “Oops” on this?” You start to build an expectation in the culture like, “Hey, what happened here?”

Amy Tobey: I’m so glad you mentioned culture because I really feel like that’s a big component of how it can take off at Netflix, whereas one of the things I’ve noticed in the years since I’ve been there is that that kind of cultural environment isn’t very common. Do you have any feelings for how much either easier or more enabling the freedom and responsibility made that?

Lorin Hochstein: Unfortunately from my own perspective, I haven’t worked at that many companies so I can’t compare Netflix to other companies. But I can say that the culture at Netflix, the freedom and responsibility culture that gives engineers a lot of autonomy, is enormously valuable. I would not have been able to start on this in another company that didn’t have that kind of culture because I started doing this work when I was a software engineer and I could kind of justify it as saying, “Hey, we need to know how incidences really happen so we can inject failures,” but not really.

That’s a general point about resilience. The engineers really need to have autonomy to be able to do the things they need to do, during an incident in particular, but also in general. I think that autonomy is more important than being able to do good incident analysis. If I had to choose between having a company that had more autonomy but we’re not going to do incident analysis, or we’ll have good incident analysis but the engineers don’t have as much autonomy, I would definitely go on the autonomy side.

That’s a general point about resilience. The engineers really need to have autonomy to be able to do the things they need to do, during an incident in particular, but also in general. I think that autonomy is more important than being able to do good incident analysis.

Amy Tobey: Me too. I feel like in the compulsory style, you’re going to get a lot more of what some of us are calling a shallow incident reports where you the vitals, you get the action items out of it, you might get a little blurb of narrative, but you’re not going to get the kind of complete narrative that really drives some of the lessons into people’s heads.

I feel like in the compulsory style, you’re going to get a lot more of what some of us are calling a shallow incident reports where you the vitals, you get the action items out of it, you might get a little blurb of narrative, but you’re not going to get the kind of complete narrative that really drives some of the lessons into people’s heads.

Lorin Hochstein: Yeah, exactly. You’re not going to get the rich details, like the thick description stuff because it’s just a perfunctory, like “I have to get this done because I need to fill this out.”

Amy Tobey: I feel like it’s correlated with the safety required to be vulnerable, to get the real answer of what’s happening. In some places I’ve seen, people are afraid to say, “Hey, I shouldn’t have pressed enter. I typed the command, something didn’t feel right, I hit enter and the system went down.” That’s the kind of story you want to hear, but the environment has to be there for people to feel comfortable being vulnerable.

Lorin Hochstein: Oh, yeah. Even at Netflix, I have to say like, back as a software engineer again, the “Oops” I mentioned earlier, I was the one who pushed it to prod. You think like, “Oh, did I break it? Is it my fault?” Even knowing what I know, that’s a very instinctive reaction.

At Netflix, I’m not so worried about blaming someone else, but this idea of self-blame, I’m still worried about, it’s still a huge factor. Everyone wants to take responsibility for their own actions. Getting people past that, even at Netflix or even especially Netflix, it’s hard to get to say, “Look, I know …” I’m like, “Look, you might want to say like, ‘Oh, I screwed up’ or something, but that’s not useful.” I don’t want you to feel bad.

Amy Tobey: It might be cathartic.

Lorin Hochstein: Well, yeah, there’s atonement for your sins, right? But if we want to learn about the problems in the system, you have to see yourself not as if you did something wrong, but that some aspect of the system that enabled this sort of thing to happen. It’s really hard to make that shift from, “Oh, I did something wrong. I shouldn’t have pushed that button. I should have tested more” to “what are the other factors that enabled this?”

No one ever tries to break things, but like if you don’t identify the systemic … The systemic stuff is how we get better as an organization.

Amy Tobey: Right. It’s so unpredictable. Have you caught up with the Rain Heinrich’s talk about blamelessness where he kind of breaks it down?

Lorin Hochstein: Yeah. Beyond Blameless. I think we were sitting next to each other when he gave that talk.

Amy Tobey: Oh, yeah. Because what you were talking about, right? People will take attribution for their screw ups, but we have to have that trust there that they won’t be sanctioned for it. I know I’m dramatically simplifying, but I’ll get Rain on and he can take me to task some other time.

Lorin Hochstein: I’m sure he’ll be happy to talk about it.

Amy Tobey: It’s getting the two of us to shut up, that’s the problem. While we’re talking about psychological safety and vulnerability, let’s shift gears a little bit from work to talk about how we’re both trapped at home with our children right now.

I imagine that there’s a fair bit of resilience required for … Actually, I don’t imagine, I know that it’s required for us to continue to do this while keeping our children busy and keeping our houses from falling apart. Are you thinking about those lessons learned from resilience at all when you’re dealing with stuff around your home or with the kids? Does it help you?

Lorin Hochstein: You know, it’s funny. I don’t think of it explicitly, but implicitly there’s probably something there. A big part of resilience is about being able to adapt. My kids are a little older; I have a 13 year-old and a 10 year-old. They’re adopting surprisingly well, I have to say. My 13 year old loves being on the computer so it’s not an enormous change in his lifestyle right now.

Amy Tobey: It’s the best snow day ever for him, huh?

Lorin Hochstein: Right? I think he’s interacting more with his friends now when they’re going online and Minecraft and stuff and talking to each other on the phone.

My wife and I have to sort of juggle. We’re both working, and then you have to do all the house stuff and we’re moving next week, which is like crazy. That is going to be very interesting.

Amy Tobey: I mean, it sounds amazing because when you’re staring at the same walls for weeks on end, a move to another house actually starts to sound fun for once instead of this big amount of work that’s grueling and hard.

Lorin Hochstein: It’s some variety, but somehow we have to get all this stuff packed up and hope that the world is functioning enough for that to actually happen. I guess what’s hard is that we tend to get into our own habits, right? I’m a very structured person. When I would go to work, I’d get up at a certain time, have breakfast at a certain time, and go into work and leave.

Now, when you’re working at home and that’s all turned upside down, you have to be able to develop new habits for dealing with that. If you’re too constrained in habits then you’re not going to be able to function well when circumstances change. I don’t know what lesson I’m really taking away other than to be open to change, to adapt to this stuff.

Amy Tobey: I think that is a big component of what’s happening. Everybody’s being kind of pushed to adapt, which is hard, but the outcome of it is that you learn adaptation by adapting. There really isn’t another way to learn it.

Lorin Hochstein: You know, there’s been a lot of talk about whether this will push people to be able to work remotely more once the world goes back to something resembling normal. I think it will. I think we are forced to get better at this now. I mean, I am someone who does not enjoy working remotely, but I’m getting better at doing it because you kind of have to. I think people are adaptable. That’s how our systems work and we are adapting.

Amy Tobey: That’s wonderful. I’m glad to hear that. All right. Well, with that, I’ll thank you for your time, Lorin, and be safe out there.

Mentioned resources:

“Story Craft” by Jack Heart

“Drift Into Failure” by Sidney Dekker

“The Field Guide To Human Error” by Sidney Dekker

‍