Observy McObservface Episode 12: Choking Strangers–Humans, Software, and Priorities with Tim Banks

In this episode, Tim Banks, Principal Solutions Architect at Packet, an Equinix Company, talks about prioritizing a customer-first mentality, how observability = insight, the real cost of developer burnout, and why companies should be more proficient in helping to prevent it.

As far as observability goes, Tim wants to know what's going on inside something, be it a container, a process, or a stack—and he wants to know what's going on before something breaks. Monitoring and alerting typically happen when things are going south, and then you do something about it. Unfortunately, this tends to happen in person-to-person communication as well. We are as much building systems of humans around the technical systems that we are developing. Investing in people and their mental health is essential.

Should you find a burning need to share your thoughts or rants about the show, please spray them at devrel@newrelic.com. While you’re going to all the trouble of shipping us some bytes, please consider taking a moment to let us know what you’d like to hear on the show in the future. Despite the all-caps flaming you will receive in response, please know that we are sincerely interested in your feedback; we aim to appease. Follow us on the Twitters: @ObservyMcObserv.

Jonan Scheffler: Hello and welcome back to Observy McObservface, the observability podcast that we let the internet name and got exactly what we deserve. My name is Jonan. I'm on the developer relations team here at New Relic, and I will be back every week with a new guest and the latest in observability news and trends. If you have an idea for a topic you'd like to hear me cover on this show, or perhaps a guest you would like to hear from, maybe you would like to appear as a guest yourself, please reach out. My email address is jonan@newrelic.com. You can also find me on Twitter as the Jonan show. We are here to give the people what they want. This is the people's observability podcast. Thank you so much for joining us. Enjoy the show.

I'm joined today by my guest, Tim Banks. How are you today, Tim?

Tim Banks: Good. How are you doing?

Jonan: I'm doing really well because you're here. I'm excited that you're able to join us. Do you want to tell people a little bit about yourself?

Tim: Sure. My name is Tim Banks. I am, as of today, my last day as a technical account manager at Mission Cloud. And on Monday, I start as a principal solutions architect at Equinix Metal. Prior to those, I've been a technical account manager at Amazon, and before that, about 20 years of experience in systems administration, systems architecture, database architecture, SRE, DevOps.

Jonan: So just a couple of things.

Tim: Yeah, just a couple of things, here and there.

Jonan: Just a couple of things in tech for a long time but primarily around the systems world, a lot of DevOps experience.

Tim: Yeah. A lot of DevOps, a lot of operations, a lot of keeping things running.

Jonan: Awesome. Are you excited about this transition? This new company sounds fun.

Tim: Yeah, I really am. So I've always appreciated customer-facing stuff even as an engineer. I do think that gaining customer insight, gaining context is super important for engineers, especially when you're talking about why it's important for this thing to stay up. What is the most critical thing to stay up? How do you prioritize things? When everything's on fire, what's the thing you got to get up first? And I know what I think, and I know what the developers think. And I even know what the project managers think, but they're not paying us.

Jonan: Yeah. This is an excellent point. I think what a lot of engineers lose along the way is keeping sight of that customer-first mentality. A lot of tech companies preach this but very few actually practice it. If you listen carefully to the executives when they're stating the goals for the company, it's always "Provide shareholder value then really take good care of our customers." Well, wait, why isn't that the first thing we talk about then if that really is our priority?

Tim: As I said, I think it's interesting when we talk about what is the priority? You always hear about, especially for software development, let's get this feature out, let's get this feature out, let's get this feature out.  And the thing is that your features may be why somebody buys something. But if you want them to renew whatever it is you're selling them. It's not features; it's uptime. Because I can get you all kinds of features in something, but if it falls over every time you use it, then you're not going to pay for that. Features will get you in the door, but uptime is what's going to keep people coming back. And so I've talked about that on Twitter, which I'm very active @elchefe, for anybody who's listening.

Jonan: Say it again so we can now get it clear. What is it?

Tim: @elchefe, E-L-C-H-E-F-E. And I've talked about how a lot of the dev role advocacy evangelism concentrates on adoption, trying to sell to the developer, trying to sell to the CFO, trying to sell to the CTO - we should use this great thing. But operations like the Ops teams, they're the ones that have to deal with it in the end. You can deploy anything you want to. You can turn up anything you want to but care and feeding, maintenance, patching, all that kind of stuff that's all operations. That's the day-to-day.  That's what people end up paying for in the end, month over month. And so that needs to be a big focus.

