►
From YouTube: Manage Engineering/Product Weekly 2020-05-28
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
I
guess
we
can
pause
the
recording
for
this
part.
This
is
more
of
just
kind
of
a
cool,
so
it
looks
like
thanks
Jeremy
for
adding
some
points.
I
just
had
a
quick
kind
of
shout
out.
You
might
have
seen
it
in
the
stage
wide
channel,
I
added
the
rest,
that
Jeremy
had
a
good
start
kind
of
kick-starting
a
lot
of
the
release
mouse.
No,
that's
a
bad
word,
the
dates
that
are
important
to
milestone
and
release
planning,
that's
documented
in
our
workflow
engineering,
workflow
and
product
development
timeline.
A
I
just
went
ahead
and
finished,
adding
that
the
other
pieces
just
to
the
manager
calendar
just
so
there's
visibility
there
so
that
I
don't
know
it.
The
idea
where
you
discuss
the
last
time
which
just
how
do
we
make
it
more
visible,
so
people
are
hopefully
more
aware
of
it.
So
just
a
small
thing,
but
you
know
that's
there,
don't.
D
D
E
I
don't
know
if
I
don't
know
if
I
would
say
it's
a
problem,
I
think
it's
just
an
inherently
complex
process,
because
I
think
that
when
like
when
I'm
first
made
aware
of
an
issue
from
a
customer
right,
they
expressed
some
sort
of
pain
point
an
issue
gets
created
for
that
pain
point
it's
very
broad
in
scope,
it's
very
general!
So
then,
as
we
go
through
more
of
the
validation
pieces,
we
then
realize
how
we
can
refine
it
a
bit
and
then,
when
it
comes
to
China
solution,
something
or
determining
what
the
implementation
looks
like.
E
There's
a
collaboration
with
the
engineering
team,
the
product
designer
that
all
eventually
culminates
or
manifest.
As
like
this
more
precise
issue,
and
so
then
you
necessarily
update
the
description
with
that.
Depending
on
the
complexity,
it
might
then
become
an
epic
or
just
like
an
implementation
issue
that
maps
to
other
like
smaller
issues.
E
So
I
would
say
it's
mostly
async
and
the
compliance
group.
The
way
we
operate
is
I'll,
typically
work
with
engineering
managers,
so
Dennis
or
Dan
first,
until
or
unless
they
appoint
or
kind
of
tag
and
a
specific
engineer
or
two,
and
then
it's
usually
just
the
one
or
two
engineers
from
front-end
or
back-end,
that
we
asing
communicate
with
to
figure
it
out
and
so
it'll
usually
be
a
combination
of
myself,
Daniel's
the
designer
and
then
some
number
of
engineers,
maybe
including
the
e/m,
as
we
walk
through
each
of
those
issues.
A
C
From
my
perspective,
I
like
coming
from
for
someone
coming
from
a
team
that
it's
like
all
done,
synchronously
right
this,
which
is
kind
of
like
where
I
was
coming
from
it.
What
it
is
still
a
little
bit
unclear
to
me
like
how
things
flow
and
like
what
are
the
exact
markers
that
cause
engineering
to
pick
issues
up
for
refinement
right
like
it's,
not
a
hundred
percent,
clear
right
and
I.
Actually
just
like
created
an
issue
this
morning.
C
Do
you
kind
of
like
solidify
that
with
Dennis
and
Liam
right
just
to
have
clear,
handoffs
I
think
when
you
do
things
async,
it
can
just
be
really
easy
for
things
to
get
missed,
right
and
I.
Think
that's
where
we
need
to
kind
of
like
to
find
things
more
clearly
right
of
like
when
are
things
ready
for
kind
of
handoffs
I
call
them
it's
not
throwing
up
over
the
wall,
but
just
like
when
you
bring
people
in
to
your
basically
okay
I'm
done
writing
this
issue.
C
Right
I
need
engineering
and
UX
to
look
at
it
and
tell
me
what's
missing
right,
like
what
are
the
exact
kind
of
like
markers
for
that
right
and
then
making
sure
the
other
part
of
the
team
is
looking
for
that
right
on
some
sort
of
regular
interval
and
just
agreeing
on
what
that
is,
that
wasn't
very
clear
to
me
coming
in
right
and
I.
Think
that's
gonna
be
different
team
by
team
I.
A
Yeah
just
wanted
to
understand
like
if
he
can
be
with
some
of
these,
like
things
you're
hearing
like
in
what
ways
they're
being
open-ended.
Is
it
because
they
don't
understand
that,
like
the
end,
state
of
an
issue
should
be
like
moving
to
workflow
scheduling
or
ready
for
development
or
what
exactly
I
guess.
I
understand
I,
understand
like
what,
where
the
lack
of
clarity,
I.
D
Think
that
was
part
of
might
be
asking
the
question
here:
training
and
clarity
on
that
and
but
in
general
I
think
that
it's
just
a
you
know.
We
err
towards
giving
groups
flexibility
to
in
terms
of
how
they
would
like
to
operate
and
refine
issues,
and
maybe
there's
a
sweet
spot
between
being
so
open
and
did
a
nun
structure
that
you
leave.
D
The
milestones:
here's,
how
like
we
find,
how
we
hand
off
issues
from
product
engineering,
here's
old
engineering
expect
some
product
is
product
out
and
how
we
do
that
asynchronously,
because
it
does
take
time
to
get
right
like
when
I
was
new
to
get
lab.
It
took
me
quite
a
long
time
to
be
able
to
really
crack
that
so
that
that
was
that's
got.
A
It
yeah
I
mean
there's
definitely
I
mean
I'll,
say
from
my
perspective.
We
do
have
a
few
gaps
of
connecting
the
dots
so
to
say
in
our
stage
page,
we
include
how
we
organize
issues
in
terms
of
like
we
use
the
on-deck
label
or
whatever
it
will
rename
that
to
so
we're
gonna
use
that
we
want
or
currently
we're
fine.
We
do
mention
that
we
don't
want
to
schedule
things
until
they're,
ready
for
development
and
have
a
wait,
but
I
don't
think
we
have
kind
of
a
clear
description
of
in
this
in
this.
A
How
a
work
section
of
like
here's,
how
things
would
typically
go
from
start
to
finish.
So
that's
that's
something
I'm
happy
to
put
it
draft
up
and
we
can
continue
iterate
on
that
and
then
I
guess
out.
This
will
be
a
general
habit
for
the
EMP
meetings,
but
in
my
experience
with
the
different
groups,
we're
doing
all
sorts
of
different
things.
So,
as
Matt
mentioned
compliance,
you
know
I
work
with
him
when
the
very
level
of
variance
is
very
high
and
then,
as
things
become
clearer,
we
start
involving
individual
contributors
on
import.
A
I
know
Harris
we're
pinging
all
the
ICS
on
every
issues,
just
to
kind
of
chime
and
bring
in
a
role
of
understanding
through
the
entire
group.
At
the
same
time,
we
all
are
assessing
the
well.
The
all
the
engineers
are
assessing
the
complexity
with
that
and
then
on
access,
it's
kind
of
like
both
the
it's,
both
myself
as
a
manager
and
Peter,
as
the
engineer
being
involved
in
discussing
things
with
Melissa
to
do
it
so
I'm
operating
across
the
entire
spectrum.
A
It
doesn't
particularly
bother
me,
but
if
anything
like
like
I,
like
I've,
said
before,
we
should
probably
just
note
that
these
are
the
possible
modes
of
operating,
and
then
we
can
figure
out
if
there's
a
better
way
to,
if
there's
a
need
to
to
calibrate
that
or
align
that
closer
together
across
the
groups.
If
that
makes
sense,
yeah.
D
I'm
happy
to
take
a
stab
at
that.
I'll
assert
an
opinion
that
and
a
little
effort,
John
Mason
voiceover
what
his
comment
there,
but
you
know
the
the
some
issues
are
going
to
be
straightforward
where
it
requires
so
the
end
goal
is
that
something
is
deemed
shovel-ready
when,
like
both
engineering
and
product
has
said
yes,
this
is
this
is
ready
to
go.
So
that's
the
end
goal
some
issues,
you're
gonna,
get
there
very
quickly
that
it's
just
gonna
require
like
one
pass
of
the
ball
back
from
product
engineering
product
says:
hey.
D
We
want
to
add
this
simple
thing
to
the
UI
and/or
make
this
simple
copy
change
engineering.
What
do
you
think
any
drinks?
Just
yeah?
That's
all
straightforward
great
we're
done
one
iteration
one
pass
of
the
ball
and
then
we're
done.
Other
complicated
initiatives
are
in
a
require
like
many
passes
back
and
forth,
and
what
sometimes,
where
I
think
that
sometimes
things
get
derailed
is
when
it's
unclear
who
has
what
that
what
the
critical
path
is
in
order
to
get
to
both
product
engineers
sign
off
in
the
thing
in
that
we're
ready
to
go.
D
So
maybe
there's
like
some
like
lightweight
process,
change
or
indication
that
says
like
we're.
Waiting
on
product
rating
on
engineering
like
there
is
some
unanswered
question
and
then
like
it
is
unambiguous
who
needs
to
take
action
in
order
for
an
issue
to
get
to
get
to
the
end
goal.
I'm
like
seeing
a
lot
of
issues
in
my
time,
IKEA,
lab
and,
of
course,
I'm
super
guilty
of
this.
D
Where,
like
I'll,
write
a
comment,
that's
it's
ambiguous
like
that
I'm
looking
for
something
for
engineering
or
someone
needs
to
answer
a
question,
and
then
the
issue
will
sit
there
for
like
a
week
and
then
I'll
revisit
it.
I'll
say:
what's
going
on,
this
isn't
ready,
and
it's
because,
like
engineer
you
didn't
know
that
I
was
expecting
so
there
live.
I
know
that
engineering
expected
something
for
me
and
so
that
I'll
point
to
is
like
maybe
a
problem
that
I
can
open
in
a
market
right
now
solve.
But
that's
yeah,
that's
my
cue.
It's.
A
Hard,
it's
hard
to
I
mean
and
it's
to
hit
stuff.
There's
there's
so
many
different
aspects
of
it
in
terms
of
like
product
discovery,
UX
is
kind
of
react,
type
of
stuff
like
and
perhaps
doing
an
engineering
spike
that
might
have
to
happen
as
a
result,
but
I
don't
know.
This
is
also
a
10
year
old
product.
So
when
we
want
to
make
changes
of
things,
it
requires
a
bit
more
investigation,
so
I
mean
if
people
are
thinking,
it's
a
bit
heavy-handed
or
it's
been
open-ended.
A
E
You're
right
I,
something
came
to
mind
that
I'd
be
curious
to
understand
from
like
Melissa
John,
Mason
Harris,
especially
that
do
you
feel
that
you,
the
engineers
you
work
with,
are
like
excited
and
interested
in
participating
in
deriving
a
solution,
or
do
they
tend
to
be
of
the
mindset
that
they
just
want
like
clear,
defined
instruction
on
what
to
deliver?
Well.
B
Those
are
a
lot
of
process
on
me
in
the
end
to
be
shut
down
by
the
actual
truth,
which
is
this
was
not
something
that
we
could
should
do
so
and
then
the
engineers
wanted
to
have
also
the
visibility
into
where
we're
going
in
order
to
kind
of
feel
like
they
know,
and
they
they
just
don't
live
in
their
own
world.
They
want
to
know
where
we're
going
so
they
can
think
about.
Things
participates.
There's
been
a
lot
of
question.
B
A
Mean
speaking
on
behalf
of
the
front
engineers
and
also
curious
John
reason,
if
you
want
to
verbalize
your
point
out
from
my
but
I
just
answered
this
question
a
little
bit
like
from
the
front
end
engineers
perspective,
they
all
want
some
sense
of
ownership.
They
all
want
some
buy-in
to
the
direction
they're
heading
towards
and
so
to
my
understanding.
They
don't
want
like
they
want
to
be
involved
as
early
as
possible
across
the
board.
I.
A
Imagine
there's
a
bit
of
fatigue
in
that
which
to
John
Masons
point
could
be
why
you
get
a
little
bit
of
ups
and
downs
in
terms
of
participation
in
terms
of
refining
issues
and
staying
on
top
of
that,
especially
with
all
the
deliverables
we
have
for
that
given
milestone,
but
I
mean,
generally
speaking,
it's
it's
been
good
to
have
them
involved
in
the
solution
and
I
think
most
of
them
wants
to
be
involved
in
the
solution
if
at
all,
from.
B
Finding
Dennis
to
your
point
about
it
being
too
much
or
not
enough,
we've
been
fine-tuning
that
so
you
know
at
first
everybody
felt
kind
of
swamped
with
all
the
things
that
they
could
shine
it
on
gave
feedback.
We
talked
about
it
again
and
decided
to
kind
of
restrict
that
and
also
create
the
process
to
where
they
can
do
this
a
synchronously,
and
then
they
can
do
this
at
their
own
time.
They
don't
have
to
like
reply
to
each
one
of
those
in
sync
or
kind
of
through
the
two
deuce.
B
A
F
Uh-Uh
there's
some
other
kinds
of
observations
that
other
people
have
been
making
I
think
I've
bounced
all
over
the
place
between
having
too
much
detail
and
not
enough
clear
questions
about
hey.
What
is
you
know?
What
kind
of
feedback
am
I
looking
for
engineering
on,
and
some
of
my
issues
too?
To
being
you
know,
more
open-ended,
but
defining
the
problem
and
and
and
still
not
seeing
you
know
much
engagement.
F
And
I
haven't
been
involved
in
any
kind
of
retrospective
process.
Yes,
so
I
mean
I.
Think
there's
just
there's
still
a
lot
of
getting
up
to
speed
for
me,
I
think,
and
but
it's
definitely
a
conversation.
I
really
want
to
open
with
the
team,
because
in
order
for
there
to
be
enough
shovel
revit
ready
items,
we
have
to
groom
quite
a
bit.
F
B
Was
that
we
buy
first
two
months
here,
I
kind
of
put
issues
out
there
and
they
just
don't
refine
themselves.
Okay,
like
at
the
end
of
month,
they'll
be
the
same
spot.
Nobody
contributes,
you
know,
nothing
has
moved
on
and
now
I'm
planning
and
then
planning
all
the
questions
arise,
and
we
then
pretty
much
refined
had
to
refine
the
issue
during
planning
because
they
haven't
been
refined
ahead
of
time.
So
I
was
in
the
exact
exact
spot,
like
the
whole
store
me
before
the
theme
forms,
and
then
we
kind
of
had
a
lot
of
talks.
B
One-On-One
same
group
talks
to
discuss
that
and
kind
of
came
out
with
with
the
process
that
seems
to
work
for
most,
but
it
was
only
because
everybody
talked
like,
for
example,
us
talking
here,
I
feel
as
an
anti-pattern.
If
we
talk
about
what
the
engineers
should
be
doing
and
how
they
should
be
doing
things,
this
needs
to
like
this
discussion
needs
to
happen
with
the
people
who
are
involved
and
affected
by
this.
F
D
Cool
well
I'm,
happy
to
I'm
happy
to
invalidate
Dennis's
last
point
that
this
is
a
you
know:
less
productive
meeting
with
fewer
agenda
items
so
we'll
keep
this
as
a,
but
as
a
weekly
meeting
for
now,
thanks
Dennis
for
moving
up
the
last
item
on
okay
ours
to
next
week,
I
will
say:
I
wanted
to
just
as
a
quick
preview.
D
D
Just
let
me
know
I'll
help,
however
I
can,
and
as
far
as
engineering
goes
I
clicked
into
some
of
the
engineering
issues
and
I'm
not
I
would
love
to
know
if
there's
how
we're
doing
there
and
if
product
can
do
more
to
kind
of
help,
us
make
sure
that
they're
receiving
our
engineering,
okay,
ours
for
for
individual
groups
as
well.
So
looking
forward
to
talking
a
little
more
about
that
next
week,
we.
A
D
D
C
I
am
pseudo
player,
plagiarize
Harris's
process
and
created,
like
my
own
backlog,
actually
this
morning
and
I
tagged,
Dennis
and
Liam
on
it.
Are
we
I,
don't
know
like
sorry
we're
over
time,
but
are
we
kind
of
like
leaving
it
sort
of
open
for
teams
to
like
define
this
on
their
own?
Should
I
pass
on
that
and
y'all?
Are
you
working
on
something
for
the
whole
stage?
What
do
we
do?
No.