►
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
Oh,
my
headphones
are
disconnected
anyways
welcome
to
the
staff
Engineers
path
book
club
today
we're
going
to
be
discussing
chapter
five,
which
is
all
about
leading
big
projects
and
just
a
quick
recap
of
that
chapter.
It's
I
mean
talking
about
large,
difficult
or
complex
projects
that
could,
you
know,
potentially
take
longer
than
a
short
time.
B
A
Possibly
multiple
months,
the
kinds
of
projects
that
that
seem
overwhelmingly
large
or
or
deal
with
complex
and
and
cross-team
type
of
problems.
So
I
had
the
first
question
here,
and
so
there
was
a
lot
of
talk
about
how
to
choose
what
to
work
on
and
how
to
kind
of
advocate.
For
what
you'd
like
to
work
on,
and
the
author
describes
using
an
RFC
process,
which
is
a
request
for
comment
and
also
advocating
in
other
ways,
but
suggested
a
variety
of
topics
that
you
should
kind
of
have
an
idea.
A
An
understanding
of
before
you
really
push
forward
with
a
project
and
I
was
happy
to
see
that
the
list
kind
of
contained
everything
that
we
do
at
gitlab
when
we
are
preparing
for
these
sort
of
large
projects
or
proposals
in
our
issues
and
ethics.
But
I'm
curious,
like
if
you're
kind
of
just
you
see
a
problem
and
you
you
want
to
advocate
for
this
new
project
and
and
nobody
else
is
working
on
it
or
prioritizing
it.
A
C
Also
I
think
I
can
try
to
answer
this
question
and
I
used
an
example.
I
I
pasted
the
link
to
the
CI
data
CI
time,
Decay
blueprint
about
improving
conditions
in
how
we
archive
and
move
around
CI
data,
and
this
this.
C
This
particular
project
took
around
18
months
from
the
idea
to
actually
starting
kicking
all
the
work,
and
it's
been
a
lot
of
work
for
these
18
months
to
actually
convince
people
that
it
might
be
important
and
I
think
that
basically
finding
time
it's
it's,
how
to
find
time
for
things
like
that,
it's
probably
you
can
find
some
tips
in
issue
number
two
in
the
project
I
linked
from
the
agenda.
C
There
I
recently
created
an
issue
about
some
questions
from
the
previous
chapter
about
how
to
decide
what
we
are
going
to
work
on
and
for
me
advocating
for
doing
something
that
you
believe
is
important.
C
This
part
of
the
job
so
and
and
then
of
course,
you
need
to
evaluate
the
priority
and
decide
whether
you
want
to
spend
time
on
this
or
or
not,
and
it's
probably
a
slightly
different
answer
and
different
scope
of
the
answer
than
what
you
asked
about,
but
yeah
I
think
that
I'm,
usually
using
this
data,
informed
way,
because
using
solid
data
is
one
of
the
best
ways
to
provide
Clarity
around
whether
something
should
be
done
or
not,
and
getting
this
data
is
something
that
definitely
it's
important
to
spend
time
on.
C
But
when
you
are
working
on
a
project
like
that,
it's
never
just
one
thing:
I
mean
you
can
make
some
step
get
some
data,
show
it
to
your
manager
and
ask
them.
Do
you
think
it's
okay
to
spend
more
time
on
this
right
and
things
like
that?
You
are
moving
forward
step
by
step
and
after
some
time
you
have
really
a
lot
of
solid
data
on
on
this
topic,
and
you
use.
B
A
A
Yeah
I
think
so
so
it
sounds
more
like
like
I
was
envisioning
like
okay
I
want
to
do
this
thing,
I'm
going
to
like
spend
a
bunch
of
time
figuring
it
out
and
then
kind
of
like
propose
it.
But
it's
more
that
you
you
just
chip
away
at
it
over
time
in
in
small
pieces,
and
then
it
starts
to
grow.
A
So
it's
not
necessarily
like
you're
you're,
dedicating
a
massive
amount
of
time
towards
it.
At
the
beginning
of
the
process.
C
Yes,
I
think
it's
it's
exactly
that
and
I
think
it's
very
important
to
to
figure
it
out
how
to
start
well.
What
what's
going
to
be
the
first
message
you
are
going
to
convey
to
people
that
are
decision
makers?
How
to
explain.
You
know
you,
the
idea
that
you
want
to
spend
a
bit
more
time
on
figuring
it
out
and
yeah.
D
I
guess,
in
addition
to
convincing
others,
another
aspect
is
also
actually
convincing
yourself
that
it's
important
and
and
worth
your
time
and
worth
focusing
on
I
I,
actually
really
like
the
idea
of
kind
of
using
data
to
well.
It's
it's
a
double-edged.
Well,
maybe
not
double-edged
sword,
but
I
I,
guess
not
every
not
everything
worth
doing
can
easily
be
measured.
D
If
you
can
find
some
data
that
backs
up
your
theories
or
it
sort
of
shows
the
problem
great,
but
I
I
guess
also
not
always
that
easy,
because
you
have
kind
of
long-term
effects
that
are
measured
on
the
time
scale
of
years
and
and
sort
of
second
order
effects
or
side
effects
that
maybe
there's
no
convenient
metric
form.
C
Yeah,
when
what
I'm
sometimes
doing
when
there
is
no
data
I
can
actually
use,
is
just
talking
with
other
experienced
Engineers
brainstorming
together.
Sometimes
it's
enough
to
convince
myself
that
something
is
important.
But
in
such
cases
it's
usually
very
difficult
to
convince
decision
makers
to
actually
invest
time
and
money
in
doing
something
when
it's
not
really
supported,
but
any
kind
of
very
concrete
evidence.
D
It
was
a
a
conference,
a
recording
of
a
conference,
talk
called
quantifying
risk
that
talks
about
I,
guess
the
the
difficulties
of
getting
funding
for
projects
similar
to
what
Matt
described
that
are.
D
You
know,
infrequent
Maybe
unlikely
or
there's
a
there's,
a
low
likeliness,
but
you
still
want
to
sort
of
protect
against
it
and
I
guess:
I,
I
kind
of
have
a
bias
towards
that
being
in
infra,
I
guess:
infrared
security
tend
to
be
more
directly
exposed
to
these
types
of
events,
but
I
thought
that
was
a
really
good
presentation
that
effectively
suggests
attaching
a
dollar
value
and
a
probability
to
these
events
and
then
multiplying
that
out
and
it
sort
of
so
it's
a
little
hand
wavy
right,
but
it
gives
you
at
least
a
way
of
talking
about
and
comparing
the
Worth
or
the
the
costs
benefit
of
various
potentially
large
projects.
D
I'll
be
honest,
I'm
super
behind
on
reading
and
like
two
two
chapters
behind
so
I
just
kind
of
tried
to
skim
most
of
the
the
latest
chapter.
D
F
Yeah,
so
my
skin
was
a
chapter
three
paid
some
attention
to
chapter
four
and
I've
been
plowing
through
chapter
five,
and
my
overwhelming
impression
is
these
chapters
kind
of
serve
to
reinforce
a
point
that
the
author
made
earlier
in
the
book.
F
Whenever
there's
a
feeling
of
someone
should
do
something
here,
there's
a
reasonable
chance
that
someone
is
you
yeah,
so
chapter
five
just
seems
to
kind
of
cover
every
potential
role
that
a
big
project
could
have
and
then
explain
to
you
how
you
should
do
it
and
I've
I've
I'm
kind
of
struggling
to
get
through
it
really,
while
I
do
see,
the
value
is
if
I
was
in
a
situation
where
I've
identified
no
one's
doing
that
particular
role
being
able
to
refer
to
this
and
have
the
benefit
of
their
wisdom.
G
Yeah
I'll
definitely
say
that
I
always
read
the
chapter
the
right
night
before
like
right
before
I
go
to
bed
for
this
book
club,
because
this
is
my
morning
right
now
and
like
I,
don't
sleep
very
well
after
I
read
these
chapters
because
I'm
always
like
wow,
okay!
This
is
like,
like
there's
a
lot
on
my
plate
here
like
if
this
is
supposed
to
be
a
description
of
what
I'm
supposed
to
be
doing
like
it's.
Just
quite
a
lot
and
I
really
enjoy
the
descriptions
that
she
gets
like
I.
G
Think
it's
a
very
helpful
guide
but
kind
of
to
agree
with
Ben's
Point
like
it's
there's
a
lot
there
right.
It's
like
you
like!
Do
the
product
management?
What
are
your
metrics
for
six
stars
write
a
compelling
narrative
that
anybody
can
understand,
even
if
they're
not
familiar
with
the
problem,
it's
I
can't
help
but
feel
that
I'm
deficient
in
in
many
ways.
Just
given
the
sheer
number
of
responsibilities
described
in
this
chapter
and
the
other
chapter,
oh
Hercules,
you
have
your
hand.
B
Yeah
I
just
wanted
to
mention
one
small
detail:
I
read
in
the
chapter
about
a
mistake
and
it
really
resonated
with
me
because
I
made
this
mistake
before
in
one
part
of
the
book.
It
says
that
don't
specify
in
details
the
Technologies
use
it
when
you
are
writing
a
design
document
and
I
have
made
this
mistake
before
and
because
I
knew
my
strengths
and
my
skills
and
also
I
knew
the
team.
B
They
could
be
any
other
programming,
language
or
framework,
because
the
problem
at
hand
was
not
something
super
difficult
to
solve,
but
then
people
started
discussing
why
using
these
Technologies
instead
of
focusing
on
the
problem
and
how
to
solve
the
problem
and
yeah,
we
wasted
a
lot
of
time.
Just
because
of
that.
If
I
have
left
out
this
detail,
people
would
discuss
about
the
problem
at
hand
and
how
they
wanted
to
solve,
instead
of
just
discussing
why
using
a
specific
technology.
E
Yeah,
that's
that's
a
fantastic
point.
I
think
part
of
part
of
choosing
the
the
story
you
want
to
tell
particularly
when
you're
selling
an
idea
is,
is
choosing
the
points
of
focus
that
you
want.
Readers
and
reviewers
to
to
focus
on
I
I
spend
a
lot
of
time
differentiating
between
what
is
the
problem
that
we
want
to
solve
versus.
E
How
are
we
going
to
solve
it
and
I
find
it
really
useful,
depending
on
the
context
and
the
people
that
you're
working
with-
and
you
know,
the
relationships
that
you
have
separating
those
two
out
can
can
be
really
useful,
so
I
guess
sometimes
I
guess
what
I?
What
I'm
saying
is
I
feel
like
it's
always
helpful
to
describe
the
problem
in
in
in
an
easily
understandable
way.
E
Apart
from
the
implementation-
and
sometimes
it's
also
useful,
as
an
addendum-
to
increase
to
include
a
concrete
example
of
of
pieces
of
the
solution
as
kind
of
an
optional
for
reference,
not
not
as
a
as
a
mandatory
requirement,
sometimes
concrete
examples,
help
kind
of
you
know
drive
the
conversation
forward.
I
guess
is
all
I'm
really
having.
A
A
You
might
be
inclined
to
share,
like
all
of
the
information
that
you
have,
because
more
information
is
better,
but
that's
not
necessarily
true,
because
too
much
details
obscure
your
message
and
I
think
I've
run
into
that
a
lot
with
with
status
updates
and
with
just
because
we
are
async,
it's
kind
of
like
you
know.
I
I
might
not
hear
back
from
this
person
until
tomorrow,
so
I
should
give
as
much
information
as
possible,
but
then,
when
I
do
hear
back,
they
missed
the
main
thing
and
went
with
the
second
part.
E
I
totally
agree:
I
don't
know
if
this
is
helpful
to
anyone
else,
but
I
I
compulsively
need
to
give
like
you
know
the
you
know,
detailed
messages,
so
I'll
always
write
that
out
in
detail
and
then
go
back
to
the
very
top
of
the
thing
and
try
to
summarize
it
in
one
or
two
sentences,
and
that
way
people
can
ignore
everything
else.
I
wrote
If
if
they're
not
interested
in
more
than
the
gist.
C
Yeah,
if
you
go
to
our
index
page
for
all
the
architecture,
architecture,
Evolution
blueprints-
you
will
see
that
almost
everyone
has
an
executive
summary
at
the
beginning
and
a
couple
of
times,
I
got
explicitly
asked
to
add
executive
summary
because
someone
didn't
really
want
to
read
through
all
of
it.
So.
H
One
of
the
things
I
actually
thought
about
like
Jesse.
Where
is
like
what
race
must
be
curious,
like
no
there's
I
mean
there's
no
way:
you're
you're
a
single
person.
You
only
have
so
much
time
in
your
day
and
that's
assuming
that
you
don't
get
pulled
into
incidents
and
escalations
which
I'm
sure
pretty
much
all
of
us
do.
H
I
wanna,
actually
like
go
back
to
a
little
like
kind
of
much
earlier
in
the
book
where
the
author
talks
about
how
they
had
written
this,
to
well
focused
on
staff,
engineer,
actually
to
be
able
to
apply
to
a
lot
of
different
roles
and
also
recognizing
that
stop
loss
can
mean
so
many
different
things
and
cover
a
very
different
set
of
responsibilities
depending
on
the
organization
and
the
organizational
needs.
H
So
it
do.
You
kind
of
want
to.
H
You
know
almost
reiterate
the
fact
that
I
don't
think
anyone
expects
any
of
us
to
like
do
all
of
these
things
and,
while
I
found
the
exercises
useful
to
think
about
I
honestly
didn't
actually
work
through
any
of
them
on
on
paper
or
or
anything
part
of
it
was
time,
but
part
of
it
was
should
I.
Don't
know
that
it's
the
right
time
for
me
to
be
going
through.
H
Some
of
those
exercises
I
feel
like
some
of
them
will
that
opportunity
is
kind
of
passed
or
it's
something
that
I
need
to
look
at
later,
like
potentially
but
I
I.
Don't
know
that
it's
useful
for
me
right
now
and
I
mentioned
before
in
support.
In
particular,
we
have
a
very,
very
Broad
scope
of
responsibilities.
H
I
mean
look
at
how
big
the
product
is.
I'm
sure
that's
true,
though
even
in
like
and
while
the
scope
I
think
is
a
little
bit
different
for
someone
in
development.
Most
of
the
time
sure
it's
true
in
for
a
true
I
mean
input
covers
so
much
right
when
same
with
security.
It's
like
no
staff
that
we've
had
has
been
focused
on
the
same
thing.
H
And
I
think
it's
important
to
have
a
good
understanding
of
what
your
focus
and
scope
should
be
when,
whenever
you're
stop
loss
or
even
working
towards
a
stop
loss
or
promotion,
so
I,
don't
that's
kind
of
my
take
on
it.
I
do
want
to
emphasize
that
especially
gitlab
is
such
a
large
product.
Most
of
the
time.
There's
there's
no
way
you're
going
to
be
able
to
know
and
do
everything.
C
Yeah
I
think
it's
really
interesting.
Today,
I
had
this
conversation
with
someone
about
the
staff
class
engineer,
archetypes
that
we
have
documented
in
our
handbook,
and
someone
asked
me
like
how
can
you
do
all
those
things
or
am
I
supposed
to
do?
One
of
those
things
and
for
me,
it's
more
like
being
willing
to
do
all
of
those
things,
but
perhaps
specializing
in
one
or
two,
but
when
there
is
a
business
need,
you
can
actually
transition
between
different
archetypes.
C
But
it's
never
like.
You
are
the
best
in
all
of
this,
but
you
know
sometimes
it's
just
what
you
prefer
to
do
and
I
think
in
the
end,
it's
just
about
having
a
positive
impact
on
the
company
on
people
around
you.
B
C
Yeah
I'm
not
sure
if
this
you
know
answers,
question
or
yeah,
but
the
archetypes
may
be
confusing
a
bit.
E
Yeah
I,
I
I'll.
Add
that
I
think
it's
it's
really
important
to
give
yourself
the
latitude
to
take
off
a
hat
when
you're
putting
on
a
different
hat,
and
it's
also
really
valuable,
because
everyone's
gonna
have
their
own.
You
know
interests
and
and
and
aptitudes
and
I,
think
respecting
that
in
your
own
work
is,
is
really
important.
It's
okay,
to
give
yourself
latitude
to
focus
on
areas
that
you
find
rewarding
and
gratifying
as
long
as
you're
able
to
put
on
the
other
hats
as
needed.
B
Yeah
just
a
side
note
regarding
the
archetypes
I
believe
it's
I
think
of
well
maybe
opportunity
and
what
you
are
aiming
for
for
your
career,
because
you
can
be
the
expert
and
then
you
will
have
your
mind
already
said
to
be
the
expert
in
a
certain
technology
or
a
certain
area
of
the
business.
B
And
then,
when
the
time
comes,
then
you
are
able
to
mix
like
your
expertise
with
the
opportunity,
and
sometimes
people
have
more
people
related
activities
like
managing
teams
or
cross
across
team
collaboration,
and
they
are
both
like
staff
plus
engineer
tasks,
but
they
have
completely
different
skill
sets.
Let's
say
some
people
are
driven
in
a
certain
path.
Other
people
they.
B
Intentionally,
try
to
aim
for
that
specific
archetype,
so
I
don't
think
there
is
a
right
or
wrong
decision
to
you.
Maybe
it's
more
I,
think
of
do
we
have
opportunity
to
do
this
in
a
certain
way
and
use
our
skill
set,
or
are
we
driven
away
from
what
we
are
aiming
and
we
because
we
need
to
do
a
different
kind
of
test.
A
I
think
it's
interesting
like
on
the
on
the
subject
of
big
projects
like
if
we
look
at
each
archetype
like
what
role
they
play
in
a
big
project
and
and
it's
like
they
can
all
play
similar
roles
but
coming
from
different
angles,
depending
on
their
Styles
and
expertises,
which
I
think
that
adds
to
the
just
overall
I
guess
variety
of
ways
that
things
can
get
done.
D
I
want
to
ask
people's
texts
on
how
do
you
feel
about
big
projects
in
general
and
I'm,
going
to
define
a
big
project
as
I
guess,
project
attacks,
let's
say
longer
than
a
quarter.
I
I
will
say
in
my
experience
with
big
projects
here,
I
find
it
it
can
be
difficult
to
see
them
come
to
like
completion.
For
me,
that's
what
I've
seen
because
I've
I've
had
all
quite
a
few
times
where,
like
organizational
priorities,
get
shifted
and
all
of
a
sudden.
Oh
no,
we
don't
go
back
and
touch
that,
and
it's
it's
hard
to
get
back
to
those
things
and
I,
don't
know
yeah,
it's
just
something.
I've
observed
I
haven't
found
any
really
good
way
to
like
adjust
it.
I
C
Yeah
I
think
it's
interesting
that
right
now,
I'm
involved
in
a
couple
of
big
projects
and
in
the
past
I
definitely
experienced
this
problem
of
Southern
priority,
changing
priorities
and
moving
on
to
different
things.
C
C
You
can
interrupt
the
project
between
phases,
but
a
phase
should
be
done
as
a
whole,
but
phases
are
small
enough
to
actually
convince
people
that,
let's
finish
this
phase-
and
this
is
especially
important
when
you
think
about
technical
depth
that
may
be
left
in
the
code
base
when
phase
is
not
complete
and
then
stuff
like
that,
so
helping
PMs
and
EMS
to
plan
the
work
in
a
way
that
there
are
phases
and
iterations.
It's
really
helpful
to
avoid
this
problem
of
living
a
lot
of
technical
debt
when
there's
a
suddenly
changing
priorities.
G
B
G
You
know
in
front
and
back-end
technical
writer
like
wearing
these
little
pods,
which
is
really
great
for
pushing
forward
initiatives
that
are
specific
to
that
group
really
quickly,
because
it's
very
efficient
for
that
group,
but
it
makes
cross-organizational
projects
more
difficult,
and
you
know
there
are
other
ways
to
organize
a
company
and
they
all
have
you
know
pros
and
cons,
but
I.
Think
for
me.
Looking
at
work
on
a
large
project,
that's
going
to
require
across
organizational
support.
G
I,
definitely
ask
myself
the
question:
you
know
how
do
I,
how
do
I
get
these
people
motivated
to
even
help
with
this
large
project
because
it
helps
them,
but
it
it's
really
a
project
that
comes
out
of
my
group
and
I
think
that's
kind
of
the
most
intimidating
thing,
not
so
much
the
length
of
the
project,
but
the
span
or
the
the
scope
of
people
who
need
to
be
involved.
D
Yeah,
that's
that's
an
interesting
point,
because
I
I
was
thinking
more
about
duration
and
scope
or
I.
Guess
how
many
stakeholders
there
are
potentially
is
is
another
access
by
which
it
can
evaluate
the
size
and
scope
of
a
project.
E
Yeah
I
feel
like
I
I,
think
I
share
Jesse's
perspective,
it's
the
the
more
the
more
the
larger
number
of
people
you
have
to
bring
into
a
project
the
harder
it
is
for
me
personally
to
to
kind
of
metabolize
the
anxiety
and
stress
of
selling
the
idea
to
each
group
that
needs
to
be
part
of
it.
E
Once
once
we
have
once
we
have
some
momentum,
though,
once
we've
got
people
you
know
invested
in
in
solving
it,
I
love
working
on
projects
where
we
we,
where
we
can
build
up
the
momentum
and
particularly
if
we've
got
if
we've
got
solid,
break
points
between
to
to
deliver
results.
Iteratively,
I
think
to
your
point
of
a
project.
Spending
multiple
quarters
totally
totally
agree.
It's
it's
important
to
have
I
love
the
framing
of
having
phases
where
you
can.
E
You
can
stop
after
completing
a
phase,
and
you
have
something
deliverable
you've
got
you've
got
clean,
stopping
points
and
people
can
kind
of
reconvene.
After
after
the
phase.
D
I
wanted
to
before,
since
we're
about
a
time.
I
wanted
to
also
give
my
perspective
on
the
question.
I
asked
I
hate,
big
projects,
I
hate
them;
okay,
that's
all
thanks.
C
Yeah
so
I
think
that
the
last
point
is
mine.
I
I
wanted
to
share
this
project
I
created
some
time
ago
to
make
it
easier
for
people
to
ask
questions,
and
perhaps
there
are
questions
that
are
not
big
answered
in
a
book
and
perhaps
we
have
a
stop
plus
principle
plus
Engineers
who
can
answer
them,
and
my
commitment
here
is
that
I
will
try
to
find
answers
for
you.
If
you
have
them,
I
I
may
not
be
able
to
do
that,
but
I
can
at
least
try.
A
Thanks
Ben
did
you
want
to
verbalize
your
last
point
there
about
the
last
discussion.
F
Yeah
I've
been
involved
in
large
projects,
but
generally
speaking,
I've
I've
been
an
individual
contributor,
but
in
terms
of
being
responsible
in
any
way
for
a
project.
F
Yeah
I
can't
conceive
of
all
of
my
roles
fundamentally
have
been
torn
between
so
many
different
things,
usually
kind
of
operational
responsibilities
and
mentoring,
people
and
just
diving
into
whatever
was
on
fire.
But
there
was
a
couple
of
rolls
back.
I
was
running
backup
infrastructure
and
fundamentally
we
needed
to
rebuild
all
the
server
infrastructure
from
scratch
and
most
of
the
fiber
channel
infrastructure
as
well
and
I'd
been
planning
for
it.
For
years,
I
had
service
racked
up
and
I've,
been
begging,
Bull
and
stealing.
F
Everything
I
needed
to
do
the
work
and
then
I
resigned
and
I
delivered
it
in
my
notice
period,
and
that
was
the
only
way
I
could
get
the
focus,
because
management
would
then,
like
we've
got
to
get
this
done
now
and
so
yeah.
Basically,
I
wasn't
allowed
to
do
anything
else
so,
but
yeah
I'm
part
of
that.
A
All
right,
well,
I,
think
that's
a
good
point
to
stop
it
since
we're
a
little
bit
over
time
here,
but
thanks
everyone
for
joining
in
and
yeah
I
look
forward
to
talking
about
talking
about
chapter
six
next
week.