►
Description
Organizational Conversations
John Willis Red Hat
Global Transformation Office
OpenShift Commons Briefing
July 17 2020
A
Welcome
again
to
another
openshift
commons
briefing
today
is
friday
and
as
we
want
to
do
on
fridays,
we
have
folks
to
talk
about
transformation,
organizational
transformation,
cultural
shifts
and
all
those
kinds
of
wonderful
things,
and
on
today
we
have
with
us
john
willis
from
the
global
transformation
office
and
he's
going
to
have
a
conversation
about
conversations,
organizational
conversations,
I'm
gonna,
let
john
take
it
away
and
introduce
himself
and
we'll
have
live
q
a
at
the
end,
so
john,
take
it
away.
Thank
you.
B
Great
thanks,
diane,
thanks
for
everything
you
do
for
this.
This
is
an
awesome
you
and
chris.
Thank
you
so
much
yeah,
so
organizational
conversations.
What
the
heck
is
this
so
hopefully
we'll
I'll,
give
you
some
insight
of
what
I've
been
thinking
about
for
last
two
or
three
years,
and
and
actually
having
some
fun
at
red
hat.
Doing
some
of
this
stuff
too.
So
jan
willis,
I'm
part
of
global
transformation
office
and
jay
willis
red
hat
our
team.
B
If
you've
been
coming
here
on
fridays,
you've
probably
gotten
to
meet
andrew
clay.
Shafer
he's
my
boss,
one
of
my
best
friends.
I've
been
working
with
him
for
years.
He
we
we
kind
of
co-created
on
the
shoulder
of
giants
with
many
other
people,
but
the
devops
movement
kevin
bear
next
to
him
is
the
one
of
the
authors
of
the
phoenix
project.
That's
me
on
the
short
guy
there
and
then
jay
bloom
to
my
right
has
been
working
with
kevin
for
years
and
I've
known
all
these
guys
for
years
and
they're
just
I.
B
I
say
that
I
feel
like
I'm
willy
wonka
in
the
chocolate
factory
working
with
these
guys.
It's
just
an
amazing
team
to
be
on
andrew
likes
to
say
we
wrote
some
books,
so
I
was
the
co-author
of
the
devops
handbook
and
the
beyond
the
phoenix
project,
and
I've
got
a
fair
amount
of
other
publications
that
wouldn't
fit
on
a
page,
but
so
one
of
the
things
that
you
know
I
started
thinking
about,
I
won't
give
you
my
resume.
Go
to
my
linkedin
profile.
B
Jay
willis
said
I
think
it's
john
wilson
atlanta,
something
nonsensical
like
that,
but
I
was
a
doctor.
You
know
I
had
been
like
12
years
in
vendor
space,
a
chef
I
would
start.
I
was
very
early
chef.
I
sold
the
company
dell,
I
sold
the
company
at
docker
and
and
by
the
time
I
was
ready
to
leave
docker.
I
was
really
excited
about
going
out
and
being
independent.
B
B
You
know,
institutionalized
this
sort
of
memory
muscle
you
know
bad
behaviors,
so
I
I
started
I
didn't
know.
I
still
don't
really
know
what
a
great
name
of
it
is.
I'm
pretty
sure
organizational
conversations
is
not
it's
just
the
one
I've
called
it
organizational
anthropology
I've.
Other
people
have
given
it
names
to
me,
but.
A
B
Really
an
idea
where
you,
where
I
just
literally,
go
in
and
I
and
I
have
conversations
with
people
so
typically
I
get
to
work.
The
only
way
this
works
is
the
work
was
usually
a
cio.
I
see
here's
how
this
is
going
to
work.
In
fact,
what
typically
happens
is
people
say
john?
Can
you
come
in
and
and
sprinkle
pixie
dust
all
over
our
devops
and
I'm
like
yeah?
B
Sorry,
it
doesn't
work
that
way
and
then,
but
what
I
can
do
is
do
this
and
in
a
very
few
companies-
and-
and
I
I'll
be
honest
with
you
a
lot
of
times-
I'm
interviewing
the
cio,
because
you
know
some
chief
of
staff
or
somebody
who
will
bring
me
in
to
say
I
don't
tell
this
yeah,
you
need
to
hear
john.
You
need
to
hear
what
he
has
to
talk
and
and
I'll
at
the
end
of
that
I'll
go
back
to
the
person,
the
champion
that
tried
to
get
me
in
and
I'm
like.
B
As
you
know,
somebody
who
speaks-
and
you
know,
tries
to
always
sort
of
educate
people,
which
is
my
nature.
Whether
I'm
presenting
is
that
when
you're
in
these
conversations
you
want
to
correct
people
if
they
say
something
like.
Oh,
let
me
teach
you
so
that's
not.
You
can't
do
that.
I
you
need
to
just
listen
and
that's
sort
of
anybody's
trying
this
model
just
make
sure,
because
again,
what
you
don't
want
to
do
is
when
you're
into
like
30
minutes
of
15
or
20
people.
B
Having
this
great
conversation
telling
you
how
things
really
work,
you
don't
want
anything
to
derail
that
so
the
other
thing
I
think
a
lot
about
is
you
know,
andrew
andrew
clay,
schaefer.
You
know,
I
think,
he's
the
first
time
I've
seen
in
the
devops
world
he's
he
took
and
he's
great
at
like
metaphors
he's
awesome.
B
He
did
the
blind,
you
know,
devops,
you
know
sort
of
a
devops,
you
know
blind
person
and
you
know
sort
of
the
elephant
and
it's
a
it's
an
old
sort
of
metaphor,
and-
and
I
I
look
at
this
as
like,
this
is
what
leadership
right
there
there's.
So,
the
the
ceo
is
touching
the
trunk
and
he
thinks
it's
a
snake,
maybe
the
the
the
cto
she's
touching
the
the
the
tail
and
and
she
thinks
it's
a
rope
on
and
on
right
and
and
but
the
thing
is
it's
it's.
B
This
is
sort
of
systemic
of
the
problem,
like
you
have
the
blind
eye,
t
right
where
dev
is
touching,
and
you
know
possibly
just
to
just
really
just
trash
the
metaphor.
The
the
leadership
one
is
you
know,
is
a
purple
elephant
and,
and
the
the
it
one
is,
is
an
orange
elephant,
so
they
again
not
even
be
able
to
see
that
the
context
is
different
from
release
and
network
and
dev
right
like
so.
This
is
just
the
what
you
know.
We
all
know
this
right.
B
B
It's
not
even
just
a
different
color,
it's
the
giant
attacking
rabbit.
You
know
the
the
the
trojan
rabbit
right,
monty
python
right.
So
so
how
do
you
get
the
point
right
like
that?
That
that
is
the
problem
right
sort
of
our
context,
our
individual,
our
team,
our
group,
even
our
leadership
context
or
or
you
know,
we
see
things
with
different.
You
know
memory
models
or
models,
cognitive
models
right,
and
so
that's
just
human
nature
right
so
right
off
the
bat
we're
host.
B
No
we'll
do
fine.
So
I
I
there's
this
notion.
If
you've
ever
started
a
company
or
you
do
start
a
company
you'll
be
turned
very
early
by
somebody.
Usually
your
lawyer
that
there's
this
thing
called
piercing
the
corporate
veil,
which
means
that
if
you
don't
act
like
a
corporation,
you
know
the
irs
could
come
in
and
say
you
have.
No,
you
know
you
have
no
journals.
You
have
no
sort
of
meeting
notes
anyway.
B
They
call
it
piercing
the
corporate
veil,
but
but
I
I
I
think
this
is
like
what
I
call
piercing
the
organizational
veil
right,
which
is
you
know
the
veil.
Is
this
adversary
relationship
of
consultants
come
in
and
and
then
the
people
who
are
sort
of
doing
the
work
or
like
well
here
comes
the
bops
right,
the
bob's
in
in
office
hours.
B
The
class
example
right,
like
you,
don't
want
to
tell
them
anything
or
you're
afraid
to
tell
them
anything
or
you
need
to
always
spin
things
that
they're
better
than
they
aren't,
because
you
don't
want
to
be
the
one
that
gets
fired.
So
what
I
have
to
do
is
come
in
and
earn
trust
or
somebody
who
sort
of
evolves.
This
model
earn
trust,
so
they
don't
seem
like
the
bombs
and
I
need
to.
I
can't
ask
you
questions
like
how
is
your
cmdb,
how
accurate
is
it?
B
Oh,
john,
it's
fine,
you
know,
and
you
know
no
open,
critical
vulnerabilities
or
cvs
cvs
on
your
production
system.
Oh
no!
No!
Not
at
all.
John!
Don't
worry
right
like
so.
You
have
to
you
have
to
sort
of
gamify
a
little
bit,
but
it's
it's
a
trust.
It's
getting
people
to
open
up
to
you,
and
actually
it's
not
that
hard.
You
know.
B
I've
been
called
the
anti-mckenzie
right,
which
is
like
such
a
compliment
right
you
know,
so
I
shouldn't
call
it
any
so
think
of
mckinsey
as
any
one
of
the
large
consulting
companies,
but
but
the
model
of
of
most
of
our
industry
is
they
come
in
and
they
already
know
what
they're
going
to
tell
you
and
they
do
a
little
bit
of
lip
service
to
make.
Oh,
we
want
to
listen,
but
they
don't
really.
B
B
That
is
that
I
honestly,
even
though
I
have
lots
of
sort
of
meta
and
and
process
of
how
to
do
things,
you
know
as
an
educator
as
an
implementer
as
a
you
know,
thought
leader,
which
is
a
terrible
phrase,
but
for
lack
of
a
better
one,
but
I
really
try
not
to
go
in
with
the
solution
and
the
other
thing
is.
I
don't
really
want
to
have
an
in-depth
conversation
with
the
leadership
I
want
to
have.
B
You
know
surveys,
they
don't
work
right
or
let
me
speak.
They
don't
give
you
this
level
of
truth
and
depth
to
what
your
problems
really
are.
I
mean
I
can
generically
walk
in
the
door
and
say
I'm
your
bank,
I'm
pretty
sure
you
have
this
this
this
and
this
problem
and
chances
are
I'm
about
80,
right
and
anybody
else
who
re
has
a
reasonable
understanding
of
what
we
do
in
things
called
devops
or
transformation.
B
I
mean
just
taking
notes
with
hundreds
of
people
and
then
you
have
to
figure
out
like
how
do
I
take
all
this
stuff,
because
joe
said,
oh,
my
goodness,
you
know
we
have
no
sense
of
priority
here.
You
know
sue
says
well,
our
budgets
are,
you
know
ridiculous.
We
get
yearly
budgets
and
they
change
every
three
weeks
on
what
we
should
do
right
and
you're,
not
like
you're,
not
getting
all
that
stuff
in
like
categorized
discussions
they're
like
you're,
when
you
go
back
to
your
notes
and
then
so.
B
The
first
thing
I
realized
is:
I
had
to
come
up
with
these
sort
of
buckets
and
a
reasonable
way
to
sort
of
capture
I
mean
and
not
not.
All
things
are
perfect
there.
There
certainly
are
other
buckets,
but
I
I
use
this.
As
my
was
my
framing
for
how
I
go
about
trying
to
do
like
a
quality,
a
quantity,
qualitative
analysis
of
everything
I
heard,
and
and
typically
it
stems
into
these
seven-
it
could
have
been
six,
it
could
have
been
eight
seven
just
sounds
cooler,
invisible
work.
B
We'll
talk
a
little
about
that.
You
know
it's
it's
about
work,
that's
just
you
know
downstream
dependencies
that
aren't
captured
work
that
isn't
captured
because
you
have
so
many
different
management
systems.
Management
system
toil,
I'm
probably
the
worst
offender
of
managed
system
toil
is
when
I
work
an
organization,
and
I
find
they
have
seven
ways
to
capture
work.
B
You
know,
share
a
point:
jira
message:
email,
you
know:
remedy
tickets
right,
you
know,
work,
work,
tickets
and
remedies
ars
and
and
none
of
that's,
aggregated
or
correlated
and
and
in
the
end
a
lot
of
data
is
missing
from
what
you
actually
do
so
not,
and
so
it
stems
back
to
invisible
and
then
misaligned
to
sentence.
We
know
that
that's
a
great
narrative
of
the
devops
story,
but
but
you
know
we
think
the
road
map
is
this,
but
then
I've
been
told.
B
I
have
to
do
this
and
in
you
know,
and
even
the
dev
and
ops
is
this
classic
core
chronic
conflict
right
dev,
you
know,
classically
dev
wants
to
move
fast
and
get
things
out.
The
door
operations
is
resilience
and
scale
and
like
we
need
you
know
so
so
again,
the
whole
and
and
again
in
in
those
classic
scenario,
operations
will
get
rewarded
by
reducing
impact
incidents
and
those
things
development
will
get
rewarded
based
on
delivering
things
on
time
and
features
right
and
right.
B
There
there's
there's
a
misalignment
center
tribal
nominees
for
any
of
you
have
read
the
phoenix
project
right,
the
brent
classic
example.
You
know
the
these.
There
are
these
sort
of
pockets
of
tacit
knowledge
that
that
the
people
just
don't
know-
and
you
know
when
you
start
interviewing
people
and
you'll-
get
a
a
a
flock
of
younger
people.
Who'll
be
like.
I
just
never
know
how
to
do
this
and
then
some
sort
of
seasoned
person
in
the
back
room
will
say.
Oh,
that's
easy!
You
just
go
to
bob
and
they're
like
yeah.
B
I
want
the
bomb,
but
he's
too
busy,
and
you
know
and-
and
I
asked
bob,
could
you
explain
how
you
do
this
and
I'm
like
I'd
love
to,
but
I
don't
have
time
right
so
the
whole
brent
character.
Who
is
you
know
that
you
know
and
the
more
if
they're,
not
it's,
not
the
person
who's
trying
to
preserve
their
job?
It's
just
somebody
who
likes
to
help
everybody
and
tends
to
be
you
know,
doesn't
really
realize
they're
a
bottleneck
right.
B
B
You
know
and
kevin
barrett
was
a
big
part
of
who
works
on
gta
was
a
big
part
of
that
brent
character
as
well
incarcerate
organizational
design
when
you
go
on
and
on
you
know
the
you
know
anywhere
from
and
it's
not
just
sort
of
you
know
the
sort
of
waterfall,
not
waterfall,
but
but
microservices
versus
monoliths
right.
That's
a
part
of
a
sort
of
inverse
conway
maneuver,
if
you're
a
villa
if
you've
been
with
conway's
law
or
but
it's
organizational
as
well.
B
There's
a
great
story
of
the
equifax
breach
right
where
the
the
cso
reported,
the
chief
find
the
chief
legal
officer
and
and
when
they
did,
the
congress
actually
did
a
postmortem.
You
haven't
read
it
it's
it's
a
fantastic
document:
they
they
interviewed
the
cso
and
they
asked
well
when
you
knew
that
the
you
know
pii
and
there
was
like
you,
there
was
a
compromise.
B
Why
didn't
you
go
to
the
cio
and
the
answer
was,
I
didn't
think
of
it
and,
like
that's
a
classic,
I
think
conway
lorrism,
in
that
their
mindset
was
all
the
things
that
were
required
from
a
legal
perspective
right,
so
incongruent
organizational
dying,
just
understanding,
complexity
right
through
this
we'll
talk
a
little
later
about
incidents
and
just
understanding
that
these
are
complex
systems.
You
need
to
have
system
thinking.
You
need
to
understand
blameless.
B
You
know
it's
a
whole
different
way
of
thinking
about
failure
and
then
last,
but
certainly
not
least,
you
know
security
and
what
I
love
about
this
model.
Is
it
almost
always
funnels
down
to
something
that
I
want?
I
call
security
compliance
theater,
so
let
me
move
on
a
little
bit.
You
know
this
is
just
a
model
from
elliot
gorat.
Who
is
the
person
who
wrote
the
goal
and
if
the
phoenix
project
was
model,
it's
about
thinking
about
complexity
in
a
different
way.
B
You
know
in
a
lot
of
ways
when
you
go
into
an
organization,
and
you
start
asking
questions,
they
start
giving
these
abstract
answers
with,
which
are
basically
telling
you
stories
where
what
you
really
need
to
do
is
find
out.
So
I
don't
want
those
first
order.
Answers
of
the
problem,
like
john
the
cmd,
is
fine.
Okay,
let
me
ask
you:
what
did
you
do
last
time
when
you
had
to
deal
with
a
remedy
for
sort
of
some
incident
to
find
all
the
systems
that
were
impact?
B
Like
I
use
my
spreadsheet?
Oh,
why
didn't
you
use
the
cmd?
Oh
because
it's
a
piece
of
junk,
it's
not
accurate,
and
so
the
process
I
go
through
is
this
it
it
I
I've
kind
of
over
time
gotten
to
and
to
model
it's
a
little
different.
Now
I've
done
a
couple
of
virtual,
which
are
it's
just
different
one
client,
it's
like
the
one
of
the
top
three
or
four
banks
in
the
world.
B
I
did
last
summer
I
spent
30
days
in
london
that
shouldn't
give
you
a
hint,
but
I
actually
became
a
bachelor
and
I
interviewed
400
people.
I
just
stayed
there.
I
actually
got
to
go
to
a
pub
at
night,
which
is
like
a
lifelong
dream
of
mine.
But
but
the
process
is,
you
know
you
have
these
initial
calls
I'll
talk
about
this
pre-assessment
leadership
call
you
know.
I
say
I
don't
really
want
to
hear
from
leadership
too
much,
but
this
there's
a
little
bit
of
a
head
fake
process.
I
go
through
and.
A
B
There's
the
online
analysis
and
and
and
to
be
clear,
although
I'm
not
a
scientist,
I
do
work
with
a
couple
now,
but
but
it's
it's
qualitative
analysis,
not
quantitative
right,
I'm
not
just
counting
the
things,
I'm
literally
trying
to
put
categories
initial
readout
report
final
report.
This
is
example
of
that
that
large
financial
institution
I
did
last
summer,
you
know
350
assessment
team
meetings.
It
was
actually
about
three.
It
was
more
than
200
people.
It
was
in
the
neighborhood
of
350.
B
400
pages
effectively
this
book
right,
I'm
getting
better
at
creating
a
systems
that
I
don't
have
to
have
notebooks,
but
I
I'm
just
old
school,
see
how,
if
you
look
at
that,
I
hope
it's
color-coded
and
so
those
become
the
categories.
I
literally
had
a
dcio
at
this
bank
at
the
end,
so
one
of
the
things
I
don't
do
is
I
write
down
everything
everybody
says,
but
it's
part
of
the
qualitative
analysis
fancy
way
to
say
it.
I
aggregate
the
stuff.
Nobody's
name
gets
bubbled
up.
It's
all
like
I've
heard
this
thing.
B
You
know
15
times,
I'm
pretty
sure
this
is
the
one
of
the
most
important
things
that
we
should
probably
address,
and
then
I
use
it
for
a
quote
wall
if
I
get
called
on
by
the
cio,
but
I'll
never
call
anybody
out
for
what
what
I
wrote
down
as
a
quote,
but
I,
but
I
had
a
dci
offered
me
ten
thousand
dollars
for
this
book
after
they
were
already
paying
me
a
big
money
for
the
engagement
right.
This
was
a
personal
and
you
know
the
answer
was
no.
You
know.
B
Sorry,
that's
my
promise
to
the
people
I
interview.
This
is
the
thing
I
actually
got
this
from
kevin
bear.
You
know
if
I
haven't
said
I
love
working
with
my
gto
team.
Let
me
say
it
again:
I
love
working
on
my
gto
team.
The
kevin
bear
and
he
says
it's
from
ellie
go
rat,
which
you
know
that's
great
right.
Even
better
is
this
idea
I
figured
out,
and
I
don't
do
this
all
the
time
it
just
depends
on
the
circumstances.
B
But
when
I,
when
I
get
to
interview
leaders,
I
don't
I
don't
want
to
ask
questions
a
different
way.
So
one
of
the
things
that
this
technique
is
really
works.
Well,
is
you
walk
in
the
room
and
you're
in
the
office
and
they're
about
to
tell
you
their
resume
and
what
they've
done
like
hold
on
a
second
before
I
get
started.
I
want
to
ask
a
question,
and
you
say
what
are
the
five
things
that
xyz
your
corp
is
not
doing.
B
It
should
do
and
then
they're
like,
oh
just
like
you,
just
threw
water
in
there
whole
water
in
your
face
like
and
then
the
next
thing
you
know
they
just
start
rattling
stuff
off,
and
then
you
get
a
sometimes
you
got
to
stop
them
at
10
or
15,
and
only
lives
for
five
and
and
I've
had
comments
like
wow.
This
was
therapeutic,
or
I
can't
believe
I
just
told
you
all
that
stuff
right
it
it
it
really
and-
and
it
really
sets
the
foundation.
B
In
fact,
I
was
forced
to
do
this
because
I
had
to
prove
that
this
would
work
to
one
cio,
so
they
wanted
to
start
off
with
a
smaller
engagement,
and
I
typically
would
say
no
to
that,
but
it
was
doing
it
for
a
friend
who
a
real
friend
that
brought
me
in,
and
you
know
he
needed
something
to
change
there
and
you
when
I
went
back
to
say.
Oh
this
is
your
leadership.
B
But
you
didn't
ask,
and
you
didn't
know
what
the
problem
was.
First
right
like
and
the
training
probably
will
fit.
You
know
there
are
some
great
I'm
actually
going
to
show
some
of
the
the
examples
of
road
maps
that
I
give
from
people
who
do
training,
including
red
hat,
of
course,
but
but
like
the
idea
of
just
coming
in
and
creating
a
training
budget
for
like
a
thousand
people
on
some
new
thing.
B
When
you
haven't
even
asked
the
people
who
do
the
work
what's
wrong,
maybe
maybe
I'm
crazy.
You
know
I
mean
I'm
living
on
an
island
all
by
myself.
I
wish
I
was
right
now,
but
hey
the
so,
but
then
we
get
into
the
sort
of
wrote
like
meetings
and
like
virtual,
it's
a
little
different,
but
you
know
just
the
nature
of
virtual.
Is
you
know
normally?
B
What
I
do
is
try
to
have
one
meeting
for
a
whole
day,
another
meeting
for
all
day,
I'm
now
doing
hour
and
a
half
two
meetings,
just
it
just
you
know
virtual
and
all
that
just
makes
sense.
It's
just
and
it
actually.
I
didn't
think
it
would
work.
It's
actually
working
better
than
I
thought,
and
then
I
have
to
go
through
some
process
of
qualitative
analysis
and
and
actually
again
working
with
a
guy
like
jay
bloom
right
has
got
a
phd
in
design
transition
and
like
we're
going
to
work
together.
B
Although
I
started
john
allspar
the
other
day,
who
does
very
little
stuff
on
incident-
and
he
says
that
maybe
one
of
my
the
one
of
the
things
that
might
make
this
great
is
I'm
not
a
not
not
a
sort
of
academic
based
scientist,
I
don't
know
we'll
figure
it
out
top
five
visibility.
Prioritization
toil
inconsistencies,
but
here's
the
thing
I
don't
know
I
mean
more
likely.
These
are
the
problems.
B
If
you're
a
100
year
old
bank
and
you're
sort
of
early
on
on
your
transformation
and
you've
got
sort
of
pockets
of
devopsism,
you
know
probably
three
or
four
days
are
gonna
hit
and
I
could
walk
in
as
a
high
paid
consultant
and
throw
my
devops
handbook
at
you
and
say
I
know
how
to
fix
this
right,
but,
like
I
don't
until
I
listen
right,
you
know,
and
then
you
know
so
like
all
right.
So
now
it
gets
a
little
sort
of
easier.
B
So
now
you're
mapping
all
the
analysis
to
the
top
and
here's
the
other
thing
too
right.
Not
all
parts
of
your
organization
move
at
the
same
speed.
You
can't
just
tell
everybody:
hey,
let's
safe
on
monday
in
the
world,
will
be
awesome,
but
you
have
to
meet
people
where
they
are
like
the
legacy.
Mainframe
people
like
I
started
my
career.
The
one
thing
I
wasted
is
really
cool
for
me.
Is
you
can't
stop
me
like?
B
B
You
know
jboss,
of
course,
or
you
know,
rabbit
mq
or
you
just
go
down
the
list
right
of
all
these
different
systems
that
you
know,
but
the
point
is
this
is
just
an
example.
The
the
real
magic
is
figuring
out
your
capacity,
the
different
speeds.
How
do
you
apply
different
techniques
at
different
speeds
in
the
organization?
B
It's
not
like.
Just
hey
everybody,
devops.
Well,
wait
a
minute
wait
a
minute.
Some
people
are
ready.
Some
people
are
not
so
when
I
say
this,
you
know
I
do
think
there
are
some
common
themes,
kind
of
called
the
operator's
guide
right.
You
know
you
want
to
create
an
operator's
guide
or
you
know.
If
you
want
to
be
fancy
call
it.
You
know
xyz
kata,
xyz
corporation
or
you
know
the
shared
agreement
right.
They
were
starting
a
company
the
other
day
where
their
their
new
cio
really
understands.
B
What
he's
doing-
and
he
has
this
idea,
how
he's
going
to
re-factor
the
organizational
structure?
Ask
me
if
it
sounds.
Is
it
sound?
I'm
like
yes
that
sound,
but
it
will
fail
if
you
don't
have
that
operator's
guide
across
all
those
things,
these
common
things
that
we
all
have
to
understand
as
the
true
naughts
right
and
so,
of
course,
automation,
but
taxonomy
like
maturity
like
again
going
back
to
the
speeds
like
you
want
to
get
everybody
to
the
same
place.
B
True
north,
but
you
figure,
you
know
some
people
and
there's
different
maturity,
models,
badging
or
different
things
that
may
or
may
not
work.
But
the
point
is
you
know
somebody
might
start
off
as
yellow
somebody
might
be
orange.
Somebody
be
like
green
right
and
and,
like
the
point,
is
you're
going
to
get
them
all
in
sort
of
directionally
the
same
way,
and
then
I
find
taxonomy
might
be
one
of
the
biggest
problems
in
organizations.
B
Is
people
use
about
10,
different
terms
and
there's
basically
a
thousand
variations
of
those
10
different
terms,
so
the
people
having
meetings
and
they
don't
even
know
they're
not
talking
about
the
same
thing,
but
it's
just
so
amazing.
How
just
simplifying
a
common
taxonomy
in
an
organization
might
actually
be
the
the
most
easiest
thing
to
do
and
solve
such
a
large
variety
of
problems.
Learning
understand
team
team
team.
B
B
I
the
one
I
heard
recently
would
blow
me
away.
Is
hey
john?
It
takes
me
about
a
minute
and
a
half
to
two
minutes
to
get
an
amazon
instance,
but
it
takes
me
another
two
weeks
to
use
it
like.
What
are
we
doing
here
folks
right
right
like
we
have
you
have
to
figure
this
out?
So
if
you
keep
thinking
that
and
I'm
a
big
fan
of
cloud,
I'm
a
big
fan.
If
you
don't
know
me
of
you
know
of
containers,
you
know
openshift.
B
I
think
the
the
platform
model
is
the
right
way
for
the
future,
but
like
if
you're,
building
all
this
stuff
on
a
platform,
and
there
are
people
out
there
that
you're
not
talking
to
and
saying
that
platform
is
great,
but
it
still
takes
me
two
weeks
to
get
a
computer
instance
to
run
a
test
right,
general
visibility.
I
I
won't
go
through
all
these.
I
will
make
this
deck
available,
inconsistent
road.
This
is
the
thing
where
you
it's
not
like.
B
What's
on
the
screen,
it's
what's
going
on
right,
which
is
you
know
like
there,
are
these
sort
of
notional
beginning
of
your
road
maps,
and
then
you
know
six
or
eight
months,
people,
the
people
that
I
talk
to
like
they
have
no
idea
what
we're
doing.
They
think
we're
doing
all
this,
but
every
three
weeks
I'm
told
to
change
to
do
this
too
many
practices
way
more
projects
than
our
people,
so
having
not.
Even
the
visibility
just
show
the
chart
that
you
are
over
compat.
B
You
know
your
your
your
allocation
of
you
know
what
you
believe
is
the
the
capacity
that
you're
running
is
150
beyond
and
that's
not
even
counting
the
hidden
work
that
doesn't
get
calculated
in
the
early
budgets
and
and
bottlenecks
too
much
work
in
progress
like
there's,
not
even
sort
of
a
sense
of
whip
going
on
right
or
if
it
is,
it's
localized
like
that.
You
know
I'll
run
out
of
time,
I'm
sure.
But
sorry
you
know
the
thing
I
love
like
is
you
know,
and
I'm
not
an
agile
expert
in
it.
B
Like
you
know,
I
learned
enough
to
be
smart
about.
I
learned
enough
from
the
really
smart
people
and
to
be
smart
enough
to
be
able
to
have
the
smart
conversations
if
that
even
makes
sense.
So,
but
when
I
walk
in
a
room-
and
I
talk
to
a
bunch
of
people-
and
I
talk
about
story
points
and
all
that-
and
I
already
know
they're
date
driven-
I
mean
I
know
they're
date
driven
right
like
right
so
like
I
don't
have
to
be
an
expert
in
all
things,
agile
and
and
scrum,
and
everything
else.
B
I
just
you
know
like
simple
math,
I
know
they're
date
driven
and
I
want
to
hear
them
explain
story
points
now.
I
actually
have
heard
viable
cancer
story
points,
but
more
often
than
not
it's
this
fun
game
of
well,
john.
We
did
this,
I'm
like
okay,
but
but
isn't
this?
Isn't
there
a
date
on
this
project?
Yeah?
But
you
don't
know
like
yeah,
but
I
don't
get
to
you
know.
Aren't
you
just
reverse
engineering?
The
story
points
to
meet
date?
B
Well,
you
put
it
that
way,
john
anyway,
so
I
hope
you're
sort
of
laughing.
I
can't
hear
you
when,
when
you're
doing
this
virtual
but
like
hopefully
somebody
just
laughed
a
couple
of
times
conflicting
priorities
unknown
dependencies
right,
I
don't
tell
this
story
really
quickly
like
so
I
one
of
the
stories
I
love
in
the
phoenix
project
right
and
I'm
gonna,
I'm
gonna
mangle
it,
but
but
there's
a
story
about
where
they're
all
in
the
boardroom
and
somebody's
saying
well,
why
does
it
take
63
hours
to
do
a
15-minute
task?
B
You
know
and
and
then,
and
then
it's
explained
to
them?
Okay,
let
me
explain
so
it's
a
very
simplistic.
You
know
queueing
theory
and
if
people
are
90
busy
and
they're
doing
something
that
has
this
yeah
very
simplistic,
but
everybody's
90
busy,
which
is
not
too
far
from
a
lot
of
organizations.
I
visit
and
everybody
has,
you
know
seven
downstream
dependencies
in
everything
they
do
all
right.
B
You
know-
and
I
have
this
great
conversation
with
the
cio
like
how
do
we
do
it?
John
I'm,
like
not
real
good
bob,
I'm
like
ordering
john
I'm
like
well,
you
know,
let
me
put
it
this
way.
If
you
build
the
airplanes,
I
wouldn't
fly
on
them
or
john.
Come
on,
be
a
little
serious
with
me
now,
like,
okay
bob.
B
As
far
as
I
can
tell
you
have
a
three
billion
dollar
I.t
budget
and
you
only
capture
about
30
of
all
the
things
that
are
happening
in
rit
and
I'm
wondering
what
other
part
of
your
business
would
tolerate.
That
finances.
We
reconcile
the
books
every
wednesday.
If
it's
not
raining
right,
you
know,
and
then
you
know.
B
Furthermore,
when
I'm
talking
to
people
about
that
sort
of
process,
I
say
why
don't
you
write
how
come
you
don't
create
a
ticket
to
that
or-
and
I
don't
believe
you
know-
we
have
a
whole
discussion
about
like
ticket
cues
and
all
that
that's
terrible
stuff,
but
but
why
isn't
there
any?
Why
aren't
you
keeping
an
electronic
document
on
that
work?
This
work,
you
just
told
me
about.
B
Oh
I've,
been
working
with
sally
for
like
15
years.
I
know
when
sally
gives
me
something
it's
only
going
to
take
me.
15
minutes.
Okay,
let
me
ask
you
something:
does
that
thing
you
do
for
sally
need
file
space?
Does
it
need
to
be
dealt
with
like
with
ldap
or
active
directory?
Of
course
it
does
cost
us
like
how
long
those
things?
Well,
that's
not
my
problem
right.
So
it's
a
the
context
of
the
the
view
of
how
long
it
takes
is
already
skewed
because
in
their
mind
it's
15
minutes.
B
B
I
wouldn't
be
here
on
this
call
right
now,
I'd
be
on
like
some
ridiculously
expensive
fishing
boat
on
the
gulf
of
mexico.
Maybe
calling
people
periodically
how
they
were
doing,
but,
unfortunately,
that's
not
the
case.
Shared
service
environments
are
terribly
hard
right,
like
if
you're
running
these
very
complex
systems
that
have
legacy
code,
you
can't
have
four
environments,
a
certain
kind
like
tibco
or,
or
you
know,
large
gateways
and
your
mulesoft
gateways
or
whatever
right,
like
not
every
organization,
and
I
can't
walk
and
sell
your
big
problem.
B
Is
you
need,
like
you
know,
eight
of
these,
for
everybody,
like
you
know,
of
course
that's
not
gonna
answer,
but
it's
still
a
problem
right,
because
you've
got
this
sort
of
yo-yo
effect
on
share
of
honor
somebody's
moving
up
you
go
to
tests,
you
got
to
move
it
back
down
to
a
release.
Somebody
left
some
artifacts.
You
know
it's
just
a
mess,
inconsistent
environments,
things
like
ansible,
you
know,
or
shaft
or
puppet.
B
So
you
just
told
me
you're,
manually,
building
stuff,
okay,
sure
I
mean
again,
I'm
being
a
little
funny
and
sounding
judgmental.
But-
and
I
don't
do
this
when
I'm
doing
this
with
clients,
but
sometimes
you
can't
help
but
laugh
among
friends
and
y'all
are
my
friends
right,
unclear
roads
and
responsibilities?
Yeah
we
could
go
through
anti-patterns
with
ci
cd
and
just
gonna
ping.
My
boss
is
yelling
at
me.
No,
no,
that's
not
totally
kidding.
You
know,
there's
tons
of
stuff
written
about
anti-patterns.
Here's
the
across
functional
chaos.
Right
yeah,
makes
your
space.
B
Then
you
know
in
one
team
the
the
there's
team
members
that
actually
are
cross-functional
to
somebody
else
and
another
group
there
they
report
to
this
one
but
they're
cross-functional
know
it's
just
like
there's
a
lot
of
chaos
in
how
you
and
again,
I'm
not
saying
like
product
owners
and
product
managers
or
technical
leads,
or
you
know,
technical
product
owners
and
and
back
to
the
taxonomy
right
like
getting
all
that
straight,
not
market
oriented.
We
have
a
whole
bunch
of
this
stuff
in
the
devops
handbook
about
that.
A
B
We're
getting
better,
you
know
and
again
there's
a
lot
sort
of
lisa
red
hat.
You
know
just
to
be
clear.
I
think
red
hat
has
a
red
hat
there.
We
go
been
doing
too
much
work
this
week.
It's
a
friday.
Red
hat
has
a
lot
of
really
good
leadership,
starting
with
and
the
rest
of
the
organization
with
gto,
but
you
know
about
how
we
are
getting
better
and
you
know
we
have
something
called
the
five
elements
andrew.
You
know.
B
You
know
this
strategy
is
just
all
different
arrows,
pointing
in
different
directions.
General
risk.
You
know
risk
in
general
right.
I
do
a
lot
of
work
on
automated
governance.
You
can
look
it
up.
Maybe
we'll
get
some
links
to
some
of
the
projects
or
devops
automated
governance
cloud,
automated
governance,
but
you
know
most
organizations
still
perimeter
based
right
their
their
mentality
was.
B
So
he's
one
of
the
leaders
in
network
people
in
the
world,
a
brilliant
guy.
You
know
he
said
you
know
a
couple
years
ago
I
saw
a
presentation
that
our
industry
spends
about
eighty
percent
of
its
spend
on
parental
base
and
less
than
twenty
percent
on
inner
perimeter
right,
subjective
governance
models
right.
So
a
lot
of
what
we
do
from
audit
and
control
is
basically
subjective
in
that.
B
You
know
maybe
something
like
a
blockchain
and
stuff
like
that
low
at
the
station.
F,
you
see.
So
that's
back
to
the
you
know
a
high
at
the
station
efficacy
that
it
would
be
something
like
you
know,
sort
of
like
a
blockchain
evidence
for
audit
data,
ops,
interesting
conversation,
starting
so
attestations
for
how
data
moves
you
know
most
of
the
largest
breach
and
the
most
worst
breaches
are
not
about
like
the
vulnerability
and
struts
to
jakarta.
B
It's
about
finding
data
that
probably
shouldn't
have
been
sitting
there.
So
if
we
had
anticipation
models
or
evidence
of
how
data
gets
transformed
and
placed
in
s3
the
nsa
breach
same
thing,
you
know
stuff
in
s3
buckets
so
the
working
model.
Typically,
you
know
again,
not
all
not
all
the
same.
This
is
when
I
start
to
do
I've
done
with
the
the
analysis.
B
I
start
thinking
about
what
are
these
things
and
what
order
they
should
be
put
in,
or
there
are
other
things
they
need
to
add,
but
taxonomy
models,
understanding
roles
of
responsibility,
community
practices-
you
know
open
org
stuff
is,
you
know,
works
really
well
if
it
hasn't
been
added,
really
understanding
how
you
know.
2020
incident
and
problem
management
look
service
transition,
upskilling
and
outcomes
I'll
go
again
a
little
a
little
faster,
it's
hard
to
do
this
test,
because
I
love
talking
about
this
stuff
and
I
think
it's
pretty
good
information.
B
So,
instead
of
sort
of
rewriting
all
the
the
400
column
risk
spreadsheets-
or
you
know,
15
stacks
of
books-
of
all
the
corporations
sort
of
risk
definitions,
you
can
actually
start
building
through
sort
of
evidence
and
emergence.
It's
pretty
cool,
a
long-lived
teams.
You
know
this
idea
of
whack-a-moling
teams,
you
know
taking
a
bunch
of
people
and
okay
for
the
next
six
week,
we're
gonna
put
sally
bob
and
tom
and
jam
together
and
then,
when
that's
over,
I
get
well.
B
You
know
what
I
need
to
pull
bob
out
of
there
early
because
he
needs
to
start
this
new
team.
The
teams
are
not
getting
learning
how
to
function.
There's
a
lot
of
research
on
on
like
how
long
I
think,
it's
three
months
before
a
team
actually
starts
to
bond
and
if
you're
ripping
them
apart,
you
just
you're
not
getting
the
whole
reason
why
you
might
have
wanted
to
go
to
build
run
teams
or
two
pizza
teams
was
for
that
synergy
and
bonding
building
trust
in
the
pipeline.
B
B
Picnic
tables
the
so
you
so
you
really
have
this.
It's
been
called
agile
budgeting.
I
don't
I'm
not
crazy
about
that
term,
but,
like
you
have
to
sort
of
break
that
you
get
a
budget
at
the
beginning
of
year.
You
know
what
happens.
You
know,
I
always
say
the
first
quarter,
you're
like
we
got
the
budget,
it's
great.
Second
quarter
like
we
really
should
start
working
on
that.
You
know
working
out
that
budget
stuff.
Third
quarter,
like
oh,
my
god,
we're
getting
close
to
fourth
quarter.
B
What
are
we
gonna
do
in
fourth
quarter,
like
you
know,
you
know
titanic
organizational
change.
Man
again,
you
know,
I
think,
with
everything
we
have
to
move
away
from
quantitative.
You
know
looking
at
like
from
the
leadership
perspective
like
how
many
of
these
did
you
get
done?
How
do
you
like?
You
really
have
to
sort
of
look
at
that
and
just
sort
of
smash
it
to
say
if
this
is
not
qualitative?
B
B
You
know,
half
of
that
screen
shouldn't
be
green
and,
like
after
meeting
somebody
comes
up
to
them,
you
know:
hey,
you
really
shouldn't
say
that
in
a
meeting
so
the
next
time
they
come
back
the
next
meeting,
they
say:
oh,
you
know
what
a
quarter
of
that
team
shouldn't
be
green
manager,
pulls
them
apart.
Dude,
didn't
I
tell
you
like
you
really
should
not.
You
know,
you're,
not
a
team
player
and
I'm
gonna
ding
you
next
year
on
your
your
bonus
and
what
do
they
do
about
the
fourth
fifth
time
they
come
in
like
bob?
B
What
do
you
think?
Do
you
think
that
screen's
all
green?
Yes
bob's?
Your
uncle,
you
know
so,
like
you
have
to
break
it.
Agile,
funding,
zero
trust
model
shift
left
security.
Again.
I've
got
a
lot
of
presentations
on
this.
We've
done
a
couple
in
this
forum,
I'm
sure
I'll
do
more
policies
code.
This
is
really
interesting
stuff.
I'm
about
to
work
on
a
new
working
group.
Here
I
worked
on
a
paper
called
devops,
automated
governance.
It's
a
creative
commons
on
the
itrevolution.com
site.
B
I
talked
about
data
ops,
you
know
and
then
really
understanding
the
new
world
of
configuration
like
we.
We
know
the
sort
of
ansible
chef
and
all
that,
but
all
the
configuration
that
goes
into
containers
and
and
clusters
or
managers
like
kubernetes
openshift,
like
there's
a
ton
of
vulnerabilities
there
and
it's
really
hard
to
keep
up.
So
I'm
really
understanding
the
you
know.
A
switch
that
you
turned
on
in
a
container
could
be
no
opt
by
not
turning
a
switch
on
on
an
open
shift
right,
so
common
language.
B
You
know
this
is
from
jane
grow.
Who
does
a
great
job
of
sort
of
talking
about
devops
sre,
and
I
tell
she's
an
ital
expert.
You
know
for
years,
but
just
like
it's
kind
of
funny.
If
you
look
at
some,
we
can
have
some
funds
like
a
ci
or
sort
of
dev
accessory
with
continuous
integration.
It
would
be
called
ci
configuration
item
in
cmdb.
B
Figuration
management
will
be
something
like
chef
or
puppet
ansible.
You
know
I
don't
speak,
you'll,
be
a
cv
and
you
get
the
point
right
and
and
then
what
you
know,
and
then
you
have
this
other
thing
that
I
think
is
important.
We
do
a
pretty
good
job
in
devops.
Handbook
is
sort
of
understanding
the
roles
of
your
organization.
B
B
Somebody
who
an
oracle
dba
that
really
becomes
t-shaped,
might
actually
learn
python
or
and
then
really
start
exploring
on
being
having
that
same
level,
expertise
on
my
sequel
or
sort
of
other
relational
databases,
or
maybe
even
taking
on
some
of
the
non-relational
and
then
e-shape.
You
know
I
mean
it
just
depends
on
where
you
when
I
you
know.
I
think
I
detest
the
the
phrase
full
stack
engineer,
there's
a
whole
book
on
it
about
it.
B
You
know
models
and
talk
a
little
bit
about
models.
You
know
again,
I'm
giving
you
a
little
snapshot
says
like
again,
it's
context
sensitive
to
the
analysis,
I'm
not
showing
you
everything
that
I
I
put
in
a
report,
I'm
just
giving
you
little
snippets
here
and
there
on
things
that
I
think
are
hopefully
you'll
find
interesting.
B
Basically
say
they
do
right,
but
I
make
fun
of
everybody
by
the
way,
including
myself
but
the,
but
the
thing
that,
even
if
they're
noticeably
doing
or
they
are
doing
it.
The
thing
I
very
rarely
see
is
this
notion
of
a
tp
team
tape,
api
and
it
comes
from
the
book
team
topologies,
which
I
highly
recommend
and
and
here's
an
example
of
it
like
so
each
team.
There's
a
problem
you
have
is
very
rarely
those
inner
organizations,
any
one
team
know
what
other
teams
do
right
or
worse.
B
What's
the
architectural
design
of
their
system,
in
fact,
they
call
this
sort
of
architectural
design
anthropology
where
people
have
to
go,
find
the
original
mrd
and
usually
it's
out
of
date
and
not
consistent.
You
know
the
the
requires
document
is
not
like
anyways
here
with
the
existence,
but
that's
the
only
best
that
they
have
how
about
a
world
where
the
the
team
sort
of
makes
these
promises.
That
will
always
support
two
versions:
well,
here's
our
wiki
and
documentation
to
the
best
of
our
abilities,
here's
our
practices
and
principles.
B
B
If
you
go
into
office
hours,
which
will
tell
you
when
their
prescriptive
times
are
we'll
promise,
15
minute
responses
right
and
then
we'll
make
sure
we
show
you
our.
You
know
kanban
boards
and
our
you
know
so
getting
near
the
end
here:
team
complexity
and
cognitive
nodes.
A
lot
of
this.
Some
of
this,
not
all
of
it-
comes
from
the
team.
Topology
again,
just
having
an
understanding,
I
mean
you
could
say
we
have
nothing.
B
We
don't
have
bill,
run
teams
they're,
not
two
piece
teams,
and
next
monday
at
4
pm
at
3
30
in
the
afternoon
eastern
time,
we're
going
to
have
build,
run
teams,
or
you
can
actually
do
some
research
and
understand
some
of
the
models
that
work
or
not
don't
work.
You
know
again,
there
are
some
organizations.
I
think
the
azure
model
is
pretty
good,
which
they
use
internally,
which
is
they
believe
that
you
need.
B
You
know,
like,
I
think,
there's
some
researchers
that
you
need
three
months
to
bond
and
you
won't
get
the
effectiveness
unless
you're
doing
12
to
18
months
of
keeping
a
team
together
or,
if
you're
sort
of
losing
a
lot
of
the
benefit
of
having
those
sort
of
build
run
teams.
Anyway,
you
know
red
hat.
We
have
some
models,
I'm
not
a
great
fan
of
horizon
based,
but
I
you
know
I
I
worked
out
with
one
client
how
you
could
do
a
horizon
one.
B
B
Here's
some
we'll
publish
this
I'll
go
through
this.
This
is
some
of
the
stuff.
Where
I
got
my
information
from
you
know
one
of
my
early
things
I
got
called
on
and
said
john
where's,
the
research
from
that.
Well,
okay,
let
me
make
sure
I
document
it
and
then
let's
end
up
with
incidents,
so
you
know
I'm
a
big
fan,
john
osborne.
If
you
haven't
followed
him,
he
works.
B
This
is
actually
a
sort
of
a
modified
quote
of
john.
I
actually
did
a
podcast
with
him
yesterday.
He
said
you
know
he
talked
about
how
like
why
incidents
are
so
important.
Right.
Incidents
are
signals
that
are
the
most
effective
directors
of
attention
of
what
an
organization
needs
for
recalibration
and
one
of
the
things
john
said.
I
think
it's
really
clear
and
it's
and
again
we
spent
a
whole
hour.
You
know
maybe
we'll
get
john
on.
I
know
we
had
john
on
last
week,
hey
well.
I
forgot
about
that.
B
A
pilot
like
sully
right,
if
you
watch
that
movie
sully,
was
great
because
sully
could
tell
stories
and
he
listened
to
stories.
In
fact,
he
had
a
a
blog
about
aviation
problems
that
were
stories
so
so
we
need
to
make
sure
incidents
are
stories
that
we
can.
People
want
to
listen
to
and
there's
a
lot
more
there
too
goals
of
incident
management
trying
to
get
near
the
end,
I'm
getting
pretty
close
again.
A
B
B
There
was
a
by
a
company
that
talked
about
you
know
literally
last
year.
What
was
it
like?
An
18-hour
spanning
tree
incident
right?
You
know,
I
mean
I
asked
my
network
friends
should
we
should
be
having
spanning
three
incidents
in
2019
he's
like
yeah,
john,
unfortunately,
yes,
but
but
like
18
hours
spent,
I
mean
this
is
billion.
This
is
like
ridiculous
money
loss
right
like
we
need
to
figure
out
how
to
invest
in
as
opposed
to
just
recording
them
and
throwing
them
into
dustbin
documents
all
right.
B
So,
with
the
six
minutes,
I
have
left
incident
management
opportunities.
You
can
tell.
I
know
it's
a
friday
right
because
I'm
so
I'm
actually
in
a
cynical
funny
mood.
You
want
to
learn
from
these
investments
to
that
point,
right
like
let's
make
sure
that
we're
telling
stories
and
we're
not
just
filling
out
checklists,
you
know
if
we
think
about
the
classic
idol
on
certain
matters,
we're
just
we're
running
up
to
get
reports
into
a
system
that
nobody
learns
anything
about.
Those
incidents
like
it's
a
bean
counter.
B
You
know
screen
right
where
what
you
know,
if
you
listen
to
john
in
adam
pets,
labs
like
we
should
be
attending
a
lot
more
investment
in
how
we
take
those
stories
to
learn
from
and
there's
a
ton
of
great
stuff
there.
Some
things
about
service
transition,
improvement,
there's
a
great
book
on
it.
It's
a
2019
book,
just
look
for
scott
prue
and
csg
he's
one
of
the
authors.
This
comes
right
out
of
that
I.t
revolution
forum
paper.
B
This
is
where
you
talk
to
him
about
localized
authority,
and
it
goes
back
to
the
t-shaped
individuals
and
you
start
building
build,
run
teams
right
so
you're
and
what's
interesting
about
this
kind
of
investment
right.
It's
all
about
economics,
investment
right
like!
Why
would
you
do?
Why
would
you
replicate
team
skills
and
not
have
a
centralized?
Well,
maybe
one
is
that
the
test
person
becomes
a
developer.
B
I
think
jay,
brilliant
jay
bloom.
I
work
brilliantly
calls
this.
Let
me
show
I
get
it
right.
Wait:
jay,
you're,
listening
liquid
skills,
liquidity
right,
it's
a
it's
a!
I
think,
he's
written
some
stuff
on
this.
It's
a
brilliant
way
to
think
about
a
dojo.
You
know,
dallas,
I'm
a
big
fan
of
davos,
dojo,
immersive,
learning
creating
repeatable
patterns.
It's
not
like
an
excellent
center,
it's
a
place
where
people
come
over
and
over
to
enhance
their
craft
and
their
skill
and
learn
new
things
making
work
visible.
B
This
is
another
really
good
book
on.
I
t
revolution
not
book.
It's
a
forum
paper
about
the
sort
of
cycle
of
you
know,
work
management
flow
from
handoffs
to
batch
size
to
work
in
progress
and
then
sustainable
approaches.
I
I
do
think
you
know
people
ask
me
a
lot
of
times
like
okay,
john,
when
you
leave,
you
know
what
we're
gonna
do
I'm
like.
Well,
you
need
to
find
somebody
that
can
like.
B
So
the
question
comes
up
a
lot
like
I've
had
engagements
where,
because
of
the
you
know
my
schedule,
their
schedule
budget,
all
those
things
you
start
it
like,
and
then
you
don't
come
back
till
six
months
later,
which
I
don't
recommend,
but
then
you
get
back.
Things
are
actually
better
like.
There
was
some
conversations
initial
that
actually
changed
some
things.
There
was
some
changes
that
they
made
and
and
then
the
question
from
the
cio
on
the
c-level
team
is.
Are
we
done?
You
think
we're
better?
B
I'm
like
no,
but
like
the
way
you
find
out.
Is
you
do
this
like
organizational
conversation
thing
over
again
and
the
people
will
tell
you
if
you're
better
worse,
getting
better
lean
coffee
if
you
haven't
experimented
slack
internal
devops
days?
If
you
haven't
done
this,
this
is
brilliant
again
ping
me
j
willis
at
redhat.com.
I
can
tell
you
who
has
done
it,
how
they've
done
it?
Internal
hackathons,
the
dojo
and
then
last
but
not
least,
with
three
minutes
man.
I
did
this.
It's
like
crazy.