DevOps Lunch and Learn Starts a Book Club [Sept 8]

Rob Hirschfeld: Hello, I’m Rob Hirschfeld. This is the September 8, DevOps lunch and learn. And we had a great discussion, our HPC v2 is rescheduled for two weeks out, and we decided to start a book club with the Phoenix project by Jean Kim, so please check that out. Join us at the 20 thirty.com. Unknown: Definitely a stream deck is useful for that because you can switch scenes like if you can pre save your scenes have them linked to a physical button. And it makes things a lot easier, like when you’re switching from recorded mode to like recorded mode to multi speaker mode two, if you want to do the Brady Bunch, view, you know, things like that. It’s kind of nice to be able to do that. Okay, it’s useful if you’re using a Mac. Now I’m using Linux, Linux. Okay, cool. Yeah, I haven’t I haven’t actually tried a stream deck under Linux yet. I’m pretty sure it’ll work fine. But just but we are Rob Hirschfeld: bringing up Promoting everybody in the background by the way.

01:03 - Unknown: We are me postalytics a cut up. Rob Hirschfeld: We’re talking about doing a VMware livestream session. Like during vmworld Jean and I are planning it and we’ll come out with details and stuff like that. That should be fun. But tomorrow next week is a there’s an overlapping session from the people at So not every cloud is equal winning with multi cloud and it directly overlaps with this session. So I was going to suggest that if y’all are willing to to be guinea pigs, we would do this as a mystery science 3000 version of of that talk and we can we can set up my streaming and we can play a little bit.

If that 01:56 - if y’all want to bring popcorn and then discuss the talk live. See how that goes. Cool. Good. Don’t think I have somebody slotted in that slot yet. I have a couple of people on deck but not not there. Unknown: That’s next week. Rob Hirschfeld: Thanks. I keep expecting this week to be quiet but y’all are willing to talk DevOps on a holiday for the US at holiday week. So welcome. Unknown: Emily is here. Rocky: So, one of the reasons why we’re here is because out here in California we’ve been confined to the house for like the past two weeks, between bars Moke and outrageous heat.

I mean, triple digit heat In San Jose, San Francisco broke an all time record of 100 degrees in September broke a 03:11 - record from 1904. That was 92 degrees. So between smoke and heat, we haven’t left the house so yeah, this is our in my entertainment. Unknown: Glad to have you. Rob Hirschfeld: But yeah, oh my goodness. I’ve been watching that. That’s crazy. I know how hard that is from houses around there are not structured 400 degree temperatures. Rocky: Oh, ours isn’t bad, but it’s really it’s a little bit distressing to wake up and find the nature of sunlight to be altered because of the smoke particles in the air. Unknown: It’s the same in Seattle today. Rocky: Oh yeah. It’s it’s kind of freaky to see the only other time I’ve seen sunlight altered like this is during an eclipse Unknown: wow that’s a lot of smoke Rocky: Yeah, it’s the the sunlight has a nature of being yellower and less strong.

One day was actually orange I took pictures of sunlight 04:25 - hitting the ground and plants and whatnot and it was just read very strange. Unknown: Remember during one of the eruptions, one of the I’m trying to remember where where the volcano was one of the eruptions that actually West Coast of the US the skyline was completely you know, colored from from the the, from the eruptions and stuff that was that was tricky enough, but I can only imagine from from that scale of wildfire. What is Gotta be like, yeah. Rocky: So and that was probably the eruption in southern Washington. So the Seattle folks got that one too. Rob Hirschfeld: How far how far north is the like, what’s the area covered by the smoke? Rocky: a satellite pretty much shows that trailing all the way up to Colorado. Unknown: Ski velocity us West. Wow. It’s pretty bad. Rocky: Yeah, pretty much the whole of the West Coast. Unknown: We’re all gonna move to Ohio. I’ll be upside lived over there. No, thank you. The grew up in Michigan. Rob Hirschfeld: In color in Colorado. I was reading and I was like, This can’t be right. They’re there. They have fire zones and snow zones.

05:57 - Rocky: Oh, yeah, that that’s actually correct. Going from 95 to like 37 or 35 today, and it’s smoke fire snow and ice zones with a few not so much. Rob Hirschfeld: I The problem is I don’t see i don’t i don’t think the next year you know it’s not going to change. Rocky: Well, potentially maybe all of California will have burned it or at least once by the time. Yeah 10 years is up. And this is providing for a clean out of California’s oldest State Park.

Essentially when it was created, all forest management pretty much Much stopped except for 07:02 - dangerous trees and whatnot. So there’s a lot of fuel. And this is allowing them to take up the Doug firs which burn a lot and bring it back to what it was. Originally, they did lose a lot of redwoods. Most of them were second growth redwoods one or two of the big ones. But by getting this all cleaned out and literally burned, the entire park didn’t leave a single corner. It will be much healthier when it’s all over, but they don’t know.

