►
From YouTube: 2021-01-19 Delivery team weekly
Description
Delivery team discussion of ideas for Q1 OKRs
A
Hello,
so
welcome
to
tuesday.
I've
got
in
a
slightly
extended
time
for
this
meeting
today,
just
so
that
we
can
get
through
a
bit
of
discussion
on
okrs.
We
may
not
need
all
the
time,
and
so
you
may
get
some
time
back.
We'll
certainly
finish
on
time,
so
this
will
be
time
box
so
that
we
have
a
little
bit
of
time
at
the
end
to
go
through
our
kind
of
social
chat
as
well.
A
So
if
we
need
more
time
afterwards,
we
can
have
that
or
we
can
go
async,
but
we
shall
see
how
we
go
so
there's
a
few
announcements
in
there.
Please
have
a
read
through
and
well.
No,
the
only
one
I'm
not
going
to
have
is
read.
Only
is
congratulations,
myra,
I'm
getting
a
bonus!
Thank
you
for
your
help
on
these
things.
A
A
So
thanks
for
the
feedback
in
the
retro
from
the
previous
quarter,
and
thanks
for
the
work
you've
already
done
to
get
us
the
stage
so
far,
so
a
few
little
things
around
okl's
before
we
dive
into
the
discussion,
okrs
won't
be
the
only
work
we'll
do
in
the
quarter,
but
they
are
there
to
help
us
prioritize
so
they're
there
for
us
to
be
able
to
make
decisions.
If
something
drops
in,
we
actually
know
what
we're
having
to
prioritize
that
new
piece
of
work
against.
A
Hopefully,
it
gives
you
a
bit
of
a
way
as
well
to
if
people
make
requests
of
you
to
be
able
to
explain
to
them
like
what,
where
you
have
focused
on
working
on
as
well
as
sort
of
feeling
like
you,
don't
have
to
do
everything,
so
this
is
one
way
we
hopefully
be
able
to
limit
things
a
little
bit
and
generally
with
the
okrs.
They
are
meant
to
be
ambitious
enough
for
like
to
cover
a
whole
quarter.
A
If
we
consistently
hit
100
on
all
of
our
okrs,
then
we
need
to
be
a
little
bit
more
ambitious.
If
we're
consistently
below
on
that,
then
maybe
we
need
to
rein
in
our
ambitions
just
a
little
or
consider
like.
Are
we
prioritizing
carefully
enough
or
things
like
that
so
generally,
as
we
go
through
like
if
you're
in
your
mind,
trying
to
work
out
what
the
right
size
is
have
a
think
about
something
at
seventy
percent?
A
So
the
main
thing
I
wanted
to
cover
today
is
a
bit
of
a
discussion
around
how
we
rank
these
things,
which
we
didn't
do
at
all
last
quarter.
So
last
quarter
we
were
kind
of
at
this
stage
and
we
had
some
ideas
and
then
we
more
or
less
just
kind
of
went.
Okay,
they
look
good
on.
We
go
so
two
things
we
didn't
do.
One
was
discuss
other
options
and
two
was
discuss
the
size
of
the
things
and
were
they
clear
enough
for
us
to
to
pick
up
for
the
next
quarter?
A
A
So
what
I've
done
is
for
each
of
these
categories.
The
top
ranking
idea
is
slightly
darker,
green
and
also
bolded
number
and
then
the
second
and
third
option
are
slightly
lighter
green
there's
one
exception
where
we
have
three
with
the
same
score,
so
I've
just
picked
the
second
third
and
fourth.
So
what
we
can
see
here
is
quite
interesting
as
a
kind
of
personal
opinion
across
the
whole
team,
the
continuing
the
kubernetes
migration
ranks
top
and
then
we
have
quite
consistently
high
results
on
rollbacks
and
also
on
changelog
plus
security
backpacks.
A
A
B
So
I
think
we
are
generally
ready
instead
sounds
like
abs
and
we
we
can
do
it.
I
think
the
concern
thus
far
has
always
been
like.
Oh
we've,
never
done
it.
So
you
know
what,
if
this,
what
if
that
and
yeah,
I
don't
think,
there's
a
way
we
can
sort
of
get
rid
of
that
unless
we
actually
do
it
or
at
least
try
to
do
it.
D
So
the
general
idea
is
that
there
is
kind
of
go
no
go
point
which
is
around
post
deployment
migration.
So
if
we
want
to
roll
back
prior
to
post
deployment
migration,
then
it
is
allowed
if,
after
the
job,
we
need
a
way
to
figure
out
if
there
we
actually
run
post-deployment
migration
or
not.
But
the
idea
is
that
we
roll
back
code
but
not
database.
D
A
And
one
of
I
suppose,
one
of
the
big
things
as
well
is
going
to
be.
We
all
need
some
percentage
of
coordinate
deployments
completed
as
well,
so
this
ties
in
would
people
feel
comfortable
having
something
along
the
lines
of
the
objective
being
basically
like
this
isn't
the
wording,
but
something
that
basically
says
like
run
a
rollback
or
something
that
kind
of
sets
us
up
that
near
the
end
of
the
quarter.
D
Well,
I
think
it
makes
sense
it.
We
may
also
be
able
to
run
it
earlier.
I
mean
it's,
it
really
depends,
probably
is
just
like
a
deployment
without
certain
jobs
being
run,
so
it's
kind
of
deploying
again
the
old
version
without
running
migrations,
and
things
like
that.
So
once
we
have
them
a
an
easier
pipeline,
so
the
deployer
is
easier
to
handle
because
it
doesn't
have
multi-environments
and
things
like
that,
and
we
have
more
control
over
how
we
trigger
it.
A
Cool
okay,
great
and
that
say
rollbacks
has
we
believe
it
has
most
significant
contribution
towards
site
reliability,
which
is
great.
It's
going
to
be
a
huge
focus,
continues
to
be
a
huge
focus
for
the
whole
department
and
then
slightly
lesser,
like
I
guess
more
as
we
become
comfortable
with
how
it
works,
it
will
contribute
to
mttp
and
also
make
release
management
easier.
So
nice
does
anyone
want
to
add
anything
else
to
rollbacks
before
we
move
on.
A
B
So
my
current
goal
is
basically
to
get
a
api,
and
some
state
functioning
by
this
quarter
probably
still
behind
a
feature
flick,
but
at
least
it
will
be
there
and
then,
roughly
speaking,
I
would
say
the
first
month
of
the
second
quarter.
We
would
spend
testing
it
on
our
own
projects,
starting
with
release
tools.
B
B
A
Cool
okay,
so
dog
fooding
is
gonna,
be
like
I
mean
it's
been
a
focus,
I'm
sure
you've
all
noticed
for
the
last
few
months.
So
if
we
get
asked
about
it
quite
frequently,
it's
going
to
become
increasingly
so
so
would
it
make
sense
considering
any
of
our
other
dog
fooding
items.
So
we
have
these
three
around
like
it
as
a
kind
of
in
addition,
since
this
maybe
isn't
a
full
quarter
just
to
make
it
clear,
we
have
three
which
rank
quite
high
as
dog
fooding.
A
D
D
D
Should
not
focus
on
that?
The
other
two
are
doing
the
same
thing
in
different
ways.
I
am
kind
of
leaning
toward
not
using
the
feature
flag,
so
the
thing
is
using
fissure
flag.
We
are
dog
fooding,
but
we
are
not
adding
a
new
valuable
feature
with
the
product
and
there
is
something
that
I
don't
like
it
is
that,
depending
on
how
we
implement
it,
we
may
end
up
having
feature
flipping
during
ci
job
run,
which
is
not
what
happened
with
variables
with
variables.
D
A
A
I
guess
almost
like
investigation,
because
I
think
one
of
the
things
that
we're
coming
up
across
a
little
bit
at
the
moment
is
the
constant
decision
of
do.
We
build
this
in
like
release
tools
or
add
our
own
code,
or
is
there
a
feature
already
so
how
about
we
had
something
where
a
key
result
was
either.
A
I
mean
we
could
do
that
separately.
I
guess
one
of
the
things
that's
in
my
mind
is
it's
been
interesting
as
we've
gone
through
the
changelog
work,
particularly
as
we've
been
trying
to
work
out,
the
edit
commit
message
feature
there's
a
bit
of
a
blur
about
who
does
the
work
and
who
we
need
to
get
on
board
with
the
ideas.
E
A
Yeah,
that
might
be
a
good
idea
actually
like
again,
I
wasn't
really
sure
where
that
f,
whether
that's
in
a
backlog
already,
but
it
certainly
doesn't
seem
like
it's
necessarily
something
that
is
controversial
enough,
that
you
know
we
wouldn't
be
able
to
work
that
out
in
a
quarter
so
yeah.
That
might
be
a
good
idea.
A
D
This
seems
a
bit
too
much
because
I
mean
it's
it's
four
quarters,
so
it
means
that
every
quarter
we
need
to
ship
dog.
We
need
to
dog
food,
something
plus
we
have
two
quarter
two
going
from
not
having
rollback
to
having
kind
of
stable
and
actually
enjoyable
rollback
system,
plus
kubernetes
and
defining
deployments
low
as
hello,
which
is
kind
of
yeah,
a
lot
of
work,
even
in
terms
of
understanding,
measuring
and
figuring
out
what
we
want
to
do
so
this
was
kind
of
driving
my
scoring
here
to
try
to
figure
out.
D
A
A
A
So
we
might
need
to
just
tweak
on
that
a
little
bit,
but
I
agree
on
the
rollbacks
I
mean
the
other
thing
to
contribute
towards
rollbacks
is
our
current
mttp
target
is
12
hours
and
it
won't
be
lowered
until
we've
been
hitting
that
for
three
months,
which
actually
we're
getting
very
close
quite
frequently,
but
it
will
be
that
plus
rollback.
So
actually
we
can't
make
much
more
impact
on
mttp
without
having
a
rollback,
so
okay.
A
D
Yeah
but
I
second
your
idea
of
kind
of
having
some
kind
of
pre-work
state
for
because
especially
for
the
things
that
requires
that
requires
pms
right,
because
if
we
are
adopting
something,
then
it's
just
up
to
us.
But
when
we
are
actually
coding
the
feature
ourselves,
then
he
needs
interaction
with
pms
and
things
like
that.
So
it
may
take
some
work
up
front.
Otherwise
we
just
don't
have
time
to.
A
Yeah,
okay,
that
makes
total
sense
like
I.
I
fully
intend
to
kind
of
kick
off
on
that
stuff
and
pull
you
in
as
needed,
but
yeah
I
agree
like
it
doesn't
have
to.
I
think
we
can
use
it
to
set
ourselves
up
for
future
quarters
nicely:
okay,
great,
okay
and
then
the
other
big
one.
I
think
that
that
makes
worth
discussing
is
security,
automating
security,
so.
C
D
A
Yeah,
I
know
I
mean
I
think
that
it's
I
could
certainly
having
been
through
it
recently
like.
I
can
definitely
see
the
benefits
like
after
having
it,
but
I
still
think
people
are
remember
the
recent
security
process.
So
in
a
way,
it's
almost
still
in
a
it's
a
positive
we've
made
big
impacts
on
this.
I
don't
know
how
much
additional
work
will
will
add
a
much
more
value
onto
that
one.
D
I
remember,
and
it
is
done
I
mean
it's
just
a
matter
of
babysitting
pipelines
and
things
like
that,
but
pipelines
will
still
be
there,
so
all
the
edge
cases,
all
the
fact
that
we
want
to,
if
I
remember
correctly,
there's
this
idea
of
trying
to
to
cherry
peak
ahead
of
time
so
that
we
know
if
the
merge
request
is
still
say
compatible
with
the
security
branch
or
with
the
the
target
branch,
the
backboard
branch
or
not.
So
this
guy.
D
All
these
kind
of
things
are
super
nice
to
have,
but
it's
a
lot
of
stuff
built
on
top
of
our
tooling
system.
It's
a
lot
of
code
to
manage,
and
it's
just
really
how
much
time
is
it
saving
for
the
engineers
involved
into
this,
because
when
you
are
working
on
a
security
fixes,
usually
this
is
your
main
goal
right.
So
you
have
as
an
engineer
you
have
all
the
your
top.
D
Priority
is
working
on
that
you
put
all
the
attention
on
that
fix
and
this
kind
of
yeah
it's
a
minor
part
of
the
of
the
process,
the
providing
the
the
backboards
and
it's
it's
a
problem
when
the
the
peak
doesn't
well
when
you
can't
pick
it,
but
in
that
case
no
tooling
can
help
you.
It's
just
up
to
you
to
figure
out
how
to
code
that
fix
for
the
old
version.
C
It
is
hard
for
them
to
find
what
stable
version
they
need
to
target.
It
is
also
hard
to
have
them
approved
by
the
maintainer
and
then
assign
them
to
the
bot.
I
am
not
saying
it
is
difficult
itself,
but
I
think
it
is
tiresome
because
they
have
to
do
that
three
times
but
yeah.
I
I
think
it
is
fine
not
to
do
this.
This
quarter,
I
mean
we
have
been
living
like
this
since
forever.
C
A
Yeah,
I
think
it's
a
great
point,
and
actually,
I
think
one
other
thing
that
makes
me
want
to
defer
this
actually
is
that
if
we
are
possibly
saying
that
this
might
change
at
some
point
this
year,
and
actually
the
number
of
releases
we
backport
to
theoretically
could
change
that
might
add,
or
also
remove
the
need
to
be
automating
these
back
ports
right.
If
we're
suddenly
going
back
a
lot
more
versions,
maybe
automating.
It
is
the
wrong
approach,
because
we
won't
get
so
much
benefit.
A
E
A
E
A
A
Now
we
do
need
to
reach
nestle;
it
probably
has
very
minimal
value
for
now.
So
the
goal
behind
this
slo
is
to
separate
out
the
different
kind
of
stages
of
our
pipelines,
and
we
we
don't
all
equally
share
responsibility
for
these
things
right,
so
we'll
be
able
to
use
this
to
identify
like.
Is
it
something
that
delivery
needs
to
focus
on
or
actually
do
we
need
to
be
spending
way
more
time
with
quality
or
or
development
or
whatever,
whoever
it
is
to
help
move
things
forwards?
A
A
I'm
gonna
propose
we
possibly
don't
have
this
as
an
okr,
unless
people
feel
strongly,
and
my
reason
for
saying
that
is
purely
because
we
already
have
three
if
we're
saying
that
we'll
do
something
with
rollbacks
something
with
the
dog
fooding
and
change
logs
and
kubernetes,
which
already
feels
like
quite
a
lot
given.
There's
only
seven
of
us.
A
If
we
do
have
one
I'll
I'll
ask
aaron
if
he
agrees
with
that,
if
we
do
have
one,
it
will
be
incredibly
lightweight
and
you
know
I'll
focus
on
doing
the
bulk
of
the
work
so
that
it's
not
four
for
everyone
in
the
team.
So
unless
people
strongly
want
to
particularly
define
an
okr
around
slos
I'd
say
for
q1,
let's
maybe
use
the
quarter
to
define
that.
E
A
E
A
Yeah,
no,
it's
a
really
great
point
yeah
and
I
think
for
all
of
them.
It's
it's
going
to
be
all
of
these
okrs.
It's
going
to
be
scoping
these
correctly,
but
yeah.
I
agree.
Let's,
let's
frame
this
as
let's
start
with
web
and
api
put
in
the
observability
things
and
then
to
see,
we
may
still
need
to
refine
it
down
a
little
based
off
this
last
quarter.