►
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
today
we're
talking
about
chapter
one
of
the
staff
Engineers
path
and
also
anything
from
the
forward
or
intro
that
if
you
might
have
read
those
areas,
so
I
added
a
few
points
to
start
us
off.
So
the
first
one
is
on
the
topic
of
management
versus
IC
paths.
There's
a
quote:
if
you
really
see
or
could
see
five
years
ahead
and
both
of
these
paths
that
you'll
find
they
have
a
lot
of
in
common.
A
But
at
the
start
they
look
quite
different
and
that's
something
that
kind
of
stood
out
to
me
because,
as
I've
talked
to
more
and
more
staff
plus
folks
I
hear
that
a
lot
that
there's
a
lot
of
there's
a
lot
of
overlap
in
what
you're
doing
and
then
I
also
hear
a
lot
that
many
people
have
at
some
point
already
been
a
manager
by
the
time
they
ended
up,
choosing
the
staff
path,
and
so
that
idea
of
the
like
staff
and
manager
pendulum
seems
pretty
common.
B
A
B
Can
the
I've
been
staff
and
EM
at
other
companies
before
gitlab
and
there's
a
definite
overlap
in
my
experience
in
terms
of
skills
that
you
end
up
using,
it's
really
sort
of
a
like.
What
what
are
you
spending
your
time
focusing
on
and
like
what
do
you
consider
your
output,
but
the
skills
and
the
perspective
the
place
that
you're
sitting
and
looking
at
things
is
different,
depending
on
which
path
you're
taking.
A
Yeah
I
know
that's
that's
interesting,
yeah
and
I
think
yeah.
They
kind
of
touched
on
that
in
the
book
a
little
bit
about
some
of
the
different
skills
that
come
into
play.
Even
in
just
looking
at
the
leadership
aspect,
it
can
be
a
little
bit
different
from
one
side
to
the
other.
A
Let's
see
the
the
second
item
that
I
noted
from
the
intro
section
was
kind
of
addressing
the
non-technical
skills,
so
there's
one
that
stood
out
to
me,
which
is
framing
a
problem
so
that
other
people
care
about
it
and
I
think
this
is
something
that
I've
seen
a
lot
in
our
staff,
Engineers
and
so
I
know
that
having
an
authority
can
drive
other
people
to
care
about
your
opinion
more
whether
or
not
that's
intentional,
but
I'm
curious.
A
What
other
ways
can
we
better
frame
things
so
that
other
people
care
when
you
don't
necessarily
have
that
Authority?
So,
like
maybe
you're
just
you
know,
you're
a
senior
engineer
or
intermediate
engineer
or
you're
working
with
a
set
of
peers
where
you
don't
necessarily
have
that
sense
of
authority,
and
my
first
thoughts
were
you
know,
including
facts.
Anything
that's
backed
with
facts
is
easier
to
kind
of
push
forward
and
then
and
then
taking
time
to
examine
other
people's
perspectives
before
offering
your
own
opinion
to
make
sure
you've
really
thought
about.
A
C
Yeah
and
I
don't
quite
remember
where
I
learned
this
specific
phrasing,
but
I've
heard
of
thinking
in
terms
of
painkillers
versus
vitamins,
so
people
don't
like
taking
vitamins,
they
don't
like
doing
preventative
work.
C
What
they'd
like
doing
is
having
painkillers
I
like
stop
something
stopping
something
negative,
that's
happening
presently,
and
so
it
can
be
helpful
to
think
of
describing
your
problems
in
in
that
way
like.
What's
the
what
is
it
causing
us
now
versus
and
like
what
is
solving
this
problem?
Get
us
immediately
if
you're
a
psychology
person.
This
is
non-linear
temporal
discounting,
and
you
get
this.
You
know
even
things
that
are
very
kind
of
mild
in
intensity.
C
So
even
if
something
seems
relatively
minor,
if
it's
something
that's
closer
in
time,
it
can
have
like
an
outsized
impact
compared
to
what
you
might
think.
It's
the
absolute
value
save
that
impact
is.
A
Yeah
I
think
that
actually
reminds
me
a
lot
of
something
that
very
specifically
that
you
worked
on.
That
I
happen
to
know,
which
is
the
container
registry.
A
You
know
of
all
these
ideas
for
for
features
like
in
the
future,
but
we
needed
to
implement
garbage
collection
and
a
metadatabase,
and
sometimes
that
doesn't
look
that
appealing.
But
when
you
point
out
like
this
costs
us
a
lot
of
money
right
now,
suddenly
it's
very
appealing
to
a
lot
of
other
people.
So
it's
a
really
good
point.
A
All
right,
so
I've
got
a
couple
more
points
here,
so
the
first
one
is
engineering.
Norms
are
set
by
the
behavior
of
the
most
respected
Engineers
on
the
project.
A
D
Yeah,
so
this
is
just
some
examples:
I've
seen
it
is
many,
many
more
which
is
awesome,
so
I
think
I
think
the
first
one
is
sort
of
setting
a
respectful
tone
and
discussion.
You
know
being
respect
for
other
people's
contributions
and
also
having
that
discussion
in
public
there's
also
a
very,
very
awesome
and
very
detailed
incident
reviews
which
really
really
help,
and
it's
very
nice
to
learn
from
as
well
and
then
there's
this
bias
for
actions,
so
small
fixes,
helping
always
share
tasks.
D
So
those
things
I,
guess
they're,
also
driven
by
from
regular
values,
which
is
also
nice,
I.
Think.
E
Yeah,
just
something
that
I
see
and
try
and
emulate
is
the
comic
convention,
especially
like
the
praise
aspect.
When
you
see
something
like
when
you're
doing
an
MR
review
remembering
to
praise
people
I,
think
it's
a
really
values
align
thing
that
we
do
at
gitlab.
E
F
To
expand
a
little
bit
on
the
respectful
discussion
and
feedback
and
merge
requests,
the
accepting
of
of
feedback
is
also
one,
that's
really
prominent
in
in
gitlab.
It
was
really
great.
A
The
next
point
is
mine
again,
so
this
one
I
thought
just
kind
of
like
summed
up
at
least
what
I
assume
is
going
to
set
the
tone
for
a
lot
of
the
book,
which
is
just
staff
engineering
is
a
leadership
role,
so
I'm
like
what
does
everyone
think
about
that
statement?
You
know
from
any
whatever
level
or
perspective
you
happen
to
have.
Is
that
something
that
that
you
agree
with
or
have
thought
about
before,
when
considering
like
what
it
means
to
be
staff.
A
Take
the
silences,
mostly
agreement,
probably
so.
E
C
I
think
hopefully
this
is
not
too
tangential,
but
I
think
one
of
the
things
reading
the
this
chapter
was
how
common
it
was
for
staff
Engineers
to
actually
not
write
a
lot
of
code,
and
you
know,
do
more
design,
work
and
collaboration
across
departments.
You
know
sections
of
a
company,
so
I
think
that's
part
of
you
know.
The
leadership
aspect
is
you're,
not
necessarily
in
the
trenches,
as
it
were
quite
as
much
as
others
as
other
engineering
roles.
E
Yeah
and
also
there's
some
parts
of
that
saying
so
what
you
say
no
to
is
really
important
at
the
start
level
like
and
leaving
leaving
things
you
know,
you
could
do
for
other
people
to
use
those
as
a
learning
opportunity.
G
Could
I
ask
the
staff
Engineers
this
call
just
around
that
idea
of
that
stuff
roles
may
not
necessarily
be
so
kind
of
code
oriented
just
whether
or
not
that
has
been
their
experience
and,
if
so,
positives
and
negatives
around
that.
But
then
personally,
if
anyone
has
any
thoughts.
H
Well,
certainly
at
my
last
job,
I
was
a
staff
level
and
I
was
a
staff
test,
engineer
and
I
wound
up
having
to
bounce
back
and
forth
between
being
Hands-On
on
the
Frameworks,
as
well
as
trying
to
architect
out
the
Frameworks
and
how
they
all
interacted
together
at
that
company
we
had
well,
it
was
an
application
built
up
of
about
2
000
repos
written
in
107
languages,
so
the
Frameworks
had
to
you
know
we
couldn't
have
one
framework
to
rule
them
all
so
figuring
out
how
all
those
pieces
fit
together,
wound
up
being
a
major
chunk
of
my
time
and
wound
up
getting
occasionally
in
trouble
with
management
for
not
being
Hands-On
quite
as
much
as
they
would
like.
H
I
I
can
share
a
story
as
well
I
at
a
these.
Are
these
are
also
stories
about
previous
work,
I'm
just
newly
staff
here,
so
one
is
I.
I
I
really
feel
the
advice
about
about
learning
where
what
to
say
no
to
to
protect
your
time,
I
didn't
do
I
did
that,
very
importantly,
my
first
round
of
of
that
level
and
totally
burned
out
the
I
think
the
the
better
I
learned
through
through
my
mistakes,
that
that
better
use
of
my
time
was
being
an
advocate
for
people
who
who
couldn't,
who
didn't
feel
that
they
had
enough
voice
to
to
raise
their
concerns
and
and
trying
to
build
Bridges
between
between
work
groups
that
didn't
really
communicate
it
and
didn't
understand
each
other's
needs.
I
There
was
partly
a
barrier
of
I
mean
Mutual.
Understanding
is
difficult
to
achieve.
If
you
don't,
you
know,
speak
the
same
language
and
have
overlapping
sets
of
concerns,
so
building
that
Rapport
by
by
Framing
things
in
a
way
that
that
mapped
to
both
of
both
both
of
the
competing
groups.
Sets
of
concerns
was
really
really
fruitful
in
getting
them
to
to
work
better
together
and
and
unblock
each
other.
I
Rather
than
be
a
blocker
for
each
other,
I
think
that
kind
of
bridge
building
becomes
easier
to
do
the
more
experience
you
accumulate
and
the
more
and
the
more
trust
you
build
across
across
teams.
So
I
think
that's
that's
part
of
part
of
the
work
that
you
can
leverage
at
these
higher
levels.
D
Yeah
yeah,
that's
good
points.
I
I
feel
like
it's.
It's
more
that
that
advice
is,
it
needs
to
be
quite
nuanced,
like
I,
think
I
did
my
previous
job
I
I
bounced
between
being
very
court-rounded,
because
I
was
first
starting
out
as
a
staff
level
to
being
very,
not
Court,
oriented
and
and
both
extrins
are
very
harmful
because
it
really
didn't
solve
the
problem
and
and
I
think
this
is
why
I
say
it
depends.
D
You
really
need
to
look
at
the
problem,
understand
the
problem
and
disseminate
your
understanding
of
the
problem
and
how
you
achieve
that
depends
on
the
problem
right
so
and
sometimes
you
do
need
to
dive
into
the
code.
Write
some
POC,
sometimes
you're,
just
organizing
backlogs
right,
so
it
depends
definitely.
H
Yeah,
it
also
sort
of
depends
on
me
to
me
on
how
much
of
your
time
you're
spent
being
a
force
multiplier,
because,
certainly
to
me,
being
a
staff
you're
there
to
multiply
everybody
else's
Effectiveness.
And
if
your
hands
are
on
code,
you
can't
really
be
affecting
other
people
directly
that
much
because
you're
you're
affecting
code.
B
Andy
I
think
you're
touching
on
a
really
important
part
of
that,
which
is
that
staff
is
isn't
so
much
like
a
a
progression
on
the
ladder,
but
it's
a
role
right.
So
it's
like
it's
a
completely
it's
a
different
job
than
being
a
straight,
and
you
know
pure
engineer.
You
have
all
these
other
responsibilities
like
organizing
backlogs
or
finding
the
private
concept,
or
you
know
getting
it
and
writing
the
code
that
makes
it
able
for
other
people
to
do.
You
know
an
extra
two
percent
of
their
work
or
three
percent
or
10x.
J
I
was
just
going
to
add
for
what
it's
worth
just
being
on
the
management
side.
I
think,
although
I
think
I'm
lonely
a
manager
on
this
call,
I
have
managed
staff
Engineers,
who
have
asked
for
more
opportunities
to
write
code.
I,
think
staff,
Engineers
I
think,
as
we've
talked
about,
have
had
more
opportunities
to
maybe
I'm
doing
what
we're
calling
more
and
more
leadership
aspect
of
things.
J
A
All
right,
you
can
move
on
to
the
next
item
here.
This
is
my
last
one,
so
there's
a
section
about
writing
out
your
understanding
of
your
job
and
sharing
it
with
your
manager,
and
there
was
a
big
example
of
what
that
looks
like
and
and
I
thought.
A
That
was
a
great
idea
not
only
for
staff
but
for
any
level
of
engineer
and
maybe
even
Beyond
engineering,
and
it
seems
like
the
kind
of
thing
that
that
can
definitely
be
done
like
regularly
to
kind
of
realign
with
your
manager
and
I
was
curious.
A
If
anyone's
done
this,
like
I
know,
we
all
might
have
career
conversations
but
but
actually
going
through
the
exercise
of
writing
out
like
this
is
what
I
think
I'm
doing
versus
you
know,
maybe
what
you
think
I'm
doing
and
if
so
like,
how
did
that
work
out?.
H
Well,
certainly,
I've
done
that
at
my
last
job
we
wound
up
well,
there
were
three
of
us
that
were
staff
level
and
no
one
in
the
company
really
knew
how
to
use
us.
H
H
A
E
E
It's
in
my
public
handbook,
at
least
in
that
SEC,
is
like
a
big
bullet
point
list
which
I
like
and
then
the
performance
review
that
we
just
did
was
aligned
against
that,
or
at
least
you
know,
for
me,
I
just
copy
pasted
is
what
was
expected
of
me
at
this
level
or
at
the
staff
level,
because
I
guess
trying
to
position
myself
as
a
staff
potential
person,
and
you
can
just
talk
to
that.
So
I
thought
that
was
that
the
last
performance
review
is
quite
useful
for
discussing
this
sort
of
thing.
A
C
Got
the
next
one
yeah
so
I
think
something
that
struck
me
in
the
book
was
that
being
in
a
leadership
position
but
also
not
having
Authority
is
actually
like
a
beneficial
could
be
like
a
beneficial
aspect
of
the
role,
because
you
know
if
you're,
a
manager
and
you're
and
you're
the
technical
aspect
of
this
of
this
role,
but
you're
also,
like
writing
people's
performance
reviews.
They
are
probably
not
going
to
be
as
Keen
to
say,
like
I.
Don't
think
this
is
a
good
idea.
I
have
another!
C
B
It
was
the
biggest
one
of
the
biggest
changes
for
me
when
I
made
Staff
last
summer
was
how
many
people
actually
listen
to
me
with
I,
have
something
to.
B
Want
me
to
weigh
in
on
things
in
a
way
that
I
didn't
have
before
it's
like,
like
things
like
that,
but
I
have
absolutely
no
earthly
concept
of
this
piece
of
the
product
or
experience
with
it,
but
you
want
me
to
like
evaluate
or
something
I.
You
know
it
was.
It
was
very
astounding
and
it
it's
part
of
that,
like
the
social
fabric
changes,
because
you
are
outside
of
that,
you
are
outside
of
that
hierarchical
structure.
So
you
can
be
this
voice,
an
advocate
for
different
things
in
different
ways.
E
I've
got
number
five
people
yep,
so
what
does
it
mean
to
be
in
the
room
in
quotes
where
decisions
have
made
at
gitlab?
So
in
chapter
one,
it
said
if
you
want
to
influence
the
technical
direction
of
your
org
or
business
you'll,
find
yourself
gravitating
towards
opportunities
to
take
a
broader
view.
You'll
need
to
be
in
the
rooms
where
the
decisions
are
happening.
C
Yeah
so
I
think
working
groups
are
probably
the
the
formalist
version
of
that
we
have
here,
but
I
think
you
know
I,
don't
know
how
all
teams
do
that,
but
you
know
they're
they're,
often
in
the
package
stage,
a
big
discussion
topics,
you
know
where
we
invite
feedback
to
sort
of
like
the
larger
Direction,
medium-sized
kind
of
efforts
and
I
think
that's
kind
of
like
the
normal
gitlab
workflow
place
for
that
kind
of
input
to
happen.
D
I'll
talk,
there's
also
architecture
blueprints
as
well,
which
is
an
organized
way
to
discuss
big
changes
to
the
code
base
and
and
various
select
channels.
E
J
E
A
I
think
that
go
ahead.
F
Oh
I
just
say:
I'd
I
think
I'm,
the
only
front-end
engineer
on
the
call,
but
we
have
the
front
end
rfcs
group
or
project
as
well
for
front-end
big
changes.
A
I
was
just
gonna.
Add
that
I
found
that,
like,
if
I,
if
I,
am
curious
about
something
or
a
specific
meeting
that
maybe
seems
like
a
manager.
Only
type
meeting,
usually
like
people
are
receptive
to
letting
you
join
in
and
Shadow
it
or
at
least
sharing
some
of
the
information
from
it.
A
If
you
ask
like
I,
know
some
meetings
like
you,
don't
want
to
overcrowd,
but
I've.
Never
like
asked
about
a
topic
or
a
meeting
that
I
wasn't
able
to
like
eventually
like
kind
of
like
learn
about
either
indirectly
or
directly.
K
Perhaps
this
is
a
bit
silly,
but
sometimes
up
come
across
proposals
inside
of
issues
or
epics
and
while
I'm
a
person
who
may
not
have
a
contribution
to
said
proposal
I
at
least
do
make
sure
I
hit
the
little
notification
icon.
So
I
get
pings
on
stuff
like
that
in
the
future,
and
I
could
read
about
that
in
the
future
as
it
progresses
over
the
course
of
time.
I
I'm
curious
about
about
how
folks
feel
about
this,
so
the
the
book
characterizes
talks
about
characterizing
your
yourself
as
a
useful
framing
as
being
a
depth
first
versus
a
breadth,
first
kind
of
kind
of
personality
and
I
I've
used
this
framing
for
myself
for
many
many
years,
I
have
depth
first
for
sure.
A
lot
of
the
answers
I'm
hearing
are
here
to
this
last
question,
really
kind
of
reflects
sort
of
a
breadth,
first
survey,
kind
of
style
for
discovering
new
topics.
I
Does
anyone
have
any
thoughts
on
how
I
guess,
I'm
kind
of
curious?
How
how
how
folks
feel
about
exploring
things
in
a
depth?
First
manner.
I
I,
imagine
that
would
take
the
form
of
things
like
having
choosing
particular
areas
of
to
to
build
a
greater
depth
of
domain
expertise
and
staying
plugged
in
in
those
particular
channels,
whether
they
be
slack
or
or
rfcs
or
design
docs.
What
not.
C
Yeah
so
I've
worked
on
the
container
registry
project
for
my
entire
tenure
here.
So
that's
coming
up
over
three
years
now
and
it's
not
a
small
project,
so
I
think
it's
just
picking
picking
a
place
and
starting
to
dig
a
hole
basically
and
not
not
digging
another
hole
and
so
I
I
I
like
it.
It
is.
C
Container
she's
big
enough
where
I
don't
quite
know,
I
can
know
most
of
it,
but
there
was
an
MR
Upstream
which
I'm
also
maintainer,
and
it
was
a
part
of
the
code
that
I
haven't
touched
before
and
it
was
like
walking
into
a
room
in
your
house.
You
didn't
know
it
was
there.
C
It
was
that
same
feeling
of
how
does
this
exist,
but
you
know
having
that
sort
of
knowledge
in
that
context,
I
I,
like
it
and
being
able
to
provide
kind
of
nuanced
answers
to
why
things
are
and
are
not
possible.
I
really
do
enjoy
that.
I
Fantastic.
Thank
you.
Thank
you
for
that
response,
for
what
it's
worth,
I
I
feel
the
same
way.
It's
I
think
there's
a
lot
of
a
lot
of
benefit
to
being
able
to
speak
to
we're,
probably
probably
at
time
aren't
we
I'll
just
say
that
that
I
think
that
there's
a
huge
benefit
to
having
to
having
both
Styles
in
in
your
pocket
and
and
collaborating
with
people
that
have
a
complimentary
Style.
A
All
right:
well
thanks
everyone
for
joining
and
I'll
kind
of
just
stop
us
there,
but
feel
free
to
add
some
notes
to
the
items
after
the
time
and
yeah
we'll
see
you
all
next
week
for
chapter
two
bye.