►
From YouTube: 2023-08-29 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
B
B
C
B
Right
we
got
a
good
crowd,
all
right,
let's
get
rocking
and
rolling.
Does
everyone
have
the
link
to
I'm
going
to
post
it
in
chat
here
regardless,
but
though
I
posted
a
link
to
the
in
progress
platform,
maturity
model,
if
you're
not
already
in
the
WG
platforms
channel
in
the
cncf
slack,
please
join
please
jump
in
there.
E
B
So
again,
so
Abby
and
Josh
have
some
conflicts
for
the
first
part
of
this
meeting,
but
they're
going
to
show
up
at
about
the
30
minute
Mark.
So
we're
gonna
dive
in
and
just
try
to
get
a
little
bit
of
an
agenda
going
and
figure
out
what
we
can
tackle
in
the
meantime
before
they
come
in
so
otherwise
I'll
be
facilitating
to
start
and.
F
B
E
F
B
G
B
E
B
B
As
far
as
how
much
advice
should
we
give
on
things
like
Cloud
native
maturity
and
things
like
that,
just
like
the
overall
scope
of
the
paper
itself
and
we've
been
talking
with
cartographers,
who
does
the
cloud
native
maturity
model
and
we're
collaborating
with
them,
and
so
I
actually
kind
of
work
between
the
two
groups
a
little
bit
and
part
of
the
goal.
There
is
for
folks
that
are
going
through
a
cloud
native
journey
and
they're
still
a
ton
of
them.
H
B
H
B
Platform
might
not
be
for
everybody,
but
when
somebody
does
reach
a
certain
level
of
maturity,
it
would
be
great
for
them
to,
instead
of
rehashing
the
entire
maturity
model
as
a
part
of
a
larger
scope
of
the
cloud
native
maturity
model,
just
direct
people
to
our
conversation
for
platform
maturity
and
things
there.
So
there
is
a
an
intentional
effort
with
the
cloud
native
maturity
model
to
provide
more
of
a
high
level
summary
of
the
platform
maturity
model
and
integrate
it
with
their
material
as
well.
B
G
E
E
B
F
E
Yeah
look,
I
I,
don't
spend
as
much
time
in
platform
engineering
land
as
I
think
a
lot
of
people
on
the
call
I
tend
to
come
and
do
it
where
it
intersects,
with
API
management
and
and
so
I
the
what
I
can
bring
is
some
outside.
In
view
of
how
this
hit
me
as
a
reader,
and
so
when
I
saw
this
as
a
focusing
on
development
release,
it
made
me
feel
like
we
were
we're
missing
the
operations
piece
that
I
think
is
very
much
part
of
this
platform
goal
and
I.
E
Think
the
other
piece
was.
You
know
how
how
do
how
does
API
management
intersect
with
this,
and
that's
mostly,
my
my
world
view,
so
that's
I,
think
the
challenge
of
having
this
quote
to
start
things
off
is
that
it
helps
frame
the
discussion
later
and
so
maybe
there's
a
different
quote
to
have.
Maybe
we
need
to
to
talk
about
that
more,
but
that
that
was
my
observation
and
why
I
made
the
comment
here.
E
Repeat
it,
yeah
I
was
just
saying
that
like
because
this
quote
is
framing
some
of
it's
meant
to
you
know,
help
provide
context,
I
think
for
the
rest
of
the
discussion
that
this
that
the
scope
of
this
it
seems
a
little
narrower
than
what
we're
trying
to
do,
and
that's
a
challenge
of
the
quote.
So
I
don't
know
that
we're
going
to
resolve
that
today
right,
it's
just
an
observation
to
consider
whether
we
can
find
a
better
one.
B
F
Yeah
I
mean
I
I,
like
the
quote
overall
I
think
it
could
just
be
like
you
know
how
you
can
sort
of
like
inject
stuff
into
quotes
by
using
the
brackets.
It
could
just
be
like
development
operations
and
release-
that's
maybe
two
mundane,
but
something
that
makes
it
or
even
just
using
like
a
broader
term.
Something
like
that.
F
A
G
B
B
So
if
this
is
the
maturity
model,
then
our
some
of
our
quotes
should
be
in
context
for
improving
increasing
maturity,
and
we
definitely
need
to
reinforce
the
importance
through
some
of
these
quotes,
but
in
this
in
this
case,
it's
almost
it's
just
like
one
example,
but
at
what
point
do
we
also
just
refer
back
for
like
prefer
the
reading
or
other
examples
or
a
list
of
capabilities?
See
the
white
paper
refer
back
as
well.
E
B
G
B
E
E
Yeah,
it's
an
interesting
question,
but
I
don't
think
it's
going
to
make
today's
discussions.
Productive
and
I.
Don't
think
we
can
change
it
at
this
point.
Okay,
it's
just
I
think
good
to
be
mindful
that
platform
engineering
is
is
difficult
to
pin
down
at
times
like
the
the
meeting.
Is
it's
one
of
the
things
that
you
could
apply
in
lots
of
different
ways
and
I?
Think
it
that's
it
there
isn't
enough
consensus
around
this,
so
what
I
think
the
general?
E
B
E
H
E
B
You're,
mentioning
here
like
the
like,
the
evolution
of
devops
I've,
got
a
little
image,
I'm
just
going
to
paste
in
really
quick
and
then
delete
from
the
paper,
because
I
don't
want
to
include
it
necessarily.
But
this
is
from
one
of
the
reports
that
was
out
I
can't
remember
it
was
Fairwinds
or
somebody
else
talking
about
like
The
devops
evolutionary
model,
and
it's
it's
interesting
to
me,
because
this
is
coming
from
the
devops
mindset
in
a
devops
focus.
B
One
of
the
first
I
think
we
talk
about
this
in
the
operations
Deep
dive
a
little
bit
too,
but
devops
is
kind
of
one
of
the
first
groups
that
starts
to
mature
and
develop
into
this.
But
it's
because
we're
adding
additional
capabilities.
Beyond
devops
and
like
introducing
capabilities
for
software
engineers
and
even
data
platform,
folks,
right
and
I
guess
AI
deserves
to
be
in
there
somewhere
or
people
that
have
specific
roles
that
need
to
participate
in
the
same
sandbox.
And
so
it's
interesting
to
me
in
that
report.
B
It
makes
perfect
sense
right,
we're
going
to
go
from
expanding
our
practices
to
Automation
and
then
providing
self-service
capabilities.
That's
like
the
the
level
of
maturity
that
changes
there
I,
but
I,
that's
in
the
context
of
devops,
but
I
think
it
hits
your
comments
a
little
bit
of
being
able
to
talk
about
and
did
it.
It
didn't
just
delete
your
comments
right.
Where
did
those
go.
E
Automate
infrastructure
delivery.
Like
again
this
is
missing
the
observability
piece.
The
and
the
operations
pieces
like
it
seems
overly
specific
to
some
degree
right
anyway.
I
think
our
goal
is
that
platforms
are
big
spaces
and,
and
what
are
the
things
I
like
about?
This-
are
providing
the
self-service
capabilities
and
standardize
and
reduce
variability.
E
I.
Think
it's
not
just
like
December
is
also
normalizing.
The
technology
stack,
but
this
is
really
about
creating
repeatable
outcomes
at
scale
and
so
right.
Here's
our
chance
to
say
this
and
frame
it
and
so
I'm
happy
to
dive
in
I.
Just
I
was
trying
to
flag
these
things
as
I
read
through
it
as
areas
where
we
could
improve.
B
B
C
B
B
H
Yeah
it
just
I
guess
the
I
should
have
put
why,
but
the
reason
I
was
thinking.
Is
it
just
felt
a
bit
jolting
to
go
from
there
to
then
what
is
platform
engineering
and
then
back
to
like
the
constructs
of
the
the
model,
so
it
seems
like
we
did
like
a
bit
of
an
intro
on
some
things
and
so
I
just
didn't
know
if
that
was
like
it's
useful
to
set
the
context
like.
B
And
we
were,
we
were
just
talking
about
before
that.
So
Marsha
had
good
comments
about
the
the
quote:
that's
up
above
the
Improvement.
It's
about
improving
developer
experience.
Is
that
too
narrow
for
that
section,
but
does
it
does
it
set
too
narrow
of
a
tone
for
the
rest
of
the
paper
to
a
degree?
But
then
the
other
comment
there
is
that
it's
interesting
that
we
we
add
all
this
color
and
then
we
talk
about
target
audience
and
then
we
talk
about
what
is
platform
engineering
and
like.
H
And
I
put
a
possible
solution
which
I
should
have
put
basically
more
of
the
issue,
which
is
that
it
does
feel
out
of
ordered
in
some
way.
Like
all
the
content
seems
sensible,
like
I
agree
with
your
comment
by
the
way
Marsh
on
the
the
quote
so
like
while
I
say
it
all
seems
sensible,
I,
don't
think
it's
final
yet,
but
it's
sensible
right,
it's
close,
but
there's
something
about
the
order
that
felt
wrong,
which
is
why
why
I
had
that
comment.
So.
B
B
H
B
G
G
Yeah
I
think
in
in
the
details.
When
I
look
at
what
we've
been
discussing
it,
it
seems
we
do
mix
it
a
little
bit
up
like
sometimes
we
we
go
more
into
like
the
maturity
of
the
platform
like
with
interfaces,
I,
guess
right
and
then
in
other
sections
we
might
be
more.
Focusing
on
the
processes
and
and
I
mean
you
could
say,
processes
are
part
of
a
system
right
people
are
part
of
the
system.
That's
why
my
professor
always
used
to
tell
me
information
science.
G
H
Engineering,
that's
my
soft,
that's
my
soft
preference
and
so
like,
but
it
is
just
a
soft
preference,
but
the
reason
I
think
it's
a
soft
preference
is
because
I
believe
that
there
is.
There
are
ways
you
can
be
doing:
platform
engineering
before
having
a
like
concrete
platform
that
might
meet
some
of
the
maturity.
Conversations
that
we're
having
right.
D
Yeah
from
my
side,
I
I,
when
I
was
thinking
through
this
last
week,
when
I'm
going
through
platform
engineering
seemed
to
be
a
more
adaptable.
For
me,
the
reason
is
that
once
you
announce
it
as
in
platform,
maturity
model
and
you
are
giving
an
a
confusion
right
away,
that
what
are
we
referring
to
their
random
many
things
we
considered
as
a
platform,
so
it's
an
engineering
platform
so,
like
anything
like
there
are
many
namings.
Even
if
you
just
go
on
Google
and
search
platform.
D
Maturity
model,
like
you,
see
entirely
different
architecture,
some
kind
of
random
things
you
see.
So
we
are
definitely
into
the
engineering
discipline
and
we
are
planning
for
a
maturity
model
around
it.
So
adding
that
engineering
might
change
the
meaning
of
platform
engineering,
but
but
still
keeping.
That
will
give
a
more
context
and
audience
to
come
directly
to
the
model.
H
B
B
You
don't
have
a
platform
team,
probably
right
now,
when
you're
evaluating
the
platform,
maturity
model
or
the
maturity
of
a
platform
that
you
have
in
place.
It's
probably
something
that
you
choose
to
build
as
part
of
your
investment
right.
You
move
people
into
new
roles
or
establish,
and
so
from
just
personally
for
me
having
a
good,
clear
understanding
of
what
your
platform
Journey
needs
to
look
like,
or
even
what
your
platform
needs
to
look
like.
It's
so
I
mean
doing.
That
is
the
act
of
platform
engineering,
but
I.
I
Yeah
I'm
just
going
to
build
on
what
Colin
said
there
a
little
and
both
platform
and
Engineering
I
think
are
very
different
for
different
teams,
and
so
that
I
think
you
know,
adds
to
the
complexity
and
ambiguity
here
and
then
you
throw
security
into
that
mixed.
And
then
you
know
you
have
like
so
many
more
and
so
I
think
it's
important
to
identify
those
base
characteristics
that
we
are
targeting
when
we
say
platform
engineering
depending
on
you
know,
team
size,
and
so
so
many
other
heuristics
and
say
well,
our
definitions.
I
You
know
sort
of
apply
to
these
designs
of
platforms
and
teams
and
software
and
sizes
Etc,
and
so
if
we
can
narrow
it
down
that
way
and
put
the
definition
within
those
specific
conditions
in
which
it's
supposed
to
work,
I
think
it
might
look
better.
That's
it
so
and
I
mean
in
summary,
I
think
what
I'm
trying
to
say
is
it's
by
Nature
a
rather
complex
and
ambiguous
term.
So
we
might
hear
so
many
different
opinions
and
all
of
them
might
be
true.
B
H
B
A
quick
little
thing
to
build
on
that
too.
If
I'm
looking
at
target
target
audience,
would
it
be
helpful?
We've
got
app
Dev
there,
and
we
just
had
a
discussion
about
you
know-
is
application
development
and
that
a
little
bit
too
narrow,
but
should
we
include
platform,
Engineers
or
platform
engineering
as
like
an
audience
of
this
paper.
H
It's
one
of
those
like
how
much
of
a
list
do
you
need
I
think
what
I
find
really
interesting
about.
All
of
the
suggestions
like
between
platforms
and
platform
engineering
is
I
actually
heard
the
exact
same.
If
I
heard
correctly,
the
exact
same
kind
of
concern
on
both
sides
of
the
fence
and
I
think
that
both
are
extremely
valid.
H
Further
further
further
Define
yeah
yeah
I
hear
it
so
I
think
my
my
gut
reaction
right
now
is
that
this
is
a
hard
thing
to
Define
and
a
hard
thing
to
clarify.
But
I
haven't
heard
I.
Don't
think
anybody
on
this
call
or
previous
calls
want
to
limit
this
document
to
technology.
Only
like
just
adds
like
as
an
ethos
like
as
what
we're
trying
to
achieve.
We
want
to
include
the
people
in
the
process
and
the
organization
in
to
the
document
and
so
I.
G
Yeah,
it
was
actually
also
gonna
agree
with
you
Abby
in
in
terms
of
like
keep
it
and
you,
you
said,
like
I,
think
two
or
three
times
there's
like
people
process.
What
was
it
private
process
technology?
Maybe
we
just
add
that
to
that
to
this
paragraph
right
that
this
includes
people
like
just
make
it
really
clear
that
we
mean
the
whole
Shaban.
H
Yeah
and
I
think
that,
like
yeah,
Colin,
I
think
you're
right
to
add
another
section,
I'm
wondering
if
it's
something
I'm
just
gonna
add
another
sub
comment.
We
can.
We
can
deal
flesh
this
out
in
a
minute
like
after
after
the
call
or
whatever,
but
something
like
or
like
why,
engineering
and
not
platforms
or
something
like
that's
a
terrible
sentence.
But
basically,
if
there's
like
a
subcategory
of
basically
saying
what
is
platform
engineering,
why
does
this
model
focus
on
platform
engineering
and
not
the
outcome
of
platforms?
H
It's
because
and
then
Puja
to
your
point
like
because
we
want
to
call
attention
to
the
fact
that
this
is
a
socio-technical
problem
that
requires
people,
process,
org,
etc,
etc.
Right
and
so
we've
had
lots
of
conversation
about
this,
and
this
is
a
really
good
trigger
for
the
fact
that,
like
I
think
we
talk
a
lot
about
how
we
all
get
the
most
benefit
out
of
putting
out
these
papers
like
everyone
else
who
reads
them
think
they're
great,
but.
H
It's
these
calls
that
are
like
where
we
do
all
the
learning
and
and
refining,
and
that's
a
that
socio-technical
concept.
We've
talked
a
lot
about,
but
we
haven't
actually
written
in
here,
and
this
is
a
really
good
way
for
us
to
tie
back
in
some
of
our
learnings
and
our
discussions
into
the
paper.
So
yeah.
G
By
the
way,
I'll
mentioned
it
before
you
join
Debbie.
Is
there
a
way
of
us
marking
some
thoughts
for
like
a
V2
of
the
white
paper,
because
I
think
we
are
we're
like
sometimes
going
in
a
direction
of
like
sometimes
wanting
to
add
things
to
that
are
not
in
the
white
paper
that
we
could
like
already
Mark
for
ourselves
for,
like
oh
yeah,
next.
B
G
B
H
H
It's
been
done
already,
since
it
was
released
and
I
think
the
intention
is
is
to
enable
those
kinds
of
PRS
that
are
maybe
smaller
in
nature
and
I
think
the
ones
that
maybe
would
be
like
in
changing
our
like
world
view
are
welcome,
but
maybe
it
would
be
more
like
issues
rather
than
than
with
a
PR
of
course,
but
like
with
just
making
sure
to
basically
give
a
big
context
as
to
why
that,
like
change
in
world
view,
view
has
happened,
but
yeah.
We
definitely
view
it
as
something
that
we
want
to.
H
We
don't
want
to
just
stop
in
like
a
year
and
be
like
all
right
rewrite
like
we
want
to
enable
people
to
to
give
their
opinions
and
improve
things
as
we
go,
and
and
people
who
are
happy
to
take
early,
adopting
versions
of
the
white
paper
can
do
that,
and
people
who
are
happy
to
take
the
more
stable
version
can
do.
Do
that
as
well,
so
cool
Colin's
already
written
everything?
Oh
Marsha's,
writing
everything
cool!
Well,.
E
H
I'm
gonna
I'm
just
gonna,
throw
that
in
now
I'm
a
big
fan
of
like
we
want
something
to
then
comment
on.
If,
if
everything's
always
a
suggestion,
then
it's
hard
to
like
actually
make
comments
on
it.
So
I
think
that's
a
great
straw
man
and
we
start
there
and
we
we
make
comments
from
there.
So
thank
you
very
much
for
adding
adding
that
context
to
it.
H
E
H
Or
you
know
whatever
I
was
just
curious.
I
know
that
we
have
some
of
the
authors
of
different
of
the
sub
sections
here,
and
there
was
a
lot
of
questions
around
that.
Like
consistency
across
that,
where
did
you
have
a
a
game?
Did
the
team
have
a
game
plan
about
the
amount
of
time
on
the
intro
versus
on
sort
of
the
the
detailed
sections.
B
So
we
were
just
gonna
Hammer
through
some
of
the
comments,
some
of
the
existing
comments
in
the
paper
itself
and
then
we
were
going
to
jump
into
investment
and
operations.
We
already
lost
sorry
so
yeah.
We
can
talk
about.
He
put
some
comments
in
there
too,
but
we
can.
We
can
talk
about
that
or
we
can
just
jump
into
Ops
as
well,
but
cool
it
looks
like
there
might
be
some
more
some
more
comments,
Puja
I,
think
I'd,
say
I,
hope,
you're,
saying
your
name
right.
G
H
Yeah,
it's
just.
It
was
a
I
think
that
was
a
leftover
from
V
like
zero
zero
one
of
like
talking
about
example,
implementations
and
how
that
that
sort
of
shifted
in
our
intentions
in
the
talk
so
I'm
just
sort
of
leaving
that
comment
that
the
intention
there
is
maybe
to
leave
the
comment
there.
Until
until
we
have
the
detailed
sections
a
little
bit
clearer
because,
like
basically
that
would
be
used.
H
H
H
I
think
the
other
ones,
what
that
are
really
like
high
value.
Are
this
like,
as
we're
going
through
the
details,
sections
we're
finding
that
sometimes
the
words
in
the
table
aren't
quite
what
we
were
hoping
for
right
and
that's
that
was
natural.
That
was
expected
that,
like
we
wanted
to
have
that
as
stable
as
possible,
so
that
we
we
had
confidence
that
the
The
Arc
that
we
were
providing
as
a
model,
but
that
doesn't
mean
that
a
single
word
was
always
going
to
be
perfect.
H
B
E
E
B
E
G
G
What
I
kind
of
like
about
interaction
is
that
it
captures
also
the
non
the
non-technical
interface
like.
Maybe
even
the
process
right
like
you
could
fold
in
a
bit
of
process
in
there,
because,
if
you're
interacting
and
you
like,
even
if
it's
an
automated
process
and
an
API
call,
if
you
need
to
fill
out
15
pages
of
form
until
you
get
a
VM,
that's
most
probably
not
a
delightful
interaction
for
you.
H
That's
going
to
get
copy,
pasted
everywhere
right,
so
making
sure
that
we
trigger
the
right
words
and
the
right
thinking
up
front
is
is
why
we
put
so
much
time
energy
into
getting
the
table
kind
of
refined
and
and
there
so
I'd
be
interested
at
tool.
Are
you
there
since
you're,
not
on
video
I?
Don't
know
if
you
you're,
taking
a
break
in
our
two
hour
marathon
call
here,
but
I'd
be
interested
since
you
were
working
on
that
detailed
section.
If
you
have
any
insights
on
interface
versus
interaction.
H
Probably
taking
a
short
break
which
is
well
earned
with
a
two-hour
call,
but
we'll
try
I
think
Marsh.
Are
you
cool
with
leaving
that
comment
there
and
like
because,
like
some
of
these
other
comments
on
the
table
have
been
there
for
a
kind
of
a
week
and
people
have
been
noodling
on
it?
We
can
do
the
same
thing
with
that
comment.
Leave
that
there
give.
H
H
H
Group
on
the
last
call
we're
super
Keen
to
to
see
a
bit
of
an
improvement
there
and
I
think
where
we
landed
was
robust
contracts.
Well,
that
is
where
we
landed.
For,
Better
or
For
Worse
and,
like
I,
think
that
the
conversation
was
around.
We
didn't
want
the
technical
implementation
side
of
things
to
be
a
requirement.
So
in
the
detailed
sections
we
can
talk
about
technical
apis
without
it
being
like
the
the
headline
for
the
Box.
H
Basically-
and
there
was
a
late
Dark,
Horse
I
think
right
at
the
end
of
the
conversation
that
talked
about
integrated
as
a
service
capabilities
or
some
some
form
of
as
a
service
capabilities
in
there,
but
how
the
power
people,
feeling
after
a
week
of
having
robust
contracts
in
there
is
that
feeling
good.
Is
there
something
else
that
feels
better.
G
H
G
E
I,
just
struggling
to
get
traction
on
it,
I
think,
is
what
it
is
robust
contracts
just
to
tell
me
what
it
means
like
to
me:
it's
not
obvious
it's
not
nearly
as
obvious
as
some
of
the
other
words
in
these
other
cells,
and
so
what
does
it
mean?
Explain
it
because,
maybe
there's
a
simpler
way
to
say
it.
H
E
Let
me
look
at
the
transition
here.
We
go
from
bespoke
processes
to
supported
Solutions,
to
self-service,
used
to
be
self-service
Solutions,
but
the
self-service
so
I
can
see
that.
So
what
does
that
mean?
It
means
I
can
discover,
for
instance,
an
internal
developer
platform
and
begin
to
participate
in
that
way,
but
then
I
think
the
next
phase
is
really
about
making
sure
you're
building
into
the
developer,
workflows
that
are
going
to
make
them
more
successful
with
less
effort
meet
them
where
they
are
and
to
do.
E
H
F
E
Yes,
yeah,
yes,
I!
Think
that's
right!
So
something
about
this
is
about
scaling
it
right.
So
it's
great
that
it's
self-service,
but
if
I,
if
it's
not
meeting
me
where
I
am,
if
I'm,
not
if
I,
don't
I,
think
the
API
having
the
API
for
the
platform
is
a
means
to
the
end
here,
I
think
the
the
issue
isn't
having
robust
contracts.
It's
it's
that
you've
you've
gone
the
full
distance,
so
that
is
integrated
into
developer
workflows.
E
H
And
that
that
does
actually
so
I
think
that
with
self-service
at
scaled,
it
is
still
like
one
of
the
things
that
we
were
talking
about.
The
detailed
section
is
at
that
stage.
It
could
still
be
like
templates
and
things
like
that
which
which
are
self-service
but
are
maybe
difficult
to
use
or
put
a
lot
of
pressure
on
the
developer.
The
application
end
users
to
understand
terraform
and
Helm
and
whatever
it
is.
E
E
If
you
come
back
just
to
jump
in
from
what
you
said,
the
the
to
me,
the
the
motion
is
inconsistent.
When
we
get
to
robust
contracts,
bespoke
processes,
supporting
capabilities,
self-service
capabilities,
and
then
we
go
to
the
solution,
which
is
robust
contracts
that
doesn't
feel
right
to
me.
So
we,
what
is
the
yeah?
Well
Integrated
Solutions
works
for
me
that,
like
they're,
this
is
made
possible
through
apis
I.
Think
we
break
that
out
in
the
detail.
That's
where
I
was
trying
to
get
at.
H
I
think
integrated
so
I
if
we're
gonna
go
that
way.
So
I
agree
with
the
the
call
out
right.
We
and
we've
found
a
few
of
those
where
we
went
to
how
not
why
and
it's
like
shoot
all
right,
pull
ourselves
back
right,
which
is
a
good
shout.
I
would
like
to
look
look
to
use
that
as
a
service
kind
of
concept.
H
H
But
that
still
require
me
to
run
database
migrations
and
upgrades
and
things
when
I'm
a
software
developer,
that
just
couldn't
care
less
I
just
wanted
access
to
SQL
store
like
what
are
you
doing,
and
so,
if
I,
if
I,
take
integrated
to
the
extreme
right,
so
I
agree
that
Integrity
doesn't
have
to
mean
that.
But
that's
what
I
worry
that
word
lends
itself
more
to
versus
when
I
look
at
as
a
service
and
I
take
it
to
an
extreme
I.
H
Think
of
that
sort
of,
like
you
know,
deliveroo
I,
don't
know
what
countries
of
people
in
like
Netflix,
like
you
know
these,
like
great
Amazon
Prime,
like
all
these
like
services,
that
just
they
take
care
of
everything
behind
the
scenes
and
all
you
do
is
say
what
you
want
to
like.
Actually
interface
with
and
then
like
you
can
move
on
and
focus
on
your
tier
of
the
of
the
solution
right.
H
So,
instead
of
having
to
understand
the
whole
stack,
it's
like
you
can
depend
on
services
that
then
you
can
build
on
top
of
without
having
to
fully
understand
or
engage
with,
which
is
I.
Think
why
the
original
implementation,
or
the
original
word
was
around
apis.
That
idea
of,
like
separating
the
concerns
and
I,
think
as
a
service
might
be
a
less
implementation
version
of
that.
Maybe
maybe.
G
I
might
want
to
get
an
integrated
like
high
level
capability
out
of
the
box
right
instead
of,
like
choosing
to
say,
I
need,
I,
don't
know
Flagger
and
observability
and
a
service
match.
I,
say
I
need
Progressive,
rollouts
and
the
platform
hopefully
has
a
setup
pipeline
for
me.
That
gives
me
that,
no
matter
what
kind
of
low
level
capabilities
and
features
that.
H
So
another
option
would
be
integrated
services,
so
we
basically
move
away
from
so
we've
used
like
capabilities
or
Solutions
in
the
past
and
I
know
that
there's
some
shifting
of
that
language
in
the
previous
two,
and
we
can
have
that
conversation
at
some
point
but
like
Services,
brings
into
concept
where,
when
we
get
into
the
details
behind
what
is
a
service,
we
get
to
dig
into
that.
But
it
brings
that
into
the
Forefront
and
integrated
brings
in
the
Forefront.
H
You
know
what
Marsh
was
saying,
but
bringing
it
to
the
people
right
and
not
like
out
of
their
workflows
I'm
getting
some
nods
that
I've
at
least
heard
Puja.
So
other
people
feel,
like
that's,
captured
the
intention
of
what
we've
been
talking
about
today.
If
we
were
to
sort
of
set
a
new
bar
in
the
sand
of
integrated
services,.
A
From
the
infrastructure
point
of
view,
so
just
to
really
the
move
from
like
virtual
machine
to
container
now,
possibly
to
webassembly
right
so
be
staying
well,
integrated
doesn't
mean
it's
going
to
adapt
into
the
new
technologies.
Should
that
be
even
more
and
even
another
layer,
a
maturity
level,
probably
being
adaptive.
Innovative,
Cutting,
Edge.
H
It's
more
that,
like
those
feedback
loops,
that's
what
you
really
want
to
get
people
like
thinking
about,
because
if
they
have
the
feedback
from
their
people,
then
they're
they're
going
to
be
exactly
the
right
technology
for
their
organization
and
and
for
some
that
will
mean
taking
that
leap
into
wasm
sooner
than
others
and
for
others
it
will
be
no,
no
we're
a
Mainframe,
that's
how
we
run
this
bank
and
like
that's
just
what
they
have
right
and
that
might
not
be
a
bad
thing
for
them.
There's.
B
It's
not
going
to
say
that
directly,
but
it's
it's
covered
in
adoption
and
like
operations
a
little
bit
as
well
kind
of
in
the
content,
because
if
it's
product
driven,
if
we're
trying
to
identify
it
and
continuously
provide
new
capabilities
based
on
demand
from
the
users
of
the
platform
and
having
a
product
mindset,
then
you
know
if
I
need
a
new
type
of
tool.
That's
going
to
come.
If
I
have
mature
adoption
and
operations
of
the
platform.
C
B
B
Right
by
by
proxy
with
the
other
horizontals,
but
you
know
I,
think
there's
a
thing
in
there
that
I'm
thinking
about
kind
of
on
the
same
vein,
I
feel
like
integrated
services
and
well
Integrated,
Solutions
I,
think
they're
touching
on
it,
but
they're
still
a
little
open-ended
I
feel
like
you've
got
a
like.
You
have
a
well-defined
platform
at
this
point
like
I,
almost
want
to
be
able
to
say
like
in
in
web
dev.
B
As
the
platform
and
it
let
the
developers
in
context,
understand
like
I,
need
to
look
at
the
capabilities
of
the
browser
and
the
specifications
and
the
rules
and
contracts
to
find
and
like
what
the
w3c
says
and
like
everything
as
a
whole
was
referred
to
as
the
web
platform
or
the
platform
they
even
dropped.
Web
and
I
want
to
my
optimized
phase.
I
want
to
have
the
platform
I
want
to
have
like
a
well-defined
platform
that
yeah.
C
H
I
think
we
talk
about
discoverability
and
we
talk
about
usability.
One
aspect
of
usability
is
like
a
consistency
in
how
you
access
and
manage
things
right.
So
I
hear
a
lot
of
what
you're
saying
in
there
about
that,
but
I,
don't
but
I
think
there's
a
lot
of
at
companies
of
scale.
The
platform
tends
to
fall
apart.
H
I,
don't
think
I've
heard
anyone
Advocate
that
it's
backwards
from
robust
from
API
contracts
or
robust
API
contracts
or
robust
contracts
or
or
some
version
of
those.
So
what
I'm
going
to
propose
is
that
we
put
integrated
services
on
the
table
and
then
allow
for
for
like
Colin
as
you
get
like
a
deeper
thought
on.
You
know
what
you're
looking
for
in
that
spot
and
whatever
like
that's.
What
comments
are
for
and,
and
please
add,
more
things
but
I'm
gonna.
H
H
What's
the
what's,
the
general
movement
of
the
team
and
that
kind
of
stuff,
so
I
am
gonna,
accept
integrated
services
and
get
rid
of
the
other
two
for
now
and
again
comments
comment
away,
but
we'll
start
there
all
right,
I,
think
one
thing
that
would
be
too
bad
is
that
we
spend
a
lot
of
time
on
the
table
and
they're
still
refinement
to
be
done.
But
wordsmithing
is
hard
and
very
time
consuming
and
will
eat
as
it
will
goldfish.
It
will
take
up
as
much
space
as
we
give
it.
H
So
what
I'm
thinking
is
we
have
a
lot
of
people
around
that
are
trying
to
dig
into
the
detailed
sections
and
I
think
that
there's
some
really
interesting
differences
if
I
just
cycle
through
the
detailed
sections
like
how
long
are
the
sections
that
people
are
writing
what
kind
of
tone
of
voice
like
what
is
the
like?
How
like
what?
H
What
by
Tone
like
how
yeah
tone
and
then
also
like
outcomes
versus
techniques
and
tools
and
processes,
and
so
I'd
like
to
like
maybe
I,
have
a
couple
of
questions
that
might
prompt
good
conversation
in
my
head
from
me
reading
through
them
all,
but
I'd
like
to
first
open
the
floor
for
anybody.
Who's
been
working
on
the
detailed
sections
to
like
raise
a
question
that
they
have
to
make
sure
that
we
touch
on
the
things
that
are
making
people
who
are
focused
on
those
sections
on
uncertain
or
unsure
about
stuff
yeah.
H
So
does
anyone
who's
been
working
on?
Details
have
something
from
like
a
standardization
point
of
view
that
they
want
to
talk
about
and
then
we'll
dive
into
more
detail
than
that
as
well.
But
I
want
to
start
with
standardization
that
might
be
applicable
across
all
the
detailed
sections.
Then
we
can
dive
into
any
questions
about
your
section
in
particular
of
like
I.
Don't
understand
this,
you
know
this
words
or
I.
Don't
something
like
that
foreign.
A
H
Good
question
so
merged
anything
from
the
last
two
into
one
or
anything
like
measurements.
A
brand
new
idea
that
wasn't
on
any
table
previously
I
think
I'd.
Is
this
a?
Is
this
a
concern
with
more
people
on
the
call,
because
I'd
sort
of
like
to
to
take
this
conversation
and
shift
it
so
that
we
take
advantage
of
everyone
who's
working
on
the
detailed
sections?
But
if
everybody's
sitting
here
going,
what
the
heck
is
this
model?
And
why
is
it
five
things
and
not
seven
things
then
like.
H
D
So
maybe
like
a
better
focusing
on
the
detail
section
because
of
the
the
timeline
perspective
and
because
also
the
these
are
the
five
different
people
working
at
the
same
time,
into
five
different
levels
of
understanding
on
the
platform,
the
model.
So
maybe
we
can
take
one
one
of
it,
which
is
thoroughly
defined
at
least
that
we
all
feel
like
we
can
Define
and
then,
if
time
left,
then
we
can
go
back
to
answer
that
question.
H
Yeah
I,
definitely
so
it's
a
great
question
and
as
Vijay
shared
like
we've,
definitely
had
the
conversation
about
it
and
I'm
happy
to
rehab
that
conversation
and
I'm
just
trying
to
figure
out
the
priority
of
doing
that
on
this
call
versus
doing
that
on
a
separate
call.
So
just
floor
is
open
if
anyone
else
feels
like
the
the
model
as
a
five
late.
Five
line
item
is
confusing
or
not
matching
up
with
their.
What
they
would
expect
to
see
like.
A
I
think
I
think
it's
just
clarifying
nothing.
I,
don't
think
it's
confusing.
It's
just
I
like
to
know
I
think
when
we're
talking
about
the
seven
roles,
two
of
them
kind
of
irrelevant
I,
think
that's
why
it's
dropped
right
and
then
two
merge
into
one
of
them.
It's
just
like
to
just
like
summarize:
what's
the,
what
is
the
that's.
H
B
G
B
We
had
a
ton
of
we
had
a
ton
of
conversation
around
that
and
I
agree.
It
would
be
good
to
see
the
other
stuff
in
context
too,
but
just
thinking
about,
for
the
sake
of
time,
to
prevent
it
in
other
places
or
help
us
move
along
with
some
of
the
detailed
models
like
we
should
have
a
release
date
or
something
or
a
lock
date
for
these
things,
not
for
the
whole
dock,
even
just
the
section.
H
H
I'm
back,
okay,
sorry,
so
I,
don't
know
what
I
finished
on
so
I'm
just
gonna
say:
September
10th
is
our
Target
to
get
into
GitHub.
That's
not
final!
That's
not
published!
That
gives
us
a
month
of
reviewing
the
paper
still
to
to
finalize
it
and
to
gain
a
lot
of
confidence
in
it
and
stability
in
it.
But
when
we're
moving
from
Google
docs
to
GitHub,
it's
going
to
be
a
higher
bar
of
change
it
just
naturally
is
it's
not
our
intention
to
make
it
hard
to
change.
It.
H
Just
is
with
PRS
and
comments
and
all
those
things.
So,
therefore,
that's
why
we're
trying
to
be
as
collaborative
and
as
kind
of
absorbing
of
ideas
during
this
phase,
so
that
we,
when
we
get
into
that
phase,
it's
like
we're,
really
targeted
more
targeted
with
the
things
that
we're
editing.
So
just
to
reiterate,
our
goal
is
to
be
into
GitHub
on
September
10th,
and
there
may
be
along
that,
the
next
kind
of
10
days
or
whatever
that
we're
doing
that
for
12
days.
H
There
may
be
points
in
time
points
in
the
road
where
we
have
to
sort
of
pick
one
and
go
with
it,
and
then
it
becomes
like
a
process
over
the
last
month
to
be
like.
Is
this
something
that
we
are
concerned
about
for
publishing?
How
do
we?
We
can
open
an
issue
about
it
and
that
can
be
a
really
targeted
conversation,
so
yeah
good
point
Colin
and
that's
sort
of
why
I'm
like
if
we
can
right
turn
back
quickly.
H
H
Four,
like
I
work
in
a
seven
person
organization,
if
I'm
optimizing,
anything
I
am
going
to
be
out
of
business
right,
like
I'm,
like
I,
should
be
in
probably
provisional
for
the
vast
majority
of
things
and
possibly
getting
into
operationalize
on
some
really
core
features
of
our
company
right
on
and
I
mean
that
not
just
on
this
model
but
like
in
life
right
so
I
think
it's
really
important
that
we
that
we
make
sure
that
every
level
is
like
here's
what
you've
achieved.
Here's.
H
What
you
are
achieving
here
is
the
outcomes
of
your
decision
to
be
at
this
level
fact
thing
positive,
spin-esque
and
then
it'd
be
like,
and
if-
and
here
would
be,
if
you
were
to
go
to
this
other
level
or
drop
down
to
this
level,
these
would
be
the
outcomes
that
you
would
be
feeling
and
those
might
be.
There
might
be
kind
of
challenges
that
we
might
want
to
raise
in
the
details.
H
I
don't
mean,
to
put
you
know
a
Sparkles
and
Glitters
on
everything
and
make
everything
sound
perfect,
like
you
can
talk
about
what
the
challenge
is
on
a
certain
level
challenge
at
level.
Four
might
be
how
much
how
difficult
it
is
to
implement
it
right
challenge
at
level.
One
might
be
something
else
that
you're
feeling
as
an
organization,
but
so
talk
about
challenges
and
talk
about
outcomes,
but
always
make
it
be
a
stable
state
of
if
you
are
here.
H
G
Yeah
I
tried
to
to
not
have
any
like
downsides
to
a
level
that
are
solved
in
the
next
level
like
teasing
out
the
next
level
in
the
in
their
former
level
kind
of
I.
Try
to
not
do
that,
but
I
do
get
your
point
and
I
think
there's
still
some
improvement
that
at
least
I
could
do
in
operations
to
make
the
challenge
less
negative.
Sounding
it's
like
okay.
G
H
G
H
E
E
Almost
the
the
whole
reason
why
we're
here
in
some
ways
right
because
productization
is
necessary
for
scale
and
what
we're
trying
to
do
is
standardize
or
create
consistent
outcomes
at
scale
scale
this
stuff
up,
if
you're
a
seven
person
company,
you
don't
have
a
scaling
problem
right.
You're
you're
really
like
to
me
the
level
one
is
about
r
d
level.
Two
is
like
product
Market
fit.
Do.
Are
you
solving
problems
that
matter
to
people
and
levels?
Three
and
four
is
about
scaling
that
up.
H
Yeah,
so
I
think
that
we
used
to
at
one
point
have
so.
First
of
all,
yes,
I,
your
summary
I
think
was
really
good
and
I.
Think
that,
like,
as
you
said,
platforms
products
where
you
start
to
scale
and
that's
exactly
where
product
budget
comes
in,
and
then
we
start
talking
about
that
product,
not
just
being
something
that
you
deliver
but
like
something
that
actually,
your
company
sees
as
like
a
profit
Center,
something
that
like
genuinely
affects
the
bottom
line
of
the
company.
H
H
E
E
H
E
As
you
can
say
that,
like
in
thinking
about
the
The
Matrix
here
at
the
bottom,
like
your
your
point,
Abby,
you
know
hit
me,
which
was
you
know
like
yeah.
You
should
not.
This
is
the
problem
with
the
maturity
model.
It
feels
like
you'd
aspire
to
be
level
four
and
that's
a
that
is
an
issue
but
like
so
that,
so
we
need
to
somehow
soften
that,
like
you're,
don't
don't
try
to
scale
if
you
don't
have
a
need
to
scale.
G
Maybe
in
the
model
structure,
because
we
we
talk
a
little
bit
in
model
structure
about
the
this,
this,
like
the
level
in
the
second
paragraph
right,
so
maybe
that's
that
would
be
a
place
where
we
could
add
kind
of
this
common
sense
of
yeah
I.
Don't
care
if
you're
not
scaling
if
you're
not
at
scale.
It's.
H
Yeah
I
can
take
a
stab
at
getting
that
into
that
top
part.
So,
like
make
clear
level,
four
isn't
necessary
for
all,
and
it
may
be
in
that
paragraph.
It
may
be
somewhere
else,
but
like
yeah
I,
think
that,
like
this
is
really
good,
because
I
think
we're
identifying
some
of
the
things
we've
had
conversations
about,
but
actually
haven't
made
their
way
into
the
paper.
Yet
and
like
it's
almost
shocking,
they
haven't
we're
like
wait.
E
H
H
To
see
you
all
yeah,
thanks
Marsh,
as
always
cool,
so
what
I'm
gonna
do
then
is
I'll.
Accept
this
just
because
I
wanted
to
I
just
want
to
call
it
out.
Basically,
we'd
have
the
conversation
about
all
the
other
bullet
points.
I
thought
of
a
one
to
add
and
I
wanted
to
just
yeah
make
that
make
that
clear
for
people.
G
One
thing
that
I
asked
myself
is
and
I've
done
this
because
others
have
also
done
this
is,
should
we
use
this
ad
list
at
this
level
at
this
stage
and
I
think
we
also
sometimes
interchangeably
interchangeably,
use
level
and
stage
and
maybe
get
some
consistency
we
we
need
to
do
in
the
last
copy
edit,
but
at
least
we
need
to
be
aware
of
it.
Yep.
H
H
A
H
See
yeah
be
being
verbal,
so
I
think
that
the
like
that
that
is
sort
of
what
we're
hoping
to
do
is
to
take
all
of
these
ideas
and
basically
put
them
side
by
side
and
be
able
to
say
you
can't
tell
who
authored,
which
section
right.
That's
the
end
result
that
we
want
to
achieve,
and
it's
not
going
to
be
achieved
today
and
it's
not.
H
You
know
it's
going
to
be
something
that
we're
going
to
work
towards
for
September
10th
and
there
very
well
might
be
a
moment
where
I
have
to
sort
of
copyright
through
and
sort
of
like
standardized
language
without
changing
the
without
intending
to
change.
The
intention
of
anybody's
document
just
to
like
make
the
voice
consistent
right,
that's
sort
of
what
Josh
did
with
the
white
paper
and
it
might
have
to
be
Josh
or
I.
H
H
I.
Think
one
of
the
things
that
I
want
to
the
other
thing
I
sort
of
wanted
to
call
attention
to
after
reading
some
of
them
was
like
what
aiming
for
them
to
be
really
consumable.
So
this
is
this
is
like
a
a
prompt
for
myself
again
as
well
to
be
fair,
which
is
that
there's
so
much
we
could
write
about
each
of
these
points,
but,
like
this
is
I,
think
our
white
paper
Target
was
something
like
five
pages
and
we
wound
up
having
something
like
eight
pages
of
content.
H
This
is
you
know
we
don't
want
this
to
be
much
longer
than
the
white
paper.
We
want
this
to
be
something
like
that's
consumable
and
then
we
can
spin
off
deep
Dives
on
individual
topics
that
we
can
link
to.
Because
remember.
This
is
all
on
the
website
right.
You
have
a
link
to
the
Deep
dive
on
these
topics
and
then
all
of
a
sudden
people
are
are
given
as
much
detail
as
we're
able
to
provide.
H
But
that's
not
the
intention
of
this
document
so
trying
to
keep
it
really
kind
of
short
and
snappy
sentences.
Short
and
snappy
kind
of
paragraphs
is
something
just
to
like
have
a
think
about.
How
can
you
do
it
at
like
a
a
reading
level?
That's
that's
lower
than
yours,
probably
right
so
reading
I
think
they
say
to
Target
at
least
when
I
was
growing
up
in
America.
H
They
used
to
say
Target
like
a
an
eighth
or
ninth
grade
reading
level,
so
that'd
be
like
a
16
year
old
or
something
15
year,
old's
reading
level,
because
at
that
stage
they
are,
they
can
read
complex
things,
but
they
maybe
can't
parse.
You
know
business
speak
and
that's
sort
of
where
we
want
to
be.
Is
we
want
to
be
in
a
place
where
we're
talking
about
complex
topics,
so
there
might
be
complex
things,
but
that
they
are
consumable
and
easy
to
read.
You
know
as
a
as
a
best
attempt.
H
G
I
definitely
have
a
challenge,
but
I
kind
of
ignored
it
for
now,
with
the
naming
in
the
end,
so
I
tried
to
first
come
up
with
the
detail
and
not
open
the
naming
discussion
yet
kind
of
because,
like
I,
feel,
I
would
like
to
rename
a
little
bit
on
level.
Two
three
and
four,
but
I
wanted
to
first
get
like
consensus.
Also
in
the
bigger
group
on
is,
is
this
the
right
direction
and
then
only
try
to
find
a
name
for
what
I've,
whatever
I've
this?
H
Think
that's
a
great
approach,
I'm
totally
happy
to
do
like
a
deep
dive
on
this
one
section
for
for
at
least
10-15
minutes,
and
then
we
can
jump
onto
something
else
if
people
want
so
I'll
keep
it
up
on
the
screen
here.
But
it's
operations.
If
you
want
to
Dive
In
Yourself
and
give
everyone
a
couple
minutes
just
to
read
it
and
then
like
yeah,
the
idea
is
to
see
if
we
are.
G
Then
yeah
give
a
like
high
level
intro
to
to
kind
of
the
thought
process.
As
I
was
working
on,
this
I
was
thinking
of
like
like
within
operations.
You
have
the
the
kind
of
a
life
cycle
management
itself
and
then
there's
also
a
maturity
and
responsibility,
ownerships
kind
of
and
it
it
felt
we're
not
super
clear
on
this
and
I
tried
to
have
like
both
ownership
and
life
cycle
management.
G
Maturity
like
in
each
level
and
like
and
just
evolve
them
together
and
yeah
them
feeding
into
each
other,
and
that's
why
I
was
like
changing
things
slightly
from
so
the
centrally
track,
essentially
managed
and
defined
responsibility.
Don't
work
that
well
anymore,
but
I!
Guess
if
you
look
at
the
details,
it
might
still
make
sense.
I
hope
it
makes
sense,
at
least
no.
H
G
H
Haven't
we
because
the
new
in
the
new
ideas
is
going
to
be
around
investment
and
stuff,
so
I
think
you
had
it
right,
starting
with
ongoing
maintenance
through
to
Sun
setting,
but
I
think
you
can
probably
get
away
with
like
a
sentence
and
if
people
don't
know
the
life
cycle
of
a
of
a
product
or
of
yeah
capability,
then,
like
that's
one
of
those
things,
we
could
always
do
a
deep
dive
on.
If
there's
a
a
set
of
questions
there,
and
then
we
could
make
space
for
another
sentence.
G
H
H
No
I
love
that
I
think
that's
a
very
a
very
important
piece
right
is
like
in
some
cases
yeah,
and
this
is
where
actually
I
had
another
question.
One
of
the
things
I
was
wondering
is,
as
in
like
I.
I
should
suggest
this,
rather
than
edit
hang
on
with
great
power.
It
comes
great
responsibility,
but
like
EG.
H
Environments
right,
like
versus,
like
I,
was
using
I've,
been
using
I
tried
to
take
a
bit
of
a
stab
I,
think
I
shared
at
one
of
them.
Measurements
I
think
this
is
when
I
took
a
stab
at
and
I.
Think
I
tried
in
a
couple
places
to
use
examples
that
weren't
weren't
like
King
making
that's
the
thing
people
are
most
concerned
about
is
I,
didn't
use
an
example
like
you
could
use
Jenkins
for
this
and
then
I'd
get
like
rocks
thrown
at
my
head,
but
like
I,
didn't
try
and
use
tools.
H
As
examples
I
tried
to
use
like
Pro
like
more
kind
of
org
things
that
people
can
easily
be
like.
That's
not
my
org,
so
I'll
I
hope
easily.
So
like
I'll
give
an
example
of
like,
for
example,
a
consistent
view
into
daily.
Active
users
may
be
used
to
evaluate
if
the
platform
could
support
day-to-day
activities
for
its
customers,
like
as
an
example
that
backs
that
the
leaders
need
to
be
aware
of
metrics
and
check
in
regularly
as
I
read
it
back.
H
G
G
So
maybe,
from
a
high
level,
I
like
I
went
from
provisional,
it's
kind
of
like
there's,
still
less
processes.
Everyone
takes
care
as
they
see
fit,
there's
usually
sometimes
there's
a
request
or
requirement
and
going
to
operationalize
where
stuff
suddenly
starts
getting
tracked
and
processes
get
defined,
but
this
responsibilities
and
ownerships
might
still
be
yeah
more
more
decentralized
and
that's.
G
Why
also
the
processes
might
be
this
surrender,
as
one
team
might
be
already
like
they
might
be
still
using
different
processes
just
to
to
to
to
manage
their
life
cycles
and
keep
things
up
to
date
or
keep
things
evolving
and
only
in
a
scale
phase.
We
start
actually
centralizing
and
with
centralizing
we
need
we.
G
We
suddenly
have
the
need
for
higher
responsibility
or
clearer
responsibility
and
a
better
separation
of
ownership,
because
I
try
to
end
add
some
things
that
I've
seen
in
some
organizations
not
being
done
to
like
have
a
more
holistic
view
of
ownership
that
includes
developer.
Experience
includes
security
because
I've
seen
a
lot
of
teams
say:
oh
that
doesn't
it's
not
my
responsibility,
and
only
in
optimized
kind
of
I.
A
B
One
quick
thought
you
might,
it
might
be
something
further
out,
but
the
I'm
curious
at
what
point
do
we
start
saying
like
using
the
term
like
a
platform,
engineering
team
or
something
too,
and
is
that
here
or
is
that
an
investment
with
regards
to
like
defining
responsibility,
just
thinking
about
it
from
if
I'm,
a
smaller
company
I'm
at
level,
one
or
even
heck,
just
somebody
just
getting
started?
But
this
is
a
strategy
but
level
one.
B
G
Kind
of
was
thinking
that
even
like,
even
if
you
have
a
platform
engineering
team
on
the
operations
maturity
you
might,
you
might
not
be
already
at
the
scale
level
like
you,
you
might
still
be
at
level
two
or
even
in
a
direct
in
in
a
way
on
level,
one
because
your
team
might
be
just
way
understaffed.
So
you
you're,
like
I've,
seen
like
big
corporations
having
two
people
in
the
platform
engineering
team,
so
they
by
definition,
can
only
reach
operations
level
to
one,
even
if
they
need
a
minimum
of
three.
G
A
Aspect
I
wonder
whether
security
should
be
called
out.
Specifically,
the
reason
is,
as
a
database
guy
I
know,
most
applications
when
designed
scalability
and
performance
is
also
kind
of
ignored
in
the
beginning
a
lot
of
times.
So
that's
all
important
but
I
think
the
platform
model
is
more
about
like
an
operation
is,
is
yeah,
should
security
be
specifically
cut
out,
as
you
know,
important,
you
know
required
for
the
material
Level
I.
B
A
platform
should
provide
the
capability
for
security
teams
to
go
and
perform
what
they
need
to
perform
right
and
so
I
I,
don't
know
that
it
belongs
to
get
called
out
in
operations
or
like.
If,
if
we
need
to
call
out
specific
examples
like
that
or
lists
your
you
have
operationalized
all
of
these
things,
and
then
that
means
you
know
you're
at
level
two
or
something
like
that.
I
I,
like
that
it
focuses
on
okay,
you've,
centralized
management
of
what
you
have
this
capabilities.
As
being
that
thing
here,.
G
B
Yeah,
it's
interesting,
that's
a
tough
one,
because
that
one
would
be
great
for
an
even
more
like
a
blog
post
or
another
conversation,
or
a
breakdown
surf
record
or
something
because
I
could.
All
I
could
also
see
providing
tools
to
enable
security
teams
to
control
access
to
the
platform
by
consuming
security
related
functions
from
the
platform.
It's
just
kind
of
funny,
chicken
and
egg.
There.
H
H
H
I
think
it's
great
and
it's
exactly
like
that,
allows
for
that
asynchronous
thought.
Process
I'm,
just
calling
myself
out
of
that,
like
I,
haven't
managed
to
do
that
yet,
but
I
think
that,
like
I
can
see
in
the
top
of
it
that
you're
basically
calling
into
question
the
like
reality
in
different
organizations
on
if
defined,
responsibility,
matrixes
or
Define
like
who
owns
like
upgrades
and
things
like
that
is
something
that
genuinely
waits
till
the
last
level
or,
if
that's
something
that
needs
to
come
in
sooner
and
I.
H
Something
when
connecting
to
that
database
like
it
could
kill
the
the
app.
So
there
is
a
responsibility
Matrix
there,
but
in
my
experience
it's
commonly
that
that
is
like
sort
of
on
the
platform
engineering
team
to
like
reach
out
and
sort
of
have
that
conversation
there's
not
really
a
and
then
the
application
team.
So
like
I,
don't
have
time
for
you.
H
I
have
things
to
do
and
like
you're
sort
of
beg,
borrowing
stealing
people's
time
to
try
and
get
these
upgrades
done
in
a
collaborative
way
versus
making
it
really
clear
what
is
expected
of
both
sides
and
like
having
that
be
highly
visible
and
and
all
that
so
but
I'd
be
super
curious,
calling
Vijay
Victor
John.
If
any
of
you
have
different
experiences,
yeah.
G
Yeah
I
try
to
also
make
like
write
a
little
bit
of
that
notion
into
the
last
level
in
terms
of
like
there
is
some
quality
assurance
and
Progressive
rollout,
but
for
like
bigger
changes,
there
is
like
migration
processes,
adoption
plans
and
that's
like
the
platform
team
working
with
their
end
users
to
like
get
them
to
the
next
kubernetes
version,
because
125
broke
a
lot
of
apis
or
they
can't
use
pod
security
policies
anymore.
I
need
to
move
to
gatekeeper
or
caverno
or
yeah.
H
Yeah
I
think
that,
like
that
automation
is
a
really
so
to
me,
I
guess
maybe
there's
like
a
hidden
thing.
I
should
call
myself
out
on.
Is
that
in
our
all
of
our
conversations,
we've
been
very
adamant
that,
like
not,
everyone
should
get
to
level
four
and
that,
like
level,
four,
should
be
aspirational
in
a
lot
of
ways
and
and
all
those
things
and
I
wonder
if,
like
you
can
reach
too
far,
you
can
make
it
so
that
no
one
ever
wants
to
get
to
level
four,
and
we
don't
want
to
do
that
right.
H
We
want
it
to
be
that
there
are
organizations
where
optimization
is
the
right
play
for
them
right,
I.
Think
in
my
head,
this
is
really
good.
This
is
why
I
wanted
something
concrete
to
look
at
in
my
head.
I
think
that
these
comments,
you've
made
are
spot
on
and
I.
Think
I
was
expecting
those
to
show
up
at
level
three,
because
I
think
what
I
was
expecting
at
level.
Three
is
that
you
have
a
really
high
performing
team.
H
That
knows
how
to
manage
upgrades
and
does
so
in
an
automated
way,
where
possible,
but
a
but
a
migration
plan
where
necessary,
and
that
the
difference
is
that
at
level,
four
that
centralized
team
is
no
longer
a
gatekeeper
to
upgrades
in
a
way.
That's
like
we
have
like
we
are
on.
Our
roadmap
is
a
set
of
upgrades
over
the
course
of
the
Year
first
kubernetes
and
then
postgres
and
then
whatever.
H
Instead,
it's
like
there's
like,
if
you
think
about
try
and
use
an
example
from
our
Cloud
experiences,
if
you're
using
gke
or
eks
or
whatever
the
cloud
provider
of
kubernetes
is,
you
can
subscribe
to
an
upgrade
Channel
and
everything
from
give
me
every
upgrade.
You've
possibly
got
as
soon
as
it's
hot
off
the
press
through
to
don't
you
dare
touch
it
like,
and
you
know
like
whatever
the
levels
are
that
are
between
it
and
I,
feel
like
level
three
doesn't
have
that
level.
H
Three
is
like
I'm
taking
care
of
you
when
I
tell
you
that
you
need
to
be
taken
care
of,
and
you
need
to
be
upgraded
and
level.
Four
is
like.
There
are
reasons
that
you
should
want
to
be
more
Progressive
with
your
upgrades
or
less,
and
you
have
that
ownership
of
understanding.
And
if
you
choose
to
turn
off
automatic
upgrades,
you
then
are
like
kind
of
owning
that
upgrade
process
and
we'll
have
to
prompt
they'll,
be
like
automated,
prompts
for
you
and
deprecations
and
whatevers,
as
like
an
example
like
another
example.
H
Being
possibly
the
responsibility
Matrix
like
I,
haven't
seen
this
done
super
well
in
an
organization.
This
is
where
I
think
we're
stretching
for
level
four
a
bit
and
maybe
too
much
calling
myself
out,
but
I
think
that
idea
of,
like
basically
marking
that
the
application
team
needs
to
validate
that
their
code
base
works
with
version
X
and
the
operations
team
needs
to
mark
that
they're
ready
to
upgrade
to
X
and
like
somehow
they're
like
they're,
making
clear
that
those
are
the
requirements
and
that
they're
each
being
prompted
at
the
right
pace.
H
D
We
have
to
have
like
an
what
you
call
it
as
right
right
what
I'm
looking
for
any
any
application
that
integrates
that
platform.
They
have
like
a
regression
suit
that
runs
against
a
new
version
of
the
platform
through
the
github's
model,
and
we
are
when
they
run
the
test
suit,
and
we
ask
them
to
enable
a
flag
in
their
pipeline
that
it's
not
only
in
the
against
the
current
platform,
but
also
for
the
beta
version
of
it.
D
D
At
the
same
time,
we
don't
want
them
to
deal
with
what
the
problem
is.
We
want
to
deal
with
it,
so
so
that's
how
we
call
ourselves
as
a
matured
platform,
team
and
platform
engineering
practices
that
we
build
upon
and
what
you
are
referring
to
is
like
a
balance
between
these
application
and
platform.
Teams
makes
sense
to
a
certain
extent,
but
Central
teams
being
proactive
on
future
releases,
gives
two
values
number
one.
D
H
H
The
centralized
team
is
in
charge
of
Beta
release,
Health
like
that
and
like,
and
that's
the
that's.
What
I
think
was
the
was
the
the
hope
for
the
for
the
defined
responsibility
at
the
top
level
that,
like
that's
what
the
organization
is,
having
a
conversation
about
like
who's,
doing
what
who's
in
charge
of
upgrading
who's
in
charge
of
the
health
of
the
system
at
like
within
and
it
can
be
within
their
like
parts
right
like
within.
D
Yeah,
so
one
of
the
right
simple
way
to
put
it
the
same
problem
is
that
whatever
the
features
that
we
are
building
to
the
platform,
I
I
I
do
especially
see
it
as
a
a
technology
offering
than
a
platform
offering.
So
that
is
where
I
was
able
to
Define
intimately
when,
when
I
was
explaining
my
team
the
same
problem,
they
are
confused
with
this
and
they
because
they
have
a
number
of
questions
right.
What
the
way
how
I
was
translating
is
that
the
current
production
systems
are
more
like
a
platform
under
any
enhancement.
D
They
were
doing
as
you
think
it
has
a
technology
offering
you
are
going
to
offer
a
technology
and
then
make
sure
the
technology
works,
it
breaks
or
cracks
and
everything
not
as
a
platform,
so
I
I,
I
I
categorize,
both
into
two
different
aspects,
so
that
interesting
way
they
see
it
as
before,
or
even
they
call
it
as
a
platform
model.
They
call
it
as
a
technology
platform,
a
technology,
a
technology
model,
so
that
that
is
a
it's
almost
like
an
upgrade
from
technology
to
platform.
B
So
you're
I
I,
really
like
your
example.
Also,
and
one
thing
that
we
had
had
in
the
past
in
the
table-
or
at
least
it
was
I-
hesitate
to
say
it
was
more
clearly
defined
because
it's
not
the
right
way
to
put
it.
But
that
kind
of
that
Journey
from
and
it
was
more
on
the
adoption
side.
I
guess
to
being
able
to
proactively
now
provide
new
capabilities
to
the
consumers
of.
B
And,
rather
than
just
being
reactive
in
the
past,
we
said
you
were
reactive
and
just
responding
to
the
needs
of
your
users
and
now
you're,
anticipating
the
needs
of
your
users
and
I
really
like
bringing
that
back
up
here,
almost
even
at
the
level
four,
because
at
the
adoption
level,
we're
saying
like
provider
driven
and
then
Community
enabled
and
like
it
feels
like
we're
kind
of
making
that
same
turn.
Where
you're
like
you're,
not
relying
on
the
teams.
B
C
B
H
B
H
D
No
actually,
that
came
because
of
the
one
word
I
heard
in
the
call,
which
is
a
high
performing
teams,
usually
like
you,
cannot
teach
you
like
with
the
normal
team
that
kind
of
results.
Actually,
the
high
performing
teams
are
eager
to
look
for
that
kind
of
proactive
things
like
how
we
can
build
it
so
that
next
time,
so
that
is
a
biggest
thing
that
I
always
look
see
like
as
a
puzzle
that
is
hidden
a
secret
puzzle,
solution
that
building
the
team
and
the
rest.
Everything
will
follow.
H
G
G
G
Four
I
think
I
I
that
that's
definitely
a
point
that
I
I'd
like
to
make
then
more
clear,
especially
when
moving
towards
your
suggestion
of
moving
some
of
it
to
some
of
what
is
currently
in
level
four
into
level
three
and
yeah
in
a
way
it's
it's.
It's
then
also
the
enablement
of
of
the
of
the
users
right,
it's
like
in
in
level
three.
H
Doing
these
calls
we
get
so
excited
and
we
talk
about
so
many
things
and
then
it's
like
okay,
but
now,
how
does
that
like
translate
back
into
like
the
concrete,
concise
short
sentences
and
so
forth?
So
definitely
like
call
people
out
in
the
comments.
There's
there
are
stuff
in
this
lock.
We
can
do
asynchronous
chat
on
some
of
this
and
and
refine
it
as
we
go.
I
think
I'd
expect
that,
like
this
is
tough
stuff
to
to
try
and
clarify
so
Victor.
Sorry,
sorry
that
was
a
long
wait.
So.
A
H
Yeah
I
think
I
think
that
definitely
we
we
called
out
automation
into
level
three
I
think
different
types
of
automation
may
end
up
being
surfaced,
but
also
just
the
concept
of
automation
being
a
focus
point
for
level.
Three
I
think
one
thing
we
just
have
to
keep
in
mind
is
that
each
level
isn't
you
aren't
precluded
from
doing
the
things
at
a
higher
level
just
because
you
aren't
fully
in
there
right.
A
Yeah
yeah,
maybe
because
it's
just
a
database,
because
database
automation
have
many
levels,
you
could
have
simply
a
script
to
help.
You
install
that's
automation
or
you
could
have
a
database
everything
installed
for
you
and
then
it's
still
patched,
but
but
you
have
access
to
the
operative
system.
That's
another
level
of
observation.
You
could
have
this
database
provisioned
by
the
application
team.
Everything,
including
patching
all
that
is
automated
for
you,
so
they're
different
level,
automation.
H
Yes,
yeah,
definitely
and
I
think
one
thing
that
I
find
that
really
difficult
with
putting
that
into
the
detailed
sections
is
that
what
people
choose
to
automate
and
to
what
level
is
going
to
be
very
different,
based
on
which
capability
they're,
looking
at
so
you're
talking
about
databases,
but
what
about
VMS
and
what
about
Edge
compute?
And
what
about
all
these
development
environments?
H
And
all
these
things
and
the
other
thing
that's
going
to
be
very
hard
to
like
kind
of
wrap
up
well,
is
going
to
be
that,
like
it's,
it's
a
very
tactical
solution.
That
is
maybe
hard
for
people
to
abstract
away
to
their
organization,
and
we
want
to
keep
kind
of
the
focus
on
the
the
practices
or
the
the
like
outcomes
that
they're
achieving
not
how
they're
achieving
them,
because
our
ability
to
script
databases
has
changed
tremendously
over
the
last
like
five
years.
H
Our
need
to
automate
work
loads
so
that
it
is
repeatable
and
less
and
more
reliable
and
more
resilient,
and
all
that
has
not
changed.
And
so
we
want
to
focus
on
our
attention
on
writing
more
towards
the
automation
for
repeatability
and
less
towards
the
type
of
automation
that
can
be
applied
to
Any
Given
capability,
but
I
think
your
example
is,
is
spot
on
and
it's
exactly
as
powerful
as
vj's,
where
it's
like.
H
H
The
the
like
yeah,
the
amount
which
you
have
to
be
thinking
about
the
infrastructure
versus
just
using
the
capabilities
awesome.
Well,
it's
been
two
hours
for
you
all.
Let's
live
in
an
hour
and
a
half
for
me.
I've
got
fresh
legs
for
another
30
minutes,
y'all
no
I'm
just
kidding,
but
genuinely
really
big.
Thank
you
to
Colin
for
getting
us
started
here
and
to
everyone
for
for
sticking
out
on
these
long
calls.
I
think
these
are
so
powerful.
I
personally
could
get
so
much
for
them.
H
So
if
nothing
else
selfishly
thank
you
for
spending
the
time
on
the
calls
we've
got
kind
of
a
week
and
a
half
or
so
until
we
want
to
try
and
get
these
refined.
So,
let's
figure
out
what
we
need
to
do
on
on
digging
into
some
of
the
other
detailed
sections
as
well
as
people
gain
a
bit
more
confidence
in
them.
But
yeah
give
a
shout
in
slack.
We
can
do
stuff
asynchronously
as
well.
I'm
really
excited.
B
H
B
D
You
Abby
again
no
stress,
maybe
one
last
request
from
myself:
everyone
can
drop
like
if
but
because
it's
too
loud
call
so
thanks.
Everyone,
nice
meeting
you
all
so
if
you
I,
went
through
the
the
summary
that
you
started
with
and
thanks
for
that,
and
especially
like
I,
was
little
confused
when
I
was
writing
the
initial
version
of
it
and
I
had.
But
this
is
definitely
a
very
good
start
for
me.
D
So
I
will
build
up
on
from
here
and
then
I
use
industry,
references
too,
and
maybe
sometime
next
week,
I'll
have
a
a
synchronous,
call
with
you
to
make
sure
that
we
are
getting
into
the
right
line,
because
it's
September
10th
is
almost
like
a
10
days
and
we
should
definitely
Target
that
line
date.
So.
H
Have
a
big
group
call
have
everybody
shout
their
opinions
in
different
directions
and
then
I'll
just
take
some
calls
and
like
get
a
get
a
draft
in
and
then
you
know
it,
it
worked
out
pretty
well
I!
Think
for
the
table
When,
taking
into
account
everyone's
thinkings.
One
person
tries
to
put
a
consistent
voice
on
it,
and
then
we
can
kind
of
tackle
the
the
details
from
there.
So
that's
probably
how
I'll
go
about
it,
but
I
have
to
check
on
when
we
have
a
time
for
another
call,
so
yeah
awesome.
Well.