►
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
Hey
everyone
welcome
to
the
staff
Engineers
path
book
club.
This
is
the
Americas
and
APAC
session
and
today
we're
going
to
be
discussing
chapter
five,
which
is
leading
big
projects
top
you
have
the
first
point.
If
you
want
to
get
started.
B
Yeah
sure
so,
overall
I
think
the
chapter
has
some
really
good
advice.
It
talks
a
bit,
though,
about
recruiting
people.
C
And
also
assigning
roles,
so
I'm
just
wondering
like
on
a
large
project,
should
a
staff
class
be
even
doing
those
or
is
it
more
collaborative.
A
C
A
A
A
And
it
seems
that
at
gitlab,
that's
kind
of
like
where
we
see
Senior
Management
getting
involved
and
putting
together
the
team
I
speculate.
Maybe
they
are
talking
to
some
of
the
staff
folks
when
they
do
that,
but
I
don't
really
know,
and
then
the
second
type
of
project
is
one
that
includes
cross-team
work,
and
so
the
project
might
start
with
one
team.
But
then
it
extends
to
other
teams
or
needs
work
from
other
teams.
A
And
so
what
I've
seen
here
is
that
the
person
or
people
leading
the
project
reach
out
to
those
teams,
but
don't
necessarily
like
name
who
they
want.
Help
from
and
then
it's
kind
of
up
to
the
other
team
to
decide.
Okay,
we're
gonna
allocate
one
person
to
help
with
this
project
for
a
period
of
time.
Here
are
those
people
and
that's
sort
of
decided
within
that
other
external
team.
A
So
that's
at
least
what
I've
seen
I'm
kind
of
curious
to
hear
of
others
have
seen
other
behavior
and
then
kind
of
as
a
side
note.
So
that's
sort
of
like
recruiting
people
and
assigning,
but
when
it
comes
to
like
assigning
roles,
I
do
think
we
do
a
good
job
of
sort
of
delegating
responsibilities
and
roles
like
I
always
see
like
there's,
always
a
dri,
there's
always
someone.
That's
kind
of
posting
updates
and
people
seem
to
know
what
their
specific
role
is
in
a
project.
A
I
don't
know
if
we
formally
write
it
down
all
the
time,
but
it
seems
like
we
do
a
pretty
good
job.
D
Yeah
to
your
point,
Steve
I
think
when
I
read
this
chapter,
like
working
groups,
came
to
mind
when
we
were
looking
for
specific
roles
on
on
bigger
projects,
but,
as
you
mentioned,
like
you
know,
some
of
these
initiatives
can
come
up
some
up
organically
or
if
there
is
a
need
so
to
answer
on
this
question,
I
think
it
really
depends.
D
I
do
agree
with
you
that
I
think
it
is
a
lot
for
staff
Engineers
to
spend
their
time
recruiting
people
so
especially
for
that
cross
stage.
Effort
and
I
think
this
is
where
Steve
mentioned,
like
Em's
or
a
higher
level
could
help,
but
I
do
think
part
of
it
is
having
enough
of
an
understanding
as
well
of
why
it's
important
prior
to
advocating
for
it.
So
I'll
give
you
an
example
of
something.
I
I
worked
on
recently.
D
I
think
I
actually
talked
about
this
in
a
few
weeks
ago,
with
the
CI
data,
partitioning
efforts
and
I
know
there
was
a
blueprint
involved.
Initially,
when
I
was
working
with
Jacob
she's
like
oh,
we
need
to
do
this
and
I'm
like
okay
and
then
so
we
talked
about
it
in
one
101
and
then
we
didn't
really
get
back
to
it,
and
you
know
it
was
really
a
lot
of
it.
It
was
I
have
to
say
it
was
his
effort
to
drive
it
he's
like
no.
D
No,
we
really
need
to
do
this,
or
else
you
know.com
Falls
over,
like
you
know
worst
case,
of
course,
but
you
know
having
myself
understand
it
better
and
then
I
was
able
to
Advocate
it
better
as
well,
so
that
we
were
able
to
add
people
and
from
that
I
was
able
to
have
conversations
with
products
talking
about.
D
You
know
why
we
need
certain
people
on
this
initiative
and
how
that
you
know
is
a
higher
priority,
maybe
even
some
of
the
other
product
initiatives
we
have
on
our
plate,
so
yeah,
it's
I,
think
I
would
also
just
say
it
is
helpful
to
Leon
Engineering
Management
for
it,
but
yeah
I
think
I
think
it
really
depends
on
the
project.
C
C
Em
that
formally
kind
of
handle-
that
is
a
huge
help,
if
especially
for
large
projects,
yeah.
E
Yeah
I
was
what
I
took
away.
Is
that
if
you're,
if
you're
the
Technic,
if
you're
leading
a
project
as
a
staff
person,
you
do
need
to
be
aware
that
these
things
need
to
be
done,
and
it
at
the
book
mentioned
like
having
like
a
clear
you
know,
you
should
be
aware
that
these
things
need
to
be
done
and
that
someone
is
doing
them,
not
necessarily
that
you
have
to
spend
your
time
doing.
That.
E
A
One
thing
that
I
thought
was
interesting
that
you
said
Cheryl
is
that,
like
it
was
kind
of
like
you
started
out
with
that
conversation,
and
then
you
ended
up
kind
of
going
to
product
and
and
talking
to
a
bunch
of
other
folks,
and
so
that
kind
of
actually
like
it
reminded
me
a
lot
of
how
they
talked
about
like
the
sponsorship
roles.
A
In
terms
of
of
how
some
of
these
relationships
work,
where,
like
the
the
Project
Lead
or
the
staff
person
like,
is
kind
of
like
pushing
the
project
forward
and
getting
it
moving,
but
then
they
need
like
a
voice
in
in
that
management,
Circle
to
kind
of
push
for
it
in
those
and
and
inform
people
in
those
other
areas.
So
kind
of
sounds
like
that
might
have
been
like
a
little
bit.
What
happened
there.
D
D
It
is
sometimes
tricky
conversation
when
you
know
there
could
be
other
priorities
products.
You
know
on
roadmap
and
we
need
to
sort
of
determine
how
best
to
proceed.
C
This
might
be.
Let
me
let
me
get
at
my
thoughts,
okay,
so
as
a
staff
plus
you,
you
do
have
a
kind
of
a
your
own
okr
or
Psy
projects.
So
I
have
a
long
list
of
potassium
projects.
I'm
curious
how
the
folks
choose
their
projects.
C
Is
it
customer
goes
or
results
or
improving
the
architecture?
How
would
you
choose
those
projects
for
yourself.
A
That's
really
good
question:
I'll
speak
of
my
two
experiences.
First,
looking
at
the
product
development
side
of
the
org
and
I.
Think
from
that
side
it's
at
least
my
experience,
so
not
being
a
staff
engineer
is
that
a
lot
of
that
comes
from
working
with
product
managers
and
Engineering
managers
to
decide
like
what's
important,
I
think
there
is
a
lot
of
advocating
coming
from
the
engineers,
depending
on
the
team
that
you're
on
I
suppose,
like
I
know
that
on
my
team,
we
spent
a
lot
of
time
discussing
what
was
important.
A
And
why
and
like
not
just
kind
of
like
saying
whatever
the
product
manager
says
goes.
So
that's
kind
of
how
we
chose
products
or
I
mean
it
shows
projects
from
that
aspect
and
now
on
the
infrastructure
side.
A
It's
interesting
because
a
lot
of
it
is
more
I
mean
it's
still
very
like
need
driven
based
on
customers,
but
because
the
customer
is
internal,
it's
kind
of
a
little
different,
so
there's
a
little
bit
more
room
for
us
to
kind
of
advocate
for
things
that
that
others
might
not
like
see
as
much,
and
so
even
though
it's
a
similar
idea,
it
feels
a
little
different
I,
don't
know
if
that
makes
total
sense
or
not.
E
This
wasn't
this
was
well,
it
was
yeah,
so
we
we
listed
things
that
are,
we
want,
you
know,
and
then
we
also
had
a
weight
of
how
important
that
is,
and
then
we
just
like,
went
down
sort
of
and
filled
it
in,
like
we're
choosing
between
three
options
and
like
how
well
each
opposite
option
was
able
to
do.
You
know
fulfill
those
kind
of
require
those
wants
that
we
had
and
the
weight
kind
of
helped
it
from
like
getting
in
a
situation
where,
like
maybe
you
have
one
option.
E
That
does
a
lot
of
things
that
well
that
actually,
you
don't
value
as
much
as
some
other
options,
and
it
was
a
bit.
It
was
a
bit
formal,
but
I
think
we
were
sort
of
I.
Think
we
didn't
need
to
sit
down
and
do
it
in
a
formal
way
at
the
point
we
were
at
if
not
and
I
think
I
think
more
than
the
score
like
having
things
broke
down
like
that
makes
it
easier
to
make
a
decision
because
you're
not
like
making
one
correct
decision.
E
You'd
like
you're,
just
making
a
bunch
of
small,
lower
Stakes
decisions
in
a
row
and
then
looking
at
the
like
the
com,
the
composite.
F
Matter
of
you
know,
you've
got
a
list
of
projects
that
you
could
work
on
weighing
the
okay.
These
are
projects
that
would
you
know,
Advance
the
product
versus
these
are
projects
that
would
enable
other
people
to
deliver
better,
faster,
more
efficiently,
insert
whatever
phrase
you
wish
to
use
there
and
weighing
those
two
against
each
other
and
as
staff
you
know
advocating
for
the
one
that
you
think
would
be
most
useful
to
the
company,
whether
that's
the
aligns
with
what
product
or
management
believes
in
or
something
different.
That
would
ultimately
provide
value.
A
A
If
you
really
want
to
to
see
it
get
moving,
and
so
do
you
feel
like
there
was
a
fair
amount
of
like
ideas
covered
in
the
book
about
how
to
evaluate
whether
or
not
something
is
worth
doing
and
I
mean
I'd
have
to
pull
up
the
list
which
I'm
not
going
to
be
able
to
do
quickly.
But,
yes,
yeah.
C
D
Yeah
I
was
just
going
to
ask
if
anyone
since
reading
that
has
considered
those
variables
or
resources
when
taking
on
certain
projects.
A
I
definitely
do
it
explicitly
like
like
I,
don't
I'm
not
like
consciously
thinking
about
it,
but
if
I
think
back
about
like
why
did
I
choose
to
do
this?
It
definitely
can
easily
be
be
drawn
into
like
I
wanted
to
do
this
because
it
will
increase
my
credibility
or
increase.
My
social
capital,
like
like
a
good
example,
would
be
when
I
on
board
onto
a
new
team.
A
I
pick
up
a
variety
of
issues
that
I
see
are
like
impactful,
but
maybe,
like
also
I,
don't
know
like
visible
and
the
idea
being
that
you
know
these
are
new
people.
They
don't
know
me
I
want
to
increase
my
social
capital
these
first
few
months
and
then
I
can
kind
of
switch
to
the
other
track
of
focusing
on
other
things.
A
C
A
C
F
Yeah,
that's
one
thing
that
I've
noticed
occasionally
when
I
was
working
at
the
staff
level
was,
you
know,
often
you're
the
person,
that's
doing
the
initial
groundwork.
You're,
not
the
person,
that's
going
to
take
the
project
across
the
finish
line,
so
it's
finding
the
thing
that
needs
to
be
worked,
doing
enough
work
to
get
everybody
else
behind.
That
needs
to
be
continued
and
then
setting
it
up
so
that
somebody
else
could
take
it
over
and
keep
it
and
take
it
across
the
finish
line.
E
Yeah
I
did
like
the
point
the
book
made
about
that
you.
If
you
do
code
as
a
staff
engineer
like
you,
need
to
be
careful,
it's
reset
the
standard,
and
you
know
if
you
kind
of
rushed
the
curtain,
because
you
can
and
maybe
you're
not
adding
all
the
tests
or
breaking
the
Mars
up,
because
you
know
you
can
just
bang
it
out.
You
know
you're
kind
of
signaling
that
this
is.
This
is
the
way
to
do
it
in
a
way.
That's
like
really
powerful.
F
D
D
So
yeah,
when
I
was
reading
this
chapter
I
mentioned
earlier,
that
I
was
reminded
of
our
concept
of
working
groups,
I'm
curious
how
folks
feel
about
managing
their
time
between
work
and
working
groups
if
you've
had
experience
working
with
in
a
working
group
and
say
work
on
your
teams,
for
example,
I've
heard
and
EM
mentioned
to
me
once
that
a
working
group
I
think
it
was
a
vgs
one,
maybe
would
actually
require
50
of
an
engineer's
time.
E
So
when
I
was
on
the
working
group,
I
was
on,
we
were
in
a
a
phase
of
the
project
where
it
was
like
pulling
in.com
and
we
were
sort
of
dealing
with
things
in
a
reactive
way.
So
there
wasn't
much
like
new
coding
being
done.
E
That
was
truly
planned
or,
like
you
know,
a
small
tweak
scene
right
there
getting
things
out
on
production,
so
I
had
more
focused
time.
E
C
In
a
group,
that's
100
because
of
a
working
group
so
anyway,
actually
it's
a
good
thing
that
that
it
can
be
quite
clear
like
that
I've
seen
working
groups
where,
unfortunately,
where
there's
too
much
to
do
and
people
drift
off
instead
and
like
the
vagueness
is
actually
worse
to
me.
F
A
Yeah
I
think
it
kind
of
depends
on
the
working
group.
My
the
one
I
was
involved
in
there
was
essentially
like
there
were.
The
functional
leads
that
that
did
a
lot
of
the
coding
and
they
did
spend
a
fair
amount
of
time
on
writing
code
from
what
I
could
tell.
A
But
then
there
were
there,
were
you
know
it
kind
of
like
there
were
other
roles
that
that
were
less
involved,
maybe
that
that
spent
less
time
being
involved
so
I
suppose
it
depends
on
what
the
working
group
is
set
out
to
accomplish
on
whether
or
not
it
is
a
code.
Heavy
thing,
a
process,
heavy
thing
or
or
something
else.
A
D
Yeah
I
would
agree
that
the
roles
really
help
with
that.
With
my
limit
experience,
I've
seen
that
people
who
are
I
think
just
a
member
of
the
working
group
as
they're
called
we'll
kind
of
just
drift
off
or
just
you
know,
participate
sometimes
but
I
think
I.
Think
to
your
points.
You
know
once
if
someone's
a
functional
lead,
I
think
that's
when
you
see
sort
of
more
consistency
in
attending
or
participating
I'm
working
on
this.
A
A
I
guess
one
of
the
things
that
I
found
interesting
was
when
discussing
like
how
to
sort
of
like
put
a
project
together.
A
There
was
the
like
request
for
comment
document
I,
think
that's
what
it
was
called
and
like
that
definitely
aligns
with
you
know
we
create
issues
for
that
or
an
epic
and
then
discuss
there,
but
what
I
really
liked
was
that,
like
a
lot
of
the
sections
were
described
of
like
here's
all
the
things,
you
really
need
in
order
to
to
say
you're,
ready
to
to
do
this
project
and
went
through
like
metrics
the
goal
the
people
involved,
like
all
of
that
kind
of
stuff
and
I,
was
really
happy
to
see
that,
like
not
only
did
I
agree
with
the
list,
but
I
feel
like
when
I've
seen,
projects
at
git
lab
that
are
well
defined.
A
All
of
that
stuff
is
there.
Maybe
not
just
one
person
got
all
of
that
information.
It
might
have
been
a
combined
effort,
but
we
do
make
a
point
of
focusing
on
a
lot
of
those
same
items
which
I
liked
to
see
that.
E
E
C
Yeah
and
I
found
that
naming
was
is
a
good
point
as
well.
I
think
there
were
I
was
on.
I
saw
the
working
group
where
Sid
in
particular,
was
like
really
obsessed
about
being
clear
on
the
name
and
and
actually
having
a
definition
for
for
names,
so
that
that
I
think
really
helped
reduce
the
amount
of
like
confusion
in
later
conversations
and
then
I
think
a
lot
of
blueprints
now
have
like
it
starts
with.
C
E
Yeah
we
had
an
issue
with
that
with
registry,
with
the
router
Library,
it
has
an
option
called
strix
lashes,
which
means
the
slashes
are
optional
and
I've
really
had
to
break
it.
Down
like
this
is
the
behavior
and
like
even
if
you
have,
if
you
have
one
bad
name,
you
need
an
entire
paragraph
of
text
to
explain
what
it
actually
does.
A
All
right
well
we're
just
about
a
time.
So
if
nobody
has
any
other
items
to
chat
about
and
I'll
go
ahead
and
stop
the
recording
here,
but
thanks
everyone
for
joining
in
excited
for
next
week
for
chapter
six.