An experienced technology leader running tech startups since 1990. From 2014 leading the team at Daysha to help clients adopt DevOps mindset, processes and tools.  Brendan is an Agile Coach and Lean Yellow Belt. He is a DevOps Institute Ambassador and published a book in 2020 titled 1FaaT – One Feature at a Time to help organizations to overcome their older ways of working and engage customers in a process of ongoing value realization.

Thanks to our episode sponsor Kolide!

Want access to more content like this? Gain the tools, resources and knowledge to help your organization adapt and respond to challenges by becoming a member of DevOps Institute. Get started for free: https://www.devopsinstitute.com/membership/

Have questions, feedback or just want to chat? Send us an email at podcast@devopsinstitute.com

Please find a lightly edited transcript below:

Narrator 00:02
You’re listening to the humans of DevOps podcast, a podcast focused on advancing the humans of DevOps through skills, knowledge, ideas and learning, or the SK il framework.

Brendan O’Reilly 00:17
If we have a connection to the customer to the fact that we’re competing for business, you know, if we have that connection, then energy flows in I mean energy is this an intangible thing, but it’s very present. You can see a team that’s energized versus the team. That’s not.

Jason Baum 00:34
Hey, everyone, it’s Jason Baum, Director of Member experience at DevOps Institute, and this is the humans of DevOps podcast. Welcome back. Hope you had a great week. Last week, I hope you listen to our episode, we discussed VR tech, so you’ll definitely want to go back and listen, if you haven’t. We talked all about the metaverse whether it will play a role in the future of remote work. We’re going to continue the conversation centered around remote work on today’s episode. But today we’ll be focusing on silos. Look, whether we’re on site, hybrid remote, teams, and departments tend to work in silos. It’s not a new concept. In fact, it’s quite natural when silos pop up. Often you’ll see a team working and communicating very well with each other, but then not as effective with other teams. There’s where the silos come in. We’ve been aware of this issue for a long time. And in some ways, we’ve created methods to avoid working in silos when in the same office space. But it’s definitely harder when we’re working remote, whether we’re cities, states or even countries apart. But we have the pleasure today of speaking to my guest, Brendan O’Reilly, a DevOps specialist who co-founded his company, Dacia in 2004. And most recently led its transformation as a DevOps training and solutions business and experienced technology leader running tech startups since 1990. Brendan is an Agile coach and lean yellow belt. He is a DevOps Institute ambassador, and published a book in 2020, titled one fat that’s what to aim is one feature at a time to help organizations overcome their older ways of working and engage customers in a process of ongoing value realization. Brendon. Welcome to the humans of DevOps podcast.

Brendan O’Reilly 02:32
Hey, Jason, thanks a million for having me along. Looking forward to this. Hopefully, it’ll be a good fun day. And actually, I must listen to your last episode. Because just before we came on, we were having a chat about VR. And I’ve actually delivered some lectures in VR recently, and how to a whale of a time, the really interesting part happened after the lecture where which happened in a lecture theatre, and we went in to have a coffee, and there was a virtual coffee machine. And then all the students came up and interacted with me when it was less formal, so to speak. So yeah, I believe I also believe that VR is the future.

Jason Baum 03:09
Yeah, you know, you know, what’s so different about VR is like, and you’re describing the networking component, that that does not lend itself as authentically, I guess, is the right word in Zoom, because you don’t have the ability to like, tap someone on the shoulder and interrupt their conversation, something as simple as that, that we have taken for granted, but is embedded in us, I guess, in long term networking, for example, or just randomly bumping into someone, right?

Brendan O’Reilly 03:38
Yeah, I mean, it’s, it’s really hard to know how it’s gonna pan out. But the ability as you say, to go and shake somebody’s hand, for example, in a virtual world, create a different form of connection. And sit down and have a coffee even, even though you’re and you are actually sipping the coffee creates this atmosphere require it’s just a bit more relaxed, I guess.

Jason Baum 04:00
There’s haptic feedback. There’s the sound travels around, you know, wherever someone’s speaking, you hear it over to the left, or to the right, the spatial audio. It’s very cool. So so check out last week’s episode for those listening and Brandon, please check it out. And I’m sure we’re going to do more on the topic. And I do think it plays a little bit into our conversation today on silos. I was a communication major and I was beaten into me that there is not such communication. There are so many different variations of communication, types of communication. And then there is effective communication, there’s no such thing as more communication. There is effective communication or ineffective noise. Right. And I think that too, plays a little bit into the conversation today on-site about silos and I talked about it in my lead up. But why don’t we just start right at the beginning? Why are silos bad? And how do they even come up?

