►
Description
As many organizations attempt to adopt devops principles it becomes clear that executives are struggling to find a “home” for these new cross-functional teams that collaborate with others. Current ideas about organizational design have struggled with alignment and larger adoption of devops outside of the devops team concept. In this talk Kevin will explore and illuminate the challenges and pitfalls of several organizational adoption attempts and provide techniques and tips for how to design an enterprise approach to embracing devops and what lies beyond.
A
All
right
welcome
again
to
another
openshift
commons
briefing
today,
as
we
do
on
fridays,
we're
going
to
talk
about
transformation,
cultural
shifts,
all
kinds
of
interesting
things
with
the
that
we
do
with
the
folks
from
the
global
transformation
office.
Here
at
red
hat,
and
today
we
have
kevin
beer
back
again
and
he's
going
to
talk
about
anti-patterns
of
devops
in
particular,
he's
going
to
rant,
hopefully
on
devops
and
ownership,
and
I
guess
who
owns
devops
so
kevin.
Take
it
away.
A
B
So
these
are
my
buddies
and
color
cohorts
and
colleagues
in
the
gto
that
I've
been
working
with,
and
you
know,
andrew
and
and
john
and
james,
I
don't
think
they
really
need
any
introduction,
so
devops
teams.
This
is
a
thing
that
actually
really
bothers
me
not
for
the
same
reason.
I
think
that
it
bothers
a
lot
of
people.
B
B
We
actually
don't
organize
around
our
work.
In
many
cases
in
our
companies
we
organize
around
hr's
ideas
of
spans
layers,
titles
and
and
then
our
job
descriptions.
I
mean
how
many
of
us
in
technology
look
at
our
job
descriptions
and
we're
like
yeah.
I
guess
maybe
I
do
some
of
that,
but
it
doesn't
really
capture
what
I
do.
Our
titles
in
many
cases,
don't
capture
what
we
do
and
they
certainly
don't
belie
the
interactions
we
need
to
have
in
many
cases
with
people
outside
of
our
functional
groups.
B
So
the
notion
of
taylor
ideas.
It
comes
down
to
this
right.
Taylor
made
an
observation
he's
famous
for
making
this
observation
back
in
the
late
1800s,
early,
1900s
and
and
frederick
winslow
taylor
by
the
way,
and
basically
he
was
kind
of
the
father
of
and
man,
I'm
using
a
lot
of
air
quotes,
but
I'm
air,
quoting
scientific
management,
and
his
idea
was,
you
know
at
the
kind
of
at
the
beginning
of
the
industrial
revolution,
and
so
his
idea
was
based
on
this.
B
B
The
key
is
kind
of
and
worked
for
a
while,
but
it
became
the
basis
of
a
lot
of
management.
Thinking
that
a
lot
of
people
don't
even
understand
right.
So
I
want
to
kind
of
talk
a
little
bit
about
the
fact
that
we,
as
companies
are
experiencing
organizational
nightmares
as
we
push
all
of
the
boundaries
of
what
humans
can
handle.
You
know
how
many
people
we
can
know
how
many
people
we
can
trust
how
many
things
we
can
keep
in
our
head
in
terms
of
tasks
right.
B
These
things
push
us
to
the
edge
of
and
beyond
our
actual
human
capabilities
that
are
innate
in
us
as
as
humans,
and
so
the
these
kind
of
information,
physics,
trust.
All
these
things
are
broken
by
the
way
organizations
work
in
the
enterprise,
and
so
you
can
tell
that
the
focus
that
put
them
together
was
really
more
about
control,
more
about
keeping
the
enterprise
stable
and
more
about
kind
of
the
enterprise.
B
So
the
goodwill
is
for
the
whole
enterprise
right
versus
something
like,
maybe
a
famous
steakhouse
named
after
an
athlete.
The
good
will
that
you're
going
to
that
company
for
is
based
on
that
athlete
and
your
admiration
or
respect
or
some
sort
of
connection
to
the
food
that
they
might
have.
So
that's
the
opposite
of
enterprise
goodwill.
B
That's
individual
goodwill,
so
enterprises
are
built
for
enterprise
goodwill,
which,
if
you
kind
of
take
it
apart
in
a
weird
way
like
I
do
kind
of
means
that
the
actions
of
any
one
person
cannot
take
down
the
enterprise,
but
also
because
of
that
kind
of
hardening
and
the
structures
that
we've
put
in
place
in
the
divisions
that
we've
put
in
place.
I
mean
these
words
are
key
right.
B
So
why
is
it
that
we
see
enterprises
talking
about
digital
transformation
and
appointing
chief
digital
officers,
because
they're
not
digital?
Why
are
they
talking
about
agile
and
devops,
because
they're,
not
agile,
they're,
slow
executives,
use
these
words
to
mean
different
things
than
what
we
think
they
do?
We
kind
of
maybe
will
be
hinting
or
hinted
at
the
fact
that
they
don't
understand
the
full
dimension
of
what
that
means.
But,
to
be
honest,
I'm
not
sure
all
of
us
or
any
of
us
really
do,
there's
a
lot
of
constructs
involved
here.
B
But
my
point
is:
is
that
when
executives
say
we
want
to
be
agile,
we
want
to
deliver
faster
and
get
features
to
our
customers
so
that
they
can
approve
them
or
love
them
or
hate
them.
We
can
get
quick
feedback
in
essence,
if
you
flip
it
around
there's
a
negative
side
to
that.
That's
the
internal
messaging,
which
is
we're
not
fast.
We
don't
experiment
enough.
We
don't
know
what
our
customers
mean
at
some
level.
The
reason
we
have
to
transform
is
because
we
are
not
at
the
place.
B
We
need
to
be
in
the
market
to
compete
today
and
or
take
advantage
of
all
the
opportunities.
So
when
we
hear
leadership
talking
about
transformation-
and
we
talk
about
organizational
change,
we
have
to
understand
that
we
may
not
actually
understand
what
behaviors
we
need
to
change.
What
organizational
elements
will
actually
make
that
much
more
possible
and
likely
and
then
how
we
incentivize
all
of
these
units
to
work
together.
B
The
problem
with
that
is
it
treats
everybody
largely
the
same
in
the
organization.
Now
there's
a
lot
of
customizations
for
the
type
of
organization
you
are,
and
some
of
those
organizations
have
to
represent
revenue.
Certain
ways
and
there's
gap
to
deal
with.
But
my
point
is:
is
that
finance
is
at
the
heart
of
a
lot
of
the
reasons
in
the
enterprise?
B
This
is
largely
not
true
in
the
enterprise,
so
we
spend
a
lot
of
time
justifying
why
we
have
to
do
what
we
have
to
do
to
stay
stuck
and
my
point
about
hr,
not
helping
right
spans
layers,
these
ideas
in
general.
We
don't
organize
around
the
work.
We
organize
around
functional
units,
management
of
those
functional
units
and
then
compensation
reward
review
in
those
functional
units,
the
idea
being
they're
closest
to
the
work
and
the
worker
and
can
have
an
objective
or
more
objective
point
of
view
on
what
it
is
they're
doing.
B
Therefore
they
can
be
managed
and
centered.
You
know
corrected
whatever
needs
to
happen
best.
That
way
turns
out.
That's
not
true
anymore,
and
it
hasn't
been
true
for
quite
a
while,
and
yet
nobody
notices
and
the
one
of
the
places
where
you
can
really
see.
It's
true
is
when
we
outsource,
because
nobody
actually
knows
at
the
point
of
contact
what
needs
to
be
done.
B
So
we
want
them
to
have
some
sort
of
answer
and
we
want
them
to
have
some
sort
of
need
to
improve
if
it's
not
what
we
want.
But
accountability
is
one
thing
but
building
a
system
you
know,
which
is
all
of
these
components.
Working
together
in
one
direction,
is
really
really
important,
and
this
system
in
your
organization
needs
to
include
these
pieces
of
the
value
stream,
procurement,
finance
and
hr.
All
of
these
things
help
shape
the
organization.
B
And
I
mentioned
before
the
enterprise
construct,
which
is
just
that
notion
that
we
have
to
protect
the
organization
at
all
costs
and
and
because
that
is
what
allows
us
to
continue,
and
so
the
construct
of
kind
of
minimizing
the
ability
for
any
one
group
to
make
enough
change
to
actually
fundamentally
change.
The
company
has
to
change.
It
literally
is
in
the
way.
B
B
You
know,
unfortunately,
the
projects
that
have
come
out
of
a
lot
of
these
organizations
that
I've
seen
argue
the
kinds
of
projects
that
devops
do
right,
automation,
building,
tool,
chains,
building
capabilities
fundamentally-
and
I
I
think
that's
what
the
real
important
pieces
vendors
have
really
swayed
us
into.
Devops
is
a
team
building
out
continuous
delivery
tool
chains
and
some
automation,
and
that
literally,
couldn't
be
further
from
the
truth
of
the
spirit
of
devops.
B
You
know,
there's
a
lot
of
confusion
about
how
the
organizations
need
to
work
to
work
together,
but
at
the
end
of
the
day,
devops
is
not
a
methodology.
That's
very
important.
It's
certainly
not
a
software
development
methodology.
It's
certainly
not
an
operational
responsibility
that
gets
contained
inside
of
infrastructure
and
operations
and
kind
of
run
outwards.
B
Think
about
what
the
portmanteau
has
in
it.
Development
operations
it's
actually
in
the
order
of
its
value
stream.
In
terms
of
where
work
comes
from
and
moves
to
and
literally
was
invented
by
patrick
dubois.
One
of
the
kind
of
the
co-founders
of
the
movement,
along
with
andrew
clay,
schaefer
and
and
patrick,
was
looking
for
a
domain
name
for
the
first
devops
days
conference
and
he
wanted
to
have
a
developer
and
operations
conference
and
basically
that
was
the
domain
name
he
could
find,
which
was
dev
and
ops.
B
So
this
is
a
term
that's
made
to
encapsulate
a
set
of
ideas
about
working
together,
patrick's
inspiration
from
when
I
talked
to
him
about
this.
Is
you
know,
working
as
a
consultant
and
trying
to
help
as
a
developer,
push
fixes
to
operations
and
help
them
out
and
build
kind
of
bridge
that
gap,
and
he
it
wouldn't
happen.
It
couldn't
happen
in
the
organizations
that
he
was
in,
so
he
wanted
to
start
a
dialogue.
How
can
we
actually
improve
this
experience
and
understand
we're
in
this
together?
B
We
can
make
each
other
better
and
we
can
help
the
company
in
doing
that,
and
so
you
couple
that
with
andrew's
prefix,
you
know
his
kind
of
desire
to
have
agile
infrastructure
that
he
was
talking
about
at
velocity
and
those
two
really
formed
the
crux
of
a
new
movement:
to
bring
development
operations
together
in
a
way
that
we've
seen
in
high
velocity
companies
and
kind
of
what
we
call
greenfield
companies
and,
and
certainly
in
the
fangs
and
again
these
aren't
words.
You
hear
a
lot
in
these
places.
B
B
Remember
the
only
place
we
produce
value
is
by
having
things
in
in
operations
literally.
The
definition
of
business
operations
has
something
like
create
value,
right,
you're,
harvesting,
value
from
your
assets,
so
things
capabilities.
You
have
things
you
own
people
that
work
for
you.
These
notions
are
you're
using
production
operations
to
create
the
value
for
your
customers,
whoever
they
are,
whether
they
be
internal,
whether
to
be
external.
Ultimately,
so
really
really
important.
B
So
people
say
to
me:
well,
if
you
don't
like
the
idea
of
like
an
organizational
unit
set
up,
you
know
or
another
silo
for
devops,
if
you
will
first
of
all
why
and
then.
Secondly,
what
are
some
other
approaches
that
we
could
use
so
cios
and
cxos
in
general,
but
cios
and
ctos
specifically
have
not
really
like
been
able
to
answer
some
simple
questions.
It
seems
like
about
where
the
organizational
implications
of
devops
are
and
really
how
to
make
it
a
strategic
capability
without
embedding
and
making
a
team.
B
I
mean
that's,
really
really
important
and
our
individual
safety,
so
we
will
band
together
with
people
that
maybe
have
the
same
interests
or
the
same
concerns,
we're
literally
the
same
terror
right.
We
have
to
actually
figure
out
how
to
get
safe
and,
and
we
have
to
advance
each
other's
values
so
that
we
can
all
remain
in
a
company
or
remain
in
a
you
know
in
any
situation.
B
B
What
it
can
mean
is
that's
the
definition
of
devops
for
the
company,
and
all
you
have
to
do
is
look
at
the
work
that
group
is
doing
and
it
can
kind
of
be
scary.
So
if
you
have
tribes
in
your
company,
which
I
can
guarantee
you
do,
all
you
have
to
look
at,
is
look
at
a
bunch
of
cubes
and
see
all
of
the
different
universities
and
sports
teams
and
things
that
people
love.
B
Those
are
all
tribal
identifications
now
some
of
them
are
for
pleasure,
but
at
the
same
time
a
lot
of
them
are
just
things
they
went
through
to
get
their
careers
going
and
through
their
life.
So
we
see
lots
of
tribes
in
our
organization.
But
imagine
this
imagine
your
infrastructure
people
feel
like
in
order
to
keep
the
promises
that
they
have
to
keep
to
the
people
that
pay
them
and
the
people
that
determine
whether
they're
going
to
be
there
day
after
day.
B
In
order
to
keep
those
promises,
they
have
to
protect
themselves
from
people
that
cause
them
to
not
be
able
to
keep
their
promises
in
their
opinion,
and
some
of
this
can
actually
explain
the
pre-decision.
You
know
predisposition
of
operations
to
kind
of
have
the
hand
up
when
it
comes
to
developers
and
other
people
that
want
to
get
into
their
infrastructure
and
so
a
lot
of
times
even
development
teams.
If
you
have
a
devops,
you
know
group
in
your
company
or
or
you
have
some
sort
of
divisional
structure
or
some
sort
of
organizational
structure.
B
They
are
going
to
have
to
work
with
other
teams
and
interact
with
other
teams.
You
know
the
classic
thing
I
see,
all
of
them
doing
putting
in
continuous
delivery
pipelines
and
so
the
the
the
problem
with
that
is
manifold.
You
don't
know
if
that's
your
biggest
constraint,
you
don't
know
what
that
is,
but,
secondly,
the.
B
B
So
in
some
cases
that
could
be
the
delivery
processes
into
production.
But
I
can
tell
you
this:
if
production
isn't
ready
for
those
delivery
processes,
you're
not
going
to
be
able
to
keep
your
reliability
promises
in
some
cases.
So
we
all
have
self-fulfilling
prophecies
in
this.
In
this,
if
we
aren't
careful,
but
if
we
can
cross
the
boundary,
we
can
actually
make
those
self-fulfilling
promises
work
for
us.
So
a
little
bit
about
alternative
ways.
You
could
look
at
this.
B
B
B
It's
like
it's
orchestrated,
and
I
talk
about
management's
role
inside
of
these
organizations,
and
one
of
the
things
I
talk
a
lot
about
is
how
it's
more
akin
to
orchestration
than
it
is
to
child
rearing
right.
The
the
kind
of
etymology
of
management
goes
back
to
manger.
You
know
the
idea
that
we
have
to
raise
things
and
that
there
is
some
element
of
fomenting
and
support
and,
and
you
know
building,
but
this
is
not
a
you
know-
a
family
relationship
here.
B
What
we're
talking
about
is
that
the
the
management
of
the
team
really
isn't
the
goal.
It's
it's.
The
learning
of
the
team
that's
important
and
the
team's
ability
to
actually
work.
So
I
think
one
of
the
problems
that
we
have
is
that
management
doesn't
see
some
of
the
things.
We
need
them
to
see
right
now
and
we
may
not
necessarily
have
the
language
to
communicate
with
management
about
those
things
so
part
of
what
devops
really
can
be.
B
So
the
temporal
team
concept
is
is
really
powerful
and
I
think
that
that
idea
of
how
we
organize
can
be
a
place.
We
also
see
project,
oriented
work
and
even
program-oriented
work
where
folks
are
actually
participating,
like
with
almost
like
a
a
call
of
duty,
in
the
sense
that
you
have
a
time
that
you
serve
on
this
team
and
then
you
rotate
back,
and
I
think
a
lot
of
companies
understand
that
rotation,
oriented
team
work,
which
is
collaboration
across
multiple
functions,
not
a
functional
unit,
called
the
devops
team
right.
B
So
one
of
the
things
that's
really
important
to
understand.
These
multifunctional
teams
is
to
understand
that
devops.
If
you're,
looking
at
like
a
venn
diagram,
there's
a
lot
of
people
that
say,
dev
and
ops
need
to
be
the
same
circle.
They
just
have
to
come
together
and
be
literally
all
in
the
same
circle.
B
But
most
of
us
in
larger
organizations
need
to
have
some
sort
of
structure
around
what
we
do,
and
so
I
find
that,
having
leadership
that
rotates
and
having
team
members
that
do
rotations
and
keeping
the
whole
thing
dynamic,
keeps
it
becoming
owned
by
any
one
person.
Whoever
stays
there.
The
longest
right,
whoever
hangs
out
the
longest
contributes
more
ideas
in
theory,
and
so
we
want
this
to
come
from
everybody.
B
B
The
way
you
work
yourself
out
of
learned
helplessness
is
by
using
the
scientific
method
over
and
over
and
over
again
to
solve
problems
and
the
toyota
code,
or
the
improvement
kata,
actually
takes
a
subset
of
that
and
makes
it
a
super
high
cycle
rate
fast
way
to
do
it
every
day.
That's
light
but
makes
massive
change
over
time.
B
So
if
you
want
to
have
a
constraints,
busting
crew,
that's
constantly
rotating,
but
has
a
nice
mission
because
we
figured
out
organizationally
what
our
constraints
are
executives
right.
This
is
stuff
where
you
can
help,
but
the
the
the
idea
is
is
that
we
can
actually
bridge
these
problems
and
knock
out
a
lot
of
the
toil
knock
out
a
lot
of
the
stuff.
That's
preventing
us
from
working
better
together
right,
but
by
rotating
people
in
from
development
teams,
operations,
teams,
security
teams,
network
teams,
right
compliance
teams.
B
B
It
really
isn't
and
I'm
not
saying
that
we
couldn't
do
better,
organizing,
but
they're
there
and
you're
not
probably
going
to
change
them.
The
best
thing
to
do
is
figure
out
how
to
hack
them
and
cross-functional
alignment
allows
the
tops
of
all
of
those
silos
to
be
open
and
actually
allows
parts
of
the
insides,
so
that
people
can
actually
permeate
those
organizational
silos
regularly.
B
So
that
is
a
thing
I
would
suggest.
Use
continuous
improvement,
use
a
kata
and
start
to
assemble
cross-functional
teams
and
solve
these
problems
together
and
with
the
idea
that
we
have
not
a
single
bin
where
we
have
one
circle,
we
actually
have
two
circles
here
and
there
is
an
overlap
between
development
operations.
I
would
suggest
start
with
a
pareto
shape.
What
are
the
20
of
the
things
that
you
know
an
operator
could
learn
about
development
that
will
actually
make
operations
better
like
what
we
do
with
software.
Oh,
a
script
is
software
wow.
B
I
should
put
that
in
version
control.
This
is
really
interesting
and
likewise
developers
can
learn.
Oh
my
gosh,
that's
why
you
keep
having
to
talk
to
me
about
servers
and
the
primitives
like
storage
and
memory
and
cpu
right
these
things
when
we
start
to
have
an
understanding
together
of
what
it
is,
that's
holding
us
back.
We
can
work
on
them
together
if
we
have
a
systematic
way
of
doing
it.
You
know,
and
then
I
think
I
kind
of
mentioned
the
initiatives
or
the
big
projects
that
we
work
on
again.
B
It's
very
important
to
build
those
rotations.
This
argument
that
well,
they
know
the
most
they're
going
to
get
it
done.
The
fastest
actually
reveals
a
short
term.
Thinking
problem
that
we
have,
which
is,
is
that
we
aren't
envisioning
the
whole
task.
The
whole
work
does
not
involve
just
getting
it
out
the
door.
B
There's
somebody
who
has
to
deal
with
that
thing
and
support
it
day,
one
and
day,
whenever
all
the
way
to
the
end
of
its
life
cycle
and
based
on
legacy
things.
If
that
thing
works,
we're
not
going
to
get
rid
of
it
right,
so
we
need
to
be
able
to
build
organizational
resilience
and
more
response
options
in
the
organization
right.
B
In
many
cases
that
needs
to
be
made
at
the
layers
that
we're
at
or
maybe
one
above
us,
but
when
we
take
it
multiple
layers,
we
take
the
the
first
of
all.
You
know
the
cough
principle
of
the
higher
you
go
in
the
organization,
the
more
you
know
about
less
and
the
lower
you
go
an
organization
towards
the
work.
B
The
point
being
is
when
our
organizations
don't
function
correctly,
cross-functionally
we
escalate
too
much,
and
now
that
manager
is
in
the
value
stream
rather
than
the
teams
who
produce
the
goods
and
services
right.
So
the
the
key
piece
is,
decisions
need
to
get
made
in
the
right
place.
There
needs
to
be
enough
agency
for
the
teams
to
actually
make
decisions
about
work
that
they
know
far
more
about
than
anybody
else.
B
B
I
need
to
assemble
a
team
that
will
collaborate
and
is
diverse,
because
this
problem
is
complex,
diverse,
collaborating
teams
that
are
assembled
are
one
of
the
best
ways
to
deal
with
complexity,
and
one
thing
I
would
suggest
is
technical
folks
that
we
may
not
do
right
off.
The
bat
is
add
somebody
who
you
would
consider
naive
to
that
problem.
Solving
group,
in
other
words,
somebody
that
doesn't
have
the
technical
details
of
it,
and
one
of
the
reasons
is
you
need
this.
Everybody
that
gets
hyper
focused
on
bits
bites.
B
You
know
all
kinds
of
things
may
miss
one
of
the
most
powerful
questions
that
actually
could
unlock
a
lot,
and
so,
when
you
invite
a
person
who
is
not
necessarily
the
subject
matter,
expert
to
this
naive
is
not
by
the
way,
some
sort
of
way
to
talk
down
about
this
person.
This
means
they
have
a
different
point
of
view
and
they
may
not
be
subject
matter
experts,
but
what
the
value
they
can
provide
is
and
I'll
tell
you
one
meeting
that
I
was
in.
It
was
amazing.
B
B
So
the
other
thing
I'm
going
to
start
to
talk
about
here
at
the
end,
which
is
the
organizational
capability
that
devops
can
create,
is
kind
of
starting
to
see
things
beyond.
Even
the
development
and
operations
end
of
things
right
all
of
our
work
coming
from
somebody
else,
all
of
our
work
going
to
somebody
else.
What
does
that
value
stream?
Look
like
who's
one
step
above
us
or
before
us
in
the
value
stream
and
who,
who
are
the
people
that
are?
B
You
know
the
next
step
in
the
value
stream
from
us,
because
I
think
one
of
the
hard
things
about
technology
groups
is
of
the
many-to-one
relationships.
We
in
many
cases
get
work
from
multiple
people
and
we
deliver
work
to
multiples
of
people.
So
these
two
many-to-one
relationships
can
make
it
hard
to
see
the
patterns
and
flow,
so
one
of
the
key
things
that
you'll
see
in
devops
as
you
start
to
dissect
these
problems,
that
a
lot
of
us
have
shared
in
terms
of
the
organizational
dysfunctions
how
we're
pitted
against
each
other
basic
economic
models.
B
B
So
I
think,
what's
important
here
is
platforms,
as
interfaces
can
help
us
actually
start
to
digest
some
of
this
problem
too,
and
we've
had
this
conversation.
This
is
an
old
picture
right.
I
think
this
goes
back
to
andrew
and
damon's
presentations
early
on
in
the
days
of
devops,
about
this
wall
of
confusion,
throwing
things
over,
but
one
of
the
things
that
we've
actually
seen
is
this
organizations
can
solve
this
because
essentially,
development
is
economies
and
it's
economy
of
differentiation.
B
It
literally
is
building
new
things
and
actually
allowing
us
to
kind
of
seek
out
new
needs
meet.
Our
client
needs
through
a
lot
of
different
approaches,
and
then
this
drives
a
lot
of
technical
decisions
where
we
actually
have
to
differentiate
as
well
with
frameworks
and
all
kinds
of
things
right.
So
the
problem
with
that
is
is
that
operations
is
an
economy
of
scale,
which
literally
means
they're.
Measured
by
how
many
things
can
they
manage
with
how
many
people,
a
ratio
and
their
cost
curve,
is
almost
always
heading
down
by
a
percentage
every
year?
B
So
one
of
the
problems
they
have
and
one
of
the
basic
explanations
for
this
kind
of
crazy
divide,
is,
if
you're
coming
at
operations
with
a
ton
of
differentiation,
another
way
to
say
that
in
and
in
some
operational
language
be
a
bunch
of
snowflake
applications
that
are
all
completely
different
right.
If
you're
coming
at
them
with
a
ton
of
variety,
it
becomes
hard
for
them
to
scale
a
matter
of
fact,
the
negotiation
of
all
that
variety
into
production
becomes
very
tedious,
long
and
full
of
lead
time.
B
So
it's
a
problem.
When
you
have
one
organization,
that's
not
made
to
handle
variety
and
another
one
that
generates
pretty
much
endless
variety.
So
the
thing
that
you
know
jabe
came
up
with
that,
I
think,
is
really
brilliant-
is
to
create
economies
of
scope
between
the
two
of
these.
In
many
cases
they
could
be
a
platform
you
know
in
in
infrastructure.
B
We
understand
that
a
lot
of
our
resources
can
be
exhausted
or
completely
consumed
network
storage
people,
all
those
things
right
and
one
of
the
key
places
that
we
need
is
an
economy
of
scope
where
the
more
it's
used,
it's
not
exhaustible.
It
actually
provides
more
value,
the
more
functionality
and
cross-functional
functionality
that
you
build
into
a
common
platform
and
the
more
people
that
use
it
the
more
powerful
it
is
so
scope.
B
We
can
actually
build
all
of
the
kind
of
frameworks,
the
things
we
need
into
platforms
that
allow
the
developers
to
asynchronously
interact
with
the
platform,
develop
test,
add
capabilities
to
the
platform,
that's
great,
but
then
they're,
reused
right
and
then
we
see
that
the
operations
folks
know
how
to
run
platforms,
and
they
can
run
a
lot
of
uniform
platforms.
In
other
words,
each
one
is
less
work
to
them
and
less
variance
than
all
of
the
individual
applications
that
people
were
writing
before
they
could
attach
them
to
a
platform.
B
B
The
big
thing
that's
important
with
devops
is:
is
that
the
economies
of
scale
and
differentiation
all
do
a
lot
to
make
platforms
work,
so
they
are
recommending
the
things
they've
learned
and
the
benefits
and
capabilities
they've
made
into
a
platform
of
scope,
and
this
keeps
it
fresh.
This
allows
it
to
have
more
value
over
time
to
more
and
more
people.
B
So
I'm
going
to
kind
of
talk
about
that.
You
know
in
light
of
what
we
do
at
red
hat,
which
is
you
know
a
lot
of
what
jave
and
I
really
believed
when
we
did
practice
flow,
which
is
actually
praxis
is
the
term,
for
you
know,
practice
and
form
theory,
and-
and
so
I
think,
a
lot
of
people
get
frustrated
with
just
pure
theory.
B
That
is
what
practices
mean.
So
when
we
talk
about
behavior
change,
informed
by
theory
and
then
modified
by
more
practice,
it
becomes
really
really
synergistic
and
we
need
organizations
to
see
that
across
the
organization
system,
not
just
in
the
local
situation
or
our
organizational
unit
or
our
tribe
or
our
team.
B
So
I
think
it's
important
and
I
want
to
make
sure
and
attribute
jabe
bloom,
my
partner
here,
because
a
lot
of
this
work
comes
from
his
phd.
In
terms
of
the
three
economies
again
really
really
recommend
you
check
out
his
presentation
on
recommending,
I
think
it's
powerful
and
really
kind
of
embodies
the
spirit
of
a
lot
of
what
we
do
here
at
red
hat.
B
So
with
that,
I'm
going
to
say
thanks
and
if
you
want
to
continue
this
conversation,
I'd
love
to
do
it
on
twitter,
I'm
at
kevin
bear
all
one
word
b-e-h-r,
just
like
the
paint
and
love
to
you
know,
follow
back
and
and
engage
in
direct
messages
if
be,
but
this
is
a
fun
place
to
have
discussions.
Diane.
A
B
A
I
can
remember
that
happening
to
me
in
the
early
80s,
because
obviously
is
that
and
I
was
doing
process
manufacturing
software,
and
I
can
remember
how
hard
it
was
to
get
my
brain
around
the
folks
swap
swapping
management
and
they
were
actually
doing
it
in
the
early
days
and
I
and
I'm
old
as
dirt.
So
and
I
can
remember
as
an
someone
who
went
to
computer
science
in
you
know,
mythical
man,
month
period.
A
A
B
A
A
Was
really
really
cool
and
I
I
thought
that
was
an
interesting
thing
to
remind
people
about
and
the
other
thing
that
was
really
nice
today,
that
I
heard
the
differentiation
economy
versus
the
scope.
Economies,
metaphor
that
you
used
in
terms
of
and
and
I
think
for
developers-
that's.
This
is
where
the
one
that
clicks
in
is
like
the
modularity
of
code,
the
reusability
of
services
and
be
able
to
you
know
we
have
for
us
and
who
are
developers.
That
is
something
that
we
can
live
with
yeah.
A
A
Yeah,
so
hey
welcome
if
you
want
to
unmute
yourself
and
and
chime
in,
but
you
know,
there's
a
lot
of
things.
Yeah
dan
was
saying
you
really
like
the
changing
temporal
windows
illustration.
As
you
move
up
and
down
the
levels
of
the
organizations
and
how
window
references
affects
decision
making.
It's
yeah.
B
A
B
Total
quality
management
and
again
another
thing
that
management
ran
off
with
and
didn't
totally
understand,
and
the
organizations
that
did
didn't
need
to
adopt
it
like
they
already
had
it
in
their
dna
right,
and
so
everybody
trying
to
circum
like
you
know,
actually
impose
that
on
talking
on
top
of
an
organization,
it
was
just
like
wow,
it
was
hard
to
watch,
but
the
same
thing
in
you
know
in
groups
of
folks
within
devops.
This
isn't
an
organizational
structure
right.
A
A
The
tribal
mentality
and
anyone
who's
been
in
tech,
especially
women,
have
seen
those
tribes
and
people
get
defensive,
and
all
of
that
and
the
idea
of
the
volunteer
fire
crew.
As
you
get
a
notification,
you
just
show
up
you
get
on
the
truck
and
you
go
put
out
the
fire
and
that
whole
notion
of
crews
versus
tribes
and
assembling
people
from
across
domains
and
silos
to
to
to
do
that.
A
B
A
A
B
Yeah
we
do
cruise,
we
get
that
and-
and
I
and
I
love
seeing
that
you
know
as
we
as
we
interact
and-
and
I
think
that
having
some
of
that
in
our
dna
has
kind
of
allowed
us
to
stand
on
the
shoulders
of
those
giants
and
see
further
in
some
cases
and
and
yeah.
I
think
I
think
you're
right.
It's
like
it's
really
really
beautiful
in
motion,
because
what
happens?
B
A
A
B
A
And
I,
but
I
think
you
know
it's
times
like
these
we're
in
covid
the
world
is
changing.
Everyone
is
tense
a
little
bit,
I
think,
worried
about
their
jobs.
Probably
so
there
there's
a
tendency
to
put
you
know
more
like
more
of
those
silos
up,
and
I
think
the
thing
we
all
have
to
keep
coming
back
to
is
one
for
me
is
transparency.
A
I
think
transparency
in
processes
and
responses
to
things.
You
know
issues
and
stuff
like
that,
so
that
when
we
follow
up
after
an
outage
or
an
incident-
or
you
know
a
request
from
a
from
a
customer
that
we're
transparent
with
each
other
and
with
the
customer
or
with
you
know
whomever
we've
caused
the
issue
for
then
I
think
then
we
can
actually
collaborate
and
yeah
yeah
at
night,
and
that
was.
B
That
moment
where
this
is
where
leadership
can
step
in,
but
this
is
where
anybody
can
step
in
and
say,
listen
the
goal
here
is
we
have
a
common
problem.
We
have
a
common
goal.
We
may
even
have
a
common
enemy,
so
super
tribes.
This
is
what
we
have
to
have
right.
The
tribes
all
have
to
see
that
the
threat
to
them
is
greater
if
they
don't
form
a
super
tribe
and
address
the
external
threat
right.
If
we're
worried
about
our
jobs.
Well,
we
can.
B
We
can
actually
understand
a
little
bit
about
what
makes
our
companies
work
right,
and
so
I
think
that
in
many
cases
the
threat
to
our
organizations,
the
threat
to
our
our
livelihoods
is
so
much
more
important
than
my
squabble,
with
bob
in
ops
about
getting
my
change
through
right.
Like
seriously,
do
you
love,
paychecks,.