►
From YouTube: Manage Engineering/Product Biweekly 20200409
Description
Jeremy Watson leads the 3rd installment of Manage's new bi-weekly meeting for Engineering and Product to discuss and improve our collaboration processes and our productivity.
A
Awesome
thanks
a
lot.
It's
great
to
see.
Y'all
excited
to
kick
off
another
engineering
project
bi-weekly,
so
I've
got
the
first
couple
of
items
on
the
agenda
and
I
wanted
to
kind
of
highlight
our
okay
ours
for
fiscal
year,
21
q1.
So
it's
the
end
of
March
and
we've
actually
only
got
this
current
release
to
attend
to
make
progress
on
these
things.
A
So
I
wanted
to
highlight
the
support,
incremental
iacv
goal
and
I
wanted
to
ask
so
there's
two
things:
there's
deliver
the
top
two
customer
requested
features
as
prioritized
by
product
management
and
also
deliver
15
items
in
the
performance
or
infra
dev
dashboard
I
have
a
little
more
visibility
on
the
first
I.
Have
none
on
the
second,
so
I
wanted
to
just
kind
of
put
that
out
there
to
say
how's
this
going.
How
can
we
work
as
a
stage
talk
to
see
this
goal?
A
I
think
I've
talked
with
Matt
a
little
bit
about
one
of
the
features
and
I
think
we've
agreed
that
we're
gonna
kind
of
Miss
on
that
one,
probably
by
a
release
but
I'm
curious,
like
how
the
second
kind
of
like
request
a
feature
is
going
and
also
how
the
performance
goals
kind
of
going
as
well
dan.
Can
you
help
talk
to
the
latter
at
all?
I'm
I
have
no
visibility
on
this
I
really,
don't
know
how
we're
tracking
this.
B
Yeah
so
I'm
I'm
just
reading
through
this
right
now
so
I
mean
generally
the
tracking
is
supposed
to
be
in
periscope
or
science
or
science
or,
however,
we
pronounce
it,
but
Liam
and
I
also
encountered
the
that
a
lot
of
the
like
group,
specific
dashboards,
seem
to
have
been
archived.
It
looks
like
somebody
tried
to
go
through
and
clean
things
up
and
I'm,
not
sure.
We've
actually
figured
that
out
yet
so
a
little
bit
of
a
hiccup
there.
A
Okay,
cool
so
I'm,
looking
at
the
so
it
looks
like
that
15
items
across
the
dashboard
was
across
maybe
the
entire
section
or-
and
it
looks
like
our
key
result-
is
just
delivering
two
items
which
it
looks
like
we
we
hit
on.
So
that's
that's
good.
So
it
looks
like
according
to
what
I
see
here,
that
we're
on
track,
for
that,
at
least,
which
is
which
is
awesome,
does
does
that
jive
with
what
you
see,
yeah
yeah.
A
Cool
all
right
great,
so
then
I
guess
I'll
turn
to
the
second,
which
is
the
top
two
customer
requested
features
around
I.
Guess
it's
extending
your
managed
accounts
to
all
groups,
Luca
D.
It
looks
like
that.
We
stole
some
items
that
are
gonna
they're
gonna
slip
to
13.0.
Do
you
think
that
that
is
accurate,
like
it
looks
like
we're
gonna
miss
on
this
one
as
well
is
that
is
that
accurate.
A
Okay,
cool
I'll
update
the
issue
with
kind
of
an
update
and,
let's
kind
of
take
it
offline
in
terms
of
product.
How
we
can
make
sure
that
if
this
kind
of
comes
back,
is
they
don't
care
for
q2
that
we
can
make
sure
that
we
we
hit?
We
scope
down
their
epics
in
and
see
if
we
can
hit
it
in
the
future,
so
cool
thanks.
C
A
This
one
here
so
with
the
regarding
the
two
issues
we
selected
as
part
of
our
key
of
our
okay,
our
kind
of
two
features
that
we
wanted
to
kind
of
go
ahead
and
deliver.
That
was
based
off
of
recommendations
for
product.
So
we
just
that's,
that's
that's
know
or
there's
a
periscope
board
associated
with
that
I.
E
Just
I
don't
know
I.
Imagine
it's
probably
worth
talking
about
at
least
briefly,
but
you
and
I
had
at
least
talked
about
how
at
least
part
of
my
disconnect
on
this
was
kind
of
the
timing
of
it
like
for
my
own
personal
and
work
travel,
but
also
the
kind
of
like
high-level
timing
of
I
think
it
was
announced
in
February
or
like
brought
up
in
February,
which
I
think
it
is
basically
the
start
of
q1.
E
A
That's
what
I'm
gonna
cover
with
Erik
I
think
so
like
that's.
Why
I
it's
the
I'm
satisfied
with
just
knowing
that
we're
gonna
kind
of
Miss
on
both
of
these
because
of
the
timing
of
the
okay
are
but
I
agree
with
you
I
think
one
of
the
things.
What
are
the
root
causes
of
that
is
that
the
okay,
our
could
have
emerged
in
like
mid-february,
I,
think
so
by
the
time
that
we
had
actually
like
figured
out
which
features
we
wanted
to
kind
of
tackle.
A
We
only
had
two
more
releases
to
do
it,
while
we
were
doing
planning
for
the
second
release
really
like
we
were
kind
of
this
12
10
was,
or
the
only
release
that
we
had
in
order
to
kind
of
make
sure
that
we
hit
on
these
on
these
goals,
so
that
I
feel
like
is
it's
a
mess
and
so
I'm
gonna
work.
Basically
I'm
gonna
quickly,
ask
like
Scott
near
so
like
do
we
anticipate
this
being
recurring?
Okay,
art,
I,
think
I.
A
Think
it's
a
great
one,
but
I
think
that
we
need
to
make
sure
that
at
the
start
of
the
quarter,
we
have
everything
ready
to
go.
We
have
expectations,
we
have
scoping
that
set
and
the
epics
are
kind
of
kind
of
fixed
so
that
we
can
kind
of
burn
the
issues
in
that
down.
So
I'm
gonna
just
lie
conventional
comments
in
that
issue
to
say:
here's
what
we
need
for
success
next
time.
A
E
I
think
two
quick
clarifying
things
on
that
is
that
at
least
for
the
q1
okay,
our
I
think
it
either
assumed
or
was
generally
disruptive
like
if
we
were
working
on
other
priorities
from
like
external
source.
Early
customers
are
saying
hey.
This
is
high
prey,
but
then
internally,
we
feel
that
these
other
things
are
important,
like
that,
at
least
for
me,
that
was
kind
of
disruptive
I.
Imagine
I'm,
probably
not
the
only
one.
E
So
that's
something
to
consider
and
if
we're
going
forward,
if
we're,
maybe
choosing
those
top
two
iacv
based
on
I
mean
it
should
be
based
on
like
the
objective
data
right.
But
if
there's
some
element
of
what
we're
picking
this,
because
this
is
what
I'm
currently
working
on,
then
that
also
potentially
skews
the
intent
of
the
OKR
right
like
when
we
work
on
these
two
things
that
I'm
already
in
progress
on
that
have
high
AC
V
value
versus
pivoting.
A
A
If
there
are
already
things
were
working
on
and
I
say
great
amazing,
then
all
we
need
to
do
is
just
make
sure
that
we
globally
optimize
within
this
stage
to
make
sure
that,
like
we
are
making
sure
that
we
are,
we
can
deliver
that
that
you
know
if
we
have
to
pull
resources
or
folks
from
another
from
another
group
in
order
to
make
sure
that
happens,
that
that
makes
that
all
the
more
easier,
because
it's
like
a
stage
okay,
are
so
I
idea.
I
think
it's!
A
These
features
for
the
okay
are
like
we
were
already
working
on
these
things
anyway,
but
I
think
that,
where
we
kind
of
learn
what
was
challenging
was
like
figuring
out
where
to
you
know,
put
a
stake
in
the
ground.
To
say
like
this
is
the
scope
at
which
you
know
we
do
get
positive
business
value
from
and
we
can
stop
here
and
then
we
feel
really
strongly
that
we
can,
you
know,
take
Eastern,
Market
and
they'll
actually
be
able
to
to
win
deals
for
customers.
A
E
F
A
That's
right,
so
what
happened
since
you
weren't
you
weren't
here
at
the
time,
was
weeks
that
this
OPR
in
February-
and
this
was
a
new
OPR.
We've
never
done
this
before
or
we
said.
Well,
you
know,
I,
you
know.
Work
on
the
two
highest
is
CD
features
that
you
that
you
have
for
the
for
the
stage,
and
so
it
wasn't
so
that
meant
you
know.
Where
does
the?
What
is
a
feature?
A
Where
do
we
start
and
stop
in
terms
of
like
you
know,
if
we
stop
here,
if
we
deliver
these
particular
capabilities,
then
we
know
we
have
confidence
that
were
actually
gonna
like
be
able
to
sell
something
that
actually
has
like
positive
business
value
that
took
us
more
time
to
kind
of
make
sure
that
we
had
a
justifiable
business
case
around
it.
Didn't
change
really
like
our
prior.
A
It
isn't
anyway,
because
we're
already
working
on,
like
you
know,
high
AC
V,
you
know
features
but
for
the
purpose
of
the
okay,
our
it
was
requiring
you
to
like
deliver
something
discrete
and
like
where
we
light
those
created
those
those
those
boundaries
was
a
little
bit
hard
to
to
figure
out.
So
I
guess
the
takeaway
is
that
we'll
just
start
that
process
a
little
bit
sooner?
A
A
Cool,
so
the
next
thing
that
I
wanted
to
kind
of
cover.
It
was
an
emergent
up
on
the
manage
handbook
page.
So
we
have
talked
a
little
bit
about
process
and
we
are
trying
I'm
trying
we
wouldn't
I've,
been
thinking
at
lest
I
think
it's
last
biweekly
meeting
we
had
I
volunteered
to
create,
like
a
merge
requests
to
try
to
define
a
little
bit
or
process.
A
You
know,
because
we've
been
talking
a
little
bit
about,
we
need
to
have
some
consistency
with
like
the
product
development
flow,
but
leave
flexibility
for
individual
groups
to
kind
of
figure
out
the
details
on
their
own.
But
one
thing
that
we
need
is
some
consistency
with
how
product
and
engineering
kind
of
work
together
and
what
boxes
that
we
check
before
for
something
ready
for
development.
So
in
this
change,
I
proposed
an
MVC
of
simply
stating
that
sorry.
A
If
this,
the
diff
is
a
little
bit
hard
to
read,
but
the
main
theme
that
I've
noticed
is
in
a
last
meeting.
I
think
Dennis
was
a
proponent
of
using
the
product
development
for
a
little
bit
more
strictly,
and
the
problem
that
we
want
to
try
to
solve
is
making
sure
that
when
we
are
transitioning
an
issue
from
it's,
not
implementable,
we're
still
kind
of
figuring
things
out
to
ready
to
build
it.
There
should
be
some
consistency
in
terms
of
like
who
is
actually
looking
at
the
issue
and
who
gives
it
a
thumbs-up.
D
Oh
thanks
Jeremy,
so
creating
that
magic
quest.
What
what
do
people
think
about?
Because
we
we
plan
right
now,
like
one
milestone
ahead
right,
like
will
do
a
planning
issue
in
top
10
foot
13
like
what
do
folks
think
about
maybe
doing
it
an
extra
milestone
ahead
so
that
we
have
a
lot
more
time
to
do
that
planning.
So
then,
we've
got
like
two
milestones:
pretty
much
like
planned
before
we've.
A
Yeah
well
I
think
it
depends
like
ideally
I
would
love
that
personally,
like
as
an
individual
contributor,
I
never
had
time
to
plan
that
far
that
far
in
advance
I
will
I
would
love
it.
It's
like
we
got
to
that
point
and
I
think
that
this
or
this
this
MVC
does.
Is
it
kind
of
forces
you
to
do
some
of
that,
because
you
can't
you
no
longer
can
do
things
can
adjust
in
time.
A
You
have
to
wait
until
like
an
issue
is
gets
engineering
feedback
which
obviously
takes
so
take
some
cycles
and
some
time
before
everyone
gives
it
their
blessing.
So
you
can't
it
kind
of
forces
you
a
little
bit
to
plan
things
in
advance,
but
I
totally
agree
with
you.
I
just
wouldn't
I,
don't
know
if
I
would
like
write
it
down.
So
you,
like
we
planned
two
months
in
advance,
every
single
time,
yeah.
C
G
E
Ahead
John
me:
oh
thank
you
well,
I
know.
Dan
and
I
have
talked
about,
at
least
for
the
30
no
planning
issue
tossing
in
some
13
1
Plus
discovery
issues,
discovery
in
the
sense
that
hey
these
are
things
that
are
pretty
well
thought
out.
At
this
point
we
have
to
have
that
dialogue
to
break
them
down
and
so
surfacing
those
and
the
planning
issue,
as
kind
of
like
I
originally
had
it
as
a
stretch
goal.
E
But
Dan's
feedback
was
well,
let's
maybe
break
that
out
and
make
it
more
obvious
that
this
is
not
part
of
this
milestone,
but
please
do
participate
as
able
so
that
we
can
have
this
discussion
early
on
so
I'll
report
back
with
how
that
goes.
But
maybe
that's
one
way
to
work
towards
this
as
well,
because.
D
It
sounds
like
an
currently
from
wrong,
but
it
kind
of
sounds
like
whistle
hovering
in
space
of
if
we
think
about
the
product
development
flow,
and
we
have
all
of
the
different
workflow
status
is
an
issue
could
be
at
like
some
of
the
things
that
I
do,
particularly
if
it's
a
large
epic
and
if
we're
doing
all
of
the
research
and
design
stuff
like
I'm
a
milestone
before
they'll,
be
like
a
separate
issue,
because
it's
hard
to
have
one
issue
that
go.
That
goes
through
different
stages
right
so
like.
D
If
we
have
like
a
planning,
we
want
to
get
all
the
planning
done
for
this
Marc
for
this
issue.
In
this
milestone
we
would
have
like
workflow
planning
or
whatever
or
problem
validation,
but
the
expectation
from
like
a
customer
standpoint
is
like.
Oh,
this
is
going
to
be
delivered
in
this
milestone,
but
that's
not
really.
What
we're
saying
we're
saying
like
this
set
status
of
the
issue
is
going
to
be
delivered
in
this
milestone,
but
not
necessarily
the
actual
feature
itself.
D
E
The
risk
of
proposing
a
thing
that
I
myself
enough
of
labels
that
are
tied
to
confidence
if
they
don't
already
exist,
I
like
I,
know
deliverables
supposed
to
be.
This
is
our
top
priority,
but
you
know
if
we
have
belief
to
the
contrary
that,
yes,
this
is
deliverable,
but
we're
only
somewhat
confident
it'll
ship
in
this
particular
milestone
for
reasons.
Maybe
that's
the
way
to
do
it,
but
that's
a
label.
It.
D
Yeah
I
mean
aside
from
breaking
it
down
into
like
issues
per
status
like
to
get
something
like
I.
Don't
see,
another
simple
way
around
it
because
we
can
put
all
these
workflow
labels
out
but
like
if
a
customer's
looking
at
it
they're,
not
necessarily
going
to
know
what
like
workflow
proper
validation
means.
They
might
not
know
that
that
the
expectation
is
to
complete
that
part
of
the
issues
sort
of
life
cycle
in
that
particular
milestone.
D
And
you
know,
if
we're
the
only
group
doing
it
or
the
only
stage
doing
it
like
that,
might
not
be
the
expectation
for
leadership
or
other
people.
Looking
at
the
initiative
as
well,
so
it's
kind
of
like
I
guess
the
problem
I'm
thinking
about
how
we
can
solve
is
like
how
do
we
effectively
communicate?
What
we're
actually
trying
to
achieve
with
this
particular
issue
in
any
given
milestone.
C
Planning
issues
more
than
one.
You
know
this,
this
one,
the
next
one,
the
one
you
know
the
one
following
with
items
that
are
candidates
or
that
are
being
worked
on
from
a
design
standpoint
or
something
listed
just
in
the
description
of
the
issue
as
candidates
and
then
right,
I,
don't
need
to
use
labels
to
find
them.
I
can
just
go
to
that
issue.
I
can
find
these
are
the
things
that
are
sort
of
design
priorities
and
I.
C
G
John
I
think
that
to
me
you're
describing
you
know,
using
the
product
in
a
way,
that's
not
very
helpful
to
what
you're
trying
to
do
feels
to
me,
like
you're,
really
describing
a
board
with
issues
that
you
want
to
have
now
and
then
next
release
and
so
on
and
then
being
able
to
easily
see.
What's
there
move
things
up
and
down
move
things
from
left
to
right,
like
if
I
have
all
these
issues,
they're
not
like.
First
of
all,
I
didn't
open
them
all
side
by
side.
G
C
If
I
had
a
lot
of
them,
I
I
think
I'd
worry
about
that.
But
for
me
at
this
point
having
the
problem
with
the
board
is
that
there's
no
way
to
have
any
discussion?
You
know
the
discussions
buried
in
individual
issues.
You
can't
have
a
discussion
about
the
milestone
and
that
that's
kind
of
what
what
I
find
interesting
about
this
idea,
totally
unproven,
they're,
just
an
experiment
president.
So.
A
Right,
like
our
security
issues,
have
to
be
assigned
particular
milestone,
otherwise
the
bot
will
yell
at
you
over
and
over
again,
but
then
like
when
we
actually
get
to
a
plating
and
release.
My
engineering
manager
is
like
I've,
never
seen
this
issue
before
in
my
life.
I
have
no
idea
if
this
is
something
that
we
can
actually
accomplish,
or
not
so
I.
The
problem
I
wanted
to
solve
and
I
think
we
should
optimize
for
this.
A
First
is
making
sure
that
product
and
engineering
are
in
sync
and
that
we
can
maximize
our
throughput
and
our
shared
understanding
of
what
we're
trying
to
deliver.
How
we
communicate
things
to
our
community
I
think
is
very
important
and
needs
to
be
a
consideration,
but
I
think
that
we
should
solve
it
first
and
then
consider
how
we
solved
a
second
in
context
with
how
we
work
Dan.
What
do
you
think
about
this
conversation?
Yes,.
B
B
We've
already
put
the
work
into
it
than
we
need
to
put
into
it
so
below
that,
underneath
that
to
get
to
that
point
of
sufficient
refining
that
we
need
sort
of
momentum,
especially
on
the
engineering
side
and-
and
you
know-
maybe
another
way
of
putting
that
is
just
sort
of
you-
know
sufficient
attention
over
a
period
of
time,
because
we
can't
refine
these
things
instantly
right.
It's
not
a
matter
of
one
exchange.
It's
it's
a
process
of
ongoing
exchanges
to
get
to
that
point
of
refinement,
so
I
think
it's!
You
know
another
way
of
phrasing.
B
Momentum
is
maybe
just
eyeballs
over
a
period
of
time,
so
I
like
Matt
and
I,
like
he
mentioned
just
the
other
day,
talk
about
on
these
planning
issues,
including
as
just
a
matter
of
course,
a
section
where
Matt
tells
me
hey.
These
are
the
issues
I'm
interested
in
as
refining
to
the
point
where
we
can
execute
them.
You
know
the
next
three
you
know
somewhere
in
the
next
three
and
four
milestones,
which
is
super
helpful
to
me.
Another
thing
Jeremy
that
you've
introduced
is
the
on-deck
label,
which
has
been
super
helpful
for
me
and
I.
B
Don't
want
to
speak
for
other
engineering
managers
here,
but
you
know
I
think
I'm
roughly
capturing
their
interests
as
well.
You
know
if
we
can
have
a
better
idea
of
what
we
need
to
putting
you
know
put
our
sort
of
like
weekly
or
even
daily
sort
of
discovery.
Attention
into
that
be
super
helpful,
yeah.
A
And
that's
I
think
the
prominent
return
that
I'm
trying
to
solve
with
that
merge
request,
which
is
the
like,
if
you
want
to
do
that
with
an
on-deck
label.
If
you
want
to
do
with
a
milestone,
if
you
want
to
do
that
missing
conversation,
that's
all
fine,
but
the
point
is
is
that
we
need
to
have
some
sort
of
refinement
that
goes
up
until
that
process.
G
Completely
agree
with
the
principle
and
and
to
be
there's
a
link
to
something
that
the
group
in
port
is
mulling
over
right
now
we're
trying
to
come
to
to
something
we
want
to
try
out
so
we're
still
kind
of
open
for
discussion.
I'd
like
your
feedback
on
it,
but
I
think
it
tries
to
solve
the
same
problem,
which
is
understanding
having
a
better
understanding
of
things
that
we
want
to
schedule
for
a
release
ahead
of
that
release
where
engineering
had
time
to
provide
their
input
and
and
both
on.
A
B
B
B
C
A
Think
that
was
born
in
a
time
when
we
used
deliverable
and
stretch
like
here's-
maybe
kind
of
mentioned
in
his
comment,
which
so
like
it
didn't
make
sense
for
us
to.
You
know
whack
any
one
of
the
nodes
if
they
like
missed
a
stretch
issue,
but
it
did
for
a
deliverable
issue,
so
both
could
be
scheduled
for
a
milestone
and
then
stretch
just
like
if
you
actually
miss.
A
So
you
know,
you
could
say
that
the
same
kind
of
applies
right
now,
but
based
off
of
how
I
understand
that
we
plan,
we
don't
put
things
in
the
milestone
that
we
don't
have
some
reasonable
confidence
of
delivering.
If
we
don't,
then
it
shouldn't
be
in
the
milestone.
So
I
personally
am
supportive.
It's
less
stuff.
We
have
to
maintain
so
I'll
jump
in
that
issue
and
the
voice
that
over.
B
A
Yeah
great
right,
I
mean
I
think
it
depends
on
like
how
we're
sitting
our
KPI
like
our
okay,
ours
right,
like
which
I
don't
remember,
to
be
honest
with
you
like.
If
we,
if
we,
if
we're
putting
consideration
at
I,
don't
I,
don't
believe
I
don't
were
considering
that
and
under
current,
like
goals
or
our
current
logic.
So
if
that's
the
case,
then
we
shouldn't
it
should
be.
Consideration
should
just
like
if
we
schedule
something
for
a
milestone,
did
it
get
delivered?