Narrator: 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: 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: 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. Here's a surprised hint I do.

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: 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: Yeah, you know, you know, what's so different about

VR is like, and you're describing the 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: 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: There's haptic feedback. There's the 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 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 there's no such thing as more

communication. There is effective 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: 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 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: 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: 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 that's, that tends to be and it is the most productive

way for 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 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 which is really

the waste so they're 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: 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 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 future rather

than today. Right? We are we that's, it can get overwhelming,

it can get complex. We actually, we 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: So for me, and 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 a 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, that 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 we're at our most productive. I think in

terms of the ideation let me 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

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: My guess is maybe one to 2%? Oh, you're

Brendan O'Reilly: 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 the

look, I digress, we can talk about innovation another day,

we're here to talk about silos.

Jason Baum: 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 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 in breaking down silos?

Brendan O'Reilly: 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 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 thing that really works, there is 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: Today's episode of the humans of DevOps podcast is

sponsored by collide collide 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 callide.com/h o dp to sign up

today. That's callide k olid.com/h. O. DEP enter your

email when prompted to receive your free callide 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 environment present? With sound?

Brendan O'Reilly: Yeah, so yeah, so here's, here's the thing,

right? I think it's a really good point, people, when 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 ladies 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 you know, when you have a an all hands on the

Zoom to say, Hey, listen, particularly thank to engineer a

or b for their for their 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 that whose feature is just no

cost to one side.

Jason Baum: 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 with their development team in

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 that

was one example from from last week that was shared with me.

Brendan O'Reilly: Yeah, so let me let me just add to that,

that's really interesting. So the university the 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: why don't? 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 lunch room. 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 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: 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 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: you know, when you can feel it, you can feel it

when someone's new, 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 fit 100 time, 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 into 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: 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 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 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 can we find a way to, to

think about a problem? Can we get a bit of timeout can can

can, 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: 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 to 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: 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's 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: We call it we, it doesn't make any sense. But

that's that's what we do.

Brendan O'Reilly: 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: I well, I know the Wright brothers. But

Brendan O'Reilly: 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 turns 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 we'll Yeah,

Jason Baum: it's a great exercise because it does make

you think outside potentially your comfort zone, and thinking

the other person's shoes. I mean, that. That's, that's a

great exercise. I'm sure the the quality of the product could

just improve based on your knowledge of,

Brendan O'Reilly: yeah, I just want to I don't know how it

worked in, in football, but we did that with our team. So with,

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: 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: Yeah. And I think it's a route to management

as well. I mean, I work with a coach some of the, you know 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 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: But is that 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: Yeah, absolutely. I mean, to 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 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,

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 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 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: 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 enter. And an interesting example of this is

the company Disney. Walt Disney has a team of of artists right

now they're digital artists, but they are they are artists. And

you know, whether you're coding whether you're whether you're

drawing, you know, they're working on collaborative teams,

and then they have peer reviews. We were watching them 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 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 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: So it's really interesting. My youngest son is

24. And he's an animator.

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

Brendan O'Reilly: Yeah. Well, oddly enough, yeah. So when I

first when he first started to work as an animator, two or

three years ago now, and 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

this kid. He's right up there with it. So the thing that also

occurred to me when you were 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 in

software terms, what we try to do is we try to, we 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 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 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 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: 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 that's maybe a positive take on it.

Brendan O'Reilly: 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 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: It'll come to you into in the 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 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: okay, but let me give you some upside. So I

did a call with 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's a couple of upsides. So normally,

the CTOs that I spoke with, were quite happy to have their

engineers work remote because there was less or they go drive

by shootings. Are you familiar with that expression?

Jason Baum: In this context, okay, so,

Brendan O'Reilly: 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 was 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 like I have,

Jason Baum: yes, I have seen that.

Brendan O'Reilly: 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: 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

the more I think will feed, feed the silos but then also break

them down. So I think there's a lot we can we can kind of talk

about. So I hope someday you will come back and continue to

share with us,

Brendan O'Reilly: that would be a pleasure. This is the most fun

I've had in the podcast in a long time.

Jason Baum: 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: That I died trying?

Jason Baum: I love that.

Brendan O'Reilly: 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: 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: today. Likewise,

Jason Baum: take care, Jason. 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: 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