07:36 - It’s close for the next year because they don’t know what the winter rains will do for landslides and stuff like that. So they’re not even going to open it or build structures until it’s gone through an entire year. Unknown: So what is she trying to think what I’m reading Rob Hirschfeld: Octavia Butler’s the parable parable of the sower and the parable of the talents, books. If, and I can’t imagine a more relevant book for California at the moment because literally they’re there. It’s set in the year 2025 to 2030. But it was written in the in 98. And it’s, it feels very like she had a crystal ball and described things. It was pretty.

If you haven’t read it, I highly recommend it, especially 08:34 - in California. Rocky: So put a note up in the chat so I get the title right. Unknown: Thanks. actually find it. Rob Hirschfeld: Start YouTube with the first book. That’s not the right thing. That’s not the right one do not well maybe this it’s danger of calling sign parable of the sower is it’s an actual parable. This is before Unknown: this is a better link definitely Rob Hirschfeld: powerful interesting book right Unknown: if you Rob Hirschfeld: have an informal book club if people want to start reading some although we for the theme we should stick more to the Jean Kim Jean Kim books did anybody read jeans? The the more recent one The what? unicorn? Unknown: Oh no, it’s on my list. I have not though. unicorn project.

I think 10:00 - In front of me, but I haven’t read it yet. All right, I got this. I bought it. I have it here sitting here. Yeah, there’s a link for that one. I’m excited to read it, but I just haven’t done it. Rob Hirschfeld: I’m a big fan of the goal and and I thought he did a good job with the Phoenix project. But I haven’t done it. I haven’t came out right just at the beginning of the pandemic, I think. Unknown: Maybe Rob Hirschfeld: I’m waiting for it for a while. I don’t know. I haven’t. Unknown: haven’t bothered yet.

Honestly, ever since working from home, I haven’t had a commute. So I don’t actually have time to read books. It’s exactly my thing is my reading list is stacking up. Although I did, I did. I learned that I can blot out most of the moaning noise when I mow my lawn with with an audiobook so I’m getting a little bit But that’s quite not not quite as the same as a daily commute sadly. I’m competing with my kids. So I’m going to drop the video. Okay. Rob Hirschfeld: Keith house, how is it if you’re, if you’re reading it? Unknown: We can, it’s, it’s, um Keith Braddock: it’s the same storyline, it’s just another side. So if you remember, an unfinished project, you kind of see it to the eyes of the operations had to kind of, in a way kind of working his way to almost CTO CIO.

So you see the executive his interaction with the executive team, 11:46 - his interaction with senior executives. Unknown: Um, Keith Braddock: this book is the same story, same timeline, but from the people who are in the trenches. So it’s from their view. Oh, um, so he uses it to kind of tell the story of how they pushed from the ground up the concept of DevOps teams and, and and working and and Sprint’s with x price, combine boards and things like that. So it’s, it’s kind of like they are hearing the rumblings, the announcements are being made, how they’re being affected by it, how they’re reacting to it, and how they’re doing disruption from the ground up to how they’ve, in a way they’ve built this kind of insurgents team that’s doing all of the best practices that we read about right, and DevOps, and how they are doing that trying to move across in the name of building normal skunk work. And so it’s kind of interesting perspective. This Unknown: sounds awesome. The Keith Braddock: great storyteller man, you Rob Hirschfeld: really yeah, we can I bet we can get chained to come to a session if we if we commit to reading it better I bet we could do a discussion group and he and he or one of the co authors would be willing to jump in.

So 13:20 - Unknown: are you proposing at devoxx book club? I think Rob Hirschfeld: I am proposing a DevOps book club. I you know, part of what I want to do is not be dependent only on speakers, but to have some just some regular, you know, y’all are already a amazing discussion group. So I think fun. Keith Braddock: All right, recommend them interesting read, if you do Phoenix accelerate. And this the new one. It’s an interesting perspective. And, and I take the books, and in my own experience, I think we’ve had some of these conversations where I’ve kind of seeded some of them around the whole concept of have we failed. You know, we’ve invented some of these different processes, and are they really making things better? And then I start talking about engineering and the skills of the engineering.

And one of the things you see here in this particular book is you 14:16 - see the effects of good engineering versus bad engineering. Um, and how these processes don’t eliminate that or help that, right. They just make good engineering better. Right? Right. Um, worse engineering, you know, more exposed. But there has to be a focus on good quality engineering, good design techniques, all those kinds of things. And they, and those concepts kind of weave in and out through the book so far. But again, I know, it’ll be interesting to get into a debate with him, especially as we’ve gone through his own transformation from his group being acquired by Google.

