Join us as we gather around the hedge,
where we dig into technology, business, and culture
with the finest minds in computer networking.
Hello, Tom. I think since the last time
I've seen it, your plant is
going further
towards the window.
Yeah. Yeah. It wants it wants the light.
It's it's moving towards it.
You gotta turn it every now and then.
Oh, right. Or else it'll get lopsided. Well,
maybe I'll just see how long it goes.
Plant abuse. We're talking about plant abuse.
Wow. And Yvonne is with us in the
she shed with the frog lamp, which is
awesome. You can actually see the frog lamp.
Yeah. I need to figure I don't remember
actively turning it off. So I don't know
if my bolt's gone out or if it's
come unplugged or I have to take it
out. But I also have a plant. See?
Yes. I see. Yeah. Where the grow light
looks like.
Yeah. Yeah. With with a girl like a
dickenbafia.
Dickenbakia.
Dickenbafia.
Okay. I don't know. I can't pronounce anything
anyways. I've become a plant lady.
So if you come to my house, I
have plants everywhere. I've become that person.
Is it intermixed with cats?
No. Because my husband is deeply allergic, and
I don't like cats. I'm a dog person.
Yeah. I'm more of a dog person too.
I used to have cats when my kids
were young. And
I don't care how hard you try, they
still get on your counters.
And there's just something
about cooking dinner,
and the cat has wandered around on the
counter, and you're just like,
no. I just, it's not that I don't
like their personalities. Not that it's just
that just really disturbs me.
So I have a our our cat only
has three legs and she cannot make it
to the counter. Oh, well, there's yeah.
Not not a not an active solution you
can take, but if you find it for
me, it might work out for you.
Wow. That voice you hear in the background
or that that that radio voice that you
hear talking about his three legged cat is
Chris Grundemann.
Hi. Hey. Yeah. Who needs to be a
guest more often.
We need we need this we need Chris
on more often. So alright, Chris. So we're
talking
about
NetEng
in culture. And I just wanna say
that
I have been in toxic cultures. I have
been in very good cultures.
And
toxic cultures are really bad. They really hurt
people.
I mean, it's not just a matter of
does the work get done. It's a matter
of no.
You're hurting people's families. You're hurting people.
Like, this is that that toxic culture goes
home,
and it's it's really horrible.
They're also bad for business. I'm gonna say
that too. But go ahead, Chris. Exactly right.
Yeah. I mean, that that's the thing. I
think, you know, definitely in the extreme cases,
it it's bad for for for for everyone.
Like you said, Russ, it can be really,
really bad.
But even in fairly functional,
organizations,
you can be missing a lot of opportunity.
Right? And and this goes into I think,
you know,
I I I and I kinda break it
out a little bit. Right? Culture is a
big part of this. I think leadership obviously
plays into culture, but then but but but
plays a little bit wider role, and then
the organizational structure itself. And I think all
three of those things, you know, I don't
know if we wanna call them a a
triangle or three pillars or however you wanna
look at it, but I think those three
pieces really, interrelate in in a way that
produces both, you know, the outcomes of, like,
are people happy? Do they wanna come to
work? Or are they excited to to be
here? And, also, how is this business gonna
perform to to a Von's point. Right? Definitely.
Isn't it funny how things are in threes?
Quick
peak quality,
state, state,
state surface in optimization
and,
you know,
the cap theorem, everything's in threes.
That's it's like a universal thing. So, you
know, if you found two, you've got to
go find the third. Cause there's a third,
stop it too. Yeah. Don't stop at 2.
There's 3. And if you get the 4,
it's too many.
So yes. So when you talk about culture,
what do you mean, Chris? Like, we're not
talking about just
the problem of the people being toxic and
stuff like that. You're talking about something very
specific or more specific. I think so. Yeah.
DevOps and stuff like that.
Exactly. Right? And that's where this has come
from for me is I've been you know,
this term net DevOps gets thrown around a
lot. And, obviously, you know, I've been focused
on network automation more and more and more
over the last, I would say, ten years.
It probably goes back further than that. Right?
The first networks I worked on, we built
with software controls. We just didn't know any
better.
And and then, you know, more recently, it's
it's it's gaining traction in in more places.
Telcos are finally waking up to automation.
You know,
enterprises are waking up to it. But the
the problems they're running into
are are not technical. And and so as
we start talking about this net DevOps and
what does this mean, I I really started
kinda diving into that and and looking back
into DevOps and what does that mean. You
know, having been a network engineer for the
last twenty years, I I wasn't, you know,
super
tied into the DevOps revolution that's kinda happened
over over those years. And so I'm going
back and learning about it now and trying
to understand how to apply that to NetOps.
And and most of it, again, comes down
to culture, organization,
and leadership.
The yes. You need the enabling technology, but
that stuff exists. And so this culture is
more like,
there's a guy named, Ron Westrom
who was a sociologist or psychologist from the
eighties who who wrote about this. He wrote
a paper or a book on these typologies
of of culture, and he broke it down
into three pieces, right, or three different types
of culture.
Well, one is,
the power centric culture. I forget the actual
name, but it's basically
is the word. Psychological. That's
right. Exactly.
Which is that's the terrible one you're talking
about, Russ. Right? Where Yeah. Where if you
make a mistake, you're, you know, you're you're
getting taken out back and and, you know,
yelled at. And, it's all about power and
and and structure and and and there's, you
know, that kind of thing. Then there's another
culture, which is the bureaucratic one, which becomes
kinda rules based. Right? And it's not that
bureaucracy is bad. You know, if you got
a big enough organization, you've gotta have some.
But a bureaucratic organization,
they would you know, the the overall culture
is we're gonna follow the rules
at the expense of of anything else. Yeah.
We don't even really care
if it works. We just care
that I followed the rules. And by the
way, this is big in
government and military organizations. If you've never been
in the military
or around government,
the pointy end of the military tends to
be much less rules based, which is counterintuitive.
But the back end where people do
quartermasters
and
deal with supply chains and everything else,
it's extremely
rules bureaucratic,
rules oriented. So And and you're gonna see
it a lot in your heavily regulated industries.
Right? Which which are influenced by government. Right?
If if if, in health care in The
US with HIPAA compliance
or in some of your,
financial services, especially banking
less so in venture capitalism
or,
those kinds of orgs, but yeah, anything that's
heavily regulated, they're also gonna lean toward
being bureaucratic. And and there are reasons for
that. Yeah. But but then that if if
your culture embraces that structure,
then it's gonna be hard for harder for
you to innovate.
Yeah. And I think there is a separation
here between, you know, having bureaucracy
and being in a bureaucratic culture. I think
there's a good reason to separate those. Yeah.
Yeah.
And I would actually say before you sorry.
Yeah. Yeah. The other thing I would actually
say is is that I think bureaucratic culture
is becoming more of the norm in a
larger number of companies
as I walk around. Right? Bureaucratic culture is
I take
my
thing back to the store. I bought it
to return it. And they say I can't
do that because the computer won't let me.
It's the rules. Right? It's the rule. It
doesn't matter how the how the customer feels
Doesn't matter whether you're using losing business.
What matters is the rules are followed.
And that I think is becoming more common.
So sorry, Chris. Go ahead. Well, I'm just
gonna add. There's a reason for that because
when you get a really sufficiently large organization,
50,000,
a 100,000,
a 150,000
people, if you don't have some sort of
bureaucracy and organizational
structure,
those people cannot be effective. Like, they need
to know what their job is, where they
fit in the org, how they interact with
other
groups, other teams, and you have to have
some degree of bureaucracy. So I I think,
like, large organizations,
the gravity of their size is just gonna
drift that way.
And it takes serious leadership
to push against that and keep it.
And then I'm not gonna steal, steal Chris.
It's under Chris. What's the to to keep
it what? What's the next Yeah. So the
so the third type is is a generative
culture, which really the definition there is it's
results oriented. Right? So it is what we're
doing effective Is the is the the the
thesis that everyone works on?
Right? And and if everyone's driving towards that,
sure, you're you're gonna have process. You you
have to. Right? And you're gonna have hierarchy.
Again, in our large organization, you kinda have
to. But the the the shift there is
that culturally,
we all know that everyone is out to
provide the best outcome,
which, you know, there there are some things.
Right? This is you know, it sounds great.
It's not easy.
Everyone has to be aligned because in order
to get good results, we have to know
what the goals are Mhmm. Which requires this,
you know, communication and this gets into psychological
safety and some things like that. Yeah.
Yeah. I think
the bureaucracy tries to tries to force communication
into certain patterns and certain interaction surfaces between
different groups.
And
and communication outside of that just sort of
doesn't compute. Like, in most of the large
companies, all the large companies I've worked with,
there's this idea that if you wanna talk
to another team, you have to kinda sort
of go up through the hierarchy. And if
you don't do that, you're breaking the rules.
And, you know, I found that you need
to break through in those organizations, you need
to break the rules to get anything done
anyway. But it's but it's sort of, like,
not okay to do that. Yeah.
Yeah. Yeah. And and I would also say
that part of the reason for this is
also that people or bureaucracies like to measure
things. They like to quantify things.
And you can only quantify things if the
relationships and the work is totally exposed.
So you can't have skunk works projects.
You can't have people sitting in a corner
in the in by the water cooler
working on stuff. That stuff has to have
a process around it. It's gotta be recorded,
you know, all of that because you've gotta
make sure that you have quantified and measured
all of those things.
Well, I would say you you actually
you you create Skunk Works projects sometimes
depending on who you have. Right? Like
and I'm using Skunk Works in a very
loose, like, you know, not not the original.
But, like,
sometimes if you get sufficiently talented, highly motivated
people, they'll just ignore it. And so and
and do their own thing and, you know,
and you can argue whether that's good or
bad, but I think it's a reality in
bureaucratic organizations that, you know, if you have
those personalities there,
I think that's kind of fun, actually. I
think that's a great way to get things
done, but it's pretty disruptive.
Well and and I'll also add the,
the degree to which people are willing to
do those informal
skunkworks kind of projects
is is gonna be directly related to the
amount of risk that they feel. Right? So
Yep. If if you feel like you have
enough freedom
to reach out to the guy across the
cube wall or the the the gal on
Slack and say, hey. I had this idea.
Would you work on this thing with me?
They have to have enough psychological safety, enough,
freedom to say, yeah. I'm gonna give a
little bit of my time to this, and
it's not gonna put my job at risk.
Because I think, you know, depending on how
much risk people feel or whether they, you
know, feel like they're it's gonna impact their
compensation
or rating or something like that,
will depend on how much,
cooperation you get when you try to do
those
informal
outside of the system
kind of that that work, which is where
all the magic happens, frankly.
So how does this relate to DevOps? This
is all great social theory.
Sure. But how but how does this relate
to DevOps?
Well, so there's a couple pieces here that
I think that that fit in. Right? And
and one of them is, I think,
another defining characteristic between these things here, and
I think part of what Yvonne and Tom
were leading to, right, this idea of, you
know, that that risk and things, the inverse
of that, I think, is is trust.
Right? And so if you if you're able
to trust
people in other parts of the organization, whether
it's, you know, laterally or or below or
above,
then
that's a that's kinda how you start moving
towards this more generative culture. Right? And and
that leads to more collaboration.
And the collaboration becomes really, really, really key,
I think. And so what we've seen, in
in the DevOps stuff, right, is that the
a big part of what happened there
was creating these, you know, if you look
at team topologies,
which is pretty famous looking at the organizational
structure side of this,
they talk about stream aligned teams.
And this is again software development side of
things.
Other folks call them service teams. Right? But
what you basically do is say, okay. Instead
of being broken down by in functions,
so you've got, you know, the front end
people over here and the back end people
over here and the database people over here.
Instead, we say, okay. This team is gonna
work on this problem and this problem is
a is a subset of what the overall
company is working on and they're gonna end
own it end to end.
And and the reason that this all comes
back to culture is that that requires this
collaboration and this trust where you've now you've
got a database engineer and a front end
engineer and a back end engineer on the
same team, and they need to be able
to collaborate,
and they need to be able to work
with other teams in in in structured ways
and and trust that the the the platforms
they're relying on are gonna be handled well
and trust that,
they're gonna be getting the feedback they need,
and then increase this collaboration, which then leads
to better results. So it it again, that's
why I think they're tied together. Right? The
leadership needs to enable this. The culture has
to be enabled through the leadership, and then
you need to actually put the team structure
together. But a lot of this comes down
to collaboration.
So how does that relate to CICD, for
instance?
Mhmm. Do you think that I I now
when I think of the this collaborative structure
you're you're talking about, I think it actually
improves
CICD
because now you're doing CICD on a functional
level level or on a service route level,
however you wanna put it, as opposed
to, oh, I do CICD for all of
the front end. I do CICD for all
the back end. No. You actually are doing
CICD
for a product
or a module that is then used.
Maybe the customer doesn't see it,
but it's still a unit. It's a thing.
Well, absolutely. I think because part of this
is when you're creating this cross functional team
that's responsible for a set of services or
a set of features, they now own it
end to end. And and I think that,
you know, maybe this isn't quite a stake
in the ground, but that that's the only
way to really have CICD is when you're,
you know, when there's not handoffs in that
process. Right? So So, some of the biggest
challenges with CICD is if you've got,
you know, somebody's doing part a and then
some other team or some other person is
doing part b and then there's an approval
process that goes over to QA and then
there's a security approval process that goes over
to team c.
Right?
That that blows up CICD because you've got
these handouts, you've got these checks, and and,
sure, you can kinda cobble it together.
But that collaborative approach of actually owning this
end to end, I think is what enables
what I would call true CICD where you're
actually doing constant development, constant improvement because,
again, there is this one collaborative team that's
working on this full stream. Right? The whole
flow from from start to finish of whatever
this kind of chunk of the work is,
and then they're trusting that the other chunks
are gonna get done. And I think a
way to, you know,
you know, the the alternative there is is
basically silos. Right? And we've talked about silos
and and silo busting a lot in IT
over the last, you know, ten, twenty years.
And that's kind of you know, these two
things are kind of opposite of each other.
Right? So, there's this collaborative approach where you're
actually kind of seeing something end to end.
I think silos are kind of determined by
dependencies. If if you're dependent on another team
that that's kind of how you know you're
in a silo. And if if you if
you've got all the dependencies inside the teams
so you can get your work done, then
you don't have silos. Right? And and that
comes back to, again, the CICD, I think,
functions better when there's not those silos, when
there's not those handoffs.
And, again, I think that's directly applicable to
to networking as well. It's a little different,
but not that much different, as far as
being able to own piece of the the
the stream. I think the d in CICD
is really important to understand because there are
two ways to see this, continuous delivery or
continuous deployment. And you can be operating just
because you're using c I c d doesn't
mean you're not in a silo
continuous delivery
is absolutely for organizations that are siloed like
I built my thing here's my artifact it
was delivered to you now somebody else go
deploy it and make it into a useful
machine
whereas
CICD as in deployment means
you you develop it, you work, you test,
and you and you and it ends up
in production, not it just ends up on
somebody across the wall. I think I think
there's a lot of places doing CICD where
it's where it's actually delivery and not deployment.
And I think what we're talking about is
deployment. It's about making the whole thing,
you know, from end to end collaborating,
until we get a useful business machine out
of it.
Makes no sense. Yeah.
Yeah. That actually makes sense to me too,
that there is
the CD being deployment means that you're actually
building something that's useful
end to end rather than this little component.
And it's okay in some cases to specialize
and deliver a little component. Right? Like, people
who make wrenches, they make wrenches, and they're
excellent at making wrenches.
And they design new ones, and they innovate
in that field,
but they don't make cars.
And people who make cars with the wrenches
make cars with the wrenches.
And so that's that's a siloing that's rational
and logical.
Each problem is large enough that it needs
to be its own thing.
Well, I don't know if that makes it
a silo though, Russ. I I I think
there's I think that absolutely specialization is is
still part of the picture and it has
to be.
I I think,
for instance so so another kind of, you
know, one of the things I I recently
reread,
Henry Ford's biography, biography, and and I was
kinda struck because we talked about him as
being, like, you know, the father of the
assembly line. But a big part of what
he did comes back to, again, organizational structure,
and and part of what he did is
he he took the the, you know, the
sharpest folks
and and moved them in away from the
assembly line to actually build tools.
And and and they were building tools that
enabled the folks on the assembly line to
work faster and better. And and so there
is specialization there, but I don't know that
that's actually a silo because there's not quite
a dependency there. There's one team enabling another
team. There's not, you know, there there's no
waiting on that team. And so so I
think without the dependency, you don't quite have
a silo, but you definitely can have specialization
without without silos and without dependencies, I think.
That's interesting. What do you think, Tom? Yvonne?
Yeah. Yvonne, you've not been talking either. Go
ahead, Tom.
Yeah. Go ahead, Tom.
I I like I like the analogy with
the,
with the ranch and the and the car
because they're both critical. You have to have
both of them. I I that makes sense
to me. I think the, there's not that
there's a dependency in the in the fact
that you have to have the tool in
order to work on the car. But but
it's not
they're,
loosely coupled. You know, you can you can
do whether you can you can get a
wrench for somebody else. You could, you know,
use a different type of tool if you
needed to and so I think that brings
another thing in which is tight versus loose
coupling and systems and where do they need
to be tightly coupled and where do they
need to be loosely coupled and every place
they're tightly coupled we have to be very
careful we have to collaborate we have to
be very close to each other
And, you know, that's I I I think
I think the ranch,
analogy is pretty great.
Well, and I was thinking about, you know,
how are how are we thinking about, like,
what is a silo? Because it's is it
it and it's it's not just a group
with a function. It's a group with a
function
that operates
too independently
from the rest of the system, I think.
And so, you know, we we've been talking
about this, but it but it continues to
all go back to communication, collaboration. Do we
have enough trust,
communication,
collaboration?
Do we have enough trust
to go to another part of the system
and say, hey. Like, we found this problem
or this thing isn't working as well as
we think it
should be. Or we'd like to try something
new or we have
this
idea. We can do this part of it,
but we need your help to do that
part of it. And does everybody across that
organization
have have have the freedom and the trust
and the ability to to jump in there
and try to fix it together? Because most
of our systems are so complex, very
rarely, try to fix it together because most
of our systems are so complex.
Very rarely can one team, one group, one
specialization
impact
broad change. And so that's, you know, that's
where the you you gotta have organizational groups.
You gotta break down people into teams
so that they can be effective. It the
the question of whether or not it's a
silo is whether or not they they, frankly,
play well with others.
Yeah. So the way I've been looking at
it, and and may be my own harebrained
idea, but I've been looking at, you know,
at least to me, the the problematic definition
of silos. Right? So problematic silos are defined
by dependency. That's I've said this a couple
times, but, you know and then there's there's
a bunch of work around dependencies as well.
There was,
researchers Malone and Krauston, who created this coordination
theory, and they talked about these different levels
of of coordination of of dependency. Right? So
flow
is a flow dependency is a sequential. Right?
So I have to do a before I
can do b before I can do c.
And and if you've got different teams doing
those, then you can potentially have these bottlenecks
where where if one team's running slower, the
whole thing falls apart. Right?
There's also what they called sharing,
which is multiple teams or people need the
same resource. And so, again, you can you
can see can you can have contention there
and, again, create dependencies where, you know, maybe
we have to, you know, we can't all
maybe we actually can't all use it at
once or or maybe, you know, there's,
scaling challenges there and things like that. And
then
there's another dependency, which
which is fit, which means, okay, there's multiple
teams building different parts of the same thing.
And when we're done, they all have to
fit together. And so there's dependencies because if
I build my thing wrong, it's not gonna
fit with Yvonne's thing or or Tom's thing
might not be able to plug in. Right?
Which I which I think is interesting. And
so so I see those those dependencies. If
you have dependencies, then maybe you have a
silo. And I think that's where if you're
looking at kind of this bigger picture of
organizational design, that's how you might spot those
things and start to
open up coordination,
and and cooperation a little better.
There By by by finding those dependencies and
and smashing them, essentially. Yeah. Everything you've described
as as a dependency
could be to be described in the programming
world as an API.
And in the networking world as an interaction
surface.
Right? These are all things that things interact
here,
and they have to interact in a certain
way. And by the way, that's part of
the reason for open standards or was,
was that open standards are supposed to allow
you to have well known interaction surfaces or
dependencies
that everyone knows,
and they all work the same. So people
can build OSPF,
BGP on their own, they can build forwarding
planes, whatever, it doesn't matter. You build all
this stuff and it should work together
because
on the wire, the wire that connects the
devices,
the format on the wire
is the same
for everybody.
So here's here's my question. Is Conway's Law
inevitable?
Is it possible to build an organization where
you have high trust and high communication
but still have the machine be
modular and coupled in the right way, though,
so that it doesn't mirror the underlying organization?
Do you guys think that that's possible?
It sure looks like Conway's Law holds,
even here. Right? And and I think even
with coordination and cooperation, you've still gotta be
careful of those team boundaries.
I I think for sure. I I think
I think it it it's natural. Right? If
you if you put a group of people
together, they're gonna work on a thing that
has boundaries of of their knowledge and their
ability. And and so you're just going to
see those those boundaries in the system that
they build. I I I don't know how
you get around that at at all. I
don't think this solves that. I think this
needs to take that into account.
And every well, I was thinking everything we've
talked about today
is really operating at the assumption that Conway's
law is true. Right? That that your work
product, the thing that you build, is going
to mirror your communication structures, whether it's, you
know, your org chart or whatever. And the
the way I've summarized this very crassly, and
I I don't think it's original to me,
but, like, you ship your org chart. Right?
Like, what you ship
looks like your organizational and communication structures.
And and to me, it's it's almost a
a truism.
Right? It's like just this is how humans
operate and how they build things.
And part of structuring an organization is figuring
out what do we wanna build and then
how do we organize our people around
how to build it. And that's the difference
between
building and being a people leader and being
a technical leader. But interestingly enough,
like, those even those two disciplines
have to work together
Because if they don't, you'll you'll end up
designing an organization that doesn't support your tech
technical needs.
Yeah. Yeah. Yeah. That's what you'll do. Or
a technical organization that doesn't support your people
needs,
which which actually happens. It happens a lot
as well.
Now I also wonder if there's a scale
element here where
smaller organizations
are just better able
to be flexible in what they ship, like
what you're talking about, Tom.
Right? Like a smaller organization, can it turn
faster
and and
decouple the product from the organizational
structure
better just because it's smaller?
Or is that true all around?
Well, I I think it's true, but I
think it's true because of exactly what we've
been talking about. Right? Like, so,
studies have been done. Basically, one human can
have about a 150
human connections,
right, inside of an organization. So once your
organization gets, I mean, if it's smaller than
a couple 100 people, like everybody knows everybody.
So there is no
real communication hierarchy.
You know
that Joe
over in marketing does x y z, and
you can message Joe or walk up to
Joe and say, hey, this is what I
was thinking. What do you wanna do?
So it it's it's still based on the
communication structures. It's just in your smaller organizations,
there are fewer interaction services.
And that organizational
structure hierarchy doesn't get in the way because
people can scale to that size. But then
once you get bigger, like, we humans can't
scale beyond a 150, 200 human connections.
Yeah. So I would The Dunbar's number,
stuff. Right? So Dunbar did did work on
this, and then it goes back to, like,
AWS's famous, like, two pizza rule and things
like that where, you know, the team needs
to be, you know, probably less than 10
people. You can have squads of teams, and
and this is how you kinda chunk and
build these things out.
But definitely easier at smaller scales. Absolutely. Yeah.
I was I was just thinking, this is
sort of the nerdy interpretation, but we figured
out how to build IGPs without full mesh
of connectivity. Right? What's the human equivalent of
the OSPFDR?
And Yeah. We still get we still get
enough information around to move packets. So I
I don't know. That's
I I'm not sure how well, OSPF translates
into human domains, but but, you know, it
doesn't have to be full mesh. Right? Yeah.
When you think about, like, route summarization. Right?
That's a lot of what your communication structures
in your organization are. How do I take
this very complex detailed information, summarize it, and
then
information they need,
but not overwhelm them with so much information
that they can't function. I mean, that's that's
exactly what route summarization is too. Right? And
not and not and and
understand the optimizations that you're stripping out when
you do it because you do strip out
optimization.
So let's go back to to to NetOps,
though. How
how do you think this all of this
relates to NetOps? Is this mostly a matter
of
organizing network operations teams,
NREs, network of network reliability engineers, whatever you
wanna however you wanna do it,
in a different way? Like, should there be,
like, a lot of companies separate architecture from
design,
from troubleshooting,
from
security?
Like, is it better to rethink that and
say,
no. We should really have a team
that does the network
core, and that's what they do. And to
the rest of everybody else who connects to
the core,
that is an opaque unit
managed by that team,
all of it.
I mean, is there, like, an organizational
In short, yes. I mean, I I think
I think yes. I think going down that
path. Right? I think if we if we
back up a little bit and we look
at the network
and and
operating the network itself
more as a software project and and we
approach it with these kind of DevOps principles,
I think that's exactly right, Russ. I I
think that is how it needs to work.
I think there are maybe core network functions
that become kind of a platform, you know,
in in the software speak to the rest
of the organization
where that, you know, that that's being operated
and it's being delivered as a service to
the rest of the organization
and so then no one needs to know
how that works and and to some degree
we do this. I just don't think we
do it very consciously and well. Right?
You know, there's there's some folks who talk
about going back to the earlier piece, right,
that,
especially in software architecture, right, looking at Conway's
Law and some of the things that Yvonne
and Tom were saying,
there's a lot of people who will tell
you that, you know, a software architect
actually needs to have the skills of a
people manager because you actually have to design
the organization to get the software outcomes you
want.
Another way to look at architecture
is as the smartest folks who have the
best practices
and maybe instead of designing things and and
sending designs down to other teams to implement
them, maybe the architecture team should be reimagined
as an enabling team that pops in
and provides expertise where it's needed, when it's
needed so that these more stream aligned teams,
maybe maybe there's a team that handles,
service provisioning for
HR. I don't know. Right? Like, how how
do you chunk this down into a team
that can be a collaborative team that can
see something end to end, and then you
have the architecture team that's more of an
enabling team that can pop in and provide
advice
as needed. Right?
And then maybe there's a, you know, a,
complicated subsystem team in the in the team
topologies language that's focused on on BGP routing.
And and and they're handling that off to
the side. And and, again, they can maybe
provide that as a service to others or
or they're just handling it and people can
interact with them as they need. But, yeah,
I think I think, you know, looking at
how we can break this down in different
ways instead of just saying, okay. It's tier
one, tier two, tier three operations,
engineering, architecture, security is over there, DNS is
over there, monitoring is over there, and you
guys figure it out. Because now you're creating
a situation where you do have to have
that full mesh between all these teams, which
is not,
appropriate because,
cognitive load is a big part of this.
Right? If if if I if I've got
to know all the things and know who
to talk to for all the things and
I've got to hold all that state, I
don't have any brainpower left to do my
job. But if you can take all that
away and provide me these things as a
service and I know just the things I
need to know and everything else kinda just
works,
then I can focus a lot more cognitive
load on the actual job that I've been
hired to do instead of on all this
other stuff of, like, okay. Where in the
Wiki do I find the, you know, the
BGP code that I have to copy and
paste?
Yeah. I like the I like the enabling
team,
version of architecture,
Chris. I think that's really I think that's
really cool. I
I feel like I I feel like I've
seen a couple a couple of the I've
I've seen the aspiration of that a couple
of times.
And the issue is that people,
if if all you're doing is giving advice,
first of all, a lot of a lot
of really smart people wanna be building things,
and the smartest people don't go there. So
I think I think it should be like,
it just would have to be it would
have to be done carefully with with the
team has to provide deliverables of some sort
in addition to advice.
But I but I think that kind of
thing could be a really fun job to
do. I think it would, you know, and
and they could cross pollinate. Like, they you
know, by definition, they'd be moving between lots
of different teams. And so ideas, I think,
would get spread across the organization a lot
more a lot more effectively. And, like, some
of these
awful, awful architecture reviews that I've been in,
like, that I'm sure you all have been
in, like, oh, my heavens. We don't we
don't need this in PowerPoint. Let's just put
a human that that is walking around talking
to everybody. I don't know. Seems really cool.
Yeah.
Yep.
And I I yeah. And one way you
could do that, I suppose,
is you could make your architecture team a
super team
that draws from all the other teams
25%,
30% of their time
is doing architecture,
and the rest of their time is doing
whatever they normally do.
Right? Right. So so, yeah, you take your
two
best DNS people
on the design side, not on the troubleshooting
side, because obviously those aren't necessarily the same
thing. Mhmm. And you put them, you say,
okay, 30% of your time you're doing architecture
work. And what I mean when I say
architecture work is you are enabling
the applications
people
to do what they need to do
using DNS.
And and part of the problem is
people don't know what you can do with
a lot of the protocols and a lot
of the services
that are out there. So they go out
and they invent new things
Yeah.
Which great for you, you invented a new
thing except it looks just like the thing
that was already running someplace else in your
network
and
every other thing that's ever been invented in
the history of network engineering
and but it's a new thing.
I called it something different.
What what Russ was just talking about is
an example of why you would need a
generative culture. A bureaucratic culture could never tolerate
what you're talking about, 25%
of this and 75%
no way No way. And your bureaucracy would
lose its mind. And then, you know, the
power centric probably has absolutely no way to
comprehend that. But, yeah, the the culture would
allow you to do these kinds of things.
Right. Which is why yeah. Which is exactly
why I think a lot of this comes
back to that that that foundation of culture,
of having trust, of having cooperation, of having
psychological safety, which enables trust and cooperation, which
psychological safety is a really interesting topic, I
think, because
I find that a lot of people get
it wrong.
I think a lot of people think that
psychological safety means that everyone needs to be
nice to each other, and and I actually
think that's almost the opposite of what psychological
safety means. I mean, obviously,
you you you shouldn't be mean. Kindness is
definitely part of it, but I don't know
the niceness is part of it. Right? I
think to me, psychological safety,
I think I heard somebody say it's it's
permission for candor
is what it really means. Right? It's it's
it's the ability that you know that you
can say that the true thing no matter
who you're talking to, whether it's your boss,
your boss's boss, somebody from a different team.
I need to be able to tell you,
hey. This didn't work, and here's the result
I actually got. Or, hey. This was a
problem. Let's figure out what the real you
know, what what what what caused that.
It definitely is a move away from blame.
Right? It's not about blaming people, but it
is about talking about the things that aren't
working,
which isn't always nice.
You can do it kindly, but but Yeah.
Yeah. Well, I think another component of psychological
safety, and maybe we shouldn't do this here,
maybe we should do a different show. But
anyway,
another component of that is that people actually
trust each other enough to listen.
And we don't do very good at that.
I'm sorry.
I have been in situations
where I say, oh, no. You know, really,
you don't really wanna do it that way.
And they're like,
no, I do. And you're like, wait. Here's
a research paper
showing you that this or here's an example
of a protocol that did it that way,
and it failed, and this is how it
failed.
And they're just like, but you're not on
my team. I don't need to pay attention
to you.
Whatever it is, it's not the process,
blah, blah, blah, blah,
blah. And then they walk away without listening.
Mhmm. And then then you get to the
point where you're like,
why am I talking?
Why do I research? Why do I open
my mouth
if no one's ever gonna listen? And I
think there's components of that as well in
there.
There's this there's this great thing that's defined,
in Westrum's typology, and he talks about the
the responses across several different categories for pathological,
bureaucratic, and generative.
And my favorite is the one where it
talks about messengers.
And in a pathological
culture, messengers are shot.
In a bureaucratic
culture, messengers are neglected. And what you described,
Russ, was somewhere between the two. Either,
like, you know, like, why I don't even
need to listen to you go away, which
to me is more shot.
And
and and then neglected is like, yeah. Whatever.
You can say that, but I'm gonna go
do my own thing anyway.
In generative cultures, messengers are trained. In other
words, like the people who come with
feedback about the state of the system
are they're they're not just listened to. They're
empowered to do that better because we realize
that our messengers, our truth tellers,
yes, who do that respectfully
are actually the lifeblood of how we get
better.
And I think that that
component is so important.
Yeah. Bringing this back to net to NetOps
and and how we operate networks.
Here, we have
the people in the core
telling somebody who's building a campus,
honestly, you really shouldn't use that data center
fabric router
in your campus.
Right? It's not really designed for campus use.
And the data center people or the the
campus people going,
forget you. It's cheap.
I don't care. I'm gonna use what I
wanna use.
Not accepting or understanding
the wisdom
of the other teams who have built stuff
at scale
because they're different than you. I think that's
a big part of NetOps
that people seem to miss, to me anyway.
By the way, same thing with coders.
I've seen so many times when somebody's doing
DevOps,
and they're writing a piece of code to
do something very simple, get all the BGP
information out of a 100 routers, whatever it
is, fix fix some silly thing.
And the coder comes to them and says,
you go to a coder for help, a
full time coder for help, and you say,
well, how why isn't this working? They're like,
okay. Honestly, the data structure you're using
is not really the cool thing.
And the and the DevOps person goes, it's
already written. That's what I'm using. Now just
help me fix my problem. Right?
No. Not cool. Stop that.
Yeah. And there's a lot of individual quirks
that I think could contribute into it. So
I think culture kinda gets smashed on both
sides. Right? Like, the individual the leadership definitely
has a play part to play, but but
the individuals do as well. And I think,
you know, some of this is that,
I I guess you maybe call it ego
that that's tied into a lot of folks
who work in IT. I know I I
struggled with that definitely early in my career
for quite a while where I I felt
like I needed to know the answer
to such a degree that I was unwilling
to be wrong, which which which, you know,
doesn't allow learning.
Another side is, like, there's there's definitely, like,
the idea of, like, the folks that kinda
hoard control or hoard knowledge because they think
that's how they become valuable or irreplaceable is
that they don't talk to anybody and they
don't tell anybody what's going on. Yeah. So
you definitely yeah. There's definitely these, like, individual
quirks that that play into this.
It's not easy. It's not easy to have
a trusting culture. It's it sounds really, really
nice, and it is great.
But it's it's work. It's constant work.
And we we all want to be in
a trusting culture.
A lot of times we don't wanna build
one. Mhmm. Right? Because building one takes significant,
like, interpersonal risk, and it's challenging.
And
you've gotta be willing to stand up and
be the one that takes the hits. And
so,
yeah. Like, we all wanna be be in
a trusting culture. It's way harder for us
to be the ones who start or,
yeah, begin to try and exhibit that trust.
Go ahead. Yeah. And so if you're an
individual trying to develop that skill set
to be better at
NetOps and DevOps, just to throw this in
there, it's not really the topic, but
go present stuff,
write stuff,
and teach stuff.
Because people will tell you when you're wrong.
And not only does it improve your knowledge,
it also improves your humility.
Like, I I can write things now. I
can write a whole book, and somebody come
back and say I can have Edgar come
back and say,
you know, mark half of it with red
ink.
Okay?
I don't really care anymore.
Right?
My my ego left the room about book
number three.
Yeah.
Yeah. That is tough going through the editorial
process your first time or whether it's an
art I mean, a book is is is
huge, but even just an article, you gotta
run it through somebody else to, like, go
through and and mark it up. And you're
like, you can definitely take that very personally.
And that's a that's a big part of
this too just in general. Right? Like, just
take things less personally. I mean, we should
care about our work,
and so there's a balance here. Maybe everything's
a balancing act, I guess. But there's a
balance here between, you know, caring about your
work and then not taking it too personally
where you're actually getting, you know, depressed or
pissed when someone brings something points out a
mistake you made or or something along those
lines. Yeah. Exactly. This is this is where
network engineers have something to learn from software
developers. Like, it's just natural and part of,
like, code review is just is just life.
Like, and, like, having someone else look at
your work is what you would normally do.
And, you know, they're gonna and just because
they offer feedback doesn't mean you have to
take it and all that stuff that that
comes with it. Like, I think there's
I I have enjoyed quite a lot being
in mostly in software the last few years.
I've enjoyed quite a lot having someone else
look at it and point it point out
something, and, oh, oh, awesome. Like, I I
get to learn from this before it becomes
a disaster in production. Like
Yep. Definitely true. So, yeah, all trust culture
type stuff.
And as you said, generative culture type stuff.
Right?
Power cultures and pure bureaucratic cultures don't really
deal with these problems very well.
Okay.
I think I'm at the end of my
discussion on culture. I know Yvonne can go
for another two hours.
We could. But it's okay. Brytes are good.
Yeah.
Save some for the next show. That's right.
So, Chris, we gotta have you back on
sometime on a more regular basis. It's, you
know,
we just gotta find topics. That's all we
ever gotta do is find topics.
So Well, there's a whole another thing. So
Westrom is great. There's also this guy, doctor
Rob Cook, who has another framework, that's interesting.
There's a like you said, this this topic
can can dive a little deeper and there's
ancillary stuff as well. Okay. Cool. Also, more
technical topics too. Yeah. Somewhere. Yeah. That's cool.
Awesome. Alright. So, Chris, where do people find
you if they want to? Do you blog?
Or
Yeah. So chrisgundeman.com.
There's a blog there,
where where I keep updated pretty well. And
then, on I've been more and more active
on LinkedIn as well lately. So if you're
on LinkedIn, definitely feel free to follow me,
and I share things there as well. Cool.
And Yvonne?
Yeah. You can find me on LinkedIn or
on Twitter at Sharp Network.
Yeah. And also at the Cloud Gambit over
at PocketStation.
Gonna say, I know that you're doing another
podcast. Do not leave it out. I'm sorry.
Short changing our audience.
Oh, well,
no. Come see us over at the Cloud
Gambit.
And, Tom, say your word.
LinkedIn.
I think that tell tell the editor, by
the way, don't take out the pause because
I think that's part of my thing now.
Alright. Cool. Well, thank you very much for
listening this episode of The Hedge all the
way to the bitter end.
We know we live in an attention driven
economy,
and so we thank you for spending the
time with us and giving us your attention,
and we will catch you next
time.