►
From YouTube: 2021-02-01 - Ops Section Manager Meeting
A
All
right
for
those
joining
the
recording
we
just
did
our
one
to
fives,
but
we're
now
on
to
agenda
item
number
two.
I
was
just
announcing
that
we
adjusted
the
cadence
of
this
and
thanks
everybody
for
keeping
us
efficient
and
removing
meeting
cadences.
We
don't
need
so
what
this
meeting
will
be
every
other
monday
going
forward.
A
I
had
a
op
section
funding
update,
so
this
process
is
a
little
bit
convoluted
and
I'm
happy
to
answer
any
questions
for
how
that
kind
of
process
works,
but
we've
been
maintaining
in
the
r
d
function,
so
product
and
engineering,
a
single
source
of
truth
for
hiring.
In
the
case
that
you
know
we
performed
well
relative
to
our
sales
goals.
A
We
could
open
up
additional
hiring
and
so
on
wednesday
sid
and
the
r
d
leaders
went
through
and
approved
funding,
for,
I
think
it
ended
up
being
like
1.5
million
was
the
budget
for
new
hires,
and
so
it
ended
up
being
to
item
number
eight
on
that
spreadsheet
and
for
the
op
section
that
included
a
set
in
pipeline
authoring
and
two
developers
in
runner
hayana.
Your
question
is
spot
on
it's
my
question
too.
A
The
proposal
didn't
really
differentiate,
but
I
think
of
it
as
very
important
that
we
have
front-end
developers
in
runner,
especially
since
we're
trying
to
move
one
of
the
specific
things
that
we
said
we
were
funding
in
this
investment
was
run.
Our
enterprise
management,
which
I
know,
has
kind
of
been
blocked
because
I
think
most
of
the
team
members
there
are
back
end
engineers.
B
A
We're
looking
at
I'll
say
this
explicitly
in
the
op
section
that
I
would
like
to
know
the
results
of
whether
we're
hiring
one
backend
and
one
front
end
or
I
don't.
I
guess
the
alternate
would
be
two
back
ends.
Maybe
it's
two
front
ends
before
we
pull
the
trigger
on
that.
So
I'll.
Let
darren
and
elliot
know
that
I'd
like
to
review
that
decision
before
it's
finalized.
A
A
I
feel
like
we're
not
funding
our
long-term
long
investment
priorities
as
well
as
we
should,
and
other
product
leaders
and
business
leaders
said
hey,
but
I
don't
want
to
just
open
up
funding
for
just
those
there's
other
really
critical
positions
that
we
need
to
fill
and
have
been
holding
off
on
and
so
there's
kind
of
a
mix
of
both.
But
one
of
the
original
impetus
was
this
apm
single
engineer
group
that
we
are
going
to
be
funding,
so
I'm
glad
to
see
that
one
got
funded.
B
A
Yeah,
the
other
thing
that
I
guess
also
for
mentioning
progress,
tim
rizzi
and
the
package
team
kudos
to
them
put
together
a
business
case
for
increased
package
investment
and
it
materially
moved
the
prioritization
of
that
from
you
know
what
was
in
like
the
30s.
So
now
I
think
it's
number
three
after
the
this
next
funding
round,
so
great
work
on
their
part,
and
that
is
also
a
recognition
of
seeing
increased
usage
in
package.
So.
B
B
There's
a
focus
on
s
like
severity,
one
and
severity,
two
bugs
in
continuous
integration
source
code
is
another
area
we're
looking
at,
but
there's
a
place
where
this
might
not
be
surprising
to
the
folks
here,
but
there's
kind
of
a
there's,
a
backlog
of
bugs
that
bug,
backlog
of
bugs
has
been
growing.
For
you
know
a
year
at
least
it's
now
a
couple
hundred
bugs
deep
and
it's
kind
of
a
challenge
in
terms
of
how
do
we?
How
do
we
address
that?
B
So
that
is
one
of
the
focuses
is
going
to
be
mainly
in
the
verified
team.
Obviously,
mr
rate,
we're
not,
I
guess
we're
not
focusing
as
like,
like
across
the
whole
group
on
like
driving
mr
rate.
In
the
same
way.
Maybe
we
were
a
year
ago
really.
What
we're
planning
to
do
this
time
is
look
at
the
teams
that
have
lower
mr
rates.
B
Really
excuse
me,
sorry,
so,
basically,
the
ones
in
kind
of
the
lower
half,
and
so
because
we
have
some
teams
that
are,
you
know,
kind
of
doing
as
well
as
you
maybe
would
expect
with
mra
like
they're.
They
have
high
mr
rate,
it
doesn't
seem
like
it's
really
healthy,
to
try
to
get
that
higher,
there's
other
ones
that
kind
of
lower
in
that
distribution,
and
you
know
we
think
that
the
reason
why
is
there's
points
of
friction,
there's
there's
technical
debt.
There
may
be
process
things
kind
of
standing
in
their
way.
B
We've
seen
some
teams,
for
example,
improve
their
mr
rate
and
output
by
limiting
the
amount
of
things
they're
doing
at
once,
limiting
work
in
progress.
So
essentially,
this
is
an
effort
to,
for
you
know
those
teams
we've
identified
for
the
managers
to
look
at
what
are
those
you
know,
process
kind
of
friction
concerns,
and
then
you
know:
how
do
we
map
a
path
to
addressing
those
and
a
target
around
mr
rate
for
those
teams?
So
that's
something
we'll
be
driving.
B
I've
got
a
couple
around
architecture,
blueprints
kind
of
a
good
point
of
leverage.
I
think
for
us
in
terms
of
how
do
we,
you
know,
particularly
from
the
development
side,
push
forward
the
thinking
on
how
we
achieve
some
of
these
bigger
things
so
ado
like
to
deliver
a
blueprint
for
that.
We've
got
an
engineer.
Who's
been
identified
to
work
on
that
tong,
we'll
be
doing
that
and
that'll
kind
of
dovetail.
I
think
with
some
of
the
work
that's
happening
in
product
and
design
around
kind
of
envisioning,
you
know
what?
B
Where
are
we
going
and
then
we'd
like
to
follow
that
up
with
kind
of
a
clear
technical
understanding
of
directionally
what
that
is
and
then
kind
of
similar
thing,
around
tech,
debt
reduction,
so
in
ci
again
and
verify
in
general,
there's
kind
of
a
fair
amount
of
tech
dad
it's!
You
know
highly
used,
it's
critical
functionality
for
a
lot
of
people,
so
you
expect
to
see
that
and
there's
a
set
of
blueprints
that
they're
working
on
there
around.
B
B
At
the
end
of
this
last
quarter,
we
made
a
lot
of
progress
on
improving
performance
in
very,
like
you
know,
user
perceived
performance
in
various
endpoints
that
were
slow,
and
I
think
that's
important,
that
user
experience
and
it
just
seemed
like
you
know,
we
have
momentum
on
that
right
now.
I
think
there's
some
more
work
to
do
like
more
work
that
we've
identified
there.
That
would
be
meaningful,
so
I
thought
it
made
sense
to
carry
that
one
forward.
Any
questions
on
that
before
I
move
on
to
the
few.
A
A
A
The
second
one
is
scalability
of
ability
to
contribute,
and
is
that
how
you
think
about
those
tech,
debt
items?
What
I
don't
want
it
is
for
it
to
be
a
like
here's,
a
thing
that
we
could
optimize
when
you
know
product
doesn't
actually
see
that
being
a
place
that
we're
putting
forward
investment
and
or
need
to
optimize
I'd
rather
optimize
for
those
two
things.
Yeah.
B
I
I
think
that
that's,
I
think
that
that's
a
fair
way
to
break
it
down,
I'd
see
it.
Similarly,
I
might
as
opposed
to
I,
I
think
it
is
about
the
ability
to
contribute.
It's
also.
The
ability
to
you
know
for
the
team
to
remain
efficient
and
you
know
be
able
to
kind
of
manage
their
technology
keep
driving
that
forward
without
getting
bogged
down.
So
I
I
would
put
that
I
guess
in
the
same
category
as
the
scalability
yeah.
A
B
And
with
that
ability
they
can
they're
better
set
up
to
support
the
community
contributions
too,
so
yeah
yeah.
Definitely
the
goal
there
and
I
know
greg
like
has
been
doing
some
work
on
this
already
and
some
of
it
I've
got
to
like
dig
deeper
in
to
really
be
able
to
speak
to,
but
the
thinking
is
that
you
know
yeah.
There
may
be
you
know
kind
of
data,
scalability
concerns,
and
we
can
look
at
that
also.
You
know
if
we
have
literally
hundreds
of
s2
bugs
categorized
that
are
not
being
addressed.
B
If
we
have,
you
know
just
a
lot
of
a
lot
of
work
to
do
in
terms
of
people.
You
know
want
new
functionality.
They
want
fixes
to
hold
functionality.
There's
a
lot
of
demands
on
the
team
like
that.
Looking
at
looking
at
that
problem,
architecturally
too,
maybe
a
way
to
kind
of
find
some
shortcuts
or
some
smart
solution
like.
B
If
you
see
you
can
look
at
200
bugs
as
200
bugs
that
need
to
be
worked
one
at
a
time
or
you
could
look
at
it,
as
maybe
there's
a
pattern
in
there
and
if
we
fix
some,
you
know
do
some
kind
of
larger
effort
around
fixing
that
pattern,
you
know,
maybe
that
maybe
that
closes
half
the
bugs.
I
mean
just
design
so.
A
Cool
I
like
that,
and
I
was
not
thinking
in
that
way,
so
I
appreciate
that
connection.
That
really
does
I
agree
that
we
have
a
number
of
s1
bugs
and
I
have
been
thinking
about
them.
It's
just
like
we
got
to
work
them,
but
it
makes
sense
that
there
might
be
some
there's,
probably
some
architectural
thing
underneath
there.
B
It's
also,
I
think,
a
way
to
for
us
to
leverage
the
staff
engineers
in
the
group
more
and
one
of
the
goals.
For
this
year
I
wrote
like
a
vision
which
I
guess
I
should
share
in
here.
I
I
don't
know
if
it's
linked,
but
but
one
of
the
goals
for
the
department
this
year
is
to
really
flesh
out
the
senior
technical
leadership
in
the
group.
We
have
five
stages.
B
We
have
today
three
staff
engineers
who
are
all
fantastic,
but
you
know
there's
a
definitely
opportunity,
I
think,
for
us
to
one
kind
of
mentor,
more
people
into
that
type
of
role
and
then
two
for
those
people
to
you
know
have
a
act
as
a
point
of
leverage
in
terms
of
being
able
to.
You
know,
really
identify
some
of
these
bigger
opportunities
and
smart
solutions
to
you
know
to
broader
problems.
A
Cool
my
other
comment
would
just
be-
I
think,
I've
added
this.
It
must
have
been
to
a
different
issue
on
the
large
contentful
paint
performance
that
I
do
think
that
there
are
probably
I'll
just
pick
on
monitor.
I
don't
think
we
need
to
have
this
focus
in
monitor,
even
though
they
might
have
ones
that
have
slow.
It's
like
something.
You
taught
me
once
sam
in
monitoring
tools.
You
multiply
like
time.
It
takes
to
do
it
versus
how
many
times
users
interact
with
it
and
that's
the
real
metric
we
should
be
looking
at.
A
B
Yeah,
no
absolutely
I
mean
the
goal
here
is
to
identify
ones
that
are
highly
used.
Slow,
it's
not
that
hard.
You
know,
unfortunately,
or
unfortunately,
to
identify
some
of
those
and
we've
made
a
lot
of
progress
on
a
number
of
them,
but
yeah
it's
not
about
everybody,
has
to
do
this.
It's
about.
You
know
it's
a
pretty
meaningful
thing
for
perceived
performance.
You
know
user
experience
if
you're
waiting
18
seconds
for
your.
You
know
package
registry
list
to
load.
B
You
know
that
that
sucks
and-
and
I
know
this
quarter-
where
did
they-
I
put
an
update
here.
This
was
in
the
okr
from
this
last
quarter
that
I
was
just
kind
of
gathering
information
about,
but
yeah
they
did
yeah
in
package.
There
was
some
huge
improvement
that
wasn't
even
captured
by
this
metric
verify.
There's
a
similar
thing.
They
had
a
endpoint
that
was
18
seconds
to
load
on
average,
pretty
slow
right
and
then
now
it's
2.5
seconds,
which
is
the
target.
That's
like
green,
is
2.5
and
below.
B
A
B
There's
some
good
stuff,
like
the
verify
kickoff,
I
think,
is
a
great,
like
example
of
product
and
development
working
together
and
I'd
expect
yeah
that
that
probably
will
have
an
impact
on
mr
right
go
ahead
and
capture
it
in
the
okay.
In
terms
of
the
team
stuff,
I've
got
a
placeholder
there
in
terms
of
culture,
ramp
actions,
so
I
didn't
wanna.
You
know
there
are
ways
I
could
have
written.
B
I
guess
in
action
at
this
point,
but
it
I
felt
like
it
made
more
sense
to
spend
some
time
developing
that,
instead
of
just
trying
to
crank
something
out
immediately,
the
other
one
I
put
in
there
is
that
you
know
we're
doing
work
to
share
those
results
with
everybody.
So
you
know
every
team
in
the
group
is
going
to
have
a
meeting
to
discuss
their
team
level
results
and
then
I
think,
there's
a
set
of
follow-ups
that
we'll
want
to
do
throughout
the
quarter
to
kind
of
engage
with
those.
A
Cool
sam
you
and
I
talked
in
our
one-on-one
about
the
results
from
the
developments
department.
I
think
it's
really
important
that
we
as
cross-functional
leaders,
maybe
there's
a
way
we
could
kind
of
share
the
like
the
functional
groups.
Engagement
survey
results
and
talk
about
how
we
can
help
each
other
out.
Sam.
You
saw
me
open
a
couple
of
issues
for
how
product
can
help
improve
the
development
department's
ones,
but
would
be
great
if
we
could
do
that
kind
of
like
it
would.
It
would
be
great,
and
I
can
juliana
is
juliana.
A
A
A
I
don't
think
they
do.
Okay,
juliana
helped.
Me
accidentally
run
a
report
sam
that
included
some
of
your
team
members,
so
I
think
we
could
probably
run
a
report
that
was
like
all
whether
all
engineering
or
product
team
members
who
are
in
the
ops
section
and
then
then
we
could
have
an
engagement
result
for
all
of
us
and
talk
about
things
we
could
do
to
improve
anna.
Are
you
able
to
get
your?
C
D
C
A
A
On
it,
I
think
one
of
the
things
that
I
just
immediately
realized
when
looking
at
sam's
results
is
that
there's
ways
we
can
help
each
other
get
our
teams
like
help
our
teams
feel
fulfilled
in
their
in
those
metrics.
So
I
think
if
we
got
those
reports
brought
them
into
this
discussion
and
reviewed
them,
we
could
come
up
with
some
things.
We
can
do
to
help
cross-function.
C
B
I
think
it
would
be,
I
think
it
would
be
straightforward
for
juliana
or
whoever
to
run
a
report
that
just
included
all
of
the
groups
that
contribute
to
the
ops
section.
So
you
could
do
a
you
know:
op
sub
department,
ops,
product
managers,
ops,
designers
and
I
think
just
combine
that
into
one
group.
Then
we'd
have
all
have
one
report
we
could
look
at
that.
You
know
represents
the
full
group.
It
wouldn't
have
all
the
nuance
of
the
the
more
focus
reports,
but
I
think
that
could
be
a
good
place
to
start
cool.
B
It
I
mean
kenny,
and
I
we
looked
at
our
you
know,
reports
and
it's
like
all
the
product
managers
feel
like
there's
a
great.
You
know
like
mission
and
vision.
You
know
like
high
marks
there
developers
it's
less
so
you
know,
and
so
there's
those
types
of
interactions
where
you
know
one
group,
may
you
know
kind
of
be
less
sensitive
to
one
type
of
thing
as
another
or
you
know
be
dependent
on
another.
B
You
know
folks
in
other
another
department
to
be
providing
something,
and
so
I
think,
there's
probably
lots
and
lots
of
examples.
You
know
where
we
can
get
a
better
context
by
kind
of
looking
at
that.
You
know
like
what
are
what
are
the
designers
complaining
about
that?
We're
not
you
know
we're
not
as
conscious
of
in
development.
You
know,
for
example,
and
how
do
we
then
you
know
serve
that,
need
better.
A
Cool,
I
guess
last
broad
product
update
I'll,
provide
I'll,
see
if
I
can
find
a
link
to
it.
Last
week
there
was
announcement,
there's
gonna,
there's
some
changes
in
the
product
leadership,
org
structure
and
david
de
santo
is
gonna,
take
over
the
former
devs
section
product
management
in
a
interim
basis,
product
management
leadership
in
an
interim
basis.
This
is
after
for
those
of
you
who
don't
know
eric
brinkman.
A
His
last
day
was
friday
as
the
dev
section
leader,
and
then
his
two
crew
managers,
jeremy
and
james,
are
both
leaving.
I
think
next,
this
friday
is
their
last
days,
so
the
product
org
is
trying
to
figure
out
how
to
restructure
and
as
an
immediate
thing
david
is
going
to
be
managing
those
managing
those
teams,
I'll
likely
be
helping
out
not
in
direct
management
but
with
hiring
and
just
kind
of
providing
coverage
and
support
for
product
team
members.
A
While
we
fill
out
that
org
structure
I'll
share
with
you
transparently,
you
know
one
of
the
things
that
this
does
give
us
an
opportunity
to
do
as
a
product
leadership
team
is
kind
of
promote
from
within
to
have
other
group
managers
who
are
senior
or
principal
product
managers
today
take
on
management
roles.
So
we
are
excited
about
that
opportunity.