Interview w/ Kristen Gallagher (Part 1)
Published 10/18/2017
In today's episode, I talk with Kristen Gallagher about HR. This isn't the boring stuff you think when you first hear the term human resources; we talk about how HR can help teams work better together.
Today's episode is brought to you by Linode.
Linode provides superfast SSD based Linux servers in the cloud starting at $5 a month. Linode is offering Developer Tea listeners $20 worth of credit if you use the code DEVELOPERTEA2017 at checkout. Head over to spec.fm/linode to learn more about what Linode has to offer to Developer Tea listeners!
Transcript (Generated by OpenAI Whisper)
If you haven't heard this before, you don't work in a silo. Whether you work as a freelancer, or you work on a team, or perhaps you manage teams, or maybe you work on your own on a product that is used solely by computers, believe it or not, even you have to work with people. Because here's the reality. Our future self is kind of a different person than your current self. Of course you're not a different person, but you are creating things for other people and sometimes that means for your future self because you don't hold all of this information in your head all of the time. So other people ultimately become perhaps the most important resource that you have. And that's exactly what HR is intended to be, or at least that's what Kristen Gallagher believes. In today's episode, we're going to be talking to Kristen, she created edify. EDU, you can find that at edify edu.com. You're listening to Developer Tea, my name is Jonathan Cutrell. And my goal on this show is to help driven developers become better at what they do so they can have a positive impact on the world around them. On the people they come in contact with on a daily basis. And so I believe this episode is going to help you do that. And that's exactly why we're having Kristen on the show. Thank you so much for listening to today's episode. And let me get out of the way and we'll get into this interview with Kristen Gallagher. Kristen, welcome to the show. Thank you so much. I'm really excited to be here. This is Kristen Gallagher on Developer Tea today. And Kristen, you mentioned in a recent talk that you gave at a conference that you know a little bit of HTML and CSS, but you're not a developer by trade. What is it that you do on a daily basis? That's right. I don't write code on a daily basis. I can if I need to, but that's probably only ones or twice a week. But on a daily basis, I write and build and architect out technical onboarding programs for companies, primarily growing tech companies. So that basically translates to, well, I'm going to butcher it here. That's okay. You have a company called Edify and this company is basically kind of the new way to do HR. Is that an oversimplification? Yeah, no, it's not an oversimplification. I think it's part of it. So I like to let people know that I stay pretty far away from the compliance of HR and that there are legal implications. And I like a lawyer to help people don't trust my compliance and risk management stuff. But what you can trust is the way that I bring in the kind of human element to employ development and to human resources. So what technical onboarding really translates to is going into a technical team like say, a products organization or an engineering or even a sales organization and helping them assess what's all that in their head, tacit knowledge that usually is locked pretty far away or it's buried in confluence or in Google Drive or maybe even, you know, it's in Slack somewhere and they haven't figured out how to share it with folks because they're moving so quickly. But that's the stuff that new hires need to know in order to be successful, right? We are hiring people really quickly, but we're asking them to dive into something, but there's really like not even any water in that pool. They're just diving into an empty pool because there's so much that they can get lost in and we're really not setting them up for success. I'm actually going to use this interview to my own advantage here. I'm going to ask you questions that are going to be useful to me. So I'm the CTO of a smaller firm, whiteboard here in Chattanooga and we have a lot of those same problems, but it's not because we're hiring rapidly. It's actually because we a lot of that stuff that you're talking about, this information that's in our minds is in our Google Drive, we don't use Confluence, but I assume if we did, it would be there too. It's in Slack, it's in emails, it's in conversations on whiteboards, quite literally trying to figure out our org structure and restructure things on a regular basis. And so there's all this knowledge that floats around and my question, I guess it's not really much of a question as much as it is saying, okay, Kristen, if you were to come to a company like mine and you see that we don't have a lot of turnover and we aren't trying to ramp people up necessarily, but how is it that we're still dealing with some of these kind of codifying of some of those same things that you deal with rapid onboarding? That's such a good question, Jonathan. You bring up a really good point that you can pretty much everyone deals with this problem, the Googles and the Intel's of the world down to the one person companies. They deal with this issue because frankly, humans are not machines and we don't code information, the way that a computer might or that we've taught computers to think about information. And then on top of that, the information systems that we have built to hold our knowledge aren't actually necessarily designed with the guardrails we have or we need in order to help us categorize and share that information. And so this might come up again later, but I actually have a humanities background. So my background is in museum education and my very first teacher in that program was his first degree, I guess, was in library science and I always think, God, what if a developer had started out as a library scientist and then maybe we would get organized companies? And so I will answer your question, but I think part of the problem is that the tools that we built are so open air, they allow us to do so many different things that we can't all agree on how we're going to share and categorize and manage information. And that's really what a company is about, right? When you hire even one more person, you still have to process information for them, you still have to share things. And so much of it, especially if you're the founder, this is something I deal with in my company. If you're the founder, you have to share a bunch of stuff that's in your head about the way that the company works. And when you do this thing and when you do that thing, and what are the rules for when you don't follow the rules and all of that. And I categorize that into tacit and explicit knowledge. So the tacit knowledge is the stuff that's in your head and isn't written down anywhere and it's almost second nature to you. And the explicit knowledge is the stuff that you didn't write down. It's maybe on a whiteboard. It's in whatever tool or system that you have, right? Slack, any of them. But I think if I were to walk into your company and say, okay, so you're not hiring that quickly, congrats on your retention. That's great. But you still have this challenge. I would ask you, how are you doing your job today? What would you need to do if somebody wiped your memory, what would you no longer be able to do at your company? And that's how you'll know what the important information is, right? And unfortunately, it's kind of a time consuming process because you have to keep asking yourself this question every single day. It's a constant process because we add new skills and new knowledge to our repertoire every day, right? You write a script and you realize, wow, that really worked. And I'm going to start using that now. But you know, or you learn what the error was and you don't ever repeat that error again. So we have to decide what kind of information we're going to codify and what warrants writing down and how quickly something's going to change too because we want to be mindful that our companies are changing quickly, technologies are changing quickly. So you don't want to build precious things, you know, things that take a lot of time to maintain. That's not what we're going for. We're going for, you know, easy ways to share information. And frankly, I don't care if you just took pictures of your whiteboards and you ordered them and then you put them into a Google slide deck and that's how you onboarded new hires. Totally fine with me. It's not the most polished, but it gets a job done. That is so interesting. I love this idea of wiping my memory and, you know, what is it that I need to learn to be able to do my job? And some of this actually, you know, and I think this is kind of the misconception of HR, old school HR is that, you know, HR comes in to clean up the mess and cover, you know, cover the company in bad scenarios, right? And like create as, yeah, and create as much of it like a smooth process for new people coming in and a smooth process for people who need severance, right? And like the ins and outs, all of that is HR. But the reality is, you know, a lot of this stuff, especially for, well, certainly for our agency, I don't know especially and necessarily, but certainly for whiteboard, a lot of the things that you're talking about are greatly influenced by our business model, right? They're greatly influenced by values that we hold as a company, for example, you know, we don't really codify every single language that we, that you need to know to be able to work at whiteboard, right? We don't have that's not something that we've created, you know, prescription for because so many things are changing so often and by the time we've created that prescription, the prescription needs to be rewritten, right? That's something that we kind of hold as a value at whiteboard is that we're constantly evaluating and using new tools. So perhaps it's the evaluation process that we would need to codify. How does that work where, you know, these companies are constantly changing. How often are you, you know, kind of revisiting because you said you're doing this every day. How often are you revisiting some of these major pieces? I, it's a really good question. I really recommend that people put in perpetuity a note on their calendar, an actual session with their fellow managers or themselves if they're the only person, but it becomes more imperative to do it as, you know, as your company grows. Recorder and sit down and, you know, go through what you have developed for your onboarding and, and I, I do something with companies called a touchpoint matrix and it identifies, it's really just a spreadsheet, it's not fancy at all. And line by line, we identify all of the things that a new hire in a specific group would need to know to be successful. And that's the document that we update every quarter. So they've just got it on their calendar, they, they follow it, they know the way to do it. And there are different columns in that document that allow it to be really easily updated. So you've got a column that says, you know, something like parent knowledge. So for example, let's just pick something like professional expectations. So within professional expectations, you might have an expectation that your new hires need to be on page or duty. And within that, they need to know exactly what the process for page or duty is. How do I escalate something or what do I do when no one's answering the phone or what do I do in this case, right? But maybe that changed last month and, you know, we were not doing the same escalation path or the SLA is different now. So let's go ahead and update that, right? And the other way that you can have things updated is you can build even a really simple onboarding plan for your new hire, like a one page on onboarding plan. And one of the things you can have in there for the new hire to do is go through documentation and flag what looks confusing or flag what looks updated because they've got fresh eyes, right? And they can say, so I was just in that stand up and they said that this was the process. But this, you know, piece of documentation we have says it's this. So can I go ahead and update that, you know, and that's some really easy fix. You know, that's, it's super important. I want to kind of hover over that for a second because you said, something that I think a lot of companies take for granted is the value of the new. And we wanted, we want to rush past that and get to, we're just trying to get you experienced so that you can become valuable. And unfortunately, you know, if you're, if you're a company that's doing that kind of thing, if you're rushing, trying to move as quickly as you can and pushing some one of your new employees past their questions, right? And just kind of pacifying them to the point where they finally get it, right? This is, this is way too common. Unfortunately, it is. Then what you're, what you end up doing is, you know, all of the value of that new, what you're saying, those fresh eyes, all of the value of a kind of an unbiased perspective is pushed away. And instead you're trading it for, you know, this, this kind of training approach rather than learning. And these are two different things. Right. If you're training, if you're training the employee, rather than learning from them, right? It needs to be both, both things need to happen. Yeah. The employee has to learn. They have to ramp up. They have to understand new things about, you know, their job that they didn't understand before they walked in the doors. That's, that's one side of it. But the other side of it is, if you want to become better as a company, if you think that you've arrived and you've figured out HR and everything is done and you've wrapped it up, you put a bow on it and, you know, you have no more work to do, then unfortunately you're going to get left behind in a lot of different ways, right? Oh, you are. This is something that's constantly changing, constantly changing. So I really love that you brought that point up that, you know, new people, new fresh eyes, if you're not listening to them and perhaps in ways that you're not listening to your other employees, right? The other employees have different biases and they have different perspectives, still important but very different. So absolutely fantastic point there, Chris. Yeah. I want to, you call something out that I really think is crucial that there is a difference between learning and training and I really, we call it the T word and we don't use the T word because you train a dog, right? And I don't want to train employees that way, right? I want to invite them into a process that makes sense for their learning pattern and the way that they're going to take in information and exactly what you said, we want to design ways for them to engage that allow them to offer critique, offer insight, right? Because you went through this whole rigour moral of hiring them, you must think that they're valuable, right? And so you're totally right, we shouldn't, you know, be rampant, you know, we shouldn't be optimizing for the shortest possible time to productivity, we should be optimizing for them to share the expertise that they have to optimize the company together as a group and we should be optimizing for sure for them to learn that information but knowing too that we lose the value of a new person if we sort of acculturate them completely. Today's episode is sponsored by Linode. Imagine that you're doing your budget and, you know, you run across a line item that costs you $5 a month. What would you expect to get for $5 a month? Typically the answer is not much, right? There's almost nothing that I can get for $5 a month but Linode is breaking that mold for you today. You can get a one gigabyte Linux server for $5 a month. This is by far the best deal that I've been able to find at least on the internet in terms of dollar per gigabyte of RAM. Linode is at the top of the game so not only can you get a one gigabyte of RAM server for $5 a month, they also have high memory plans and these are even better dollar per gigabyte ratios. You can get 16 gigabytes of memory for only $60 a month. Of course Linode also offers a $10 a month plan that's two gigabytes of RAM and that's probably suitable for most applications. Most web applications that you're going to build especially in a startup phase in the early days. You're probably not going to need to scale beyond something that requires more than two gigabytes of RAM. On top of that, you know, Linode servers are built on Intel E5 processors which means they're very fast and they have internal networking between these servers. It's built on a 200 gigabit internal network. So you could spin up, let's say two or three, Linode boxes that are connected to each other. They're all built on Intel E5. You get six gigabytes of RAM for example across the whole thing, but you also get the ability to do node balancing. And you can use Linode's built-in services for that as well. They have a node balancing service. So all of this stuff is incredibly affordable and on top of that, Linode has incredible customer service. You can even get access to 24-7 customer service. That's something that Linode prides themselves on. Tons of stuff here for you as a developer. And you know that Linode supports developers because they've been supporting Developer Tea for a long time and they're part of the reason that you're able to get these episodes three times a week so consistently because Linode is helping us keep this thing running. So go and check out what Linode has to offer. They're going to give you $20 worth of credit towards any of these services. Head over to SpectadoFim, slash Linode and use the code Developer Tea2017 if you want to get $20 worth of credit for free. Thanks again to Linode for sponsoring today's episode of Developer Tea. I'm trying to think of companies that do this and the thing that comes to mind over and over is, you know, my dad was in the military. And you know, military culture is that, but it's partially, you know, it's not intended to operate the same way that a company is. And I think we had this wrong, and perhaps it's built by our education system or, you know, there's a variety of things that kind of put this in our minds that it's our job to kind of create workers, right? But if you, you know, as a person who's leading other people, you're probably going to start hearing complaints like, for example, I feel like a cog. I feel like I'm kind of just playing a role. I'm just a part of the machine and I don't really, I don't feel appreciated and don't feel like I'm growing, I don't feel like I'm contributing very much. And then I'm replaceable, right? Yeah. And in those scenarios, that's where you start having really high turnover. That's where you start having a lack of innovation in your company. People are essentially, you've just tried to replicate yourself and done a pretty poor job at it because it's impossible to do. It's so true. And I'm just talking with a client today about retention and turnover and, you know, in their case, it is related to the lack of a clear development path and a lack of an appreciation from leadership of their more junior devs. And, you know, there are times, so many times in our companies where we don't have the head count, you know, approval or we don't have the finances to do it or for whatever reason we're not able to actually move someone along in a promotion path. But there are a lot of ways that we can kind of try to give them a development option without promoting them, for example. So let's say that you've got, you know, a new hire or somebody who was a new hire a year and a half ago and you're finally ready to hire another person that that most recent new hire can be the buddy for the brand new hire, right? That's a development path that is really kind of understated, but it allows that kind of older new person to flex their own mentorship muscles or their pair programming muscles or whatever it is that you want to test them with. But that's an option too. And I think that onboarding can be that kind of stand in. I, well, I don't want it to be a stand in, but it can be a way to leverage your employees knowledge, right? And it's just managers sitting in a room and thinking, oh, you know, what do people need to do to be successful here? It's the people who are actually kind of boots on the ground doing the work. Yeah. I've said this to developers many times before, probably on this show and certainly in person. Usually the people who are going to teach you a particular skill the best is someone who is just beyond your skill level, right? And this happens to be so, I mean, it really, so you have the opportunity to be mentored by somebody who is significantly more experienced than you, right? That's a valuable opportunity. But most of the time, if you're talking about specific training, I'm going to use the word T unfortunately, let me back up. If you're talking about guiding someone and helping them learn a particular set of skills, then the person who just learned those is more familiar with the learning space itself. They may not be more familiar with the execution space, but they're certainly more familiar with the learning space. And so they can empathize a whole lot better with the person who's learning it. You know, I've talked with developers who know, for example, a particular language and they've been working with it for a very long time. And there's a big knowledge gap between me and them. And so setting someone up, you know, to be mentored by somebody at a career level, then certainly experience makes sense, et cetera. But if you're creating pathways for learning between developers, for example, I would also agree with Kristen here. I recommend, you know, having somebody who's an intermediate level developer, teaching the beginner level developer and the more advanced teaching the intermediates and certainly not jumping, you know, major jumps between those two. Yeah, there's neuroscience to suggest that that's true. You know, there is a lot of value in someone who has just failed and just succeeded, right? Because they're really fresh with what didn't, didn't work. And you know, somebody like you said who's been doing it for five or ten years is going to forget the shortcuts. They're going to forget the things that they tried that didn't work. That's just how our brains work. We kind of get this amnesia about things that were hard. And somebody who's just learned it will be able to share those with you. Yeah, it's distant memories for me. And, you know, I can't intuit the things that are going to be difficult for someone who's going through it now because it's hard to put myself back in that position. That's absolutely the case. Yeah. So, I'm going to ask you to do something that I didn't ask you to prepare for. Okay. So, this would be fun. I'm going to ask you to kind of give me as a manager and kind of a technical manager because we have some of those listening and people who are aspiring to become, you know, to kind of elevate to that position. I'd love to know maybe two or three kind of, you know, never break these rules kind of things that I can do to best set up my team to work with other teams. I know this is something you're passionate about, empowering people to work better with other people. So, do you have two or three just kind of, you know, I won't call them rules again, but I will say kind of give them a label of rule. Yeah. This is a great, I'm excited about this. This is going to be really fun. So the first thing that I would say is that, and I don't, I don't know if it's a rule or it's a principle or what it is, but I want you to be really mindful of how your team works and agree with everybody on your team. This is how we communicate amongst each other. This is how we manage process, whether it's codified or not, and that's okay. We're not passing judgment on, you know, whether or not you have it written down or, you know, a whole workflow in JIRA or something, but, you know, what is the process for doing whatever it is that your team does that makes it, you know, I guess the business value of your team? How does that work? Because you need to know that in order to communicate with another team, right? Because the other team doesn't necessarily understand your world. They're working in a completely different space. Even if they're also another technical team, they're working on a different problem space, right? They're maybe doing different things and different tools. And so they're not necessarily speaking the same language. So that first one is work with your team to understand and agree on how you work right now. And there's so many benefits that'll come from that anyway that they don't have to do with inner team communication, just even, you know, laying it out for each other is really helpful. And it's easier to do this when you're small, but I think it gets more important as you get bigger because that every time you add a new person, you're kind of like adding food coloring to a glass of water, right? You are not necessarily changing it in a negative way, but you are changing it and things are getting diluted. So it's important to have that. So that's number one. Number two would be to seek first to understand and then be understood. So when you have a request come in from another team, give me an example. What's something that comes in from another team? Hmm, that's a great question. So just today we had a major, unforeseen kind of software bug. And the request came down kind of from a more of an executive level because it's an urgent issue. And so we need this to be fixed as soon as possible, kind of an all hands on deck kind of thing. Okay. So I'm going to interpret all hands on deck to mean that multiple teams had to work together to get this fixed. Is that right? Well, it was certainly multiple people on the development team. It was almost solely a development issue. So I wouldn't say that multiple teams came together. It was more focused. So I guess to be fair, I was involved as a CTO and that would put me on a different because I'm in an executive position. So that would be at least two teams are involved. Sure. So I might embellish this a little bit more based on my experience. Yeah, sure. Let's imagine that you don't have any development expertise and you come from more of business operations or a sales background. And you see that this problem is really causing pain for your customer and you go to the development team and say, this needs to get fixed and needs to get fixed ASAP. So that if we're going back to the principle, seek first to understand, you need to learn how to ask the right questions. So that's kind of sub principle to seek first to understand. And the second sub principle to that is really try to assume good intent, try to assume that everyone is working on the same project and everyone is sharing the same mission. We want our customer to be successful and we know that this is causing them pain. And the reality is that we all have different priorities even in the same company. And that's never going to, we're not all going to be able to align because we have different roles. But I think first trying to understand what the real problem is by asking better questions and being able to say, not just, okay, I'll fix it, but can you elaborate? Can you tell me more about this particular part of the problem or what failed or can we reproduce that part of the problem or did you already try to reproduce it? You know, I see like little questions like that don't always get answered. They don't, they don't always get asked, they should say. So you're asking better questions and then you're assuming that we all want to work together to fix this problem because I think we can get really emotional, especially if we're tied to something that's happening, right? So let's say I, let's pretend that I wrote the code that broke. Well that's, that's going to maybe make me feel uncomfortable in some way at the very minimum that, you know, that I caused a problem for a customer or that it's a really high profile issue. You know, so let's, let's assume that we're all working on this together and we're not passing any personal blame on this and that helps take some of the emotion out of it. So I would say those two things are really big for me and if I could throw in a third one, it's, it's pay attention to how other teams communicate too and try to work on, on their channel sometimes. So if we're all kind of, you know, speaking different languages to each other, then we're not going to get along and we're not going to get things passed through quickly. So I talked about this a little bit in a talk I gave at DevUpStays, PDFs where I said, you know, what are the ways that you communicate right now and how could you onboard other teams into that? And the first thing you have to do though is to understand how that team communicates. So let's, let's say that you were building out a feature that really required you to work with product marketing. Well, how does product marketing ship their projects? You know, do they do it in a completely different process than you? Do they use standups? Do they use Slack? Like do some ethnography, do some research to try to understand, you know, how they're shipping their work and that will help you communicate better with them. You just hit like about 20 different things that I've talked about on this show before and just kind of affirmed a lot of boxes that I check on a regular basis in terms of what needs to be done to solve a lot of this stuff. And I'm preaching to the choir to be honest, or I guess I'm preaching to myself is what I meant to say. You know, the, the, there's a couple of things that you mentioned in there that are, there's so important. One of the things I just did and I did a couple of episodes on this, the traits of a great developer. And one of them is becoming a communications expert. Yes. Okay, so actually studying the model, the various models of communications. And this is so important because developers so often, and not just developers, people in general. So I don't want to, I don't want to target developers listening to show, but people in general so often take for granted that the way they do things, the way they see things, the way they say things, the way they hear things that everyone else does it the same way. Right. Right. And not just, you know, we're not just talking about like a different country, kind of cultural differences. We're talking about next door neighbor, there's a massive jump between how you do things and how they do things, how you see things and how they see things. Because both of you have fundamentally different experiences in life. You have fundamentally different values, right? And so when you bring people together, even if you codify some of those values together, even if you have, you know, shared goals, there's still going to be differences between teams and between people on those teams. And if you can't understand those differences, then your teams are always going to clash, right? If you as a, if you have a development team that you work on and you are focused on optimization, for example, this is a very common one. If you're focused on optimization, you don't want to make any decisions that could possibly negatively impact the user's experience from an optimization standpoint. So you want your application to be fast, you want it to be snappy. And especially for web development teams, this happens all the time. Let's say a client or, you know, maybe a design team or even the product owner, somebody in that kind of role, the decision making feedback role, they ask for something that negatively impacts your optimization standards, right? It's very easy as a developer to demonize that request and to say, well, they don't understand, they don't get it. They don't have the right things in mind. We are not aligned. And therefore, I'm going to look at their request and basically reject it as valid, right? And I'm begrudgingly, I'm going to do what you say, but I think it's a terrible idea. And that's a toxic atmosphere to cultivate. And it's toxic on both sides if you can't get to a common ground and say, this is how we're going to approach optimization together. Yeah, you're so right. And I'm glad to use the word toxic because that's exactly what was going through my mind when you said that because that's exactly what it creates is this, you know, kind of malevolent, like, icky feeling where, you know, I think somebody's stupid because they don't do it my way. You know, and that's a reductive way to think about it. But I genuinely think that that happens a lot where we'll look at a ticket that comes in and say, you know what, that's really dumb or that customer is so stupid. You know, I've heard support people say this before where it's like, well, we just have kind of like stupid customers. You know, no, you don't have stupid customers. You have bad software, you know, I mean, and I don't, I will, you know, say that to the day I die because, you know, your customer is not always right, but they definitely didn't make up their experience, right? And that's just an example to illustrate. But I think we do that internally all the time, you know, why do I have to file expenses this way? It seems so stupid, right? Well, you know, why don't you try being the accountant and see how hard it is to manage, you know, 200 people's expenses? Maybe that's why you have to do it, right? So having a little bit of empathy for the other team, the other person and understanding that their job is just as hard, you know, I think when I onboarded people for a job, not just as a consultant, I would, I loved the days where I had multiple, like people from multiple teams so that we could facilitate discussions about this and say, you know, what do you think people in HR do? What do you think people in marketing do? And we have such bad understandings of what people do every day and how they spend their hopefully eight hours, hopefully 12 or 16, but you know, we don't necessarily know how the other half lives and that would help us ship better products, right? It would help us develop a company that truly appreciated everybody at the company. Thanks so much for listening to this first part of my interview with Kristen Gallagher. In the next part of the interview, we're going to keep talking about HR, but we're going to talk more specifically about onboarding. Isn't it amazing that we can have so little of an idea of what's going on in the other teams around us, the people that we're working with? What is it that they do? Sometimes it's hard to even say what we do. It's hard to articulate the things that we do. So these are important things to be thinking about. I hope you will join us in the next part of the interview. I think there's a lot of really valuable knowledge that Kristen shares in the next part of this episode. Now, I want you to ask yourself a question. If you don't subscribe, are you going to remember about the second part of this interview? My answer to that at least would be probably not. So I would encourage you to make that decision to go ahead and subscribe to Developer Tea whatever podcasting app you use. And here's the trade-off. Here's the pros and the cons. The pros are that you could end up hearing something extremely valuable on the next episode of Developer Tea. You could end up hearing something that Kristen says that totally unlocks a new way of thinking for you or you may find some really important information that you can share with someone who needs it deeply. Maybe you already done that with today's episode. Now the reasons you might not subscribe given these pros is that it takes too long to press a button maybe. I'm not really sure, but I encourage you to subscribe in whatever podcasting app you use if you don't want to miss out on future episodes of Developer Tea. Thank you again to Linode for sponsoring today's episode. With Linode, you can get a Linux box up and running for $5 a month. Just a few clicks. And on top of that, they're going to give you $20 worth of credit. You can use towards, for example, high memory plans or node balancing or really anything that Linode provides. Go and check it out. Spectat FM slash Linode in use of code Developer Tea2017. It's Developer Tea 2017. When you check out. Thank you again for listening to today's episode. And until next time, enjoy your tea.