►
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
A
Welcome
to
this
week's
session
of
the
staff
Engineers
path
book
club
this
week,
we're
going
to
be
discussing
chapter
six,
which
is
why
have
we
stopped
and
it
kind
of
goes
over
a
variety
of
different
ways
that
people
get
blocked
on
big
projects
and
then
also
different
ways
that
people
might
get
lost
along
the
way
and
get
stuck
on
big
projects.
A
So
I'll
kick
it
off
with
the
first
question
here
and
first
item
to
discuss
and
so
I'm
just
kind
of
curious
in
general.
What
ways
have
you
seen?
Projects
or
people
get
blocked
at
gitlab,
and
and
how
have
you
seen,
staff
plus
folks
get
involved
with
resolving
those
problems.
C
B
See
this
happen
is
when,
like
the
answer
of
what
to
do
is
not
clear
like
if,
if
the
situation
is
like,
oh
yeah,
we
have
a
doc
for
that
done,
easy
when
it's
like
yeah,
but
there's
nothing
written
down.
Someone
has
to
figure
it
out,
like
the
theme
in
this
book
is,
if
you
use
that
word
someone
it's
you.
B
A
When
I've
seen
some
big
projects
stall
out,
it's
usually
I
think
one
of
the
biggest
reasons
I've
seen
is
like
kind
of
waiting
on
another
team,
which
was
one
of
the
the
main
reasons
brought
up
in
the
book
and
that's
always
due
to
like
misaligned
priorities
or
or
mis
understanding
and
and
yeah
I
see
the
the
staff
engineer,
eventually
just
kind
of
steps
up
and
and
starts
the
discussion
with
the
other
team
or
or
finds
out
what
needs
to
happen
in
order
for
for
each
person
to
move
forward.
D
I
almost
feel
like
it's
not
always
like
a
stock
plus
that
necessarily
solves
it,
because
obviously
there
are
times
when
you
have
to
involve
other
teams.
Sometimes
it's
access.
Sometimes
it's
like
just
even.
D
A
Yeah
definitely
yeah
and
I
think
that
the
bigger
the
project
like
it's
it's,
you
know
the
wider
spread.
Those
strings
are
that
that
need
to
get
pulled
together.
So
that's
that's.
Definitely
a
common
common
theme.
A
All
right
does
anyone
have
some
other
points
that
they
wanted
to
chat
about
or
bring
up
from
this
chapter,
if
not
I
can
play
add
one
or
two.
B
B
It's
less
scary
to
say:
oh
yeah,
I'm
gonna
bring
this
all
together
and
make
some
decisions
and
I
think
part
of
growing
into
into
that
staff
role
is
bias
for
Action
means,
like
anyone
can
be
the
person
that
sees
something
and
says
something
and
I
think
it's
important
to
just
make
it
not
be
a
oh.
You
have
to
have
this
kind
of
a
title
to
be
a
problem
solver
and
just
get
the
thing
done.
E
I
think
that's
that's
even
more
true
here
in
our
async
culture
too,
because
any
delay
will
mean
another
day
or
two
days
or
something
like
that,
whereas
like,
if
we
were,
you
know
in
an
office
together,
I
might
just
walk
over
to
you
and
talk
to
you
if
I
wasn't
getting
response
or
call
you
or
or
you
know,
all
those
things
and
that's
not
as
common
here
so
I
I
I,
do
think
it's
kind
of
like
sending
an
email
in
the
past
where
you
I
might
send
an
email
and
ask
everybody
their
opinion
and
send
it
to
like
an
email
group,
and
you
know
how
that
goes.
E
You
don't
get
a
response
at
half
the
time
right,
so
you
have
to
pinpoint
so,
and
so
it's
the
same
type
of
concept,
in
my
mind,
is
is
if
you
need
an
action,
and
especially
here
to
here
when
I
ask
someone
something
I'll
more.
C
E
Go
down
the
path
of
suggesting
something
and
say
I'm
going
this
route
and
ask
them
to
stop
me
instead
of
asking
and
waiting
for
that
feedback,
if
I
think
that's
the
path
to
go.
B
G
Yeah,
so
my
take
on
it
to
some
extent,
is
from
support,
where
We've
not
had
that
many
staff
support
Engineers.
It
is
obviously
present
with
us,
but
the
previous
or
the
other.
Two
staff
support
Engineers,
but
also
the
previous
two
I
think
one
more
particularly
on
self-managed
were
were
much
much
more
deeply.
G
Technical
and
I
was
trying
to
think
about
the
way
for
all
of
a
better
phrase
that
you
know
they
would
be
used
when
there's
a
difficult
customer
situation
going
on
and
actually
what
I
kind
of
ended
up
with
it
is
that
yeah,
if
you've
got
a
customer
with
a
kind
of
ongoing
Major,
Performance
issues
or
whatever
and
they've
got
big
Incident
Management
bridge
going
on
and
Senior
Management
involved.
G
If
you
assign
a
soft
support
engineer
to
that,
it
shows
a
level
of
commitment
by
gitlab
equivalent
to
what
the
customers
providing
you
know.
They've
got
Senior
Management
involved.
We've
got
senior
Engineers
involved
kind
of
the
book
touched
on
that
in
terms
of
the
way
staff
Engineers
map
to
people
managers.
But
it's
you
know
it's
a
different
angle
on
it.
G
And
actually,
in
that
respect,
it
wouldn't
even
it
wouldn't
matter
whether
or
not
that
staff
Engineers
able
to
actually
fix
the
problem
at
hand.
It's
just
about
yes,
something
different
politics
for
one
of
a
better
word.
H
I
will
say:
I
will
feel
like
I've
also
been
on
the
other,
like
I've,
been
the
one
blocking
a
project
before
not
this
reading.
This
chapter
specifically
reminded
me
of
a
time
at
a
previous
position
and
Company,
where
I
was
kind
of
made
aware
of
this
decision.
Record
RFC
design,
architectural
document
to
build
a
new
system
for
audit
logs
and
I
was
on
the
team
that
was
supporting,
Auto,
Vlogs
and
so
I
knew
that
we
had
insufficiently
staffed
and
staffed
our
existing.
You
know
service.
H
We
had
tons
of
feature
requests
that
we
hadn't
been
able
to
fill
from
customers
and
then
kind
of
somebody
from
outside
had
just
come
in
and
been
like.
But
what
have
we
built
a
whole
new
thing
and
it
had
all
of
the
features
and
it's
like
you
know
it's
going
to
be
amazing,
and
you
know
I
was
the
one
like
okay,
but
like
who's
gonna,
do
it
and
like?
H
Are
you
aware
that
we
already
have
this
system
that
we
haven't
properly
invested
in,
and
maybe
that's
why
people
are
unhappy
with
our
current
offering
and
like
I
guess,
I've
seen
kind
of
the
result
of
I?
Don't
know
what
it's
called
when
some
kind
of
just
plops
in
with
zero
context,
and
it's
like
here's
a
plan.
What,
if
you
all
just
did
this
and
you're
like?
Oh,
my
gosh,
like
I
I,
am
not
gonna
just
kind
of
adopt
this
plan
because
you
clearly
don't
have
all
the
context.
E
Yeah,
how
do
you
go
about
communicating
that
in
a
nicest
way
possible?
Let's
put
it
that
way,.
H
That
case,
my
memory
is
that
I,
just
I
mean
I,
definitely
attended
the
architecture
working
group
where
that
RFC
was
discussed
and
made
sure
that
the
point
was
made
that
we
actually
do
have
an
autolog
system.
It
just
you
know
it's
kind
of
sitting
here,
waiting
for
someone
to
pay
attention
to
it,
but
I
basically,
I
never
saw
that
project
go
anywhere
because
it
would
have
had
to
have
been
my
team
to
have
built
it
right.
It
would
have
been
me
to
have
started
building
it
and
I
mean
I.
H
Think
this
kind
of
goes
back
to
the
previous
chapters
on
planning
projects
where
it's
like,
if,
if
you
don't
have
the
proper
organizational
support
for
something
to
start
with,
it's
gonna
be
hard
to
just
like
convince
the
group
of
Engineers
to
work
on
it,
but
on
the
other,
on
the
other
hand,
it's
possible
that
I
as
an
IC
didn't
have
the
proper
context
like
maybe
there
was
like
a
very
valid
custom
reason
that
this
needed
to
happen.
H
E
I
I,
too,
have
felt
that
where
it's
not
like
really
a
a
I,
won't
call
it
a
they're
stepping
on
your
Turf
I,
wouldn't
call
it
that
or
or
but
it's
like
all
those
types
of
anxiety-inducing
things,
I
I
believe
when
you
initially
get
something
you
feel
like.
E
How
could
have
it
been
approached
to
you
in
a
way
where
you
might
have
accepted
it
easier
or
or
just
maybe
I
mean?
Is
there
something
there
where
the
person
could
have
approached
it
differently?
Maybe
had
a
one-on-one
I'm
just
using
it
Jesse,
because
you
brought
up
the
example
one-on-one
with
you,
or
is
it
something
that
you
need
to
change
about
yourself?
You
know
I
mean
how
you
take.
Take
these
things.
I,
don't
you
know
I
I'm
torn
on
these
things.
Sometimes.
D
I've
worked
in
a
lot
of
a
lot
of
organizations
where
you
certainly
have
to
I'd
say
seed.
The
idea
for
big
changes
before
actually
proposing
it
in
a
large
room,
I
feel
like.
We
don't
need
to
do
that
as
much
at
Get
on
where,
if
you
know,
someone
does
propose
a
big
thing
that.
D
We
can
I
think
it's
it's
kind
of
a
little
bit
of
both.
So,
like
you
want
to
understand,
you
want
to,
you,
know,
assume
positive
intent
and
that,
like
you
know
they,
they
may
have
a
reason
or
rationale.
Like
Jesse
said
maybe,
like
you
just
don't
have
all
the
contacts,
maybe
they
didn't
put
it
in
there
for
one
reason
or
another
and
then
so
I
find
that
the
most
useful
thing
is
just
to
ask
questions
right
like
to
just
ask
like
you
know
whether
things
like
whether
they
had
it
looked
at
the
existing
one.
D
A
Yeah
and
I
think
that
kind
of
goes
back
to
a
lot
of
what
was
described
in
the
last
chapter
about
like
leading
a
big
project.
There's
you
know
a
big
list
of
like
if
you
want
everyone
to
buy
into
this
project,
you
pretty
much
need
all
of
these
boxes
checked
and
there's
a
lot
of
them,
and
so
this
is
almost
kind
of
seeing
it
from
the
other
side
where
someone
comes
to
you.
A
Without
all
the
boxes
checked
and
like
what's
the
right
way
to
respond
and
I
think
that's
yeah
asking
questions
and-
and
you
know
assuming
positive
intent
and
all
of
that
is
definitely
like-
makes
the
most
sense.
E
Yeah
I
think
that
that
key
there
is
assuming
positive
intent.
I
think
we
all
have
history
unless
welcoming
cultures
of
companies,
where
that
isn't
always
the.
C
E
D
I
also
found
that
I
don't
know
if
it
always
helps,
but
maybe
people
who
work
with
reality
like
Bree
and
Ben,
can
can
tell
me
there
are
times
when
I've
created
an
issue
and
then
assigned
myself
because
I
know
that
I
have
the
ability
to
do
it,
but
because
of
competing
priorities,
things
might
not.
D
D
They
want
someone
to
support
them
in
making
the
change
that
I'm
happy
to
prepare
with
them
or
be
a
men
like
be
a
mentor
or
a
coach
or
whatever
it
is
in
getting
that
change
done.
So,
whether
that's
code
or
process
or
whatever.
Sometimes
the
process
ones,
are
even
more
complicated
that
the
code
right
so
regardless
of
what
the
change
is
and
what
the
issue
is.
D
So
I
try
to
be
very
explicit
about
some
things
in
some
cases,
there's
so
much
context
in
history.
Around
it
that
it's
very
difficult
for
someone
else
to
take
it
on,
but
so
I
try
to
be
very
explicit
on
like
here.
Here's
an
issue
that
anyone
could
take
on
and
I'd
be
happy
to
pair.
With
someone
other
times,
I
assign
to
myself
and
I
I
will
sometimes
say
like.
E
Or
things
like
that,
I
have
the
time
to
write
the
issue,
but
I
don't
have
the
time
I
don't
feel
I
have
the
time
or
the
desire
at
the
moment
to
write
out
all
the
domain
context
that
I
have
in
my
head
and
that's
I,
don't
know
if
that's
bad
and
I
don't
know
if
it's
good
it's
it's
just
what
it
is
sometimes
I.
Think
too.
A
I
mean
I
think
the
awareness
is
really
good,
like
the
fact
that
you're
aware
that
you
have
some
sort
of
knowledge
or
level
of
understanding
that
that
you
know
other
people
won't
just
get
when
you
tell
them,
I
think
that's
very
good
awareness,
so
that's
sort
of
like
the
first
like
aspect,
and
then
you
know
if
you
wanted
to
improve
upon
that,
you
can
kind
of
like
almost
retro
on
like
how
did
I
gain
all
this
domain.
A
E
B
I
think
about
this
topic,
a
lot
like
how
do
we
ate
and
maintain
that
domain
knowledge
like
as
we're
going
along
rather
than
waiting
and
needing
to
do
it
later?
Does
anyone
have
like
and
I
on
one
hand
the
issues
being
a
rabbit
hole
I'm
like
yeah,
that's
too
bad,
but
also
life
is
messy.
It
kind
of
is
it's
a
rabbit
hole
because
we
haven't
solved
the
problem.
Yet.
Does
anyone
have
like
good,
partial
Solutions.
E
Well,
I've
been
dog
fooding,
the
wiki
lately
I
know
we're
handbook
first
and
all
that
stuff,
but
sometimes
I
feel
like
some
things
are
just
I
need
to
throw
this
information
somewhere.
So
I
don't
forget
it
and
it
may
not
be
true
tomorrow,
but
it
may
be
true
and
I
need
to
reference
it
and,
and
so
I've
been
using
the
in
my
my
team.
E
There's
we
have
a
growth
group
in
in
git,
lab
itself
and
I
put
a
Wiki
there
and
I
just
started
dumping
things
like
I
mean
it's
silly
little
things
like
how
to
reproduce.
E
Locally
that
you
have
to
like
put
in
merge
requests
a
lot
to
get
it
reviewed.
It's
like
well
I
referenced
that
a
hundred
times,
I'm,
usually
searching
for
that
across
many
different
things
and
I'm
like
it,
doesn't
really
feel
like
a
handbook
item.
But
it's
something
I
want
on
the
tip
of
my
fingers
and
something
other
people
my
team
could
use
for
like
domain
knowledge
and
things
like
that
and
so
I'll
dump
that
in
in
the
wiki,
just
a
link
to
the
merge
request.
You
know
instructions
basically.
A
They
have
definitely
done
similar,
like
I,
had
a
repo
that
was
like
my
own
set
of
notes
and
then
I
found
myself
sharing
them
and
realized
like
that.
Shouldn't
be
my
project
that
should
be
my
groups
project,
so
I
ended
up
just
putting
them
in
the
docs.
A
So
there
are
like
a
handful
of
pages
of
just
my
personal
notes:
kind
of
hidden
developer,
docs,
which
it
is
tricky,
though,
because
with
that
those
types
of
notes,
they
can
get
outdated
very
quickly
and
and
or
get
neglected
very
quickly,
so
I'm
not
sure
of
another
solution
where
that
that
is
better,
like
I,
like
the
slight
informality
of
the
wiki,
but
it's
also
good
to
make
things
as
discoverable
as
possible.
D
I
think
it
kind
of
depends
on
what
the
knowledge
is,
so
to
speak,
that,
like
we're
trying
to
capture
I've,
actually
found
here's
a
better
place
to
put
this
or
like
what
not,
but
in
support.
We
have
a
training
project
and
we've
tried
to
put
together
trading
modules
to
get
support
team
members
kind
of
at
least
about
like
to
a
certain
level
of
knowledge
in
a
particular
topic,
and
in
there
we've
included
links
to
deep
dyes,
actually
not
just
from
within
support,
but
also
from
the
development
team.
D
Actually
really
love,
Jesse
and
Emery
did
a
lunch
and
learn
which
in
a
way,
was
kind
of
similar.
It
was
a
bit.
It
was
more
scope
to
a
very
specific
piece
of
what
authors
working
on
and
less
I
would
say
what
I
would
call
domain
knowledge,
but
it
was
very
similar
to
a
deep
dive
in
a
lot
of
ways
and
I
have
actually
found
a
lot
of
those
useful.
D
There
are
times
when
support
has
been
really
struggling
with
the
topic,
for
example,
and
we've
actually
asked
the
development
team
member
to
do
a
deep
dive
for
us,
which
of
course
we
would
then
record
and
just
put
on
unfiltered
from
our
training,
but
of
course
it.
This
was
open
to
anyone
at
gitlab
to
attend
and
watch
afterwards.
D
So
yeah
I,
don't
know
I
feel
like
Stan
used
to
do
office
hours
as
well,
where
he
would
dig
in
I
think
he
found
those
unscalable,
but
he's
kind
of
moved
to
doing
things
like
blog
posts
or
things
that
are
similar
to
that
and
I
again.
I
found
those
really
useful
I
think
it's
a
way.
It's
finding
a
way
to
share
the
knowledge
in
a
way
that
is
consumable
and
also
scalable
for
the
person
doing
it.
I,
don't
know
where
that
balance
exactly
is.
B
The
blog
posts
are
helpful,
they're
kind
of
nice
because
you
can
look
at
the
date
and
use
that
to
like
Steve's
point
about
like
things
to
get
neglected.
It
Was
Written
in
2021
use
that
context
in
your
brain
to
figure
out
how
much
of
this
you
consider
to
be
gospel
and
how
much
you
like
use
other
information
to
supplement.
A
All
right,
well,
I,
think
we
are
just
about
at
time
here.
So
if
nobody
has
any
other
points
they
want
to
discuss,
then
we
can
end
it
here,
but
thanks
everyone
for
joining
and
next
week
we're
moving
to
section
three,
which
is
all
about
leveling
up
and
helping
others
grow.
So
look
forward
to
getting
into
that
with
all
of
you.