►
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
today
is
April
6th
2023
and
we're
discussing
chapter
eight,
which
is
good
influence
at
scale
and
so
I'll
give
a
quick
overview
of
what
the
chapter
was
about.
A
A
This
could
be
like
a
group
of
maintainers,
Frontline,
Engineers
or
a
group
of
people
involved
in
a
specific
incident
and
then
there's
the
Catalyst
level,
which
is
like
pretty
much
at
the
organization
or
system
level,
and
it
involves
things
like
setting
up
Frameworks
or
cultural
structures
that
let
you
or
that
let
your
influence
continue
even
after
you're
gone
and
the
author
describes
various
ways
to
extend
your
influence
at
those
different
levels,
and
the
first
way
is
that
advice
which
they
make
sure
to
point
out
that
make
sure
that
your
advice
is
welcome.
A
Asking
for
admission
is
always
a
good
idea
and
then,
in
terms
of
reaching
more
people-
or
you
know,
maybe
being
a
lot
less
personal
writing
and
speaking
in
larger
venues,
can
help
reach
larger
groups,
in
addition
to
advice,
there's
teaching,
so
that's
things
like
pairing,
shadowing
reviews,
coaching,
actually,
teaching
specific
classes
or
even
designing
classes
for
others,
and
one
of
the
unique
topics
in
this
chapter,
or
at
least
I
thought
it
was
a
little
more
unique
in
the
way
they
named.
A
It
was
guardrails
which
is
choosing
to
let
other
people
get
work
done
autonomously,
but
then
kind
of
being
there
to
step
in
and
protect
them
from.
You
know
running
into
any
dangerous
mistakes,
and
the
last
way
I
described
to
extend
your
influence
was
opportunity
and
that's
creating
opportunity
for
others
through
delegation
or
through
direct
sponsoring.
A
So
with
that
I'll
let
bri
take
it
away
with
the
first
Point
here.
B
Sure,
thank
you
so
yeah
the
scaling
advisor
group
talked
about
like
giving
a
talk
and
writing
an
article
and
I
think
those
are
great.
I
do
I'll
start
with
the
second
question
which
is
like:
do
you
all
have
less
boring,
Solutions
I
think
those
are
actually
really
good,
boring
Solutions,
but
this
is
a
space
where
it's
slightly
more
safe
to
have
a
not
boring
solution.
So
I'm
curious.
If
you
have
thoughts
on
less
wearing
solutions
that
still
achieve
that.
A
I
think
the
first
thing
that
comes
to
mind
for
me
is
I'll,
often
link
to
docs
that
I
might
have
written
so,
like
you
know,
if
I
noticed
something
at
some
point,
where
I
noticed
that
I
keep
repeating
something
at
some
point:
I'll
open
an
MR
and
add
it
to
the
docs
or
to
the
handbook
and
then,
as
it
continues
to
come
up,
I
just
keep
re-linking
it.
And
it's
surprising
how
many
times
it
might
be
something
that
I
added
myself,
which
maybe
it's
just
because
I'm
so
familiar
with
it.
A
But
then
the
same
thing
goes
with
with
the
rest
of
the
docs
as
well.
Just
kind
of
being
able
to
point
to
things
without
re-explaining
seems
like
a
good,
boring
solution.
C
C
Because
I
was
thinking
about
this
in
the
sense
that,
like
I,
think
just
any
writing
we're
talking
like
in
a
recorded
form,
I
guess,
is
or
like
to
a
group.
I
do
think,
like
writing,
and
recording
talks
in
any
form
is
a
good
way
to
scale
right,
so
that
people
like
anyone
can
discover
the
writing
or
talk
in
some
way.
C
I
actually
find
just
because
of
the
way
we
work
that
writing
tends
to
scale
better,
because
videos
tend
to
be
difficult
to
find
I,
don't
know
if
that's
partly
just
because
of
the
week
get
LAB,
Works
and
I
don't
know
there
may
be
better
systems
to
integrate,
searching
of
certain
repositories,
videos
and
all
that
other
stuff
right,
but
I,
think
in
in
general
I
think
either
of
those
would
be
good,
boring,
Solutions.
D
There's
another
thing
that
this
makes
me
think
of
is
like:
how
do
we
force
multiply
right?
How
do
we
get
our
advice
out
there
automatically
or
or
standards
or
or
whatever
you
want
to
think
about
it?
Where
I
sit
from
a
coding
standpoint,
I
kind
of
kind
of
I've
had
this
thing
where
I'm
like
well
I,
really
think
we
should
write
tests
in
this
certain
way
because
to
make
them
more
readable
and
things
like
that.
D
How
do
I
not
make
that
go
and
automatically
get
that
concept
get
changed
within
a
month
right
and
so,
when
I
think
of
it.
That
way,
I
think
like
how
do
I
publicize
this?
How
do
I
yeah
all
those
things
and
that's
the
boring
Solutions
you
have
there,
but
for
me,
easier
to
reach
was
linting
and
so
in
in
codes
like
it's
kind
of
like
automatically
putting
that
advice
out
there
in
probably
a
more
strong
way,
but
yeah.
D
C
C
And
I
think
it
kind
of
goes
to
the
part
actually
about
guard
rails
right
because,
like
the
point
adding
like
all
the
pipeline
checks
that
we
have,
whether
it's
for,
like
the
code
part
even
the
docs
part
of
kitlab
right,
we
have
a
lot
of.
We
have
co-quality
for
docs
in
our
pipelines,
so
I
think
all
of
these
tasks
and
pipeline
checks,
and
all
of
that
are
a
good
way
to
help
set
up
guard
rails
and
I.
Think
there's
there's
other
ways
to
do
that
in
some
ways.
C
Certainly
I've
done
it's
kind
of
maybe
somewhere
between
teaching
and
guardrail
right,
but
like
kind
of
being
like
a
shadow
on
an
MR
for
someone
and
their
support
to
just
like
follow
along
and
like
it's
depending
on
where
they
are
in
their
stage
of
learning.
I
might
not
be
there
to
actually
coach
them.
I
might
just
be
there
to
like
Shadow
an
MR
follow
along
and
make
sure
that
if
they,
if
I,
think
they're
going
in
the
wrong
direction
to
kind
of
just
nudge
them
back
on,
that's
my
course.
B
Correction,
something
that
that
makes
me
think
about
is
a
guard
rail
thing.
I
kept
thinking
about
also
roadblocks
and
I.
Think
a
lot
of
the
examples
we've
come
up
with
are
like
guard
rails
truly
and
not
roadblocks,
because,
like
a
guardrail
is
genuinely
helpful,
like
I
feel
like
lose
the
roadblocks
but
add
the
guardrails
and
the
the
jobs
and
pipelines
are
like
everything.
I'm
like
okay,
yeah,
a
human's
gonna
look
at
this,
but
a
robot
will
look
at
it.
First
and
I
can
get
some
feedback
and
the
autonomy
benefit
I
loved
yeah.
A
There's
also
the
ability
to
have
like
unintentional
influence
in
in
those
ways
so
like
one
of
the
ones
that
I
think
of
is
like
early
on
when
I
was
at
gitlab
I
was
you
know,
playing
around
with
some
of
the
features
that
were
part
of
my
group
and
I
discovered
this
weird
way
or
not
a
weird
way,
but
like
this
way
to
use
them
that
I
didn't
realize,
I
could
do
and
so
didn't
seem
like
Doc
or
handbook
worthy.
A
So
I
just
recorded
a
video
and
I
kind
of
like
shared
it
with
my
team
and
kind
of
left
it
at
that.
A
But
then
users
started
seeing
the
video
and
started
using
the
feature
in
that
way,
and
then
it
kind
of
like
I
mean
it
was
getting
like
over
10
000
views,
and
so
we
ended
up
like
saying,
like
that's
the
way,
you're
gonna,
that
we
are
gonna
promote
using
this
feature
from
now
on,
and
it
was
a
very
like
unintentional
kind
of
road
to
that
path
forward
on
how
we
use
the
feature-
and
it's
like
I,
often
think
of
like
I-
wonder
if
that's
how
we
would
have
wanted
it
to
happen.
A
We
had
gone
back,
but
it
was
kind
of
like
at
some
point.
There
were
like
there
was
too
much
like
there
are
just
like
too
many
people
being
vocal
about
like
this
is
what
we
want.
We
want
more
support
and
more
documentation
around
it
and
all
of
that,
so
it
was
that
only
happened
that
one
time,
though
so
I
don't
know
how
often
that
happens.
B
That's
a
beautiful
segue
into
the
other
question
I
had,
which
is
like
when
you
scale
your
advice
up
to
a
group
if
I'm
talking
to
someone
one-on-one
and
they
don't
get
it
I
can
kind
of
catch
that
if
I've
written
something
and
I've
put
it
out
into
the
universe.
Maybe
you
knew
what
I
meant,
because
you're
used
to
like
the
way
I
speak
and
phrase
things,
but
maybe
you
don't
you
completely
misunderstand
me
and
you're.
You
know
six
months
down
the
road,
it's
like!
B
C
C
So
if,
if
I
write
anything
convert,
docs
blog
posts
who
knows
whatever
right,
thankfully,
with
the
the
with
you
know,
gitlab
resources,
whether
again
it's
box
or
conduct
or
whatever
other
people
can
also
teach
it
right
like
it's
not
just
be,
but
even
on
a
like
on
a
personal
blog
post.
C
If
someone
points
it
out,
then
I
can
go
and
easily
update
it,
whereas
video
I
think
it's
obviously
more
difficult
to
update
and
but
it
is
obviously
possible,
I
think
I
think
we
can
give
ourselves
a
certain
amount
of
Grace
that,
like
you
know
within
context,
I
think
a
lot
of
people
will
understand
that
you
know
like
what
Steve
did
where
he
just
recorded
a
video
for
the
team
right
I
think
it's
usually
fairly
obvious
from
Context
and
the
the
way
that
it's
presented
that
there's
a
certain
amount
of
like
okay,
I
just
did
this
for
the
team,
it
you
know,
kind
of
thing
right
and
but
it
it's
definitely
interesting.
C
I
found
people
I've
had
people
message
me
about
things
that
I've
just
I've
just
edited
like
as
soon
as
they.
Let
me
know
so.
Yeah
I
haven't
thought
about
it
too.
Much
to
be
honest,
I'd
be
interested
with
Steve
and
that
might
have
to
say,
but
it's
it's
definitely
one
of
those
things
where
I
was
just
like
well
yeah.
That's
why
we're
ready.
D
I've
never
really
thought
of
that.
But
that's
a
good
point:
I,
don't
know
how
you
would
combat
it
other
than
getting
feedback
or
doing
what.
What
would
Arty
was
saying,
yeah.
A
A
Yeah
the
importance
of
paying
attention
to
the
channel
that
you
like
put
things
in,
like
you
know
like
where,
where
are
you
like
posting
this
like
article
or
talk
or
whatever
and
I?
Think
yeah
gitlab
unfiltered
is
a
very
you
know
anything
can
be
there,
so
it
shouldn't
be
expected
that
something
there
is
going
to
become.
D
D
I
think
that
more
resonates
with
me
about
when
I
put
something
out
there
and
I
think
it's
understood
and
then
I
have
maybe
a
pairing
session
with
a
group
we
talk
about
it
and
I
realized.
I.
Didn't
I,
didn't
explain
that
very
well
at
all.
You
know
and
and
finding
ways
to
do
that
and
being
proactive
about
that.
Maybe
a
good
thing
to
do
as
well.
D
Yeah
I
think
it's
harder
here.
I
know
when
I
started
at
gitlab
I
was
immediately.
Cognizant
of
I
would
be
talking
to
non-native
English
speakers
a
lot
more
and
and
not
talking
synchronously
like
this,
so
I
I
try
to
make
a
conscious
effort
to
speak
in
more
to
reduce
my
use,
use
of
of
slang.
D
B
I
think
about
that
a
lot
too
dog,
like
writing
to
people
on
tickets
and
it
when
you
look
with
that
eye
and
a
lot
of
the
idioms
we
use
it's
like
yeah.
What
does
that?
How
would
someone
know
what
that
means
and
it
I
sort
of
I
use
it
as
like
plain
English,
I
know
what
you're
saying
I
sort
of
think
it's
like
plain
English
and
it's
probably
like
an
actual
term
for
it.
I,
don't
know
what
it
is.
D
B
D
We
we
do
I
find
myself
thinking
of
things
all
the
time
like
like
that,
like
it's
natural
for
me
to
say,
oh
I'll,
give
that
I'll
take
a
stab
at
that
right.
But
but
that's
that's
violent,
but
that's
you
know,
but
it's
just
an
example
of,
like
that's
a
slang
term
right
like,
and
you
wouldn't
realize
that
unless
you're,
like
really
trying
to
think
about
it,.
A
A
I
do
have
one
point
that
I
had
noted,
and
it's
kind
of
like
this
realization
about
the
Catalyst
level
influence
and
so
I
think
like
at
gitlab
in
the
career
Matrix
like
we
talk
a
lot
about
expanding
your
scope
to
larger
groups,
which
is
kind
of
that
same
idea
of
like
individual
level,
group
level,
Catalyst
level
and
so
I've
often
kind
of
like
thought
about
it
of
like
how
do
you
actually
do
that
like
I'll,
have
an
idea
of
like
this
would
be
great
at
company-wide,
but
then
like?
What
like?
A
A
Think
one
of
the
things
I
realized
was
that,
like
influencing
at
that
level
kind
of
requires
a
lot
of
the
skills
that
were
covered
earlier
in
this
book,
like
being
able
to
lead
big
projects,
and
you
know
having
the
different
maps
to
navigate
your
organization
and
so
I
think,
like
I,
had
always
kind
of
thought
of
some
of
those
skills
as
being
separate,
like
you're
good,
at
leading
you're
good
at
influencing
you're
good
at
like
doing
big
projects,
but
I'm
realizing.
C
As
part
of
that
I'm
curious,
whether
either
you've
seen
or
done,
like
aside
from
like
you
know
the
example
in
the
book
like
if
you've
seen
or
done
anything
I
get
land
that
you
think
is
kind
of
at
the
catalyst
level
of
things
and
curious,
like
specifically
kind
of
in
engineering.
A
I
mean
the
the
ones
that
come
to
mind
were
things
that
kind
of
already
existed
when
I
started,
but
I
think
like
at
some
point,
you
know
like
a
lot
of
the
values
were
built
in
and
kind
of
became,
a
part
of
everyday
engineering
like
iteration
and
breaking
down
Mrs,
and
things
like
that
like
at
some
point,
someone
must
have
been
like
you
know.
A
We
need
to
start
doing
this,
so
it's
I,
guess
it's
before
my
time,
but
like
those
are
some
of
the
examples,
I
think
of
trying
to
think
of
something
more
recent
that
may
come
to
mind.
B
So
you
know
what's
really
coming
to
mind
for
me:
it's
I
don't
know
if
this
is
like
the
best
example
of
it,
but
the
request
for
help
issues
that
were
rolling
out
across
different
stages
like
that
is
something
that
reaches
a
whole
bunch
of
different
groups
within
gitlab.
It's
how
gitlab
support
gets
help
from
different
groups,
like
that's
a
thing
that
we
easily
could
have
said:
okay,
just
support
and
off
they're
gonna.
B
Do
this
thing,
but
it's
support
and,
like
everybody
and
I,
think
that
took
a
lot
of
it's
iterative
and
we're
doing
it
like
in
groups,
but
that
takes
a
lot
of
talking
to
people
across
the
company
to
like
get
that
done.
I,
don't
know
Doug
and
Steve.
How
much
you
you
see
those
but
like
to
me.
That's
a
thing
that
stands
out
in
this
category.
D
I'm
Googling,
what
you
just
said
or
I'm,
not
Googling
I'm,
going
to
Google
it
to
our
docs
or
whatever
to
see
like,
because
I
haven't
heard
of
it.
Where
I
haven't
remembered
it.
C
I
hate
to
say,
I
haven't
actually
used
it
because
I
always
just
go
to
filing
a
bug
issue
where
I'm.
Just
like
here's
a
bug
issue,
here's
everything
that
we've
done.
Can
you
like
I'll,
take
a
look
at
this.
B
I
find
them
useful
in
some
situations
where,
like
to
your
points
of
the,
if
the
right
thing
is
create
an
issue
create
an
issue
but
like
if
it's
like
I,
don't
know.
If
this
is
one
issue,
misconfig
18
issues
all
bundled
into
one
that
we
need
to
like
figure
out,
and
it
also,
if
there's
a
lot
of
like
stuff,
that's
specific
to
the
customer's
setup,
that's
highly
relevant
because
we
can't
reproduce.
It
then
I'll
do
this
because
then
I
can
add.
Other
information
I
wouldn't
go
like
in
the
issue.
D
D
D
D
I
see
the
dev
section
one,
but
then
you
still
have
to
figure
out
which
group
right.
C
Yeah,
certainly
not
all
those
sections
are
in
there,
I
think
for
support.
It's
just
been
a
really
good
way
to
encourage
and
make
sure
that,
like
we've
captured
things
in
an
issue
regardless
of
where
that
really
is
like
this.
This
kind
of
helps
push
support
to
put
it
in
a
specific
place.
C
So
that,
like
we're
not
always
like
asking
the
question
of
like
oh,
where
do
we
put
this
and
it's
a
place
where
we
can
put
issues
in
order
to
kind
of
just
even
discuss
like
Brisas,
just
to
even
discuss
when
it's
like?
It's
not
clearly
a
bug
or
like?
We
need
to
request
help,
and
we
just
need
a
form
like
some
way
to
kind
of
discuss
it
without
it
being
all
in
slack,
because,
as
we
all
know,
it's
very
it's
difficult
to
troubleshooting
spot.
A
Yeah
and
I
can
speak
from
like
the
Stage
Group
standpoint,
like
I
like
how
it
pulls
the
question
out
of
slack,
so
it
makes
a
little
bit
more
async
and
documented
because
a
lot
of
times
when,
when
someone
asks
something
in
slack,
it's
like
really
hard
to
know
like
how
urgent
it
is
or
how
high
of
a
priority
it
is
like
it
makes.
You
want
to
answer
right
away,
but.
C
A
That
moving
it
to
another
platform
like
help
create
more
like
guidance
around
it.
I
guess.
C
A
A
Thanks
everyone
for
joining
and
yeah
next
week
is
the
last
chapter
so
hope
to
see
you
all
there.