►
Description
Sam Ramji, the closing keynote of Kong Summit 2019 and the founding CEO of Cloud Foundry Foundation, discusses how in a competitive environment, slow is dangerous. By building up from the smallest coherent units, we can engineer systems that work for the long haul through sharing what we each do best and relying on each other to learn at speed.
Learn more about Kong: https://konghq.com/
A
Good
evening,
how
are
you
all
doing
this
this
month
marks
25
years
in
the
software
industry?
For
me,
which
is
pretty
weird
quarter
century,
but
nine
years
ago,
I
had
the
uncanny
opportunity
to
meet
a
couple
of
Italians
who
were
pursuing
a
dream.
They
moved
to
San
Francisco,
they
rented
an
apartment
by
themselves.
They
cooked
me
pasta
and
they
called
me
Uncle
Sam,
and
that
was
a
ghost
Mrs
E,
who
you
know
as
Augie
the
geek
sniper
and
Marco
Palladino
the
CTO
so
when
they
invited
me
to
come
and
give
the
closing
keynote.
A
For
this
event,
I
was
beyond
privileged
at
the
open
source
business
conference,
which
some
of
you
might
have
gone
to
back
in
the
2000s.
The
last
keynote
of
the
day
was
called
the
footnote
and
it
was
very
special
indeed
so
to
uphold
the
spirit
of
the
evening.
I've
got
a
few
notes
here,
and
hopefully
this
will
be
a
good
way
to
summarize
what
we've
done.
A
So
my
inspiration
for
this
talk
is
this
community
we're
a
community
of
builders
right,
we're
building
on
ideas
that
came
from
the
generation
before
us
and
we're
building
a
platform
for
the
generation
that
comes
after
us
now
as
builders.
We
need
ideas
as
builders.
We
need
tools
as
builders,
we
need
customers,
but
even
if
we
have
all
three
of
those
things,
ideas,
tools
and
customers,
we
still
need
something
else,
which
is
other
builders
as
a
community.
We
continue
to
hope
to
learn
and
to
build
together.
A
We
share
with
each
other
because
we're
stronger
together
so
connecting
the
people
and
connecting
the
ideas
makes
us
powerful.
So,
as
we
close
out
our
first
day
together
at
Cong
summit,
I
thought
I
would
try
to
draw
together
a
set
of
threads
that
we've
been
discussing
so
making
one
fabric
out
of
threads
like
microservices,
api's
serverless
service
meshes
kubernetes
containers
out
of
the
operators,
developers,
architects,
business
leaders
out
of
organizational
design,
digital
transformation
platform,
thinking
and
decision
velocity.
That's
a
lot.
A
The
one
thing
all
of
these
have
in
common
is
speed.
We
all
here
believe
that
speed
is
safety.
I'll
talk
about
cargo
cults,
which
inhibit
speed
about
Concilium,
switch,
helps
us
think
about
speed
and
Conway.
Who
can
help
us
organize
for
speed
so
in
a
competitive
environment.
Slow
is
dangerous
when
the
market
moved
more
slowly
in
computing.
Resources
were
scarce
right.
We
thought
about
software
made
me
the
more
the
way
that
we
think
about
physical
goods.
A
Waterfall
like
let's
get
it
right,
it's
expensive,
but
it
turns
out
software.
It's
not
like
a
physical
good.
It's
made
of
bits,
not
atoms,
it's
massless
its
non-rival.
We
can
transport
it
anywhere.
So
really
we
need
speed
because
computing
resources
are
abundant
and
we
want
to
keep
up
with
the
market.
The
business
software
is
really
in
is
the
learning
business,
so
in
the
learning
business,
whoever
learns
faster,
wins
we're
learning
about
our
customers,
our
users,
our
constraints,
our
surpluses
and
each
of
those
dimensions
are
changing
over
time.
A
The
faster
we
learn,
the
faster
we
can
get
better,
the
faster
we
can
win
the
market.
So
the
limit
to
speed
right
the
limit
to
the
speed
that
software
can
recover
from
failure
that
we
can
iterate
on
a
feature
that
we
can
improve.
Scalability
that
we
can
add
value
to
users
and
that
we
can
learn
is
in
fact
the
time
it
takes
one
developer
to
change
one
line
of
code
and
get
that
into
production.
A
That
is
the
takt
time.
For
this
whole
environment.
This
is
what
we're
trying
to
build
towards.
So
if
speed
is
safety-
and
we
understand
this
well
then,
what's
our
constraints,
often
it's
our
models,
so
here's
the
you,
know
loop.
Many
of
you
have
seen
this
before.
This
was
modeled
by
john
boyd
in
a
very
competitive
environment,
observe
orient,
decide
and
act.
A
Some
of
us
think
it
looks
like
this
when
we
get
into
software
systems
a
continuous
flow
of
learning,
the
ability
to
turn
ideas
into
software,
bad
ideas
into
better
software
and
make
things
right
in
the
organizations
that
are
failing
in
digital
transformation.
They
look
a
little
bit
more
like
this
they're
following
a
different
common
sense.
The
common
sense
here
is
marketing
wants
more
customers,
customers
want
more
features.
A
Product
managers
specify
the
features,
designers,
design,
the
features
developers
build
the
features
and
then
operations
blocks
the
features
because
those
are
going
to
risk
the
stability
of
what
the
customers
came
to
you
for
in
the
first
place.
So
then
we
follow
our
intuition
and
we
mitigate
that
with
a
bunch
of
cascading
errors.
We
do
things
that
assume
that
slow
is
safe.
It's
not
slow
as
dangerous.
We
say,
there's
gonna,
be
more
reviews
which
produces
smaller
change.
Windows
takes
time
to
build
the
reviews.
You
still
have
features
waiting.
That
means
you
have
bigger
releases.
A
Bigger
releases
lead
to
more
failures,
more
failures,
more
time,
working
all
night
or
weekend
more
burnout.
None
of
this
is
good.
This
is
not
what
our
organizations
deserve.
So
what
we
need
to
do
is
empower
marketing,
product
management,
design,
development
and
operations
by
giving
them
a
consistent
system
which
supports
flow.
That
means
moving
away
from
us
versus
them
thinking
and
into
DevOps
into
a
platform
mindset
and
into
an
inversion
of
control.
So
if
we
all
agree
that
speed
is
safety,
what
is
it
that
we
can
use?
What's
holding
us
back?
What
can
we
learn?
A
That
can
get
us
all
on
the
same
fast
train
together.
One
of
the
most
important
things
that
I've
observed
personally
is
that
cargo
cults
inhibits
speed.
So
what
do
I
mean
by
a
cargo
cult?
Our
cargo
cult
is
one
in
which
you
copy
behaviors.
You
don't
understand
in
order
to
obtain
a
wonderful
result.
Chaos
ensues
I'm
inspired
by
Richard
Feynman's
1974
close
a
commencement
address
to
Cal
Tech,
which
I'll
read
out
briefly
here.
A
He
said
in
the
South
Seas
there
is
a
cargo
cult
of
people
during
the
war
they
saw
airplanes
land
with
lots
of
good
materials,
and
they
want
the
same
thing
to
happen
now
so
they've
arranged
to
make
things
like
runways,
to
put
fires
along
the
sides
of
runways
and
to
make
a
wooden
hut
for
someone
to
sit
in
with
two
wooden
pieces
on
their
head,
like
head,
phones
and
bars
of
bamboo
sticking
out
like
antennas,
that's
the
controller,
and
then
they
wait
for
airplanes
to
land
they're,
doing
everything
right.
The
form
is
perfect.
A
It
looks
exactly
the
way
it
looked
before,
but
it
doesn't
work,
no
airplanes
land.
So
I
call
these
things.
The
cargo
cult
science
because
they
follow
all
the
apparent
precepts
and
forms
of
scientific
investigation,
but
they're
missing
something
essential
because
the
planes
don't
land.
You
might
have
seen
these.
We
have
scrum
masters.
We
perform
the
ritual,
we're
now
a
truly
agile.
It's
one
of
my
favorite
trigger
where
it's
truly
somebody
uses
the
word
truly.
What's
underneath
that,
so
what
we
really
need
is
science
right.
A
We
understood
that
the
limit
of
how
fast
our
software
could
learn
was
how
quickly
one
developer
could
push
one
line
of
code
to
production.
So
automating
everything
is
the
core
of
it.
We
should
always
move
away
from
cargo
called
thinking
to
say:
ok,
great
I'm,
so
happy
that
you
have
the
rituals.
But
are
you
going
faster,
most
important
question
for
all
of
us
to
ask
every
single
day
where
he's
stuck
right?
A
There's
a
constraint
based
theory
of
capability
that
is
being
developed
by
nichole
force,
grin
says
humble
and
gene
Kim
that
you
may
have
heard
of
they've
written
a
book
called,
accelerate
I,
highly
recommend
it
they've
applied
science
and
math
to
assess
a
22
dimensional
constraint
based
model
for
IT
performance.
You
can
go
and
apply
it
and
use
the
science
to
get
unstuck.
A
Now
one
of
the
trickiest
places
that
organizations
get
stuck
it's
between
disciplines
and
that
is
where
Concilium
scan
help
us
so
Concilium
by
Edward,
o
Wilson,
the
famed
biologist
in
his
book
in
1998
said
knowledge
is
intrinsically
unified.
Intersectional
practices
make
us
stronger
and
smarter
together.
A
He
used
as
an
educational
example,
something
tremendously
important
to
us
even
now,
20
years
later
he
said,
as
you
get
deeper
and
deeper
expert
into
each
of
these
areas.
The
experts
find
it
harder
and
harder
to
communicate
with
each
other.
So,
as
you
look
at
the
intersection
of
these
circles,
the
less
progress
we
tend
to
make
and
these
have
issues
that
are
of
deep
importance
to
us.
How
do
we
put
a
valuation
on
forests?
How
do
we
understand
the
ethics
of
ecology?
A
How
do
we
understand
the
psychological
benefits
of
living
in
a
green
world
in
our
world?
In
our
technologies
of
api's,
microservices
service
meshes
and
server
lists,
we
can
start
to
ask
ourselves
in
a
generative
way.
What
are
our
shared
practices?
How
do
we
discuss
behaviors
at
the
intersection?
Perhaps
dependencies
are
a
good
conversation
to
have
between
developers,
building
lots
of
new
things
in
a
service
environment
and
the
micro
services
that
we
have
to
imagine
are
serviced
by
them.
A
Perhaps
observability
is
a
great
conversation
between
api's
and
service
meshes,
so
we
understand
why
things
are
performing
where
they
are.
Maybe,
more
importantly
than
the
technology
is
the
people.
How
are
the
architects,
the
business
leaders,
the
operators
and
the
developers
all
working
together?
How
do
they
have
respectful
conversations
that
really
help
move
forward
our
architects
and
developers
having
code
reviews
together
so
as
built
as
designed
as
imagined?
Is
that
really
working?
A
How
do
we
make
sure
that
the
business
and
the
operator
is
talking
about
cost
efficiency,
because
we
know
from
practice
a
cost-efficient
service
is
a
reliable
service.
If
it's
cost-efficient,
it's
unlikely
to
get
turned
off,
it's
likely
to
have
the
resources
necessary
allocated
to
it.
One
of
the
most
important
things
here
is
right
in
the
middle
service
level
objectives,
it's
something
that
we
can
have
as
a
practice
across
all
four
groups,
so
you
will
come
up
with
your
own
map.
The
power
here
is
to
borrow
the
idea
of
Concilium
sand.
A
Ask
ourselves:
how
do
we
make
it
easier
to
have
intersectional
conversations
between
these
different
communities
that
have
intersectional
overlap,
which
brings
us
to
Conway,
so
Melvin
Conway
didn't
come
up,
didn't
say
that
this
was
a
law,
his
peers,
called
it
a
law
and
1968
in
the
conversation
on
modular
systems
design
he
offered
the
following.
He
effectively
said
you
ship
your
organization,
so
if
we
find
that
you
ship
your
org
right,
then
you
can
shape
your
organization
to
produce
what
you
want
to
ship.
So
a
question
to
ask
is:
what's
your
basic
unit?
A
Do
you
think
about
a
brilliant
developer,
or
do
you
think
about
highly
collaborative
teams
if
you're,
on
the
left
hand
side,
you
are
probably
stuck
if
you're
on
the
right
hand,
side
you'll
be
stuck
somewhere
else?
What
we
often
find
is
that
great
teams
are
stuck
in
bad
organizations
if
this
is
a
model
that
reminds
you
of
anything
that
you've
seen
you're,
not
alone
hierarchies
crush
the
ideas
and
voices
out
of
groups
that
have
every
right
to
do
great
work.
A
So
if
we
think
that
one
brilliant
person
at
the
top
can
make
all
the
decisions,
we
can
then
start
to
find
things
like
slow
decisions,
frustration,
a
decision,
backlog,
undiscussables,
passive
aggression.
So
perhaps
you
need
an
inversion
of
control.
Perhaps
you
can
Conway
your
way
out
of
the
chaos
and
turn
it
upside
down
and
say
what
we
need
is
leadership
by
the
most
curious.
A
What
we
need
is
systems
that
support
lots
of
high-performing
groups
acting
with
high
fidelity
with
high
autonomy
and
high
alignment,
so
leadership
by
the
mores
curious
rather
than
leadership
by
the
most
vocal,
so
speed
does
come
from
these
small,
complete,
empowered
teams
moving
at
speed.
I
think
the
cool
thing
about
how
we
built
software
today
is
our
interconnectedness,
so
the
flow
of
ideas
across
boundaries,
the
flow
of
information
across
api's,
the
mesh
of
services
that
support
our
work
by
building
up
from
the
smallest
coherent
units.