Right and, and he’s kind of working his way out of that because what Does that look like now has that diminish the work of their group in 15:03 - their annual survey? What does that mean to the industry? Are we seeing kind of this? I think you mentioned in one talk we had here, where it’s been this kind of product driven change, and have, you know, have we as an industry that the technologist within the industry allowed the product, part of that kind of pushes in the direction that takes us away from a holistic enterprise view set? It’s almost like I almost feel like it’s akin to what it would be like for the Defense Department prior to the the defense manufacturing ecosystem, the defense manufacturers and their influence on purchasing of systems and what how that’s driven strategy and defense strategy and things of that nature. versus how it was before you had to whether the the military industrial complex, being a driver of that, right so the military drove what they needed and they told the industrial complex with the defense manufacturer of defense weapons and systems what they need it now it’s almost like reverse where they have gone the defense industry goes to Congress Congress and says defense you need this Defense Department says we don’t need this weapon. Yeah, you do. Have we now? You know, and why? Because it means it means jobs in our district or whatever. Yeah. Have we allowed the tools, the products to drive our solution in behavior? as relates to DevOps? How has the tool chain driven our behavior as opposed to us driving the tools to effectively give us what we need to be better? Just the question, Unknown: I Is it the tool? So the marketing? Rob Hirschfeld: Just cut right to the bone on that one? Yeah, Unknown: that one went right in there. Rocky: Ties right back to the session we had with the charity too.

So I want to point out one little thing and that is the whole thing about the 17:31 - processes drive the good DevOps to be better, but doesn’t do anything for the bad ones. Well, that’s an exact description of agile. Agile was developed by good developers, and it works for them. And most of the folks out there have no clue. And they just go through the motions. It doesn’t give them any advance anything because they don’t know how to actually apply what’s good about it to their process, Unknown: but I have my Scrum Master certificate. So that means I can endeavor that. Oh, my Rocky, Keith Braddock: you know, you had this conversation, a couple of other sessions will come back around this area. Right. And Rob knows I’ve kind of done this throughout.

Since I’ve joined these conversations, we’ll kind of see that these types of topics when we talk about process. One of the things that, you know, I’ll be a little controversial. Here, I’ll say this, he said, and I’ve said this other folks is that I think the process sees in how we deal with technology as a whole from end to end has been driven by the business allowing one side of the house company use the lack of transparency on the other Other side of the house as an excuse for saying, well, we need less documentation less process less, you know, whatever, in order to basically do make products better, I’ll be more specific. I’ve grown to think that developers have gotten away with for years complaining that infrastructure moves too slow. That infrastructure is not transparent, that they, why does it take them so long to give us an instance.

And there’s this been this push for the last decade or so to make infrastructure with faster, lighter, more flexible, more agile, so to 19:46 - speak, and we have allowed, continue bloat, consumption of memory and you know, network speed, all those things. There’s been this allowed bloat because memory is cheap. You know, bandwidth is cheap. disk space is cheap. And there’s not been that same flexibility or agility being applied to developers to be better at what they do, right? I go take a course on go or Python, and I now have my developer certificate. I’m a developer, but am I an engineer? Do I understand better memory management and what I deliver? Do I understand how to build better software so that I’m being more judicious in how I leverage this space and compute power? Rocky: Give this man Unknown: I agree. Rocky: And I’m wondering if this whole remote thing oops.

I’m going to expose the part of the issue that I saw years and years ago at cadence 21:10 - design systems was that and they actually did a reasonable job. It’s you have senior in charity. Tell us about this, do you have senior engineers? But how do you transfer that experiential knowledge to the juniors, this whole mentoring thing, and demonstrating better use of tools, resources, etc. A lot of that has fallen by the wayside. A lot of that falls by the wayside and a lot of these companies it’s, you hire the senior ones, they don’t talk to the junior ones, the junior ones make this, this mess that the senior ones have to work around, but it all kind of sort of worked. So they saw The product. And I’m thinking that possibly the remote work concept is going to accentuate this trend even more and people are going to see that they’re not an there’s not enough collaboration coordination across the different knowledge levels, experience levels, and it will either cause collapse or cause, hopefully cause the business side of the house to realize, maybe we should fix something here. They might not know what they need to fix. But if they can say we need to fix this, that might be enough to get some some of the companies to do something.

22:50 - Unknown: It’s funny that you mentioned that the business side because on the previous discussion we were talking about like, okay, the developers just use Memory more memory because it’s available using more resources because it’s available. Partially understand that? Yes, there’s been more resource consumption nowadays and development project projects. But on the other hand, I also see that developers perspective on this, and they have what you said the business side of the company breathing down them and saying, is this product rather, is this product ready? Why isn’t this product not ready? So did they have the choice to either spend a lot of time optimizing their code for less infrastructure, or they just cut corners, they either risk risk faults because they don’t do the testing or they use more resources because cheapest available, why not use it? I also find that many developers are not so well versed in the economies of scaling on applications. So for them, it works fine on their desktop, or their testing, where they have 32 gigs of RAM and a racing processor. So like us, it’s working nice and fast. And then we deployed in the cloud infrastructure and suddenly, business cars freeze down on us saying, hey, why is this so expensive? Why are we using these three instances instead of like I know and three or whatever on it, and we end up having to justify look, we need to use these resources because application is developed for these resources.

