►
From YouTube: 2023-09-05 WG Platforms - Maturity Model
Description
TAG web site: https://tag-app-delivery.cncf.io/
TAG Slack channel: https://cloud-native.slack.com/archives/CL3SL0CP5
TAG git repo: https://github.com/cncf/tag-app-delivery
TAG meeting notes: https://docs.google.com/document/d/1OykvqvhSG4AxEdmDMXilrupsX2n1qCSJUWwTc3I7AOs/edit
A
B
Presumed
the
recording,
but
you
didn't
miss
much
people
that
are
watching,
recording
we're
just
going
over
what
we're
going
to
talk
about.
So
this
is
the
this
is
the
maturity
model
where
we
spend
quite
a
bit
of
time,
actually
a
few
meetings
settling
on
these
five
aspects
as
most
relevant
for
companies
in
the
midst
of
adopting
platform,
engineering
or
platform
Journey.
B
So
right
now,
yeah
we're
pretty
settled
on
these
five.
If
you
go
down
in
this
top
document,
you'll
see
there's
a
details
section
for
each
one
right
now
we're
going
to
work
on
this
adoption
one,
but
it
does
help
to
kind
of
have
an
eye
on
what's
happening
in
the
other
five,
because
we're
going
to
need
to
integrate
them
all
in
the
next
week
or
two,
so
the
state
that
we
we're
at
and
that
in
the
adoption
areas
of
this,
this
chart
is
a
little
big
to
fit
on
a
page.
B
Unfortunately,
but
we
have
so,
we
settled
adoption
as
an
aspect
and
we're
pretty
settled
on
these
ideas
that
these
three
are,
these
four,
you
know
things
across
the
column
reflect
different
stages
or
different
maturity
levels.
It's
a
little
tricky.
We
don't
want
to
say
you
have
to
go
to
two
three
four,
but
like
yeah
reflect
these
states
states.
That's
a
good
word.
B
It
would
help
if
I
got
this
out
of
the
way,
but
this
call
is
to
kind
of
discuss
those
a
little
bit
more
make
sure.
I
know
that
Matt.
Thank
you
so
much
by
the
way
and
and
give
you
a
chance
to
introduce
yourself
sorry
about
that.
Oh
I
was
late
too
yeah
yeah.
Do
you
want
you
wanna?
Did
you
want
to
introduce
yourself
sure.
C
B
B
There
was
some
other
text.
I
think
that
Victor
you
wrote
some
too.
Over
the
weekend,
I
tried
to
gather
some
of
the
ideas
that
were
that
had
been
in
there
and
that
Matt
added
into
a
couple
sections
in
each
one.
One
a
list
of
characteristics
like
that
might
characterize
that
level
and
then
I
was
just
thinking
and
I
definitely
want
people's
feedback
on.
This
is
scenarios,
maybe
because
May
so
to
explain
where
I'm
go
like
so
we
we
have
this
table
and
the
idea
is
like
people
can
land
on
this
table.
B
B
C
Go
math,
oh
just
I,
know
some
of
some
of
what
I
had
added
there
I
think
gets
into
the
investment
category
more
than
the
adoption
category.
That
was
one
of
the
things
that
I
sort
of
didn't
have
a
sense
of
that
boundary
and,
as
I
wrote,
more
I
think
I
kind
of
discovered
that
boundary
like
for
for
me,
and
maybe
this
is
something
I'm
interested
in
opinions
on
this.
C
D
C
Right,
well,
that's,
and
that
gets
someone.
One
of
the
other
comments
on
the
document
was
talking
about
the
flywheel
effect
and
I.
Think
this.
This
pair
of
aspects
of
the
model
really
are
a
flywheel
right,
where
greater
adoption
shows
the
value
of
Greater
investment,
which
can
drive
greater
adoption
still.
B
D
Likely
yeah,
the
the
other
thing
that
I
was
thinking
about
I
think
is
somewhat
related
to
what
you
just
said:
Matt,
which
is
the
the
idea
that
what's
weird
about
platform,
is
that
your
addressable
Market
is
the
constraint
to
the
size
of
the
company
right.
So
your
adoption
goal
here
is
also
your
growth
goal.
I
think
it's
to
get
as
close
to
100
of
usage
by
your
target
audience
as
possible.
Right.
B
D
Yeah
I
think
they're
going
to
be
emerging
technologies
that
are
not
yet
mature
enough
to
be
included
in
your
platform
and
you're
gonna
have
to
figure
out
how
to
draw
the
boundary,
and
so
you
know
I'm
not
sure
you'll
ever
hit
100,
but
like
of
the
stuff,
that's
really
at
the
core
to
what
you
do.
It
should
obviously
be
the
best.
It
should
be
the
obvious
best
way
to
build
and
deploy
and
manage
software
in
your
company.
C
Yeah
and
that
I
think
that
it
gets
into
interesting
questions
around
sort
of
like
the
platform,
but
there
are
ancillary
Technologies
which
could
be
considered
part
of
the
platform,
but
at
a
lower
level
of
adoption-
or
you
know
like
it
doesn't
have
to
be
one
size-
fits
all
talking
about
our
platforms
at
this
level.
But
we
also
have
this
like
incubating
part.
You
know
not
not.
B
C
B
That's
well
that's
exactly,
though,
what
we
want
to
talk
about
if
you're
saying
they,
you
might
adopt
that
the
database
function
and
the
platform
is
amazing
and
everybody
uses
it,
but
the
observability.
You
know
we
do
our
own
thing.
That
kind
of
I
could
hear
that
so,
okay.
So,
let's
start,
why
don't
we
kind
of
talk
at
a
high
level
here?
This
was
me
kind
of
brainstorming.
Yesterday
and
and
I
wanted
to
share
the
thought
with
you
I
guess
so
the
the
four
columns
there
was
some
discussion.
B
I
know,
you
know
whether
the
The
Columns
were
just
you
know,
matters
of
degree,
I'm
trying
to
make
it
show
better
here
or
or
actually
difference
is
in
in
quality
in
what
they
are
and
we
ended
up
with
a
little
bit
of
difference
in
quality.
So
in
the
first
stage
it's
provisional,
it's
one-off.
It's
not
you
know
adopted
broadly
it's
wherever
it
comes
in.
The
second
stage
is
operationalize.
B
It's
actually
part
of
a
pattern
of
some
sort,
maybe
not
the
most
efficient
pattern,
but
it's
in
there
scaled
I
guess
in
my
mind,
it's
kind
of
like
productionalized.
It's
it's
in.
It's
been
put
in
and
unaccepted
well-adopted
way
that
maybe
overlaps
a
little
with
optimized.
You
know
in
the
in
the
best
possible
way
so
mapping
that
into
what
we
had
here,
which
which
I
this
is
addictive,
meaning
and
I
kind
of
wrote
it
down
here.
Also
at
the
erratic
stage,
you
know,
there's
always
a
platform.
B
E
C
Explicit
yeah
and
I
think
one
of
the
things
for
me,
too,
is
about
like
in
at
this
erratic
stage.
Decisions
are
made
by
teams
and
scoped
to
teams,
and
so
part
of
a
platform
for
me
is
things
being
broader
than
the
team
right
like
my
team
needs
a
database
we're
just
going
to
go
to
AWS
and
pick
an
RDS
database
and
that's
like
a
local
maximum
for
us
right,
but
it's
not
for
the
organization
necessarily.
E
B
C
E
Well,
to
that
point,
there's
no
specific
Direction
being
you
know,
because
at
the
end
of
the
day,
leadership
is
going
to
have
goals
and
priorities
with
funding
and
all
those
other
issues
with
you
know
with
their
Cloud
strategy,
so
you've
got
it
online
to
the
greater
business
as
well.
So
absolutely
that's
a
good
point.
Matt.
C
Right
and
doing
things
ad
hoc
at
this
erratic
stage,
you
don't
as
an
individual
developer,
have
all
the
context
around.
Oh,
our
security
team
needs
to
sign
off
on
a
new
technology.
You
know,
there's
all
these
other
things
where
there's
not
the
process
that
allows
all
these
stakeholders
to
come
together.
E
C
B
Okay,
I'm
gonna
continue
into
that.
This
is
a
good
conversation
and
that's
I,
think
it'll
I
think
that
everything
we
say
about
each
will
affect
so,
let's
keep
going
as
we
get
to
the
next
stage,
which
you
know
we
titled
the
column,
operationalized
I
use.
This
word
I'm,
not
sure
you
see
Abby,
said
I
think
she
said
somewhere
like
is
this.
Are
people
gonna
know
the
word,
but
here
it's.
B
This
is
also
because
I'm
kind
of
getting
at
like
why
what
what
you
know
before
the
Radix
just
random,
but
here
they're
adopting
because
of
not
because
the
platform
itself
is
amazing
and
just
this
is
I-
really
need
a
database,
and
this
is
the
best
place
to
get
it.
But
kind
of
something
else
is
saying:
hey
join
the
team
use
our
use
our
platform
use
these
things,
they're,
not
finding
it
themselves.
B
C
Yeah,
it's
like
it's
reacting
to
the
erratic
nature.
You
know
the
organization
says:
hey,
you
can't
all
just
be
getting
your
own
AWS
accounts
and
creating
your
own
databases
like
everybody
use.
Rds
use
this
version
right
like
there's
a
standard
sort
of
impose
that
people
are
using
the
standard
because
it
was
imposed
still
maybe
absent.
C
B
E
And
to
a
point:
that's
what
drives
the
next
step,
the
ability
to
scale
and
the
ability
to
optimize
right,
because
some
guy
finds
something
and
builds
it
great.
Then
he
tells
a
bunch
of
his
friends.
They
go
out
and
build
it
great
and
then
leadership
all
of
a
sudden
say
wait
a
second.
What
are
you
guys
doing?
E
A
C
And
I,
like
the
that,
the
aspect
of
this
that's
like
it's,
it's
imposing
a
consistency,
it's
consolidation,
but
it
it
to
me
it
doesn't
this
doesn't
get
into.
Is
this
the
best
approach?
This
is
we
have
too
many.
We
should
have
a
small
number
that
we
can
manage,
but
there's
there's
a
sense
of
you
know
the
first
person
to
do
the
thing.
Their
solution
is
the
one
that
we're
adopting,
because
it
was
first
and
the
business
says.
No,
no
just
do
this
one
it
already.
C
C
C
B
Okay,
would
you
say,
oh
I,
just
because
I
think
it's
on
a
similar
topic
like
I
know
backstage
one
of
the
reasons
it's
popular
is
because
it
brings
it
all
into
a
single
pane
of
glass
would
like,
at
this
level,
you'd
be
more
likely
to
have
Jenkins
here
GitHub
here
you
know
observability
system.
There.
C
B
C
E
C
Like
the
the
organization
top
down
will
say,
like
everybody
use,
RDS
and
then
somebody
says
well,
we
we
can't
use
RDS
because
XYZ
in
the
business
says:
okay,
will
you
use
mongodb
everybody
else.
Use
RDS
like
there's,
there's
a
certain
amount
of
inconsistency,
but
it's
still
like
very
kind
of
ad
hoc
right
where
the
business
says
be
consistent.
Do
this
and
some
team
will
say
no,
we
can't
and
the
business
will
say:
okay
you're
the
exception.
Everybody
else
do
this
like
it's
still
like
absent
the
strategy.
C
A
B
Let
me
copy
that
in
Victor.
Is
that
what
you're
getting
at
the
in
the
investment
side?
It
says
level
two
is
emergence
of
a
sustained
platform
budget
that
isn't
Incorporated
within
the
company's
long-term
strategic
goals,
still
a
means
to
announce,
so
they
basically
dedicate
investment
as
a
one-off
like
outside
of
their
normal.
You
know,
profit
loss
strategy,
they
say
here's
a
million
dollars
to
build
a
platform
team.
B
C
And
that,
like
there's
I
I,
feel
like
I,
don't
know
how
to
phrase
this
comment,
but
there's
like
Engineers
can
only
do
so.
Much
like
you
can
only
get
such
a
level
of
adoption
before
you
bring
in
like
explicit
product
investment
like
I.
Don't
I,
don't
know
the
right
way
to
frame
that,
but
I
feel
like
there's.
B
C
E
Well
and
I
think
that's
where
we
get
to
that's
the
pain
point
before
we
get
to
the
scaled
side
of
the
platform
right,
we're
we're
identifying,
okay,
well,
yeah,
we
need
resources,
you
need
a
product
manager,
all
those
things
to
drive
the
strategy
to
drive.
You
know
the
end
State
at
this
point
to
your
point:
Matt,
it's
it's
Engineers
are
solving
their
own
pain
points,
they're,
not
actually
necessarily
looking
at
a
holistic
view
of
what
the
business
needs
to
function.
Yeah.
A
A
So
that's
why
from
there's,
there's
no
strategy
so,
but
if
there's
a
kind
of
outside
in
kind
of
incentive
to
try
new
things
compared
to
level
one
which
is
more
mostly
just
individual
people
trying
level
two
is,
is
more
of
a
widespread
kind
of
tryouts
a
few
things,
but
there's
no
there's
no
sense
of
you
know
what
can
what
can
I
do
it's
more
of
oh.
This
is
probably
good.
Let's,
let's
try
webassembly
or
kubernetes.
So
that's
that's
the.
B
B
C
With
that
okay
measure
of
the
business
or
I'm
directed
to
or
to
phrase
it
differently,
I
don't
have
to
solve
this
problem
myself,
because
there's
a
pattern
I
could
follow
right.
I
don't
have
to
do
the
research
on
what
database
is
best
for
my
team.
I
can
just
use
RDS
because
the
business
said
use
RDS,
but
it's
still
like
sidesteps.
The
question
of
is
this.
The
best
you
know
is
this:
is
this
the
right
choice?
Isn't
the
question
that
gets
asked
it's?
How
do
I
do
this?
Here's
a
way
to
do
this.
B
That's
yeah
what
I'm
struggling
a
tiny
bit
is
like
that's
almost
intrinsic,
like
that's
like.
Oh,
this
platform
is
great
I
want
to
adopt
it,
but
you're
saying
a
little
bit
different
you're
saying
so
much
that
it's
great
it's
that
well,
it's
something
it's
better
than
nothing!
I,
don't
want
to
have
to
start
all
the
way
from
scratch.
C
See
the
hand
raised
the
whole
no
no
go
ahead.
Go
ahead,
go
ahead,
I
mean
I,
think
there
is
the
sense
as
as
a
user.
It's
solving
my
problems,
but
it
but
again
it's
like
a
very
concrete
sense.
A
narrowly
scoped
problem
I
need
to
do
X
and
here's
a
way
for
me
to
do
X.
It
doesn't
get
into
like
the
larger,
more
abstract
problems
about.
You
know
cross-team
strategy
or
resource
expenditure
at
the
organization
level.
C
D
Well,
what
we
were
talking
I
was
just
playing
around
with
the
level
headings
like
what
are
the
questions
that
are
being
asked
at
each
of
these
stages,
so
just
added
those
in
and
they
don't
need
to
stay,
but
like
I
was
trying
to
frame
in
my
head.
What
are
people
asking
her
like
to
me
level?
One
is
like
surely
there's
a
better
way
and
level
two
is
more,
you
know.
Maybe
you
should
try
this
tool.
Instead
This
is
a
people
have
solved
this
problem
in
interesting
ways
and
you
should
consider
it
level.
D
B
Yeah,
well,
that's
a
good
in
let's
move
to
level
three
now
so
actually,
I
kind
of
think
what
you
put
in
four
is
three
here
are
the:
when
my
provider
driven
is
the
platform
provider,
whoever
builds
the
platform,
you
don't
need
the
director
of
it
to
tell
everyone
to
go.
Use
it
like
everybody,
you
know
the
provider
themselves
create
an
atmosphere.
I
want
to
go
use
it.
They
help
me
understand
what
it
is.
They
you
know
meet
my
needs,
they're,
adding
all
the
capabilities
that
I
want.
B
C
One
of
one
of
the
things
I
think
about
too.
With
this
level
three
is
like:
if
level
two
is
a
kind
of
consolidation
among
approaches,
level,
three
is
also
kind
of
a
consolidation,
but
it's
for
a
different
reason.
So,
like
if
level
one
is
hey,
I
figured
out,
I
can
go,
get
an
rkws
account
and
get
a
database
and
level
two.
Is
this
consistency
everybody
use
RDS,
so
I'm
going
to
do
RDS
level.
Three
is
like
hey.
I've
got
an
existing
RDS
database
that
I
created
myself.
C
B
I
definitely
agree
with
what
you're
like
so
like
when
I
was
last
night
trying
to
come
up
with
the
scenario
you
know.
Building
on
that
database
example
was
like:
okay,
not
only
do
I
get
a
database.
It
also
includes
a
standard
backup
plan,
a
monitoring
dashboard,
a
way
to
get
the
service
connections
and
secrets
and
stuff
right.
So.
C
Like
it's
a
level
of
thought
into
this
product
right,
so
if
level
two
is
I'm
using
RDS,
because
I'm
directed
to
use
it
or
because
it
solves
an
immediate
pain
point.
For
me,
level
three
is
like
from
a
kind
of
organic
adoption
perspective.
Maybe
I'm
not
obligated
to
use
it
but
I'm
choosing
to
because
I
can
see
that
it's
got
the
value
there
like.
B
D
A
We're
discussing
about
investment,
one
thing,
I
think
from
two
three:
four:
it's
more
about
data
collection,
kpis,
so
so,
most
likely
between
level
two
and
level
three
there's
kind
of
survey,
because
level
two
is
still
trying
right
and
then
in
level
three
there
are
more
kpis
defined,
so
that's
there's
more
and
that
level
four
is
become
more
automated,
more
comprehensive.
So
that's
why?
If
you
see
the
definition
for
level,
three
kti
is
probably
one
of
the
key
factors
for
level
three.
B
A
B
Yeah,
so
this
is
also
like
the
it's
less
reactive
and
more.
What
are
the
platform
stakeholders
and
what
is
the
organizational
strategy
demand
from
us
here
which
which
that
kind
of
maps
what
we're
saying
I,
think
let's
see
self-sustaining
and
self-marketing,
they
seek
it
out
themselves,
product
manager,
so
yeah
I
think
we
all
agreed
on
that
like
in
this
stage,
you'd
have
a
product
manager.
B
Do
you
all
see?
Do
you
all
see
that
that's
another
thing
I
would
love
some
of
these
example
scenarios
if
anyone's
comfortable,
putting
in
like
an
actual
scenario,
actually
I
have
a
couple
from
customers.
I've
interviewed,
you
know
you
could
put
it
in
anonymously
but,
like
I,
said,
there's
kind
of
room
for
us
to
Define
what
these
sections
look
like.
So
if
we
want
this
to
be,
we
should
go
back
and
discuss.
We
want
it
to
be
a
list
of
characteristics
and
a
list
of
scenarios
alongside
Pros
that
we
could
do
that.
C
C
B
A
F
George
is
a
one
question,
let's
say:
there's
one
question
that
I
see,
let's
say
which
of
the
level
answering
me
this
question.
Just
as
a
as
a
example,
let's
say:
I'm
working
in
an
internal
form,
I'm
a
I'm,
a
product
manager
and
my
team
is
working
on
the
terraform
and
tomorrow
they
migrated
to
the
Cross
plane.
What
sort
of
organizational
shift
I
need
to
make
for
this
new
tooling?
B
B
F
F
If
we
can,
if
we
can
rephrase
the
tool-
but
let's
say
if
you're
using
some
services
and
those
services
are
abstracted
away
from
you
and
there's
the
underneath
tooling
behind
it-
and
you
actually
divide
and
share
responsibilities
on
the
tool
on
the
platform
for
different
teams.
Now
you
are
migrating
to
the
newer
services
and
that
newer
services
are
obstructing
under
newer
set
of
tools
or
the
existing
organization
structure
will
stay
Remains
the
Same,
or
do
you
need
to
do?
You
need
to
actually
migrate
to
the
newest
organization
structure?
So
that's
the
question.
F
Like
if
I
think,
if,
if
let's
say
again,
if
you
can
create
example,
let's
say
if
I'm
using
a
platform
a
and
that
platform
a
is
using
some
abstraction
behind
it
and
that
and
that's
providing
let's
say,
get
off
service
mesh
kind
of
capability
and
I
res
I
actually
organize
my
team
members,
like
this
team
member
using
get
off
stooling
and
they
are
responsible
for
the
service
mesh.
Now
I
migrated
to
the
nether
tool,
and
these
are
same
tooling,
do
and
do
another
two
or
do
another
tool.
F
B
That's
an
interesting
question,
I
kind
of
feel
like
you
might
use
this
maturity
model
to
kind
of
answer
it
like.
If
you
were
at
a
certain
stage
in
the
maturity
model,
then
you
know
and
you're
mandated
to
say,
go
to
Azure
from
AWS
and
use
Arm
instead
of
cloud
formation.
How
do
you
arm
as
Azure
resource
manager,
it's
kind
of
their
equivalent?
So
how
would
you
work
that
into
your
org,
like
I,
If
you're
at
level?
One?
Then
you
just
mandate
it
and
everyone
has
to
figure
it
out
and
just
create
tons
of
technical
debt.
B
B
C
C
It
creates
a
platform
engineering
team,
the
business
hires,
a
product
manager
for
the
team
Etc
are
there
Parts
under
the
adoption
heading
where,
like
a
team,
is
saying
we're
going
to
take
on
ownership
of
this
thing,
because
we
see
a
need
for
it
or
we're
gonna
devote
resources
within
our
team
to
focus
on
Tooling
in
this
area
like?
Is
there
bottom-up
organizational
change
that
we
should
call
out.
B
Who
addressed
that
I?
Think
it's
a
good
one
to
bring
up
the
last
one,
because
maybe
that
is
this
community
enabled
one
where
I
mean
at
least
the
way
that
I
was
thinking
it
was
good
and
that
we
should
discuss
like
the
the
rest
of
the
teams
are
become
more
than
consumers
become
Advocates
become
a
community.
Is
that
what
you're
getting
at
Matt
like
they
might
at
that
point
say
well:
I
need
a
blockchain,
so
I'll
build
a
blockchain
capability
for.
C
Well,
I
think
the
way
I
interpreted
that
kind
of
community
enabled
level
of
adoption
was
like
teams
and
and
individual
people
outside
of
this
kind
of
platform.
Engineering
function
feel
personally
invested
in
the
success
of
the
platform,
and
you
know
contributing
code
changes
back
to
it
and
writing
documentation
for
it
and
selling
it
to
other
people
or
new
hires
whatever.
C
But
it's
it's
interesting
to
think
about
the
bottom-up
organizational
change
things
separately
from
that,
like
you
know
the
stage
two,
maybe
are
there
opportunities
for
teams
to
say?
Oh
the
business
says
everybody
use
RDS
and
so
we're
going
to
focus
energy.
This
person
is
going
to
go,
go
off
and
do
all
of
that
migration
work
or
you
know
how
does
the
question
of
organization
change
in
the
adoption
kind
of
bottom-up
framework
I
think
is
interesting.
I,
don't
know
what
the
the
answer.
B
How
does
organizational
change?
That's?
Okay!
Let's
summarize,
what
same
is
asking
keep
it
in
mind,
you're,
saying
when,
when
that
changes
is
mandated
from
external
forces
like
like
a
like
changing
from
terraform
to
cross-plane
or
Azure
to
AWS,
or
something
like
that,
I'll
do
different
levels
of
maturity,
incorporate
that
or
reflect
it.
F
F
Previously,
in
the
previous
platform,
you
have
a
separate
team
for
the
security
and
the
compliance.
Now
you
adopted
another
platform
that
has
built-in
feature
for
secret
management.
Now
the
question
becomes
in
the
newest
platform:
do
I
need
a
security
and
compliance
team,
or
does
it
become
of
the
job
of
the
platform
to.
B
F
B
Yeah
yeah,
that's
pretty
interesting,
I
I'm
thinking
that
it
may,
but
what
you're
bringing
out
made
may
fit
well
in
interfaces
like,
in
other
words
like,
as
you
get
more
mature,
hopefully,
you've
created
that
abstraction
or
that
interface
that
if
you
replace
the
underlying
implementation,
it
doesn't
necessarily
affect
your
users
like.
If
you
replace
your
security
solution,
it
might
not
be
quite
an
API
but
like
it
would
be
invisible.
Everyone
still
automatically
gets
the
agent
injected
as
a
demon
set
or
whatever
it
is
yeah.
I,
guess
that's
what
I'm
leaning
now
is.
B
Maybe
interfaces
captures
that
let's
I
I
want
to
keep
going
a
little
bit
on
so
back
on
the
third
one,
one
other
thing
which
came
up,
which
I
wanted
to
ask
your
opinions
on
coverage?
Should
we
should
we
mention
coverage
at
all?
Is
there,
like?
You
know
an
erratic?
It's
probably
erratic.
You
know
you
have
a
database
and
you
have
a
blockchain
and
you
don't
have
identity,
let's
say
or
observability
operationalized,
you
know,
I,
don't
know.
Maybe
at
least
you
start
to
know.
Well
that's
databases
or
what
we
need
and
message
cues.
B
C
I
feel,
like
that's
appropriate
here
at
those
stage
three,
because
to
me
it's
that,
like
product
thinking,
that's
going
to
do
that
evaluation
right
stage.
Two
is
like:
oh
you,
you
have
to
use
this
technology
and
then
the
one
team
says,
but
we
have
a
special
use
case,
and
so
the
business
says:
okay,
you
can
use
that
other
technology
and
then
level
three
is
when
the
product
thinking
says.
Hang
on
this
technology
is
lacking.
C
C
B
E
No
I
think
that's
a
good
cause.
I
just
went
and
pulled
up
the
actual
platforms
white
paper
over
kind
of
you
know,
building
this
off
of
and
yeah
it's
a
good
point.
Are
you
talking
about
interfaces?
Well,
yeah,
that's
that's
there.
Do
we
want
to
look
at
you
know
something
like
capabilities
are
a
requirement,
maybe
not
a
concrete
list
of
capabilities
or
specific.
E
D
D
C
Level
three
capabilities,
like
defining
capabilities,
feels
like
a
significant
stepping
stone
in
that
direction,
right
where
everything
should
have
observability,
but
the
definition
of
observability
and
specific
success
criteria,
for
that
is
maybe
level
four
but
saying
observability
is
a
capability
that
we
want
to
have
is
level
three
for
me.
That's.
B
Chargeback
model,
this
might
be
the
stage
where
it
becomes
reasonable.
I
mean
if
you
want,
if
you're,
trying
to
get
people
to
adopt
in
stage
two
you,
you
know
you're
giving
incentives
and
this
you
might
start
charging,
maybe
because
that
shows
the
value
like
I'm
willing
to
pay
you
a
hundred
thousand
dollars,
for
you
know,
operating
kubernetes.
This
quarter.
B
I
might
tie
to
investment,
then
a
little
bit
too
yeah,
let's,
let's
I'll
keep
going.
Let's
go
to
the
last
one.
I
think
that
you
know
our
goals
for
me.
Obviously
we're
talking
pretty
broadly,
although
hopefully
this
all
does
come
back
to
user
adoption
based
on
this
I
think
we
we're
pretty
aligned
in
what
we
want
to
convey
I
think
actually
I'm
kind
of
thinking
Matt.
B
If
you
want
to
take
a
shot
at
just
going
over
what
you've
done
so
far
and
see
if
you
want
to
update
it,
and
maybe
that
can
be
the
foundation
of
the
of
the
prose
text
and
then
we
can
accept
that
in
and
then
iterate
from
there
but
yeah.
Let's
keep
going
down
to
the
last
one
here
so
I
see
you
at
I
think
it
must
be
Marsh
right
between.
D
D
That
yeah,
participatory,
so
I
I,
didn't
feel
I
felt
like
Community
was
too
again,
like
the
platform
team
is
still
driving
things
right
to
me,
though
I
think
what's
mattering.
What
matters
here
is
that
it's
participatory,
Community
didn't
feel
like
the
right
word
to
me
here,
but
we
can
keep
playing
with
them.
B
C
Mean
I
think
that
the
metaphor,
inner
source
is
used
here
and
I.
Think
that's
a
lot
of
like
a
lot
of
this
feels
very
parallel
to
open
source
communities
and
their
success
right.
So
if
stage
three
is
there's
a
product
roadmap,
maybe
stage
four
is
like
the
product
roadmap
is
very
public,
and
people
cannot
vote
down,
vote
things
or
contribute
to
the
planning
process,
as
well
as
contributing
code
back.
E
D
B
C
C
C
Yeah
I
think
the
the
timing
is
also
very
interesting
because,
if
level
three
is
sort
of
like
okay,
we
there's
a
platform
as
a
product
group
platform
manager
or
product
manager.
Engineers
who
are
looking
at
what
teams
are
doing
today
and
working
on
ways
to
improve
what
they're
doing
today
level
four
is.
A
Get
into
the
platform
team
also
adopting
industry
standard,
because
what
I
find
is
in
open
source
Industries,
there's
a
lot
of
standardization
effort
going
on
so
maybe
in
level.
Four,
that's
adopt
standards.
That's
that's
how
you
can
get
data-driven
approach
and
stream
aligning
the
features.
Etc
automations.
B
C
E
Well,
to
that
point,
I
mean
it's
the
same
thing
I
run
into
in
the
security
space
with
you
know,
devops
versus
devsecops,
and
where
we
get
involved
in
the
process
and
all
of
a
sudden,
we
get
a
developer
that
didn't
know
who
to
talk
to
that
comes
to
us
18
months
into
a
project
and
we're
like
all
right
all
right.
Well,
you
did
everything
wrong.
You
know
yeah.
D
C
C
B
I'm,
okay,
with
everything
we've
got
here,
except
one
thing:
I'm
not
clear
on
is
the
measurement,
so
the
measuring,
so
in
this
fourth
stage,
I'm
driven
to
adopt
because
I'm
part
of
the
the
program
I
do
see
the
need
to
measure
that
is
a
category
of
its
own.
That,
like,
as
we
get
more
mature,
we
will
have
better
ways
of
measuring,
is,
is
measuring
related
to
adoption
or
is.
D
B
D
B
B
Okay,
so
we
are
getting
really
close
to
time.
I
can't
go
too
much.
I
can't
really
go
over,
so
our
I
guess,
let's
make
sure
everyone's.
You
know
we're
in
a
reasonably
aligned.
We
don't
have
a
ton
of
time
to
talk
over
more
Matt.
If
you
want
to
go
ahead
and
update
your
edits
and
I'll
and
we'll
take
those
as
the
first
paragraph
we'll
leave
it
just
leave.
It
I
think
for
now
the
characteristics
that
we
discuss.
B
Example:
scenarios:
they
might
not
go
on
the
final
doc,
but
let's
leave
them
for,
and
people
can
add
you
know
if
you
think
of
some
more
characteristics
you
want
to
add
for
us
to
think
about,
but
then
we'll
have
Matt
write
those
paragraphs
I'll
accept
them
in
pretty
much
Matt
If
You're
Happy,
and
then
we
can,
but
then
we'll
we'll
comment
on
from
there.
So
at
least
we
have
a
place
to
start
from
great
yeah
I'll
try
to
do
about
dinner.