Click a paragraph to jump to that point in the audio.
Matty: [00:00:08] Welcome to Arrested DevOps, episode 38, Career DevOps. I’m your co-host, Matt Stratton, @MattStratton on Twitter.
Trevor: And I’m your co-host, Trevor Hess, @TrevorGHess on Twitter. Arrested DevOps is brought to you by TenthMagnitude, a cloud services company that figures if you’re listening to this podcast, You must be pretty cool. You can find out about joining our cloud services team at arresteddevops.com/10thmagnitude.
Matty: This episode is also sponsored by PagerDuty. PagerDuty eliminates the noise, chaos, and manual processes across the entire incident lifecycle to decrease resolution time. PagerDuty is trusted by companies like Etsy, Nike, and GitHub. To sign up for a free 14-day trial, visit arresteddevops.com/pagerduty.
Trevor: Tonight, we’ll be talking with Jeff Hackert about developing your career in DevOps, or just in general. DevOps is a hot career choice these days, and a lot of folks want to know how to grow their career. Jeff, can you tell us a little bit about your background?
Jeff: [00:01:09] Yeah, hi. My name is Jeff Hackert, and I’m the Director of Learning Experiences at Chef. Yeah, I’ve been, I’ve been around the internets for a while. I’ve been hooking things up since, I guess, for about 30 years. So I’ve worked with software development teams and infrastructure teams as an engineer and as a people manager, yeah, for a little over 30 years. And at Chef, my role is an interesting role. It’s partly working with the people organization and partly working with managers to develop the management skill set. So some experiential coaching.
Trevor: So what can you tell us about having a career in DevOps? You know, like, for me right now, I’m kind of going through this, like, internal existential crisis where I don’t necessarily feel quite like a developer anymore, but I’m not really an ops person, and now I’m starting to wonder if I am the DevOps. So where is that line?
Jeff: Yeah, I don’t know. It’s a good question. I think Well, first of all, I guess I would say that just thinking about career development within the workplace is not something that’s super common. I was reading a study just a month or so ago, sort of preparing for some stuff internally at Chef, and in that study nearly half the respondents said that any sort of personal development wasn’t at all taken seriously by their current employer, and something like 65-66% admitted that they had no development plan in place. I read another study that was from exit interviews of a very large enterprise organization, and fewer than 5% responded that they’d received any sort of career counseling at all from their managers in the entire time of their employment. So I think in some ways it’s very rare. So if you’re wondering right now who you are, you’re in a good spot to start down this road, sort of like to take the reins yourself, which is something that I think people don’t often do. Given that exit interview, so less than 5% of people got any sort of direct feedback from their bosses, I wonder how many people within that organization before they were asked the question had considered sort of driving their own career.
Trevor: [00:03:35] As one of my former managers would have put it, there are definitely people who are hungry and really interested in advancing their career, but there are also those people who are so content with what they’re doing that they don’t— I don’t see them thinking about that next step. And that’s a point I hadn’t really considered.
Matty: Well, can we— before we kind of maybe talk about like how to advance your career or things like that, maybe we might talk about what career development in general means and what it might mean to some, some different people. Because to Trevor’s point, we’ve all got different thoughts on, I guess, depending on where you are in your career as to how you develop it and, and how you might identify that. So maybe, maybe let’s talk about how to figure out what’s it— what, what career development means to you, because I don’t think it’s a matter of like Jeff or Trevor or me defining career development because we’re different people, but what might— Heckert, what might be some things that someone could do to figure out what that means to them?
Jeff: [00:04:39] Well, yeah, it’s a good question. Here’s what I would say. I think that just to touch on what Trevor was talking about, I think that we enter into the workplace and in general We have a strong desire to learn, probably a strong work ethic, and usually that’s enough. And I’ve interviewed now hundreds, probably hundreds, maybe we’re in the 3 digits, maybe we’re at 4 digits. I’ve interviewed a lot of people and gone over their ideas around personal development, and what I hear frequently said is, well, I’ve never really thought about it before. I just sort of, you know, these opportunities have arisen as a result of whatever I’m doing, and I’ve just sort of flowed with my career. And sadly, a lot of times that’s somebody who’s now in like a manager position who’s like, how did I get here? Like, well, okay, well, let’s retrace the steps. And they’re like, well, I just went with the flow. And the next thing you know, you know, on the back of a successful project or on the back of some very good work in a particular area, Suddenly they’re leading a team. And then it feels like— it sounds to me a little bit like crowdsurfing at a show. You just sort of throw yourself back and you let your manager or you let the company sort of define where you go. And that’s one way to do it. And if your interests lead you in good directions and people are generally supportive, you could end up in a pretty good spot. There’s a lot of ifs in that description, which I think is kind of dangerous. So another way to go about it is to do something that I think that people are normally afraid to do, and that is to get declarative about who you are and why you’re doing what you’re doing. It is— so I guess I just want to throw that out there for a second and see how the two of you respond. So if I just show up in your place of employment and I’m like, hey, I’d like you to write me, I don’t know, 6, 8 paragraphs about who you are, and what you want to do, and I’d like you to make that available to everybody in the company. How are you going to feel about that?
Matty: [00:06:55] I’m going to feel pretty good because I already did it. I’m one of the people that already did it on my team. But that’s because we already do that. But I can tell you about— but first, I guess I’d like to— snarkiness aside, before I reply, because I could speak from what it was like to do it, let’s let Trevor answer.
Trevor: Yeah, so given that, So it would honestly— I think now I have an answer for that question. But I think 2 months ago, I wouldn’t have had an answer to that question. And it’s one of those things where it’s sort of hard to reconcile that because it’s such a different way of thinking. So it’s— recently, I was promoted to senior consultant. And sort of that was, that was kind of my, like, my goal out of college was because people were starting to tell me, you know, that I was good and that I could do all these things. And so my goal was, you know, how quickly can I get to, to the title?
Jeff: Yeah.
Trevor: But now that I’m at the title, I also realized that the title has nothing to do with reality.
Matty: [00:07:59] It’s like, it’s like I had massive respect for MCSEs till I became one. Oh, okay. Right.
Trevor: Like, I’m still in the same, the same boat as as I was before where, you know, I know nothing but I can answer questions and find answers.
Matty: You get paid more for knowing nothing?
Trevor: Socrates would be proud.
Jeff: Yeah.
Trevor: I think, like I said, now I think I have an answer to that question and I have— I’m luckily in a position where I can facilitate that for myself.
Jeff: Yeah. Well, that’s good. It’s not— yeah, so was it scary? Sorry, can I ask really quickly, Matt? Was it— Did that question, like when it came up, how comfortable were you in starting to formulate that answer? What was the process like of understanding who you wanted to be, and then did you have to declare it? Like did you have to let anyone know, hey, I want to be a senior consultant, or did you get the title conferred?
Trevor: [00:09:02] So I had to ask for it, but I think the answer I’ve come to since then Yeah, I actually— I had a conversation with John Cowie about it last time— well, one of the last times I was in London. It was, you know, it was kind of scary to admit, like, you know, maybe there’s more of a niche that I want to focus on, and it’s, you know, it’s not necessarily, you know, writing, you know, ASP applications.
Jeff: Right. There’s something interesting about saying yes to a particular thing because, you know, we’re saying no That’s right. A lot of other things. Matt, what was your experience like when, when, when I, uh, or somebody in an organization that I put pressure on asked you to do that thing?
Matty: Well, one thing that I thought was interesting when we, when we did that at Schaff was, so you made a comment, this is what I wanted to, I was gonna follow up with Trevor and, and say how he would feel about this particular part, because you specifically called out the, and this be shared with the entire organization. Yeah, because usually when we talk about coming up with a development plan or whatever, it’s like this thing you do with your boss. While I don’t think it was necessarily explicitly made clear, and if it was supposed to be and my boss did this wrong, then I hope I’m not getting him in trouble.
Jeff: [00:10:24] How terrible would that be?
Matty: So many people— yeah, how much trouble is he gonna get with you, right?
Jeff: I’m making notes.
Trevor: What happened to blameless, Matt?
Matty: Yeah, right. Well, but what I was gonna say, but what was interesting, and I just want to make this point, was I don’t recall being told that it had to be shared, but I saw that so many people had shared theirs that it was kind of natural for me to do it. So I was like, oh, well, I actually, I saw that as a challenge. Like, well, I’ll do this publicly because that makes me uncomfortable. Yeah. Because it made it very hard to be honest. I mean, and I don’t mean like to not— I mean, let me put it this way. Made it be very hard to be very vulnerable in it. Let’s put it that way. That’s a better part. Instead of, you know, about saying— and it also made it hard to be declarative in both ways, both on the things that are like, hey, this is something that— this is a weakness, or this is an area of improvement. You know, this is something I suck at and I don’t want to suck at anymore, right? It’s how I looked at some of the things. And being able to be really, you know, brutally honest about that was, was kind of hard to do in public. Well, but what was actually harder now that I think about it was being brutally honest about the strengths. Yeah, because it comes— it made me feel like it’s something that I would have no problem writing up in a document that was going to my boss or my boss’s boss. But something that was going to the whole company, I felt like, especially working in a company where I feel very privileged to work with really, really great people, so it’s kind of hard, like it’s very hard for me. I hate to say brat, right? You know what I mean? Like I feel like I’m like, oh, it’s one thing if I was telling, you know, my boss this, but now I’m going to have this be read by Jez and, you know, Julian Dunn and, you know, and who knows, maybe Adam or whatever, and they’re going to be like Is that true? But I got over it. The one thing that was really awesome about it being shared with the company, or at least within my team— I don’t know if anybody outside— actually, I do think a couple people outside my team read mine because I do vaguely remember getting some notes like, hey, I really like how you wrote this, or this was an interesting idea, or, you know, some kind of a thing— was that there’s accountability that went into that where my team now knows, or my coworkers without me having to request it, if they choose to want to help me with those things, to help me be accountable, they know things I want to work on. And I made a similar comment when I was helping a coworker with his, when I was just sort of looking at it, I was like, hey, here’s some unsolicited feedback, but how could somebody help you with this particular thing? So if I’m reading this and I want to be a good teammate for you, how can I, how can I hold you accountable? Right? I mean, in a really uplifting way, not a like, so did you do your TPS reports? But be like, hey, I know you say you want to work on more open source, contribute to more open source projects. Have you had it? What are some cool ones you’ve done lately? And if you go, oh yeah, you’re right. Sorry, I forgot I was supposed to do that. That’s actually like better. You know, I don’t know. I think it’s really scary to share it, but I see the power.
Trevor: [00:13:40] One of the things we did when I started at Tenth was kind of put our, like, our goals and what we want to see as a team together, kind of our, like, our internal team plan and mission statement kind of thing. And one of the first, one of the big things we talked about was how we all need to kind of, we need to be our own advocate such that we can support each other. But we didn’t, we didn’t go this step further to advocate, to sit down and actually compile and advocate our goals so that we could support each other.
Jeff: Well, that’s actually a great segue. What I thought I would do is walk back just a little bit and explain to people what the it was that Matt went through and just talk about how we do career development at Chef a little bit. So the it that Matt is referring to is— it might as well be called the TPS document. We call it lovingly the PDP. Which is Personal Development Plan. Because naming things is hard. We could have named it like Astro Kittens or something, but I just felt like the name is probably the least—
Matty: [00:14:47] We already have enough things with silly names at Chef that we need to actually sound like a business sometimes.
Jeff: Bacon yada yada development something, right? But it’s just— so this document is is really simply— it’s very simple in terms of its structure. So about, you know, maybe about 40% at the top is your aspirational goals, like where is it that you’re going with your career. So this could be what brought you to this particular company, what has brought you to this particular role, and where do you see that developing. And then the middle section is focused on strengths and weaknesses. So the areas where you think you’re really strong, it sometimes comes in the form of a list of things that you are sort of willing to do for yourself and others. Normally when I join a new team, I create a list of things that you can expect from me, and that list is things I will do and some things I won’t, right? So it cuts both ways, and then at the very bottom of the document is just some link to maybe target conditions or just some area that someone could look at what you’re doing or what you’re trying to achieve in a more concrete way, not as a status mechanism but as a way of sort of tying things together. And the reason for that is that, you know, you could have somebody really, really give you a lot of exposition in terms of where they want to go. They can really pour their heart out at the top of that document. They’re like, I want to be the president. For all of these reasons, and they could be super compelling reasons. And then you’d look at all their strengths and you’d be like, oh, I’m in, right? And then maybe look at their weaknesses and like, wow, with a little development, this could be the greatest president ever. And then at the bottom, they’re like, the list of things is, you know, I’m washing dishes on a regular basis. I guess I’m being a little silly, but they’re not doing anything that’s actually Completely unrelated. So in the case of an engineer, you could have someone who aspires to be a very strong engineer who, for reasons, is doing maybe the scut work for the team and is not getting a chance to do the kind of engineering work that they want to be doing. And so being able to sort of first of all say that, and second of all be able to take action on it, can be really powerful. I would say though that people are often people are often nervous or scared. Scared to expose— Matt, you talked about being vulnerable. It’s this huge act of vulnerability to say who you want to be in an organization. I think the single biggest reason is that we’re afraid— like, this sounds terrible, but in some organizations you’re just afraid that someone’s going to like, you know, what is the old move your keys, right? Someone’s going to Someone’s going to steal your cheese. So if you’re like, hey, I want to be the person that does the thing, there’s first of all that fear of will I be supported, will I be blocked, right? Will people take me seriously? And then when you’re talking about strengths and weaknesses, often people feel like it’s the weaknesses that are going to be difficult to talk about. But in fact, it’s literally the opposite. I’ve seen engineers just write pages about areas where they think they’re weak, but are very reticent to talk about their strengths. Some of that is humility, and I think that that’s an important quality, but some of that is born from a different— it’s born from those ideas of imposter syndrome, or I’m not as good as my peers, and I don’t know that that’s healthy. It’s a thing that we see in the industry, and we make lots of jokes and references to it, but I think those concepts can hold us back. So at Chef, we do this document, and the concept is— or the way that we work it is this. I say to the people managers at Chef, every engineer is responsible for their career development. Full stop. And then I tell them, and you are 100% responsible for the career development of every engineer on your team. And I think that that is the only way that you can work it. Both those things have to be simultaneously true. In order to get really the best outcomes for the people that you’re working with. So from your own side, it’s good to get in touch with and invested in who you want to be, and to communicate that to your team, mainly because they’re going to help you. You’ve got to take that trust fall a little bit, but your team is going to help you. I recognize that there are some organizations in which that may not be true. I don’t— I wouldn’t know what to do in that case in the time we have allotted to talk. But if you’re listening and that is your experience, I’m super happy to talk with you. But in general, your team wants to help you. But before they can help you, they need to know who you are. And just to sort of bring us back, I think that’s the place where people tend to get stuck. So Trevor, when you talked to John Cowie, who by the way, I could not recommend a better career counselor or a less handsome one. So when you talked to him, was it your dream? And is it now your dream fulfilled to be a senior consultant?
Trevor: [00:20:22] I mean, I think at that moment it was, and then there was kind of a week or so where I was like, well, okay, now what?
Jeff: Right.
Trevor: And so that’s kind of like, you know, figuring out what the— what kind of the next steps are, even though a lot of those kind of the next steps I want to take, we identified in that same conversation.
Jeff: Mm-hmm.
Trevor: To be honest, I don’t know if John realizes that that was what the conversation became for me, but that was what the conversation became for me.
Matty: Yeah.
Jeff: And how far out can you see on your sort of career horizon? Like, what do you see— where do you see yourself in terms of developing as a senior engineer? Or sorry, as a senior consultant. What does that entail?
Trevor: So that’s a better question. So more what I’m looking at is the sort of things I want to work on and less— like, I’ve got less vision into what the next step is in terms of a title. So much as the things I want to be working with and the things I want to be contributing to. I like to lead. I like to build. I like to do those sorts of things. And so I really want to focus on making those things better so that I can take whatever the next step is in terms of position, be that lead something or director of something or whatever. Whatever comes next.
Jeff: [00:21:50] I think it’s really—
Trevor: Matt snickering over there.
Matty: I was, I was snickering at the, like, it’s, it’s still like about the title, you know, but, but that’s hard, right? I totally get it because it’s hard to know what does that, what does that mean because titles are hard, right? Yep.
Trevor: I mean, ultimately they’re meaningless.
Matty: Well, because they mean different things in different places, you know, and Because the thing is, like, if you wanted to say, like, well, it’s important to me to have the word director in my title, you could figure out a place to go work and be the director of something, you know, and it could be— that could just be like, that’s what we call— but you could be the one engineer writing code for this startup and they’d be like, sure, we’ll call you director of whatever the hell you want to be called, but we’re still paying you $60 grand and options.
Jeff: Is it okay if we talk about that for just a second? I think what I hear, Trevor, and maybe I’m just mapping what I’ve heard others say onto you right in this moment, so let me know if that’s the case, right? Yeah. But the title— titles are usually about getting enough positional authority to be able to make the thing that you want to make real.
Matty: [00:23:00] Yeah.
Jeff: And so I will say again, like, 2 contradictory things in one sentence. Right, that titles don’t matter, and they absolutely matter. So you have to know your environment. So when you’re thinking about title though, I think the best way to think about it is thinking about it in terms of what you’re trying to accomplish. Where I see people get stuck, I think Matt makes a great point, you can fail up. What do they call it? They call it failing to your to the highest level of incompetence.
Matty: The Peter Principle, right?
Jeff: Exactly.
Matty: You’re promoted to your level of incompetence.
Jeff: Exactly, which, you know, is fair. Seems like what we all deserve. But no, like, you can, as Matt was saying, you can find the title, but what you really want is enough positional authority. And so that can come through leadership through influence. It can come through actual authority conferred via title, but I have found in my own career that that has been harder to work with.
Trevor: [00:24:12] So just in terms of like raw material, I think I have the respect of my peers where I have a lot of that sort of positional authority already. It’s sort of, I mean, it’s again, it’s sort of that like that next step where like it’s acknowledged that I’m, you know, I don’t know, it’s sort of, it’s the stupid confirmation piece, which, yeah, and it certainly, there’s absolutely going to be places where you can get, you know, for lack of a better term, a bullshit title, like that’s pure bullshit, you know, I can be the director of flowers.
Jeff: Yeah, actually, that’s like, is that a job that I could have? Yeah, right?
Matty: It would actually be a really hard job.
Jeff: Part program, part executive.
Matty: Those folks work for a living.
Jeff: Well, you know, here’s the thing, that recognition is real, and there’s nothing wrong with wanting it. As a matter of fact, I think the better we can get about being explicit about what we need, I think the more willing people are going to be really to help us get where we want to go. And I don’t mean that in some magical way. I think that if you can marry sort of a vision of yourself with a certain amount of flexibility or authority in a title and a thing becoming real in the world and you can make that thing manifest and people want that thing, they’re going to come with you. It never works out when you want to be the assistant to the regional director. That’s all you want to be. And you’re chasing that title. But when you can marry the need or the desire for the position to the thing, and then you make the thing, getting that recognition is sweet. And I think that’s a fine reason to want to do something. I think starting with that position of, I want to build a thing— because I think we’re talking mainly about engineers here— starting with that position of, I want to see a thing in the world, and this is what I think it will take to get me there. Is a great way of going through that process. And if you make it explicit early, I think you get more help, which is why we do the PDP process at Chev. It’s a way of taking some— you know the cheese thing, you know the Who Moved My Cheese? Yeah, there was a book and there was cartoons and some mice and some cheese being moved from cheese station to station.
Matty: [00:26:43] It’s a self-improvement book by Spencer Johnson.
Jeff: It is that, yeah. So I think that’s a little bit real, like that fear of talking about what you want to do because, you know, for many reasons is a real thing. It can be real too in your environment that communicating or signaling interest in an area can sometimes be dangerous. I think we have to cultivate, at least within the teams that we’re working on, enough trust within that unit to be able to talk about those things. And so Matt was talking about making these things public. It’s not a requirement at Chef that your development plan be public.
Matty: Okay, good, so I didn’t get my manager in trouble.
Jeff: You didn’t, no. Not everybody wants to do that.
Matty: No, I totally get that. I was just— the way that you expressed it made me wonder if— but it was— I noticed that it was— that people did do that. They did do that. It was pretty powerful to me to do it.
Jeff: Yeah, I think that document is the most helpful when it’s public because I think you get the most feedback. One aspect of what you’re doing in terms of career development is you’re opening yourself up, like you were talking about both giving and getting feedback. Feedback without the context of what you’re trying to be is sort of not that helpful, right? So just imagine you’re pounding away at some Scala because that’s a thing, right? And somebody leans over and they give you some really good feedback on your Scala code. And let’s say that it’s, you know, it’s pretty critical. So there’s 2 ways that you can maybe receive that feedback. So one is you could be like, oh, thank you so much, because it is my goal to become the greatest Scala developer ever. Another way you could receive that feedback is, I actually don’t. I just want to get this thing done. I don’t enjoy working in this language. So it would be like, thank you for the feedback, but it’s not my life’s calling, it’s not my passion. And I think it’s important to know those things because otherwise— have you ever been in that conversation where someone wants to give you some guidance but you don’t care about the thing?
Matty: [00:28:55] You’re like, yeah, I don’t really give a crap about that.
Jeff: Yeah, so you’re getting a lot of rich and enthusiastic feedback on the TPS report you just crafted, and you don’t— you’re not that interested. And if that person knew that, they probably wouldn’t invest in that way, or they might invest in a different way. They might take a different approach in terms of why the code should look differently than it does. Creating that groundwork by sort of letting people know who you are, I think, is super, super important.
Matty: I think another thing that I kind of would like to touch on And maybe it’s, maybe it’s been beaten to death, but it, but in, and in certain circles, I think we understand this and others we don’t. But it’s this idea of, of again going back all the way back to the beginning of the conversation of what is, does it mean to develop your career. And it’s, it’s this sort of this thing of, you know, I see lots of, lots of people will post about stuff like this about, hey, you know, I got promoted, now I’m the manager. Yeah. You know, and it’s this— that, first of all, the career path is that you are— and again, with the Peter Principle, right? And there’s the corollary or the extension of that that Scott Adams wrote, which was the Dilbert Principle, which is an organization promotes its incompetence to the place where they can do the least amount of damage, i.e., management.
Jeff: [00:30:18] Oh well. Yeah. So talk about that for a minute because you can do a lot— you can wreak a lot of havoc as a manager.
Matty: Yeah, and, and, but there was a, there’s a really interesting article that Lindsay Holmwood wrote back— this was last September, this was going around the Twitterverse, and I’ll put a link in the show notes— but it’s called It’s Not a Promotion, It’s a Career Change.
Jeff: Yeah.
Matty: And I have a lot of feels about this because I’ve, I’ve done it, and I, I went down kind of the, you know, the belief that, you know, the way to move up my career is to go up, up, up the ziggurat, you know, through through management, and I did. I kind of hated it and then decided, okay, I’m going to go back to being an individual contributor in anything I do. And one of the things that’s kind of challenging is it’s hard to get out of that. So I went through this role, through this world where I went in and I spent most of my life as an engineer, then was a lead. And I think a team lead is still not management. You’re still an engineer. You just You know, because you’re generally not a people manager.
Jeff: [00:31:27] You get the engineering cap.
Matty: Right, you’re still doing some real work, but you’re not dealing with people problems. You’re not doing that.
Jeff: Not too much, right?
Matty: Right, yeah. Then became a manager, but it was— that was a whole other problem of being one of those 50/50 managers, which isn’t a thing, but we’ll leave that alone. Became a director, and I had a— and then there was a leadership change, and my new boss said, Matt, I think managing people is not what gets you out of bed and brings you into the office every day. And I said, you’re right. We changed— I changed roles and left that company. I went to go work as an individual consultant with Tenth and relatively quickly ended up getting promoted and ended up hiring a bunch of people, ended up managing a bunch of people. And I was kind of— and that’s not why I left Tenth by any means. It was, it was okay. But I’ve had this conversation at Chef multiple times.
Trevor: No, we discovered that was because I joined.
Matty: Yeah, that’s right, I get that from you. But I’ve told my boss, and we’ve talked about this, and I was like, I don’t like it, right? I don’t like managing people. That’s not my thing. And I think— and I’m not great at it. I mean, I think I’m okay at it, but the trick is to say, how do we realize both as an organization allow for that to say like we want people to be able to develop and contribute more and more, but they may not be able— but just because they’re great at, you know, they’re probably not good managers.
Jeff: [00:32:59] Yeah, Matt, that’s a great point. Like we, I think we often confuse performance for career— performance management for career development, and they’re not the same thing. So that article was a great article, and it is for sure real. When you change titles from from engineer, even from eng lead— sorry, from a team lead to an engineering manager, you have changed your career. Many, many very, very competent software developers have said to me upon becoming managers, when will I find time to code? And my answer is, I don’t know, but not on this job. You’re not going to find it anywhere on this job, right? Which is, you know, not exactly true, but it’s largely true. And that’s because from my perspective, what you’re taking on are sort of 3— there’s 3 core areas. There’s first of all the people development, right, really ensuring that the people that are building the products that you’re focused on are cared for, right. You have a genuine interest in their well-being, you understand who they are and where they’re trying to go. And you are literally spending some portion of every day trying to ensure that they can get there. So that’s one aspect of it. The other is sort of process, and if you’re lucky, you know, so that’s like development process, right? So maybe you’re helping the team to improve in terms of their understanding of the work they do, helping to make it more visible. And then if you’re lucky, maybe you’re doing some architecture, maybe you’re doing some product management, as part of your relationship with the team, but not always, right? So the core—
Matty: [00:34:46] the other thing, I just want to ask a quick question about that, because I’ve been in scenarios where that was a problem, where I was in a place where the understanding was, well, our dev managers were also our architects, and the thing that I saw was, well, when you give somebody 2 jobs, they’re gonna only do one of them. And it was either— we would have scenarios where either they were focused on architecture And then they were managing—
Trevor: What’s the Ron Swanson quote?
Jeff: Yeah. What’s the Ron Swanson quote?
Trevor: Don’t half-ass 2 things, whole-ass one thing.
Matty: Exactly. And so we would have that scenario would happen in both ways where either they would half-ass managing their people because they were being good architects or they were being good managers and not being architects. And so I don’t know. I think, Jeff, I think you have a different opinion on the capability of being able to do that? Well, I’m curious.
Jeff: I think we should, I guess, here’s what I would say. I would say the first thing that has to go in that equation if you’re struggling at all is the part that’s married to the product, right. So because your core responsibility is to the humans that are in your stewardship. So I guess I see the job in a particular way, and so the job is to help to provide context around the product and to help to remove blocks. So sometimes providing architectural guidance or helping a team to sort of look at what they’re building is helpful. I think this is radically different than what we think of when we think of like an enterprise architect.
Matty: [00:36:27] Okay, that’s what I was just going to say. Okay, so you were saying providing architectural guidance and mentorship and things like that versus I was describing it as if it was to say, no, your job is you are a software architect and you are a manager.
Jeff: Yeah, I have the feelings because— and I really just want to apologize to people who are architects because I know you’re lovely people and your parents love you and your kids love you. But, you know, that role, it requires a lot of attention. I would just say. And you should only do that thing. And only that thing.
Matty: If there is one thing that you should be whole-assing, it’s architecture.
Jeff: It’s architecture, and you should be doing that in a company that loves and needs architects. Yeah. But I feel like dev process and people development are really the focus, and I think those 2 areas are important because they are the 2 areas where our psychology tends to trip us up the most. Not that your manager is a psychologist, but that they are the hardest to navigate, they are the most people-centric. So allowing your team to understand who you are and what you are working on, there are 2 facets for that. There is the actual sort of tactical, what am I working on and how do I visualize that to the rest of the people that I am working with. And then there is the meta, right, who am I, why am I here, and where am I trying to go. And I think those are 2 very important areas. That a manager acts as a steward for. There was a great Project Oxygen, which is where Google’s sort of 8 things came from that people were passing around. Those 8 sort of qualities of a manager I think are a really good example. You know, Google had no manager role, and then when in their characteristic of Google, when they decided that maybe something was missing, they should figure out what it was. They led with the analytics, and they were able through surveys and their people operations team was able to sort of figure out a list of these 8 things. I don’t think you’ll find architecture anywhere on that list, right, but that list is wholly devoted to making the lives of the people on these teams better. And I don’t mean that in like a general fuzzy way like bring cupcakes or bacon and scotch or whatever it is that that people enjoy. Does it hurt though? Those things don’t hurt, they’re good, yes. I’m vegetarian, so the bacon not so good, but everything else.
Matty: [00:39:00] You could do vegan bacon.
Jeff: Vegan bacon. But anyway, it’s really focused on— sorry, just to get back to that. Those 8 things are about the people. This is really the message of Agile and XP. The context is the practice, right, the practice of software development, the practice of infrastructure design and deployment. But within that context, it’s really about the people. Ken Schwaber, there’s this great quote in the little Scrum booklet, the Beetle Book, you know, which I think is out of print now, but it’s a good one. But Ken says, he’s like, there are 3 things in a software development project, there’s 3 sources of variation. One is requirements. You know, they’re going to change and they’re probably going to change late. 2 is the underlying tech. The tech is always changing. And this is true. Number 3, people. And he doesn’t just say people. He’s like, people individually and people working together as teams. And so there’s a lot of variation in how we work together. And navigating that, getting to a place where we’re performing effectively or even to a place that we would call high performance requires that we understand each other really well within the context of what we do. A fatal mistake that I have seen a lot of Agile sort of coaches make is that mistake where they think that they become— like you act as somehow a psychologist or a parent for a team. I think that’s a mistake. It has to be in the context of the work you’re doing, which means that, you know, I don’t know if I’ve dug myself into a little bit of a hole here, but it means that you need to understand who the person sitting next to you, like when you’re pairing, you need to understand a little bit about the motivation of that person in order to be able to relate to what they’re doing and to help them to learn or to learn from what they’re doing.
Trevor: [00:41:05] So I completely agree with that. I think knowing a little bit of the psychological component can also be helpful though. So one of my favorite tools is doing an emotional check-in with your team. And so there’s a— it’s a— we’ve talked about the McCarthy Show and the Core Protocols before, but they have this thing called the— this check-in protocol. Where you do this, you can use any combination of the 4 words mad, glad, sad, and afraid, or you can pass, to describe your current emotional state.
Jeff: Yeah, coupled with being checked in or checked out, right?
Trevor: Right.
Jeff: This is one of my favorite exercises. So first of all, Jim, if you’re listening, I don’t think you are, but if you are, I love you. I talked to him on the phone once during my boot camp. Well, so I love the core protocols. I have not— so I know Jim. I love the protocols. I’ve talked to Jim on the Facebooks from time to time. I haven’t done it, but I’ve worked with engineers that have been through the boot camp. Yeah, I think that check-in process is super, super important. I talk about this at work sometimes, and I can tell by the responses that I get, like I can tell by the face on the other side, they’re like, I don’t know. But I think it’s really important.
Trevor: [00:42:30] I think people are weirded out by it for like the first couple times, and then like when they finally get to that day when someone says like, I’m sad today, or like someone admits that they’re mad, and you see their actions that day painted with the emotional context of their day, and things fall into place. You understand the person who said they’re mad that day Yeah, they are. They actually are a little on edge and it’s not your fault. They’re just— they’re mad today.
Jeff: There’s a lot of power in that expression. You know, there’s like 7 faces that reveal emotional content. They come with the human equipment. And this is funny, like I learned that both from Jim McCarthy but I also learned it from a Tibetan monk, which sounds ridiculous but it happens to be true, right? And so the context in which it came from the monk was that he was talking about one of his teachers and how that teacher scared him, like when he was a kid in the monastery, you know. And this led to a conversation of how people’s facial expressions, devoid of your understanding the emotional, the actual emotional content, produces an emotional response in you. So my thinking face could appear to be an angry face to you, right? And so you tell me something and I give you my thinking face back and you walk away wondering why I hate you, right? Or I just look over at you while I’m running through a problem and we happen to make eye contact and I have the grimace of thinking on and you’re like, what’s going on, right? And in that moment No, now we’re not working anymore, at least I’m not, right? I’m focused on some story in my head about why you don’t like me, right? And there’s no place for that to go unless we accidentally hash it out. So I think Jim was really, really onto something, and in a way the PDP is that process writ very large, right? It’s not the moment-to-moment or the daily emotional content, But it is really the emotional content and the theme of what you’re trying to accomplish.
Trevor: [00:44:50] But I mean, when you and Matt were talking about kind of the content of that, I immediately thought of the personal alignment from the core protocols.
Matty: Yeah.
Trevor: I mean, it may not be a specific, like, I want to be better at Ruby sort of goal, but that, like— I remember when I did boot camp, my personal alignment was to love myself. Yeah. And that was like, that was a good driving force for 6 months, you know, to kind of like really understand and grok that and be better about it.
Jeff: I did not expect this conversation to go here, but yeah, I completely agree. Getting comfortable with who you are and who you want to be will— doing that with your team, for sure, will lead to better outcomes. It’ll lead to better outcomes because you’ll have a better understanding of each other.
Trevor: Right.
Jeff: I have watched all the shenanigans in my career. Like, I have seen— it’s not good what I’ve seen, right? I’ve seen people, you know, really angry and upset and frustrated with each other, and the source of the frustration was not in the people they were frustrated with. Nearly always it’s misunderstandings. Like, it’s almost Rarely, it has happened, but it’s rare that you get someone whose skills or disposition are just a really bad match. That sometimes happens, but that is really rare compared to the number of times in which disharmony occurs on a team simply because they don’t have the ability to check in in the way that you described. And it’s check in at the meta, right, where am I going? Sometimes sadly it’s even checking in on the day-to-day. Inappropriate— sorry, I know we’ve gone into a little hole here, but inappropriate sharing in your stand-up can drive people crazy. If no one tells you, then you’re like, my dog, I’m going to get my dog washed today, that’s a thing I’m going to do. And everybody’s listening to you, nobody’s saying anything, and you’re like, man, these people really care about the details of my life. And inside they’re like, we super don’t, right? And if there’s no mechanism to have that conversation, it’s the same thing, I guess, or the corollary in what we’re talking about, Trevor, is when, you know, someone really wants to do a thing with a tech, and so they hijack the team to get that thing. Almost no difference, right? One is career-related, so the energy that goes into it is probably heavier. Probably is probably not accurate. Like in the moment, whatever you’re dealing with is probably pretty heavy. But people come at it from a position of their careers. And so if you ever have this creative abrasion that just goes off the rails, right? I want this database versus that database, or I want this technology versus that. And it’s not that the decisions aren’t important, they are important. But the way that those subjects get approached is with a lot— there’s a lot behind it and you have no access to sort of the history there.
Trevor: [00:48:06] Right.
Jeff: Yeah, and this I think is really a big part of the subtext for why career development is so important. The minute that you put that out there, I want to be— I don’t know, what’s a database that doesn’t exist anymore— I want to be the best Informix database guy in the world, right? You know, once you put that out there, then people are going to be like, oh, no wonder Hackert wants to put an Informix database in there.
Trevor: Because that’s what he wants to be.
Jeff: Right, no surprise, right? But when you come at it sideways, well, I don’t know, Informix is the greatest database ever, I super think it would work, and you don’t reveal that part, those tensions don’t get resolved in any kind of an open way.
Trevor: Absolutely. So we’re starting to run out of time. I wanted to ask one more question. Sure. And that was— so we talked at the beginning about the 5% of people who said they get zero career advice whatsoever. How do you know— from their management, at least— so how do you know if you’ve got a good manager? And what are they going to do to help you grow your career?
Jeff: [00:49:17] So you know you have a good manager because that manager expresses real concern. Real meaning they’re willing to take steps to help you move along the line that you’ve laid out. So you know you have a good manager because they, first of all, they create the opportunity for you to talk about career development separate from performance. Performance is definitely something you have to talk about, but when— if You know, sorry, the lazy manager is the one who’s like, well, assistant to the regional director, possibly, but look at the quality of your TPS report. Those quality conversations need to happen. They’re super important for all of our development— skills development, competency development. But they need to happen frequently, like all the time. And they should be separate from— unless, you know, Unless you’re asking to go, you know, I want to be the CEO. Like you’re asking for some crazy power leap, in which case someone might have to make that planer to you. But in general, that’s not going to be the case, right? In general, you’re going to be talking about wanting to move to a team lead, or you’re wanting to talk about moving to become a senior engineer, or a principal engineer, or something along these lines. Or maybe a people manager, if you grow up to be awesome like me. Just kidding. There are not a ton of quality people managers in the world. It’s a finite number and it’s very small. So if you’re interested in managing tech teams, now is a great time to enter into that career field. That’s just a plug for the profession. But anyway, there might have to be that conversation about why your skills don’t match the direct role that you’re trying to get to. But in general, you want performance feedback to be frequent and focused on the work that you’re actually doing. And you want the career development conversation to be open and directive. Like you want to know what the qualities that you need to develop are. So maybe you have really good ideas but are struggling to get those ideas heard by your team or adopted. And those are the areas where— so if it’s a matter of improving around leadership, it’s 2 things, right? It’s getting the feedback and the opportunity to be able to move forward with them. And I think that’s how you know you have a good manager is they know about your goals and they are trying to create opportunities for you to step in and gain the experience you need. In the end, leadership can’t be taught, right? You have to have experience. There’s a link that we can talk about later, but this is a hot subject because there are many, many books and there’s many schools that will That will teach you leadership, but I think it’s probably real that it requires a lot of experience to know how to lead, and you can’t get that experience if you don’t have somebody who has your best interest at heart, right?
Matty: [00:52:11] Sorry, I’m flailing around because I just saw the Blackhawks lost.
Jeff: Oh, I thought you were like, make that point, Hackert.
Matty: Yes, that’s right.
Jeff: All right, so does that help?
Matty: Yes. Right.
Jeff: What do you think, Trevor? Is that legit?
Trevor: I think so. I mean, of course, I’m reflecting upon how much of that is true for me presently and the people who manage me and being happy about that because I agree with that. And I agree that those are helpful in helping you move forward. So that’s right. In my head, I’m just thinking about like, yeah, yeah.
Jeff: Yeah, right. You know, I was poorly managed through probably about 18 years of my career. And I don’t think that that was intentional. I feel like the people who tried, tried really hard to do what they thought was the right thing. It wasn’t until, it wasn’t really until the last half of my career that I started to work with managers who were really invested in the growth of the people that they worked with. And I can tell you, I’ve worked for a few companies, not a ton of them, but some of them did better at this than others. Riot certainly, really a ton of care goes into, in an industry that’s maybe not known for this, right? A ton of care goes into how engineers are managed and how the role of engineering managers is conceived and prosecuted. There’s a ton of thought. So even if it’s not—
Trevor: [00:53:53] it seems like they do a pretty good job of that for all their staff. I mean, one of my close friends is now like one of the people in charge of organizing the events, and she like, she left the same company I was at before kind of not sure what she wanted to do, and She started working for Riot, and now she’s like, now she has her, like, the thing she wants to do with her career.
Jeff: Yeah. Yeah, there are good companies out there. That’s one. That is for sure true. Anyway, if you don’t have that environment, I think you’re going to have a tougher time, but I think you can start to cultivate it. So one thing I definitely believe is that you can do anything you want at the level of your team.
Trevor: Yeah, yeah, I think the, the, the last thought I would like to share would be, at my last job, was constantly being told that some magic person was going to come and solve everything, and that I should like, because, you know, I was—
Matty: [00:54:56] wait for that person.
Trevor: Exactly, that I should wait for that person and I shouldn’t just take the reins.
Matty: And are you, are you sure you were at a consulting company and not a synagogue? You know what I mean? Like, I didn’t realize that your old company was such a messianistic cult. Oh my God, I’m learning so much.
Trevor: I mean, that’s really what my— that was what the CTO was telling me, was like, oh yeah, we’ll get— we’re going to hire all these magic .NET engineers who are going to come in and solve all the problems. I could go and solve the problems. I feel like that was a big break on my progress.
Matty: That’s that whole myth of the 10x engineer, right? It’s this person that can do all the things that will get them in here eventually. I’ve had that too. I had a— when I was at a company, we were transitioning our stack from Windows and .NET to Linux and other things. So my, you know, the sysadmin team were primarily Windows folks, and the fellow who came, came over that ended up running the ops team after I ditched it to go be an individual contributor basically had the same thing. He’s like, well, we’re gonna hire in a bunch of Linux people because clearly you guys can’t figure this out. And it was like this again, never, never occurred to this person that someone might learn, or all these Windows admins might be running Linux boxes at home. As they were, you know, but it was like clearly it was just like, no, Trevor, like to your point, there’s some mythical magic admin out there who’s going to come in and fix all these problems. And the truth is everybody out there— well, first of all, these mythical people, maybe they exist, but they probably already have jobs and you’re probably not going to hire them away.
Trevor: [00:56:44] You said you’re right that the myth is the—
Matty: coming to your busted-ass shit. And be the asshole that comes in and does all the things. Nobody wants that job, right?
Jeff: Well, you know, the biggest problem there with that position, if you don’t mind my saying, is that people mistake, I think, they mistake the value of software development teams and of infrastructure teams, or really any creative team within an organization. So we tend to get super focused on the work output. As the value that the team provides. But it’s actually the learning function of the team that is of the most value. It’s the pedagogic function of the team that results in disruption, that results in innovation, that results in the things that people claim that they want. And so I love it when the CEO is like, there will be no learning. You, Trevor, you must wait. A learned person will arrive.
Trevor: It was super frustrating as you know, as I would have to meet those reins and and but still be told like no no no no.
Jeff: [00:57:50] Yeah. Well, I think we’re I think what we’re both saying and maybe not saying it out loud is that within your team, just disrupt your company.
Trevor: Yeah.
Jeff: Nice. All right.
Matty: All right. So with it with that, let’s we’re gonna need to wrap up. So wow, this is this was one of those episodes. It comes as no surprise that. Everything went so quickly and went so well. But let’s move into some checkouts and wrap it up here. So, Hackert, what do you got for us?
Jeff: Well, I just got to throw a shout out to Lisa Adkins. I’m here in beautiful San Diego for 3 days of a coaching intensive workshop with her. She wrote Coaching Agile Teams. I think I have the book here, let me see. So I don’t know if you can see it, but anyway, so I’m here in San Diego. I think they give this training pretty frequently, so I would keep on the lookout for that. The other thing I guess I’d throw a shout out to is Marie Kondo’s book. There should be a link to it in the show notes here, but she is this tidiness expert from Japan, and she— her basic premise is that when you’re tidying, you should focus on one area and what— or sort of one type of thing, and you should get rid of all of the things except for the things that bring you joy. And I just think this is such a great thing. So I’ve been tweeting out with the hashtag, you know, the DevOps Marie Kondo, because I feel like you should apply this to your backlog I feel like you could apply this to methods that you’re writing. I think that there’s no end to where you could tidy like this. So that’s the other thing that I would say.
Matty: [00:59:43] Great. So Trevor.
Trevor: So this is actually something that Matt sent me. So it’s kind of not fair because it’s kind of like stealing something that he could be using as a checkout. But it’s fine. That’s OK.
Matty: I was planning on doing it. So it’s all right.
Trevor: So Adam Edwards built a cookbook to basically provision yourself a workstation. So it’s called Winbox. It’s on GitHub. It’s cool.
Jeff: Adam is a good dude.
Trevor: Yes. It’s— I haven’t seen it yet, and I don’t know if it’s going to be good or terrible, but Jurassic World comes out this week.
Matty: Oh, I thought you were talking about the cookbook. I’m like— he’s like, I haven’t seen it. Matt sent me a link. That’s all.
Trevor: But it’s got Chris Pratt and dinosaurs, so it can’t go too wrong.
Matty: How bad can it be?
Trevor: Yeah. And finally, another cool tidbit is Arrested DevOps has crossed the 150,000 approximate downloads. That’s downloads. I can’t confirm whether or not those are listens. But still cool.
Matty: [01:00:51] That many copies of an episode have been downloaded to some device at at some point is what we can confirm. So that’s pretty fun.
Jeff: That’s awesome.
Matty: Thank you, listeners. That’s— I really, all kidding aside, and I never agree to have all kidding aside, my mind is really blown with how our listening, our audience has responded to this show. And when we kind of started it off, and who knows what’s ever going to happen out of something. Who knows what’ll continue, but we really— it gives me the feels when I meet a listener and I can tell that they enjoy the show. So thank you to anyone who’s helped add to that 150,000 number. So that being said, thank you very much. So yeah, my—
Trevor: now it’s your turn.
Matty: Yeah, so this was funny. So I was at a meetup tonight. I was at the Kansas City DevOps meetup. And talking to some dude who was asking about testing PowerShell DSC, and I was like— and we were talking about Test Kitchen. I’m like, oh, I don’t think there’s a way you could directly test DSC. I’m not sure. And then when I was driving back to my hotel from the meetup, I was listening to our friends Steve Murawski and Chris Webber at Ops All the Things, and Murawski was like, yeah, I just released this thing called Kitchen DSC for testing DSC code in Test Kitchen. I’m like, oh, why did I not know this 5 minutes ago, but that’s my checkout. I haven’t tried it, but I think it’s cool. So if you’re doing pure Microsoft PowerShell DSC, you can actually use that. And Steve also— Steven also released a kitchen driver for Hyper-V. So if you’re in a pure, like, hey, I’m just running local Hyper-V and I just want to do DSC, you can use Test Kitchen. So that’s cool. I’ve been using this app called Dexit set for creating presentations. This may have been a checkout before. I really like it. You write them in Markdown. It’s not as fancy as reveal.js and all that stuff that the cool kids like Adam and Jacob are using. It’s fairly limited, but I really like that because it’s making me create really simple presentations that are simple slides with a lot of notes. And you can— No more. No, yeah, I can’t do builds. Yeah, but I can do an animated GIF as a background, which is pretty rad.
Trevor: [01:03:16] That’s pretty awesome.
Matty: Yeah, uh, so that’s at decksetapp.com. Jennifer Davis is the one who tipped me off to that. And then finally, just, uh, audiobooks in general. I’ve been listening to— I’m sorry to my fellow podcasters, I haven’t been listening to a lot of podcasts lately. I’ve been listening to more audiobooks. Um, I’m almost done with the audiobook of The Phoenix project. I actually just listened to one of my favorite old sci-fi books, classics, is Joe Haldeman’s The Forever War, which I don’t know what occurred— why it occurred to me to get it on an audiobook the other day, but I did, and it was really fun to listen to as an audiobook. So just, yeah, audiobooks are cool. A couple conference updates: DevOps Days Amsterdam will be June 24th through the 26th. Melbourne is July 6th and the 17th. Pittsburgh CFPs—
Trevor: 16th and 17th, not 6th through 17th.
Matty: Oh, 16th through 17th.
Trevor: It came across as 6th. Just wanted to be sure.
Matty: Well, at this point, it’s super clear now. Pittsburgh will be August 13th and 14th. Their CFPs are open. Speaking of CFPs, the CFPs for DevOps Days Chicago are open until the end of June. Tickets are— we still have about 18 early bird tickets available, although if you’re listening to the audio, They’ll probably be gone by then, but Arrested DevOps listeners can use the code ADO10. That’s ADO and the number 10 for 10% off your registration for DevOps Days Chicago at devopsdays.org. We have a newsletter, arresteddevops.com/bananastand. Funny thing is someone at this Kansas City DevOps meetup today, at the end when I was doing shoutouts like, oh, DevOps Days, blah, blah, blah. You should do a shout-out to tell people to sign up for the Banana Stand. I’m like, really? Okay. But anyway, so people like it, I guess. So it’s a good way to know about upcoming podcast episodes and cool news with DevOps. And if you want to download our iPhone app instead of using your own podcast app to listen to our show, you can get it at arresteddevops.com/iphone.
Trevor: [01:05:22] Thanks again to our sponsors. Be sure to visit them at arresteddevops.com/pagerduty and arresteddevops.com/10thmagnitude. Thanks to Jeff Hackert for joining us tonight, and thanks as always to our loyal listeners. If you enjoy listening to Arrested DevOps, we would appreciate it if you would visit arresteddevops.com/itunes and leave us a review in the iTunes store. We’d love to hear what you thought about this episode. If you want to leave comments on the website, we’ve got that too. If you go to arresteddevops.com/38.
Matty: Be sure to check us out at the aforementioned ArrestedDevOps.com or @ArrestedDevOps on Twitter. And we’d always love to get your input, ideas, feedback, show ideas, all that good stuff at shows@ArrestedDevOps.com. However, do please not suggest we do a show about a topic we just did like 3 episodes ago— Docker. Please let us know any ideas that you have. I am Matt, @MattStratton.
Trevor: [01:06:24] And I’m Trevor at Trevor G Hess. We’re Arrested DevOps, and remember, there’s always DevOps in the banana stand.