This is not like a matter of shifting blame as it was more just like trying to lay out my experience and say, okay, the 24:57 - push to get to Market before the competent competitors can cause a, a development cycle to prioritize certain aspects that we wouldn’t otherwise if it was up to us. It is understandable. I did not justifiable but understandable. And yeah, it’s it’s it’s as as we also have like an chatburn maturity is like that there is not a lot of pushback from the DevOps community yet. When it comes to saying like this is a bad deal. In some cases, some some would argue or at least on the sorry and security feel that it might not be their job to do the push back, only to say on only to expose The situation saying okay, like if we do it this way, it’s going to cost this much. If we spent this much more time, it’s going to cost this much less. But ultimately, it’s it.

There’s a whole lot of factors that come into this. Rocky: Yeah, part of it, I think there is just so much, there’s so much hardware resource out there. And it’s so easy to get to back in the day when we owned our own data centers. And if we needed more, more resource, we actually had to go through a whole purchase cycle and installation of the hardware and whatnot. So when something fell down because it didn’t scale, it became more reasonable to go back to the software developer and say, Fix it, then just throw more resources at it because the resources weren’t going to be there for a month or two.

And the timescale has changed 27:11 - because of the whole cloud availability, resource availability. Unknown: Yeah, yeah. Yeah. That there’s maybe it’s that the just culture of instant gratification has infiltrated the DevOps process. Keith Braddock: I just think that you know, what, it goes back to the conversation we had with chess is Unknown: we Keith Braddock: I think I said this time, technologists need to be better technology leaders need to be better at speaking business tech, so that we’re able to better explain to business why You know, we choose to go right, which may take a little bit longer than to go left. Because if we go left, when you come down six months now x four feature that requires X, Y and Z, we will have boxed ourselves in versus if we go right, because we are leaving ourselves open for future evolution of product and customer and customer desires. I think we do a better job of explaining and stop being so enamored with our mysterious ways. Maybe we’ll gain better trust.

And so the business will then bring us to the table and have more 28:39 - conversations. So we can rocky have those conversations about how effective are we using compute power? I’ve been thinking a lot about how do you better run a technology organization, especially when you’re leveraging r&d and innovation as a continuous part of what you do? How do you stay ahead of the evolutionary occur, and effectively inspire your team to take those leaps without bringing back some of those old behaviors where people would develop code for development sake. You know, we used to have the Easter eggs, because someone thought it was a good idea, right? I mean, that’s where we got into extreme programming, right? Was the concept was you develop what’s needed, not what you think is needed. But we don’t want but I think we’ve gotten to a point where we’ve taken away all of that engineering, knowledge and power, and we’ve kind of disciplined them into not even thinking. So I don’t know what the balances but I’m hoping that the pendulum now will swing back to the middle.

29:35 - And we will let talented engineers and talented executives that have made their way up through engineering, be better leaders of how to communicate technology, needs and experience to executives, but also teach technology be better stewards of the gift they’ve been given. So that we can be a more better practitioner. Technology. Just a thought. Unknown: It is definitely a two part problem, though because I’ve, I mean, I’ve been at the level of speaking to C level execs who we need them to be worthy of listening. Excuse me, I’m terrible, sir. We need them to be worthy of kind of listening to our advice also, when we give it is even when we’re as blunt is when at one point I had a conversation with a CEO and founder of the company and at a CPU manufacturing company, which shall not be named that you know about heating, cooling, that sort of thing and pushing the envelope of our data center and the question that returned back as well when will it catch fire? We’ll put that fire out literally when it’s on fire. Not let’s plan for it not to be on fire. Let’s wait for it. To catch on fire, and then we’ll douse it with water. And that was the mentality.

And, you know, from an engineering 31:08 - perspective, we’re always kind of looking at things from a, how do we prevent the fire from ever occurring? Whereas I will constantly get pushback of, well, we’ll we’ll put that out when it’s on fire, and not before. We’ll worry about that down the road. We’ll worry about backups when we have an issue where we need you know, we won’t validate our backups. We won’t we won’t, we won’t call the tapes back from from the silo, off site silo and test them. But lo and behold, when we have a critical need, you know, they better work, but well, we aren’t going to pay to actually bring those tapes back and test them. Because that’s man hour and time and that sort of thing.

So yeah, it’s just we need to to sea levels to listen, when 32:01 - we do speak, and trust us that this will cost your business Rob Hirschfeld: or to ask, you know, it’s not as the feature done, but you know, what’s, what’s the broader perspective on it? It’s right. The I mean, these are these are really hard problems. Actually, I want to take what you’re saying, but I want to go back to Keith, because you defined and when we were talking about the unicorn project, you know, good engineer. And I was I was interested in you know, coming back to what you were saying about what is a good engineer because I’m, I, you know, Patrick, what you’re saying on one side is like, you know, it’s this balance right, an engine a good engineer is going to say I finished it, but here’s the risks or here’s problems. Think sometimes the CEOs are like, ship it, you know, so look good on your tail I go. Any I’m guilty of this as much as anybody else. It’s like, Alright, we’re done. We’re done. Enough. Go.