Brendan O’Reilly 05:10
Hmm? Yeah, so why are they bad? And why do people okay? So generally speaking, they’re bad because there’s a loss of productivity associated with having roles, like classically, the project manager who kind of traverses groups of certain SME subject matter experts. So one individual is tasked with, you know, pulling it together and sharing things and documents course, things go missing, and tasks don’t get aligned properly, as compared with the alternative, which is to have people collaborating, be it virtually be in a meeting space, where there isn’t anyone facilitate, there isn’t anyone sort of directing the conversation or, but that the group is, to some extent self-managing, they’re self-empowered, and tasks are directed between one another rather than through an intermediary. So there’s a kind of a general loss of productivity through silos. And it’s not to say, by the way, that all silos are bad all the time. Okay. So there are situations where, you know, by virtue of needing and say, for example, a bank, you need to have Chinese walls for the guys running risk, they actually have to be separated out from the guys in the day to day running of the business, but in general terms, they’re bad. I mean, I think we’re probably all familiar with and if we’re not, then Conway’s Law is a good reference point here. So going back to, you know, the start of when manufacturing, you know, big star manufacturing the likes of Henry Ford, they started out with this idea that would break a task down to component parts, and we’ll have people specialize in those parts. And that that was the origination of, of, of, of the side of the specialist task. And then the accountants, when they came in, on top of that, they set up a chart of accounts. And Conway’s Law says, Well, okay, if we have that chart, we can send we have, you know, manufacturing, and we have supply and purchasing, well, then we’ll have separate accounts for those people, separate office spaces, separate silos, and, and they become rigid, and the software systems then tend to mirror those. So the, the flow of data tends to go from the procurement system, which is standalone to the accounting system, and we have, you know, connections between them,

Jason Baum 07:29
you know, cuz even silos, you have multiple silos, right? You have silos of teams, and you have silos of data. And, you know, I mean, you can have so many different silos within a company.

Brendan O’Reilly 07:39
Yeah, classically in it have had, you know, silos of test silos of DEV silos of analysis. So you have these teams of people who literally threw the work over the wall to one another, with the project manager kind of hovering above them. When you look at a modern DevOps team, it’s a team that, that that has the resources to get code into production, ideally, one feature at a time, right? to reference the book. Because when you’re doing it one feature at a time, you can very distinctly and clearly see the value you get from that unique feature, as opposed to the 10 features if you release all 10 together, so having a team that that that can interact with one another for the express purpose and the common purpose of getting a feature into production. And that tends to be and it is the most productive way for software to be delivered. But it’s not easy to get there. Because especially if teams have been working in those silos for quite some time, they become somewhat institutionalized to that way of working. And I’ve, I’ve worked with, one of the clients that I worked with was an insurance company. And I remember the lady who headed up the business analysis team kind of being horrified that, you know, she couldn’t produce a 300 page set of requirements that sounded heavy when it hit the desk, you know, it had to be, No, we just weren’t actually going to build next week, just actually two pages. And if you could draw some pictures that would really help. And it really was a, you know, it really was a challenge. And I understood that the lady had been working with a team of 15 people are producing. And in fact, some of her bonus system was around having, you know, producing these documents that the customer would sign off. And the customer was really impressed when the document was big and heavy. Not sure they ever read it. But and the other point about it was of course, by the time they came around to delivering everything in that book, some of it was no longer needed, which is really the waste so they’re building features, but the offered the opportunity to market has done by for when we work collaboratively and outside of those silos. Well, we’re automatically attuned to that. So our product owner is checking Do we still need this? Hey, we just deployed, nobody used it, do we really need it? You know, and that gives rise to insights that wouldn’t otherwise arise. until somewhat later if you’re not building one feature at a time.

