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