33:01 - Keith Braddock: You know, it’s interesting when Patrick are saying that I was remembering, you know, one of the best things that happened to information security was a CEO getting fired because of a breach, right target CEO was beloved by the by wall street by the the company itself in the industry. And he was fired because of that breach. Right? And target does some good things. Right. You know, we’ve seen some of the, you know, some of their initiatives in that space. Um, you know, I go back in the days when I worked for a financial company in San Diego. And I I think I’m old enough now, where I’ve come to the conclusion is that it’s almost I feel almost like, just like we allowed the quarterly earnings report to drive The way we do business in other words, unlike Europe, the US singularity and the singularity in the singular focus, the US says, well, am I up for the quarter down for the quarter? That’s all that matters. You know, even the way we deal with how we report our financials, right? They deal with returns, they call it differently, right? The way they don’t rely on a superstar executive, they rely on consistent performance.

We rely on the you 34:28 - know, the flight that the flashy CEO, the one that’s, you know, everyone loves because he’s so you know, he or she is, you know, commanding of the quarterly report. I think it is, as Patrick said, a two part problem. I almost feel like it’s a three part problem. I think we have allowed in business, as we’ve allowed in education. I don’t want to get them on. soapbox, give them a big one on this one. Unknown: We’ve allowed Keith Braddock: the immediacy, the need of the immediate to drive our behavior. And we have gotten rid of the adults in the room that says, Remember when someone brought down the system because they did an illegal command? Remember what that and then translate the cost of that to actual dollars.

So I go back and I think you talk about you asked a question about good engineering. Good engineering learns from his experience and its mistakes to perform to be better at delivering I remember when I used to hire developers I used to back in the day when I did, I hired c++ developers. And someone would say, Well, why do you want c++ trained developers so sad because you know what? The code has great structure. They think the fruit So the problem, there is a there is at least a formation of some kind of consistency, that I can bring someone in off the street that has that same skill set. And they’ll be able to know where you’re going, what you’ve done, and it’ll be able to read it understand it.

36:15 - We’ve thrown away documentation became a bad word. I think rocky talks about this all the time about, you know, where QA shift left, and that means, oh, QA needs to move faster. And it’s, you know, in this this this battle between QA, are they a part of the process? Or are they a protector of the process? And where should they be in that mix? I think we’ve we’ve allowed these silos to become competitive forces to say, I’m doing my job, I’m good boss. And it’s them. It’s them. It’s them. It’s not us. It’s not all of us. And DevOps was supposed to give us that, that we’re all part of one team. We have the similar focus and delivery. And that’s what I mean by good engineering. Good engineering means you solve the problem. By thinking of the immediate, but also the future, and you do not limit the solution based on your inability to see the entire force.

37:15 - Unknown: Does that make sense? It makes a ton of Rob Hirschfeld: sense to me. I have a background in industrial engineering side, you’re speaking my language, but this is to me one of the things that that is I’ve learned to pick up as a trigger word from that perspective is when people get obsessed with efficiency on things. I I’ve learned to translate that word into fragile. And so like but some of so like, like, the way I ended up coping with this is sort of like alright, if you’re, when you’re looking for good engineering we have what you’re saying resonates right? It’s like alright, I just want to move really quick. I need to build Got a prototype out and go, you know, not so worried about the long term sustainability, you know, and we’ve taken the responsibility from the engineering team from delivering it or the development team from delivering into, you know, they just deliver it they don’t we compartmentalize these things.

It’s funny at the same time, I’m thinking full stack engineer in which I don’t believe in full stack engineers 38:25 - either. Actually, because full stack engineers highlight this make this problem even easier to get into a full stack engineer is more likely to get all their their whole stack beautiful. And not they don’t have the diversity of thought to think through all the problems and documentation to Rocky’s point. The other other pieces, and I feel like I’m losing my thread, at the end of the day, right if you if you focus on just improving your function, you’re not building stuff that’s sustainable for for the broader broader group Rocky: systems and nearing, I think maybe what we need in our education, even for software, just software developers, who aren’t even engineers, but just everybody, some sort, of course that effectively communicates how systems thinking improves. Everything you do. Unknown: Hmm. We’re Rob Hirschfeld: rocking circle full circle back to goldratt.