Jonan: I agree with you 100%. In fact, this is very near to my perspective in dev roles that the users are the people that we're actually here to serve. Developer relations is called developer relations for a reason. If you're targeting an executive buyer -- There are people who hold the credit cards in these companies and I get it. You want to go and talk to the people with the credit cards. Do you know the first thing they're going to? They're going to message their teams and ask what they think of your product.

Tim: They better.

Jonan: And if they think that all my friends -- Tim was just on Twitter the other day talking about your product and how busted it was. Don't buy that one, buy this other one.

Tim: Or what's going to happen is you're going to make this thing. We've got these great terms; we've got this great EDP. We're going to buy this thing that's going to save us a ton of money. And then you have to double, triple your engineering hours to keep it running. And have you saved any money? Probably not. It's costing more, and why? Because sometimes we're focused on the new flashy thing instead of the care and feeding. For me, coming from an operations background, I want those nodes. I want uptime. I want to not get paged.

Jonan: And I think that moving too quickly and adding features for every ask is exactly that. It's going to impact the stability of the platform, which is really what's going to add to the retention of your customer base. I actually want to take a quick aside because I have an interesting fact about you to share in that you are very into Ju-jitsu.

Tim: Yes.

Jonan: And I recently saw on Twitter a picture of you wearing a bunch of medals. How many medals were you wearing?

Tim: In that picture, it's four gold medals from one tournament. So that was a gold medal for my division in the Gi, which is the kimono, the belt, and the pants, a gold medal for Absolute, which is no weight-classes then my division for No-Gi, which is a rash guard and the shorts and then Absolute in No-Gi as well. So that was four different brackets in one tournament.

Jonan: That's incredible

Tim: So currently in the world, I'm ranked number 2 in my division for No-Gi and then ranked number 11 in my division for the Gi in the world.

Jonan: In the world

Tim: In the world.

Jonan: I've heard of the world. It's a big place. That is impressive. And I'm not going to wrestle you when we meet in person someday when the plague finishes up. We're not going to wrestle. I used to do this in college a little bit. I studied Ju-jitsu for a little while. It's very relevant, actually, that there's a Gi and a No-Gi version of this competition because the Gi part, you use the Gi to choke people out and things.

Tim: Yeah, the Gi is a weapon.

Jonan: Yeah, that's amazing. This is really interesting to me. When you are in this Ju-jitsu space—and we spoke briefly about this before this episode but I want you to explain a little bit for our listeners. You were talking about flow state and what that means to you I guess as a break time in your life and professionally as well.

Tim: I have to deal with ADHD, and I have for a long time. I was diagnosed as a child. And I found this out as an adult that I was diagnosed as a child. In Virginia, in the 70s, the medications were not plentiful and they were very expensive. My parents couldn't afford them. So it was good old-fashioned willpower and discipline that got me through school with all the classic symptoms of someone with untreated ADHD had. Coped through as an adult and I found all these coping mechanisms as a way to work around it, but I can never quiet the voices in my head, not the voices I should say, but the threats constantly multithreaded, and it's exhausting. When I start my routine to get on the mat, when I go to change my clothes, I put on my rash guard, I put on my pants, I put on my kimono, I tie my belt. Once I cinch that belt, everything stops. Everything goes into sleep mode and all I'm concentrated on is what's going on the mat. When I bow on to the mat, nothing exists off the mat, not work, not the kids, not the mortgage, nothing, except what I'm doing at that time. And it is refreshing. It is so relaxing to only have to deal with a sweaty 250-pound man trying his level best to kill you.

Jonan: Well, that does sound relaxing. [Laughs]

Tim: That's the only thing I have to deal with.

Jonan: That does sound relaxing to me. I experienced a very similar thing getting into flow with code and my work sometimes. But it is, I think, a difficult thing for me to attain and to maintain in that context. And I'm a little bit envious of you having this. You describe it as just this moment of time, you step onto the mat, done. Threads go to sleep. You're only focused on staying alive. That does sound actually relaxing. I do get it.

Tim: It sounds counterintuitive. People's anxiety would probably shoot through the roof if someone's trying to choke them. But for me, I only have to think about trying not to get choked. It's a respite.