Jason Baum 10:03
So there’s, you’ve triggered a lot of things in my head. Sorry. So no, it’s good. So now I want to kind of review it and see if I’m wrong, right. But the first thing that I think of I love the one feature at a time, by the way, I think that concept is great. I think many times we think, several features down the line, and we get lost in the future rather than today. Right? We are we that’s, it can get overwhelming, it can get complex. We actually, talked about that on this podcast a while ago with Mark Peters. And, and I think we reference, maybe it was me, I referenced What About Bob and Richard Dreyfus is baby steps. I don’t know if you’re familiar with the concept, but it’s, you know, it’s pretty, pretty popular. I mean, the movie came out, I think, in the 80s. But I think it still holds true, that concept of baby steps, you know, one step at a time, very similar to one feature at a time concept. The other thing is, you know when you have group collaboration, I guess, I think people believe that’s the right way to go about it. But they don’t know how, because who owns it is like still the current it’s still thought about, oh, well, okay, great, we can all talk about it, we can all ideally, but at the end of the day, who owns it, right, who’s whose responsibility is tied to it.

Brendan O’Reilly 11:37
So for me, the word product will be in the job title, as in product owner, product manager, and as whether that person is permanently in the team are has a representative in the team. That’s, that’s kind of another point. But I think, you know, even though we’re going to release one feature at a time, we do have to have a vision for the product. And that becomes a cohesive force for the team, not just the team building features one to four, but also the team building features four to eight and so forth. So, that person is the person who is, in my opinion, one of the most pivotal roles. They’re able to engage engineers, customers, competitors, and, and prioritize the work, okay, what are we going to build, then the engineers build it, then we see how, what it looks like, we get the feedback, and we start again, but it’s, it’s, it’s done very collaboratively. So let me give you an example. You know, it could be the case that the product owner really wants to try and build features one and two. But when the engineers look at how the code is structured, they kind of point out that, hey, if we’re gonna change feature to make more sensitive, feature three within this sprint or this iteration, and we’ll come to feature one of the letter later stage, so we kind of collaborate those to make sure that we’re at our most productive. I think in terms of the ideation let me talk about something that is really dear to my heart. I, everybody can have a good idea. Absolutely. Everyone, Steve Jobs talked about, you know, in bad companies, it’s the people who shout loudest, who can good companies, it’s the people with really good ideas that float to the top. And I think companies should put in place a continuous innovation process, a bounty for ideas that work. So whether it’s on your team, or whether it’s the CEO, our the guy who just joined the company, as an intern, they’re all capable of having a good idea. And we need that we need our backlogs, you know, to be full of ideas, and we need our product owner, whoever it is to prioritize those. I mean, let me give you an amazing stat booking.com has at any moment in time, 1000 experiments underway. And in an average year, we’ll run the 30,000 Now, now, Jason, here’s a challenge to you, what percentage of those Palouse to be good ideas that actually add value? Have a guess?

Jason Baum 14:07
My guess is maybe one to 2%? Oh, you’re

Brendan O’Reilly 14:11
a little bit out, it’s actually closer to 10. Okay, but that means that like, 90% Yeah, don’t work. But that doesn’t stop them, right? Because the ones that work out are the ones that that yield, you know, a competitive advantage. And it is a very fast-moving world. So, you know, those companies, companies like booking.com, they have these innovation backlogs. And that comes from having a collaborative spirit that transcends silos, that the look, I digress, we can talk about innovation another day, we’re here to talk about silos.

Jason Baum 14:44
I still think actually 10% is actually pretty high to me, because, you know, I don’t know I don’t pretend to believe that 90% of my ideas are well, I’d heard that 10% of my ideas are good. I actually tend to think that most of them are bad and then the ones that are good. Hopefully, they’re Really good, you know, and I guess it’s that same, that same concept. But we kind of touched on initiating that breakdown of silos. I, you know, one of my passions right now, and then I’ve really been diving into is the customer experience side of things and I see there’s a big connection to employee experience too. So silos very much interest me. What is the role of feedback in breaking down silos?