In my opinion on that, right? 39:34 - Keith Braddock: Yeah. So Rocky, would you say what’s better? A person from a technology institution or a liberal arts degree person? Rocky: That’s an excellent question. Because in QA, one of the things that turned out to be extremely useful and this is where I talk about diversity and inclusivity is that the perspective and mind thought and the thought processes of Liberal Arts folks in QA, help to actually find edges and corners that your average user was more likely to hit upon, then your technical user. And so the best QA teams, even if it was a black box, if you want to call it a black box tester, having people from different disciplines of physics or chemistry were great because they had this perspective of software should everything I’m working on should just be tools that should just work. So where where does it not work, but with the The liberal arts funds a lot of times it becomes more. Well, I’m looking at this as something creative.

I’m using it to create things 41:14 - or to do other things that are creative. And so it needs to be flexible enough to be creative also. So having a full range of perspective really helps in making the whatever you’re working, you’re developing, more broadly useful. Unknown: Would you say that the difference then is, or, or did the addition of say the large QA person is that it takes the review of the progress of Deus is do what it’s designed to do? versus Candice do what I want to do with it? Rocky: I think that’s a good, good chunk of it. Yes. And how does it do it? Can I make sense of how it does it? Or if I do something that doesn’t make sense to a technical person? Does it still do something useful? Unknown: Yeah, I mean, different perspectives often expose those edges as you’re talking about.

And I found that, you know, that’s some of the 42:34 - most excuse me, some of the most difficult problems that I’ve I’ve kind of faced in in software challenges were found by people who just approach the product from a vastly different perspective than was even intended. Rocky: And consider the fact that we technical folks, especially, we endure Yours are in a pretty small minority of the world. So if we want this to be useful to the world, we better get the perspective of the world as opposed to just our little silo folks. Unknown: Definitely, mean siloing is kind of also kind of circling back to what we were talking about quite a while ago that siloing concept was, was absolutely kind of paramount to this whole, you know, we we don’t bring in the juniors and kind of mentor them anymore. We’re so used to the, you know, the, our silos of, you know, throw in throw in food and bandwidth and, and a product comes out, you know, kind of thing, rather than add more people and kind of teach them and bring them up.

Because, I mean, at least in my experience, many technical organizations view 43:58 - their people as That are easily replaceable. And rather than let’s bring them up and, you know, you have you have really expensive cogs that, yeah, it’ll cost you a lot of money to replace. And you’ve got really cheap cogs. And you know, from a, I hate to, I hate to use this terminology because it kind of puts people you know, in these, this these boxes, but it’s like, I’ve seen that organizations view engineers this way. And rather than saying, okay, we’ll bring in juniors and have them brought up to learn from the seniors, have the seniors have this really nice big paycheck, and keep things running and give all the grunt work to these kids who are easily replaced. And that works well enough because there’s enough people willing to do it.

But it bites companies in the long run, and it’s not a good sustainable business. Practice In my opinion, but Rob Hirschfeld: I agree with you. There’s an interesting class that you go ahead if you want to talk. Unknown: I just got a comment that Yeah, I can I can echo Patrick’s thoughts on this that particularly like the the coming on bike you they they’re on because what when you get depend on the seniors to do the core work and even the grunt work to the juniors. When you lose a senior it then becomes so much harder to replace on this particularly evident in the in the security field where I forgot where it were.

So the article 45:46 - recently but this basically replacing a security engineer takes upwards of eight months. So you’re if you lose one of them, you’re So well. And what anything that’s not even taking probably into consideration the amount of risk exposure that happens during that transitional period. Because you’re talking about potentially, you know, just amazing amounts of security, exposure, risk exposure. What, what, what, what isn’t being watched during that time period, what alarms aren’t being caught, what, what doors were left open, when that person exited? What patches were they waiting to put into place before they before they walked out the door? You know, all of Rob Hirschfeld: that travel, all that tribal knowledge. It’s interesting because I was gonna run to a different point of the update maybe the opposite point from this.

Which is my experience in a lot of cases that people don’t give themselves the time to, to learn things and do 46:54 - things right. And we’re not we don’t send clear signals. That So, like, I’ve watched people like, be like, well, I don’t have time to learn how to do this right? I’m just gonna bang it together and grind it because I’m not. Either they’re not given that it’s actually funny. I think they’re given the time to do it correctly, I think they don’t give them they don’t give themselves the time to do it correctly. So like if a junior person comes up and says, You know, I want to take a week so that I understand this and really understand how to do it, right? Build the skill set. It’s important if they start with the I want to take X amount of time, right? If they just say I’m gonna go learn it.

It’s very unbounded and they can be 47:38 - told no or it can just become a do it on your own time type of thing. That is, most organizations want their junior people to invest in improving what they’re what they’re doing, I believe, but I think most junior people, even senior people are afraid to ask for the time to improve your document make things right it’s really hard leaving airship to create space for people to do be good engineers. Unknown: I’d like to know where you’re working at, because that sounds like a great place. I know the reason I say that is just because in my, in my experience, that’s actually the opposite even, even in organizations where the culture of the corporation, as they like to say, is, you know, people first and it’s very people oriented and we want to give people the opportunity to learn, we’ll even give you an educational budget, when it actually comes time to requesting time or budget to actually expand one’s knowledge or expand was learning. It’s often Well, not at this time, where our, our, our, our list of to dues is too great.

