Christine: [00:00:00] And I think that younger engineers now, they just, they don’t have this trauma from a world where development and operations were super, super separate.
Matty: It’s time for Arrested DevOps, the podcast where we help you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m Matty Stratton, and I’ve got a great guest with me today. But first, a word from our sponsors.
Christine: Chef is a community of professionals practicing DevOps every day. We are making, proving, learning, and shaping the future. We are known for welcoming, encouraging, and liberating others to do the same. We do not talk about change, we do change. Join the community and learn about our solutions at chef.io.
Matty: This episode is brought to you by Datadog, a monitoring tool that helps bridge the gap between operations and dev teams. Datadog brings together system metrics, changes, alerts, and events from over 120 common infrastructure tools such as Chef, Docker, and AWS so that dev and ops teams share their key data and alerts in a single place and collaborate on issues in real time. Datadog is available for a free 14-day trial at arresteddevops.com/datadog. So I’m joined today by Christine Spang, the CTO of Nylas, and we’re going to be talking about her journey creating a welcoming, inclusive, and inviting company culture and kind of wherever the conversation takes us. So show notes for this episode can be found at arresteddevops.com/spang. So Spang, can you start off by telling us a little bit about, about yourself and kind of your, your history in tech?
Christine: [00:01:48] Yeah, for sure. Thanks so much for having me on the show, Matty. It’s great to be on Arrested DevOps. I am particularly excited to be on this show because my background is actually really infrastructure-focused. So while I’m a CTO now and really don’t write any code or spin up any servers or anything, it’s definitely close to my heart to be in the infrastructure community. And I love just being a part of that. So I guess I can take a step back and start at the beginning to introduce myself. I was born in Toronto, but actually grew up in upstate New York because my dad got a great electrical engineering job in upstate New York and kind of always wanted to kind of live the American dream. So I moved to upstate New York when I was 3 and a half. So I’m kind of like a fake Canadian and really am an American with a Canadian passport, which is useful, but I feel like I’ve also lost my Canadian accent at this point. So it’s a secret thing I whip out every once in a while to surprise people. And when I was in school, I was like a music geek. I played the French horn for about a decade and read a lot of books. And eventually at some point I started getting into computer games and through computer games I got into into programming, which ultimately led me to get involved in free and open source software. So I started hacking on Debian when I was in high school. And through that ended up going to MIT because I basically heard that free software came from MIT and I was like, that’s where I want to go. That’s the place for me. And I was totally right about that. Kind of found my people there and I got a CS degree. And my favorite class at MIT was operating systems engineering. So through that and through like the MIT computer club, which is called the Student Information Processing Board, it’s a super mouthful. Like this group was actually formed like decades ago in order to like manage like the timesharing on this like Multics cluster. So it’s got a crazy old name, but it’s basically the computer club. And I met a bunch of really smart people there, and including some people who started this company called Ksplice, which was a kernel engineering company that was doing some really cool stuff for Linux where you could take a source code patch and turn it into a binary hot patch. And then the company ran this service that used that process on all security updates. That came out for the Linux kernel. So I, through basically through my involvement in Debian, so I was an official Debian developer, I could upload packages and stuff like that. I knew this person, Tim Abbott, from the MIT Computer Club, and he was one of the founders of Ksplice. And so eventually I ended up working at Ksplice through that. So that was my first job after I finished at MIT. So I kind of dived into the startup world right away. I got to say my background in free and open source software didn’t really set me up for hacking all of the big company software jobs because I just thought all those people were the man basically. And in college I worked at Some like, I once spent a summer working for this nonprofit called One Laptop Per Child, which was basically trying to create really low-cost computers for kids all over the world to increase computing literacy. And they were releasing all of their software for free because it was a nonprofit. And then I also spent a couple summers working for a small software shop called Best Practical, which is One of the few companies out there that was just like a services organization around an open source product, this ticket tracking system called Request Tracker. So I kind of worked these like random jobs that I got through my network and got really excited about working on kernel stuff. And that’s how I ended up working at Caseplace. And so somehow this confluence of being a hacker on open source software stuff ended me in the startup world. And so I spent about 3 years working on Ksplice. One of those years was independent and 2 of those years were at Oracle because the founders sold the company to Oracle and Oracle ended up basically taking the product and rolling it up into their Oracle Unbreakable Linux offering and kind of porting the technology to a few other products that they had internally. So I got a bit of a taste of like being at a really big company through Oracle and had a bunch of time to get really into rock climbing, which was great. No regrets. I still do it. It’s super fun. And kind of towards the end of my time there, I was trying to figure out what to do next. And it was just like a good time in my life to kind of jump off the deep end and kind of do something that might not work out at all. I was still living in Boston at the time and had a lot of my kind of friends and network who were like slowly starting to move away. It was, you know, almost 3 years after I graduated and people were trickling on to other places and kind of wanted to check out being somewhere else and didn’t have a compelling other place to be. So there was really no reason not to kind of try starting something new though. I wasn’t one of those people that when I was a teenager or anything was like, I’m definitely going to start a company someday though. I do feel like I’ve always had a multitude of interests and I think that I can make a pretty good bridge between different cultures. So kind of looking back in hindsight, it was a good fit for me to kind of come from a hacker background and then start a company.
Matty: [00:08:53] Cool. So you’ve been working, you founded Nylas about 5 years ago?
Christine: Yeah, it’s crazy. It’s almost the, almost exactly the anniversary of our incorporation actually. So when I moved to California, I gave notice to Oracle on August 1st. So I gave them 2 weeks. So I pretty much started working around August 15th, 2013. And we incorporated the company, me and my co-founder, Michael. It was within the next like week or something like that. So. Yeah, time flies.
Matty: Can you kind of tell us a little bit about what Nylas does from a product perspective?
Christine: Yeah, totally. So the basic thesis behind the company is that email has not really had a lot of innovation in the product space over the last while, basically since Gmail came out, because over the last 5 decades or so that email’s been around, it’s just gotten so complicated to develop with and to integrate with. That people have stopped building new things with it. So the kind of reason for Nylas to exist is to make it much easier to develop things that integrate with email and also with contacts and calendar in order to allow people to build new products that make people’s lives easier. So email is pretty much the lingua franca of business. And its usage, despite many cries of email is dying or email is going to be replaced by such and such new messaging technology, its usage has actually continued to grow year over year. So unlike technologies like SMS, which are in fact decreasing in usage, email continues to grow and grow. And we need to be able to glue email to other things. People want specialized tools, and the mission of Nylas is to empower people to build those tools, to combine the data in email with the data in other systems, and ultimately to also get more value out of all of this data that we have built into our communication systems.
Matty: [00:11:12] So when we kind of— I’d like to kind of get some understanding or maybe a little bit of some of the things about building a company, starting with you and your co-founder. Getting to today when you’re building about, you know, we talk a lot about the culture of an organization and what are some of the things that you’ve done to kind of make Nylas the place that you, that you wanted it to be as a founder?
Christine: Yeah, I think there’s like a lot of different pieces of this. One is just like, like having spent time kind of like writing down what our values are and like using that as a way to kind of share and replicate those values. So I guess we didn’t do this right away, and I don’t want to dig into it super much, but for example, I can’t really beat around the bush that my original co-founder who joined the company is not with the company anymore. And there are cultural reasons that are related to that. And I’m really happy with the company where it is today. But how we got there has involved a lot of learning over the past 5 years. And one thing that we did in conjunction with my co-founder leaving was writing an actual company handbook and publishing that and using that as a way to reflect on what we wanted as a company. I think that’s been really valuable. I think in the early days we did spend some time thinking about this, but it was more kind of unsaid. And that’s possible to do when you’re just a few people in a room, but we’ve had to get more mindful and intentional about it as we’ve grown the company. So for example, in the past, 8 to 10 months or so, we’ve doubled in size as a company. And I think that you can kind of afford to run off of a shared understanding that is not necessarily written down when you’re small and not changing that fast. But when you start to kind of scale up and add lots of new people, you need to communicate with those people and tell them like what you want to be about so you can attract the right sort of people that are compatible with like the vision that you see for the company. And also like just, you know, people are not always on the same page about things. So you have to have conversations in order to like define the right words to be talking about what you want as a company. So I can dive into kind of more specifics and more details.
Matty: [00:14:12] Yeah.
Christine: But I’m curious what, what kind of resonates as interesting about that from you.
Matty: Well, and one of the things that I’d be curious about, again, and like you said, when you kind of start as a smaller organization, there’s kind of unstated things, or you kind of have a similar vibe. And as you grow, there’s more formalization or just more intentionality around it. Can you tell me a little bit about what some of the values and culture that you’re that you have at Nylas that’s important to you?
Christine: Yeah, so I think kind of overall, like, my personal leadership style is rooted in trust and listening. And I think that, like, when you’re creating a company, it’s true that, like, a lot of culture and a lot of values is set from people who are kind of in positions of power at an organization. And Like it or not, if you start a company, if you found a company, even if you don’t have a hierarchy at that company, you as a founder have more power than other people in the company. So it’s kind of this thing where if you don’t have an explicit structure, there’s still an implicit structure. So just keep in mind that as a founder, you are the leader of the company, whether you say so or not. And there is a lot of things that you can instill in your team just by living and embodying them. And one of the things that’s most important to me is to really truly listen to people, to focus on empathy, and to try to understand where people are coming from. I think that this results in trust being built, especially once you achieve understanding of where someone’s coming from and what someone needs, and you can figure out what you can do to follow up on something if it’s a problem, that builds trust over time. And I think that if you have trust in an organization, that allows you to get over a lot of things that can be really hard if you don’t have trust. So to me, like the foundation of like a great culture and a great like leadership team is trust.
Matty: [00:16:45] And what are some of the things— so we talk about building high-trust cultures. What are, you know, we’ve talked about kind of having some implicit things and things like that, but what are— I know we talk about how you can’t really just sort of define culture, right? You can work towards the behavior that you want, right, and incentivize. And so what are some of the things that people can do in your mind to kind of build towards a high-trust culture?
Christine: Yeah, I mean, it always starts by, by like demonstrating by example. You know, if you want people to like show up on time for meetings, be on time to meetings yourself. If you want people to trust people, then you can demonstrate that by, for example, giving other people responsibility and not interfering with their execution of doing that and checking in on progress and connecting that back to goals, but not micromanaging. I think that’s definitely one thing that can undermine trust is essentially giving someone responsibility for something, but then not actually allowing them to own that thing. For example, if you had someone ask someone to write a blog post about some recent thing that they built or technology that they worked on, and then when they brought that blog post back to you, you just rewrote the whole thing. That undermines trust because you’re not allowing them to share their voice. If they put a lot of work into it and try to make it really polished, then people want their writing to reflect themselves. And doing things like that is something you can do to undermine trust. I think one thing that’s really big is consistency also, like just saying the same thing week after week and being consistent. And like, if you are changing your mind, like being upfront about the fact that you have changed your mind and like being clear, like what, why the reasons are for that. Like if someone’s switching directions like all the time, it’s really hard for a team to like follow along with that. And like you can’t really like dive into a goal if like you feel like it’s gonna change next week. So I think that’s another thing that’s related.
Matty: [00:19:34] Tell me a little bit about, ’cause I’m, you know, we talked kind of a little bit earlier, you know, about kind of being an infrastructure nerd and kind of playing with that. What are, so you’re not doing that stuff stuff now, but, uh, can you tell me a little bit about what the tech culture is like, or just kind of how, from a DevOps perspective at Nylas, you know, are developers on call? You know, how are you— you know, tell— maybe tell us some of the kind of interesting, uh, pieces and parts around, around how you’re, uh, you’re running your, your, your shop there.
Christine: Yeah, for sure. So because of the nature of our product, like, you know, it’s an API company, our Our infrastructure is our product. Our team is pretty backend heavy in terms of the actual work that we’re doing. So while a lot of people on the team consider themselves to be generalist engineers, probably like 75% of their time they’re working on things that are backend related, building new APIs, scaling data infrastructure, building things in a scalable way, reliability, all those types of things. That’s one thing that makes it relatively easy to kind of have like broad policies that apply to everyone in terms of like DevOps type things. So for example, every new engineer who joins our team, at least right now, ends up on our on-call rotation within usually about like 3 to 6 months after they join. And we, we have like a frontline on-call rotation and also an escalation. So eventually some people end up moving to the escalation rotation. And I’m sure at some point we’ll have people kind of switching back and forth depending on what else they’re working on. But like, it’s really important for us to have all engineers know what it’s like to be on call because you can’t really separate out the kind of running of our infrastructure from building new features on the product. They’re all interlinked. It’s the same product. There’s not a huge separation between frontend and backend. And at the end of the day, we are an infrastructure company and people rely on us as someone who’s providing core features to their product. So people on the team need to know what it’s like to operate our software in in production. You need to know if features you’re building are scaling. What are the kinds of things that break in practice? So I think that’s really important. Actually, when we hired our first kind of full-time operations person, he was very surprised to find how easy it was to ask people to join the on-call rotation because I think we did a good job at kind of showing why it was important and also And I think that younger engineers now, they don’t have this trauma from a world where development and operations were super, super separate. It’s not as big deal to them. They just expect that if they build something that they’re going to own it and run it as well. So I think at a startup, you’re often hiring people who are relatively new to the industry and are hungry to learn and grow. And I think that’s kind of been helpful in that they don’t bring kind of preconceived notions from how the industry was 10 years ago in terms of how development teams may have been siloed and kind of broken down. So I think that’s been really helpful. There was a really bad time in the company’s past where we actually used to have 2 different products. So one was the API infrastructure backend, and then we were also working on a desktop email client. And so we had people that were, for the most part, just working on this frontend application. And we had a lot more problems back when that was the case in terms of kind of the people who were familiar with the platform and the backend having to kind of hold up the house on that end. And we definitely went through a difficult transition where we spun off that frontend product and then had to train everyone up on contributing to the backend. And there was definitely a time in our past where our on-call rotation was very, very short. And it was a huge problem. I actually wrote a blog post about it at the time. It’s definitely on our blog. I can’t remember what it’s called, but I can provide a link later.
Matty: [00:24:40] I was going to say, we’ll find it. We’ll put a link in the show notes.
Christine: Yeah, totally. And at that point, I was part of the on-call rotation, which was like 3 weeks long and stuff was broken all the time. This was kind of like right around the time where we were still trying to figure out how to make the email client work as a business. And it didn’t ultimately end up working out, but there was a lot of pain that we went through there with part of the team kind of working on something that depended on the backend, but not having to share the pain of keeping that backend running 24/7. I feel like we learned a lot from that as a company. And now we’re very vigilant about everyone having to be a part of the on-call rotation, and it’s kind of become core to how we run things.
Matty: And you can share that. And it’s interesting when you talked about how you had a 3-week rotation and how that’s rough. And it’s one of the things that I’ve started to see with customers and just also how we do things internally at PagerDuty is being able, it’s less stressful to even if it’s more frequent to have it be shorter. So like the on-call rotation for incident commanders at PagerDuty here is 3 days. So it’s like I can do 3 days standing on my head, but we sort of, I think it’s interesting, and I’ve been a sysadmin for 2 decades, right? Before I, Back when I used to work for a living. And it was just sort of the default’s always been a week. And a week is a really long— I mean, 3 weeks is wow, you know, God bless. Yeah.
Christine: [00:26:24] But, you know, when I say it was a 3-week rotation, I mean, there were like 3 people on it and the rotation.
Matty: Yeah. So you don’t have a— but you don’t have a lot that you can do about it at that point, you know? So that’s when we can share the load like that.
Christine: A soul-crushing rotation. Like you, you just get out of it and then you’re like, I have to go on call again and everything’s on fire.
Matty: Yeah. So I think that’s really it. And it’s good to hear, like I’ve seen places that I’ve been where we kind of run into this when you talk about developers being on call where, you know, and again, kind of being from the ops tribe, this always rubs me the wrong way where it’s like, oh, well, but you know, I have a family and it’s like, well, ops people have families too. One thing though that I thought I found really interesting, I was in Australia about a month ago, talking to a lot of folks, and the challenge they have with shifting their on-call is that they have reasonable labor laws in Australia. So, people who are on-call get paid more. So, it’s actually, it’s not so easy. You know, we sit there and we’re like, DevOps it up and put everybody on call. And they’re like, that’s very— they’re like, eventually it evens itself out, right? Because it’s like, then the people that they were paying were on-call less, but It’s, you know, in places like that where people actually are compensated for on-call and after-hours work, um, there’s like a financial thing that comes into play that makes that, that initial transition a little bit, uh, a little bit more challenging to see.
Christine: [00:27:57] That’s interesting. Yeah, we also have, um, an interesting setup where we, we— so one of the biggest scaling challenges on our backend is actually the size of the data. So one way that our platform works is that we actually cache a copy of all of the mailbox and calendar data that we’re serving because the way that we’ve simplified the interface to all of these mail providers doesn’t necessarily translate well to calls to the like the providers’ APIs themselves. Like if you download a thread from our API, it might take half a dozen calls to like reconstruct that thread via IMAP. And like that would be one, super, super slow and two, really flaky if we were trying to do that on the fly all the time. So instead of doing that, we actually basically just We’re almost like an email client that’s in the cloud that’s constantly keeping its data store up to date and then we’ll serve clients the data on demand. But what this means is that we have a lot of data that we have to store in order to make our product work well. So we have a pretty significant fleet of horizontally sharded MySQL clusters, which are our primary data store at this point. And We have a team of MySQL DBAs who help us run those clusters. And one thing that actually helps make our on-call rotation more sustainable is that one of those DBAs is just really excited and helpful and volunteered to cover our nights because he’s based in Russia. So our day is his night and vice versa. So it’s definitely been helpful for our team to have that geographic distribution too, because you always try to make it so that your alerts aren’t flappy and stuff like that, but it’s a really hard problem. And if you can have someone who’s like, able to triage stuff and only escalate things that are completely broken or that they don’t know how to fix. That helps people get woken up less. So that’s a big deal on my end. It’s been really helpful.
Matty: [00:30:37] That actually leads into an interesting question. So you talk about having someone in Russia. So what’s your remote culture like? Do you have— is almost everybody in San Francisco? Do you have a lot of remote employees? Are you distributed? What’s that like?
Christine: Yeah, so we started out being entirely co-located in San Francisco, but one kind of industry trend that is happening right now is that once you get to a certain stage as a company and in the venture capital world, Series A is kind of the stage I’m talking about, Series A and beyond. It can be very difficult to hire as many people as you need in San Francisco and also to provide those people with office space and kind of all the things that you need to be co-located. Just because, to be perfectly honest, the real estate environment in San Francisco is crazy right now and office space is really expensive. Housing is really expensive. And Um, the, that just like limits the speed at which you can hire people here.
Matty: [00:31:49] Um, I think our office manager was not super thrilled when I decided to move to San Francisco and they’re like, now we have to find somewhere for you to sit. Yeah. Yeah.
Christine: Seriously, I’ve, I’ve gained so much empathy for like all sorts of like problems that people don’t really encounter until they’re like kind of growing a company. And especially since I care so much about like diversity. City as a company, it’s painfully obvious how much being headquartered in an extremely expensive city affects that because there’s just certain types of people that are automatically at a disadvantage if the only option is to work in San Francisco because of the housing price. For example, people with families. It’s hard to have enough space to have kids in San Francisco. Basically, we used to be hardcore co-located and we’ve relaxed our grip as we’ve grown as a company. And I do think it is really valuable to all be in the same place when you’re kind of incubating an idea. And there’s obviously different ways to do it, but it’s fun and easy. And communication is really high bandwidth when you’re just all in the same room every day. But now that our product’s a bit more established and there’s projects that last a long time, multiple months sometimes, and the work is a bit more predictable, we’re not inventing something from scratch, it’s totally possible for us to move as quickly while having people who are not co-located. So we I would say like 80% of the team is still in San Francisco, but we’re hiring more and more remote folks. We currently have 4 people who are remote, 4 engineers on the team who are full-time remote and have been advertising for and putting out offers to people to also be remote in other locations. So we’re pretty We’re pretty committed to supporting remote from this point on. And I’m pretty much of the opinion that once you get to a certain size in San Francisco, you either have to open another office somewhere and maybe you can have 2 locations, or you just kind of go full distributed just because that’s what you have to do in the current environment.
Matty: [00:34:29] What are some of the things that you’ve been doing? You know, so sort of as you’re making that transition to adding, you know, more of a distributed workforce, more remote folks and stuff, what are, what are some of the things you’re doing for those, you know, to kind of have those remote employees be first-class citizens as well? As someone who spent most of their— this is the first time since I moved to San Francisco, this is the first time I’ve worked in an office in like 8 years. So I’ve been a remote employee for a very long time. So this is near and dear to my heart. You know, I had to, I had to train my team when I started here at PagerDuty about what it was like to have someone remote. And then I moved here, so I kind of ruined it.
Christine: It’s the first thing you did was buy a pair of noise-canceling headphones.
Matty: Yeah. First thing I did was say, remember time zones, because I was in Chicago. And so there were a lot of 6 PM, 7 PM meetings for me.
Christine: And I was like, I was just saying that now that you’ve moved to San Francisco, you have to deal with all these open-plan offices and Yeah. Figure out how to get work done while there’s people all around you all the time.
Matty: [00:35:32] Yeah.
Christine: But, but yeah, that’s a great question. Um, I’d say the first thing that we did was, um, move the time of our all-hands. So we’re a startup. We have like a weekly all-hands sync up. Um, used to be on Fridays at like 4 o’clock. And, uh, it’s basically as soon as we had people full-time on the East Coast, we’re like, well, that’s really shitty for them to either miss all hands every week or have to be at work until like 8:00 PM. So we moved it until directly after lunch West Coast time, which means that they’re done by 5:00 PM on Friday. And I think that like, time zones is like, there’s, there’s good reason to like kind of try to limit the complexity of your time zones, even when, um, you are committing to remote, at least at first, because like if we had full-time people who were like in Australia or something, that just makes scheduling really complicated. Um, so we’re kind of taking these steps.
Matty: [00:36:45] It becomes very hard math when the day changes.
Christine: Yeah. Like at this point we’re committed to like all of North American time zones and like we can handle that. It’s like only 3 hours difference. Um, but we’re not quite to like hiring full-time people who are, um, all around the world. Um, but so that’s, that was one thing. Uh, another thing is like investing in kind of better, uh, microphone setups. Um, so like we have a couple, uh, conference rooms that are outfitted with webcams. And, uh, we also got some area microphones, which, um, if you haven’t heard of them, they’re basically like, like a microphone that has like 180 degrees of like pickup. Um, so they’re directional microphones. Um, but they, kind of allow people to hear things that are going on in other parts of the room. So you can actually have a meeting in a room and people can tell what’s going on. We’ve always been pretty good at like writing stuff down in like Slack and we use Dropbox Paper for everything. So like it’s kind of like our company wiki. So Kind of the default thing when anyone’s organizing like a project or just writing up a proposal or something like that is to write a Paperdoc and drop it on Slack to get feedback. So that’s something that like doesn’t really matter where you are, you can participate in that. But yeah, I think that like definitely being aware of time zones and making sure to like loop people in. Outfitting conference rooms with like AV equipment is like the place to start.
Matty: [00:38:42] Awesome. So we’re just getting ready to probably wrap up here. Is there any other things that come to mind that you wanted to, you know, that were kind of through the history of kind of your starting your company that, that were interesting, that were kind of lessons learned, maybe any little fun, fun stories? Kind of in retrospect as we wrap up?
Christine: Yeah. One of the most eye-opening things to me is that as you grow and scale a company from 2 people to many more than that, you can kind of see over time why structures develop in companies in a certain way. And you kind of understand what processes develop for. And I think that, I guess for me, this has given me an amount of empathy and understanding for the way that other companies are that I can never go back from. It’s like, I will never like rail and complain blindly about like all of the like process that exists elsewhere because I’m like seeing it accrete and like grow over time. And like, I see why it is happening. It’s because like, you know, once you get more than like 10 people working on something, like communication starts to break down and you can like see it break down and like If you bring in people who are more diverse, you need to be more clear about the words that you’re using and you can’t rely as much on assumptions. So I think that one of the most big and valuable things is learning about human dynamics and how people are able to interact together at different sizes. Because unless you see a company grow and scale through those stages, it can just be like a black box. You’re like, wow, we have this convoluted structure for organizing things and couldn’t this be a lot simpler? But there’s always a reason why things end up that way. And it’s been very enlightening.
Matty: [00:41:14] Context is a thing. Yeah. Fantastic. So just to wrap up, as usual, if you’re looking for the chance to speak at an event, there’s a list of open CFPs for DevOps Days at devopsdays.org/speaking. Go check it out there. If you go to arresteddevops.com/spang, we’ll have this episode’s show notes. And our website is also where you can subscribe to our newsletter, all the sorts of Arrested DevOps stuff you could ever want. If you go to arresteddevops.com/itunes, leave us a review in the iTunes store, that actually helps other people find the podcast. So that’s kind of cool. So thanks a lot, Spang, for joining me today. I really appreciate it. It was a great conversation.
Christine: Yeah, great to talk to you too, Matty.
Matty: Yeah. And so as usual, I’m Matty. I’m @mattstratton. This is Arrested DevOps. And remember, There’s always DevOps in the banana stand.