Brendan O’Reilly 15:34
Yeah, so feedback is the Breakfast of Champions Cup, told me that I know, is it a great book? Yeah, I can’t remember who originally you have to google that afterwards. Without feedback, we’re like, in a car traveling across the desert, the lights are on, it’s dark, all the lights, all the windows are blank days, and we’re just driving around aimlessly, and we’re gonna get lost. So feedback tells us whether we’re actually succeeding or not in our purpose, you know, so it’s, it’s, it’s by far the most important and that the sooner you get it, the better, right. And there’s a whole bunch of really good tools out there to help you get it in real-time. So, you know, tools like New Relic and launch darkly, and these tools, you know, allow you to put one feature into one domain, for example, a geographic domain, see how it’s working. And if it’s working, then roll it out, if not deprecate the feature and start again. So there’s no reason not to be constantly running these AP tests and getting your feedback, particularly in the b2c environment, obviously, in a in a sort of b2b world or in internal applications. It’s more difficult, right? It’s not as straightforward as I’ve just described, just to touch on the initiation, I think, you know, one of the things that so much depends on context. So I work with a range of organizations from startup to growth to, you know, full-scale multinational corporations. And generally speaking, the siloing kind of creeps in as they go from growth stage to multinational, that’s when I tend, you know, up until that point, people, people are tasked with doing multiple things. And so the silos are less obvious. But then as you want to grow and become a little bit better at things you tend to want to silo after work. When you get into the MNC world, it can be Yeah, it can be full-on silos. So one of the things that really works, there are things like book clubs and hackathons, you know, to get people to start to meet one another again, and to, Hey, I didn’t know you worked here, and you’re the guy that was on that email trail, that kind of conversation really helps. And, you know, books about organizations like that, that particular reference I made to booking.com as a Harvard Business Review paper, you know, you could read it in 20 minutes, you share it with your colleagues, you invite them for a brown bag, lunch, maybe bring in a vendor, we do a lot of this kind of stuff. We’ll come in and, and host a lunch.

Jason Baum 17:57
Today’s episode of the humans of DevOps podcast is sponsored by Kolide. Kolide is an endpoint security solution that sends your employees important and timely security recommendations for their Linux, Mac and Windows devices right inside Slack collide is perfect for organizations that care deeply about compliance and security, but don’t want to get there by locking down devices to the point where they become unusable, instead of frustrating your employees collide educates them about security, and device management while directing them to fix important problems. You can try collide with all its features on an unlimited number of devices, free for 14 days, no credit card required. Visit Kolide.com/HODP to sign up today. That’s Kolide.com/HODP enter your email when prompted to receive your free Kolide gift bundle after trial activation.

From the employee side, I guess I still have some questions about employee feedback when it pertains to it. And then also relating it to a remote environment. What are some of the unique challenges that are remote environments present?

Brendan O’Reilly 19:13
Yeah, so yeah, so here’s, here’s the thing, right? I think it’s a really good point, people, when that feedback comes to those that are kind of new on the job, or inexperienced or perhaps really proud about getting a feature, right, and the feedback comes that we’ve to deprecate the feature, that’s a bit of a crushing moment for the person who loves to hear it, okay. And when it’s remote, it’s even more difficult because whereas, you know, a manager could a product owner who go and sit beside the individual and say, Hey, I know it didn’t work out, but it’s good because now we’re going to avoid a cul de sac. We’re going to have another goal. We’re going to try going this way. We’re still attempting to achieve this with the product. It’s just that particular route didn’t work out. When that happens remotely. You know, it doesn’t have the ability to just put your hand on the guy’s back or the lady’s back and say, Hey, good job. You know, not everything can can can work out, well, the software was well built, it’s just a feature isn’t required by users My bad, you know, it’s my bad that as a product owner, I picked that wrong feature. So I think it’s, it’s, it’s really difficult to get that sincerity across in a kind of a, you know, ways around that are when you know, when you have an all hands on the Zoom to say, Hey, listen, particularly thank to engineer a or b for their hard work. And we’ve learned from that. And, again, it’s a case of Try, try and try again until we get it right, you know, but yeah, it can be crushing if you’re the engineer whose feature is just no cost to one side.

Jason Baum 20:46
Yeah. Yeah, it’s interesting. I mean, all hands-on Zoom. I mean, the VR stand-ups. That was what the team last week at modern was doing. They were doing it. I don’t know if they were doing it once a day. I think they were doing once a day, like an hour with their development team in VR. And it was a different experience. I think it got them excited. The CEO was telling me, Jonathan Schneider, you know, it was just different. It got them. I think they were a little more engaged. Maybe they could collaborate more. So that was one example from last week that was shared with me.

