Mike: [00:00:00] I definitely take most of my DevOps advice from ’90s music.
Nell: Yeah.
Jill: Absolutely.
Matty: From ’90s slow jams. So it’s time for Arrested DevOps, the podcast that helps you achieve understanding, develop good practices, and operate your team and organization for maximum DevOps awesomeness. I’m your host, Matt Stratton, @MattStratton on Twitter. Arrested DevOps is brought to you by 10th Magnitude, a company that figures if you’re listening to this podcast or at DevOps Days Chicago, you must be pretty cool. 10th Magnitude empowers businesses to better collaborate across teams and achieve IT transformation using cloud. They enable customers to innovate, automate, and accelerate by leveraging the power of Microsoft Azure. You can find out more at arresteddevops.com/10thmagnitude. This episode is also brought to you by Hired. Hired is a platform for top developer jobs, and they love DevOps people. Developers get an average of 5 to 10 offers on the platform, all with just one application, You get job offers and salary or equity upfront before you interview, so you don’t have to waste your time interviewing for jobs you might not want. And they work with over 4,000 companies from startups to large public companies all over the place. ADO listeners get double the $2,000 bonus just for signing up at arrestedevops.com/hired. And finally, hey, someone’s got to pay for this stuff. The episode was brought— is also 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 with a free t-shirt at arresteddevops.com/datadog. So today’s episode is coming to you live, live, live, live, live, From the second day of DevOps Days Chicago 2016. It’s our third time doing this thing. I’m running solo as a host, but I’ve got 3 great panelists and a bunch of cool people in the audience we’re gonna talk to. So I’ll let the panel introduce themselves and we’ll see where we go.
Nell: [00:02:08] Well, good afternoon. It’s good to be here at DevOps Days Chicago. I’m pretending I’m on Wait Wait… Don’t Tell Me at the moment. And I am Nell Shamrell-Harrington. I’m a software engineer with Chef Software and from Seattle and thrilled to be here.
Matty: Thanks, Nell.
Jill: All right, I am Jill Jubinski and very happy to be here at DevOps Days Chicago. I am a community evangelist of sorts for IBM via Blue Box acquisition and super amped to be back on Arrested DevOps.
Matty: This is your third time?
Jill: My third time.
Matty: Third skate.
Jill: Yeah.
Mike: Man, so I’m a rookie on Arrested DevOps. I’m Mike Stahnke. I’m a Director of Engineering at Puppet. I’ve been there 5 years and I’ve been to this conference twice and got to speak here twice, so it’s been pretty great.
Matty: Yeah, great. So it’s like we said, so this is the 3rd time that we’ve done DevOps Days Chicago. And I have to say, personally, I feel like this has probably been our best one. I think they’ve been great so far. And maybe I’m just speaking as an organizer. This has gone the smoothest out of every one we’ve done. So basically we’re screwed now because I just said that.
Nell: [00:03:11] Just say knock on wood there.
Matty: Yeah, everything’s going to go to hell in the last couple hours. But one of the things I thought I’d like to start talking about, and then we’re going to talk a little bit to some of the folks in the room about their experiences at the conference. But we’ve had our— yesterday we had our main speakers, we had some Ignites, we had some open spaces. So far today, we’ve had some more talks, some more Ignites. And I’m curious, what are some of the themes that you’ve been seeing that people have been talking about either in their talks or in the open spaces you’ve participated in?
Nell: I’ve seen a very strong emphasis on not just humanity and technology, but the crossover between them and how they’re not really all that different when it comes to DevOps.
Mike: I guess one of the things that I saw in a lot of the open spaces was, oh my gosh, all this stuff comes down to testing, and testing is really freaking hard. And so it was testing all the way down.
Jill: Yeah, I think a main theme that I hear in DevOps Chicago and DevOps across the board and different conferences is that technology is hard, people are harder. So we need to figure out how to mitigate the two and how to work together most effectively.
Matty: [00:04:22] Yeah, we had, so our keynote yesterday was Adam Jacob giving his talk about humane systems, talking about context, talking about the idea of Ubuntu of when you thrive, I thrive, and kind of understanding how we can start to work together. And then this morning, Jill kicked off kind of talking about what she called DevOpsing recruitment. But really, one of the slides that I saw and one of the points that seemed to kind of a lot of people seem to gravitate to, at least based upon what I saw on Twitter, which is the arbiter of everything, was a slide where Jill played what she called— she said, we’re going to play a game that was recruiter or engineer and saying, so who would say this? And the spoiler was that all of them were said by both. So there’s such a commonality between groups that normally would be felt as being at odds or being completely different from each other. So I think we’re seeing this idea of commonality But then also, I agree with you, Mike, that there’s a lot of— yesterday, the open spaces, so many of the topics were around testing. And Nell, your talk today was about restructuring, refactoring code. And there was a comment, I’m gonna probably get it wrong, but I really, really liked it, where it was the intention of a software is far less important than what it actually does. And how if you aren’t actually testing for what it’s actually doing, You don’t know shit.
Nell: [00:05:45] That is correct. And the only source of truth is when you execute the code itself.
Matty: So, again, we’ve all been doing this in various different ways, some of us longer than others than we want to talk about maybe. But even over the last couple of years, so we’re talking about we’ve done— this is the 3rd year of DevOps Days Chicago. What are some of the evolutions we might have seen over the last couple of years around this, around I wanna think a little bit about this idea of testing, first of all, ’cause I think that’s something that I’ve seen change, maybe becoming a little less of lip service, maybe?
Nell: I think the way— when I asked my boss, Nathan Harvey, once about teaching test-driven development techniques to system administrators, I come from a development background, what he mentioned is you can tell them that they do test their code anyway. It might not be beforehand, but when they configure a system by hand, the first thing they’re going do is log into that system, run some commands, and see that it’s doing what they intended to do. And testing, I think more people are realizing it’s the same thing, but it’s faster and it’s more reliable than relying on a human.
Matty: [00:06:56] There was an open space yesterday that I didn’t get to attend, and I’m really kind of bummed. I’m interested to find out if any of you were at it, but it was about the challenge of applying test-driven development to infra code. So was anybody in that open space? Was anybody in the audience at that open space?
Jill: Was that the CI/CD for CI/CD?
Matty: No, it was something called like applying the testing pyramid to infrastructure as code.
Nell: I was at that one.
Matty: Oh, you were? Okay.
Nell: I was.
Matty: So how did that open space go?
Nell: It went pretty well. I was trying not to dominate the conversation because I was giving a talk on that subject the next day. We got a lot of different perspectives. I come from the Chef world, so I know the Chef testing tools really well, but I’m not as familiar as the ones you use with Ansible or with Puppet, et cetera, and we got lots of different perspectives from people who came from the sysadmin background or pure app dev background on how to apply those principles using different tools in different ways. The principles are the same regardless of which tool or testing tool that you use, and that was demonstrated by the sharing of experiences in that room.
Matty: [00:08:00] And that’s good to hear. And I think there’s, you know, having been playing in the infra code world for several years now, shall we say, I think there really have been quantum leaps in that. And it’s funny to think about how it’s really only been in the last, I don’t know, I’ll say 3 years, that really being able to do test-driven infrastructure has been a thing. And I feel like I don’t even know how we did this before. I always would tell people, I’d say, again, coming from a chef background, I specifically talk about, I’m like, how did I write cookbooks without Test Kitchen? I really don’t know. And then I sit down and I think about it and I remember, And then I go cry in the corner, and I remember how I did that. I’m like, oh, yeah, mini test handler, that was awesome, right? But one of the things, and this is why I really actually liked hearing that this was being talked about, is when we work, you know, if it’s someone like Mike or Nell or myself, we work for infra-code vendors, we’re in a bubble of the right way to do stuff, right? So, I spend all of my time talking about testing infra code, you know, applying state, thinking about things through a pipeline, put your cookbooks through modules through a pipeline, do whatever kind of thing. Nell’s actually doing that.
Mike: [00:09:13] But it’s only right until it runs into the real world.
Matty: Well, right. Well, there’s that. And then there’s also the fact that for a lot of people, we consider table stakes are not table stakes, right? You know, like, that’s the thing. Like, we kind of say, what is the beginning part? And that’s a lot of people aren’t there yet.
Mike: I think that was a lot of the conversations that I was having yesterday where Even if you can see the outline and you understand what the goals are and you’ve read a CD book and you know exactly what you’re supposed to do, every one of those bullets on that transformation plan is a journey in and of itself. And it can be 9 months or a year just to get tests around a set of modules or just to get tests in one little area of an application. And you’re so far from CD and people are like, they read about somebody deploying 50 times a day and they’re like, we don’t have 50 tests yet. There’s a lot of stuff to do in there. And I think you have to have some empathy for that. It’s not— just because you know the roadmap doesn’t mean you can actually drive.
Nell: There’s a great article by Martin Fowler where he introduces what he calls the strangler method. That is when you have a big legacy code mess, which most of us do when we come into a job, you start out by adding tests around one small portion of it that you have to change, then gradually adding them. And over months or even years, slowly that new well-tested application strangles the old one.
Matty: [00:10:28] There’s, uh, okay, this is gonna be kind of cheesy, but, uh, it’s funny because this applies to this thing that’s going on with me and my fiancée. So like, we, um, it is cheesy. Oh, you failed, just you wait. But, but the Strangler Method, that’s a, that’s not a way I would talk about my relationship. But you’ll see, you’ll see it somewhat apply, but it may be a different way. So we, uh, spend a fair amount of time in Kentucky. She works for Jim Beam, and so we were We were down there last summer, and this was kind of at an inflection point in our relationship. And there’s this bridge in Louisville. And the interesting thing about it— so we’re walking across it and looking at it. And the story of the bridge is that it’s built on top of another bridge. And they basically started building this new bridge on the old one. And then when the new bridge was strong enough to be its own bridge, they let the old one fall away. And then I said, this is kind of a metaphor for our relationship, which is like we have— because we’re older people, right? We’ve been around. We have a lot of baggage, a lot of mess, a lot of stuff. And we’re like, that’s sort of the thing.
Jill: So you’re humans.
Matty: What’s that?
Jill: So you’re humans.
Matty: [00:11:29] So we’re humans. And so we, you know, I’m like, you bring this stuff with you and you have to kind of keep that stuff around till the new stuff can come. And so I think that applies to your system architecture, right? Because again, and Adam talked about this yesterday too, right? If you’re a city planner and you come in and say, I’m gonna redesign Chicago and the first thing I’m gonna do is bulldoze it and make it be New York. You know, that just doesn’t fly. That’s what we always wanna do. But in reality, we have to start building the new thing and the old thing, is what’s going to get us there. We talk about shims. We talk about building temporary bridges. And I think a lot of times we feel wasteful when we do that stuff. Like how many people in this room have built something that you know is going to get thrown away and it only exists to get you to the next thing? Right? Okay. How many of your product owners think that’s a good idea? Right? They’re like, no, why are you doing that? Why aren’t you doing my thing? Why are you building this old thing? Right? And it’s like, but that’s the thing that gets us there. And Mike, to your point, you have to think about that roadmap so that you can get there, but you also have to realize that getting to that, it’s not a binary thing, right? It’s not like, and now Scrum, right? Now we’re gonna Scrum like crazy, right? We gotta get to that piece there. So, and that was again kind of Jeff Smith in his Ignite yesterday about Dungeons& Dragons DevOps. He talked about you fight a bunch of level 1 monsters first, right? So it’s like you’re not gonna go out and attack and say the first thing we’re gonna do is slay the 50 employees a day dragon, right? We’re gonna slay the, like, learn how to write a Git commit message dragon first, right? I see this a lot with customers when I’m working with Chef, and they’re like, the first thing I wanna do is write a Chef cookbook to manage my storage device, my Hitachi storage drive. I’m like, can you write a recipe to install a package first? Well, I don’t know how to do that, but I wanna manage my networking device first. And it’s like, we wanna do all the cool stuff right away, and The thing that sucks is we have to do some of the easy stuff, not even easy, but the building blocks pieces, and we have to fight those battles first.
Nell: [00:13:25] It reminds me of that song from the ’90s by TLC, Don’t Go Chasing Waterfalls. I think that applies to DevOps very, very well when you’re getting started.
Mike: Yeah, I definitely take most of my DevOps advice from ’90s music.
Matty: Yeah, absolutely. From ’90s slow jams, yeah.
Jill: When we’re talking about QE and testing a lot, I feel a kindred spirit with QE a lot of times being from recruitment because I feel like they’re another group that gets left out of the conversation a lot and gets talked down to a lot. So it’s really important and critical to, like recruitment, bring them into the fold and treat them as humans because they are an integral part of this entire process and they should be involved as well. And they add tremendous value to the team.
Mike: I guess as somebody who’s written software and tests, I usually find writing the tests way, way harder than writing the software. So I have mad respect for all the people that do automation and testing engineering. Usually when I run that area at Puppet, and one of the things that I try to say is, like, this is the most interesting problem, this is the hardest problem that we have at Puppet. So, you know, if you actually want a real challenge, come work in the testing area.
Matty: [00:14:28] And it’s interesting you said that, when you said, okay, writing the tests is harder than writing the code. That’s actually a lot of the pushback I usually get around TDI, right, which is the, oh, I’m gonna spend all this time writing tests. And the reality though, too, the other flip of that is that writing tests makes writing the code much easier because at least, and again, I’m not like a real app developer, like, you know, I play one on TV sometimes, right? But I’m an infracoder, right? And infracode is like, infracode tests are super hard to write without actually really writing some code to do the test, right? And so that’s the thing I found when I started writing tests for my cookbooks, I’m like, well, shit, I did half of this already by writing the test. And then it’s like just putting those building blocks together. But that’s one of those things that I kind of make that metaphor. And Jill, you’re from close enough, and you’re from O’Fallon, right? It’s, I’m from Missouri. I’m from O’Fallon, Missouri. Show me, right? I’m like, these are the things that you actually have to have that visceral experience of. I can sit and talk to you all day long and explain to you that no, this is going to change your life. Write your test first. It’s going to make it better. And you’d be like, blah, blah, blah, blah, blah, Ginger. Blah, blah, blah, blah, blah, Ginger, right? But then you’re going to do it. And you’re gonna say, oh, Matt knew what he was talking about. And then you’re gonna turn next to the person next to you and say, yeah, you should do blah, blah, blah. And they’re gonna, yeah, blah, blah, blah, blah, blah. So I think part of it is, but there’s so much of that that occurs within transformative practice that it’s really important for all of us to remember that we have to have some experience before we make a judgment, right? Because everything’s gonna sound really ridiculous and stupid. We’re going to be like, oh, these containers, what the hell is that? That’s dumb. But then maybe I’m going to try it. I’m going to go, whoa. We talked about this a little bit on our episode on Monday. I call it time to first delight, or Andrew Clay Shafer calls it mean time to dopamine. It’s how do we get quickly to having that feel? And I’ve talked with a fellow coworker of mine, and we talked about the challenge of when someone’s experienced something and then you might be, and for lack of a better word, saying you’re selling against it, right? So maybe a competitor or something like that. And it’s one of those things where he’s like, you really, you just can’t because you might have this thing where you’re like, I did this thing and it gave me a mad dopamine rush. I’m like, I had this terrible pain and this thing made the pain go away. And then you’re gonna come in and you’re gonna tell me that thing that made you feel so good is wrong. And that like, and as Adam Jacob would say, They will argue with math, right? You’re like, I’ll show you math. It doesn’t matter because it made me feel good. So I think when we think about how we’re going to affect change in our organization, we need to— that’s a thing that can work for us and against us, right? We need to understand that sometimes folks may be going down a path that’s not necessarily the way that we think is the right one because it makes them feel good, right? And we might sit there and say, like, okay, but maybe that’s okay because we’re getting to the right place. And then the other piece of that is, if we want to affect change, how do we do it in a way that gets them to that mean time to dopamine, right? Like to say, like, you’re actually experiencing results. It’s not just a thing that’s on my PowerPoint in a bunch of bullet points. You’ve actually experienced that I shipped your stuff. Your thing got done, right? It actually happened.
Mike: [00:17:39] So, can I jump in for a sec?
Matty: Please do.
Mike: I want to talk about— so, I’ve been to a lot of DevOps Days. Yeah. Many, many. I don’t know how many, but This was the first time I’ve seen a recruiter talk at a DevOps Days, and it was badass. So let’s just have Jill talk about it for a second.
Matty: Absolutely. Good. I was just getting ready to transition as well.
Jill: That’s very, very kind of you. I was excited to be here, and I really just want to, as I spoke to a little bit earlier about, you know, QE experiences bring empathy to recruitment as well. And I’ve had many experiences of of support in this community. I don’t want to throw shade on that whatsoever. I have a huge amount of individuals I’m so lucky to be backing me along the way. But also, we all hit road bumps, and we all run into individuals who are like, who are you and why are you here? And that doesn’t feel good either. Been there. Yeah. And so I wanted to make sure, and what my— actually, my goal for 2016 was to speak at an engineering conference. So yay, go goals!
Matty: [00:18:40] Excellent. You had 3?
Jill: Yeah, this is my third.
Matty: Third. And again, So, we feel good. Velocity? Yeah. No.
Jill: So, I spoke at Monitorama.
Matty: Monitorama, that was it. Okay.
Jill: I spoke about Taylor Swift and open source at Monitorama. It was super badass. I have no idea why they let me do that, but it was fun. And then I spoke at Boston DevOps Days last week and then here this week. And so, I really just want to continue to spread the message of empathy to recruiters because it’s not only just me and And I hear that a lot, and this is not like tooting my own horn, that people are like, oh, like, you’re such a great recruiter to work with, like, you’re the only one, blah, blah, blah. Like, no, that’s completely inaccurate. There is many, many other great recruiters out there, and you just need to give them a chance. Like, I’ve been on teams full of amazing recruiters, and maybe just like some engineers, like, some are a little bit more introverted or aren’t going to put themselves out there as much, but that doesn’t mean that they’re less good at their job. So, just help facilitate that. And at the end of the day, it’s going to make everybody’s lives easier. So, I am again super gracious and thankful to be here. And I want y’all to meet and love your recruiters because they’re freaking awesome, I promise.
Mike: [00:19:53] And they help you build the right team. I mean, like Puppet, like I got there, we were 35 people. We’re 470 today. We can’t grow like that without awesome recruiting and hiring pipelines and the right process for interviews and tweaks constantly along the way. Like, those people are your partners to help you build that team. And when they— trust me, when they’re absent, it really sucks too, because you notice.
Nell: Yeah. I want to give a quick shout out to Wendy McIntosh, who’s our in-house recruiter at Chef. And along with recruitment, she also has been doing a lot of interviewing training. There are a lot of interview questions which we’re very used to asking, or we’ve seen people ask, that are actually illegal and can get you in a ton of trouble, let alone not help you figure out who the best person is for your team. So, there are a lot of great recruiters out there, And the industry would not be what it is without them.
Jill: Yeah, and definitely rely on them for things like that, like interview training, because we definitely know best practices, or we talked about earlier, diversity is a huge hot-button topic. We understand the market and how to go after it. So we’re there to partner with you on things that you don’t understand, and from— I spoke on this a little bit earlier in my talk, a recruiter is great at their side of their side of the fence, which is understanding like who a human is, how they work, what the best environment for them to work in. Because sometimes you’ll talk to someone who’s amazing, but like, you know, in this particular company, like it’s not going to be successful for them. And that’s okay. So figuring out who that individual is and then working with the engineering team or whomever team you’re working with to have them suss out from an incredibly technical perspective, like that’s your side of the equation and work together to to then get a full picture view of the candidate and find out who’s best for your team.
Matty: [00:21:39] It’s something I was thinking about in your talk. You know, again, when you were talking about that is there is sort of this weird, and maybe it happens in other parts of the industry or other professions. I’m just more familiar about it from an engineering perspective and a tech perspective, but a huge amount of arrogance that we’re really good at our job and everybody else’s job too. Right. Which is like, well, oh my God, our salespeople are so stupid. They don’t know how to sell shit. They should do it the way that I think they should do it. Our marketing people don’t know how to sell our product. They’re so stupid. The recruiters don’t know how to recruit for me. They’re so stupid. So my first question is, but the thing is, like, I don’t, and then I feel like we get that from other parts of the company, right? You know, so maybe it’s just a human problem of that we just assume that we’re smarter than everybody else.
Mike: Well, it’s just Dunning-Kruger. The more you know, the more you know you don’t know.
Matty: Yeah. And so there was a Dilbert like this, right? Which is because I don’t understand, I assume it must be easy.
Mike: Right.
Matty: Right. You know, so I think that’s the thing. But then, but within like our tech sphere, we do that less, right? Like it’s one of those things where I’m like, but I’m not gonna think that way about a DBA. I’m like, oh, well, I don’t know databases.
Nell: [00:22:41] Good, good.
Matty: I’m getting my DBA to do that. But marketers are stupid, right? Like they can’t, I must know, I completely understand their thing, but that’s technical, that’s hard. So I think that’s a thing to maybe help understand, right? Which is again, you’re not gonna go try to do, you’re not gonna go build your system completely by yourself. Why are you gonna assume that you can just handle somebody else’s job, right? I had a graphic designer friend who’s like, you know, the most insulting thing she said, you know, people come to her and say, hey, can you sit down with me today and teach me Photoshop? Like, can you just come teach me everything you know? Because clearly everything you know, you can teach me in a day.
Mike: So why do recruiters get such a bad rap among technical folks? Because I would say that I read a rant on Twitter about a recruiter from somebody, I’m gonna say once a day, just roughly.
Nell: I was gonna say once a week, but that’s still pretty darn frequent.
Matty: Yeah.
Jill: I mean, some of them are coming from me, to be fair. But because there’s 2 segments of recruiters, and it can be frustrating for either or. So you have your internal recruiter that’s working at the company that is fully ingrained in the culture, can get in with your team and, you know, preach to the things that I talked to earlier. Or there’s external recruiters, which quite frankly are set up, unfortunately for them, for us to make fun of because they’re compensated on a commission basis. And so if they want to like feed their children, they need to fill seats and they don’t know anything that much about the companies that they’re working for. They’re just like, you know, given a ticket and saying, fill this role. So it’s a numbers game to them. So although it is, I personally don’t like the way it’s set up. It’s the industry as a whole. So I think that that’s where a lot of the angst is coming from, from our perspective. I mean, probably weekly I get an an email about like, do you want to be a DevOps engineer? And I’m like, if you read my profile for like literally like a 4th of a second, you would see like that’s not who I am. No offense to y’all.
Mike: [00:24:36] But do you want to be?
Jill: Not ever.
Nell: I’ve gotten emails telling me they have an administrative assistant position open.
Jill: Yeah, I mean, it’s just the little things where you’re not even trying at that point. So there needs to be a disruption. Oh my God, that’s such a buzzword.
Nell: Meantime to buzzword. Ding, ding, ding.
Jill: Um, in that industry. But what I, what I choose to focus on at this point is, is internal recruiters. And whenever people ask me like what agency they should work with, I understand that at some, some point in a company you might be too small to have an internal recruiter and there’s agencies that you need to work with. Like that’s just how life works sometimes. But if you are at a significant enough size, like get an internal recruiter and I promise you it will change your life.
Matty: I think the other thing is that you said, you know, you continually hear about it because we also live inside the bubble of people like us. So what you don’t see on Twitter all the time is people complaining about IT people.
Mike: Oh yeah.
Matty: Which is what other people are doing. Well, I mean, but you know what I’m saying?
Nell: They do that on Facebook.
Matty: [00:25:37] They do that on Facebook, right? But that’s what I’m saying. So the recruiters are all complaining about their help desk people somewhere. You know, we’re not seeing that because we’re like, we’re the help desk people. We’re like, these guys are just jerks. You know, so it’s as the consumer of the thing, you’re, you know, that’s where you’re interacting with. So we necessarily have some poor interactions with them. And, and of course, you know, it’s— you hear about a lot because it’s funny, right? Like, because it’s an easy target. It’s lazy humor, right? To be able to, you know, at this point, like, making fun of recruiters is actually just— to me, that’s just— you’re just being lazy.
Mike: I just love fake internet points.
Matty: Well, yeah, those are important, but, you know, but you should go for like a higher degree of difficulty, right? Depends if you’re going like the scatter method or the more You know, well, and that’s the recruiting problem as well.
Nell: Exactly.
Matty: See, so, oh, I see what you did there.
Jill: I mean, at this point there’s definitely lack of try from both sides of the equation because, uh, I know plenty of recruiters who I get frustrated with because to me it’s, it’s simple. Know your audience, like know who you’re, who you should be targeting. Like if you’re wanting to hire an engineer, then probably spamming on LinkedIn is not the way to go. But I will tell you, if you’re hiring marketers and you spam on LinkedIn, you’re gonna get like a 95% return rate.
Nell: [00:26:45] Oh wow.
Jill: So don’t reinvent the wheel. The wheel if it’s there. So there’s, you know, you have to know who you’re going after. But also from an engineering perspective, like, you just want to make fun of and then not try to help at all, which isn’t fair. I mean, I get Life Sucker, I say that all the time, so I’m also a hypocrite. I’m a buzzword hypocrite.
Mike: When I get the email that says, dear insert name here, and literally it says insert name here, but I think they’re probably gonna make fun of you and not help a whole lot.
Matty: I think that’s the thing, because they’re very times when, when I’ve responded to recruiters, you know, I’m not gonna lie, there’s sometimes times I’m really annoyed and I’ll respond like a jerk, but that’s more often not the case. But there are the times when I say, hey, you know what, let me actually help you. Let me tell you what’s wrong with what you’re doing. And not even so much because you offended me and bothered me, but because actually you’re not gonna accomplish the thing you want to accomplish. You listed a job description blah blah blah way. You are not— I can sort of read between lines. I know what you’re actually trying to hire for. You’re never gonna get this person. With what you just said because you have the wrong word here, you don’t understand this thing, blah, blah, blah. Let me— and what I say is, if you’d like to talk about this, let me know. I’d be happy to tell you about it. And actually, usually what happens, I’d say maybe 50% of the time, and I don’t do it that often, maybe once every couple months. Most of the time I’ll get a response that says, great, let’s talk. Awesome, I understand you’re not interested, but help me. Because they do want to hire them. I mean, whether they want to hire it because they want to like really fulfill and make everything amazing, or they actually just want to get get freaking paid. Either way, I don’t care why, you’re motivated to get the right person, and it’s how you help. But again, to Mike’s point, it’s like if the amount of effort is literally zero— oh yeah, you know, where like you get the ones that says, after carefully reading your profile, I have this great job for you at FUBAR Company. And I’m like, I work at FUBAR Company now, you know. So I mean, it doesn’t bother me that you’re recruiting for that, but don’t tell me you clearly read my profile, right? Or, or stop offering me jobs about SharePoint. Just stop, right?
Mike: [00:28:41] Is there like a checkbox for that somewhere?
Matty: To take me off the— it’s called remove SharePoint from your resume.
Mike: Just asking.
Matty: Yeah.
Jill: I mean, a great tip for recruiters, and this is difficult because we all have egos to some extent, is when I’m going to send out messaging or things like that, I typically like, I have an overarching template. Like, I’m not going to, again, reinvent the wheel every time I email someone, but I will make it specific to them. So I will, like, I don’t like doing it because I don’t like hearing negative feedback either, but I will run it by my engineers who are friends. And sometimes they tear me apart and it’s better that way. And sometimes they’re like, oh, this is rad, you should do this. But either way, we’re gonna get to a better end result. But it’s just becoming, having a trust relationship with people on the other side of the fence to say, Hey, this messaging, cool or horrible? So yeah, so I think that’s important as well.
Matty: [00:29:42] I’d like to take a little bit of a different tack for a few minutes and talk a little bit about the event, about DevOps Days in general, specifically around Chicago. So what we’ve got, so Mike, you’ve been at 2 of the Chicago events. Jill, you just came from Boston. I would say I’m not gonna ask you to compare us to Boston. But I’m going to.
Jill: No, I’d like to— I’ve been to like 6 City DevOps. So, I have lots of experience.
Matty: Well, no, but most, I’m saying like fresh in your mind. Most in your mind, okay, got it. So, what I— and then, Nell, this is your first time here at Chicago. Well, it’s your first time here at Chicago too. But I— and obviously, this is my third one. And then, in the audience, how many people have been to all 3 DevOps Days Chicagos? Yeah, if you’re not wearing a purple shirt, then there’s about one of you. Yeah, pink, that’s good too, okay. So I’d like to talk a little bit about what’s maybe some of your thoughts on this year’s event. What was interesting? What was different? What could we have done better? And we’ll start with the panel, and then we’ll see what the folks in the audience think.
Nell: [00:30:42] Well, I am a little hard of hearing. So when I go to events that are in a bar where there’s people having to yell to be heard, I generally don’t have a very good time at them because it’s like charades. But having the party at the bowling alley, one half was the bowling alley, and then one half was card games. That was enormously helpful to me, and I had very, very good conversations around there. So thank you for that.
Jill: So to me, I really liked this venue, especially for the broad talks. One thing compared to Boston— so Boston was a little bit larger than this, and it was like when I spoke, I was on a stage, and I was even more nervous. And I think a lot of that was because I felt a little bit disconnected from the audience. I wasn’t like one with the people. And so I really enjoyed I know that it gets hard because like you want to sell tickets, but then you want to keep it small and whatnot. But I really like this, this environment where you were just up close and personal with people and it felt more community-focused.
Mike: I was pretty thrilled that deep dish pizza was lunch on day 2. I mean, like, if I’m coming to Chicago, there better be some deep dish pizza. So mission accomplished.
Matty: [00:31:49] We did the first year. We had a little bit of deep dish pizza on the second day, and I felt really bad for J. Paul Reed because he was the last speaker before lunch on that day. And he got just like abducted with questions like after his talk. And then by the time he got to lunch, the pizza was— he’s like, I just came here for the pizza. And so, we specifically after the event, I went and the second day we’re like, all right, Paul, we’re gonna— and so, one of the organizer traditions of DevOps Days Chicago was falling asleep in pizza on the second day. So, I don’t know if we’re doing that this year, but because usually by the time you get to the end of day 2, you’re like— So, anybody in the audience have some thoughts? Like, what are some of your reactions? Actually, is there anyone who this is your first DevOps Day ever? Okay. Someone who’s— this is your first DevOps Day, want to tell us a little bit about your experience so far? If so, raise your hand and I’ll give you a microphone. Okay. So, I’m Mark. I’ve actually started going to conferences here in the last couple of years. I’ve been to ChefCon this year. Then this is my first DevOps Day. And quite honestly, I really enjoyed it because the feedback from you guys here, not so much you guys, but is really what I enjoyed. Networking with you guys, understanding how your company actually integrated DevOps, brought it onto your teams. What I find, it’s different for every company, but there’s a lot of tactical things to do along the way. I really enjoyed every talk here. Some of the close, what do you call these? Sorry. The open spaces. The open spaces, some of them can get kind of long when people just want to give their point of what’s going on at their company. But if you really have somebody who’s really strong at organizing and pushing those directions forward, you’ll find a difference in that. So that’s what I find, but I really enjoy my time here.
Mike: [00:33:35] Thanks.
Matty: Great, thank you. So I think, uh, we have time for a couple more insights, thoughts, questions, comments, problems with your life. We’re basically therapists.
Jill: Okay, well, I’m ready for that. Everybody get comfortable.
Matty: Um, hi, my name is Yasser. Uh, this is my first, uh, DevOps conference, uh, from St. One, it’s a great organization. I was recently involved with an event which it’s not easy to get everything right. One suggestion that I was noticing as a developer— so I’m a developer. I myself noticed that the— like the recruiting talk or the non-technical talks, I was more inclined towards and I kind of like them more. The more technical they were, I just for some reason kind of drew myself off. So, and one last comment, if you can get like sort of a rating for speakers for feedback, I don’t know if you have that already. I think we will be asking for that. If not, we haven’t sent our email out to you yet, so maybe we’ll include that. Or maybe like something, if you can have something live. Oh yeah, I could.
Mike: [00:34:46] Absolutely.
Matty: Well, we always figure like Twitter is good for that too. So you can always tweet up here.
Mike: So, I thought the comment on non-technical talks being more enjoyed was really interesting because it’s kind of been an arc and flow of how DevOpsDays has worked. Early on, it was very much— I guess there were a bunch of tools talks really early on, but culture really came in and crushed it. And like all the tool talks just got pushed out for DevOpsDays programming for a few years. And just now they’ve been coming back with a few more technical talks in the programs. And I like the mix. I like getting some good technical talks. The sad part about a technical talk is if you’re not into that specific technology, it kind of isn’t that relevant to you. Whereas usually if it’s a soft skill, like even if you’re not a hiring manager, you still care about how recruiting happens because those are humans you have to work with eventually. And so I think that I like to have a good mix. I don’t want it all one or all the other, but unfortunately sometimes it does miss the mark.
Matty: It’s an interesting thing and it happens with our show too, right? I’ll get a lot of like, oh, you guys, y’all need to talk way more deep tech on the show. And then they’ll be like, wow, you’re talking way too deep of tech. And I’m like, did you guys listen to the same show? We had the same thing. It was just a funny little anecdote about the first Chicago event is I had 2, a previous colleague of mine and then a customer of mine who came and I talked to them afterwards. And the first one was my previous colleague who works for kind of a smaller internet company here in Chicago. She came up to me and she’s like, you know, this stuff is cool and all, but it really seems like it’s way more for the big companies. And then my customer works for a very large insurance firm here in Chicago, came up to me and he’s like, yeah, this DevOps stuff seems cool and all, but it really seems like it’s for the small companies. And I was like, and you all were at the exact same event, saw the exact same stuff, and really what you were looking for was the why this doesn’t apply to me kind of thing. So you had to— yeah, and then you, and then I think we need to wrap up. Hi everyone, my name is Dongmin Liu. I’m from Critical Mass. So Mike, he introduced this one. So that’s First time here. So I’ve been through other, you know, conference. This surprised me is about non-technical part. So always like you can read a book or watch YouTube, something to get training for certain technology. But like a recruiting thing or the human nature, how you— sometimes it’s not about technology you try to convince to adopt. It’s more like how you package convince other teams. I think that’s the harder part. Yeah, I do feel that’s a real benefit. Yeah. Great. So we need to wrap up because we need everybody to be able to get to their next open spaces. A couple of things, if you are watching this live, which you might be, don’t forget that we have the CFPs for DevOps Days Detroit, Madison, Tel Aviv, Cape Town, and Berlin are all closing today. So go to devopsdays.org/speaking. To submit those. The code ADO2016 should get you 20% off at pretty much any DevOps Days, so go ahead and try that. But it especially is true about Madison, so do that.
Mike: [00:37:47] It’s a special 20% off.
Matty: It’s a special 20% off. And also, you can use the code ADO2016 for 20% off the upcoming O’Reilly Security or Velocity conferences as well. And we’re not gonna do checkouts or retro because we didn’t talk about it. So just remember that we do have a newsletter. You can sign up for it at arresteddevops.com/bananastand. I send it out sometimes. But the good news is I can guarantee you don’t get spammed from too much mail from it. And you can buy cool Arrested DevOps stuff at store.arresteddevops.com. We’ve got a bunch of new t-shirts including the Bike Shed t-shirt that I think is cool but nobody’s bought yet, but you should because I like it. And we have mugs and stuff. Thanks to our sponsors. You can check them out at arresteddevops.com/10thmagnitude, arresteddevops.com/hired, and arresteddevops.com/datadog. Thanks Mike, Jill, and Nell who had to leave for being our guests. Thanks to everybody who came for the recording and participated. That was awesome. You can leave us a review in the iTunes Store at arresteddevops.com/itunes. That actually does help us to do that. And we’re on Twitter @ArrestedDevOps. So let us know. And so I’m Matt, @MattStratton. And remember, there is always DevOps in the bananas. We’re done. Thanks everybody.
