►
From YouTube: Ops Section Manager Meeting
Description
2020-07-27 - https://docs.google.com/document/d/1NPzpJGlW9kP5TE1p8dJKingacRiY7K6Y42UYgKusrxg/edit#
A
I'm
three:
I
had
a
pretty
good
weekend,
I'm
usually
my
normal
is
two
and
a
half
it's
the
middle,
so
three's
better
than
slightly
better
than
normal
and
yeah.
I
had
a
pretty
good
weekend.
Did
some
mountain
biking
in
that
actual
mountain,
which
was
which
was
interesting,
did
not
fall
down?
Have
any
naps
which
was
good,
no
unintended
naps,
and
then
I
feel
like
we're
getting
some
goals.
D
C
B
B
B
I
didn't
even
mean
to
do
that.
I
played
soccer
yesterday,
which
is
really
nice.
It's
just
nice
to
like
get
outside
and
run
around
for
a
little
bit.
It's
cooled
off
and
I'm
excited
about
the
gc
tomorrow
and
just
generally
when
we,
when
we
prepare
for
the
gc,
like
we
talk
about
things
we
recently
shipped
and
things
we're
excited
about,
and
so
it
just
gives
me
an
awesome
sense
of
what's
going
on
and
I'm
really
proud
and
excited
about
a
lot
of
stuff
going
on
in
this
section,
sam
I'll.
E
C
E
B
E
F
B
Cool,
I
did
a
couple
of
agenda
items
for
today.
The
first
one
was
this
was
pointed
out
to
me
by
a
team
member
of
mine
who
I
can't
remember,
who
had
specifically
brought
it
up,
but
I'd
love
to
understand.
I
read
this
handbook
link
about
the
seidu
ratio.
I
guess
I'd
just
love
to
understand
how
that's
being
rolled
out
how
the
product
organization
can
help
or
assist
the
engineering
organization
or
the
development
organization,
dan
you're,
typing
away.
A
I
am
date
yeah,
so
the
side
dude
is
pretty
interesting.
I
feel
like
this
idea
is
a
really
good
opportunity
to
get
a
better
alignment
between
product
and
engineering.
I'm
a
pretty
big
fan
of
this
idea,
just
because
mr
ray
doesn't
speak
to
what
customer
value
we're
delivering
at
all,
and
so
you
can.
You
can
have
an
amazing
mr
rate,
and
just
do
you
know
like
code
climate
stuff,
which
is
good,
because
our
code
is
happier,
but
it
doesn't
like
give
value
to
our
customers.
A
So
I
just
I
don't
see
that
as
a
great
matrix
metric
to
determine
what
value
we're
delivering
so
say
you
can,
because
it
is
inclusive
of
the
collaboration
between
the
engineering
manager
and
the
product
manager
to
determine
what
we
should
commit
to
doing
in
each
milestone.
So
there's
that
element
of
that
from
a
product
management
perspective.
They
they're
part
of
that
process.
A
Right
now,
the
w
it's
still
work
in
progress.
We
haven't
sort
of
finalized
that
dashboard,
so
we're
working
towards
figuring
out
a
way
that
we
can
actually
use
this
to
make
sure
it's
reasonable.
I
had
a
kr
in
this
quarter
that
we're
in
to
get
100
and
just
to
see
where
people
settle
out
in
in
the
different
teams,
release
and
package.
A
The
main
point
of
discussion,
what's
interesting
to
me,
is
whether
we
determine
and
there's
different
perspectives
on
this,
which
I
think
is
quite
interesting,
whether
we
say
that
reprioritized
items
would
be
counted
or
not,
and
so
we
might
get
a
week
into
the
milestone
and
say:
oh
someone's,
going
to
be
out
for
a
week
for
whatever
reason,
maybe
they
take
vacation.
Maybe
we
should
have
known
earlier,
but
whatever-
and
we
say-
okay-
we're
not
going
to
get
that
it's
going
to
get
re-prioritized
one
of
those
metrics.
A
One
of
those
numbers
will
say
you
will
be
dinged
for
that
as
a
negative
and
one
of
them
will
be.
They
will
just
ignore
it
because
it
got
reprioritized,
interesting
discussion,
but
ultimately
you
can
game
this
by
committing
to
fewer
things
like
overall.
So
you
could
just
do
like
one
thing
and
I've
joked
about
this,
because
this
will
be
the
next
iteration
of
what
we
do.
I
think,
where
we
sort
of
say
well,
you're
only
committing
to
three
things
in
a
milestone,
and
is
that
really
enough?
A
Is
that
what
meat
does
that
meet
our
expectation
for
our
teams?
And
then
at
that
point
we
might
start
thinking
about
how
many
items
we're
actually
committing
to
or
what
the
value
of
those
items
are,
because
you
might
get
into
one
massive
thing.
That's
amazing
and
everyone
loves
it
right,
and
so
it's
a
little
bit
like
dependent
on
the
work
we're
doing,
and
so
I
tried
to
give
a
kind
of
a
lame
explanation
of
what
that
looked
like,
which
was
you
know.
Maybe
we
commit
to
ten
things.
A
One
thing
gets
removed
just
because
we
realized
that
another
item
was
going
to
be
more
complicated.
We
thought
it
was
that
gets
removed.
In
one
case
you
would
get
your
say
would
be
10
and
your
due
would
be
whatever
you
completed
and
the
other
case
you'll
say,
would
be
nine
and
then
whatever
you
completed,
so
that's
kind
of
a
distinction
there,
I
think
from
as
far
as
a
support
from
product
managers.
A
I
think
I
hope
my
hope
here
for
this
metric
for
engineering
is
to
actually
push
the
engineering
managers
where
they
aren't
already,
because
I
think
a
lot
of
engineering
managers
are
to
make
sure
that
their
product
manager
is
happy
because
they'll
start
getting
measured
on
this
right.
And
so,
if
your
product
manager
is
saying,
I
want
to
commit
to
800
things,
and
then
the
engineering
manager
is
going.
Okay
just
bring
deliverable
on
it
and
then
we're
only
delivering
four.
Then
our
sadhu
looks
terrible,
and
so
how
are
we
going
to
work
through
that
right?
A
E
E
You
were
going
to
get
done,
so
you
know
I
started
thinking
of
it
also
as
more
about
you
know,
kind
of
how
you
manage
that
and
how
do
you
manage
expectations
within
the
team
and
set
goals
that
are,
you
know,
realistic,
but
ambitious,
and
that
if
you
see
a
ratio,
that's
a
way
out
of
whack,
you
know
10
or
something.
Then
it
might
indicate
that
you
know.
Maybe
maybe
that
team
is
not
feeling
great
about
what
they're
delivering
and
that's
something
to
look
into
so
kind
of.
B
Cool,
thank
you,
I
will
say
I'll
start
with
responding
to
sam
your
point.
I
agree,
and
I
think
we've
encountered
through
the
course
of
my
time
here,
a
couple
of
instances
where
teams
have
have
kind
of
consistently
rolled
a
significant
portion
of
their
work
to
the
next
release,
and
that
is
dissatisfying
for
everyone
involved,
and
so
I
think
this
metric
helps
highlight
where
those
places
are
and
encourages
some
sort
of
improved
collaboration
to
deal
with
them,
and
then
dan
you're
like
a
huge
proponent
of
this.
B
But
I
want
to
make
sure
that,
as
we
roll
this
out,
all
of
our
teams
focus
on
that
being
a
collaborative
discussion,
not
a
combative
discussion.
We've
probably
all
worked
in
organizations
where
it
was
like
product
says.
I
want
to
do
800
things
and
then
engineering
has
to
tell
them
no
and
then
a
product
complains
about
how
engineering
always
tells
them.
B
No,
let's
just
make
sure
that
as
our
team,
if,
if
there
is
that
kind
of
discussion
that
we're
encouraging
this,
like
we're
all
working
together
for
this
metric,
I
make
sure
to
emphasize
with
our
product
team
members
in
their
cdf
reviews.
One
of
the
like
competencies
is
what
we
call
build
track
and
the
result
of
that
is
better
product
inputs
to
enable
engineering,
outputs
and
engineering
performance.
And
so,
if
say,
do
ratio
is
a
new
metric
for
that?
That
means
we've
got
to
make
sure
we're
contributing
to
an
effort
to
collaboratively
improve
that
metric.
So.
A
Yeah
just
to
thanks
for
that
kenny
sorry,
I
didn't
mean
to
carry
on
without
acknowledging.
Thank
you.
The
one
thing
I
did
add
was
something
to
keep
in
mind.
Here
is
the
way
it's
been
calculated
right
now,
and
it
is
work
in
progress.
Is
that
it's
calculated
on
the
18th,
I
think
and
so
items
that
you
won't
necessarily
see
this
deliverable
on
things
that
didn't
did
not
get
counted
as
a
do
in
the
say,
do
metric
calculation.
A
So
this
relates
to
the
release
that
ends
up
going
out
for
self-managed
and
on
the
bus,
so
that
timing
is
why
that's
there?
So
this
is
something
to
keep
in
mind.
It's
really.
I
personally
think
it's
kind
of
problematic
I
prefer
to
just
use,
because
we
already
have
a
bot
that
calculates
miss
deliverable
because
it's
the
22nd,
I
think
it
runs
maybe
a
little
early.
A
It
depends
on
a
couple
of
factors,
that's
documented,
but
what
that
means
is
something
could
be
done,
delivered
no
misdemeanorable
label
but
didn't
get
counted
in
the
seidu
and
didn't
go
out
on
a
release,
and
so
our
self-managers
managed
customers
did
not
get
this
so
from
a
product
perspective.
It's
important
to
remember
that
if
we
have
items
that
was
particularly
targeting
for
self-managed
customers
and
I'm
not
sure
you
make
this
distinction-
and
I'm
not
saying
we
should.
I
don't
think
this
is
ideal.
A
But
we
should
be
really
careful
to
keep
an
eye
on
that,
because
if
it
doesn't
make
it
for
the
17th
and
that
number
changes
depending
on
when
the
release
is
cut
and
a
bunch
of
random
factors
that
we're
trying
to
get
sort
of
nailed
down,
you
can
end
up
with
a
misrepresentation
based
on
what
labeling
is
on
the
issue,
because
it
will
say
no
miss
deliverable
because
it
got
done
on
the
21st
and
it
went
out
and
dot
com
got
it.
But
no
one
self-managed
got
it.
B
B
A
Yeah
I
mean
that'll
definitely
affect
it.
This
is,
you
know
like
one
of
the
arguments
that
I've
heard
in
favor
of
using
the
reprioritized
number,
so
the
things
we
took
out
take
them.
As
you
know,
that's
our
say
is
now
less
because
we
took
something
out.
The
argument
I
heard
was
that
I
thought
was
really
good
was
saying:
well,
you
know
we
should
be
adapting
to
circumstances
and
we
don't.
No
one
has
a
crystal
ball
here.
A
So
if
something
changes-
and
we
don't
do
it
at
the
last
second-
just
pull
it
out
of
a
milestone.
So
we
don't
get
things
for
it
right.
Then
that
should
be
a
positive
thing.
We
should
be
reactive
and
delivering
what's
valuable,
and
so,
if
we
went
to
shorter
iterations-
and
I
know
a
few
teams
have
tried
this,
then
that
could
lead
to
a
situation
where
it's
like.
Okay,
we're
going
to
commit
to
these
things.
A
We
don't
know
what
we're
committing
to
in
the
second
week
and
so
how
we're
going
to
have
a
say.
Do
that
makes
any
sense,
and
so
that's
that's
something.
That's
certainly
something
to
consider.
I
think
I'm
I'm.
I
would
like
to
see
us
use
shorter
iterations
because
I
think
it's
an
easier
sort
of
fight,
easy
to
bite
off
little
chunks
of
things
and
it's
more
easy
to
be
reactive.
A
A
My
mom,
my
mom,
says
I'm
pretty
anyway,
so
like
that.
That
to
me
is
like
a
really
useful
thing
to
do,
because
then
we're
not
looking
at
these
things,
because
you
know
having
an
issue
that
goes
for
a
whole
month.
Just
seems
a
bit
ridiculous.
If
you
think
about
it,
like
someone
working
on
one
thing
for
a
month
is
like
hold
on.
B
Well,
maybe
maybe
I
guess
in
the
context
of
this
discussion,
it's
just
team
members
who
are
participating
in
that
pilot
might
say
well,
this
is
going
to
screw
my
cd
ratio
up
and
we
should
be
comfortable
saying:
yes,
that's,
okay,
we
understand
it
will
probably
muck
with
the
sadie
ratio,
but
the
pursuit
of
iteration
is
and
agility
is
more
valuable
than
us.
Measuring
the
sadie
ratio
consistently
across
groups.
B
D
B
D
B
F
B
There's
one
group
that
does
this
today:
it's
geo
they
they
like
kick
off
and
present
the
what
we
call
like
the
agile
plan
for
their
two
iterations,
but
then
they
know
that
they
have
all
sorts
of
flexibility
to
adjust
in
that
second
year.
They
do
two
week
iterations,
so
they
say
I've
got
my
prioritized
list.
Generally
speaking
in
two
iterations
I
get
through
here,
I'm
going
to
kick
off
on
any
items
in
that,
but
that
is
for
public
consumption.
D
B
B
E
So
there
is
a
concept
I've
heard
brought
up
of
like
gearing
ratios,
which
is
I'm
just
gonna,
try
to
type
it
and
then
I'll
say
it,
which
I
I
don't
think,
I'm
not
sure
we
have
one
for
this,
but
you
know
eric
and
his
meeting
was
bringing
up
this
idea
of
like
how
many
ux
people
do.
We
need
per
engineer
how
many
support
people
do
we
need
per
you
know
whatever,
and
so
thinking
about
those
can
be
one
tool
you
know
for
how
we
approach
this.
E
You
know
in
this
specific
case,
I
guess
I'd
ask
like
what
like
what
is
the
problem
that
we're
solving
you
know
like
if,
if
we
think
that
that
ratio
is
not
optimized,
then
like?
How
is
that
manifesting
like
what
is
the
problem
that
we're
actually
we're
actually
seeing
there
and
I'm
not
aware
of
anything
like
specific
related
to
front-end
back-end?
But
if
you
have
details
or
dove,
does
that.
B
Yeah,
I
do,
and
in
the
specific
case
I
think
it's
you
can
think
of
it.
This
way
like
if
dove
has
his
master
desired.
Priority
list,
that's
going
to
deliver
customer
value
and
we
are
able
to
do
one
two
and
three
they
require
back-end,
but
we
can't
do
four
because
it
requires
back-end
and
we
don't
have
the
bandwidth
for
it,
but
we
can
do
five
and
six
because
they
don't
require
back
end.
B
That
would
be
an
example
where
we're
not
able
to
prioritize
the
way
we
want,
because
the
ratio
is
off
from
what
we're
generally
prioritizing.
I
think
that's
how
it
manifests
the
gearing
ratios.
We
do
have
for
front
end
and
back
end
and
they
were
used
to
create
the
teams
initially,
and
that
was
like,
so
you
could
stamp
out
cookie
cutter
teams,
but
then
what
I'm
asking
is:
how
do
we
then
adapt
to
what
is
actually
the
work
that
is
required
and
make
sure
we're
optimizing
across
multiple
groups
and
we'd
always
said?
B
Yes,
these
are
the
gearing
ratios
for
the
standards,
but
we'll
adjust
and
adapt
throughout
time,
and
I
don't
aside
from
the
realignment
that
we
recently
did.
We
have,
I
don't
have
a
great
way
for
us
to
discuss
like
is
this
generally
balanced
across
all
groups?
I
could
pull
the
pm's,
but
I
know
if
you
all
had
some
other
way
of
thinking
about
that.
E
B
E
I
think
we
could
yeah,
I
mean,
I
think,
any
kind
of
ratio
like
that.
You
know
if
you
have
a
product
manager
or
a
team
who's,
saying
yeah.
We
really
we
have
this
strategy
and
we're
trying
to
deliver
on
it,
but
we
keep
getting
hit.
You
know
we
had
somebody
who
felt
really
idle
for
a
lot
of
the
milestone
because
they
weren't
you
know
they
were
blocked
by
somebody
else,
or
we
had
this
priority
that
we
couldn't
prioritize.
For
this
reason,
I
think
he
could
spot
all
kinds
of
you
know
kind
of
miss
misallocations.
E
A
Yeah
this
happened
in
package
and
I
think
this
is
so
maybe
what
you
partially
have
in
mind
with
the
reallocation
of
ci
and
fulfillment,
when
we
had
someone
leave,
but
I
was
already
talking
about
the
idea
of
we
had
too
many
too
many
front-end
people
in
the
package.
There
just
wasn't
enough
work
for
those
people
and
I
think
if
you
had
maybe
a
different
infrastructure,
someone
was
junior,
although
we
don't
do
junior
people
generally
speaking,
but
if
you
did,
it
might
not
have
been
as
evident.
A
But
basically
I
think
you
could
potentially
measure
it
by
saying
items
that
were
added
to
the
milestone
after
it
was
planned
or
removed
from
the
master
and
after
it
was
planned
for
separate
functional
capabilities.
So
we
had
a
whole
heap
of
front
end.
Things
appear
in
the
milestone
for
our
team
and
this
wouldn't
be
necessarily
labeled,
because
they
might
be
working
on
like
pajamas
effort
that
isn't
within
that
particular
team's
labeling,
their
group
label.
A
If
those
things
are
added
to
the
milestone
and
completed
on
behalf
of-
and
it
would
just
be
like
an
analysis
of
the
author
id
basically
in
this
in
the
metrics,
you
could
sort
of
see
if
they're
doing
certain
things
the
milestones
complete
yeah,
we
did
everything
we
needed
to,
but
then
they're
doing
a
bunch
of
extra
work
or
the
inverse
could
be
true.
Another
way
you
can
look
at
it
is
by
looking
at
things
that
are
blocked
based
on
a
functional
need
for
another
person
within
the
team.
A
So
if,
if
in
monitor
health,
they
have
a
person
removed-
or
I
forget
how
many
front-end
people
went
out
of
the
team,
but
if
we're
finding
that
blocked
front-end
label
issues
start
appearing
at
a
higher
rate,
you
could
sort
of
say,
okay.
Well,
the
the
work
we
need
to
do
is
not
being
supported
at
this
point,
and
so
that's
the
other
way.
I
think
you
might
be
able
to
look
at.
A
It
depends
on
the
hygiene
of
our
labeling,
which
is
somewhat
problematic,
depends
on
the
team
depends
on
how
often
we're
updating
it,
but
I
think
there
are
ways
you
could
measure
this
in
a
sort
of
a
in
a
sort
of
a
more
objective
way
from
a
subjective
perspective.
I
knew
ages
before
it
came
up
that
we
had
so
many
overqualified
fronted
engineers
in
the
package
group.
So
we
just
we
knew
tim
and
I
both
knew
that
there
was
just
we
would
plan
a
milestone.
A
You
know
into
the
future,
as
you
know,
a
bit
fuzzily
and
then
they'd
be
completing
that
work,
while
we're
still
in
the
current
milestone,
because
they're
just
not
enough
to
do
so.
There's
that
sort
of
more
subjective
thing,
but
that
might
be
included
in
the
first
suggested.
First
suggestion
that
I
had
there
as
well
cool
right.
B
I'll
start
an
issue,
I
think
I
might
do
kind
of
all
three.
If
we
can
get
some
data
view
from
the
development
metrics,
I
can
ping
the
pms
and
just
say
give
me
a
sense
of
your
backend
to
front-end
ratio
and,
if
you
feel
like
it
is
optimal,
what
I'm
really
interested
in
is,
if
there's
an
easy
solution,
that's
win-win!
Where
one
team
needs
an
additional
front-end
and
the
other
team
needs
an
additional
back-end.
We
should
be
willing
to
consider
those
kinds
of
opportunities
quickly.
B
The
thing
that
I'm
not
super
clear
on-
and
this
is
my
own
deficiency-
I've
not
participated
heavily
in
the
retros
and
reviewed
them
on,
like
a
group
by
group
basis.
So
sam,
do
you
mind
if
I
pick
your
brain
a
little
bit
on
how
you
think
we
could
best
facilitate
that
discussion
in
retros
and
then
ensure
that
it's
getting
bubbled
up
to
leaders.
E
Yeah,
I
mean
you
said:
there's
the
development
retro,
which
you're
probably
somewhat
familiar
with.
You
might
not
attend
that,
but
monthly.
There's
a
development
metro
that
kind
of
bubbles
up
all
of
the
development
department,
I'm
into
a
big
dock
and
discussion
christopher
historically,
runs
that
all
the
last
two
have
been
run
by
other
people.
Dan.
Do
you
know
when
that
happens
in
the
cycle?
It's
like
towards
the
beginning.
B
Of
the
month
I'm
familiar
with
it,
I
guess
what
I
I've
never
like
gone
and
read
through
every
group's
issue
and
tried
to
spot
a
trend
like
you're
suggesting
I
might
be
able
to
spot,
and
so
I
might
just
if
you're
doing
something
similar.
It
might
be
good
for
me
to
just
see
how
you
walk
through
each
one
of
your
groups,
retros
for
kind
of
distilling.