Jonan: Have you ever choked anyone at work?

Tim: I'm not supposed to talk about it.

Jonan: I'm not supposed to talk about that anymore.

[Laughter]

Jonan: There's probably not a whole lot of useful skill transfer between Ju-jitsu and DevOps. But I think actually, when you look at it from the human perspective and the understanding that comes, I think most martial arts kind of prepare you for other aspects of your life. When you're in the workplace, do you think that any of those lessons apply?

Tim: Oh, absolutely. The number one thing that I think applies is dealing with what's important. Ju-jitsu is a chess game. It's misdirection. It's I'm going to do this move, I'm going to do this move. I grabbed your collar a minute and a half ago, and I'm going to choke you with it in another minute. But I need to redirect you five times, so you forget about the fact that I have your collar. And I'm going to put my knee on your belly, and you're going to be super uncomfortable to the point where you're going to forget that I have a forearm across your neck. And when you're going to put your hands down to push my knee off your belly, I'm going to choke you.

Jonan: Wow.

Tim: And so those are the things that when you're dealing with that adversity when that person has their knee on your belly, you're like, this sucks. This actually sucks. It's like you're stapling my navel to my spine. But that's not going to kill me. The hand you have on my collar that's going across my neck that's going to kill me. So as uncomfortable as I am with your knee on my belly, I'm going to make sure that the elbow on the choking hand doesn't hit the ground because if it hits the ground, it's never going to come back up again, and I'm going to die. That's concentrating on what's important, not what's uncomfortable but what will kill you. And then once you remove that thing, then you can deal with the rest.

Jonan: I like this perspective. This is a really interesting analog. Let's take it to the observability space. You have a lot of experiences. Well, first of all, I want to actually hear your perspective on what that word even means. So observability is a new way that we are describing a thing that, in my impression, is not new. This is always something that we have tried to achieve as an industry. And now we have a common way to describe it. It's a little bit buzzwordy, I guess. But what do you think of observability? What is that in your mind?

Tim: It's insight. I need to know what's going on inside something, whether it's a container, whether it's a process, whether it's your stack. I need to know what's going on inside that before it breaks. For me monitoring and alerting is typically when things are going south. Traditionally, monitoring is, oh, this thing went down, and I need to do something about it. That's a facet of observability. But I want to get insight. I don't want to know why it broke after it broke. I want to know what's going on before it breaks. So I have insight into what's going on, and I can take actions to correct these things before it goes sideways.

Jonan: So you can actually avoid the failure by using observability where previously you had metrics, you knew that a thing was broken. There are a lot of companies that can tell you a thing is broken. I could just be pinging your website repeatedly, and then your website is broken but knowing where things fell over or being able to predict that they're about to, that's observability.

Tim: And even more than that, even say, "Okay, well, I know I always run hot here, or I know this always uses a lot of memory. And I'm going to figure out why." And that's an aspect of observability. I'm going to need to figure out why it's doing that. Even if it doesn't break, it potentially could under load. And so now I'm going to feed that back into my software development cycle so I can reduce the likelihood that it's going to do that by taking whatever steps that I've gleaned from the data that I've gathered. So it's not just always going to be sometimes this thing is up, this thing is down, how much CPU is running, but I need to get inside that stuff. I need to get inside the process and figure out what it's doing so that I can iterate on it and make it better and make it more efficient. And sometimes it's not even about whether it's up or down. Sometimes it's hey, I want to save 20% on my AWS bill. Well, how do you need to do that? Well, I'm using a lot of memory and maybe I don't need to. So let me figure it out what's using all this memory, and then I can make the changes on it, so it uses less. And then maybe I can scale some of this stuff down, save some money, hire some more people.

Jonan: This, I think, is really interesting to me because hearing you talk about it -- you're talking about actually getting involved in the development process itself as part of observability. And we often forget, I think, when we're building these systems and maintaining them, that they're humans. We are as much building systems of humans around these technical systems that we're developing. And in many ways, that's the priority.

Tim: Yeah. Like you said, this isn't robots building robots; these are people. And one of the first things that we talk about is that burnout is that pager trauma where if you don't have a stable stack, you're throwing people at it, and you're throwing engineering hours at it; you're throwing sleepless nights at it. And these talented engineers that you have that are brilliant, that are great problem solvers you are burning them out because you refuse to fix the problem that's causing them to be paged at 4:00 o'clock in the morning, ten times. Or you're having them do life-encroaching things. I'll never forget one time at a company, a couple of companies back, where I had to dial into a SEV 1 call from the delivery room of one of my children.

