►
From YouTube: Book Club - The Staff Engineer's Path (APAC) - Chapter 1
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
All
right,
so
this
is
the
APAC
session
for
the
staff
Engineers
path
and
today
we're
diving
into
the
first
chapter
and
we'll
also
cover
the
forward
and
intro.
If
there's
any
additional
notes,
there
I
added
a
few
notes
to
kind
of
kick
things
off,
but
please
do
add
anything
you're
interested
in
to
the
agenda
and
we'll
kind
of
work
through
mine
and
get
to
everyone
else.
A
So
the
first
few
I
added
were
specific
to
the
forward
and
intro.
So
there
was
on
the
topic
of
management
versus
IC
paths
where
there
was
this
quote.
If
you
could
really
see
five
years
ahead
in
both
paths,
you'd
find
that
they
have
a
lot
in
common,
but
at
the
start
they
look
quite
different
and
I
have
to
admit
so.
I've
talked
to
quite
a
few
staff
plus
folks
and
the
more
that
I
talk
to
them.
A
B
B
So
for
some
context
in
my
previous
year
before
joining
it
live,
I
was
a
senior
product
manager
at
a
a
edu
tech
company
and
I
think
that
it's
kind
of
like
a
staff
classroom
as
well
in
the
sense
that
you
do
have
to
work
cross-functionally
and
you
do
have
to
do
a
lot
of
this
big
picture
thinking
and
also
diving
down
into
the
Beats
just
to
get
things
and
people
motivated
and
moving
along.
Oh
the
the
first
time,
I
assumed
a
manager
where
I
did
that
I
started
here
as
IC
as
well.
B
B
So
if
you
ask
me
it
does
feel
a
lot
like
the
skill
sets
and
the
things
you
kind
of
do
as
a
manager.
They
does
have
a
very
big
overlap
with
the
skill
sets
that
you
will
have
as
a
staff
plus
contributor
I
think.
The
only
difference
is
that
the
focus
is
very
different
as
a
people
manager
I.
My
main
focus
is
in
managing
people
and
making
sure
that
we
are
adequately
resourced
to
actually
do
the
work
that
we
need
to
do
as
a
product
manager.
It
was
a
bit
different.
B
B
Actually
it's
not
so
much
that
the
rules
are
fluid
I
think
there's
a
huge
amount
of
overlap
in
skill
set
and
I
think
that
enables
you
to
kind
of
step
into
either
role,
either
an
IC
at
a
Star,
Plus
row
or
a
manager
plus
row
depending
on
I,
guess
the
focus
that
you
want
to
have
at
any
point
in
time.
At
least
that's
how
I
see.
A
Cool
thanks
for
sharing
that,
so
the
other
one
that
I
noted
here
from
the
intro
was
they
kind
of
laid
out
I.
Think
what
we
were
going
to
work
through
in
the
book
that
there's
these
three
pillars
of
Staff
engineering,
which
are
big
picture
thinking,
execution
of
projects
and
then
leveling
up
Engineers
that
you
work
with
and
so
I
mean
it
seems
like
a
pretty
good
list,
but
I'm
curious.
A
A
D
A
Yeah
I,
agree:
I
think
the
living
leveling
up
is
a
really
interesting
topic,
because
I
think
like
there's
like
that
passive
approach
of
like
if
you're
just
exposed
to
staff
Engineers,
you
learn
a
lot.
But
then
there's
some
people
that,
like
take
a
more
active
role
in
mentoring
and
kind
of
teaching,
and
it's
really
interesting
to
me
the
whole,
like
educational
aspect,
almost.
E
D
E
Realize
my
mic's
not
plugged
in
hey
cool
is
yeah.
I
was
wondering
maybe
the
big
picture
thinking
is
actually
more
project
focused,
usually
in
gitlab
I'm,
not
sure
that's
kind
of
the
experience
I've
seen
coming
across
other
staff
Engineers.
So
it's
in
the
context
of
the
specific
project,
but
I
guess
it'd
be
interesting,
interesting
to
see.
Maybe
examples
of
Staff
Engineers
that
work
on
Big,
Picture
thinking
outside
of,
say,
more
specific
project
contexts.
C
A
F
Foreign
I
feel,
like
that's
the
whole
point
right
like
I,
think,
once
you
become
a
senior
like
okay,
the
past,
pretty
clear,
beyond
that
everybody
especially
has
different
things
like
different
requirements
of
the
company
and
I.
Think
that's
the
whole
point
why
this
is
a
big
Topic
in
itself
right!
It's
the
ambiguity
of
it
that
yeah
that's
hard,
I
guess.
G
Business
acumen
and
an
awareness
of
The
Wider
organization
and
a
way
to
jump
into
a
problem
that
you
don't
have
a
lot
of
familiarity
with
that
is
sort
of
cross
team.
So
you
can
show
your
impact
can
be
bigger,
I,
don't
know
if
you
have
to
in
order
to
be
staff,
but
I
think
that
I
think
ideally,
staff
Engineers
can
do
that.
G
So,
if
you
can
show
that
you
can
do
that
or
at
least
you
have
wider
awareness
of
the
organization,
the
business
goals
as
well
as
how
that
is
a
technical
challenges,
but
like
sort
of
meeting
the
technical
and
the
business
side,
I
think
that's
where
the
leadership
really
comes
in.
Is
it's
not
just
technical,
it's
also
from
the
business
side
of
it
as
well,
but
not
from
a
product
perspective.
It's
like
yeah,
there's
an
impact
also
in
the
business.
A
A
D
I
find
that,
yes,
it's
a
leadership
role,
but
not
everyone
necessarily
leads
projects
or
leads.
You
know
solution,
I,
don't
know
not
necessarily
in
the
in
the
project
context.
It
can
be
someone
just
fixing
problems
and
and
making
things
work.
A
clear
example
to
me
is
Stan
like
he
doesn't
necessarily
have
to
leave.
He
doesn't
lead
project
from
start
to
to
finish
it's
more
like.
Okay,
let's
keep
things
moving
smoothly
and
I
I.
Think
that
shows
like
that
kind
of
leadership,
just
slightly
different
I
guess.
E
All
right,
one
thing
that
stood
out
to
me
was
some
of
the
stuff
about
scope
and
how
it
kind
of
like
Illustrated,
being
a
staff
engineer
at
sort
of
different
levels.
So
like
say
within
the
team
within
I
guess
in
our
context,
probably
like
a
group
or
a
stage
and
then
probably
wider
and
I
guess
sort
of
the
difference
between
maybe
like
how
Hands-On
you
are
at
those
different
levels
and
how
closely
you're
working
with
your
manager.
G
One
thing
that
struck
me
when
I
was
I
think
going
back
to
this
blog
post,
because
I
had
some
in-depth
conversations
about
people
and
what
they
thought
that
staff
meant
to
them
and
for
some
people
it
was
avoiding
people
all
together
and
just
looking
at
long-term
kind
of
subtle
issues
that
people,
maybe
don't
don't
notice,
because
they're
so
subtle
and
and
very
much
cross
team.
And
there
were
some
people
who
jump
into
broken
Masters
and
do
the
sort
of
incident
response
and
all
those
you
know
very
fast
thinking.
G
C
G
Like
I
I,
remember
talking
to
somebody
who
says
I'm,
not
a
fast
thinker,
so
he
never
touched
broken
Masters
or
incidents,
because
I
just
can't
think
that
fast.
But
it
was
very,
very
good
at
hey.
I
noticed
that
this
very
low-grade
problem
is
there
and
that
we
can
fix
it
by
doing
the
following
things.
G
H
G
G
G
H
Thanks
thanks
for
for
the
details,
the
reason
I
asked
about
that
was
because
one
of
the
things
I
think
I
struggle
with
is
you
know,
say
you
come
up
with
some
kind
of
thing
that
you
think
can
will
provide
a
lot
of
productivity
increase
or
you
know,
it'll
help
prevent
broken
Masters.
Something
like
that.
So
you
provide
a
an
issue
with
all
the
details,
but
then
it
just
gets
put
into
the
backlog,
because
maybe
you
don't
bring
it
in
front
of
the
right
people
now
you
could
just
implement
it
yourself.
H
G
This
is
a
thing
that
should
be
worked
on
and
if
you
can
break
it
down
enough,
make
it
small
and
accessible
and
easy
and
interesting
for
people
to
work
on
it,
then
that
that
is
definitely
something
that
can
be
done
as
well,
and
that's
just
some
problems.
It's
not
going
to
work
with
that,
but
for
some
things,
I've
seen
where,
where
you
do
get
swarm,
I'm
thinking
of
that
the
test
was
it
test
efficiency
where
we
increased
how
fast
the
test
went
by
changing.
G
Let's
let
it
be
in
back-end
tests
and
it
made
the
specs
go
so
much
faster
and
it
wasn't
just
one
or
two
people
working
on
it.
It's
heaps
of
Mrs
from
from
people
and
they
and
I
think
it
was
the
iron
production
who
did
that
and
he
he
made
it
really
easy
and
very
straightforward
to
do
that,
and
he
had
lots
and
lots
of
collaboration.
G
G
E
Do
end
up
writing
a
lot
of
aspect
tests
over
time,
so
I
think
it's
one
of
those
nice
examples
where,
like
doing
the
work
of
a
small
proof
of
concept,
no
doubt
I,
don't
remember
the
full
context
of
it,
but
I
assume
Jan,
probably
wrote
some
tests
rewrote
them
using
letter,
B
compared
speed,
results
or
something
like
that.
Yeah.
I
G
C
Just
to
add
on
to
that
example
of
that
I
think
the
other
thing
that
I
think
yeah
did
was
also
to
make
that
business
case
obvious
by
creating
a
dashboard
that
everyone
can
see
with
this.
This
is
the
impact
of
having
slow
tests
like
how
much
time
are
we
wasting
on
this
and
I
think
that
made
because
they.
F
C
I
Sorry
I
actually
have
a
question,
so
yeah
I
I
have
just
recently
started
with
geek
lab
and
I
found
it
actually.
I
couldn't
take
like
a
lot
of
time
on
to
explore
more
things,
but
it
seems
like
in
order
to
become
a
stop
engineer,
so,
which
means
you
need
to
have
a
bigger
picture,
and
then
you,
you
have
to
be
familiar
with
other,
like
other
things
with
other
departments.
I
A
D
You
know
once
once
you
get
into
like
a
a
good
rhythm
of
working,
and
you
realize
that
okay,
the
team
has
priorities,
and
ideally
the
workload
will
be
shared
among
everyone.
So
once
you
have
a
little
bit
of
time,
whereas
part
of
your
career
development
or
something
like
that,
you
start
exploring
options
in
other
projects
and
then
I
guess
it
depends
on
how
you
can
adapt
to
that
kind
of
work.
D
G
I
just
wanted
to
add
very
quickly,
even
though
I
may
just
nailed
it,
but
yeah
I
have
it
it's
good
to
have
domain
familiarity,
which
I
think
does
happen.
Naturally,
as
you
spend
more
time
here,
I've
there's
been
a
couple
of
times
when
somebody
in
the
dev
department
has
said
hey.
Does
anyone
who
wants
to
work
on
a
thing
with
this
thing
and
I
have
said
yes
and
have
absolutely
not
regretted?
It
I've
just
learned
so
much
about
learning
this
different
part
of
it.
G
So
I've
worked
on
anti-span
stuff
as
well
as
plan
stuff,
I've
worked
on
anti-span
stuff,
I've
worked
on
workspace,
stuff
or
the
projecting
groups,
and
as
well
as
just
other
things
that
have
just
sort
of
popped
up
and
so
I
say
yes
to
those
things
and
I
think
that
in
and
of
itself
is
Career
Development,
because
you
get
a
different
view
of
different
parts
of
the
products
and
of
the
organization
that
just
helps
with
that
holistic.
View.
C
I
I
don't
know
if
this
is
right
to
say,
but
I
don't
think
that
it
is
a
requirement
to
know
abroad
to
have
a
broad
view
across
the
entire
product,
because
it's
just
too
large
I
think
that
depends
on
where
the
person
is.
What
kind
of
what
group,
if
they
are
in
whether
that
group
is,
has
interdependencies
with
other
parts
of
the
product
that
allows
them
to
be
exposed
to
that
in
that
sense.
But
there
are
also
I
think
product
areas
that
are
highly
highly
specialized.
C
G
I
think
you're
absolutely
right
on
that
I
think
it's
impossible
to
know
everything
I.
Do
you
think
that
having
a
kind
of
cursory
understanding
of
how
it
fits
in
is
probably
pretty
important
like
what
is
Italy?
What
vaguely
does
it
do
kind
of
thing?
But
if
you
need
to
know
but
I
think
it's
also
how
do
I
get
this
information?
So,
if
you're
in
an
incident,
it's
like
something's
wrong
with
Italy.
E
Was
just
going
to
say
in
terms
of
like
actually
learning
the
skills
as
well
I.
Think
like
Charlie's
approach
is
definitely
one
way
that
works
quite
well
and
for
me,
I
actually
prefer
some
other
methods,
so
I
do
like
jumping
into
things
like
broken
Masters,
often
because
you're
then
tying
together,
like
different
pieces
of
the
code
base
to
solve
a
quite
specific
problem
as
well
as
that
being
part
of
like
wider
aspects.
E
So,
like
you
know
the
pajamas
migrations
and
the
aspect
test,
migrations
and
things
like
that
have
helped
me
get
a
wider
view
of.
What's
going
on
in
different
parts
of
the
code
base,
I
wouldn't
say:
I'm
completely
well
versed
in
more
in
in
a
lot
of
the
parts,
but
I
have
at
least
like
a
cursory
understanding
of
like
where
to
start
and
I'm
looking
to
solve
a
particular
problem.
G
No,
it's
all
right,
I
think
the
recent
hiring
that
we
that
people
who
bring
us
particular
set
skills
and
who
can
be
Architects
I,
think
the
architect
was
architect.
So
they
have
a
single
problem
that
they're
working
on
and
they
understand
the
business
case
because
that's
the
single
Focus,
but
it's
really
their
skill
set
that
comes
from
outside
that
we
want
and
they'll
get
that
domain
familiarity
that
will
happen
as
they
as
their
journey
and
get
that
continues.
So
I
know
that
some
people
have
sort
of
had
question
marks
like.
G
Why
are
we
hiring
deaf
people
when
they're?
You
know
Engineers
already
in
gitlab
who
could
just
get
promoted
but
I
think
that
it's
a
different
need
of
the
business,
so
I
I,
just
I,
just
think
it's
I
think
the
archetypes
that
they
have
in
well
that
first
chapter
somewhere
was
a
I
think
a
really
good
way
of
understanding
that
staff
is
just
not
one
thing:
it's
you
bring
different
things
to
the
table
depending
on
who
you
are
and
what
you,
what
skills
you
have.
I
G
You
know
they'll
have
for
that,
but
I,
don't
it's
very
hard
to
get
a
job
at
GitHub,
we're
very
fussy
when
we
hire
so
when
someone
is
hired
a
staff,
it's
for
a
reason,
so
I
trust
that
reasoning
and
I
I
think
why
not
just
what
is
good
but
I
think
it
also
borders
on
privacy.
In
terms
of
you
know,
I
don't
think
anybody
was
like.
Well,
you
know,
I'm,
not
gonna,
join
your
I'm
not
going
to
join
unless
I'm
a
Staff
engineer
if
they're
like
well,
we
really
really
want
your
skill
set.
G
F
I
was
about
to
add
something
small
like
again
I'm
in
support
engineering
and
Sonic,
just
like
in
our
case.
Knowing
a
lot
is
actually
kind
of
part
of
the
job
description
to
begin
with,
because
we
got
tickets
and
we
just
deal
with
whatever
came
our
way.
So
that
was
kind
of
like
an
interesting
perspective
in
here,
because
for.
F
A
Oh
we're
a
little
bit
over
time
here.
I,
don't
know
if
we
wanted
to
jump
over
to
Jaime's
comment
about
that
graph,
because
I
do
think.
That's
a
really
interesting
graph
that
talks
a
lot
about,
or
it
says
a
lot
about
scope
and
about
you
know
making
decisions
at
a
level.
Beyond
sort
of
you
know
what
you
initially
start
out.
As
an
engineer,
I,
don't
know
I
mean
if
you
want
to
yeah.
D
Yes,
this
is
the
big
win,
the
and,
if
you
win,
but
how
about
we
do
it
this
way
that
is
going
to
fit
better
in
the
organization
and
with
whatever
else
needs
and
it's
I
don't
know,
I
find
it
interesting
because
it's
it's
I've
seen
it
happen
many
many
times
and
I've
been
learning
from
that
and
I
I
think,
like
over
time,
I've
I've
been
on
the
other
side
as
well
of
a
proposing
option
b.
So
I
feel
like
this
I.
Don't
know
this
crap
just
connected
to
me
for
some
reason.
C
Yeah
I
totally
agree
so
also
order
to
bring
up
this
as
well
and
I.
Think
to
me,
I
do
I
have
been
on
both
sides
like
coming
up
with
a
local
maximum
solution
and
then
also
proposing
something
that
fits
better
I,
find
that
the
the
letter
like
doing
being
happens,
a
lot
more
when
I'm
doing
like
a
maintainer
review,
for
example,
and
that
happens
and
I
feel
that
the
challenge
has
been.
C
How
do
we
like
propagate
this
knowledge
to
more
people,
so
that
then
we
can
help
them
save
time
without
having
to
go
through
like
multiple
rounds
of
review
and
later
on,
finds
out
that
hey?
There
is
a
better
way
of
doing
it
like
I
think
the
challenge
has
been
it's
really
about
like
how
do
we
make
that
awareness
happen
earlier
in
the
development
process?.
G
G
It
means
that
we
identify
the
better
solution,
B
and
then
we
incrementally
do
it
and
I've
worked
in
organizations
so
they're
like
we
don't
need
to
do
unit
tests,
because
that
takes
too
much
time,
I'm
so
glad
that
GitHub
takes
quality
very
seriously
and
we
look
at
the
maintenance
of
what
we
produce
the
cost
of
Maintenance
in
in
and
because
a
lot
of
organizations
do
not
do
that.
I'm
grateful
thanks
for
being
wonderful.
Everyone.
I
So,
even
after,
like
a
couple
of
reviews,
we
still
need
a
lot
more
work
to
get
a
fix,
so
it
iteration
to
me
yeah
I,
think
it
means,
like
things,
are
being
reviewed
and
then
people
are
getting
like
all
sort
of
solutions,
all
sort
of
ideas,
depending
on
their
background
knowledge
and
their
technical
skills,
and
then
that
may
not
lead
us
to
the
to
a
like
perfect
solution.
We
still
need
to
find
out
and
test
it
out
and
then
the
whole
process
is
actually
like
a
like
a
complete
circle.
I
G
A
Have
an
idea
and
then
I
like
refine
it
and
come
up
with
a
better
idea
and
then
only
to
find
out
that
someone
else
has
adds
a
few
little
bits
and
pieces
here
and
there
that
change
the
idea
entirely.
And
then
the
next
person
comes
in
and
does
the
same
thing
again
and
again,
which
sometimes
it
can
be
frustrating
when
things
keep
changing.
But
then,
in
the
end,
you
look
back
and
realize
that
you
know
it
is
the
right
choice.
D
Yeah,
the
good
thing
I
found
is
usually
the
product
managers
and
EMS
are
also
happy
to
support
these
ideas.
So
it's
not
it's
not
necessarily
like
trying
to
fight
with
them
in,
in
the
sense
that
okay
I
want
to
resolve
right
now
versus
okay,
I'm
fine,
with
this,
let's
schedule
the
following
work
as
soon
as
possible,
so
that
we
can
get
the
better
solution
over
time
and
that
I
feel
like
that.
Just
flows
Like
it
Loud
and
it's
I'm
grateful
that
that
happens.
I
A
Okay,
I
don't
know
if
we
want
to
go
into
any
of
these
other
ones
since
we're
a
bit
over
time
here.
Maybe
we
can
save
some
for
next
time
and
meet
back
next
week
for
chapter
two
and
as
I
mentioned,
I
may
or
may
not
come
to
most
of
these
because
they're
a
little
late
but
I'm
able
certainly
lead
for
future.