►
From YouTube: video1826300279
A
So
this
meeting
is
to
discuss
the
next
steps
for
product
maturity,
as
it
relates
to
readiness,
so
I
I
started.
This
I
started
this
basically
because,
like
you
said
Rachel,
it's
it's
every
time.
You
know
it's
it's
a
big
problem.
It
spans
multiple
teams,
I
feel
like
whenever
I
brought
it
up.
It
gets
bogged
down
in
details.
A
I
created
an
issue
to
Target
some
immediate
things
that
we
could
do,
but
before
just
jumping
into
that
and
sending
out
Mrs
I
wanted
to
at
least
have
a
discussion
with
one
other
leader
and
I
thought
since
you've
already
spent
some
time
on
this.
You
know
and
I
know
it's
something.
You've
been
thinking
about.
I
thought
you'd
be
the
best
person
to
sync
up
with
so
you
have
the
I
guess
we
already
kind
of
talked
about
the
first
item.
B
Sure
well,
I
think
just
just
going
to
the
first
item
like
I
was
interested
to
know
just
how
much
of
an
update
we're
looking
to
do,
because
where
we
are
with
the
Readiness
reviews
at
the
moment,
it's
difficult
for
people
to
know
when
they
need
to
do
one
and
it's
difficult
to
know
who
should
actually
sign
it
off,
like
who's
got
the
responsibility
to
say
yes,
we're
done
here
and
so
I
wasn't
sure.
If
you
had
thoughts
on
that,
just
how.
C
A
A
Yes,
yeah
who's
responsible
for
this
stuff,
I
mean
I,
mean
we
I
think
developers
are
really
doing
the
best
they
can
with
this
and
are
frustrated
a
bit
because
they're
not
given
enough
Clarity
around
it.
They
open
up
the
issue
and
oftentimes.
It's
just
a
check
box,
like
they're,
told
that
they
want.
They
need
to
take
a
feature.
A
Ga
and
they're
told
that
they
need
to
get
a
writing
distribute
done,
so
they
open
up
the
issue,
they
open
up
EMR
and
then
they
wait
for
someone
a
reliability
to
do
something,
and
usually
no
one
does
anything,
because
no
one's
really
on
top
of
this
and
then
eventually
they
go
to
you
know
management
and
say,
like
hey,
I
need
somebody
for
this
and
by
that
time
it's
way
too
late.
So
I
think
that's
the
first
thing
I'd
like
to
fix.
A
B
A
A
Support
yeah
yeah
this
one
yeah
this
is
this
is
really
nice
and
you
know
I
was
talking
to
a
team
who's
trying
to
go
through
Readiness
and
they
didn't
even
know
this
existed
so
I
think
they're
all
going
by
the
docs
this
this
page,
because
this
is
what
the
product
Team
looks
at
to
say.
Like
you
know,
we
want
to
go
here
TA
by
this
release
and.
A
B
B
A
C
B
A
Would
I
would
say
we
start
from
this
page,
because
I
think
in
my
experience
at
least
the
service
teams?
Maybe
not
infrastructure,
but
service
teams
are
here,
because
this
is
where
the
product
managers
look
for
like
what
to
do
to
get
something
to
GA.
So
I
think
we
should,
at
the
very
least,
link
to
what
we
want
people
to
look
at
from
here.
B
A
A
C
A
Do
that,
let's
talk
a
little
bit
more
broadly
about
like
whether
we
should
change
any
of
the
stuff
we
have
on
the
infrastructure
side.
So
who
does
the
Readiness
review
right
now?
It's
delivery,
reliability
and
infrasec
and
infrasec
has
their
own
issue
template
and
own
kind
of
separate
process
that
we've
linked
to
from
the
Readiness
review.
A
B
Maybe
something
to
try
is
I
mean
the
point
of
doing.
The
radius
review
is
to
check
that
it's
okay
in
production,
but
that
also
means
different
things
to
different
people.
So
perhaps
it's
finding
the
stakeholders
or
representative
of
the
stakeholders
and
saying
to
them.
What
do
you
need
to
know
about
a
feature
or
a
service
in
order
to
successfully
run
it
in
production
and
put
the
owners
on
them
to
say
this
is
what
we
need
from
the
Readiness
review
and.
C
B
B
That's
really
clear
like
this
is
this
is
owned
by
security,
because
the
way
that
I'm
thinking
about
this
is
each
step
needs
to
be
a
different
like
Target,
a
different
level
of
complexity
and
like
it's
a
different
requirement
to
run
it,
but
also
each
like
figuring
out
who
the
final
sign
off
is,
is
also
difficult.
So
if
the
if
it
was
grouped
by
owning
team,
you
could
then
say
infrasek.
Do
you
sign
off?
Yes,
reliability.
Do
you
sign
off?
Yes,
rather
than
just
you
know
the
air.
Do
you
sign
off?
Who
knows.
C
A
Yeah
yeah,
you
can
see
like
for
infrasec,
they
added
this.
They
went
they
they
want
to
create
an
issue
in
their
trucker
yeah.
So
you
create
an
issue
here
and
I
think
this
is
just
like
This
Is
How
They
manage
their
work
yeah,
so
security
is
broken
down.
We
don't
have
anything
like
I,
don't
think
we
have
anything
specific
to
delivery,
so
you're
right
like
we
should
talk
to
them
and
get
them
like
say.
A
Okay,
like
we
really
need
a
section
for
you
to
add
here,
I've
also
been
pushing
and
I
think
I
added
this.
Like
you
know,
some
people
are
using
Readiness
to
write
down
their
architecture,
and
this
came
originally
from
infrastructure
projects
where
we
didn't
really
have
a
place
to
put
infrastructure
diagrams
and
just
you
know,
detailed
descriptions,
so
we
put
them
in
the
Readiness
and
I.
Don't
want
to
do
this.
What
I
want
to
do
is
use
gregorz's
engineering
architecture
for.
A
B
Things
yeah:
this
is
this:
the
the
Readiness:
it's
not
even
really
a
Readiness
review.
It's
like
the
Readiness
process.
It's
like
do
you
have
an
architecture.
Diagram,
yes,
provide
the
link
here
we
go
going
through.
This
should
encourage
people
to
think
about
what
their
system
does
not
provide
dreams
and
reams
of
text
about
it.
Just
to
show
you
we've
thought
about
it
and
we
thought
about
it
here.
B
Okay,
so
so,
along
with
what
you've
written
here,
I
think
we
need
to
find
representatives
from
the
different
stakeholders
who
will
help
us
review
a
refresh
of
this,
because
I'm
happy
to
put
together
like
this
is
what
the
the
review
process
should
look
like,
and
this
is
what
all
the
things
should
be.
But
I
don't
know
who
to
go
to
to
to
get
that
sign
off
and.
B
A
C
A
A
B
I
was
just
starting
to
think
about
the
format
of
it
to
try
and
make
it
easier
to
know
who
to
talk
to
again
and
how
to
get
sign
off
of
the
specific
areas.
Also,
because
then,
if
security
go
and
decide
that
they
want
something
different
in
GA,
they
could
go
in
and
edit
it
with
like.
It's
very
easy
to
find
where
it
should
be,
but
again
coming
to
format.
A
B
A
B
C
A
A
A
I
mean
you
know
it
used
to
be.
We
would
never
allow
for
this
sort
of
thing
or
we
wouldn't
encourage
it,
but
now
it
seems
like
a
lot
of
services,
I'm
thinking
like
error,
tracking
and
now
tracing
with
opstrates.
This
is
all
SAS
only
with
no
immediate
plans
for
people
to
run
it
in
their
own
infrastructure.
I'm.
Also,
thinking
about,
like
you
know
the
AI
stuff,
like
or
or
code
suggestions,
I'm
sorry
suggest
a
reviewer
encode
suggestions.
A
B
C
A
Yeah,
so
for
the
format
I
had
this
idea,
like
one
thing
that
really
bugs
me
about
readiness
is
like
you
can't
just
like
I
can
pull
up
the
Readiness
tracker
and
as
as
someone
who
likes
usually
likes
things,
a
little
like
organized
and
clear,
like
like
man
like
I,
don't
know.
What's
going
on
with
this
stuff
like
it's
like,
we
have
a
lot
of
proposals.
We
have
some
things
in
progress,
I,
don't
know,
I,
don't
know
if
they're
blocked,
I,
don't
know
when
they're
due.
C
A
A
C
A
B
B
A
This
is
this
is
the
tricky
part,
because
originally
we
thought,
like.
Okay,
approving
the
merch
request,
approves
the
Readiness
review,
but
then
Marin
Marin
brought
up
some
good
points
and,
like
said
well,
feature
well
like
previous
previous
Readiness
reviews
that
we've
done,
we've
done
multiple
cycles
of
reviews
where
things
got
merged
and
then
but
I
think
this
was
due
to
having
a
lot
packed
into
the
Readiness
review
where
you
had
like
architecture
documents.
So
maybe
do
we
just
make
the
Mr
is
the
like.
That's
the
approval
is
that
is
that
what
you're
thinking.
B
Well,
yeah
because
everything
else
seems
to
be
like
when
you
look
at
a
piece
of
code
that
has
to
go
in
or
a
change
request,
change
issue
that
gets
done.
The
approval
is
on
the
merge
request,
so
I
would
make
the
approval
on
the
merge
request,
but
what
we
could
also
do
is
say
that
in
order
to
approve
it
rather
than
just
reliability
having
this
the,
like,
you
know,
I
tick,
this
box
or
I
push
approve
you.
B
It
could
also
be
that
reliability
has
to
write
a
sentence
in
the
merge
request
that
says
like
from
reliability.
Reliabilities
perspective.
This
was
reviewed
on
this
date.
We
had
to
accept
this
risk
because
this
piece
wasn't
finished
yet,
but
I
don't
know
if
that
makes
it,
then
an
owner
a
step
for
reliability
to
provide
the
sign
off,
but
having
that
text
available
on
the
page
rather
than
the
merge
request,
could
also
be
helpful
like
when
you're
coming
back
to
it
at
a
later
stage.
A
B
So
they
add
in
the
extra
blocks
that
are
required
by
the
beta
step.
They
add
in
the
new
information,
that's
required
by
the
beta
step
and
they
update
anything
else.
That's
already
changed
and
then
we
sign
off
and
we
go
through
the
sign
off
process
and
it
and
we
took
all
the
boxes
and
that's
great
and
then
when
they
go
through
it
again
to
get
to
GA.
B
We
add
in
the
next
set
of
boxes
that
our
4ga
level
we
bring
in
whatever
other
reviews,
are
required
for
that
level,
but
it
Remains
the
Same
document
like
we
don't
have
multiple
copies
of
the
same
thing,
because
then
what
will
happen
is
like.
Let's
say
they
made
a
significant
change
to
the
three
top
operational
risks
when
the
feature
goes
live
if
they
make
a
big
change
to
that
now,
you've
got
to
figure
out
which
of
the
three
versions
of
the
document
am
I
supposed
to
read.
A
A
C
B
C
B
Shouldn't
be,
you
haven't
ticked,
all
the
boxes
and
you
can't
go
to
production.
There
should
be
this
flexibility
in
the
system.
That
says
we
recognize
that,
but
we
do
need
to
ship
this
from
a
business
perspective.
So
how
can
we
be
flexible
here
to
make
this
work,
but
there
are
definitely
some
things
here
that
are
not
required
at
the
experimental
phase,
like
so
I
can't
I'm
trying
to
scroll
up
on
the
zoom
screen,
that's
never
going
to
work.
Let
me
just
open
it
up
here.
B
A
Yeah
so
I
think
there's
going
to
be
the
kind
of
there's
going
to
be
like
some
checkbox
are
just
not
required
for
experimental
other
check
boxes
or
maybe
like
for
the
operational
risks,
like
you
said,
that'll
just
be
kind
of
fleshed
out
a
bit
as
we
go
into
the
as
we
graduate
to
GA.
So
maybe
maybe
if,
if
I
were
to
do
this
simply
what
I
would
do
is
I
would
just
take
somebody's
check
box
and
say,
like
beta
required
GA
required
on
some
of
them.
A
B
I'd
like
to
try
I'd
like
to
have
I'm
happy
to
do
a
first
round
of
splitting
this
page
into
three
groups
and
see
what
happens,
because
if
it
turns
out
that
everything's
required
at
the
experimental
space,
then
there's
no
point
in
going
further
with
that.
But
if
we
can
find
different
ways
to
make
it
to
make
the
barrier
to
entry
for
experimental
things
smaller,
it
would
be
great
to
find
it.
But
I
think
we
won't
know
until
we've
actually
gone
through
item
by
item,
which
is
a
fair
chore
but
I'm
happy
to
do
it.
B
A
B
You
think
you're
on
time,
yeah,
so
I
can
take
a
first,
a
first
pass,
edit,
so
I'm
out
from
Thursday
again
so
some
time
between
now
and
then
to
do
a
first
round.
I'll,
probably
just
work
in
a
Google
doc
and
share
with
you.
I
can
probably
start
later
today,
but
I
can
do
the
first
round
in
a
Google
doc
and
share
with
you,
because
trying
to
do
it
in
an
MR
is
going
to
be
quite
difficult
with
the
amount
of
sort.
B
B
A
C
C
B
A
Yes,
like
I
I,
put
my
thoughts
on
that
up
here,
but
I
mean
this
is
kind
of
based
on
what
we
know
now,
which
is
like
any
new
infrastructure,
getting
your
service
that
has
new
slis
requiring
slos
or
like
any
changes
to
existing
slos
and
then
any
service
any
new
service
that
reliability
needs
to
hold
the
page
or
four
which
like
because
there
are
services
that
have
launched
like
error,
tracking
that
we've
never
completed
Readiness,
for
because
there
was
never
officially
helped.
You
know
handed
over
to
reliability.