►
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Let
me
tell
you
how
we
go
fast
and
why
we
go
fast
and
and
the
intent
of
this
discussion
or
presentation
really
is
one
in
which
I
try
to
set
up
and
I'm
trying
to
set
up
a
thought
leadership
kind
of
discussion
where
we
help
people
to
understand
what
we
do
and
how
we
do
it
without
being
a
tool
pitch
of
it
being
somewhat
educational
and
somewhat
open
and
transparent
about
where
we
are
and
who
we
are
and
where
we're
going.
So
I've
put
speaker
notes
into
this
deck.
A
So
if
you
were
to
want
to
use
it,
you
could
and
I'm
just
going
to
step
through
it
I'm
not
going
to
do
the
full
presentation
like
it
typically
would,
but
I'm
gonna
walk
through
it
and
sort
of
give
you
the
overview
of
it.
I
started
out
with
this
idea
that
digital
is
fast
and
digital
really
means
digital
transformation
means
moving
faster
and
I
talked
a
little
bit
about
that
to
try
to
make
sure
I'm
consistent
with
what
the
audience's
expectation
is
that
they
see
that
that's
the
same
way.
A
Markand
reasons
quote
the
where
he
had
a
tweet
store.
Me
talked
about
this
point
that
cycle
time
compression
is
key
and
what
he
really
did
is.
He
was
talking
about
this
analogy
between
auto
manufacturers
and
traditional
manufacturing,
where
you're
releasing
a
product
over
a
long
period
of
time
compared,
and
he
compared
that
to
software
as
a
service
and
in
a
SAS
business.
Software
is
a
service.
You
can
release
every
day.
A
You
could
release
as
fast
as
you
possibly
can
and
he
really
went
into
describing
how
he
saw
that
is
of
being
a
huge
competitive
advantage
and
and
the
reference
to
where
it
is
is
listed
here.
But
the
background
is:
is
that
and
I
think
the
point
is
fast
and
and
if
fast
is
an
advantage
and
moving
fast
is
the
objective
and
a
digital
transformation.
A
Then
you
want
to
learn
and
we
you
wanted
to
be
able
to
help
people
understand
how
you
do
that,
because
a
good
lab
we
moved
pretty
darn
fast
and
I
have
two
examples
of
how
we
move
fast
and
there
are
they're
different
examples,
but
one
is
galib
calm.
Our
website
we're
pushing
almost
70
updates
to
it
every
single
day.
Now
that
includes
the
handbook.
I
mean
there's
more
to
it
than
just
the
website,
but
the
point
is
we're
moving
really
fast
on
on
updating
and
removing
that
forward
and
improving
it.
A
Similarly,
our
product
gitlab
is
moving
crazy,
fast
as
well
89
consecutive
months
that
I
update
this
slide
every
time
I
do
it.
We've
we've
pushed
a
major
release,
a
significant
release
for
89
consecutive
months,
in
addition
to
what
we
shipped
all
the
time
as
far
as
updates
to
our
web
to
our
to
our
SAS
service.
But
our
packaged
software
goes
every
you
know
every
month
on
the
22nd
of
the
month
like
clockwork.
So
how
do
we
do
that?
And
and
what
are
the
keys
to
doing
that
and
that
that
sets
this
up
to?
A
How
do
we
go
from
being
the
slow
locomotive
to
being
this
high
speed
train
it's
moving
fast
and
it
really
the
key
that
I
try
to
drive
towards
is
its
people,
it's
process
and
it's
tools
and
it's
the
tools
that
help
us
to
do
it
and
it's.
It
gets
that
really
trying
to
remove
these
elements,
whether
it's
via
friction,
that's
introduced
from
the
silos
from
the
way
people
work
from
the
lack
of
visibility
to
make
decisions.
You
know
the
the
way
we
used
to
think
about.
A
Qa
is
responsible
for
testing
and
we
would
throw
it
over
the
wall
and
wait
for
QA
to
do
their
thing
or
we'd
wait
for
security
to
do
the
work.
You
know
the
ticket
mindset,
that's
often
in
organizations
and
so
to
double-click
into
this.
Really
it
gets
into
the
first
observation
that
we
do
a
gitlab
is
we've
eliminated
silos.
We
have
eliminated
silos
across
the
organization,
we
do
it
internally
and
we
do
it
externally,
and
the
silos
are
really
what
caused
problems.
I
mean
think
about
the
game
and
the
speaker's
notes.
A
I
talked
about
the
game
of
telephone
and
how
it
you
can
get
things.
So
wrong,
when
you
play
the
game
of
telephone
as
a
child.
Well
in
many
organizations
they
still
do
that
today,
except
they
try
to
write
it
down
and
they
sign
off
and
they
they
have
all
sorts
of
processes
to
play
the
game
of
telephone
like
it
lab.
We
don't
do
that
at
lab.
We
share
and
we
collaborate
in
ways
that
are
markable.
A
For
me,
this
is
a
screenshot
of
one
of
the
most
remarkable
collaborations
I've
I've,
seen
in
a
long
time,
Adam
Roberts,
I'm
gonna,
beat
out
of
one
of
these
days.
I
haven't
tried
to
find
him
yet,
but
he's
gonna
show
up
to
one
of
these
presentations.
Adam
Roberts
discovered
an
issue
where
we
were
working
on
value
stream
management.
He
discovered
it
on
Google.
A
They
took
the
time
to
register
and
contribute
and
share
his
input
as
to
how
he
thinks
we
should
do
value
stream
management
specifically
suggesting
a
feature
of
cumulative
flow
diagrams,
which
then
led
the
product
team
and
the
engineering
team
to
look
at
that
and
factor
in
humility
grams
into
our
roadmap.
Amazing,
it's
amazing
because
we
broke
down
the
barrier,
the
silo
between
us
and
our
prospective
customers
to
drive
us
going
forward
and
these
Siteman.
A
So
this
is
the
extreme
of
it,
but
I
think
the
reality
is
breaking
the
silos
down
across
the
organization
is
key
and,
furthermore,
when
we
think
about
it
internally,
here's
a
release
board
for
the
plan
team
for
planning
a
release
of
how
they
were
collaborating
in
a
visual
way
to
share
and
work
together
about.
You
know,
tracking
the
work
and
getting
their
release
out
and
what's
gonna
be
in
the
release
and
how
they're
gonna
close
the
close,
the
gaps
to
deliver
what
they're
gonna
deliver
for
this
specific
release.
A
So
if
silos
are
the
first
thing,
that's
important
and
changing
the
way
you
work
I
think
this
next
one
off
and
gets
a
chuckle
right.
Often
I
get
people
it'll
see
this
and
they
will
chuckle
a
little
bit
when
they
see
this.
And
the
point,
though,
is
after
they
get
done.
Chuckling,
as
the
point
is
that
the
ostrich
versus
the
hummingbird,
which
ones
at
more
agile,
which
ones
more
nimble,
which
ones
more
responsive
to
what
happens
in
its
environment
and
obviously
it's
the
hummingbird
right.
A
The
hummingbird
is
amazingly
fast
and
and-
and
the
reality
is,
is
that
when
we
think
about
shipping
software-
and
you
think
about
delivering
software,
larger
changes
with
lots
of
process
and
bureaucracy
to
test
it
make
sure
it's
right
to
prove
it's
right
and
have
lots
of
plans
and
rigor
around
them
are
almost
always
fraught
with
problems
and
risk
and
challenges
of
trying
to
back
them.
Out
and
and
we've
learned
that
smaller
is
better.
A
Now
Erik
rice
wrote
Lean
Startup
and
talked
about
Minimum
Viable
Product,
which
is
cool
a
product's
a
hell
of
a
lot
of
things
to
build
before
you
even
get
feedback
and
it
get
lab
because
we've
embraced
minimum
viable
change,
we're
moving
so
much
faster.
We've
reduced
the
impact
of
of
what
go.
What
could
possibly
go
wrong
while
we
increase
the
speed
of
getting
feedback
and
so
the
faster
we
get
feedback
the
faster
we
can
react
and
respond
to
what
happens
in
the
market.
We
can
learn
faster,
that's
the
key.
A
The
key
is
get
it
out,
make
it
better
and
learn
and
that's
what
we
embrace
them,
that's
what
we
do
and
that
has
unlocked
the
our
ability
to
move
even
faster.
You
know
graphically
a
lot
of
times.
This
is
a
view
that
I
think
helps
to
resonate.
Is
that
if
you
build
based
on
what
you
think
is
the
right
thing,
but
you'd
have
it
wrong?
You
don't
know,
or
the
right
thing
might
have
changed,
because
the
market
changed.
How
do
you
respond
to
that?
A
If
you
get
to
the
destination,
you've
built
the
wrong
thing
and
I
guarantee
you.
If
you
ask
IT
leaders
and
executives
and
anybody
who's
been
doing
this
for
a
while
ask
them
how
many
times
have
they
delivered
a
product
or
a
project
only
to
realize
they
built
the
wrong
thing?
I
guarantee
you,
you
will
have
a
half
the
audience
nodding,
they
will
not
in
agreement
because
they
will
smile
and
they
will
remember
the
last
project
they
did
that
on,
and
it
was
probably
pretty
recent.
A
This
is
a
very
common
problem
that
what
we're
talking
about
is
how
do
you
make
small
steps
moving
in
the
right
direction
and
then
constantly
adjusting
now
velocity
without
quality
is
a
real
problem
and
just
going
fast
and
shipping
crappy
code
and
crappy
solutions
is
not
what
anyone
wants.
Frankly,
that
scares
most
senior
leaders
to
death.
The
point
of
this
is
that
it's
not
speed
without
quality.
It's
actually
speed
with
quality
and
with
security
you
don't
have
to
sacrifice
quality
or
compliance
or
security
to
go
fast.
A
The
pipeline
is
the
key,
and
this
is
one
of
the
things
that
we
do
really
well.
We
build
into
our
pipelines
a
key
to
moving
faster
into
going
faster
without
risk.
For
example,
you
know
when
we
do
auto
dev
ops
and
we
think
about
what
is
a
default
pipeline.
Look
like
we
build
a
pipeline
that
has
quality
and
testing
built
into
it
with
security
built
into
it.
A
A
You
know:
dev,
sac,
ops,
DevOps
security
is
in
the
center
of
DevOps,
so
to
speak,
and
for
us
we
think
of
that
the
same
way
and
we
build
it
in
so
that
way
in
our
pipelines
when
it
runs,
we
get
immediate
feedback
about
security
to
make
sure
that
we're
not
introducing
new
problems
or
new
changes
now
the
key
is
is,
however,
you
do
this.
However,
an
organization
does
this:
they
have
to
understand
that
security
cannot
be
left
out
till
the
end.
A
It
has
to
be
an
integral
part
of
whatever
they
do
and
that's
what
we
do
here
as
well,
and
so
so
then
I
go
on
and
and
that
the
next
part
it
really
is
about.
How
do
you
go
faster
and
solve
the
other
real
organizational
challenges,
which
is
operations
and
environments
and
waiting
for
infrastructure
and
waiting
for
things
to
be
ready?
A
Additionally,
you
know
because
we're
embracing
infrastructure
is
code.
We
can
quickly
scale
up
and
scale
down.
You
know
we
can
deploy
with
you
know
canary
releases
or
a/b
releases,
maybe
testing,
etc.
We
can
go
faster
now.
The
the
final
point
and
I
left
this
for
the
end,
because
I
I
wanted
I
always
want
to
end
on
this
note.
I'd
either
start
on
this
note
or
end
on
this
note
in
any
presentation,
I
do
about
DevOps
and
increasing
velocity.
It's
about
continuous
improvement.
A
You
know
the
journey
that
we're
talking
about
organizations
embark
on
is
one
that
there
is
not
an
obvious
destination,
but
there
is
an
obvious
start
and
the
start
is
about
the
commitment
to
improving
the
velocity
and
the
speed
and
the
quality
of
what
they're
delivering
once
they're
on
that
journey
and
they're
looking
about
how
do
they
remove
waste
and
how
do
they
go
faster?
You
know
they're
gonna
land
in
something
that
looks
a
hell
of
a
lot
like
what
we
think
of
as
modern-day
DevOps,
exactly
how
they
get
there.
A
You
know
it'll
be
a
journey
for
each
one
of
them
as
to
where
their
pain
points
are
and
where
they
can
and
how
they
can
influence
the
change.
But
the
embarking
on
continuous
improvement
and
rapid
feedback
is
a
key
and
that's
something
we
do
here
incredibly
well,
we
do
live
retrospectives
on
YouTube.
We
get
together
all
the
time
to
look
for
and
gather
that
feedback
to
learn
from
our
last
releases,
and
in
addition
to
that,
because
we
learn
and
we're
learning
together,
we
document
those
changes.
A
We
document
those
lessons
learned
in
ways
that
we
can
harnessed
and
leveraged
together.
You
know
our
handbook
serves
as
a
single
source
of
truth
for
us
and
the
way
we
work
in
the
way
we
collaborate
and
work
together,
and
so
we
talked
a
little
bit
about
the
handbook
and
I
share
that
and
then
wrapping
up
this
whole
thing,
I
come
back
to
the
key
points
right
and
and
close
on
this.
A
The
this
is
a
presentation
that
then
the
the
last
data
points
really
is
that
you
know
our
humble
start
of
being
a
source
code
management
solution
being
a
best,
the
best
source
code
management
solution.
As
a
team
that
we
tried
to
build
and
started
building
seven
years
ago,
we've
evolved
and
iterated,
and
when
we
realized
the
larger
market
was
the
DevOps
tool
chain,
the
entire
tool
chain,
the
velocity
at
which
we've
delivered
is
it.
A
This
is
an
illustration
of
how
fast
we
move
and
how
fast
for,
as
a
proof,
point
of
where
we're
going
and
then
then
you
know
the
only
marketing
slide,
I
really
have
in
the
deck.
Is
this
one
here,
which
is
you
want
to
know
more
about
get
lab?
This
is
what
the
get
lab
the
product
does
and
where
we're
going,
and
why
we
think
there's
power
and
get
lab
and
that's
the
presentation,
so
feedback
can
you
use
this?
This
is
yours
to
use.
This
is
a
presentation.
A
I
continue
to
use
and
I'm
continuing
to
use
at
events
in
different
places.
The
thing
I
like
about
this
presentation,
I
think
that
really
resonates
is
one.
This
is
always
a
work
in
progress.
This
is
a
presentation
that
reflects
you
know
what
we
think
are
keys
to
our
success
and
as
we
go
forward,
I
think
this
will
continue
to
evolve
as
we
learn
together,
and
so
that's
one
of
the
ways
always
put
that
together.