►
Description
OpenShift Commons Briefing
DevOps vs ITIL
Kevin Behr (Red Hat)
Hosted by Diane Mueller (Red Hat)
2020-05-22
A
All
right
everybody
and
welcome
to
yet
another
open
shift.
Commons
briefing
with
the
global
transformation
office
team
really
thrilled
to
have
Kevin
bear
here
today
and
we're
gonna
do
some
debunking
and
have
some
conversation
afterwards
and
see
if
we
can't
dispel
some
myths,
I
think
as
well.
So
Kevin's
gonna
talk
about
DevOps
versus
ITIL
and
hopefully
explain
to
those
of
you
who
don't
know
what
I
tell
is
a
little
bit
about
that
as
well
and
I'm
gonna.
A
Let
Kevin
take
it
away
for
probably
a
half
an
hour
or
so,
and
then
we'll
have
some
live
conversational
Q&A.
So
if
you
join
us
on
Twitch
or
on
blue
jeans
or
wherever
you
are
we'll
we'll
bring
you
into
the
conversation
or
we
will
just
ask
each
other
wonderful
questions.
So
Kevin
take
it
away
thanks,
Dianne.
B
My
name
is
Kevin
Baer
and
I'm,
the
co-author,
most
recently,
the
Phoenix
project
before
that
I
wrote
the
visible
ops
guide
book
with
Jean
Kim
and
Jordan
Stafford.
Before
that
I
wrote
the
definitive
guide
to
IT
management
and
the
adaptive
Enterprise
for
Hewlett
Packard.
Before
that
I
wrote
a
book
on
pikia
PKI
called
managing
certificate
life
cycles,
where
I
started
to
send
all
those
books
before
that
into
more
technical
topics,
but
I'm
a
just
a
little
bit
of
background
on
me.
I
am
a
serial
CIO
CTO,
but
don't
hate
me
for
that.
B
I
started
out
as
a
developer
quickly
got
kicked
out
of
development,
became
an
infrastructure
person
and
held
every
job
in
infrastructure.
Until
one
day
the
CTO
of
my
company
was
no
longer
present
and
I
was
standing
in
their
office
and
got
made
the
CTO.
So
literally,
my
career
has
been
a
continual
challenge
of
my
confidence
and
always
kind
of
pushing
me
to
a
place
where
I'm
not
comfortable.
B
B
Basically,
this
is
a
false
choice
and
I
want
to
talk
a
little
bit
about
why
it
is
so
first
thing
what
we're
going
to
do
is
this
is
my
buds
here
at
the
global
transformation
office
on
the
left
and
replace
Schaffer
the
surly
guy
next
to
him
is
me
and
John
Willis
is
to
my
right
and
J.
Bloom
is
to
John
Willis
right.
B
We
all
have
different
backgrounds,
Andrew
I
like
to
say
basically
invented
devops
with
Patrick
Dubois
I
like
to
say
that
John
Willis,
who
is
just
an
incredible
stage,
lots
and
lots
of
years,
35
years,
plus
I
believe
in
this
industry,
working
from
everything
from
basically
travel
around
every
DevOps
days.
They
have
basically
ever
happened
to
working
just
really
really
hard
in
the
software-defined
networking
space
and
just
doing
lots
of
really
really
cool
stuff
with
the
containers
and
technologies
and
devstack
ops.
B
Now
so,
I
had
the
kind
of
gush
on
John
because
he's
like
the
top
of
mind
right
now,
Jeb
is
amazing,
he's
finishing
his
PhD
at
Carnegie
Mellon
in
actual
design.
The
only
I
believe
University
in
the
world
to
offer
a
PhD
in
design
proper,
in
other
words,
not
design
of
a
thing.
But
what
is
designed
so
Jeb
among
us
is
what
I
would
call
kind
of
a
real
treasure
in
synthesizing
things
from
kind
of
parallel
worlds
and
bringing
them
into
technology
and
showing
us
how
they're
relevant
how
they
can
change
our
thinking.
B
So
to
that
end,
I
want
to
talk
about
where
we're
gonna
go
with
this.
This
talk
is
literally
not
to
describe
what
I
tell
is
to
you,
although
I
will
tell
a
little
bit
about
it
and
it's
not
to
advocate
it
to
you.
It's
about
an
intersection
of
interactions
that
can
be
problematic
in
our
organizations
and
I
want
to
also
suggest
that
in
digital
transformation,
which
most
of
us
in
infrastructure
and
development
should
get
a
little
twitch.
B
We
struggle
with
existing
processes
versus
novel
ideas
and
one
of
the
things
that
pre-exists
in
most
shared
services,
infrastructure
organizations
in
the
enterprise
is
a
pro
pan
approach,
called
IT,
Service
Management
and
a
specific
approach
to
that
called
I
toll.
So
we're
gonna
talk
a
little
bit
about
these
archetypes,
some
of
that's
mildly,
useful,
but
I
think
it
can
help.
You
understand.
B
Maybe
some
frames
we're
gonna
talk
a
little
bit
more
about
what
ITIL
in
ITSM
are
and
then
yes,
there
are
some
item
ISO
things
in
here,
so
there's
reasons
to
do
this
stuff
that
don't
actually
have
anything
to
do
with
whether
these
the
right
things
to
do
or
not,
which
is
a
very
interesting
problem,
and
there
are
actual
versions
of
idols.
So
when
you're
talking
to
people
about
it,
you
may
not
be
talking
about
the
same
thing
and
I
think
that's
really
important
to
understand.
B
But
when
you
do
understand
it--all,
you
can
actually
begin
to
understand
that
the
way
I
told
may
have
been
implemented
in
your
organization
has
nothing
to
do
with
what
is
in
the
guidance.
This
is
pretty
common
people.
Take
it
literally
when
it's
not
literally
I
mean
it's
guidance
right
and
then
basically
I
want
to
talk
about
some
of
the
places
where
you're
gonna
have
these
interaction
friction
points
in
your
daily
jobs
and
and
what
they
may
feel
like.
B
This
all
leads
to
a
future
series
that
I'm
gonna
do
I'm,
not
sure
how
we're
gonna
do
it
here,
but
you're
gonna
see
me
doing
it
everywhere,
which
is
expounding
on
this
in
a
lot
of
ways.
So
this
is
kind
of
a
first
talk
to
kind
of
that
I'm
gonna
put
out
in
the
community
to
start
to
just
talk
about
this
and
then,
as
I
move
on
I'm
gonna
start
to
move
into
more
how
we
actually
break
these
conflicts,
which
ones
are
the
false
conflicts
themselves.
B
The
assumptions
behind
them
I'll
break
these
down
Socratic
style,
eventually,
with
actual
evaporating
clouds
current
reality,
trees,
I'll
use
some
tools
from
build
rats.
Theory
of
Constraints
eventually,
so
today
is
just
to
kick
us
off
like
what
is
the
topic,
and
why
is
it
problem?
So
you
may
have
heard
some
of
this
friction
happening
in
your
organization
developers
constantly
saying
these
things
gosh.
Why
do
I
have
to
interface
with
a
ticketing
system?
I
just
want
something
from
another
human
right,
and
so
why
do
I
have
to
fill
out
this
form
that
has
choices
in
it?
B
Don't
make
any
sense
to
me
just
to
get
an
environment
right
and
a
lot
of
places.
People
still
talk
about
servers
if
we're
still
talking
about
servers,
I
think
we're
lost
right
and
and
and
this
is
a
sign
in
many
cases
when
developers
are
asking
for
servers-
that's
really
not
necessarily
what
they
really
want
to
be
asking
for.
B
In
many
cases,
we've
forced
developers
to
ask
for
raw
materials
to
make
things
that
they
need
to
do
experiments
right,
and
so
one
of
the
friction
points
we
get
is
developers
have
an
emergent
need
and
or
maybe
even
an
ephemeral
need.
I
just
need
to
try
this
thing
out:
tear
down
the
environment
blow
it
back
up.
I
just
want
to
see
what
happens.
B
I,
don't
need
to
put
this
in
production,
and
so
that
kind
of
a
ephemeral
need
runs
right
into
a
very
process-oriented
structured
approach
to
delivering
things
to
people,
services,
products,
all
those
kinds
of
things
and
what
happens
when
it
hits
that
process
is
sometimes.
If
you
have
a
ticketing
system,
those
particular
workflows
get
broken
down
into
individual
work
queues
they
get
sent
out.
So
you
put
in
a
request
for
a
environment
that
requests,
after
you
say,
small
medium
large
and
you
kind
of
do
all
that
sizing.
B
That
request
will
be
sent
to
possibly
two
or
three
different
teams
to
fulfill
parts
of
that
work
in
the
break
down.
What
happens
is
is
in
many
cases
you
will
hit
two
to
three
different
queues
of
work
that
are
not
aligned
across
each
other,
so
what
you
will
instead
maybe
get
is
the
equivalent
of
if
you've
ordered
a
car,
you
might
get
a
headlight
two
chairs
and
a
rim
and
you're
going
to
wait.
A
minute.
I
ordered
a
car
and
they're
like
yeah
yeah
yeah,
but
this
other
group
has
to
do
a
thing.
B
B
B
In
other
words,
this
is
one
thing
that
we
do
on
purpose
right.
We
don't
have
35
people
talking
to
a
developer
in
a
sprint,
it's
important
not
to
right
we're
talking
about
hey.
We
need
to
take
very
powerful
skills
and
put
some
focus
on
them.
Like
horses
have
they're,
not
blinders,
they're
focusers
right,
the
extraneous
information
makes
horses
very
nervous,
they're
not
developed
for
that,
so
we're
never
evolved
for
that
right,
our
modern
world.
So
we
need
to
focus,
and
we
do
this
with
Sprint's.
We
do
this
with
stories.
B
We
do
this
with
reducing
scope
of
development
right.
If
you
move
to
operations
typical
infrastructure
operations
in
an
organization,
it's
many-to-one
relationships,
every
operator
has
potentially
hundreds
of
requests
and
relationships
from
discreet
people
that
all
have
different
priorities,
but
everybody
thinks
their
thing
is
the
most
important
and
your
job
is
to
work
at
scale
and
scale
means
one
person
relating
to
many
many
many
pieces
of
infrastructure.
Thousands,
and
so
one
of
the
problems
with
scale
is,
is
if
everything
is
unique
scale
breaks
because
I
have
to
master
a
ton
of
different
things.
B
They
have
completely
different
mind
frames
about
what
is
necessary
to
achieve
what
they
have
to
do
and
how
they're
rewarded
by
the
way
infrastructure
people
aren't
rewarded
for
very
much
of
anything.
They're
yelled
at
when
outages
happen,
and
so
one
of
the
things
that
we
develop
is
a
risk
aversion
inside
of
infrastructure
and
one
of
the
things
that
I
think.
As
you
look
at
some
of
these
kind
of
patterns
here
in
conversation
and
what
you're
seeing
is
structured
versus
novel
thinking,
some
people
call
this
old
thinking
versus
new
thinking.
B
There's
a
level
of
care
that
doesn't
make
any
sense
like
when
you
understand
how
this
infrastructure
doesn't
care
about
you,
how
it
crashes,
how
many
things
are
involved
with
it
most
infrastructure
people
that
I
talk
with
when
there's
a
problem,
they're
more
worried
on
a
level
that
actually
has
care
in
it
and
I
find
this
really
unique.
So
a
lot
of
times
you'll
see
this
archetype
kind
of
battle
between
developers,
who
might
have
a
lot
of
passion
and
infrastructure
people
that
might
seem
like
Spock
from
Star
Trek.
But
that's
actually
not
true.
B
The
caring
and
the
infrastructure
side
manifests
itself
very
differently,
and,
and,
and
so
what
I
actually
think
is
is
that
both
groups,
when
they're
in
they're,
passionate
and
best
frame,
may
not
actually
be
able
to
have
the
kind
of
empathy
staying
in
their
frame
that
they
need
to
to
get
things
done
in
a
modern
world.
So
what
we're
looking
at
is
old
frames
of
thought
that
are
built
around
stability.
The
IT
infrastructure
library
was
really
made
to
actually
stabilize
the
approach
to
managing
of
the
structure,
provisioning
infrastructure
and
maintaining
it
and
in
the
British
government.
B
When
this
started
in
the
80s,
there
was
a
lot
of
different
results
coming
from
different
the
same
kinds
of
projects.
So
one
of
the
things
the
British
government
thought
to
do
was
hey.
Let's
get
all
of
our
sage,
people
all
the
people
that
have
been
working
in
this
space
for
a
while
and
let's
build
a
best-practice
library
of
what
we
know
works
so
that
we
can
share
that
not
reinvent
the
wheel,
all
the
time
and
get
more
stable,
reliable
and
predictable
results
from
our
IT
spending
and
our
IT
projects
and
operations.
B
So,
if
you
think
about
it,
the
goal
was
stabilization,
predictability
and
consistency.
This
is
not
something
you
ever
really
hear.
Devs
talk
about
right.
It's
novelty,
we're
gonna,
build
a
new
thing.
We're
gonna
fix
an
old
thing,
we're
gonna
bridge
things
that
work
together.
All
of
this
is
change
thinking,
but
if
you
go
into
operations,
changes
risk
because
they
know
all
outages
basically
are
the
unattended
consequences
of
things
we
meant
to
do,
and
and
and
so
they
have.
B
This
cause
effect
relationship
that
many
people
don't
and
the
more
that
development
organizations
are
traditionally
shielded
from
that
kind
of
on
call
an
incident
response
type
of
a
scenario
you
may
not
be
able
to
have
empathy
for
the
fact
that
your
release
basically
means
a
lot
of
people's
kids
and
operations.
Don't
get
to
see
their
parents
over
the
weekend
and
I
worked
at
one
particular
organization,
and
one
of
my
people
in
an
OSS
group
that
worked
for
me
many
years
ago
was
a
really
really
pretty
still
brilliant
guy
and
his
daughter.
B
He
had
a
brand-new
daughter
and-
and
she
literally
never
saw
her
dad,
because
every
release
started
at
6:00
a.m.
actually
6:00
p.m.
on
a
Friday
night
and
come
in
at
6:00
a.m.
on
a
Saturday
morning,
and
a
group
of
people
would
have
to
just
sweat
over
this
thing,
and
you
know
maybe
by
Monday
it
was
stable,
and
so
what
I
realized
was,
as
this
whole
process
was
putting
everybody
in
their
worst
position
right.
B
But
we
were
all
just
doing
what
we
thought
we
should
do
and
what
I
said
was
is
how
come
what
we're
doing
results
in
all
these
people
being
separated
from
their
families?
And
so
we
started
a
project
because
we
all
agreed
that
was
dumb.
But
we
all
thought
that
there
was
not
a
better
way
to
do
this
right
now.
B
But
we
agreed
to
start
a
project
and
we
named
it
after
the
kids
that
were
getting
left
behind,
because
that's
what's
important,
sustainable
releases
right
and
these
groups
came
together
and
started
to
work
across
these
processes
to
figure
out
how
to
do
it.
So
here's
one
of
the
kind
of
dispositions
that
can
heart
be
hard
for
that.
When
you're
in
Ops,
you
see
a
developer
running
up
to
you,
you
see
them
chasing
a
shiny
object.
A
B
If
you're
in
operations-
and
you
know
so
many
deaf
comes
up
to
you-
you
might
look
like
this
guy,
which
literally
says
it's
not
necessarily
the
personality
of
the
individuals.
Remember
it's
kind
of
the
archetype
of
the
organizations
and
the
ops
guy
is
like
listen
appreciate
that
you
saw
that
I'm
here,
but
I'm
already
doing
something
and
I'm
already
kind
of
like
I'm
kind
of
already
worn
down.
B
So
whenever
your
finds
out
about
a
new
release,
he
kind
of
sometimes
feels
like
he's
getting
jumped
on
by
Tigger
right
and
if
you
try
and
resist
the
release,
because
you
don't
think
something's
right
or
unstable
or
something
smells
wrong,
you're,
just
a
bad
guy.
It's
gonna
happen
right.
So
there's
this
kind
of
almost
pessimism
that
kind
of
develops
over
time
and
maybe
what
happens
as
we
give
in
and
so
change
becomes
the
one
pivot
point:
that
operations
can
control
the
that
when
you
go
to
do
it
change
you're
gonna
touch
my
backyard.
B
So
if
we
refresh
yourself
this
whole
notion
of
IT,
Service
Management,
remember
I,
said:
ITIL
is
like
a
de-facto
standard,
worldwide
approach
to
IT
Service
Management,
and
so
basically,
what
does
IT
Service
Management?
It's
really
basic.
It's
like
a
process
based
management
approach,
right
deriving
business
results
that
are
less
terrible
than
they
are
awesome
so
that
we
can
continue
to
function
as
an
organization
right.
It's
basically
the
management
approach.
Now
ITSM,
there's
a
lot
of
approaches
to
IDs
I'm
out
there.
B
I
can
tell
you
that
none
have
gained
a
lot
of
traction
in
comparison
and,
like
I
said
originally,
the
ITIL
was
published
by
the
British
government,
but
now
it's
actually
owned
by
a
third
party
called
axel
os--
and
their
marketing
and
developing
it.
So
you'll
see
much
more
aggressive,
maintaining
publishing
of
guidance
certification.
All
that
kind
of
stuff
now
I
will
tell
you
axel
owes
for
the
eye
to
eye.
They
do
provide
certifications
for
individuals
like
hey,
you
mastered
this
material
or
whatever.
B
B
You
know,
III,
don't
want
to
talk
bad
about
that,
because
I
think
a
lot
of
people
put
a
lot
of
effort
into
that
and
the
mastery
and
I
think
that's
a
great
thing,
but
they
don't
certify
bodies
and
that
kind
of
leads
me.
You
know
so
just
to
finish
this
up.
You
know
I'll
use
The,
Awl
Courvoisier
as
brandy,
but
not
all
brandy
is
Courvoisier.
You
know
all
ITIL
is
IT
Service
Management,
but
not
all
ITSM
is
I.
B
Don't
just
to
confuse
you
just
so
you
know
the
BS
15,000
courtesy
of
the
people
that
brought
us
the
inch
the
pound,
the
mile
and
the
cubit
I.
Believe
the
British
Standards
kind
of
BSI
codification
of
service
management
using
the
ITIL,
which
is
called
a
BS
15,000,
they
made
it
a
standard,
is
really
really
useful
and
I'll
show
you
when
we
look
at
these
pictures,
because
I'm
I
tend
to
use
the
BS
15,000
picture
of
ITIL.
B
So
this
is
really
a
way
if
your
organization
is
ISO
bent
and
I
said
this
in
the
back
and
in
the
in
the
original
part
of
the
president
of
beginning
part,
where
some
of
the
reasons
we
adopt
ITIL
don't
actually
have
anything
to
do
with
ITIL.
There
are
a
lot
of
organizations
that
are
really
really
hell-bent
on
ISO
certifying
every
and
so
they're
gonna
want
to
say
hey.
B
We
want
to
have
this
iso
20000,
sir,
to
show
that
our
IT
processes
Rock
as
much
as
our
manufacturing
or
our
back
in
business
processes
or
whatever
they're,
trying
to
win
a
bid
or
you
know,
differentiate
in
the
market.
So
the
20000
winds
up
getting
dumped
on
people
and
then
all
of
a
sudden
they're
like
we
have
to
have
an
approach
to
meet
this
and
ITIL
becomes
the
approach.
B
That's
pretty
much
default,
but
neither
the
best
vs,
15000
or
ISO
are
itÃll,
basically
their
certifications
for
organizations
to
show
that
they
are
doing
those
things
correctly
and
won't
talk
anymore
about
that
crap
all
right.
But
you
should
know
this
drives
a
lot.
Also,
there's
another
slide
that
I
don't
have
in
here,
because
it's
a
future
conversation
which
compliance
in
organizations
drive,
standard,
I
process
frameworks
and
one
of
the
reasons
is
there
are
standardized
audit
frameworks
for
IT
like
Kovach
control
objectives
for
IT,
and
so
you
know
they
are
actually
and
I'm
gonna.
B
Throw
this
crazy
word
out
there.
Itil
and
COBIT
are
orthogonal,
so
ITIL
actually
describes
the
processes
and
does
have
some
controls
in
it.
Change
management
by
the
way
is
a
preventive
control.
It's
one
of
the
best
kinds
of
controls
to
have
the
problem
is,
is
when
it's
run
wrong.
It
prevents
all
the
good
things
right,
I,
don't
think.
Let's
do
risky
things
so
kind
of
one
of
the
ways
we
have
to
start
to
think
about
the
relationship
between
audit
and
ITIL
is.
B
Is
that
when
you're
a
person
doing
DevOps-
and
you
might
be
working
in
a
collaborative
scenario,
you
might
be
like?
Oh
gosh,
you
know
that's.
What's
killing
us
is
doing
that
change
management
process,
filling
out
all
those
forms
having
all
those
people
get
involved
in
my
change
and
say
whether
it's
good
or
not,
that's
ridiculous!
B
Well,
it
may
be
ridiculous
and
you
would
probably
should
change,
but
the
audit
framework
that's
associated
with
it
in
your
organization
that
allows
you
to
demonstrate
compliance
and
prove
that
your
controls
are
actually
being
used
and
working,
that's
tied
to
that.
So
when
you
start
to
think
about
changing
processes,
you
have
to
start
thinking
about
a
bigger
picture
in
the
system
of
how
do
we
demonstrate
that
the
things
we
say
we
do?
We
actually
do
and
that,
wherever
there's
risk,
we
have
appropriate
level
of
preventive,
detective
and
corrective
controls.
B
B
There
are
regulations
associated
with
that
vertical,
but
we
may
not
be
aware
of
the
fact
that
our
tech
friends
in
the
IT
groups
or
in
the
operations
group
have
a
whole
host
of
things
that
they
have
to
comply
with
and
the
ability
to
demonstrate
that
they
can
reproduce
critical
systems
as
exactly
as
they
need
to
be.
So
you
know
never
mind
the
fact
that
there
are
a
key
part
of
certifying.
You
know,
socks,
the
underlying
capabilities
to
go
to
demonstrate
that
are
financial
reports
or
what
we
say
they
are.
B
So
this
kind
of
stuff
is
tied
to
these
processes.
So
when
you
throw
a
molotov
cocktail
at
change,
management,
I
get
it
I've
thrown
many
myself,
a
matter
of
fact:
I've
detonated,
a
change
management
programs.
Only
to
find
out
when
I
have
GRC
people
running
up
to
me,
going
we've
got
examiner's
from
the
FDIC
that
want
to
see
this,
and
you
just
blew
up
the
process
that
tells
us.
We
have
that.
B
Oh
right
so
like
whenever
you're
thinking
about
these
things,
there
is
a
system
around
them
and
well
I
think
we
need
to
improve
and
change
and
eliminate
a
lot
of
these
concepts
with
modern
attestation
done
by
machines,
those
kinds
of
things
we
we
have
to
get
there
through
a
process
that
allows
us
to
be
circumspect
and
understand
what
are
all
of
the
attachments
to
these
things.
It's
just
like
service
dependencies
and
software.
You
know,
we've
all
said:
oh
yeah,
you
can
turn
that
server
off.
B
How
do
we
actually
make
changes
to
get
rid
of
things
that
are
causing
completeness
and
accuracy
issues
or
a
causing
value
to
be
lost?
We're
even
worse?
Somebody's
name
isn't
a
value
stream.
That
is
a
credible
organizational
ability
like
we
need
to
have
a
system,
not
a
person
right
and,
and
so
I
think
the
the
larger
kind
of
thinking
around.
How
do
we
create
value?
Is
there
value
without
compliance?
You
know
what
is
the
end.
B
B
Fun
prairie,
complete
with
a
framework
for
process
controls
functions
as
well
as
behaviors
right
DevOps
is
a
novel,
socio-technical
prosper,
tional
alignment
capability,
that
organizations
have
and/or
don't
have,
and-
and
so
it
fits
into
something
like
this
and
DevOps
could
be
the
catalyst
for
improving
these
processes
cross-functionally
and
turning
them
into
something
that
doesn't
look
like
the
idle
anymore.
It
looks
like
what
your
company
needs
right
and
by
the
way
that
was
the
original
point
of
the
Iowa.
B
None
of
the
original
author
said
adopt
this
the
way
we
wrote
this
and
take
every
process
area
and
make
it
a
functional
person.
They
never
said
this,
and
so
what
a
lot
of
the
ways
people
have
adopted?
Idol
has
been
with
this
literalism
that
has
no
basis
in
the
way
it
was
presented
to
people
to
be
used.
B
So
I
want
you
to
understand
that
it
was
not
intended
to
become
Dogma
not,
but
it
has
because
humans,
so
I
think
what's
important
is,
is
that
we
figure
out
how
to
undergo
ties
it
because
we've
never
really
intended
to
be
that
way
when
it
gets
coupled
with
compliance
and
it
gets
coupled
with
expectations
and
reporting,
it's
really
hard
to
change.
So
we've
got
to
be
circumspect.
B
So,
like
I,
said
the
I
don't
de
facto
standard
for
service
management,
it
does
come
in
versions,
and
this
is
really
great
because
our
vers
our
tech
industry,
is
this.
You
know
completely
obsessed
with
version
dot
numbers
which
I
think
is
bizarre,
but
revision
control
being
what
it
is.
It's
nice
to
keep
track
of
things.
So
I
don't
ii
started
in
the
early.
90S
came
to
the
came
out.
B
It
was
actually
funny
the
first
real
kind
of
formal
idle
guidance
I
believe
there
were
some
books
in
the
80s
and
the
problem
with
the
books
is
they
were
very
incomplete
and
they're
very,
like
almost
just
like
a
snapshot
of
that
time
period.
The
way
we
referred
to
things
like
Mis
I
think
was
in
those
books
like
there.
You
know,
there's
there's
a
lot
of
old
terminology,
so
what
you'll
see
is
is,
as
these
revisions
come
out,
they
trail
what's
happening
because
it's
consensus
based.
B
So
I
think
we
know
need
to
be
bimodal
like
I.
Don't
love
that
concept,
I
call
it
bipolar!
Ite
I
really
believe
that,
at
the
end
of
the
day,
all
of
us
have
to
learn
to
modulate
what
we're
doing,
based
on
the
context
that
we're
in
so
big
big
big
problem,
because
that's
hard
for
us
to
do
so
idle
to
very,
very
simple,
very
much
process,
focused
I
think
it
had
like
I
can't
remember
how
many
processors
I
want
to
say
covered
like
ten
processes
and
like
maybe
one
function
or
two
functions
in
idle.
Three.
B
We
kind
of
went
again
process
based
approach,
more
processes,
more
functions,
idle
for
changed
completely,
which
is
kind
of
interesting
to
me,
idle
for
said
it's
more
about
practices
and
process,
but
it's
not
just
process
and
there
are
values
and
we
want
to
have
an
outcome
based
approach.
So
it's
much
more.
It
kind
of
incorporating
more
modern
language
about
digital
things.
It's
incorporating
much
more
modern
language
about
value
chains
and
value.
Its
brings
mention
of
lean
and
DevOps
matter
of
fact,
there's
even
they
modified
their
product
project
management.
B
The
the
British
government
had
a
project
management
standard
now
that
actually
stones
called
prince2.
It's
basically
the
British
version
of
like
PMP.
Our
project
management
certification-
that's
been
pretty
pretty
common
here
and
prints
to
actually
made
an
adjustment
for
agile,
which
I
thought
was
very
interesting.
I,
don't
complete
to
be
honest
with
you,
I
don't
completely
understand,
but
I
think
it
might
be
genius
or
it
might
be
crazy.
I
can't
actually
figure
it
out
and
I
it's
not
because
it's
a
bad
idea.
It's
just
I
need
to
do
more
work
on
that.
B
But
the
point
is:
is
that
the
approach
changes
over
time,
but
it
always
trails
and
I
think
that's
very
different
for
developers
to
understand
maturity
comes
later
now.
Maturity
also
can
lead
to
stubbornness
right.
So
this
is
where
these
things
can.
You
know
I
I
kind
of
have
a
joke
about
how
a
lot
of
times
we're
wandering
through
the
wilderness
and
somebody
finds
something
that
works
to
get
you
to
the
other
side.
And
so
what
happens?
B
Is
enough
people
take
that
path,
and
somebody
finally
decides
to
build
a
memorial
to
the
fact
that
this
is
the
way
so
they
build
a
memorial.
Everybody
gets
disillusioned,
knocks
the
memorial
over
and
their
subsequent
generations
just
trip
over
it
and
I
think
they
don't
even
know
what
it
means
that
it's
just
in
the
road
and
I
actually
feel
like.
That's
the
state
we're
out
right
now
with
DevOps
and
I.
B
Don't
a
lot
of
us
don't
even
know
why
we
did
it
to
begin
with,
when
we
try
to
undo
some
of
these
processes
or
start
to
make
them
lighter
and
faster.
We
run
into
compliance
problems,
organizational
problems,
reporting
problems,
hey
don't
move
that
thing,
because
it's
mine
and
I
invented
it.
So
there's
a
lot
of
hooks
into
this
stuff,
but,
as
we
even
see,
there's
a
progression
with
the
versions
of
idle,
and
so
what
I
would
suggest
to
you
is
is
there's
a
notion
that
some
change
can
happen.
B
It's
about
how
we
interact
with
each
other
to
make
it
happen.
So
I
want
folks
to
stop
taking
guidance
like
this
from
the
outside.
With
like
idle
and
saying
this
is
exactly
what
we
will
do.
I
would
love
people
to
say,
hey
the
idle
was
invented
by
these
folks
in
the
government
and
they
had
this
problem
and
they
had
these
constraints.
We
have
these
problems
too,
but
we
have
different
constraints.
So
maybe
what
we
need
to
do
is
not
do
some
of
this.
Do
some
of
that
and
adjust
it.
B
So
we
can
deal
with
our
own
constraints.
You
just
made
a
recipe
for
your
right,
so
if
you
ate
every
recipe
that
was
out
there,
I'm
guessing
you
wouldn't
be
in
a
good
place.
But
if
you
made
recipes
that
sounded
good
to
you
and
actually
then
said,
I
can
adjust
these
to
my
diet
and
my
particular
needs.
B
What
are
the
universal
principles
that
we
identify
with
as
an
organization?
Now?
How
do
we
take
our
those
principles
and
adapt
into
our
constraints
so
that
we
now
have
approach
internally
that
can
work?
This
is
what
Toyota
did
there's
an
article
that
Eliyahu
Goldratt
wrote
many
years
ago
about
this
concept.
That's
called
standing
on
the
shoulders
of
giants
and
I
will
definitely
make
a
point
of
figuring
out
how
to
get
that
link.
But
it
is
a
great
article.
B
You
can,
google
it
just
type
standing
on
the
shoulder
of
giants,
space
Li
le,
which
is
e
Li
Goldratt,
you
know,
and
and
that
article
is
essentially
about
how
you
can
appropriate
practices
in
your
organization
in
oddly
enough
also,
it
was
very
controversial
in
one
sense,
it
shows
why
lean
adoption
fails
at
some
companies
because
of
constraints
and
how
Toyota
actually
built
a
version
of
the
Ford
Production
system.
That's
what
they
wanted
to
build,
but
they
had
no
space.
B
No
money,
we're
bankrupt
could
only
make
a
car
if
they
had
an
order
and
only
could
buy
enough
inventory
for
one
car.
Where
do
you
think
one
buy?
One
flow
came
at
the
lowest
cost.
They
turned
that
constraint
into
an
advantage
that
allowed
them
to
produce
one
product
that
was
completely
different
than
another
product
on
the
same
line
at
the
lowest
cost
and
in
Japan
you
don't
have
huge
inventories
of
car.
You
order
your
car
the
exactly
the
way
you
want
it
and
you
get
it
in
about
a
week.
B
A
B
Get
and
at
Toyota
one
of
the
most
important
things
to
remember
at
the
beginning
of
when
they
started
to
really
take
their
improvement,
bent
their
philosophy
changed
and
their
phrase
even
changed.
They
have
this
great
phrase:
better
cars
for
more
people.
It
put
improvement
before
the
work
in
it--all,
there's
a
continuous
provement
in
notion
in
ITIL,
three
that
gets
added
and
in
it--all
four.
The
problem
is:
is
it's
not
the
central
engine
of
everything
they
do
in
the
Toyota
Production
system?
You
improve
your
work
before
you
do
it.
B
You
have
a
systematic
approach
every
day
where
your
interaction
with
middle
management
and
your
managers
are
about
your
ability
to
improve
things
towards
a
target
that
everybody
shares.
Not
what
to
do.
How
you
think
about
what
you
do
is
the
coaching.
They
don't
solve
your
problems
for
you.
This
builds
this
daily
approach,
their
cada,
their
improvement.
B
Kata
builds
scientific
thinking
in
the
edge
at
manufacturing
to
the
point
where
some
Toyota
factories
can
do
hundreds,
if
not
thousands,
of
reorganizations
themselves
without
HR,
that's
powerful,
that's
really
powerful
and
it's
not
because
they're
God
there
are
messy
and
low-performing
Toyota
factories
just
like
every
other
company.
But
this
is
a
really
neat
example
of
how
reconstructing
and
thinking
system-wide
and
understanding
that
the
most
important
capability
is
to
incremental
e,
improve
I
I.
Think
is
pretty
amazing.
B
So
when
we
look
at
I
told
me
say,
ok
I
know
has
all
these
process
areas,
but
if
we
had
DevOps
style
efforts
going
to
continuously
improve
these
process
areas
and
align
them
with
our
new,
more
important
modern
needs.
So
we're
collaborating
on
this
or
is
fighting
it's
a
big
deal.
I
know
a
lot
of
people,
don't
have
energy
to
get
in
and
fix
everything,
but
a
lot
of
us
love
doing
that
kind
of
stuff.
So
I
think
one
of
the
things
that
can
be
really
healthy
is
is
if
this
is
stuff.
B
That's
in
your
environment,
then
you're
facing
clashes,
maybe
step
back
and
think
about
your
entrenched
position,
and
if
it's
working
for
anybody
are
we
making
effective
change
right?
Are
we
trying
to
use
politics
to
change
social
things
versus
empathy
and
interpersonal
relationships?
I
think
that
that's
one
thing
that
we
can
start
to
think
about
so
again:
here's
some
pictures
of
the
idol.
So
this
is
3
different
versions.
B
Here,
I
mentioned
that
there's
version
2,
that's
the
top
one,
and
it's
pretty
low-tech
I
mean
you
can
actually
make
a
version
of
this
in
Emacs
the
you
know
text
right,
but
sorry
about
my
fidgeting
and
if
you
actually
look,
it's
really
simple.
This
is
everything
that
you
know
you
need
to
deal
with
it:
a
large-scale
level
like
a
high
level
right
in
an
IT
organization.
You've
got
kind
of
the
delivery
things
like
capacity
management,
service
reporting
and
all
that
stuff.
The
Rana
Center
control
processes
and
I.
B
Think
if
I'm,
a
Dem
I
look
at
this
I'm
like
control,
is
right,
right
and
and
because
we
get
to
control
the
change
and
the
way
configurations
happen.
But
if
you
think
about
this,
that's
the
hot
spot,
because
that's
where
a
lot
of
people
infrastructure
realize
this
is
where
bad
things
start
like.
If
I
let
a
bad
thing
in
through
this.
Now
it's
an
outage.
Now,
it's
my
problem.
B
Now
it's
my
weekend
now,
it's
you
know,
potentially
an
executive
escalation
with
my
name
it
on
a
column
right,
it's
a
bridge
that
nobody
wants
right
so,
but
what
we
found
to
you
and
Kim
and
I,
actually,
back
in
a
day
when
we
wrote
with
Georgia
Power
group,
visible
ops,
we
found
we've
got
to
some
permission
from
our
CEOs
to
put
on
pith
hats
and
go
study,
our
best-performing
customers,
which
was
awesome,
and
so
we
went
out
and
we
found
out
they
all
had
these
three
things
in
common.
It
was
unbelievable.
B
They
all
called
things
different
stuff.
First
of
all,
the
reason
why
we
have
an
eye
tell
one
of
the
best
reasons:
standardized
names
for
processes
right
because
then
in
operations
you
can
say:
if
we
do
this
work
and
we
do
these
processes,
we
these
kinds
of
people
and
these
skills.
So
then
you
could
standardized
position
names
and
actually
have
the
ability
to
hire
in
a
fair
way
and
helpful
way,
so
that
was
kind
of
one
of
the
ideas
right.
B
So
now
you
see
how
deeply
entrenched
this
can
get
into
an
organizational
model
into
people's
positions,
careers
and
trajectories.
So
when
you
come
and
say,
I
want
to
get
rid
of
this.
You
threaten
a
lot
of
people's
existences,
so
we
might
use
a
more
tactful
way
to
do
this
right.
But
this
is
a
really
great
thing
for
you
to
think
about.
If
you're
a
developer,
what
the
hell
does
IT
do
all
this
env2.
Now
we
call
the
different
things:
there's
more
things
that
we've
added
there's
a
lot
of
compliance
related
stuff:
that's
not
there!
B
So
that's
a
v2
picture
that
started
on
the
90s,
then
Olson
v3
somebody
got
really
really
awesome
capabilities
with
Excel
or
some
sort
of
PowerPoint
or
something
and
we
made
this
wheel
and
because
we
hate
the
idea
of
linear
processes
and
we
wanted
to
show
I
tell
as
a
life
cycle
and
I
think
I
think
actually
there's
some
valid
things
that
are
in
here.
If
you
look
at
this
wheel,
that
the
notion
is,
is
that
kind
of
everything
starts
with
a
service
strategy
in
the
center
of
this?
B
So
we
have
a
grand
design
about
what
we're
trying
to
do,
what
services
and
things
we
need
to
offer
to
help
meet
our
company's
strategy
and
that's
projects,
so
those
things
would
then
go
above
it
into
the
service
design
thing
and
then
would
flow
right
into
after
design
being
implemented
at
some
level.
Now
I
kind
of
call
this
little
wheel,
that's
in
here
I
called
it
out
it.
It's
an
old
school
concept,
called
plan
build,
run
and,
and
it's
not
very,
very
agile
or
modern.
B
This
is
like
the
waterfall
approach
to
delivery
infrastructure
and
so
I
take
flak
for
saying
that,
but
I
think
this
is
still
very
useful.
Again,
we
understand
in
transition,
things
are
moving
into
production.
We
have
more
control
around
them
when
things
are
novel
up
towards
the
top.
You
know
in
in
the
design
phase
and
in
the
strategy
phase
there's
less
constraints,
but
as
it
moves
through
this
process,
it
gets
more
and
more
lockdown
when
it
gets
into
service
operation.
That
thing
is
pretty
close
to
static
so
from
a
from
an
infrastructure
standpoint.
B
So
again,
an
interesting
picture
here,
but
and
showing
motion,
but
again,
look
at
this
continual
process.
Improvement
ring
on
the
outside
I,
don't
even
know
what
that
means.
This
whole
thing
kind
of
looks
like
a
manhole
to
me
and
I
feel
like
at
the
end
of
the
day.
This
is
just
the
edge
of
the
lid.
It
doesn't
have
any
motion,
it
doesn't
show
any
integration
I
think
that's
supposed
to
mean
that
all
this
stuff
is
getting
improved,
but
I
like
the
idea
that
it's
at
the
center
and
what
actually
feeds
strategy
feeds
process
improvement.
B
B
You
can't
show
all
of
idle
for
on
a
freaking
single
page
now
and
it
bothers
me,
they
have
these
weird
amorphous
arrow
drawings
that
just
have
ideas
and
concepts.
I
think
we
need
more
than
that
kind
of
stuff
to
really
have
these
conversations.
But
what
I
will
tell
you
about
idle,
for
it
is
kind
of
the
idle
du
jour
and
and
basically
it's
got
to
focus
more
on
practices
than
just
processes,
because
I
think
the
authors
realized
that
people
needed
to
know
what
the
things
needed
to
be
done.
B
Look
like
also
the
values
that
drive
those
and
the
outcomes
that
they
can
provide,
so
I
think
they're
trying
to
get
people
to
think
much
more
like
they
were
in
version
3
about
a
lifecycle,
but
now
I
think
for
the
first
time,
idol
4
goes
outside
of
IT
operations
and
gets
into
a
lot
of
other
things.
It
has
interfaces
with
software
development.
It
has
digital
kind
of
notions
in
it.
It
even
has
DevOps
notions
in
it
and
so
but
again
imagined
from
this
frame.
The
stability
frame
right.
B
So
we
need
to
understand
that
these
frames
are
important.
Civility
frame
is
not
a
bad
frame.
The
other
day
you
actually
benefit
from
this
frame
as
as
well
as
have
problems.
It
does
keep
you
out
of
a
lot
of
conference,
bridges,
hopefully
and
escalations
right,
but
maybe
you
need
to
be
part
of
those
two
to
get
some
of
that
pain
because
it
man,
I'll,
tell
you
there
I've
sat
on
a
lot
of
conference,
calls
I,
don't
talk
on
them
as
an
executive,
because
I
think
that's
just
terrible.
B
But
unless
people
ask
me
to
but
I
do
think
that
it's
important
to
understand
the
morale
of
your
team
and
I
think
it's
really
important
to
understand
the
interactions
and
what
they
sound
like
and
feel
like,
not
specifically
to
call
people
out
all
the
time,
although
sometimes
it
does
help
to
take
people
aside
and
talk
to
them.
But
what
I
find
is
is
that
it's
important
to
just
know,
because
the
words
you
say
as
a
leader
as
a
manager
as
a
director
in
either
and
I,
don't
like
either
Wars.
B
But
what
I
say
is
is
that
they
can
cause
folks
to
feel
boxed
and
they
can
produce
behavior.
That
is
not
the
kind
of
behavior
you
want
versus
kind
of
more
optionality,
thinking
and
including
people
in
the
intent
of
what's
happening
and
starting
to
try
and
build
a
bigger
frame
that
more
than
one
person
can
see,
I
call
it
expanding
the
movie
screen
right.
We
all
have
a
phone
screen
and
we
can
turn
it
in
16
by
9,
but
there's
no
comparison
of
that
than
a
letterbox
on
a
movie
screen.
B
We
can
all
see
a
lot
better
right
there
and
we
can
have
a
shared
frame
weight.
One
of
the
big
reasons
why
directors
love
that
long
format
that
crazy
letterbox
format?
That's
what
they
see
when
they
film
that's
what
they
want
you
to
see
how
they're
choosing
their
shots,
how
they're
choosing
all
of
it
where
it
starts
and
ends,
and
so,
when
you
get
that
wider
frame
you're
now
seeing
like
a
filmmaker
so
frame
adoption
the
ideal,
can
you
see
what's
in
the
frame
of
somebody
else,
a
little
bit?
B
B
Think
that
that's
really
important
and
these
areas
where
we
need
each
other
to
interact
to
make
value,
have
to
become
focused
on
differently,
not
as
why
we
can't
get
it
done,
but
what
we're
going
to
change
to
get
it
done
together,
so
I
talked
about.
The
friction
around
patching
is
one
of
the
areas
where,
again
it's
change
developers
don't
want
to
deal
with
the
fact
that
in
many
cases,
things
have
to
be
patched
and
where
you
patch
them
is
one
thing:
I
mean
a
lot
of
operations.
B
Folks
are
still
doing
what
I
call
this
old
house,
which
is
basically
taking
servers
and
upgrading
them
in
production,
patching
them
in
production
and
basically
caring
for
them.
That's
a
lot
of
work.
The
more
modern
organizations
are
basically
building.
You
know
kind
of
what
I
call
like
a
emerge
approach
to
building
infrastructure
in
the
sense
that
we're
building
an
in
source
control,
we're
building
the
images
we're
building
and
combining
all
the
artifacts
together
to
build
a
server
on
the
fly,
and
we
don't
necessarily
and
all
of
the
stacks
above
it.
B
We
don't
necessarily
actually
now
have
to
focus
on
modifying
things
that
are
in
production,
because
I
always
say
I'd
rather
patch,
15
or
20
different
builds
that
we
have
in
source
control.
Then
I
would
patching
thousands
of
servers
that
are
all
going
to
react
differently
to
the
same
software
I
would
rather
mint
them
from
scratch
right
and
one
of
the
reasons
why
we
do
this
in
many
cases,
and
it's
not
the
solution
for
everything,
is
you
solve
two
different
things
at
once?
B
We
can
architect
a
way
of
doing
this,
that
frees
up
massive
capacity
in
operations
and
it
also
allows
developers
a
lot
more
flexibility,
I,
just
I,
love
stuff
like
that
right,
because
we
get
to
win
right
and
we
get
to
also
slide
past
a
lot
of
really
really
silly
assumptions
and
you
can
say
they're
silly
in
retrospect,
after
you've
been
through
them,
they're
really
hard
when
you're
looking
at
them
right
the
consequences.
So
we've
seen
the
friction
in
change
management.
We
see
the
friction
in
the
way
tickets
happen.
B
We
see
friction
and
the
fact
that
you
know
when
people
need
I've
heard
this
classic
tired
line.
You
know
our
devs
don't
respond
the
incident
callouts.
Well
again,
it's
the
frame,
it's
a
totally
different
frame,
and
we
need
to
make
sure
that
we
both
have
context
for
each
other's
frames
here
and
share
a
frame
together
about
how
we
resolve
things
together
and
you
know,
I
can
I
can
tell
you.
B
I've,
sat
on
release
conference
bridges
a
lot
and
and
I
can
tell
you
that
one
of
the
things
that
drives
operations,
folks
nuts,
is
and
builds
a
lack
of
confidence
across.
That
relationship
is
the
amount
of
config
files
that
just
get
bashed
in
releases
and
ironic,
as
it
may
seem.
Most
ops
departments
that
I've
been
in
have
not
been
really
crazy
about
source
control
and
a
lot
of
software
is
written
in
operations.
B
Some
people
call
them
scripts,
but
they
are
not
in
source
control,
and
so
it's
very
common
in
operations
to
have
config
file
problems
and
batch
files
that
don't
run
and
scripts
that
don't
work
correctly
and
break
that's
normal.
But
nobody
outside
of
that
group
sees
that
right,
but
when
developers
bring
a
thing
and
their
config
file
doesn't
work
right,
it's
because
the
operator
doesn't
understand
it
in
many
cases
and
it
becomes
alike.
Why?
Don't
your
config
files
ever
work?
B
Why
are
you
shipping
these
things
that
are
run
ready
and
then
all
of
a
sudden
we
get
this
big
conversation
about?
We
need
to
build
a
path
to
production.
You
guys
need
to
satisfy
all
these
requirements
before
we'll,
let
it
in
and
what
we
basically
Institute
is
a
troll
in
front
of
a
bridge
that
asks
you
what
your
favorite
color
is
right
and
so
from
a
developer
standpoint.
B
This
is
not
satisfactory,
so
you
get
these
friction
points
where
we're
trying
to
do
things
and
the
processes
just
they
don't
fit,
and
so
the
thing
that
a
lot
of
people
don't
realize
is
that
if
you
look
at
these
processes
that
don't
work
where
all
the
wars
are,
there's
a
there's,
a
ton
of
deer
paths
out
around
the
processes,
one
of
things
I
I
often
say
to
people-
is
why
don't
you
look
at
the
deer
paths
and
move
the
processes
to
those?
That's
where
people
are
we
used
to
build?
B
You
know
roads
on
cow
paths
and
your
paths
I.
Can
we
learned
how
to
follow
things
right?
That's
why
there's
nothing
straight
in
Pennsylvania,
but
I
think
that
the
the
the
idea
of
how
we
are
actually
getting
things
done
and
looking
at
the
way
they're
supposed
to
get
done,
tells
us
a
lot
about
how
they're
supposed
to
get
done
is
working
and,
and
so
I
mean
I,
hear
the
conversation.
It
is
one
of
the
most
old
and
tired
things.
B
Inside
the
devs
mind,
he's
thinking
something
that's
probably
pretty
similar.
It's
just.
He
hasn't
articulated
processes
with
drawings,
and
you
know
all
kinds
of
crazy.
You
know
meetings
and
sticky
notes
and
done
all
this
stuff.
Basically,
in
their
mind,
they
think
about
an
outcome.
They
should
get
really
quickly
and,
and
so
I
think
that
we
have
to
step
back
from
defending
what
exists,
because
neither
of
none
of
those
things
will
get
us
where
we
want
to
go
and
we've
seen.
That
so
friction
is
a
clue.
It's
a
symptom.
B
It's
most
awfully
not
the
problem
with
the
process,
though.
If
we
stop
here
and
we
decide
that
we
need
a
better
patching
solution
or
we
need
a
better
ticketing
solution
or
we
need
a
better
call
out
solution.
We're
gonna,
buy
pager
duty
for
DES
or
whatever.
It
is
maybe
step
it
back
and
go.
Why
do
we
have
to
do
that?
Right?
I'm,
not
gonna.
Tell
you
to
five
why
this
to
death,
but
these
aren't.
These
are
symptoms.
B
So
one
of
the
things
I
want
to
talk
about
about
these
things.
You
know
so
I
want
to
kind
of
introduce
this
conflict
and
I
wanted
to
briefly
frame
it
a
little
bit
and
I
also
want
to
frame.
It
is
completely
useless,
but
I
think
it
can
be
made
useful
and,
and
so
I
I
often
tell
folks,
be
very,
very,
very
careful
and
intervening
in
these
battles.
B
And
one
of
the
reasons
why
I
think
it's
important
to
understand
frames
is
that
we
make
a
lot
of
assumptions
about
why
people
do
things
and
very
seldom.
Are
we
right
at
first
and
but
we
think
we
are,
and
because
of
gut
feelings
and
our
past
experience
and
stimulus
right.
So
we
bring
a
lot
of
bias,
no
matter
who
we
are
to
these
things,
and
one
of
the
things
that
we
have
to
do
is
adopt
this
notion.
I've
learned
it
because
I've
been
humiliated
enough
times
by
thinking.
I
have
the
answer.
B
Is
this
notion
of
humble
student
right
when
you're
learning
a
new
thing
understand,
you
don't
know
it
and
that
you're
trying
to
get
closer
to
it?
Humility
in
understanding
is
very
important
and
when
you
think
you
understand
another
person's
point
of
view,
but
you
keep
running
into
this
rock
of
resistance.
B
B
Can
we
frame
these
things
with,
as
we
talk
to
each
other
with
a
little
bit
of
understanding
of
the
stability,
the
goals
that
we
have
in
operations
versus
the
goals
that
we
have
in
development
and
I?
Think
that
as
the
more
we
see
it,
we
see
that
these
aren't
versus
their
different
parts
of
value
chains
and
everything
we
build
only
really
delivers
value
when
it's
in
operations
matter
of
fact,
Business
School
definition
of
operations,
harvesting
value
from
operational
assets.
In
other
words,
we
build
software,
we
put
infrastructure
out
there.
B
We
want
our
value
back
so
operation,
the
continual
elimination
of
the
constraints
that
the
software
provides
only
in
operation
of
that
software
is
it
eliminating
constraints
and
providing
actual
business
value.
Now
there
are
the
things
that
we
can
make
that
are
patents
or
code
that
we
could
sell.
That
does
happen,
but
by
and
large,
in
the
enterprise.
The
way
we
make
value
is
by
running
those
things
that
we
built.
B
We
got
the
next
chain
here,
got
all
of
our
backs:
we're
getting
value.
Now
that
thing
you
gave
me
has
the
potential
to
generate
value,
and
it's
my
job
to
realize
that
potential
that
is
powerful
and
when
we
think
about
that
as
a
relay
race
together.
If
somebody
drops
that
baton,
we
don't
finish
the
race.
B
B
Some
of
us
are
old
enough
to
remember
when
gas
was
not
cheap
and
there
were
labor
riots
in
the
auto
factories
and
the
economy
was
terrible
and
interest
rates
were
14%
and
thanks
for
bad
and
so
GM
says
well,
people
are
kind
of
a
problem
and
we're
having
these
striking
auto
workers.
So
maybe
we
should
just
deal
with
machines
because
they're
a
heck
of
a
lot
more
simple
and
cheap
well
boy
was
that
wrong.
B
They
spent
I
think
billions
on
buying
robots
during
the
middle
of
that
Malstrom,
and
but
they
wound
up,
throwing
him
out
a
few
years
later,
and
then
they
asked
Ford's,
CEO
I.
Think
during
that
time,
saying
hey,
why
didn't
you
guys
join
the
arms
race
when
GM
did
and
buy
all
the
robots
and
the
CEO
of
Ford
said
something
to
the
effect
of
basically
realize
our
biggest
problem
was
consistency
of
practice
and
if
we
sped
up
the
rate
of
delivery
without
consistency
of
practice,
we
would
just
accelerate
the
rate
of
delivering
defects.
B
So
I
think
this
lesson
is
something
that
we
need
to
think
about
together,
which
is
in
the
car
industry.
A
lot
of
things
have
moved
really
really
far
towards
the
direction
of
develop
design
for
manufacturing.
In
other
words,
let
our
design
limitations
be
the
things
we
think
that
we
can
manufacture
quickly.
So
these
are
called
enabling
constraints.
This
is
something
that
a
lot
of
people
don't
realize.
Sometimes,
by
limiting
your
focus,
you
can
do
better
in
blues.
B
We
call
this
seven
bar
blues
in
a
sense
that
we
know
we
just
have
to
name
a
key
and
everything
after
that
has
a
basic
structure.
Why
do
we
do
that?
Because
it's
the
same
core
possessions,
because
it
allows
the
vocalist
to
improvise
over
top
of
it,
because
they
know
where
the
song
is
gonna
go,
that's
an
enabling
constraint!
It
enables
the
expression
extemporaneously
of
pain,
joy,
which
is
a
very
searching
process
right.
B
So
when
we
think
about
a,
how
are
we
gonna
work
together,
we
understand
that
sometimes
enabling
constraints
making
things
that
we
know
can
readily
be
able
available
in
production.
Now.
The
other
thing
is
is
to
pet
production,
has
to
move
enough
to
support
the
ongoing
strategies
so
that
we're
not
having
to
use
old
crap
all
the
time.
So
there's
there's
a
hybrid
thinking
in
there
make
new
friends
but
keep
the
old
one
is
silver
but
the
others
gold
right.
It's
like
the
Girl
Scout
theme
song
I
used
to
pick
my
daughters
up
from
Girl
Scouts.
B
So
one
thing
that
permeated
me
and
it
is
operational
thinking
which
is
these
assets
that
we
know
have
been
eliminating
constraints
of
providing
value
for
a
really
long
time.
You're
telling
me
this
new
friend
is
gonna,
be
really
cool
and
I
want
to
make
this
new
friend.
But
in
order
to
make
this
new
friend
I
have
to
keep
the
old
ones.
Working
I
got
to
keep
those
relationships
going,
and
so
that
is
a
different
way
of
thinking.
B
I
also
like
people
that,
when
they
want
to
make
a
new
friend
with
you,
also
consider
the
old
friends,
if
I'm
an
old
friend
of
a
lot
of
people
and
only
to
get
dropped
right
whenever
they
have
a
new
one.
So
I
think
you
know
if
we
start
to
think
about
these
processes,
these
cold
infrastructure
things
as
more
human,
relational,
emotional
and
sometimes
not
really
logical
and
also
far
more
complex
than
we
might
think.
We
actually
can
approach
them
with
the
humble.
You
know
the
humility
that
we
need
to
actually
start
to
talk
about.
B
That
is
what
we're,
after
we're,
not
after
legitimacy
for
name
banner
sakes
of
agile,
laying
and
DevOps
saying
and
idling
everything
we're
here
to
deliver
value
to
our
business,
and
some
of
these
things
make
that
easier.
If
they
don't,
we
need
to
question
what's
happening
right
and,
and
then
the
last
thing
to
say
is:
is
that
I
think
one
thing
that
we
forget
and
it's
as
developers
I
think
it's
important
understand
is
I
tool
is
actually
a
very
descriptive
versus
prescriptive
set
of
guidance.
B
So
I'm
gonna
give
you
a
little
bit
of
power
here,
not
that
I
have
it.
This
is
the
thing
I
learned
question
the
prescriptive
nature
of
the
adoption.
Is
that
really
what
people
had
in
mind?
But
don't
do
it
in
a
conversation
with
the
next
person,
like
that's
running
that
process
going
I'm
pretty
sure
what
you're
doing
is
not
what
they
had
in
mind,
because
now
you're
gonna
have
an
argument
about
points
of
view
and
odds.
B
Are
that's
not
gonna
be
productive,
but
what
people
can
do
is
actually
start
to
say:
hey
I,
I
think
I
get
why
some
of
these
processes
are
important.
But
can
you
help
me
understand
why
they're
important
to
you
and
though
boy?
Oh
boy,
talk
about
a
list
of
things
right?
It's
like
asking
the
UPS
guy
what
he
does,
but
I
think
at
the
end
of
the
day.
B
What's
really
important
is
listen
to
that
because
that's
what
you're
gonna
come
up
against
if
you
say
that
stuff's
dumb
and
try
and
understand
why
they
think
that
stuff's
important
and
ask
him
what
happens
when
it
breaks
and
how
they
feel
and
I
know
all
that
takes
time.
It's
a
lot
of
session
build-up.