Our quarterly objectives aren’t met, because it doesn’t you know, that that learning experience 48:52 - doesn’t, you know, your learning experience doesn’t enhance the company’s bottom line at this time. You know, so even though they Have a talking point of saying, where people first will educate, you know, our juniors and bring them up. Often when it’s actually true when juniors try to put that into action, they’re often met with resilient, you know, resistance to that. So at least in my experience, I have Rocky: Patrick on this. Patrick, you have your Scrum Master certificate is, is there any thing in your Scrum masters class that tells you how to incorporate learning into a sprint? Unknown: I actually but by the way, that that was actually a joke earlier. And I actually don’t believe there. I don’t believe there is actually is there. Exactly.

Yeah, there isn’t anything in the process here that says 49:46 - Rocky: exactly, we have a problem. Rob Hirschfeld: I have done it in the past, but it can cause weird results and actually, that one of the things I don’t like about agile is While it’s okay in his in to me in a scrum plan to say hey I need to learn how to do this I’m going to budget time to learn and my delivery for the sprint is that I learned how to do this or I prototype it so I can see if it’s a good idea. And and agile has great language to say let’s spend this sprint building a prototype or learning if this is a good thing you’re doing research and that becomes a delivery for the sprint with very concrete what the thing I found is that the way I’ve seen Sprint’s turn into the busy person gets all the work they get loaded up first. And then the other people in the group are given jobs that also have to get done. But they’re not the right people for and I’ve seen sprints where basically you know, Junior people or the wrong person spins their wheels for two or three Sprint’s until the person who should have given been given the work all along.

Gets it Which is, which is a it’s just a purity thing from an agile perspective, there’s agile teams that are like, here’s the work queue 51:08 - and you pop off the top, because that’s the most important and it’s prioritized correctly. So put whoever at it is at it. Unknown: And I gave that up. I don’t I don’t. That’s not all. Not all engineers have the same skill sets, though. It’s like that. If you don’t, yeah, if you if you have those who are in they’re not all divided necessarily in the individual teams that you can, divvy your task us up to, you know, sometimes you you’ve got a general software pool, you know, and that’s what you pull from. So at least I mean, that’s why in my opinion, agile tends to fall down a lot. is just that it? It’s not agile enough. It’s not, it can’t be, you know, yeah, you can remould it and rework it, but then you start to use the language of Agile but not the Agile process.

51:57 - Rob Hirschfeld: Well, it assumes that developers are relatively interchangeable. Unknown: Which, and that in my experience, they tend not to be. Rob Hirschfeld: I mean, and that doesn’t mean they’re good or bad. It just there’s an interchangeability thing that that’s one of the things that that we see. And we do, we do a degree of rotation that we have different engineers who are good at different things, or different focus areas.

And so if I want something built a certain way, this engineer is much better at it, if I want it built another way, this engineer is better at 52:26 - it. And then the ideal thing is when they swap right one works for a while, and then they swap and then the other one adds their flavor into that work. I haven’t seen quite the same thing from an ops perspective. Unknown: Um, Rob Hirschfeld: I don’t know maybe that maybe I do, where, you know, the tools that people use, like we have one person who like just code in Python, everything’s good. And then the next person down the lines like I really prefer Ansible or bash or you know, I don’t like either of those.

52:58 - I want to do it and Unknown: go Yeah, go to Yeah. Rob Hirschfeld: Yeah, Reese recent ops is really hard. Unknown: Well, and then like some, you know, ops is pretty generic, you know, you’ve got network Ops, you’ve got sec Ops, you’ve got, you know, you have all these different facilities. So you can say, I’ve got an ops person on it. Well, some of your ops people are more security oriented, some of them are more network oriented, some of them are more, you know, bare metal server bring up oriented, some of them are more, you know, it’s just more operating system centric, they have a deeper knowledge of the intricacies of kernel debug, etc. You know, it just everybody is unique and has their own skill set and you can’t really treat them as as interchangeable levels of expertise.

Hopefully you cross train your team so 53:50 - that they can support each other and hopefully you have open communication lines so that if someone runs into a problem, they can easily communicate with the other person. To your team, but reality in the world is that people tend to not they want to focus on their stack of, you know, measurable stack of problems that are in front of them. And they don’t really have time to be interrupted by all the other people who need their help. Because then you end up with that same thing where you’ve got one guy with all of the work or one girl with all of the work and getting that trying to divvy that out is just so difficult. Keith Braddock: But what is it at the organizational level and the department level? We really need to adopt good management skills like what is your, you know, goals, objectives? What are your founding or operational principles? What are your what’s your mission statement? What are the things that guiding right so for instance, we talked about cross training, we talked about making sure in this conversation we talked about letting you know how Do you train your juniors so that they’re more efficient they can grow? How do you enforce knowledge share? How do you budget for time for training, as well as getting work done. All of that sounds like guiding principles.