Jonan: Oh my gosh.

Tim: I was already supposed to be on paternity leave, but nope, SEV 1, things are broken. The person who was on call couldn't handle it because there was something else going on. And I got called, and my wife was not pleased with me about that point. But I was like, "Hey, we got to pay for this kid somehow." But those things have real impacts. I left that company not long after that.

Jonan: That was a good call. I am a little bit surprised to hear. I mean, this happens. I have unfortunately been in a position where I wasn't answering a pager for one reason or another from one of my co-workers. If my co-worker was having a baby, I would probably put a little extra focus on it. I hope that there was a great reason. I can see why you left. That's big.

Tim: But anyway, these are things that happen. These are the things that happen. These are the real human costs of it. Or you have engineers that can't take it anymore. If you're burning out your engineers, you're burning out your devs by having them fight fires all the time, by having them be critical response all the time because you're not acting on these things strategically to reduce the number of pagers they get, to improve your systems overall resilience, you're going to burn through people. That retention number is a lagging indicator. The retention numbers will tell you that you screwed something up a long time ago. If you don't have any insight into your teams if you don't have any insight into your people on those teams, you're going to pay the price and it's going to be not only your customers and the stability of your product, but you're talking about the longevity of your company. If you turn over 40% to 50% of your engineering team every six months, that's a death knell.

Jonan: You're never going to get there and not to mention the cost associated with that. I think it's pretty easy for people to forget how expensive it is to hire people and get people. Just sourcing a candidate, and getting them over the line to the part where they have signed the offer, and they're ready to start, and then you have the expense of training them up on the systems and getting them integrated into the teams where they're going to be playing a really critical role for your business. Now look at all of that money and tell me that it's too expensive to dedicate the hours to really embrace observability.

Tim: And when I say observability as a concept, we're not just talking about your stack. We're talking about observability into your team, into the process of software development of keeping your stack alive. If you don't understand or are aware of the sentiment on your team, if you don't understand or are aware of their personal blockers whether it's at work or whether it's in their personal lives, that's important. And you don't necessarily have to know "How much sleep are you getting?" But certainly, if you don't have a finger on the pulse of your people, or of your teams, or their inter-team dynamics, that's a big blind spot for you as a business. And that's observability from an HR standpoint. That's observability from an operations standpoint. That's observability from a software development standpoint that has nothing to do with writing code. And it has everything to do with understanding that these are people, these are humans, whole people with real lives that are building your business. And if you don't have any insight into that, insight to how they're doing and how they're feeling, what the stresses they have are, that's a big blind spot that's going to bite you in the butt one day and it always does.

Jonan: I have a start-up pitch for you in that vein. I think we develop an activity tracker that integrates with New Relic, and we just dump the data in so we can monitor our staff's heartbeats in real-time to detect -- This is terrible. Please, anyone listening, please don't ever build this.

Tim: No. I would honestly rather say their caloric intake today.

Jonan: Oh, that's good.

Tim: If your staff is ingesting 3000 calories between the hours of 8:00 p.m. and 2:00 a.m., you're probably doing something wrong.

Jonan: That's a good sign that there's an issue. When they go home and they eat three gallons of ice cream to get over the pager trauma that they lived during the day.

Tim: Yeah. There's a change you need to make, especially now that so many companies have been remote because of the pandemic and probably will stay remote. It's more important to be able to gather these metrics, to be able to gather insights into your people because you can't observe them. Back in the “before times” when you would have an office to go to, if you were observant, you can look at someone and say, "Hey, I noticed that Jonan is having a string of bad days. He looks really down. Let me talk to him." And he could take some time off or something like that. If you are not in that environment and you're not super comfortable or used to checking on your people in a remote culture, you're going to need some way to track how they're doing to get their sentiment. And I'm not talking about big brother tracking but just something like, "Hey, how's it going? How are you feeling?" Even though it's a happy face or a sad face. If the sad face trends over time, like, "Hey, when was the last time you took PTO? What can we do for you? How about we take you off the on-call rotation next time and just let you have some time off." Whatever it is, you need to do or figure out what it is. And you have a one-on-one with not just them but other folks and see if they have similar concerns. There's a lot of things that people can do.