Brendan O’Reilly 21:22
Yeah, so let me just add to that, that’s really interesting. So the university where I did the lecture, it’s it Carlo, there are just a region in Ireland. And they are working on the production of a virtual DevOps simulation. Okay, so they’ve created a workspace. It’s cool. It’s kind of interesting. So I’m diverting, so you might need to get back on track, but they created this workspace scene, where they put the devs downstairs and the tests upstairs. So you have to trudge up the stairs to get your test results and back down again. And then you know, guess what, we move the two side by side, we put a Kanban board up and we can, you know, we can improve. But it was really interesting, when we brought people who we brought them in to do the CNA right, you know, and then we sat them down, we said, so let’s do a retrospective here. What what do you think, what would work? What should we improve? And you know, nobody, you have to really say, Well, we could move the furniture. Oh, right. Yeah. Okay. Well,

Jason Baum 22:20
I think sometimes it’s generating excitement, right. Again, I think sometimes when you’re sitting in the same space, you know, when we’re in an office, we do get up and we do collaborate, we do have those coffee minutes, and we do have the trip to the lunchroom. And we do have times when we’re just not sitting and working, coding whatever we’re doing. You know, it is we are generally for the most part collaborative. People even when we’re in silos, I think we are still collaborative amongst like I was saying in the intro that the teams and hopefully more in DevOps, I don’t know if that’s true. But yeah, I think that’s a piece that’s just generally missing is potentially the excitement that sometimes you get from others.

Brendan O’Reilly 23:05
Yeah. And, yeah, I mean, I think you’ve touched on something there, which is that sometimes when people are in silos, it can turn into, we all do the same thing. We all have the same conversation. And if we’re not in the, if we’re not in the right frame of mind, that can turn into what we call a mon fast, right? Oh, yeah. Yeah. So whereas if we have, if we have a connection to the customer, are to the fact that we’re competing for business, or, you know, if we have that connection, then energy flows in I mean, energy is this in intangible thing, but it’s very present, you can, you can see a team that’s energized versus a team that’s not you know, the team that’s energized, works through lunch, you get a lot of discretionary effort at weekends, we’ve got to go live, you know, and we’re when we’re happening, the team that’s not energized, is trying to figure out how to knock off fairly and avoid responsibility and so forth. So yeah, that that kind of your rights, excitement is energy, it’s, it’s an essential element of, of a collaborative team,

Jason Baum 24:09
you know, when you can feel it, you can feel it when someone’s new, they come in, they’re energized, they have new ideas, they’re throwing things out, Hey, you might have talked about as a team 500 times, they don’t know, but they’re gonna throw it out, and they’re excited about it. Maybe that fits 100 times, and you heard it from an excited person, maybe all of a sudden things start, you know, moving and clicking up there. And they usually bring excitement to the rest of the team. I wonder if feedback plays a role in that? Because maybe there are ways that we can generate excitement that doesn’t just have to be someone new to a team, but yeah, I don’t know. I’m just kind of riffing on that.

Brendan O’Reilly 24:42
Yeah, well, I think I think you know, a good scrum master Are you know that the person that runs the retrospective, will generally try to elicit from all team members but particularly the new team members, I must tell you an interesting story about an airline that I worked with really interesting one, you know, a good scrum master will try to elicit ideas and feedback. So we’ll obviously do the retro and we’ll talk about what we could have done better. But then we’ll try to say, well, who’s had experience with this elsewhere and what has happened elsewhere. Now, one particular client, a team member left, went away, worked for another organization and came back about nine months later. And the retros suddenly got really interesting, because that person came back with a bunch of new ideas and things that they had experienced over that nine-month period, which they were able to bring into the team. Now within that organization, they also have another role, which is an Agile coach, which is somebody who transcends the teams. So they drop into the retros for the deployed 1617 dev teams, our delivery teams to give them the correct title because they are tasked with putting code into prod. So you know, the Agile coach has to take the best ideas from one and make sure that they transcend. So it becomes a kind of very standard way of working for the teams. So that people need to move between teams that will feel like hey, I’m not just moved to another planet, I’m just moved next door to the team that’s working on features, different features, the one that I’m on, so that feedback, I would say is also let’s incorporate shared experience there. So wherever it may have come from, and wherever it may come from, it could come from books, training courses, YouTube’s like I love people to be curious in teams, you know? Can we find a way to think about a problem? Can we get a bit of timeout, you know, between? Sprints could we get maybe a half a day to just spend some time researching new areas. And if those areas seem to America, we get a little bit of time out of production to explore them further. Get some funding, and perhaps we can build something or create something of value that can be shared across the entire team, all themes.