It sounds like you have to have an organization that 55:16 - at your core, at your fundamental principles have to be, hey, we will do these things, these behaviors get rewarded. These other behaviors do not and they need to be specifically declared, I think about a story that jack welch told back in the day, and he was on some, I think it was a CNBC or something like that. And he was talking about, he had gotten a call from one of his on air talents, and he was talking about Hey, how’s it doing? He was checking in, and he said, um, you know, I heard today that you won’t be on the air tomorrow and he goes, why are you not on the air and he goes, Well, I got to go to this, you know, GE mandated training that I have to go through a while it goes really And he goes, so he calls HR and HR person handles is very definitely goes. The woman is known as HR, I think it was at the time said that. This is that training that we’ve mandated for blah, blah, blah, blah, blah, blah. And jack welch had to apologize to the HR person.

Because he was, he was doing exactly which a 56:19 - guiding principle of GE at the time was, its organizational training, everyone wants to go, regardless of where they fit in the organization. This is mandated, this is a must, right. And you don’t get special privileges because you have the highest ratings, or you are the you make the more money, the best money. Somewhere along the line. We’ve lost our way in organizational design and principles. And we’ve stopped doing things that are part of our guiding principles. And those things should override our knee jerk reaction to the situation at hand.

I know sounds 56:55 - philosophical, but I think Rob Hirschfeld: I love what you’re saying Actually, we so one of the things I had on my list to do. So we’ve been working on principles that guide what we do design principles along those lines. And it’s for the same reason. It’s like whenever you’re confronted with a dilemma, you want to be able to go and quickly say, is this line up with our principles? Yes or no? And if that’s your test, right, sure, you you fall back to it so that you have some some Foundation, which your story illustrates I was, if people are interested, I would need to find a time in the schedule for it. But I would bring this the six we’ve got. And I would love to get the group’s feedback on it. And you can discuss if it makes sense or not.

They’re not organized, they’re organizational, but they’re really architectural from that perspective. So if people are interested, I’ll put that on the calendar. I’d love to get this this group has great insight. So I’d love to see you. tear him apart. Tell us what, Rocky: that sounds interesting. It also sounds like we might want to look at I believe jack welch also has a book on management that we might want to consider putting on a list of the book club, reading list list, Rob Hirschfeld: add it, add it to the throw it throw these. I’ll throw the unicorn project into the channel. And we’ll start doing that. And then we’ll pick up the last one. I actually think it’d be fun to read a book a quarter and throw a meeting about it and then let people join in.

58:23 - Unknown: We kind of meet Rob Hirschfeld: Yeah, if you I mean, even if you don’t read the book and come the discussion will be interesting. In that perspective, Keith Braddock: as well, five tells a story of how he blew up his first plant. Rob Hirschfeld: And what happened. Do you hear that? All right, so we’re, we’re, we’re starting, we’re starting something new. And with that, we’re just about at a time, just quickly next week, we’re going to do the bring popcorn, and we’re going to live live chat. present a webinar. See how that works. And then Greg, we’re going to try and get Greg back for the week after that.

See, I’m looking at Patrick and see what You can do it. And then I will slot in my schedule. And then we still have the engineer from RAC n who is going to talk about how we’re turning on s3 buckets dynamically with tokens. Hmm. Cool. So that that sort of the Chris love, can’t fix the fix the problem, problem thing and then bring more whatever whatever you think. Unknown: Did his cricket scheduled by any chance? Do you know if Cricket League got scheduled, but Rob Hirschfeld: I haven’t seen it for DNS. I have not seen him get scheduled. So no, I need to encourage people to just basically put it in the events list.

So 59:45 - Unknown: is there a better way to kind of manage the the kind of getting a speaker kind of signed up and conference confirmed and on the on the invite for the list and so it gets on Rob Hirschfeld: you I mean, the thing to do is to ping me with an email address to do it. But I think that the smartest thing to do is for us to just say if you have an event and you go into the everybody should have the rights to do it at an event into the events list in club 2030. And then that will basically, you know, if we end up with a conflict, then we’ll see it, because it’ll be pretty obvious and then we’re not using account you know, that solves the calendar and we know when the meetings are, pick, pick the date, and then we’ll run from there. Unknown: I’m trying to Rob Hirschfeld: delegate a little bit on the organizational stuff. So I want to empower people who are like, I want to present on this on this session. You can block that out.

I don’t, I don’t have a 00:49 - Unknown: you don’t have unlimited time. Rob Hirschfeld: I don’t have unlimited time, and I don’t have an ego on being the person to do all the scheduling. I just Unknown: it’s a good thing. Yeah. Rob Hirschfeld: Cheers all have a good weekend. It’s fun to be I’ll see some of you Thursday. Disaster lightning conversation Unknown: too early. Oh yeah. Sorry. I’ll I guess .