And you'll see these in big companies. I used to work for Amazon, and they would have all these things where it's like, "Oh, how are we doing this? How are we doing this? There are these surveys you guys can fill out," which I think is great because these things are expensive and they take a lot of time. So most of the smaller companies just forego them because it looks like an expense, and it's not an expense, it's an investment.

Jonan: You're investing in your people and their mental health ultimately, and their ability to do the work, and live a balanced life, and maintain without burnout. You're doing a check-in on mass. I've done many of these surveys. I've always kind of felt that they were a little bit ineffective in that they basically amount to NPS scores. And I'm interested for you to teach me a little bit there because I actually do see the value. I see it. I have a hard time trusting it.

Tim: And a lot of the questions are formulaic, and I'd even say they're leading. Like, please rate your manager. What do you feel? How are your interactions with the team members? And that's okay. Yeah, yeah. Great.  But then they're not asking, "How do you feel? What would you say your stress level is?" One question that I came up with when I was talking to someone else the other day which I thought was a great question -- I can tell you whether you have a toxic work culture by asking you one question. And I'm going to give you this example. It's actually one question. But as an example, if you are or identify yourself as LGBTQ, would you feel comfortable coming out to your manager, to your co-workers, anything like that? As an example. Now, if that answer is no, then you have some work to do as a company, as a culture because that says a lot about you. That says a lot about whether that person feels comfortable, whether they feel safe. And if that person does not feel safe, that's a bias stress level they're always going to have. And that is going to take away from their overall happiness, from their overall comfort, from the number of cycles they can dedicate to what you do, and eventually, the normal cycles they can dedicate to the company before they burn out.

I always feel like everyone has a finite number of cycles. I used to call it the pay to bullshit ratio. How much you are paying me versus how much bullshit I have to endure. And I have a finite level of bullshit I can endure. I can endure quite a bit of it if you're paying me in a ratio that makes it doable. But it doesn't matter how much you pay me. Eventually, I'm not going to be able to deal with your bullshit anymore. But it's not just like that. There's a finite number of cycles I think everybody has with any job, whatever it is. And you can add onto the cycles if you make them happy or you can take away from those cycles very rapidly if you don't. But if you think about that as not just we're hiring somebody and then now all the work is done, we have invested in a person, and we need to make sure that we are taking care of them.

Here's a great example—do you do plants, gardening, or anything like that?

Jonan: Yeah.

Tim: Do you ever just put a plant in the ground and just walk away?

Jonan: It doesn't go great.

Tim: But I expect this thing to give me lots of fruit like an apple tree or whatever. But if you don't do anything to this apple tree, and then you're just going to measure it on the number of apples it produces, but you're not going to do nothing else to it - I'm not going to do anything else to nurture you, to fertilize you, to help you grow, to help you thrive. I'm just going to put you in the ground and say, "Churn out apples otherwise, I'm going to get rid of you."

Jonan: Yelling at my trees does not make them produce more fruit in my experience.

Tim: No, no. But if you care for the plant, if you nurture it, if you feed it, if you take care of it, it will be fruitful most of the time. But even if it's not, the fact that you've nurtured and cared for it, it means you're doing the right things. You're not just going to sit there and put it in the ground and expect it to do stuff just because it is a plant. You're not going to do things like that. And that's a shitty way to do things.

Jonan: It is. And I think fundamentally, this is clearly a thing that we can look at and say is wrong. As human beings, we can look -- psychological safety is a crucial part of any good team. It is absolutely necessary for people to do good, and creative, and consistent work that they feel safe in their teams to be who they are just to exist. And when you frame it in these terms, -- what I really like about this analogy and the one you used previously, where we're using up these cycles, is that it makes sense from a financial perspective. And very often, we need to address that things need to be framed like that to make sense in a world that is largely driven by capitalism today. We have to frame it that way. And it's clear when you use the analogies that you do that this is not just about doing the right thing for human beings, which obviously is my priority. I think that it is right to put humans first, but it's also about the money. The money is driving those decisions.

