►
From YouTube: Cloud Native Transformation: How Ticketmaster is Changing Culture and Speeding Up - Bindi Belanger
Description
Cloud Native Transformation: How Ticketmaster is Changing Culture and Speeding Up Delivery [B] - Bindi Belanger, Ticketmaster
Ticketmaster redefined an entire market by being the first to put computers in box offices and we now have four decades worth of products and tools that connect fans with the live events they love. With over 21 ticketing systems across the world and massive global technology team that continues to create and deliver new products and services, we must continually increase our speed to delivery to keep pace with our competitors. Historically, production scale infrastructure required significant lead time and often resulted in product launch delays or painful scaling lessons. As we continue to transition to a completely Cloud Native product offering, we’re now able to deploy infrastructure within a matter of minutes instead of months, thereby allowing our development teams to quickly build and release new products and services. In this talk, we’ll discuss the challenges that we’ve faced along the way and how we’ve made organizational and process changes to help us arrive where we are today.
About Bindi Belanger
Bindi Belanger is an Executive Program Director at Ticketmaster, based in Hollywood, California. In her current role, Bindi partners with Technical Operations and Engineering leaders to define strategy for new technology implementations and ensure successful delivery of key programs, including Ticketmaster's Kubernetes project. Prior to Ticketmaster, Bindi served in various project, program and portfolio management roles at several Fortune 500 companies including NBC Universal, UnitedHealth Group and The Walt Disney Company.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
All
right,
hello,
everyone,
my
name
is
bindi
Boulanger
and
I'm.
An
executive
program
director
at
Ticketmaster
I've
been
with
light
nation
and
Ticketmaster
for
a
little
over
four
years
and
in
my
current
role,
I'm
partnered
with
the
technical
operations
team
and
work
on
strategic
planning
and
organizational
optimization,
which
is
basically
a
fancy
way
of
saying
that
I
help
the
leadership
team
figure
out
what
we
should
work
on
and
how
we
should
organize
ourselves
to
work
on
it.
So
I
am
NOT
an
engineer.
A
So,
if
you're
expecting
to
see
any
code
up
here
on
this
screen,
you're
welcome
to
step
out
and
turn
Heather
talk
at
this
time
today.
What
I
will
be
talking
about,
though,
is
ticketmasters
journey
to
becoming
a
cloud
native
company
I'll.
Tell
you
a
little
bit
about
our
company,
some
of
the
challenges
that
we
faced
in
the
past
and
then
the
steps
that
we've
taken
over
the
last
couple
of
years
to
help
us
arrive
at
where
we
are
today.
A
So
Ticketmaster
was
founded
almost
41
years
ago,
back
in
1976
and
in
1996
the
website
Ticketmaster
com
was
launched
and
most
people
when
they
think
about
Ticketmaster.
They
think
of
it
as
just
the
website,
but
in
fact,
in
2010
after
we
joined
forces
with
Live
Nation,
we
have
a
large
number
of
business
services
that
we
provide
from
selling
tickets
to
producing
concerts
to
even
providing
artist
management
services.
We've
sold
over
465
million
tickets
to
events
in
over
37
countries
last
year.
A
A
A
In
order
to
deliver
those
amazing
experience.
We've
got
a
really
large,
complex
technical
stack.
We
jokingly
and
fondly
refer
to
our
tech
stack
as
the
museum,
because
we've
got
era,
every
we've
got
software
from
every
era
and
most
of
them,
or
many
of
them
are
not
ready
for
containers
in
clouds,
because
Ticketmaster
has
grown
so
much.
In
the
last
40
years,
we've
amassed
21
different
ticketing
systems
to
sell
everything
from
concert
tickets
to
season
tickets,
to
your
favorite
sporting
events.
A
To
go
see
a
your
favorite
band
play
at
a
small
venue
that
those
ticketing
systems
include
over
250
different
products
and
services
to
build
and
maintain
those
products
and
services.
We've
got
an
organization
of
over
1400
people
globally
and
they
build
that
software
on
our
private
cloud
today,
which
is
about
20,000
virtual
machines
across
seven
global
data.
Centers
we've
got
a
huge
Network
footprint
and
our
technology
stack
continues
to
grow
every
year.
A
On
top
of
that
technology
stack,
we
have
a
massive
challenge
in
that
we
invite
the
entire
world
to
come
and
DDoS
our
website.
Every
time
we
put
a
major
artist
or
event
on
sale,
so
if
Beyonce
or
Adele
or
Bruno
Mars
is
selling
their
tickets,
millions
of
fans
will
come
to
Ticketmaster
com
in
hopes
of
getting
one
of
a
few
thousand
tickets.
We
have
we,
you
can
tell
from
the
spike
there
that
we
go
from
0
to
150
million
transactions
in
in
just
a
matter
of
minutes.
So.
A
Even
though
we
are
one
of
the
we
are
the
world's
largest
live
entertainment,
entertainment
provider,
we
have
a
lot
of
competition
because
we
do
everything
from
selling
tickets
to
producing
concerts.
We've
got
a
huge
surface
area,
which
means
that
competitors
can
come
after
us
in
any
one
of
those
parts
of
our
business.
In
order
to
keep
pace
with
our
competition,
we
have
to
be
really
agile
and
very
fast,
but
the
scale
and
complexity
of
our
forty-year-old
business
with
all
of
our
legacy
technology,
makes
you
know,
making
rapid
changes
really
hard.
A
The
analogy
that
we
like
to
use
is,
if
you
can
imagine,
turning
a
giant
ship
right
to
move.
Everybody
in
the
same
direction
is
not
an
easy
thing
to
do
so.
To
recap:
we've
got
a
lot
of
competitive
pressure
across
a
large
market
surface
area.
We
have
legacy
tech,
which
many
of
many
of
those
systems
are
not
ready
for
containers
or
public
cloud.
A
We've
got
a
lot
of
technical
debt
with
high
interest
rates
that
we're
constantly
trying
to
pay
down
huge
scale
and
complexity
and
the
challenge
that
we
face
with
our
on
sale
demands,
and
then
we
have
Black
Friday.
Every
time
a
major
artist
goes
on
sale.
So
that's
those
are
the
business
challenges
and
then
historically,
we've
also
had
challenges
just
within
the
technology
organization.
A
Within
technical
operations
over
the
last
few
years
because
of
our
legacy,
tech
stack,
we've
had
to
have
put
a
lot
of
time
and
effort
focusing
on
maintaining
the
stability
of
that
infrastructure.
For
a
long
while
we
were
spending
a
lot
of
our
time
on
constant
fire
fighting,
which
meant
that
we
have
very
limited
resources
to
work
on
projects
to
add
new
value
and
new
features
for
our
development
teams.
We
had
a
lot
of
silos
just
within
technical
operations
and
a
very
specialized
talent
pool
because
of
those
silos.
A
Those
challenges
made
it
very
difficult
for
our
developers
to
work
with
tech
ops.
We
had
a
somewhat
confusing
support
structure.
Every
time
they
submitted
a
JIRA
ticket
to
us.
They
had
to
wait
a
really
long
time
in
order
for
us
to
turn
that
around
because
of
the
complexity
of
our
tech
stack,
there
was,
they
were
highly
dependent
on
operations.
We
didn't
have
a
lot
of
autonomy
themselves
and
the
systems
and
themselves
because
of
the
way
they'd
been
built,
were
very
complicated
to
get
a
new
app
deployed
or
a
new
environment
built
out.
A
If
we
didn't
have
capacity
on
our
private
cloud.
These
are
the
steps
that
they,
a
developer,
would
have
to
go
through
and
it
often
took
several
months,
especially
if
it
required
purchasing
additional
hardware
to
build
out
our
on-prem
private
cloud.
So
you
can
imagine
the
frustration
that
our
development
teams
felt
any
time
they
had
to
deal
with
technical
operations
and
then
within
operations.
We
had
some
frustration
because
each
of
our
different
areas
function
does
its
own
mini
team
right.
There
was
not
folks
in
the
private
cloud
team
that
could
do
data
center
work.
A
The
folks
on
the
network
team
weren't
involved
in
defining
and
deploying
our
platform
solutions
systems.
Engineering
application
support
were
two
different
organizations,
even
though
there
was
some
overlap
there
and
then,
on
top
of
that,
because
it
took
so
long
to
deploy
infrastructure,
we
had
to
build
for
our
highest
peak
load
plus
20%,
which
means
if
we
were
expecting
to
sell
tickets
to
something
like
a
Beyonce
concert.
A
A
The
first
thing
that
we
did
was
really
a
concerted
effort
around
a
lean
transformation
which
met
managing
our
technology
org
like
an
investment
portfolio,
so
from
the
top
down
and
our
senior
executive
level,
they
define
the
vision
which,
for
us,
is
to
connect
with
1
billion
fans
by
2020
and
then
identified
the
goals
that
we
needed
to
achieve.
In
order
to
reach
that
vision
within
those
goals,
we
would
define
bets,
or
we
bet
that
if
we
did
a,
we
would
result
in
that
would
result
in
achieving
our
goal.
A
And
then
those
bets
were
broken
down
into
smaller
pieces
of
work
called
promises
of
value.
So
every
delivery
team
was
aligned
around
a
POV
or
promise
of
value.
We
would
regularly
review
our
progress
against
these
bets
and
goals
in
folio
reviews
and,
as
a
leadership
group
would
make
decisions
around
whether
we
needed
to
adjust
pivot
work
on
something
else
or
double
down,
meaning
put
more
resources
on
the
projects
that
we're
turning
that
we're
resulting
in
high
value.
A
So
at
the
same
time
that
that
was
happening.
Our
development
organization
grew
by
about
two
hundred
and
fifty
percent,
so
leaps
and
bounds.
New
developers
were
getting
hired
every
week,
but
our
operations
team
did
not
grow
to
keep
pace
with
that.
So
we
created
sixty
five-plus
I,
think
it's
close
to
a
hundred
now,
because
we've
grown
so
much
cross-functional
delivery
teams
which
included
UX
and
UI
software
developers
and
QA.
But
you
notice
what's
missing
up,
there
is
operations
because
obstinance
scale
to
match
the
growth
of
the
development
organization.
A
A
So
because
of
the
roadblock,
we
realized,
we
really
needed
to
make
sure
that
these
delivery
teams
were
autonomous,
that
they
could
do
a
lot
of
the
work
they
needed
to
do
on
their
own.
One
of
the
first
steps
that
we
did
was
we
moved
our
application
support
teams
out
of
tech
ops
and
into
the
product
teams
directly
by
removing
that
organizational
silo
right,
taking
them
out
of
ops
and
putting
them
directly
with
the
people
that
needed
to
make
those
changes.
We
were
hoping
to
remove
a
lot
of
those
barriers.
A
The
next
thing
that
we
did
was
we
embedded
systems
engineers
into
those
product,
delivery
teams
again
working
to
get
towards
truly
cross-functional
groups,
but
because
we
didn't
have
enough
systems
engineers
instead
of
having
a
one-to-one
ratio.
One
engineer
was
one
systems
engineer
to
one
team.
What
ended
up
happening
was,
we
would
have
one
systems
engineer
that
was
assigned
to
support
five
or
six
related
teams.
A
It
was
an
ideal,
but
it
was
much
closer
to
being
truly
cross-functional
in
that
ended
up,
resulting
in
fewer
JIRA
tickets,
because
you
remove
that
formality
of
having
to
submit
a
ticket
that
would
sit
in
a
queue
for
a
while.
Instead,
your
systems
engineer
was
probably
sitting
right
next
to
you
and
your
team,
so
that
you
could
work
much
closer
with
them.
We
also
made
an
investment
in
self-service
tools.
Things
like
access
management
to
servers,
password,
resets
things
that
our
Ops
teams
were
spending
a
lot
of
time
doing.
A
We
found
ways
to
automate
and
then
make
self-service
that
also
reduced
the
number
of
JIRA
tickets
coming
into
our
queues
with
the
goal
of
all
this
was
to
create
these
delivery
teams
that
were
self-sufficient
like
micro
businesses,
their
jobs
would
then
be
to
build
software,
run
it
own.
It
operate
it,
optimize
it
and
monetize
it.
A
We
gained
a
lot
of
insights
from
doing
this.
As
we
got
closer
and
closer
to
a
truly
DevOps
culture.
We
found
that
almost
half
of
our
time
we
spent
moving
code
around
our
different
environments.
It's
not
a
really
good
way
to
add
value
right.
We
also
found
that
we
had
150
different
ways
to
release
software
a
lot
of
the
times.
A
A
So
with
those
insights,
we
realized
we
needed
more
information,
we
needed
more
data
and
so
to
give
us
better
insight
into
how
we
can
make
more
effective
change.
So
we
built
maturity
models.
The
two
maturity
models
that
I'll
talk
about
today
are
our
tech,
maturity
and
our
team
maturity.
We
wanted
to
be
able
to
define
and
measure
team
performance
and
Technol
technical
performance
objectively.
A
The
tech
maturity
model
has
about
50
different
capabilities
and
I'll.
Show
you
what
it
looks
like
in
just
a
minute
that
cover
five
different
dimensions
of
software
development,
how
we
code,
how
we
build
and
test
that
software,
how
we
release
it,
operate
it
and
then
optimize
it.
Every
team
went
through
a
process
of
self-assessment,
guided
by
our
architecture,
leaders
and
came
up
with
an
objective
score
and
a
clear
path
for
improvement.
A
Tecna
cherry
comm
was
open
sourced
a
few
months
ago.
So,
if
you
want
to
know
more
about
this,
you
can
see
me
after
the
talk.
So
this
is
a
snapshot
of
our
score
across
all
the
different
product
teams.
When
we
first
did
this
about
a
year
or
so
ago,
you'll
notice
that
we're
really
good
at
developing
code
and
then
coming
back
later
and
optimizing
it,
but
we're
not
great
at
building
and
testing
it
and
then
operating
it
because
of
all
the
work
we
did
around
our
lean
transformation
and
moving
towards
more
autonomous
teams.
A
You
can
see
that
our
highest
score
was
actually
in
the
DevOps
practice,
so
each
of
those
capabilities
had
a
description
of
what
level
1
2,
3,
&,
4
look
like,
and
so,
wherever
a
team
self
assess
them
self
assess,
they
would
know
what
they
needed
to
do
to
get
to
the
next
level.
So
you
can
see
for
DevOps
level.
One
was
environments
and
production
are
controlled
by
someone
not
on
the
team
building
the
product
right.
So
it
was
operations
that
owned
the
production
environment,
not
the
development
team
level.
A
So
this
is
a
snapshot
of
the
tech
maturity
model,
specifically
in
the
area
of
coding,
you'll
notice,
on
the
right
hand,
side
there's
a
minimum
cloud
readiness
score.
So
what
we
were
working
towards
is,
as
we
started
moving
teams
to
the
public
cloud.
We
wanted
to
define
what
the
minimum
level
was
in
order
for
those
products
and
services
to
function
well
in
the
public
cloud.
A
So,
in
the
test,
suite
example
you'll
see
that
the
minimum
cloud
readiness
is
a
level
three,
which
is
that
they
actively
maintained
those
tests
and
with
they're
mostly
successfully
passing
for
positive
flows.
In
this
particular
case,
the
team
self
assessed
at
a
level
one
and
before
they
began
their
journey
to
the
cloud
we
wanted
to
ensure
that
they
got
to
a
level
three,
so
this
gave
them
some
guidelines.
A
The
feedback
was
really
great.
When
we
started
rolling
this
out
to
teams,
not
only
did
it
give
them
a
really
objective
way
to
say:
hey,
we
have
some
opportunities
for
improvement
in
our
tech
stack,
but
it
helped
facilitate
the
conversation
with
product
leadership,
senior
leadership
to
say,
if
we
can
improve
in
these
areas,
we
can
start
to
move
faster,
will
experience
fewer
incidents
in
production,
and
it
enabled
a
conversation
that
we
just
weren't
able
to
have
before.
Instead
of
having
you
know
talking
to
your
product
manager
and
saying
hey,
we
need
to
get
faster.
A
A
Next,
we
built
a
team
maturity
model
that
was
really
around
the
adoption
and
implementation
of
agile
practices.
We
wanted
to
help
teams
figure
out.
How
can
you
move
faster?
So,
even
if
your
technology
is
top
rate
right,
you're
building
modern
software
are
using
modern
tools.
If
your
team
wasn't
functioning
as
a
high
functioning
team,
how
did
you
get
there?
What
did
that
look
like
what
steps
should
you
take
to
improve?
A
So
we
have
a
snapshot
here
of
this
isn't
the
whole
thing,
but
just
a
portion
of
it
of
the
team
maturity
model
that
included
things
like
strategic
roadmap.
Does
your
team
understand
how
the
work
that
they're
doing
is
contributing
to
the
overall
goal
and
mission
of
the
company?
Are
your
roles
and
responsibilities
clear
just
within
your
team,
or
does
everyone
in
the
technology
org
understand
who's
responsible?
For
what
are
you
doing
paired
programming?
Are
you
actively
eliminating
waste?
A
A
So
the
value
here
wasn't
about
saying:
oh,
my
team
is
a
level
1
or
a
level
2,
but
it
was
understanding
where
you
were
and
what
skills
you
needed
to
obtain
to
get
to
that
next
level.
So
we
categorized
teams
into
less
mature
teams
that
were
still
you
know,
maybe
newly
forming
and
still
understanding
the
basics
of
things
like
agile,
best
practices
in
Kanban
to
teams
that
were,
you
know,
working
to
get
better
to
our
high
performance
teams
that
were
always
getting
faster
and
serving
as
models
for
other
groups.
A
So
we
were
continuing
our
lean
transformation
and
then
our
senior
leaders
made
the
strategic
decision
that
we
wanted
to
move
our
products
and
services
out
of
our
on-prem
data
centers
and
into
the
public
cloud.
The
two
main
reasons
for
that
were
one.
We
don't
need
to
spend
a
lot
of
time
and
money
building
out
and
our
infrastructure
to
be
always
on.
A
But
how
are
we
using
our
human
resources
right
if
your
teams
are
spending
all
their
time
building
and
maintaining
and
upgrading
their
infrastructure
they're
not
really
spending
time
adding
value
helping
your
development
teams
move
faster.
So
we
wanted
to
focus
a
lot
of
our
time
there
and
then
things
like
removing
single
points
of
failure.
Rich
telemetry,
shared
nothing
architecture
were
all
really
important
reasons
for
us
to
move
to
the
public
cloud
so
for
Ticketmaster.
A
A
We
obsessed
over
meantime
to
detect
and
meantime
to
resolve,
because
if,
if
you
failed,
but
you
were
able
to
detect
that
failure
very
quickly
and
recover
quickly,
that
was
ok
right.
When
we
had
major
outages,
we
began
doing
blameless
post-mortems.
We
had
a
really
massive
one
about
a
year
and
a
half
ago,
and
the
post-mortem
involved
almost
200
people,
everyone
from
operations
to
software
developers
to
our
client
and
fan
facing
teams
and
instead
of
spending
a
lot
of
time
finger-pointing
as
to
what
caused
the
problem
we
spent
a
couple
days
working
through.
A
How
can
we
make
sure
that
this
doesn't
happen
again
in
the
future?
What
steps
do
we
need
to
take?
How
do
we
prioritize
that
word
and
then?
How
do
we
work
together?
In
the
event
that
this
should
happen
again
to
recover
even
faster
next
time-
and
we
constantly
emphasize
it
or
iterative
delivery
iterative
improvement
and
made
it
okay
to
just
try
experiments
and
say
we
tried
this,
it
didn't
work,
let's
try
something
else.
A
The
other
main
thing
specifically
from
a
program
management
perspective
was
we
wanted
to
shift
away
from
output
and
focus
on
outcomes.
We
were
heavily
focused
on
tracking
and
reporting
and
publishing
story
points
which
that's
one
of
the
key
metrics
in
an
agile
organization
and
in
stead
of
focusing
on
story
points
which
don't
really
convey
any
sort
of
business
value.
We
wanted
to
focus
on
business.
Metrics
and
KPIs
was
the
work
that
your
software,
our
teams
were
doing.
Are
they?
Are
you
increasing
conversion?
Are
you
selling
more
tickets?
A
Are
you
getting
more
visitors
to
the
website
and
by
shifting
the
focus
to
how
fast
are
we
getting
work
done
to?
Are
we
doing
the
right?
Work
was
really
huge,
especially
from
a
leadership
perspective,
so
we
spent
a
lot
of
time
on
the
leadership
level
on
the
next
area
of
focus,
for
us
was
our
teams.
The
Technical
Operations
team
specifically
was
has
shrunk
quite
a
bit
over
the
last
couple
of
years.
A
One
of
the
main
reasons
was
because
of
the
DevOps
alignment
that
we
were
doing
right:
we're
moving
application,
support
teams
and
engineers
closer
to
the
product
teams
that
they
supported.
We
were
also
very
strategic
about
where
we
backfilled,
because
of
a
lot
of
the
self-service
and
automation
work
that
we
had
done
had
reduced
the
number
of
true
ops
or
maintenance
work
that
we
were
doing.
We
wanted
to
make
sure
we
weren't
just
backfilling
to
backfill,
but
that
we
were
getting
the
right
talent
and
the
right
people
to
help
us
in
our
next
phase.
A
A
Then
our
leadership
team-
that's
it
can
I,
take
questions
at
the
end.
All
right,
then
our
leadership
team
spent
some
time
talking
through
as
we're
back
failing
as
we're
recruiting
new
team
members.
What
kind
of
skill
sets
do
we
want?
What
are
the
characteristics
of
an
ideal,
Technical
Operations
team
member
in
this
next
phase
of
our
journey?
So
we
map
that
out
and
I
won't
read
through
all
of
them.
A
But
if
you
want
to
take
a
quick
picture,
we
broke
it
down
into
tech
skills,
soft
skills
and
then
that
sweet
spot
in
between
things
like
creative,
problem-solving,
having
a
knowledge
of
AWS
and
cloud
primitives,
excellent,
troubleshooting
skills
right
nowhere
on
here.
Do
you
see
any
specific
coding,
language
or
knowledge
of
a
specific
technology.
A
In
order
to
create
the
ideal
cloud
native
teams,
we
realized
that
smaller
was
better.
Two
to
five
people.
Teams
have
been
have
proven
to
be
really
successful
for
us
and
when
you
think
about
two
people
as
a
team,
it
may
seem
a
little
strange,
but
we
found
that
paired
programming
and
having
less
people
focus
on
the
same
problem
allowed
us
to
move
faster.
So
again,
we
wanted
people
that
were
had
development
backgrounds,
which
is
something
that's
not
easy
to
find.
A
If
you're
looking
for
people
that
also
are
really
familiar
with
infrastructure,
we
have
been
looking
for
people
that
have
either
knowledge
or
have
been
contributing
to
cognitive
projects
we
want
and
then
from
the
soft
skills
perspective
again
creative
problem
solvers
with
a
bias
for
action.
We
didn't
want
people
that
were
like
we've.
We've
done
this
for
the
past
five
years.
Let's
just
keep
doing
it.
The
status
quo
is
totally
fine.
A
So
we've
got
our
leadership.
We've
got
our
teams.
The
next
step
for
us
was
organizing
the
work
and,
if
you're,
from
the
ops
background,
you
know
that
traditionally,
infrastructure
projects
have
almost
always
followed
a
waterfall
methodology,
especially
when
it
came
to
physical
Hardware
right.
You
can't
it's
difficult
to
iterate
there.
You
have
to
plan
out
what
you're
gonna
do
the
sequence
of
steps
that
you
need
to
take
to
build
and
configure
hardware.
It's
not
something
that
was
really
easy
to
take
an
agile
approach
to
you.
A
Waterfall,
scrum
and
Kanban
don't
work
without
some
level
of
adjustment.
So,
for
our
case
a
Ticketmaster
as
we
kicked
off
our
kubernetes
project,
we
took
the
time
to
do
some
planning.
We
iteratively
delivered
and
building
out
production,
ready,
kubernetes
clusters.
Then
we
decided
to
partner
with
core
OS
and
so
adding
tecktonik
into
the
mix
caused
us
to
take
a
step
back.
Do
some
additional
planning
iterate
through
that,
as
we
were
implementing
tectonic,
we
realized
hey,
we
need
to
add
prometheus.
We
want
to
use
that
for
monitoring
and
then
helm
for
package
management.
A
So
this
level
of
flexibility
was
really
necessary
to
help
us
manage
these
projects.
You
can't
stick
to
a
single
framework
and
say
you
know
this
is
the
box
that
we're
gonna
live
in
and
we
must
live
in
that
box
because
of
that
need
for
flexible
frameworks.
One
of
the
things
that
we've
done
that
has
been
really
successful
for
us
is
we
have
two-day
on-site
collaborative
planning
sessions.
A
That
may
seem
like
a
really
obvious
thing
right.
If
you're
gonna
have
a
project,
you
should
plan
for
it,
but
for
us
the
keys
here
were
doing
them
on-site,
because
our
operations
teams
are
cloud.
Native
teams
are
largely
remote
because
we're
looking
for
the
best
talent
within
our
company
and
then
outside.
We
hire
folks
all
over
the
world,
but
bringing
them
on-site
to
work
together
to
build
those
relationships
and
then
to
really
visualize
the
work
which
has
been
really
important
for
us
in
that
session.
We'll
do
things
like
defining
our
scope.
A
A
So,
with
having
flexible
frameworks,
you
can't
just
have
a
traditional
project
manager.
What
we
needed
instead
were
leaders
who
happen
to
be
program
or
project
managers,
people
that
weren't
be
it
weren't
able
to
creatively
modify
the
established
frameworks
just
really
struggled
to
succeed,
especially
if
you
have
someone
who's
very
used
to
setting
a
plan
and
then
having
the
team
follow
it.
This
could
be
a
very
frustrating
type
of
project
to
undertake.
So
the
key
characteristics
for
success
in
this
role
were
that
project
managers
who,
like
myself,
may
not
be
technical.
A
They
needed
to
understand
enough
for
the
technology
that
they
could
ask
the
right
questions
to
drive
meaningful
discussions
and
decisions
with
the
team
they
had
to
have
enough
experience
working
on
other
projects
to
be
able
to
ask
the
right
questions.
Why
are
we
doing
it?
This
way?
Have
we
talked
to
the
teams
about
what
they
need?
Have
we
documented
our
architecture
and
validated
with
anyone?
A
A
The
same
way,
and
the
other
important
piece
of
this
is
that
our
project
leaders
needed
to
be
partnered
with
engineering
leads
and
not
in
supportive
or
auxilary
roles,
which
oftentimes
happens
when
you
have
someone
like
a
scrum
master
right
there
in
service
of
the
team
they're
there
to
support,
but
they're
not
often
seen
as
a
leader.
So
for
us
it
was
really
important
specifically
on
cloud
native
projects
that
required
flexibility
to
have
a
leader
in
this
type
of
role.
A
A
You
know,
cloud
native
and
kubernetes
conferences
as
we
can
hosting
meetups,
really
more
to
just
understand
what
other
teams
are
doing,
what
other
people
are
using
as
far
as
solutions
we've
joined
several
SIG's
and
then
most
recently
and
a
few
months
ago
we
joined
the
cloud
native
computing
foundation,
so
leadership
highly
skilled
and
motivated
team's
project
framework
and
leadership
on
the
project
front,
and
then
a
community
and
partnership
engagement
has
led
us
to
a
culture
of
daily
delivery.
So
for
us,
daily
delivery
means
for
one
we
have
twice
daily
stand-ups.
A
Instead
of
having
a
weekly
iteration
or
a
month-long
iteration.
Every
morning
the
team
will
get
together
and
say
what
are
we
delivering
today
and
at
the
end
of
the
day,
you're
asked
to
demo
the
value
that
you've
delivered.
So
we
get
away
from
this
two-week
iteration
or
at
the
end
of
the
quarter.
We'll
have
something
delivered
we'd
like
to
see
what
we're
gonna
get
done
each
day
because
of
cloud
native
solutions,
we've
gone
from
several
months
to
deploy
new
infrastructure
and
environments
to
when
we
were
in
the
middle
of
our
DevOps
transformation.
A
It
would
got
down
to
a
few
weeks
and
now,
with
cloud
native,
it's
just
a
matter
of
minutes,
same
thing
for
feature
releases,
because
there
was
so
much
coordination
required
between
our
Ops
teams.
Application,
support
teams
and
software
teams
releases
didn't
happen
very
often,
maybe
once
every
few
months
with
DevOps,
we
finally
got
to
a
more
weekly
delivery
culture
and
then,
with
cloud
native
teams
were
able
to
release
new
features,
as
often
as
they
need
to
turn
the
day.
A
One
of
the
great
use
cases
or
key
studies
that
we've
seen
is
our
new
tech
ticket
master
web
platform,
which
was
built
on
kubernetes
and
is
still
in
its
beta
phase
right
now
before
kubernetes,
even
though
they
were
a
modern
team
with
great
lean
practices,
they
were
building
on
new
technology.
It
still
took
about
20
minutes
or
so
to
deploy
with
low
confidence
right.
A
So
to
recap,
cloud
native
transformations
within
your
company
require
major
cultural
transformations
from
everything
to
how
you
define
and
set
goals,
how
your
leadership
views
the
importance
of
outcomes
over
outputs
and
then
the
skill
sets
and
teams,
and
the
way
that
you
organize
the
work
and
in
I
would
argue
that
the
way
that
you
organize
your
delivery
of
cloud
native
solutions
is
just
as
important
as
the
technology
choices
that
you
make.
So
methodology
is
just
as
important
as
the
technology
so
I'm
here
this
week
with
my
team
from
the
US
and
the
UK
there.