Jason Baum 26:51
Yeah, it’s, it’s interesting. So those who listen to the podcast know that I am a sports fan. And American football in particular. And what you’re describing to me, I’m thinking about it. And something I heard about. Coach Bill Belichick is that he trains his coaches to fill multiple roles. So it’s very standard, you’ll have like a wide receiver coach or quarterbacks coach or running back and they filled those roles. But he moves them around from year to year to build well-rounded coaches so that they could fill in whatever spot they need to be in. And I mean, the idea is to make them just better, well-rounded thinking, holistically thinking, you know, and gosh, that can be applied. That’s exactly what you’re talking about. Right?

Brendan O’Reilly 27:44
Yeah. I mean, I bet you when they bring their fresh mind if they’re a defensive coach, and they bring their that mindset to a new way, they’ll ask just lots of dumb questions. There is no such thing. You know, there are just lots of really good questions that you haven’t thought of before. And actually, I coach soccer, I think you call it soccer, right? As opposed to football, football.

Jason Baum 28:07
We call it we, it doesn’t make any sense. But that’s what we do.

Brendan O’Reilly 28:12
We call I coach soccer and had that experience of working with a guy who was very offense-oriented. And I was defense-oriented, and it worked well. And then we did the Have you heard that? The Wright brothers had they used to work it was Orville. Have you heard this story?

Jason Baum 28:30
I well, I know the Wright brothers. But

Brendan O’Reilly 28:32
yeah, yeah. So there was, here’s what they used to do. Right? This is really interesting. So one of them would have an idea, okay. And in the morning, they would argue over this idea. So in the morning, one of them would argue for, and the other guy would argue against and these would sometimes turn into, these would be shouting matches. Then they would go to lunch, and they’d come back, and then they would invert the opposite, or the opposite, right? So you know that that that concept? I found that worked really well with my colleague when he was the offensive coach, I was a defensive coach. Oh, he used to take turns it just say, okay, that match. Let’s review it. Okay, you do the offense review? I’ll do the Defense Review. And we’ll Yeah,

Jason Baum 29:14
it’s a great exercise because it does make you think outside potentially your comfort zone, and think the other person’s shoes. I mean, that. That’s, that’s a great exercise. I’m sure the quality of the product could just improve based on your knowledge of,

Brendan O’Reilly 29:29
yeah, I just want to I don’t know how it worked, in football, but we did that with our team. So, when we finished the match, we do the review. 15 guys are waiting to go for their beer, but nobody’s going anywhere until we’ve had that conversation. And then we just pick out the two or three things that we want to improve. Yeah,

Jason Baum 29:47
yeah. No, I mean, Coach Belichick. I mean, and I don’t know how many other code maybe other coaches do it. I’m sure they singled him out because he wins a lot. You know, you know, he’ll take a defensive line coach in the next year. He’ll be an offensive line coach. So like, and throwing them into the fire, but seems to work.

Brendan O’Reilly 30:05
Yeah. And I think it’s a route to management as well. I mean, I work with a coach some of the CTOs when he’s got when we’re looking at developing people and talent. And so what you really want them, especially if they come in, and they’re just working in, say, a dev role, but they could be working in an SRE role, or they could be working in test, you really want them to have that all-round experience so that when they are leaders, they actually have walked the walk. And they can, you know, understand and appreciate the perspective of all of the individuals in their teams. And that helps with, you know, I mean, we’re not talking about silos. Now, we’re talking about, you know, individual performance improvements that we can, we can look for and realistically expect as well.

Jason Baum 30:47
But is that one of because I was just about to ask you, when when we’re fostering cross-silo collaboration, you know, I think one thing that has to be kept in mind as making it not seem artificial, or unnatural. is self-improvement, you know, improving, you’re improving your own capabilities and understandings and becoming more well rounded. On on everything else, doesn’t that kind of, isn’t that one way to do it make you more aware of what other teams are doing potentially what someone else in a different role is doing? Is that one way to do that?