Tim: Absolutely. When you look at the concepts behind observability, all these things, all these metrics are indicators of whether we're doing the right things or not. Are we hiring the right people? Are we keeping them? Are they happy? How many are we promoting? How many are getting pay raises? Ideally, all of your people are moving up the ladder. And if they're moving out, I just want to know "Hey, are you moving out for a promotion? Are you moving out to get a pay raise? It's fine if you are." That means that we have done the right things to nurture you to be able to be eligible for these. Even if we couldn't retain you here because we didn't have a position for you or your growth path wasn't what you wanted, if you went somewhere else and you got a pay raise, if you went somewhere else and got a better position, that means that we've nurtured you, I think.

Now, obviously, as a company, I want to keep you, but let's be honest—you have a finite number of senior roles, and you have typically more junior roles. If your junior folks are moving up being senior folks somewhere else, you've nurtured that tree. When you have the goals, with observability, you need insights to be able to accomplish something. So I don't just want to gather numbers because what's the point of that? They have to be for something. They have to tell me something. I need these numbers to be able to gain insights on something that I need to do. In software development or in production systems, we're usually talking about uptime, or efficiency, or cost reductions or whatever like that. With people, it's are they happy? Are they productive? If they're happy and they're healthy, and they like it here, the team dynamics are good, that's going to result in better software. And so you can look at how productive they are in their sprints.  You can look at your retention numbers, you can look at your sick days, all these metrics that they have that, in theory, have nothing to do with the software sector itself or they also don't have anything to do with sentiments of the people that work there, but they're all indicators of it. And so when we talk about metrics and observability, like you said before, you have your lagging indicators, and you have leading indicators. The insight inside the system is a leading indicator. And we're only, I think not only, but far too much we're only looking at the lagging indicators or measuring the wrong stuff to be able to try and say, "Oh, we want to up our retention. So we're going to measure these things." Like you said, the NPS scores to these questions that we have, and that's pointless. If you have a system that is memory bound, but all you're doing is measuring your CPU, what good is that going to tell you?

Jonan: Yeah. It's like you're watching a building fall down and then you walk over, and you measure the way the bricks fell and you're like, "Well, yep. This one fell down. Let's build another one." And then that falls down and you measure the bricks.

Tim: I'm trying to remember the data science thing about the bombers.

Jonan: Oh, about the planes where they were getting -- It's a part of the plane. They've got specific armor. They're trying to decide where to armor the wings of the plane. Is this the story you're talking about?

Tim: Yeah. Yeah. There were deciding where to armor the plane and so they looked at the bullet holes in the planes that came back and said, "Oh, well, we're going to put armor here." Like, no, those are the planes that survived. You need to put the armor where it isn't.

Jonan: Exactly.

Tim: It's the same thing. If you're measuring the wrong thing, you're going to get the wrong results. Or if you're measuring the right things and then coming up with the wrong determination on it, you're just looking at numbers. You're not gaining insight. And I think a lot of this, too, like what we're talking about, is the different perspectives of the people making the decisions. If you gather all these insights—and we're going to be real, if you just got a bunch of straight white men making the decisions here without any perspective on anything else, they'd be like, "Oh, well, maybe we need to pay people more, maybe we need to do this." No. Why don't you ask the people who maybe aren't happy?

Jonan: Why don't you go to the people who are upset and ask them what would make their lives better instead of assuming that throwing money is going to solve the problem. Ask them.

Tim: And this would be a great question to ask the HR folks. What do they do with the exit interviews? Because if I'm selling something, I want to talk to the person that didn't buy it.

Jonan: Exactly. And the person who left. That customer, when they leave, we have whole processes that are built into these software companies for when a customer is at risk. We determine a customer is at risk. When a customer leaves, we have long conversations with them about why and what we could have done to do better. Why don't we do that with our people?

Tim: And again, I have a big blind spot myself on what happens at exit interviews. I feel sometimes exit interviews are "Oh well, they're just angry. So I'm going to take it with a grain of salt, whatever." I'm like, "No, no, those are the ones you need to amplify." If you are so mad that you are going to leave an angry exit interview or you're going to rage quit, if somebody says, "I f*cking quit." the first person that I'm going to have on the hot seat is that manager. Why did they get to this point? I want to know why they got to that point. I want to know what happened.

Jonan: How did you not see this coming? How has this not been surfaced within the organization that you were so out of touch with your team that you could not have predicted that we were getting here? What observability is missing from your team management that you were unable to see this coming, right?

