►
From YouTube: Webinar: Lean DevOps: Building a Culture of Delivery
Description
Often DevOps is portrayed as extremely complicated, making it challenging to understand for organizations who want to support their growing technical teams.
Kyle Campbell (@slajax), Founder and CEO of CTO.ai breaks it all down into a practical approach to building a culture of delivery using a “Lean DevOps” methodology.
In this talk, Kyle tackles how to select the tools your team will need, organizational standards for efficiency, adaptability as a best practice, and management of speed vs stability.
Help your team get the most out of their time and talent!
Presenter:
Kyle Campbell, Founder and CEO of CTO.ai
A
Who
writes
I
think
we
can
go
ahead
and
get
started?
Okay,
so
I'd
like
to
thank
everyone.
Who's
joining
us
today.
Welcome
to
today's
CN
CF
webinar
on
lean
DevOps
building,
a
culture
of
delivery.
My
name
is
teri
Lee
I'm,
the
lead,
DevOps
consultants
at
Media,
Consulting
and
CN
CF
ambassador.
They
see
in
Chinese
burg,
South
Africa,
so
I'll
be
moderating
today's
webinar
and
we
would
like
to
welcome
our
presenter
today
call
Campbell
a
CEO
and
founder
at
CTA
I.
A
So
before
we
get
started
just
a
few
housekeeping
items
during
webinar,
you
are
not
able
to
talk
as
an
attendee.
There
is
a
Q&A
box
at
the
bottom
of
your
screen,
so
please
feel
free
to
drop
your
questions
in
there
and
we'll
get
to
it
as
many
as
we
can
at
the
end,
and
please
know
that
this
is
an
official
webinar
of
the
CNC
F
and
as
such
it
is
subjected
to
CN
CF
s--
code
of
conduct.
A
B
Who's
who's
joined
the
call
the
webinar
here
so
just
as
we
get
started,
I
want
to
make
sure
that
I
set
some
expectations
about
what
you
can
get
out
of
this
talk.
This
is
not
necessarily
a
technical
talk,
so
if
you
were
looking
for
more
technical
details,
we're
not
going
to
be
diving
into
any
command
line
today,
but
I
do
have
a
follow-up
talk
that
I'm
working
on
to
try
to
communicate
some
of
these
concepts
in
a
more
technical
way.
B
B
As
a
software
engineer
and
an
entrepreneur
I
drop
to
the
high
school
to
pursue
tech,
I
started
my
career
in
the
very
early
shared
hosting
days
working
for
companies
like
host
Opia,
which
is
white
label
shared
hosting
back
in
2002
2003
for
telcos,
and
so
I've
watched
DevOps
evolve
from
this
early
days
of
sort
of
FTP
into
where
we
are
now.
I've
also
spent
an
equal
amount
of
time
in
my
career
on
the
front
end
and
the
back
end.
B
So
a
little
bit
about
CTO
today,
I
just
said
that
you
understand
what
we
do
and
why
this
is
such
an
important
thing
to
us.
We
provide
a
platform
that
enables
developers
to
create
and
share
workflow
automation
with
leaving
the
command
line.
The
idea
is
you
build
this
workflow
and
it's
using
a
container.
The
container
then
works
in
anybody's
CLI,
but
also
in
slack
sort
of
an
isomorphic
workflow
is
how
we
think
about
it.
You
can
publish
it
to
our
platform.
B
It's
instantly
available
to
your
whole
team,
which
means
that
senior
engineers
can
now
help
junior
engineers
who
are
joining
the
team
be
more
effective.
This
helps
the
business
because
you're
able
to
get
access
to
a
broader
base
of
talent
and
aren't
competing
for
talent
as
much
and
at
the
end
of
the
day.
What
we
advocate
a
lot
is
for
DevOps
engineers,
a
senior
engineers
to
be
a
bit
of
a
call,
10x
multiply
or
10x
engineer.
It's
not
one
person
who's
10
times
than
anyone
else.
B
It's
an
engineer
who
helps
by
people
be
two
times
more
productive
using
technology.
So
what
is
DevOps
I'm
going
to
just
frame
this
out
of
the
gate
so
that
my
views
are
understood?
I
subscribe
quite
directly
to
some
of
the
things
that
AWS
says:
DevOps
is
philosophies
best
practices
and
tools,
I
like
to
think
of
it.
In
that
order,
my
belief
is
that
the
tools
exist
to
immortalize
the
philosophies
and
best
practices
of
your
team
and
I.
Think
often
a
lot
of
times
we
read
that
book
backwards.
B
We
start
with
the
tools
and
then
we
try
to
work
towards
the
philosophies
and
best
practices,
but
I
like
to
clarify
that
out
of
the
gate,
because
it
really
informs
why
I
start
with
the
idea
of
building
a
culture
of
delivery
and
then
work
towards
tools
in
how
I
think
about
this.
And
obviously
we
all
know
the
the
impact
200
times
more
frequent
software
deployments
and
a55
faster
lead
times
or
2555
faster
of
lead
times.
B
One
of
the
the
reports
that
I
often
will
point
to
you,
also
at
the
same
time
when
quoting
these
things
that
we
I
think
we
mostly
all
know,
is
I'm.
A
report
called
the
developer
coefficient
by
stripe,
which
goes
on
to
touch
on
maybe
the
less
glamorous
side
of
DevOps.
It
says
things
about
like
there's:
300
billion
dollars
lost
every
year
in
developer
productivity
in
large
part
due
to
the
legacy
software,
but
also
complex
tools.
B
But
more
importantly,
it
really
highlights
the
interest
in
the
needs
of
DevOps
and
organizations
and
I
think
this
quotes
really
great.
It's
not
just
how
many
devs
a
company
has
it's
also,
probably
being
leveraged,
and
so
that
goes
back
to
that
multiplier
that
we
can
see
when
we
use
DevOps
so
setting
the
frame
as
I
advocate
for
early
stage
and
early
stage
with
DevOps
the
early
stage
of
a
business.
The
early
stage
of
a
team
has
lots
of
challenges
and,
let's
just
go
through
them.
Real
quick
I've
been
through.
B
B
You
know
most
of
the
innovative
tech
that
that
these
early-stage
businesses
are
implementing
is
quite
time-consuming
and
complex
for
them
to
wrap
their
head
around
and
ultimately
in
early-stage
business.
You
just
never
have
enough
money,
especially
if
you're
on
the
venture
track,
because
you're
always
working
against
some
runway,
and
so
it's
hard
to
just
spend
more
money
to
get
more
efficiency,
because
you
really-
and
so,
when
you
think
about
DevOps,
it
really
can
act
as
a
differentiator
and
how
companies
implement
their
success.
B
So
the
current
state
of
DevOps
is
that
it
is
fragmented
across
many
different
tools
and
technologies.
Developers
have
been
tasked
with
workflow
automation
and
it
burns
valuable
time
that
could
be
used
for
shipping
features
that
customers,
love
and
I've
got
my
little
guy
with
me
here
guys,
so
we're
just
gonna
try
and
work
through
this
right
now.
B
You
just
jumped
into
my
office,
and
this
is
kind
of
what
it
looks
like
I
mean
and
where
this
doesn't
even
dig
into
the
huge
amount
of
open-source
tools
that
are
now
coming
out
of
the
CNC
F
and
the
kubernetes
ecosystem.
But
when
you
think
about
this,
it
can
be
quite
overwhelming
for
a
developer
to
think
about
how
to
be
efficient
across
this
many
tools
right.
B
Many
companies
struggle
to
adopt
I
lost
best
practices
and
DevOps
tools
are
more
complex
than
ever
before
and
as
a
result,
what
I
think
is
that
most
startups,
it
can
feel
like
a
snake
swallowing
an
elephant.
So
how
do
we?
How
do
we
tackle
this?
How
do
we
make
it
easier
for
these
very
powerful
tools
to
be
available
in
earlier
stage
businesses
and
actually
realize
their
full
potential?
B
Devops
evolves
over
time,
and,
what's
really
clear
to
me
from
being
at
different
stages
of
businesses,
is
they're
sort
of
this
adoption
curve.
That's
really
important
to
understand
when
you're
thinking
about
implementing
a
DevOps
culture
early
days,
you
start
off
with
a
smaller
team,
and
the
number
of
developers
is
quite
low
with
the
DevOps
efficiency
or
the
inefficiency
is
also
low.
So
your
efficiency
is
high.
B
B
So
what
do
we
need
to
do
in
the
beginning
as
we're
considering
the
process
by
which
we
implement
DevOps
over
time
early
on
you're
flat?
You
got
a
Kanban
based
organization
if
you
evolve
into
more
of
a
matrix
or
agile
driven
organization
and
what
I
think
a
lot
about
when
I'm
adopting,
DevOps
and
organization
is
how
do
I
realize
that
this
is
the
journey
that
I'm
going
on
and
how
do
I
adopt
things
in
time
based
on
the
organization's
needs
when
I
frame
it
like
this
for
people
I?
B
Think
one
of
the
things
that
I've
seen
with
engineers
is.
It
really
puts
the
whole
journey
in
context
and
it
helps
people
to
not
too
obvious
Lee
like
be
mindful
of
things
like
security,
compliance
or
governance
and
policy,
but
obviously
like
front-loading
that,
in
your
journey
to
adopting
an
end-to-end
devops
toolset
can
be
quite
challenging
because
in
a
flattened,
Kanban
organization,
information
flows
very
differently
than
in
a
matrix
or
agile
oriented
organization.
B
The
technical
leaders
who
are
building
tools
and
supporting
engineering
teams
know
that
it's
critical
to
invest
into
the
workflow
that
their
team
requires
to
work
and
by
workflow
I
also
just
mean
generally
tools,
but
it
can
often
be
too
time-consuming,
especially
in
the
early
stage,
addict
locate,
critical
resources
to
doing
it
right.
So
how
do
you?
How
do
you
survive
in
that
situation?
For
us,
the
way
we
try
to
do
it
is
is
make
it
easy
to
automate
automation
and
intelligence
into
a
workflow.
B
We
do
this
with
something
that
we
call
ops,
which
are
essentially
an
end
end
operation
that
allows
anybody
to
automate
a
thing
very
quickly
and
that
sort
of
creates
an
experience
across
the
developer
lifecycle.
That's
quite
consistent.
We've
also
tried
to
make
it
very
accessible
across
the
command
line
slack
but
also
see
ICD.
So
these
things
that
we
offer
on
our
platform
called
ops
are
essentially
these
developer.
Workflow
developer
experiences
that
can
bridge
the
interfaces
that
developers
use
and
someone
who's
more
technical
can
adopt
tools
at
the
CLI
level.
B
Someone
who's,
less
technical,
might
adopt
it
at
the
slack
level.
But
ultimately,
what
we
try
to
do
and
the
key
thing
here
that's
a
win.
Is
we
try
to
abstract
a
lot
of
that
complexity
behind
the
scenes
so
that
the
developer
can
just
stay
focused
on
the
task
at
hand
and
they
don't
end
up
going
down
a
deeper
rabbit
hole
trying
to
work
with
the
tools
than
they
do
with
solving
the
actual
key
feature
that
they're
trying
to
deliver.
B
I
think
when
you,
when
you
approach
your
your
tooling
in
that
perspective,
when
you
start
with
philosophies,
you
start
with
best
practice
and
you
moralize
them
into
your
tools
and
you
deliver
them
in
a
very
accessible
format
to
your
team,
whether
it's
CI
CD,
whether
it's
get
ops
or
chat,
ops,
whether
it's
your
CLI.
Ultimately,
you
now
have
that
leverage
point
that
we
were
talking
about
earlier
and
that's
what
enables
you
to
sort
of
10x
your
team
and
that
one
developer
can
make.
B
So
this
brings
us
to
this
idea
of
like
building
this
culture
of
delivery
and
there's
a
number
of
things
that
I've
tried
to
really
embrace,
as
I've
learned
these
lessons
over
over
time,
I
think
as
an
organization
grows,
it's
really
easy
to
add
more
process,
wrap,
add
more
tools,
add
more
complexity,
but
in
doing
that,
you
ultimately
are
taking.
What
I
think
is
the
ease.
B
What's
harder
is
to
try
to
stick
with
simplicity,
longer,
try
to
stay
mean
or
longer
sure
to
add
less
complexity,
longer
I
think
that
really
takes
a
level
of
intention
and
really
thoughtfulness
to
to
to
do
that
and
I
and
I
think
that's
often
the
harder
path
and
I
really
try
to
encourage
people
to
do
that.
There's
been
thought
leadership
on
this.
For
a
long
time,
people
like
Dan
McKinley,
who
talked
about
choosing
boring
technology,
the
idea
being
that
you
have
three
innovation
tokens
spend
them
wisely.
B
If
you
spend
it
on
your
database
or
on
how
you
deploy
an
application,
you
don't
have
that
innovation
token
to
spin
spend
in
other
places
like
a
customer
facing
or
business
facing
item.
So
to
me
in
my
in
my
in
my
mind,
a
lot
of
things
in
DevOps
should
be
relatively
boring.
That
doesn't
mean
they
should
not
be
enjoyable
to
use,
but
they
should
be
easy
enough
to
use
that
they
feel
like
a
commodity.
B
The
other
thing
that
I
think
a
lot
about
is
how
do
you
set
expectations
for
people
who
are
joining
your
team,
whether
it's
at
the
early
stage
of
the
later
stage,
the
more
complexity
you
add
the
longer
it
takes
for
somebody
to
deploy
code,
the
experience
that
they
have
setting
up
your
tools
really
dictates
to
them.
One
of
the
philosophies
and
best
practices
are
therefore
the
expectations
in
this
company,
so
in
most
startups
that
I've
worked
in
or
started.
B
We
also
have
a
hard
time,
sometimes
clearly
articulating
what
the
impact
of
a
contribution
might
be
so
like
what
would
the
impact
be
if
I
go
and
automate
this
get
off
the
pipeline.
So
what
I
really
try
to
encourage
engineering
teams
to
do
is
not
just
estimate
things
but
actually
communicate
a
more
complex
model
for
how
they
communicate
priority
and
I.
B
Think
of
this,
as
prioritizing
your
best
work,
what
I
like
to
try
to
get
people
to
do
is
communicate
impact
Plus
confidence
divided
by
effort,
because
if
you
can
communicate
the
impact
that
something
has
and
the
confidence
that
you
have,
that
it
will
reach
that
point
of
impact,
and
you
divide
it
by
your
effort.
You
get
something
that's
much
more
valuable
than
a
story
point.
B
You
have
a
very
different
level
of
needing
to
operate
and
monitor,
obviously,
post
market
fit
or
in
a
mature
organization
that
maybe
is
a
higher
priority,
but
I
think
when
I
visualise
DevOps
and
lean
DevOps
in
this
format
on
the
right.
It
sort
of
helps
you
to
create
this
cyclical
journey,
where
you're
starting
your
first
trying
to
get
a
full
loop
and
then
you're
reinvesting.
So
you
start
with
committing
then
you're
reviewing
code
provisioning
servers,
delivering
servers.
B
You
need
to
build,
manage
incidents
once
you
have
them
in
users
and
you
need
to
measure
things
whether
it's
in
the
the
product
or
it's
in
the
system.
Now
you
need
to
reinvest
in
that
curve.
How
do
we
make
commits
and
then
review,
and
then
provision,
delivery
and
I?
Think
one
of
the
the
fallacies
about
DevOps
people
kind
of
think
like
you
set
it
up?
B
It's
done,
but
it's
a
continuous
investment
and
the
more
that
we
can
communicate
that
I
think
the
easier
it
is
for
businesses
to
justify
the
costs
and
improving
the
efficiency
of
their
engineering
teams
by
further
investing
into
DevOps.
So
I
think
part
of
what
we
need
to
work
on
as
a
dev
community
is
just
how
we
communicate
our
priorities,
whether
it's
ice
or
how
do
we
communicate
the
the
investments
that
we're
making
an
impact
that
it
has
in
the
business?
B
Another
thing
that
factors
into
this
is
how
an
organization
structure
is
set
up
and
sometimes
we
we
may
or
may
not
have
control,
or
this
is
how
this
is
organized.
It
may
be
something
that
we
can
organize
within
an
engineering
team
or
a
DevOps
organization,
but
it
also
may
be
something
that's
set
more
broadly
in
the
business,
but
it's
just
important
to
understand
that
evolution
as
I
talked
about
earlier
see
of
your
eyes
wide
open
early
on.
You
have
a
flat
organization.
Communication
is
very
easy:
have
cross-functionally
people
work
very
independently?
B
B
This
team
over
here
is
focusing
more
on
this
part
of
the
system
and
I
think
figuring
out
how
to
maintain
a
level
of
cross-functional
consistency
across
these
different
groups
is
a
really
hard
challenge
when
it
comes
to
building
a
culture
of
delivery
because,
as
an
organization
grows,
it's
usually
not
the
tools
that
break
down.
To
be
honest
with
you,
it
is
the
philosophy
and
the
best
practices
it's
how
we
communicate
about
our
expectations
and
how
we
understand
that
you
know
this
organization.
This
team
over
here
is
doing
this.
This
team
over
here
is
doing
this.
B
Those
two
things
are
different.
Well
now
we
have
a
massive
context,
switch
between
those
two
things
and
a
fragmentation
of
how
we
think
about
doing
software
development
that
doesn't
mean
to
me
that
we
need
everything
to
run
in
exactly
the
same
way.
We
need
to
control
the
you
know
the
highest
common
denominator,
but
I
do
think
it's
about
making
sure
that
if
there
are
new
ideas
emerging
in
the
organization,
those
things
can
flow,
especially
if
they're
a
net
order
improvement
on
investing
into
these
workflows
that
we
use
to
deliver
software.
B
A
good
example
of
this
that's
rooted
in
data
is,
is
ultimately
security,
and
so
you
know
the
2019
stay
a
DevOps
report.
We
pulled
some
data
from
that
and
we
looked
through
this
to
try
to
really
find
data
that
suggests
that
there's,
there's
big
changes
happening
and
you
know
still
50%
of
organizations,
have
a
centralized
security
function.
That
makes
sense
to
me
like
security,
especially
in
large
organization,
is
a
deep
specialization.
B
I
think
that
this
is
sort
of
more
of
a
like
everybody
is
involved
in
security
and
when
you
think
about
that
extreme
there's
a
there's,
definitely
a
need
to
like
pollinate
information
like
what
are
your
security
best
practices?
How
did
this
get
implemented
in
a
centralized
model?
If
you
just
go
hey
all
of
our
security
function,
that
happens
within
the
pipeline
and
the
pipeline
is
what
analyzes
our
security
and
you
basically
create
kind
of
a
black
box
for
the
rest
of
the
organization.
B
But
if
you
have
a
more
distributed
model
that
where
information
can
flow,
it
helps
people
to
understand
like
what's
happening
and
why
we're
implementing
these
security
procedures-
and
this
brings
us
to
sort
of
the
the
latus
organization
structure.
So
a
way
to
think
about
this
in
the
public
domain
would
be
some
of
the
things
that
Spotify
put
out
there,
but
how
they
organize
their
their
company
and
their
engineering
teams.
More
recently,
there's
been
feedback
on
this
that
talks
about
its
compromises
and
drawbacks
as
well.
B
I
think
that's
really
good,
because
there's
obviously
no
no
one-size-fits-all
way
to
build
a
successful
company,
but
I
think
the
benefit
of
this
approach
that,
especially
in
the
early
and
mid-stage
is.
You
can
ultimately
have
sort
of
this
vertical
ization,
as
we
highlight
in
green,
which
is
aligned
with
sort
of
business
units
that
might
have
strategic
goals
that
are
relevant
to
let's
say
product
or
relevant
to
a
section
of
the
business
horizontally.
B
But
I
really
encourage
people
to
think
this
through,
because
it's
really
important
to
how
we
communicate
philosophy
and
best
practices.
I
think
tools
are
a
big
part
of
how
we
immortalize
them
and
translate
our
expectations,
but
there's
a
lot
that
can't
be
translated
in
the
tool.
Obviously-
and
this
is
why
we
have
so
many
zoom
meetings,
so
the
the
technology
and
processed
habit
fix
really
matter
and
there's
a
lot
of
different
ways
to
approach
it.
B
I
went
through
a
few
that
I
see
out
there,
but
I
think
there's
some
like
really
core
things
that
you
need
to
just
focus
on.
You
know.
So
there's
no
silver
bullet
that'll
offer
you
on
this,
but
there
are
some
things
that
I
really
value
when
I'm
building
a
team
and
scaling
a
team
for
me,
tooling
enables
less
technical
team
members,
maybe
junior
team
members
to
be
given
more
responsibility,
which
creates
less
burden
on
senior
members.
So
the
more
you
can
like
start
there
and
figure
out.
B
How
do
you
translate
the
philosophy
and
best
practices,
so
it's
accessible
by
others.
I
think
you're
really
hitting
an
important
point.
If
that's
your
primary
goal,
secondarily
I
think
you
have
to
be
mindful
of
what
the
long-term
looks
like
and
I
think
you
need
to
start
with
strategies
and
focus
that
on
high
velocity,
because
high
velocity
is
much
harder
to
get
as
if
you
start
with
low
velocity,
it's
much
easier
to
get
to
much
easier
to
start
with
a
higher
velocity
and
then
slowly
lose
some
velocity
over
time.
B
B
A
negative
correlation
between
the
work
we
do
sometimes
and
the
productivity
of
an
organization.
Our
goal
is
trying
to
maintain
a
focus
on
this
velocity
as
we
leverage
more
DevOps
tools,
and
this
is
why
I
advocate
for
being
DevOps,
because
I
think
it's
one
of
the
most
important
correlating
factors
in
the
end
result
of
the
work
that
we
do
in
DevOps,
because
it
kind
of
looks
like
this
if
I
were
to
just
summarize.
B
So
what
we
have
is
velocity
on
the
left
and
the
amount
of
process
complexity
on
the
right
as
you
adopt
more
process
and
ultimately
people
you
have
velocity
in
green,
which
is
diminishing
over
time.
The
point
of
you
know
we
say
CTO
today,
but
just
DevOps
and
lean
DevOps
in
general
is
to
try
to
sustain
that
velocity
longer
and
I.
Think
if
you,
if
you
factor
in
that
model
into
how
you
think,
through
your
DevOps
strategies,
you
really
have
a
robust
framework
that
can
scale
it's.
B
What
worked
well
early
and
scale
into
a
growth
model
very
adaptable
and
I.
Guess,
that's
that's
the
whole
point
I'm
trying
to
communicate
is
it
should
be
adaptable,
but
it
also
should
be
very
accessible
because
the
number
one
thing
is:
how
do
I
get
access
to
the
tool?
I
need
to
achieve
the
thing
I
need
and
the
tool
is
just
the
means
to
the
end.
B
So
this
is
where
I
don't
offer
like
a
concrete
conclusion.
Unfortunately,
because
there
is
no
perfect
process,
I'm
not
going
to
tell
you
exactly
how
to
do
DevOps
and
that's
why
I
didn't
start
with
a
technical
talk
here,
because
what
I'm
trying
to
communicate
and
what
I'm
trying
to
advocate
for
are
a
lot
of
things
that
actually
don't
start
with
tools,
but
I
do
think.
Tools
are
important
part
of
the
process
of
heard
part
of
the
tactics.
So
when
you
think
about
tools,
they
enable
bottom-up
adoption
and
they
can
create
top-down
transparency.
B
I
mean
that
is
a
big,
important
thing,
but
they
immortalizes
they've
said
the
philosophy,
the
best
practices.
As
you
start
breaking
out
your
organization
into
different
specializations.
It
can
be
an
advantage
to
maintain
a
flat
organization
longer
so
think
through
really
hard.
When
you
start
breaking
out
teams,
is
this
what
we
need,
and
or
is
that
going
to
create
an
amount
of
overhead
or
a
level
of
fragmentation
and
communication
philosophy,
best
practices
and
tools
that
adds
an
exponential
overhead
to
that
business?
B
When
is
the
right
time
to
do
this
most
times,
I've
seen
organizations
start
to
do
this
as
sort
of
25
engineers
and
then
again
at
you
know,
maybe
40
or
50,
and
then
from
there
it's
kind
of
really
different
based
on
how
people
work.
But
the
most
important
thing
is
because
every
organization
is
different
is
you
have
to
be
adaptable,
and
so
should
you
tools?
You're
gonna
have
to
evolve
best
practices
along
the
way.
B
You've
got
to
be
kind
of
your
future
self
being
think
through
one
of
the
things
that
you're
gonna
have
to
tackle
later,
but
try
not
to
front-load
all
of
the
solutions
and
what
I
think
is
really
important
is
to
be
able
to
throw
away
code
and
like
as
engineers.
We
often
don't
want
to
do
that,
because
it
might
communicate
that
that
code
failed.
B
But
if
we
can
normalize
that
idea
with
an
organization
that
right
is
building
for
right
now
and
sometimes
right
now
is
not
the
thing
we
need
in
a
year
or
two
years
from
now.
What
it
does
is
gives
us
permission
to
evolve
as
we
go
and
not
carry
forward
our
assumptions.
So
I
try
to
communicate,
always
retest
those
assumptions
about
what's
working
and
what's
not
and
give
yourself
as
much
permission
as
you
can
to
throw
away
code
and
then,
as
you're
growing
like
one
of
the
key
things
here.
B
Stability
is
very
important
as
a
business
gets
to
scale
as
its
robust
and
its
predictable,
because
you
need
to
have
that
predictability
to
evolve
from
the
premise
but
early
on
adaptability
in
the
velocity
to
get
to
that
level
of
stability
is
also
very
important,
and
I
can't
count
how
many
teams
I've
seen
fail
in
the
early
stage,
because
they
think
the
goal
is
to
build
for
stability
before
they
actually
really
understand
what
their
for
stability
and
they
don't.
Leverage.
B
The
leaner
side
of
DevOps
as
an
advantage
early
on
so
the
more
you
can
do
that
I
think
the
better
you're
able
to
grow
with
your
DevOps
strategy.
So
my
takeaway,
my
the
thing
that
I'm
advocating
a
call
to
action
for
all
DevOps
engineers
in
the
cns
EF.
Is
this
idea
of
accessibility
and
intuitive
developer
tools
I
like
to
frame
this
around
the
idea
of
like
who
are
you
10
Xing?
B
B
A
Awesome
thanks
Carl
for
the
fantastic
presentation,
so
we
do
have
some
time
now
for
questions.
You
have
a
question
that
you
would
like
to
ask.
Please
drop
it
in
the
Q&A
section
at
the
bottom
of
your
screen
and
then
we'll
get
to
them.
So
I
see
that
there
are
two
questions
currently
so
the
first
one
is
from
David
and
David
is
very
interested
in
hearing
more
about
your
experiences
and
tips
with
regards
to
maintaining
a
cross-functional
consistency
across
teams
and
avoid
information
silos.
So
great.
B
Question
Jeannette
mm-hmm,
probably
the
hardest
thing:
it's
I
think
it's
the
hardest
challenge,
I,
don't
think!
There's
any
challenge
harder
than
this
in
what
we
do.
I
don't
have
a
clear
answer
for
how
to
solve
this.
In
a
situation
where
there
exists
a
lot
of
what
I
think
of
as
communication,
debt
or
expectation,
debt
or
process
debt
I
mean
there's
all
these
other
forms
of
debt
that
we
carry
forward.
B
That
is
the
number
one
thing
that
I've
seen
reduce
the
friction
that
you
can
feel
it
a
later
stage.
I
think
when
you
get
to
that
point
and
you
suddenly
see
the
forest
through
the
trees
you're
like
oh
man,
you
have
all
of
this.
These
information
silos
there's
a
lot
of
approaches.
You
can
take
that
I
think
are
helpful,
but
don't
necessarily
are
hard
to
implement
hard
to
influence
change,
and
this
is
why
we
have
things
like
digital
transformation.
That
happened.
B
B
You
know
certainly
I
think
see.
Icd
is
good.
I
think
the
thing
that's
the
most
important.
There
is
just
generally
accessibility
and
observability
and
transparency.
So
this
is
one
of
the
things
that
we
think
things
like
chat.
Ops
is
just
really
good
for
out
of
the
gate
and
obviously
chat
is
not
a
silver
bullet
like
it
does
certain
things
better
and
you
know
get
ops,
does
certain
things
better,
but
the
more
you
can
make
your
your
workflows
observable
like
default,
the
more
you
can
make
them
inclusive
by
default.
B
The
more
that,
on
that
first
day,
that
engineer
can
look
and
see.
Here's
how
somebody
did
that
the
less
they
have
to
then
go
dig
and
find
the
information.
It's
just
a
more
organic
way
to
surface
this
context
and
I
think
these
are
strategies
that
tend
to
work
really
well,
but
they're,
hard
to
implement
and
I
think
we
need
to
make
them
easier
to
I
think
by
default.
B
B
That
doesn't
mean
give
up
if
you're
at
the
later
stage
and
you're
already
at
this
point,
it
just
means
you
need
to
be
probably
more
thoughtful
and
ready
to
give
ready
to
achieve
more
buy-in
to
make
change
and
so
executive
stakeholders
are
super
key
in
that
kind
of
piece
and
that's
why
I
talk
about
trying
to
surface
how
we
communicate
about
our
KPIs
and
our
goals
in
a
slightly
different
format,
because
I
think
they
translate
a
little
bit
better
to
the
business
world
and
then
they're
easy
to
get.
You
know
stakeholder
buying
it
on
cool.
B
B
What
we
were
trying
to
do
is
like
make
systems
more
accessible,
so
devs
could
access
ops
and
B
and
therefore
DevOps
and
I
think
what
role
that
the
ops
team
plays
in
this
is
really
that
call
to
action
and
that
obligation
that
I
was
describing
about.
How
do
we
make
the
system
as
intuitive
as
possible,
whether
it's
the
CI
CD
system
or
it's
some
other
method
for
like
getting
access
to
logs?
How
do
we
make
it
as
easy
to
access
that
as
possible?
B
I
think
that's
the
obligation
of
the
ops
team
as
they
think
about
the
devs
as
their
customers,
their
internal
customers
and
I
think
prioritizing
the
needs
to
the
developer
and
understanding
like
what
is
their
endgame.
What
do
they
want
to
get
to
and
how
do
I
get
them
there
as
quickly
as
possible
without
them
having
to
take
on
all
the
knowledge
that
I
spent
the
last
10
years
doing
I
think
that's
the
role
ultimately
of
DevOps,
especially
if
you
think
about
it,
implemented
from
the
oxide
of
the
equation.
B
B
The
idea
is
you
build
this
command
line
and
you
write
it
with
our
SDK.
The
command
line
is
just
a
docker
file,
so
you
can
kind
of
think
Heroku
for
developer.
We're
close
once
you
build
it
and
you
publish
it.
It
doesn't
just
run
and
everyone's
command
line
with
them,
having
to
think
about
environment
variables,
and
all
these
other
things
also
runs
in
slack.
So
you
get
chat
ops
for
pretty
much
for
free
when
you're
building
your
command
lines
and
what
we
think
this
does.
B
Is
it
both
drives
down
the
cost
of
automating
things
and
taking
the
knowledge
out
of
your
brain
as
the
ops
person,
and
it
makes
it
very
easy
to
make
it
accessible
and
intuitive,
because
now
it
doesn't
just
run
through
slack,
it
also
earth
through
the
CLI.
It
also
runs
through
slack,
which
means
you
can
automate
away
a
lot
of
those
things
that
were
your
dependencies
on
you.
It
doesn't
replace
your
traditional
CICP
system,
necessarily
it's
a
container,
though
so
you
can
run
anything
you
want
in
it.
You
can
put
your
tariffs
or
scripts
in
there.
B
Your
bash
scripts,
like
whatever
tools
you
use,
you're
the
expert
I,
don't
I'm
not
here,
to
tell
you
how
to
implement
your
technology.
What
we're
trying
to
do
is
like
bring
down
the
cost
of
distributing
this
knowledge
out
of
the
specialists,
brain
into
the
form
that
the
generalists
can
access
them
and
reduce
the
burden
on
the
DevOps
heroes.
We
are
helping
us
all
ship
software
right.
A
B
Question
I
think
we
often
get
confused
with
CIC
V,
maybe
because,
like
an
OP
is
the
container
and
you
can
like
execute
it
in
many
different
ways,
we
don't
really
see
ourselves
as
a
CI
CD
solution.
We
see
as
ourselves
as
a
framework
for
building
a
developer
experience,
that's
accessible
and
measurable.
So
one
of
the
things
I
didn't
talk
about
is
when
you
write
these
workflows.
B
We
also
have
not
just
12
like
a
set
of
frameworks
and
SDKs
for
the
12
factor,
principals
secrets
configurations:
you
can
also
store
events
and
metrics,
so
we
try
to
layer
on
top
of
existing
tools.
You
know
lightweight
way
so
that
you
can
automate
across
your
your
tool
chain
with
some
level
of
consistency.
As
a
result,
I
guess
there's
overlap
with
some
of
the
things
that
the
CI
CDs
companies
are
doing.
There's
overlap
with
some
of
this.
What
I
think
of
as
like
the
rise
of
the
workflow
and
I?
B
Think
the
intention
behind
that
is,
here's
a
set
of
tools
that
you
can
use
to
implement
your
ideas,
bottom-up
and
drive,
transparency,
top-down,
but
I
think
we're
unique
in
how
we
think
about
it,
because
we're
really
focused
on
the
idea
that
you
can
build
the
CLI,
which
is
typically
how
we
automate
all
the
other
things
and
CLI
and
then
and
then
from
there.
The
CLI
also
works
in
slack
I.
B
Think
there's
a
lot
of
things
that
developers
do
which
doesn't
just
fall
into
the
existing
CICP
paradigm.
Things
like
getting
access
to
logs.
You
know
running
that
report.
For
you
know
a
product
manager
against
like
who
logged
in,
like
you
know
some
of
the
migration
stuff
that
we
do
is
not
great
inside
of
CI
CD.
To
be
honest
with
you,
you
know,
I
think
CI
CD
tends
to
be
in
some
cases.
It
is
a
single
point
of
command
in
control,
which
is
great
but
I.
B
Think
of
this
two
remote
world,
more
and
more
of
that
control
plane
and
how
we
think
about
where
we
jump
off
to
start
our
day,
where
we
jump
off
to
do
our
work
and
have
where
we
communicate
and
collaborate
more
and
more
I
think
it's
moving
to
slack.
So
we're
really
trying
to
take
this,
like
slack
first
mindset
of
how
developers
do
work
and
we
don't
think
of
ourselves
as
like
a
chatbot
but
we're
more
chat
first
or
chat,
free,
I,
guess
in
how
we
think
about
enabling
you
to
build
out
your
developer,
workflow.
B
A
B
So
I
do
think
that,
like
the
rise
of
depth
at
SAC,
ops
is
like
great
because
it
reduces
the
burden
on
the
generalists
to
have
to
observe
all
of
the
deep
knowledge
of
the
security
specialists
and
we're
using
tools
to
distribute
that
knowledge
and
a
process
driven
way
to
embrace
best
practices.
So
I
think
it's
one
of
the
new
trends.
Certainly
that
is
finding
that
balance
between
stability
and
velocity,
because
it's
unintrusive
and
it's
typically
quite
intuitive.
B
You
check
your
code
in
it
runs
some
sort
of
security
scan
and
then
you
get
an
output
and
then,
if,
like
you're
blocked,
you
need
to
now
go
context,
switch
and
figure
out.
Why
dabble
like
that,
but
I
think
there's
still
more,
that
can
be
emerging
from
this
field
to
make
it
even
more
intuitive
because
I
don't
think
it's
quite
enough.
Just
yet
to
say
all
right:
well,
you
failed
the
security
policy
right
and
like
now
you
have
to
go
figure
that
out
I.
B
A
B
B
Yeah
well,
digital
transformation
is
definitely
not
it.
I
saw
a
great
slide
about,
like
you
know
what
prompted
and
catalyzed
digital
transformation
in
my
organization,
the
CTO,
the
CIO
or
kovat
&
Co.
It
had
a
checkbox
in
it.
I
think
you
know,
while
I
don't
want
to
make
light
of
any
of
the
suffering.
That's
happened
here
with
as
a
result
of
this
I
do
think,
unfortunately,
like
the
catalyst
and
maybe
I'll
just
is
it
okay?
B
If
I
just
stop
my
screen
share
here:
Harry
yeah,
yeah
cool,
so
I,
one
of
the
things
that
I
think
is
like.
Unfortunately,
one
of
the
things
that
is,
that
catalyst
is
often
it's
often
some
unfortunate
situation
and
and
more
often
than
not
it's
like.
There
was
a
security
incident.
There
was
some
downtime,
a
third-party
vendor
didn't
meet
SLA
or
something
like
this.
You
know
and
there's
a
lot
of
other
things
that
sort
of
like
permeate
up
to
this
sort
of
like
challenge.
B
Where
then,
like
management
leadership
is
now
in
this
mindset
of
like
okay,
this
bad
thing
happened.
We
need
to
mitigate
that
and
I
think
that's
awesome,
it's
just
too
late
right,
and
so
this
is
where
I
try
to
like
tell
this
story
from
the
earlier
stage,
because
I
recognize
as
we
get
to
the
later
stage,
those
catalysts
are
actually
really
hard
to
create
there.
It's
not
clear
to
me
what
is
a
consistent
set
of
cattle
isms
I
think
that
the
mainstream
adoption
of
DevOps
is
definitely
one
of
those
things.
B
That's
helping
organizations
that
move
to
cloud,
but
these
things
are
really
slow,
so
they
happen
over
long
period
of
time.
I
think
the
things
that
we
have
more
control
over
is
how
we
tell
the
story
how
we
advocate
for
the
interest
of
our
teams,
how
we
create
that,
like
shared
set
of
conversations
across
an
engineering
group,
to
advocate
that
how
we
start
speaking
the
language
of
business
and
how
we
advocate
it
so
like.
B
If
you
go
to
us
chief
revenue
officer,
they
don't
understand
what
it
means
to
say
like
I
need
to,
like
you
know,
scale
the
kubernetes
cluster
or
something
like
that.
They're.
Just
like
okay,
you're
gonna,
add
more
servers
like
that
should
be
just
done
right.
But
if
you
frame
it
like
hey,
here's
our
what's
a
door
metrics
and
here's
the
result
of
how
things
are
getting
slowed
down.
And
if
you
want
things
delivered
on
time,
we
need
to
move.
B
This
number
I
think
that's
you're,
getting
closer
to
speaking
that
language,
because
I
mean
a
sales
team
is
very
data-driven,
a
marketing
team,
very
data-driven,
and
we
don't
often
try
to
create
that
same
kind
of
data
and
that
use
that
data
to
justify
some
of
our
investments.
The
same
way
that
other
teams
do
as
engineers
and
and
I
think
like
it's
expensive
to
do
that
and
I
think
it's
something
that
gets
a
thought
about
way
too
late
in
the
cycle,
and
this
is
like
door.
B
Metrics
are
usually
something
that,
like
larger
organizations,
are
thinking
about,
but
if
we
can
find
ways
to
make
these
tools
easier
to
adopt,
then
it's
less
of
a
conversation
of
time
and
energy
investment.
Where
you
need
someone
to
sign
off,
you
can
kind
of
just
do
it.
It's
a
commodity
at
that
point.
B
Why
and
here's
how
it'll
be
good
for
you
I
think
we
tend
to
lean
with
like.
If
you
don't
do
this
it'll
go
down
and
that's
like
a
fear-based
approach.
But
if
you
talk
about
it
from
as
a
profit,
Center,
here's
how
we
can
make
more
money
like
now.
The
sales
teams
are
your
price
up
like
oh,
we
like
to
make
more
money
right
so,
like
I,
think
it's
both
storytelling
a
bit
and
I
use
analogies
a
lot
which
sometimes
missed
the
point,
but
that's
what
I've
tried
to
get
across.
A
Okay,
cool
thanks,
Karl
I,
don't
see,
there's
any
questions
or
lost
chance
guys.
Do
you
guys
any
questions?
Please
put
them
in
the
Q&A
panel,
so
I
have
a
question
actually,
and
so
one
of
the
questions
mentioned:
they've
SiC
ups
or
DevOps
sick
right.
So
this
is
like
a
term
that
has
been
recently
coined
and
in
your
slides
you
mentioned
a
lot
about
DevOps
and
security
and
compliance
right.
B
A
B
B
Think
that,
generally,
is
what
I'm
preaching
on
from
my
soapbox
right
like
that's,
that's
that's
the
thing
I'm
trying
to
get
across
so
I
aligned
with
that
very
well
I'm,
certainly
not
as
deep
into
the
security
space
with
dev
Sackhoff
space
myself,
but
I
do
look
at
when
I
zoom
out
and
look
at
the
macro
effect.
That
is
a
great
example
of
a
more
a
slightly
more
niche
area
within
devstack,
ops,
I.
B
Think
now
you
have
things
like
you
were
talking
earlier
before
the
call
about
AI,
ops,
hairy
and,
like
that's
kind
of
the
same
ideas
like
we're,
trying
to
make
this
segment
of
technology
more
accessible
and
that's
where
I
really
love
the
whole,
like
Deb
sack
ops,
a
AI
ops
like
whatever
ops
you
want
to
come
up
with
I
think
to
the
extent
that
that
Deb
sack,
ops
movement
continues
and
it
continues
down
that
path.
And
you
see
AI
ops
follow
and
you
see
other
emerging
you
know,
I
would
expect.
B
There's
gonna
be
something
related
to
front
end
at
some
point.
That
kind
of
is
gets
coined.
I.
Think
that's
generally
good,
because,
overall,
what
is
doing
is
its
lowering
the
barrier
to
entry
for
the
developers
who
don't
want
to
struggle
with
the
technology
and
need
to
meet
their
deliverables,
and
then
they
can
say:
hey
look.
I
can
do
dev,
SEC
ops,
I
click.
They
can
even
put
that
on
their
resume.
B
Like
I've
been
working
a
company
that
does
deficit
box
right,
that's
good
for
everybody,
I
think
what
we
have
to
recognize
is
like
what
is
the
pathway
there?
What
are
we
trying
to
achieve
and
how
do
we
then?
Like
look
for
other
areas
where
we
can
bring
down
that
and
if
the
way
we
do,
that
is
by
like
coining
a
term
so
that
people
can
like
organize
around
it
and
bring
their
knowledge
and
expertise.
B
I
think
that
is,
it
is
incredibly
aligned
with
what
I
believe
we
need
to
do
to
build
cultures
of
delivery
that
especially
in
security,
because
Security's
often
something
that
gets
adopted
way
late
in
the
curve
and
by
adopting
devstack
ops.
You
bring
it
earlier
in
the
curve,
because
the
cost
implemented
is
much
lower,
the
cost
to
use
it
is
much
lower
and
the
more
we
can
bring
things
down
the
curve
so
they're
easier
to
adopt
right.
The
better.
A
Thanks
Karl
so
see,
there's
no
more
questions,
then
we
can
end
of
the
session.
So
again,
thank
you,
Carr
for
this
fantastic
presentation
and
thanks
everyone
for
joining
us
today.
The
webinar,
recording
and
slides
will
be
online
later
today
and
we're
looking
forward
to
seeing
it
at
a
future
scene.
Cf
webinar
have
a
great
day.
Everyone
thanks.