Brendan O’Reilly 31:27
Yeah, absolutely. I mean, the individual within any team wants to be able to add value, ideally, around their specialist skill. But equally, they want to raise the game for the others in the team. So they want to be able to help other people be more productive. I mean, I’ll give you an example. This is very typical. But again, one of my clients, when they analyze the code that actually works, the code that goes into production, there’s probably a small number of engineers that actually do that. And there’s a large number of engineers that write a kind of code that needs to be then fixed up after the event. What what, what has to happen next is the engineers that aren’t getting their code into prod, they need to be helped, they need to be coached, the best way for them to do that is to look at how, how the senior engineer has actually edited and change the code. And to do that openly, right. So to have a review, this code is, is better now because we restructured how we had we designed it, built it and so forth. And then that engineer, the engineer that’s on the learning side of things gets better and grows and hopefully goes on to become that senior engineer, it’s a normal kind of a path, saying for tests, same for all of the other disciplines. So yeah. And then when they get better at doing those things, they can move on to doing other things. Yeah, it’s also a real tension, because of course, you’ve got really good engineers that are producing really high-quality code, you know, do you really want them to be managers, and very often, by the way, those individuals become managers and say, Hey, this isn’t for me, I just wanna get back to writing software that works, you know, so, but it’s all part of the fun and games, but definitely, in terms of breaking down the silos, and making it easier to move people between teams, those kinds of behaviors, that openness, that transparency, and that that culture, you know, you know, it’s interesting, one of the companies that do a lot of work with, that frightens people off, if you’re not an engineer that’s comfortable to have your code explored and reviewed, peer-reviewed. You probably don’t, you’re not going to fit in, you know, they have an expression in that particular customer account, if your last six days, your last six years. But if on the seventh day, you’re feeling really uncomfortable, and yeah, good luck. does happen, you know, people just won’t stay.

Jason Baum 33:44
This might not, this might be an example. And forgive me because again, so if you listen to this podcast, you know, I have a four-year-old daughter, and everything in my life right now is surrounded like everything goes back to parenting. And an interesting example of this is the company Disney. Walt Disney has a team of artists right now they’re digital artists, but they are artists. And you know, whether you’re coding whether you’re drawing, you know, they’re working on collaborative teams, and then they have peer reviews. We were watching the documentary about the making of frozen their biggest franchise hit right. And they have several peer reviews for just one cell, right one cell of the movie, get seen by like 15 people they sit, they talk about it, what could they do differently. They’ll have you know, the directors will be there, the producer will be there, they’ll pick it apart, make them go back to the drawing board, redo it, come back present it again and it is just constantly analyzed, but by a team collaboratively. And they produce they take those same designers and or those same artists, and they’ll be working on another feature film while they’re working on that, and they’re just doing these different scenes. And so they’re just dropping a plate picking them up moving them on to something else. And, and, but then collaborative, collaboratively coming back and talking about holistically how it fits into that. And I thought, wow, that’s kind of what we’re talking about a little bit. And I feel like Disney does it so well because they produce so much content in a year.

Brendan O’Reilly 35:28
So it’s really interesting. My youngest son is 24. And he’s an animator.

Jason Baum 35:32
Okay, so you know a little bit about this.

Brendan O’Reilly 35:35
Yeah. Well, oddly enough, yeah. So when I first when he first started to work as an animator, two or three years ago now, we started talking about how work was organized. And guess what a lot of the core concepts for software engineers originated out of Disney, this idea of a storyboard and visualization of work, and they use JIRA. And so he was only working there in this company for a very short period of time. And he started talking to me like, and this release, and that sprint and other oh, wait a minute, this kid. He’s right up there with it. So the thing that also occurred to me when you were speaking, though, was kind of, there’s a real tension here between the context switching that’s required to go from a piece of work, I’m really intensely focused on now, to kind of getting my head out of that and going and looking at another piece of work. Now in software terms, what we try to do is we try to, automate how we build the software. So we have this idea of continuously integrating, integrating the code that all of the engineers are working on. So that we can be objective is to kind of break the bills right now, historically, that was a bad thing, people who sort of fear of breaking the bill, but actually breaking the bill is a good thing. Because we need to know now not in six weeks’ time when we have to do a compute context switch to get back and look at what was broken. I saw I must I’m now curious, I’m now gonna ask my son. So when you’re asked to do the peer review on something that’s nothing to do with what you’re currently working on, is that a bit of a head melt? Is it good? Is it a good switch off or something? Because in general, when an engineer is asked to work on something until it works, that’s the system right? We don’t really want to have to come back to that in six weeks’ time and fix it, because now we’ve got the wreck in each context, which is about an 11% overhead. That’s sorry, that’s for the first while, right for the first context, which the second is 33%. Okay, so now we’ve lost a third of a working day, we just switch context-wise. And after that, it goes exponential. It’s just like, I’m getting nothing done because I’m just moving between tasks, you