Tim: Yeah. Unable to see it coming or even if you saw it coming, what did we do? What things did we not do as a leadership team to give you the tools to be able to prevent it? Because, like I said, people are going to leave, but you want them to leave for good reasons. You want them to leave because they had another opportunity somewhere else. You want them to leave because they want to go out and open their own business. But you don't want anybody rage quitting.

Jonan: Yeah. And I want to reframe the way I said that because I think that you're exactly right. It was almost this blame culture thing like get that manager in there and yell at the manager. But it's not about that. It's about the systems and the tools that you provided that manager and the tools you provided your teams to make work better for everyone. And that I think has a huge parallel with the kind of system stuff we talked about with observability.

I want to ask you to make a prediction if you would because I'd like to have you back about a year from now. I really enjoyed hearing your thoughts on this. I love the way that you draw these parallels. So if you were to make a prediction about observability or the industry generally or how companies may change over the next year in the way that they address some of your feedback just so we can have you back in a year and I can say, "Look, Tim, you're so prescient. You just predicted what was coming."

Tim: I think the biggest thing that the industry will have to do and will do if they listen to me as this seer is to find ways to get insight into people at home. We've got mothers out there who are leaving the industry in droves because of the pandemic.

Jonan: Huge numbers.

Tim: Huge numbers. And it's a goddamn disgrace. We worked super hard.  I'm getting emotional because I know some of my friends that are having to deal with this stuff. We worked so hard to be inclusive to try and get these brilliant people in this industry, and we are failing them and they're leaving. And we're failing them for things that maybe aren't even our fault. If they've got to deal with their kids and they got to do stuff like that, that's not necessarily your fault as a business, but you better deal with it. You better find a way to let these people be their whole people and retain them. That's a talent drain. And if it continues as a talent drain, we may never recover from it. We will literally go back 30 years and not just because we took feminism back 30 years. We will take the industry, and the talent, and the brilliance back 30 years.

Jonan: And the technologies that we're building as a result of that...

Tim: Will be bad.

Jonan: Yap.

Tim: They will be bad. So, gain insight into how your people are doing at home, gain insight into what you can do for them to make their lives as whole people be better so that they can offer you their expertise and their knowledge, which is the whole reason why you hired them. Like I said before, if you don't nurture the tree, you're not going to get fruit from it.

Jonan: You can tell people you want their best work but showing them and helping them provide their best work is what actually matters. It is kind of a dark year, I think, for the world. But hope comes for me in knowing that we're learning some lessons about ourselves as human beings that we've needed to learn for a long time. And I hope that that is a wake-up call for the planet and the industry. And the people at large I think need to see a lot of this as a growth opportunity. It's hard for me day-to-day but certainly, there's hope I try to remember that.

Tim: I think what's important is that we as a civilization, as a society we have made it through some horrendous sh*t, and we've done it all together. And I think we need to make sure that we take this opportunity that we've had where people are at home, where they're with their families trying to make the best. And we've had to radically change how we do things to make this a change for the better even despite the sh*tty circumstances that brought it about. And if we don't do that, we've wasted time. We've wasted resources. We've wasted lives.

Jonan: I agree with you, and I am actually kind of sorry that we're out of time for this episode because I could go on on this for a while. But maybe we'll have another episode soon, and I can get some more of your thoughts. I think that that specific topic of how the pandemic has influenced our industry and our collective mental health is a really important topic that we need to go deeper on. It was really nice having you, Tim. Thank you so much.

Tim: I love being here. I appreciate it so much.

Jonan: I want to remind people again where they can find you online if they want to hear more of these thoughts, and I bet you do. Where can they look you up?

Tim: I'm on Twitter @elchefe E-L-C-H-E-F-E.

Jonan: And we'll throw a link in the show notes. Thank you again, Tim. I hope you have a wonderful day.

Tim: You too. I appreciate it.

Jonan: Thank you so much for joining us for another episode of Observy McObservface. This podcast is available on Spotify and iTunes, and wherever fine podcasts are sold. Please remember to subscribe so you don’t miss an episode. If you have an idea for a topic or a guest you would like to hear on the show, please reach out to me. My email address is jonan@newrelic.com. You can also find me on Twitter as the Jonan show. The show notes for today’s episode, along with many other lovely nerdy things, are available on developer.newrelic.com. Stop by and check it out. Thank you so much. Have a great day