►
From YouTube: Keynote Panel: A Deep Dive into the Benefits of CD - K. Hightower, R. Benoit, B. Leach & I. Mosquera
Description
Keynote Panel Session: A Deep Dive into the Benefits of CD: A Fireside Chat - Kelsey Hightower, Google; Rosalind Benoit, Themist; Brandon Leach, Autodesk & Isaac Mosquera, Armory
Join Kelsey Hightower as he moderates a fireside chat diving into the benefits and importance of CD and Spinnaker in an organization. This panel will dig into this subject from two perspectives: from an orchestrator of CD at a large company, and a business that is developing tools to support release automation and CD at scale.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
Autodesk
is
interesting
to
me,
mainly
because
that's
how
I
personally
got
into
tech.
So
in
10th
grade
I
was
in
a
computer
club
after
school
program
and
the
first
thing
we
learned
was
autocad
and
I
did
a
design
competition
at
the
state
level
in
georgia,
and
I
think
I
came
into
second
place
mainly
because
I
couldn't
print
the
actual
diagram.
So
I
gladly
took
second
place
and
decided
that
tech
was
for
me.
So
I
appreciate
all
the
folks
over
at
autodesk
that
have
worked
on
autocad.
A
That
was
definitely
my
entry
point
into
tech,
but
today
we
really
want
to
talk
about.
You
know
when
we
talk
about
ci
cd,
there's
so
many
ideas
about
you
know
you
should
be
deploying
two
trillion
deploys
per
per
hour.
You
know
it
gets
kind
of
overwhelming
to
think
about
the
way
people
use
this
stuff,
but
we
want
to
hear
what
the
reality
is.
So
I
guess
brandon
if
you
could
give
us
a
little
bit
about
you
know
we
want
to
start
with.
A
We
have
isaac
and
rosalind
here
from
armory,
and
you
know:
they're
one
of
the
powerhouses
behind
open
source
finicker
tell
us
a
little
bit
about
like
what
life
was
like
before
really
kind
of
getting
something
like
spin
and
occur.
This
conscious
deliberate
effort
to
standardize,
and
what
do
things
look
like
after
sure,
absolutely.
B
C
B
With
a
common
data
developer
experience,
but
if
you
look
at
you
know
where
we're
coming
from
right:
there
were
many
different
cloud
infrastructure
and
cd
tools
and
processes
right.
So
this
represented
a
large-scale
duplication
of
work.
You
know
we
didn't
really
have
the
leverage
to
make
a
change
in
one
place
or
add
a
capability
in
one
place
and
and
all
services
that
autodesk
get
that
so
so
consolidating
around
spinnaker
really
allows
us
to
start
consolidating
all
these
tools
and
offer
a
unified
developer
experience.
B
D
B
So
you
know
also
all
the
major
cloud
providers
are
also
developing
for
spinnaker,
and
this
has
been
very
powerful
for
us.
So
you
know
we.
We
have
a
strong
relationship
with
aws
and
being
able
to
go
to
them
and
working
with
armory
and
be
able
to
say
hey.
We
want
to
expand
lambda
support
on
spinnaker
and
them
being
able
to
do
that
and
making
it
a
a
a
first-class
deployment
target
and
spinnaker
alongside
containers
and
dms
has
been
really
powerful
for
us.
A
I
guess
isaac,
you
know,
how
is
this
inevitable?
Does
every
company
just
end
up
in
a
world
where
you
know
different
teams
go
off
and
do
their
own
thing?
You
know
get
something
working,
maybe
adopt
their
own
tools
and
automation
and
their
own
platforms,
and
then
eventually
people
try
to
reign
it
all
back
again
is
that
is
that
something
common
you
see
across
companies,
whether
big
or
small,
like
autodesk,.
C
Yeah,
I
think
I
think
the
size
of
the
company
is
absolutely
a
factor
in
terms
of
that
happening
right.
So
typically,
when
you
look
at
smaller
companies
and
organizations
that
have
let's
say,
20
or
30,
devs,
they're,
probably
standardizing
on
something
like
kubernetes
or
maybe
kubernetes
and
lambda
right,
it's
a
it's,
a
it's
fairly
homogeneous
workload
but
as
you
start
to
grow,
it
is
inevitable
because
you
look
at
these
enterprises
and
you
look
at
a
company
like
autodesk
they've
acquired
other
companies,
they've
grown
and
inevitably
what
happens?
C
Is
you
end
up
with
this
disparate
tool
set
and
tool
chain?
And
so
we
see
that
really
quite
quite
frequently
and
then
then,
of
course,
then
we
also
see
like
okay,
let's
try
to
standardize
as
much
as
we
can,
but
I
actually
I
disagree
with
the
idea
of
standardizing
the
entire
organization.
You
will
always
have
teams
that
are
doing
something
unique
or
maybe
on
the
forefront
or
trying
to
do
something
innovative.
C
If
you
try
to
put
them
into
the
standardized
bucket,
they
may
not
be
able
to
achieve
their
goals
right
and-
and
this
you
can
see
this
with
a
whole
set
of
new
infrastructure
and
tools
that
people
use
to
innovate,
that
they
didn't
have
before
and
and
typically
that's
how
it
happens.
So
you
want
to
have
you
know
a
majority
of
them
standardized,
but
you
want
to
leave
room
for
people
to
kind
of
get
off
the
beaten
path
and
innovate.
A
Yeah
I'm
going
to
get
over
to
roslyn
before
we
get
back
to
brandon
here
is
that
I
know
ryzen
did
a
lot
of
work
with
the
community,
not
just
the
practitioners,
the
people
building
the
stuff,
but
also
the
customers,
and
this
friction
was
kind
of
core
to
that
right.
You
even
see
this
inside
of
spinnaker
itself.
You
know
the
features
people
want.
Everyone
wants
to
do
things
slightly
different
way.
How
do
companies
and
people
should
deal
with
that
as
they
kind
of
listen
to
this
today?.
D
How
should
they
deal
with
it?
I
mean,
I
think
I
think
isaac
said
something
really
key,
and
that
is
I
heard
him
say
they
may
not
be
able
to
achieve
their
goals.
If
you
try
to
lock
them
down,
and
I
I
really
think
the
key
really,
I
think
the
way
you
start,
these
conversations
is
the
most
important
part
setting
the
tone
of
assessing
what
what
you're,
because
you
say
the
word
customer.
D
So
as
a
when
I
work
for
a
devops
company,
my
customer
is
a
customer
like
autodesk,
but
brandon
has
a
lot
of
internal
customers
and
they're
all
different
different
personas.
They
may
be
at
different
points
in
the
game
like
isaac
is
talking
about,
and
so
I
think
really
starting
from
that
perspective
with
your
internal
customers.
D
Understanding
what
what's
your
goal,
because
because
brandon
knows
what
his
goal
is
right,
he
probably
knows
what
his
organizational
goal
is
in
terms
of
that
digital
transformation,
but
I
think
asking
about
other
people's
goals
as
part
of
the
front
door
of
your
process
and
then
really
taking
the
time
to
listen
and
understand,
can
really
go
a
long
way
to
helping
you
navigate.
Difficulty
proposing
solutions
that
can
be
easily
agreed
upon,
because
they're,
a
win-win
and
helping
you
figure
out,
you
say:
serializing
culture
kelsey.
D
A
Well,
it
does-
and
I
remember
when
we
were
kind
of
doing
the
pre-work
for
this
session.
When
we
talk
about
cd,
especially
the
cd
component
right,
you
want
to
continuously
deliver
this
stuff.
There's
always
some
workflow,
that's
underneath
this
and
I
think
brandon
you.
You
talked
a
lot
about
like
look
everyone's
like
business
value,
digital
transformation,
blah
blah
blah.
Like
it's
cool
the
end
of
the
day,
you
have
to
automate
something
and
make
something
repeatable.
A
B
Yeah,
so
one
of
the
interesting
things
that
we
came
across
at
autodesk
was,
you
know
it's
one
thing
to
to
automate
the
deployment
of
a
service,
but
then
there's
a
lot
of
meta
infrastructure
around
a
service
that
you
we
actually
had
to
manage.
So
these
are
things
like
aws
accounts.
I
am
permissions,
you
know
and
we
started
to
think
about.
How
can
we
fully
automate
the
manage
of
kind
of
this
meta
infrastructure?
That's
that's
really
not
managed
by
spinnaker
or
any
of
these
cd
platforms.
So.
B
We
came
across,
you
know,
we
went
with
a
more
segmented
account
architecture
where
we
have
an
account
for
service
per
region
per
environment.
So
now,
when
we
create
a
new
service
or
we
launch
a
new
service
into
a
new
region,
you
know
we
don't
just
have
to
think
about.
Okay,
we
need
to
deploy
that
service
net
region.
We
also
need
to
manage
the
networking
and
the
kind
of
the
account,
and
I
am
and
authorization
for
that
service.
A
Right
now,
I'm
gonna
double
click
on
that,
because
if
people
are
listening
to
that,
they're
gonna
be
like
what
yeah
one
account
per
service.
Oh
yeah,
right
that
that's
hard
to
manage
period
yeah
and
I'm
pretty
sure,
there's
a
reason.
Why?
Right,
because
I
think
in
some
people's
mind
there
is
a
best
practice
to
do
everything
in
the
world
yeah,
but
you've
chosen.
This
approach,
maybe
give
a
little
context
of
why
this
approach
works
best
for
autodesk
and
also
maybe
give
us
a
little
color
about
what
a
service
is.
Are
we
talking?
A
B
A
that's
a
good
question.
The
answer
to
your
the
last
part
is
that
we
have
some
variability
there
right,
so
people
might
have
multiple
components
that
they
call
a
service,
but
we
skewed
towards
it
being
more
segmented
right
and
that
is
really
kind
of
related
to
how
we
set
up
authorization
for
access
to
those
things
based
on
the
account
so
yeah.
B
So
you
know
some
of
the
reasons
that
we
did
it
is
you
know:
we've
had
problems
with
large
multi-tenant
accounts
hitting
aws
api
rate
limits
where
you
know
where
they
start
to
affect
each
other.
You
know,
there's
also
some
some
complexities
related
to
aws
billing.
When
you
start
going
multi-region
where
you
know
the
aws
pair
might
be
different,
and
it
also
simplifies
this
automation,
if
you
think
about,
if
you,
if
you
know
what,
where
the
account
coordinates
based
on
the
services
region,
its
environment,
etc,
then
it's
easier
to
automate.
B
You
know
we
actually
work
with
aws,
so
we
we
have
a
service
that
we
built
in-house
to
kind
of
it
kind
of
works
as
a
service
registry,
and
it
also
creates
accounts
and
does
all
the
associated
networking,
and
we
actually
worked
with
aws
at
armory
last
year
to
build
dynamic,
account
registration
into
spinnaker
to
help
us
kind
of
automate.
Some
of
this,
some
of
this
complexity.
A
A
You
know
you
probably
did
the
put
everything
in
one
account
approach
revisited
that
changed
it
around
and
then
landed
on
something
that
just
made
sense
for
the
business
for
the
security
policies
and
when
you
tuck
that
and
said,
okay,
let's
make
our
cd
tool
do
that
versus
the
other
way
around,
where
I
think
some
people
will
start
with
the
cd
tool
and
try
to
have
its
ui
guide.
The
way
they
work
isaac
is
that
is
that
the
best
way
to
approach
you
know
this
particular
way
of
using
something
like
spinnaker
and
armory
services.
C
C
Heard
you
said
this
is
like
there
really
are
no
such
thing
as
cd
like
best
practices.
It's
really
like!
What's
good
for
your
organization,
what
do
you
need?
Because
I
can
tell
you
what's
good
for
brandon
and
autodesk
is
not
the
same-
that
the
the
same
needs
of
perhaps
a
bank.
I
have
a
financial
institution
that
has
different
security
needs
and
has
different
requirements
right.
So
absolutely
starting
from
you
know,
and
actually
roslin
was
saying
starting
from
your
goals.
What
does
your
teams
need
and
then
and
your
business?
What
does
your
business
need?
C
And
I
think
this
is
something
that's
really
really
important,
because
so
many
times
the
the
the
I
can
give
you
feedback,
but
it
just
will
not
fit
into
the
things
that
you're
doing,
because
it's
so
specific
and
context
specific
to
the
way
that
you
need
to
deliver
your
software.
So
absolutely,
I
think,
and
I
actually
love
the
way
that
brandon
and
autodesk
did
this,
because
that's
just
something
kind
of
like
out
of
the
box.
C
Thinking
of,
like
hey,
we're
going
to
create
an
account
for
every
single
service,
and
it
sounds
crazy
at
first,
but
if
it
meets
your
requirements
like
what
what
actually
is
crazy
about
it
in
reality,
right,
there's,
there's
really
nothing.
If
you
step
back,
I
I'd
love
to
know
brandon
like
how
difficult
was
it
to
actually
get
that
through
to
the
rest
of
the
the
organization
like
that
sounds
crazy.
Was
it
crazy
to
the
teams,
or
did
they
just
kind
of
jump
onto
it,
because
they
knew
that
it
was
the.
B
Right
thing
to
do
well,
one
of
the
things
that
we
we
paired
with
the
rest
of
the
organization
and
actually
wrote
a
strategy
paper
around
this.
So
we
we
involved
a
lot
of
different
organizations
across
autodesk
to
be
able
to
think
through
this
problem.
We
we
allowed
for
some
variability.
You
know
so
you
know
this
is
not
an
account
per
container
right.
You
know,
so
we
we
allowed
for
some
variability
there,
and
then
we
also
like
they
checked
in
with
aws,
said
hey.
B
What
is
the
best
practice
that
you're
seeing
people
do
this
at
scale
and
they
definitely
verified
with
us
that
you're
headed
down
the
right
path
of
having
a
more
segmented
account
architecture,
so
you
know
kind
of
it.
Didn't
it
wasn't
something
that
we
just
came
to
overnight
right.
It
was
something
that
we
worked
with
the
rest
of
the
organization,
multiple
organizations
within
autodesk
and
all
came
together
and
and
drove
to
the
same
place.
A
With
aws
yeah,
while
you
talk
about
business
goals,
a
lot
and
I
think
some
people
kind
of
conflate,
this
right
is,
you
know
in
this
case,
what
I'm
hearing
what
brandon
talks
about
is
like
this.
Is
the
plan
to
execute
and
deliver
the
software
that
we're
building
and,
of
course,
hopefully,
that
software
is
being
built
to
tackle
business
goals
right,
sometimes
people
will
say
well
what
brandon
is
talking
about
are
not
the
business
goals
right?
What
brandon
is
talking
about
is
too
low
level,
and
no
one
should
think
about
it
or
worry
about
it.
A
D
Yeah
and
actually
what
you're
talking
about
kelsey
is
the
most
computationally
expensive
work
that
the
human
brain
can
do,
and
this
is
one
it's
a
it's
actually
a
mystery
of
science.
There
is
no
working
mathematical
model
of
how
human
brains
do
this
quickly.
We
do
not
understand
how
we
take
a
bunch
of
different
motivations
that
were
inferring
through
communication
and
they're
all
weighted.
They
all
have
different
weights
and
that
we
have
to
make
inferences
on
the
weights
too,
and
then
we
have
to
decide
what
to
do
or
decide
what
to
say
and
how
to
communicate.
D
So
I
think
it's
a,
I
think.
It's
a
billion
dollar
question
that
you're
asking,
but
I
think
there
are
some
strategies
to
to
fall
back
on,
and
it
really
does.
It
really
does
start
with
getting
that.
Getting
that
context
and
thinking
about
the
difference,
I
think
kind
of
what
you're
pointing
to
is
the
difference
between
individual,
individual
motivations
and
then
what
are
your
joint
goals?
Ideally,
your
company
has
really
clearly
outlined
joint
goals,
joint
intentions
for
what
you
want
to
do
for
the
business
and
those
are
attached
to
what
your
stakeholders
want,
etc.
D
But
then
below
that,
there's
all
kinds
of
possible
motivations
that
individuals
can
have,
they
could
be
looking
for
recognition.
They
may
really
want
to
have
influence
at
the
company
and
make
their
mark
that
could
be
important
to
them.
They
could
really
want
to
smooth
away
and
make
things
easier
for
them,
because
their
brain
is
like
in
a
lazy
place
and
they
want
to
do
less
work.
That's
very
human.
D
They
may
have
some
shame
around
some
skills
that
they
think
that
they
don't
have
or
the
amount
of
time
it
takes
them
to
do
something,
and
they
don't
want
that
to
be
exposed.
There's
the
whole
american
value
of
independence
that
I
think
is
still
really
prevalent
in
our
culture
that
folks
feel
like
they
have
to
solve
problems
themselves
and
that's
very
prevalent
in
our
in
our
space.
D
Also,
some
folks
really
want
to
do
things
themselves
because
they
want
to
develop
the
skills
to
do
it,
and
people
are
really
motivated
by
that
and
there's
that
fear
of
being
left
behind
that
comes
up
too
right.
So
we
have
our
basal
ganglia.
Those
are
responsible
for
all
of
our
automatic
behavior
and
keeping
the
homeostasis
that
we
get
from
our
routines.
D
Part
of
those
basal
ganglia
are
our
amygdala,
which
is
responsible
for
protecting
us
keeping
us
safe
and
that
actually
interprets
change
as
a
threat.
So
when
that
amygdala
gets
activated
by
a
change,
then
that
can
really
create
a
lot
of
pushback.
So
I
think
it's
worth
it
to
take
the
time
to
double
click.
When
you're
talking
with
people
one-on-one
about
so
brandon's
saying
hey,
I
really
need
you
to
adopt
this
pattern.
It's
really
great.
To
start
that
conversation
by
trying
to
suss
out
it's
a
little
touchy
feely,
but
trying
to
figure
out.
D
Maybe
have
they
had
any
bad
experiences
with
doing
this
type
of
thing
in
the
past
and
where's
their
head
at
understanding
that
and
then
really
clearly
also
give
you
an
opportunity
to
clearly
state
what
your
goal
is
right,
because
so
you're
asking
someone
about
their
goal:
you're
getting
that
you're,
really
listening
and
you're
keeping
track
of
that,
and
then
maybe
they
at
the
same
time,
the
other
person
might
be
trying
to
understand
what
your
goal
is
right
so
and
that's
really
expensive
for
their
brain.
To
do
so,
just
tell
them
hey.
A
I
think
that
maps
really
well
to
the
consensus
building
that
brandon
laid
out.
This
fact
that
you
go
and
put
this
in
a
dock
and
say
hey
here's,
the
strategy
we
want.
We've
talked
to
aws,
they
gave
us
guidance.
We've
worked
with
the
spinnaker
team
over
at
armory.
They
gave
us
the
integration
work
that
we
needed
inside
of
the
tool
itself.
A
This
is
where
we're
going
to
roll
out,
and
my
guess,
brandon
and
you
know,
maybe
add
a
little
detail
here
when
you
go
out
and
you
build
consensus
with
the
rest
of
the
organization
about
this
plan.
You
know
how
much
feedback
goes
into
that
doc
and
then
how
much
does
it
change
over
time
and
does
it
live
on
as
a
living
doc?.
B
Right,
it's
not
as
only
a
technology
problem-
and
you
know
when
we
originally
came
out.
We
started
focusing
on
one
group
of
a
persona
of
customer
that
wanted
a
higher
level
abstraction
right
and
maybe
didn't
care
about
some
of
these
things
that
we're
talking
about
necessarily
they're
like
just
let
me
feed
you
my
requirements
and
I
don't
care
about
any
of
the
details,
but
then,
as
we
started,
to
expand
our
scope
and
started
to
talk
to
more
of
the
organization,
what
we
realized
is
that
there's
a
large
variety
of
ownership
models
across
autodesk.
B
B
Then
right
because
it's
a
it's
fundamentally
a
shift
from
thinking
like
okay,
I'm
an
internal
team.
I
have
a
product
and
I
have
a
customer
right
from
saying
that
I'm
building
a
platform-
and
I
have
partners
right-
the
partners
are
coming
and
helping
building
on
top
of
the
platform
yeah.
So
it
is
definitely
all
these
things
are
living
documents
and
a
constant
conversation.
A
You
also
kind
of
talk
about.
You
talked
about
a
little
bit
of
this
pattern.
I
see
with
customers
this
emergence
of
the
platform
team
yep
right.
I
think,
there's
this
idea,
and
it
reminds
me
a
lot
of
the
way
people
used
to
have
like
the
the
qa
team
and
the
build
team,
like
you
had
a
person
solely
responsible
for
figuring
out
how
bills
are
done,
hey
pencils
down
it's
thursday,
I'm
gonna
tag
a
release
in
cvs.
A
Some
people
may
remember
that
it's
way
before
github,
and
so
you
kind
of
pushed
all
this
responsibility
there,
but
I
think
what
you
kind
of
describe
now
is
like
look
if
you're
a
platform,
team
and
you're
going
in
this
direction.
I
think
ross
talked
about
this
as
well
you're
dealing
with
a
lot
of
responsibility
in
terms
of
like
creating
these
golden
paths,
learning
that
there
will
probably
be
no
golden
path
and
you're
gonna
have
to
build
something
a
little
bit
more
extensible,
something
that
actually
captures
feedback
and
allows.
A
B
You
know
we
we
definitely
we.
So
if
we
talk
about
the
spinnaker
piece
of
the
cdp
that
we're
talking
about
today,
we
group
a
couple
technologies
of
that.
Together
we
have
some
terraform
that
we
run.
That's
also
does
some
infrastructure
stuff
for
us
and
we
actually
kind
of
run
this
as
an
inner
source
project.
So
we
have.
You
know
people
came
to
us
and
said
hey.
We
like
what
you're
building,
but
we
want
x,
y
and
z
and
they're
different
from
what
you
have.
And
oh
I'm
looking
at
your
roadmap.
B
You,
oh
well,
you
know
what
your
roadmap
doesn't
fit.
What
I
need
that's,
okay,
you
know
what
I'm
gonna
go
build
my
own,
and
so
what
that
had
us
do
is
take
a
step
back
and
say
hold
on.
How
can
we
give
all
of
these
partners
from
across
the
organizations
a
seat
at
the
table
to
actually
bring
their
resources
and
help
build
on
top
of
the
platform,
what
they,
what
they
need
right
so
that
we're
all
building
and
contributing
together
so
yeah?
That's
exactly
the
kind
of
the
pivot
that
we've
taken
recently.
A
A
A
C
Yeah,
well,
I
I
think
you
know-
we've
said
this
a
few
times,
I'm
just
going
to
reiterate,
because
I
think
it's
so
important,
which
is
is
having
very
clearly
stated,
goals
that
you
have
people
aligned
around.
One
of
the
things
that
I
can
tell
going
into
an
organization
is,
if
I
talk
to
three
or
four
different
people,
and
they
respond
back
to
me
that
with
three
or
four
different
goals
on
to
why
we're
moving
on
to
kubernetes
man,
I
could
tell
you
it's
going
to
be
a
long
haul.
C
Getting
everybody
aligned-
and
you
know
it's
going
to
be
two
three
years
before
you
get
one
or
two
services
on
there
and
I
and
that's
those
are
real
numbers
like
I've
seen
two
services
take
two
years,
because
the
reason
why
and
raj
was
talking
about
this
watch,
oh
by
the
way
roz
that
was
elegant
going
from
the
psychology
in
the
brain
to
back
to
the
technology
that
was
an
elegant
transition.
I
like
that.
I
can
tell
other
people
like
that
too,
and
I.
C
It
really
does,
and
I
think
that
the
why
and
getting
people
to
understand
the,
why
is-
is
much
harder
than
I
think.
Engineering
leadership
understands
what
it's
going
to
really
take
to
get
people
to
understand.
Why
the
crossover
from
being
afraid
of
change,
to
accepting
the
change
and
moving
with
the
change
now
from
there.
I
do
think
you
know,
I
don't
I
personally
don't
ever
love.
C
The
idea
of,
like
innovation,
only
happens
on
these
teams,
but
I
do
think
you
need
to
start
somewhere
and
starting
small
is
a
great
place
to
kind
of
have
people.
You
know,
put
their
guards
down
a
little
bit
and
just
go.
Listen!
We're
going
on
this
this
journey
and
we're
starting
here.
This
is
the
beginning
of
the
journey
and
and
and
starting
from
the
very
beginning
brandon.
I
I
like,
where
you're
at
right
now
with
the
idea
of
like
hey.
C
Actually,
I
can't
lock
everybody
into
just
this
one
golden
path,
because
I
understanding
that
everybody's
going
to
be
a
little
bit
different,
but
you
do
have
to
start
with
someone
right.
You
got
to
pick
that
team
that
you're
going
to
kind
of
take
to
the
cloud
or
whatever
that
change
may
be
for
you
and
start
working
with
those
people,
but
but
when
you
get
to
that,
second
customer
don't
impose
the
the
requirements
of
that
first
customer
on
that.
Second,
one
or.
C
C
I
know
the
right
way
to
do
cd.
Your
way
is
the
wrong
way.
This
will
never
work
and-
and
I've
seen
those
two
different
mentalities,
and
I
love
how
brandon's
approaching
this
and
it's
it's
night
and
day
you
can
and-
and
you
and
I've
seen
this
too,
where,
where
teams
go
well,
I'm
just
going
to
mandate
it
to
my
other
teams
and
even
if
you
have
the
power
to
mandate
onto
these
other
teams.
C
What
I've
seen
and
I
can
measure
this
with
the
data
that
we
have
is
that
the
adoption
of
your
platform,
even
when
it's
mandated,
is
much
slower
than
the
teams
that
are
not
mandated
and
feel
a
sense
of
ownership
on
the
project
or
feel
a
sense
of
flexibility
that
they
can
do
what
they
need.
It's
really
interesting
the
mandate.
I've
almost
never
seen
work.
C
So
if
you,
if
you're
out
there
and
you
think,
oh
I'm
going
to
go
to
the
top
and
we're
going
to
have
the
vp
or
the
svp
mandate,
something
it'll
just
go
much
much
slower
than
actually
doing
the
work
of
listening
to
people
being
empathetic
and
being
flexible,
and
actually
it's
more
fun.
Designing
a
platform
where
it's
flexible
and
you
can
give
people
the
ability
to
put
components
together
from
an
engineering
perspective,
at
least
for
me,
that's
more
fun
than
just
hard
coding,
everything
for
for
for
the
customers.
It's
a
much
more
interesting
programming
problem.
A
Yeah
on
the
mandate
front,
you
know
the
analogy
I
like
to
use
here.
You
know
I
have
a
daughter
in
high
school
and
you
know
when
you
mandate
things.
That's
like
the
equivalent
of
going
school
shopping
for
your
kids,
but
you
don't
let
them
come
with
you
and
you
just
bring
back
what
you
think
they
like
to
wear
and
you
just
see
their
faces
like
mom,
I'm
not
into
goth.
What
is
this?
A
And
so
it's
one
of
those
things
where
you
want
them
to
actually
have
a
say
and
what
they're
buy.
You
might
put
some
parameters
around
that
like
a
budget
or
something,
but
you
definitely
don't
be
want
to
buy
your
kids
school
clothes
for
them.
We
got
to
wrap
up
here.
We
got
a
couple
minutes
left
and
I
think
the
biggest
thing
that
we've
learned
a
lot
today.
I
think
a
lot
of
companies
really
don't
understand
the
time
horizon
to
get
started
and
really
start
to
see
value.
A
I
think
we're
gonna
wrap
with
you
brandon
here
when
people
are
getting
started,
how
long
before
they
can
really
expect
to
see
some
value
and
then
how
long
before
they
get
to
really
feel
like
they've
really
arrived,
because
you're
never
done
maybe
take
us
out
with
those
two
checkpoints.
When
you
receive
value
and
when
you
really
feel
like
you've
made
that
transition.
D
B
Did
a
previous
a
transformation
at
my
previous
company
before
autodesk,
and
it
was
much
smaller
company
and
the
value
was
able
to
be
realized
a
lot
quicker
just
because
there
was
a
lot
less
people
to
get
alignment
with
and
a
lot
more
a
lot.
Less
compliance
controls
and
stuff
like
that
to
be
able
to.
B
I
think
that
also,
though
you
know
spending
the
time
like,
we
did
around
the
account
strategy
and
doing
things
up
front
and
trying
to
think
about
some
of
the
hard
problems
up
front
is
also
you
know
that
takes
time
and
that
pushes
out
the
horizon
of
when
you're
going
to
be
able
to
get
value
immediately,
but
definitely
definitely
is
worthwhile
yeah,
and
then
I
mean.
Obviously
it's
never
done
right
and
I
I
think
that
one.
B
That
we're
taking
out
of
this
conversation
is
this
idea
of
building
with
partners
right
and
not
trying
to
have
this
golden
path
that
you
force.
Everybody
into
is
really
going
to
accelerate
your
your
the
the
timeline
that
you
get
to
having
value
for
your
organization,
because
you're
gonna
have
a
bunch
of
people
come
build
with
you
right,
rather
than
you
know,
kind
of
like
talking
to
people
and
trying
to
reason
about
what
is
the
golden
path.