Jason Baum 37:34
know, but I wonder to bring it back to something we had talked about earlier. I wonder if that keeps the energy level up? Or is it frustrating? I don’t know. Because, you know, maybe it keeps it fresh. You’re not constantly on the same thing. I don’t know if you’re pulling your hair out because of an issue and you can just jump off it for a day working on something else? I don’t know. Maybe it does to see, you know, that’s maybe a positive take on it.

Brendan O’Reilly 37:59
Yeah, I mean, yeah, sometimes they change can be as good as a rest, you know, right. Absolutely. Yeah. I mean, it certainly if you’re rattling on whatever the problem is, and you’re kind of iterating on a piece of code with some engineers and just getting nowhere there is a point it’s like if you do crosswords a Sudoko. Sleep on it. And in the morning, things seem to be clearer.

Jason Baum 38:18
It’ll come to you in the morning, right. Yeah, yeah. I mean, and look, some of these practices to bring it back to remote. It does make it difficult to do some of this peer review and to collaborate and, you know, sometimes even just looking at the same thing at the same time with someone else, if you’re not in the same room, that can make it difficult. So,

Brendan O’Reilly 38:43
okay, but let me give you some upside. So I did a call with three or four CTOs. I wrote a blog about it. Actually, I think I’m gonna share it with you the remote working learnings. There are a couple of upsides. So normally, the CTOs that I spoke with, were quite happy to have their engineers work remotely because there were fewer or they go drive-by shootings. Are you familiar with that expression?

Jason Baum 39:04
In this context, no,

Brendan O’Reilly 39:08
so engineers sitting at his desk and a customer by power, you know, one of the business guys bypasses all of the procedure in terms of the sprint and all that kind of thing just drives by and says, Hey, you wouldn’t just give it 10 minutes and fix this for me. And, you know, some engineer gets kind of shot as they drive by right, so, so less of that more opportunity for focus. Another big upside was people who tended to be quieter at reviews in the virtual in the Zoom world. You know, the person controlling the Zoom could mute everybody and ask the quiet guy to speak up. Okay. And for the first time they were being heard in that sense, so there were some positives there. And I think the other one that was very interesting was writing like an Amazonian. I don’t know if you’ve seen it as I have,

Jason Baum 40:00
yes, I have seen that.

Brendan O’Reilly 40:02
So people were, you know, put on training courses in one instance, to take the waffles and put the fact in. So I

Jason Baum 40:10
love that. Yeah. Yeah. Well, my gosh, Brandon, we could talk about this topic, I think for another two hours easily. There’s a lot to say here. I hope you’ll come back. I think we should review this. Again, I think this is a topic that’s going to continue to evolve. Certainly, I mean, it always, it always has, it always will. The more work environments we have, the more and more roles that pop up and are created, the more I think will feed, feed the silos but then also break them down. So I think there’s a lot we can kind of talk about. So I hope someday you will come back and continue to share with us,

Brendan O’Reilly 40:53
that would be a pleasure. This is the most fun I’ve had in the podcast in a long time.

Jason Baum 40:56
Awesome. Okay, so I did warn you about this. Sometimes I warn our guests, sometimes I don’t, that we’re going to ask a very personal question. So I hope you’ve thought about it. Today, our closing question is going to be if you could be remembered for one thing, what would that be?

Brendan O’Reilly 41:19
That I died trying

Jason Baum 41:21
I love that.

Brendan O’Reilly 41:23
I think I think continuous improvement and continuous learning are, you know, they’re just part of who we are. And as long as you have those things and you die trying then yeah, you’re I’ll go happily to my grave that’s on the gravestone that’ll be on behalf of

Jason Baum 41:41
die trying. I think that is fantastic. I think that would be I think anyone just could just hope for that. Right. That’s great. Thank you so much, Brendan. It was an absolute pleasure having you on the podcast

Brendan O’Reilly 41:54
Likewise, take care, Jason.

Jason Baum 41:55
And thank you for listening to this episode of the humans of DevOps Podcast. I’m going to end this episode the same way I always do encouraging you to become a member of DevOps Institute to get access to even more great resources just like this one. Until next time, stay safe, stay healthy, and most of all, stay human, live long and prosper.

Narrator 42:18
Thanks for listening to this episode of the humans of DevOps podcast. Don’t forget to join our global community to get access to even more great resources like this. Until next time, remember, you are part of something bigger than yourself. You belong