►
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
welcome
to
the
staff
Engineers
path
book
club
today
we
are
talking
about
chapter
seven,
so
this
kind
of
jumps
into
part
two
of
the
book
and
we're
talking
about
leadership
roles,
kind
of
a
bit
more,
and
this
chapter
is
you're
a
role
model.
Now
sorry,
so
we
can
jump
in
I.
A
I
have
the
first
two
points
here
that
I
added
the
first
one
I
thought
this
was
a
nice
quote
that
true,
true
confidence
comes
from
having
done
the
work
for
long
enough,
that
you've
learned
to
trust
yourself,
and
there
was
quite
a
bit
at
the
beginning
of
this
chapter
about
just
making
sure
that
you've
gained
enough
technical
experience
before
jumping
into
the
staff
role
or
a
management
role,
or
any
sort
of
you
know
other
like
next
level.
A
Role
up
your
career
ladder
and
I
know
that
that's
something
that
I've
struggled
to
realize
at
various
points
in
my
career,
where
it's
kind
of
like
you
know,
I
I
get
the
promotion
and
then
it's
kind
of
like
all
right.
What's
next,
how
do
I
get
there?
Let's
just
you
know,
take
that
path
and
check
out
those
boxes.
A
But,
as
the
author
points
out
here,
sometimes
there's
there's
things
that
you
can't
just
hurry
through
and
there's
a
there's,
a
certain
types
of
experience
that
just
takes
time
so
I
thought
that
was
a
nice
Point
I,
don't
know
if
anyone
else
has
any
thoughts
or
anything
about
that.
B
I,
let's
say
that
prayer,
if
you
have
a
part
of
it,
is
struggling
with
imposter
syndrome,
though,
because,
like
we
say,
I
get.
One
of
that
get
loud
is
too
big
for
you
to
be
an
expert
in
everything
and
even
being.
B
Like
I,
don't
know
if
it's
a
little
easier
in
Dev,
where
you're
kind
of
scoped
to
a
specific
product
group.
So
in
theory
you
could
be
a
you
know
very
deep
expert
in
that
area,
but
I
can
tell
you
that
in
support,
for
example,.
B
B
B
In
some
ways,
a
little
different
than
I
guess,
like
I,
don't
necessarily
especially
at
gitlab
I,
don't
know
that
staff
loss
means
that
you
are
an
expert
in
every
area
that
your
responsibilities
cover
so
much
as
you're
working
at
a
certain
level,
which
means
you
have
the
technical
competencies
and
Leadership
competencies
that
we
talk
about.
A
Yeah,
that's
a
really
good
point.
I
mean
I
think
that
that
yeah,
that,
like.
A
Of
a
staff
engineer
shouldn't
be
tied
to
a
domain,
expertise
necessarily
and
and
I
think
that
makes
sense,
because
the
staff
engineer
should
be
able
to
to
switch
teams
and
still
be
a
staff
engineer
because
of
of
their
their
competence
in
in
the
other
areas
that
you
kind
of
talk
through
so
yeah.
There's
like
that
aspect
of
like
through
gaining
domain
expertise
and
and
gaining
technical
expertise
through
time.
A
But
it
is
interesting
that
you
talk
about
like
the
difference
between
like
stage
groups
and
support,
and
maybe
some
other
groups
where
there's
different
levels
of
technical
depth
or
domain
depth.
I
guess
and
I
do
agree
that
in
a
Stage
Group
you
can
become
an
expert
at
a
specific
domain,
but
I
think
it's
interesting
because,
like
when
I
when
I
was
in
the
Stage,
Group
I
felt
like
I,
had
a
pretty
good
level
of
expertise
in
in
the
domain.
A
I
was
in,
however,
I
lacked
I,
don't
know
what
the
right
word
would
be
here
for
is
like
I
lacked
user
expertise,
so,
like
I,
knew
in
depth
how
something
worked
and
how
to
optimize
it
and
build
new
features
on
it,
and
things
like
that,
but
in
terms
of
like
how
to
use
it
in
a
complex
way,
that's
where
I
would
have
to
reach
out
to
support
because
they
would
see
how
customers
are
are
actually
implementing
this
or
they
would
work
through
the
difficult
situations
that
customers
are
dealing
with.
A
C
This
is
more
of
a
problem
in
small
companies,
I'm
speaking
from
an
experience
here,
where
people
will,
with
one
or
two
or
three
years,
experience
gets
promoted
to
a
manager
and
the
way
to
sum
it
up
is
that
you
can't
lead
other
people
if
you
haven't
seen
enough
disasters,
so
that's
basically
it
and
then
it's
it's
more
that
it's
more
for
your
own
career
trajectory,
because
if
you
become
a
leader
too
soon
then
effectively
you
get
pigeon
hold
into
being
just
a
leader
type
position
in
it's
really
hard
to
get
back.
B
So
I
know
it's
not
like
super
common
I
feel
like
at
gitlab.
We
do
a
generally
good
job
of
allowing
people
to
move
from
like
one
role
to
another
and
I've
never
heard
of
anyone
doing
this.
B
B
And
I
also
know
that,
like
it's
like
I
said
it's
not
very
common,
it's
not
like.
It
happens
all
the
time,
but
I
have
seen
quite
a
few
people
who
have
moved
laterally
between
manager
and
staff
in
both
directions,
usually
manager
like
a
leadership
role
to
an
IC
role,
actually
more
often
than
I,
see
to
manager
but
I.
Think
like
we
do.
B
We
generally
do
a
good
job
of
letting
providing
that
freedom
to
do
that,
which
is
nice,
because
I
definitely
agree
that
it's
sometimes
you're,
promoted,
Into,
Your
Role,
just
because
of
how
long
you've
been
somewhere
and
that
sort
of
thing
and
yeah
I,
like
different
people,
are,
are
going
to
take
a
different
amount
of
time
to
learn
the
competencies
that
you
need
to
move
out.
The
level.
A
Yeah,
it
actually
reminds
me
of
I
had
a
friend
that,
like
he
worked
at
this,
the
small
startup-
and
he
was
you
know
he
was
the
best
engineer
there
and
there
were
just
a
dozen
or
so
people,
and
so
they
named
him
the
principal
engineer.
A
But
he
only
really
had
you
know
a
few
years
of
development
experience
and
it
only
worked
at
the
small
startup
and
maybe
one
or
two
other
small
companies
and
what
he
ran
into
was
when
he
was
trying
to.
You
know,
look
for
a
new
job.
He
kept
getting
these
interviews
for
principal
engineering
jobs,
which
is
pretty
nice,
but
realized
quickly
that
you
know
like
just
because
he
was
the
most
experienced
person
at
this
company.
A
That
company
was
doing
different
things
than
like,
say
like
the
Googles
or,
or
you
know,
apples
of
the
world
and
and
as
Tom
was
kind
of
saying,
is
that
you
know
at
some
point.
You
need
to
have
seen
enough
in
order
to
to
kind
of
like
reach
that
level
and
I
think
it
was
pointed
out
earlier
in
the
book
that,
but
there
are
a
lot
of
companies
that
that,
like
staff,
Plus
rules
aren't
really
warranted
because
of
that
type
of
leadership
isn't
necessary
at
the
scale
that
the
company
is
at.
A
So
it
is
interesting
how
how
like
titles
can
can
play
such
a
big
part
in
your
trajectory
or
or
your
path.
D
You
know
software
development
and
web
development
professionally
for
over
30
years
between
30
and
35
years,
depending
on
how
you
count
it
and
the
some
of
the
places
I
worked
at
you
know
even
most
recently
like
didn't,
didn't,
have
titles
or
didn't
necessarily
have
those
roles,
and
also
because,
like
the
last
20
years,
I've
worked
fully
remote.
D
I
didn't
necessarily
have
the
opportunities
for
doing
that.
Responsibility,
which
is
one
of
the
reasons
I
chose
gitlab,
is
intentionally
as
an
all
remote
place
like
that.
Those
political
opportunities
you
know
and
or
the
lack
thereof
and
bias
against
remote
employees
in
a
hybrid
environment
don't
exist,
but
you
know
I've
been
here
over
three
years
and
I've
had
the
attitude
that
you
know,
I
don't
want
to
be
a
staff
like
I
like
the
code,
and
you
know
everything
in
this
book.
D
Like
you
know,
I,
like
the
technical
part
and
I,
have
a
lot
of
experience.
I've
seen
lots
of
disasters
in
30
years
in
many
different
ways
and
places
and
part
of
me,
is
like
I.
Don't
really
want
that
responsibility
in
some
ways,
because
it
it's
not
only
more
difficult,
but
it
means
I'll.
You
know,
I'll
have
less
hands
on
the
code.
I'll
have
to.
D
You
know,
do
more
of
the
difficult
things
that
you
see
in
this
book,
but
you
know
more
recently
and
especially
seeing
what
it
looks
like
in
gitlab
I've
come
to
the
realization.
Well,
I'm
doing
this
stuff.
Anyway,
you
know
I'm
having
cross-organizational
impact.
You
know,
just
by
de
facto,
the
current
group
doesn't
have
any
staff
Engineers
on
it,
remote
development,
but
where
it's
a
very
complex
and
important
feature-
and
you
have
to
step
up
anyway,
so
part
of
me
is
like
well
I
might
as
well
get
paid
for
it.
D
If
I'm,
you
know
doing
a
lot
of
that
work
anyway,
even
if
I
don't
want
to
necessarily
do
it
all
and
like
it's
okay,
like
it
says
in
here,
you
don't
have
to
be
good
at
all
of
these
things
or
necessarily
want
to
do
them
all.
Nobody
is
is
going
to
be
the
perfect
canonical
staff
engineer,
but
you
step
up
when
you
have
to.
A
Yeah
I
think
there's
yeah.
The
idea
of
like
I've
talked
with
a
few
people
about,
like
you,
know,
like
sort
of
like
staying
like
like
how
senior
can
be
the
career
level.
If
you
want
it
to
be,
and
that's
it's
really
interesting
to
hear
what
that
looks
like
you
know
as
you've
shared
this,
because
at
some
point
you,
you
kind
of
end
up
doing
a
lot
of
the
things,
even
if
you
didn't
necessarily
mean
to
purely
because
you
become
the
person
that
has
the
ability.
A
D
Yeah
and
like
a
lot
of
that,
is
just
the
the
political
aspects
it's
like
yes,
I
know
what
that
is,
and
I
know
it
needs
to
be
done
and
I
know
how
to
do
it,
even
if
I'm
not
necessarily
good
at
it.
It's
just
like
that's,
not
a
pleasant
thing
really
for
anybody.
Unless
you're
the
type
of
one
it
enjoys
being
a
born
politician,
which
I'm
definitely
not
I'm
a
crafts
person.
D
C
That
that
you
should
be
taking
on
the
glue
work
because,
like
for
For,
Better
or
Worse,
as
the
chapter
does
say
like
if
someone
really
Junior
takes
on
the
glue
work,
is
a
detriment
to
them,
learning
actual
the
work
that
they
are
kind
of
describe
to
do.
Indeed,
I
don't
get
rid
of
water
for
it.
So
that's
part
of
the
responsibility
of
you
know
becoming
the
start
classes
taking
on
those
deliberately
and.
A
All
right,
I
can
move
on
to
the
max
point,
though,
so
this
was
one
of
the
themes
that
stood
out
in
this
chapter.
To
me
that
I
I,
really
love,
is
I
really
liked.
The
name
of
this,
specifically,
is
radiating
intent,
the
idea
of
signaling,
what
you're
about
to
do
before
you
do
it
and
it
was
kind
of
like
I,
think
they
paralleled
it
with
ask
forgiveness
not
for
permission.
B
A
I
really
just
love
the
like
the
name,
radiating
intent
and
there's
another
book
that,
if
you
haven't
heard
about
called
turn
the
ship
around,
it's
kind
of
a
leadership,
slash
management
book
and
that's
kind
of
just
the
core
idea
of
the
entire
book
of
like
leading
people
by
just
kind
of
saying
what
you're
doing
rather
than
like
asking
like,
should
I
do
this
and
it
it
really
works.
A
Well,
with
our
transparency
value,
I
get
loud
and
working
remotely
because
oftentimes,
you
don't
know
like
who's
who's,
looking
at
slack
or
who's,
not
so
like
in
my
mind,
it's
it's
most
helpful
to
just
kind
of
like
say
what
you're
doing,
even
if
no
one
ever
looks
at
it,
it
could
be
beneficial
and
it
can
be
beneficial
on
many
different
levels
like
you
know,
like
people
that
are
less
experienced
or
are
learning
what
you're
doing,
and
why?
Because
you're
kind
of
thinking
out
loud
and
then
manager,
type
people
or
people
that
are.
C
A
C
So
yeah
it's
a
it's
a
really
awesome
book.
If
you're
looking
for
a
leadership
kind
of
lessons
or
stories,
yeah
definitely
agree
with
that.
I'll
note:
I'll
also
spoil
the
story
a
little
bit.
It
only
works
well
if
it
comes
top
down
I
believe
so.
C
If
you're
trying
like
to
change
the
culture,
it
Bottoms
Up,
trying
to
kind
of
read
it
and
then
and
kind
of
like
influence
everyone
to
to
do
the
same,
it
doesn't
work
as
well
and
you
might
actually
backfire
to
try
to
do
that
in
a
quite
hierarchical
structure.
C
Culture,
because
I
believe
the
the
author
was
saying
that
in
other
ships,
where
the
captain
didn't
kind
of
delegate
that
kind
of
authority
to
everyone
it
didn't
work
at
all,
especially
the
so-called
like
the
middle
ranks
or
the
mineral
management,
was
trying
to
change
that
from
from
the
bottoms
up
and
yeah,
it
doesn't
work
yeah.
So.
D
D
Important
that,
like
you,
know,
we're
handbook
first
there's
but
there's
a
lot
of
stuff
in
the
handbook
and
the
larger
we
grow,
the
more
and
more,
by
definition,
some
of
those
things
don't
apply
to
every
group
so
like,
for
example,
our
our
group,
at
least
like
we're
following
a
much
more
lightweight
agile.
D
You
know
traditional
interesting
programming
or
scrum
style
approach
to
project
management,
at
least
the
build
phase
and
like
it
doesn't
look
very
much
at
all
like
what
is
in
you
know
the
secret
lab
project
management
process
for
for
that,
but
like
because
of
the
nature
of
the
team
because
of
the
nature
of
our
PM,
the
nature
of
the
engineers
on
the
team
and
the
work,
we're
doing
you
know
it,
it
can
work
for
us.
So
it's
you
know.
D
D
I'm
also
a
big
you
know
personal
experience,
metaphor
person
like
the
author
of
the
book
and
then
when
I've
like
when
I've
taught
classes
or
you
know
like
I,
did
you
know
cloud
Cloud
native
training
to
like
senior
architect
types
and
the
feedback
I
got?
Was
this
the
experience
that
and
and
type
of
instruction
that
people
at
that
level
find
the
most
helpful
in
junior
Engineers
too,
when
I've
you
know
taught
or
mentored
them?
D
They
want
to
hear
the
real
stories
about
the
ugliness
things
that
went
horribly
wrong,
Mis
mismanaged
stuff,
it's
failures
because
that's
you
know
everybody
learns
from
their
own
mistakes,
but
if
you
can
have
that
rare
opportunity
to
learn
from
somebody
else's
mistake,
it's
good.
B
D
Yeah,
like
that
was
definitely
the
favorite
part
of
my
favorite
part
of
the
the
chapter,
because
it's
it's
something
I
really
intentionally
try
to
do
and
double
down
on
just
be
extreme
about
the
humility
of
what
I
don't
know
the
amount
of
things
I
don't
know
are
vast
and
infinite,
and
even
the
things
that
I
think
that
I
know
a
little
bit
about
there's
so
many
people
who
know
so
much
more
about
it
than
me
and
like
that's
critically
important
for
culture
and
like
they
said
for
junior
Engineers,
to
understand
it's
like
I've,
been
doing
this
30
years
and
there's
lots
of
things
I
know.
D
B
D
I
do
even,
though
I've
been
doing
web
development
since
the
web
came
out
like
rails
since
rails
came
out.
Maybe
that's
just
me,
but
like
I,
try
to
intentionally
model
that,
because
you
know
it's,
it's
part
of
me
like
an
ally,
that's
being
I'm
in
a
space
of
safety
because,
like
I'm
assumed
to
have
that
experience,
but
so
even
I
don't
know
this
even
I.
Don't
really
know
anything,
we're
all
we're
all
in
this
boat
together.
D
C
D
D
The
attack
on
paraprogrammed
like
full-time
for
years
on
end,
so
I'm,
really
good
at
verbalizing,
while
I'm
completely
confused
and
clueless
like
Ashley
I,
got
some
feedback
just
today
on
mats
and
somebody
repair
program
made
their
life
you're
really
good
at
parent
program.
I
was
like.
Why
don't
you
say
that
they're
like
because
you
talk
while
you're
coding
and
it's
a
special
skill
to
continue
describing
your
thought
processes
when
you're
completely
clueless
about
what
you're
doing
so
I'm
good
at
that
I?
Don't
know
if
that's
an
answer,
but
it's
it's
a
skill.
D
B
Yeah
I
think
I
should
wrap
this
up,
but
just
very
quickly,
I
think
one
of
the
big
things
we
often
talk
about
is
that,
because
you
can't
be
an
expert
in
everything,
it
is
more
about
making
use
of
your
existing
skills
to
figure
out
like
what
is
a
next
step
right,
whether
that
be
looking
online,
whether
that
be
knowing
where
internally
to
ask
or
where,
in
the
code
base
to
look
for
something
you
know
where
to
start
in
the
docks
like
it's
just
I
one
of
the
things
we
try
to
do,
we
in
support,
we
have
a
daily
help
session
and
the
focus
is
not
necessarily
to
dig
in
because
it
can
take
a
really
long
time
to
do
that,
but
to
just
to
help
people
like
figure
out.
B
B
Where
do
you
go
next
and
I
think
that
is
a
lot
of
what
I
think,
senior
and
even
like
even
senior
plus
right,
but
especially
stock
plus,
is
kind
of
that
I
think
that
goes
kind
of
back
to
like
the
idea
between
domain
expertise
and
just
technical
competency
right,
like
you're,
expected
at
the
stop
level
to
have
the
technical
competency
to
know
to
have
ideas
and
and
figure
out
where
to
go
next,
even
if
you
are
completely
lost.
D
But
I
think
that's
why
to
me
is
so
valuable
when
I,
when
I
Mentor,
really
just
people
that
are
learning
to
program,
because
it
forces
me
like
when
what
was
the
thought
process
I
went
to
to
decide
what
I
do
next,
like
I,
it's
subconscious
for
me,
but
being
forced
to
verbalize.
That
makes
me
think
about
it,
and
it
also
makes
me
think
about
my
own
biases
and
when
I,
when
I
get
it
wrong
to
be
able
to
reflect
on.
A
All
right:
well,
we
are
right
about
that
time
here
or
I,
guess
overtime,
so
I'll
go
ahead
and
cut
it
off,
but
I
appreciate
everyone
joining
in.
This
is
great,
so
look
forward
to
chatting
with
you
all
next
week.