►
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
And
today
we're
going
to
be
talking
about
chapter
one
and
the
forward
and
intro
of
the
staff
Engineers
path.
So
I'll
kick
it
off
with
the
first
item
here
so
in
the
intro
I
think
the
the
three
pillars
are
laid
out,
which
is
like
kind
of
going
to
be
what
the
discussion
of
the
entire
book
is,
and
so
there's
big
picture
thinking,
execution
of
projects
and
leveling
up
the
engineers
that
you
work
with
so
I'm
curious
I
mean
do
you
agree
with
this
list?
A
Do
you
see
some
things
that
are
not
on
this
list?
That
should
be,
and
just
what
do
you
think
in
general
of
those
ideas.
A
I
personally
thought
it
was
a
like
a
pretty
like
all-encompassing
list.
I
mean
it's.
It's
somewhat
generic,
but
specifically
like
at
git,
lab
I,
do
think
big
picture
thinking
and
execution
of
projects
are
kind
of
intertwined
with
how
staff
Engineers
seem
to
work
here
like
they
see
these
large
problems
and
find
Solutions
and
whether
or
not
they're
the
ones
that
are
actually
completing
them
is
not
necessarily
true,
but
they
might
be
the
ones
leading
the
project
and
delegating
the
work
to
other
engineers.
B
Yeah
I
think
I
could
see
like
leveling
up
Engineers
you
work
with
is
like
in
the
documentation
that
you
do
and
like
I
feel,
like
our
meetings
are
pretty
thoughtful
and
you
know
having
like
an
agenda
in
every
every
meeting
and
how
we
work.
Asynchronously,
like
I
I,
mainly
work
with
a
couple
people
like
in
Australia,
and
you
know
we
We
sync
up
you
know
later
in
the
afternoon,
but
we're
able
to
like
pass
along
information
and
kind
of
it
feels
like
almost
like
a
continuous
workflow,
where
you
know
they.
B
They
work
on
something
while
I'm
asleep,
you
know
asleep
or
after
hours
and
wake
up
in
the
morning,
go
to
work
and
like
there's
a
continuation
of
it
and
it
just
kind
of
it's
almost
like
a
feedback
loop,
which
is
really
nice.
C
I
see
I
see
the
leveling
up
theme
in
in
interactions
I've
had
with
Steve
who
he,
whatever
an
updates
to
take
it,
and
he
does
some
like
pretty
deep
investigation.
He
includes
not
always
but
a
lot
of
the
time
he
includes
what
he
like,
what
steps
use,
what
tools
you
use
to
do
his
investigation?
That's
a
lesson
for
me.
D
E
A
Awesome
cool
we'll
get
to
the
next
one
here
so
in
chapter
one,
there
were
some
notes
about
like
kind
of
looking
at
the
big
picture,
and
so
just
as
important
as
seeing
the
big
picture
of
the
situation
is
being
able
to
anticipate
how
your
decisions
will
play
out
in
the
future.
On
the
topic
of
big
picture
and
scope,
how
do
you
think
about
scope
beyond
your
project
or
your
group,
or
even
your
department?
A
And
so
how
often
are
you
considering
decisions
that
you
make
that
you
know
like
how
they're
going
to
play
out
over
a
year,
or
you
know
how
they
might
not
play
out?
As
you
see,
I
thought
that
was
kind
of
like
an
interesting
topic,
because
it's
one
that's
really
easy
to
not
think
about.
You
just
see
like
here's,
what
I'm
working
on
I'm
going
to
do
it
not
necessarily
here's
what
I'm
working
on?
A
What
does
this
mean
in
the
long
term?
So
I
know
we
have
like
some
staff
and
some
other,
like
various
level
folks
here
so
I'm
curious.
What
everyone
like
kind
of
like
does
to
think
about
these
things
in
their
roles.
F
F
F
I
think
that
I
aim
to
have
a
wider
View
and
I
would
like
to
have
a
wider
view,
but
the
reporting
structure
makes
it
such
that,
like
I,
feel
invested
in
the
team
and
what
the
team's
doing
and
that's
actually
changing
for
me,
I'm
going
to
be
reporting
up
to
the
next
level
soon,
so
I'll
be
interested
in
how
that
affects
kind
of
my
view,
I
think
the
hope
with
that
change
is
that
I
will
be
able
to
have
a
wider
view,
but
I
don't
know
how
the
common
that
is
at
gitlab
I,
don't
know
how
many
staff
Engineers
here
are
higher
in
the
reporting
structure
versus
kind
of
embedded
with
an
engineering
team.
G
Notice
that
of
like
staff,
tends
to
be
reporting
to
the
lion
managers
but
they're
at
least
in
infrastructure.
There's
also
the
distinguish
the
staff
plus
the
distinguished
engineers
and
and
I.
Think
it's
fellow
I,
don't
remember,
there's
another
one
about
that
and
they
do
report
at
that
higher
level
much
much
higher
and
that
looked
that
that
felt
like
it
matched
she
was
talking
about
and
the
the
author
was
talking
about
in
the
in
those
broader
perspectives.
G
I
to
answer
the
question
a
little
bit
too
I
thought
it
was
I
I.
Think
about
this,
a
lot
when
I'm
working
on
the
things
because
I
have
seen
through
my
career
now.
But
if
you
don't
think
about
those
things,
it
can
be
a
little
difficult,
I
mean
at
a
bigger
companies.
G
It
can
be
more
interesting
because
I've
worked
in
smaller
startups,
where
everything
you
do
can
have
a
very
large
impact,
although
even
when
you
do
not
intend
that,
but
at
a
company
the
size
of
git,
lab
or
I've
worked
at
Apple
II,
and
then
you
know
they
try
making
a
ripple
in
that
pond.
But
you
know
you
at
a
company
like
git
lab.
G
You
can
still
have
that
impact,
but
it
is
harder
to
immediately
see,
but
it's
still
a
very
good
thing
to
be
thinking
about,
because
you
know
future
I
I
like
to
think
about
the
future.
You
problems-
maybe
it's
not
actually
you,
but
but
it
it's
going
to
be
somebody
and
that
either
you
are
going
to
hate
what
you
did
before
or
or
or
somebody
else
is
going
to
hate.
You.
A
Yeah
I
think
it's
interesting
yeah
go
ahead.
Okay,
yeah
the
size
of
gitlab
I.
Think
it's
the
right
size
where,
like
you,
can
kind
of
stay
in
your
little
bubble
of
maybe
like
your
section,
I,
guess
and
and
be
very
focused
and
kind
of
like
that's
your
entire
world.
A
But
it
is
interesting
to
like
kind
of
step
out
sometimes
and
look
at
you
know
the
company
as
a
whole
because,
like
I,
think
I
was
on
the
package
stage
for
like
three
years
three
and
a
half
years
and
like
it
wasn't
until
I
started
to
see
like
the
use
of
the
package
Tools
in
in
respect
to
the
other
tools
that
I
started
to
understand
the
scope
of
the
impact
in
comparison
to
some
of
the
other
features,
and
that
that
kind
of
made
me
think
about
it
differently
and
how
to
like
Target
users
and
and
propose
features.
A
Because
of
just
like
understanding.
You
know
where
it
fits
in
that
sort
of
big
picture.
H
Yeah
so
we've
been
talking
quite
a
bit
about
sort
of
the
the
formal
structures
and
management
structures
in
particular
and
I
guess.
For
me,
a
big
part
is
also
the
the
more
informal
structures
and
relationships
and
kind
of
building
relationships
across
the
org
with
other
teams
is,
is
a
huge
part
of
just
understanding
the
understanding
of
broader
scope
and
understanding
what
other
people
are
working
on
and
identifying
themes
and
also
being
able
to
delegate
and
or
ask
questions
escalate
issues.
H
D
Yeah
I
think
that's
that's
kind
of
what
stable
counterparts
are
all
about
right,
that
you
can
form
these
connections
between
groups
that
are
not
necessarily
working
together
directly.
Otherwise,
at
least
for
me,
once
I
started
being
a
support
stable
counterpart
for
two
product
groups,
I
very
very
quickly
felt
that
these
connections
do
have
a
different
quality
and
give
me
a
picture
of
things.
D
I
would
not
get
otherwise,
and
that
is
super
valuable,
even
though
I'm
to
this
day
after
more
than
half
a
year
in
the
role
still
very
much
figuring
out
what
a
super
stable
carbohyde
actually
is
supposed
to
do,
but
still
from
the
very
beginning,
I
felt
okay.
This
is
this
is
big
and
and
good
and
important.
D
Well,
I
wish
I
could
give
you
a
definitive
answer.
It's
it's
something.
I've
been
thinking
about
a
lot
recently
and
I'm
still
trying
to
understand
the
the
general
idea
is
that
a
stable
counterpart
is
a
constant
person
that
you
can
speak
to
like
I'm
I'm,
the
support
step
counterpart
in
Pipeline
authoring
and
in
pipeline
execution.
So
everyone
in
these
groups,
when
they
want
to
talk
to
support
they
know
how
Manu
is
there.
They
can
talk
to
me.
D
First
I
can
figure
out
who
is
the
best
person
in
support
to
talk
about
this
things
like
that
it
just
it's
a
lower
barrier
right,
you
don't
have
to.
Oh
do
I
go
through
this
slack
Channel,
who
should
I.
Think,
let's
just
ask
Manu
I'm
I'm
already
here
and
similarly
like
the
product
manager
for
a
group,
is
in
itself,
of
course,
a
stable
counter,
but
it's
always
the
same
person
as
well.
A
Yeah
I
think
that's
a
really
good
point
that,
like
we,
have
these
counterparts
in
a
lot
of
areas
of
the
company
that
sort
of
create
these
relationships
automatically,
but
it
is
still
I
I
like
how
you
Gore
kind
of
went
through
it
like
it's.
It's
worth
pursuing
these
relationships
and-
and
you
know
getting
out
to
for
other
parts
of
the
company
which
that's
another
topic,
I
guess
in
it
of
itself-
is
how
do
you
go
about
doing
that?
A
C
F
Oh
I
was
gonna,
say
I
actually,
I
feel
like
I've,
like
kind
of
indirectly
gotten
this
feedback
from
like
I,
because
I.
This
is
my
first
time
working
in
an
asynchronous
organization
as
I'm
sure
it
is
for
many
of
us
and
I,
so
I
always
have
in
the
past,
have
really
relied
on
just
like
Hey
we're
all
on
slack
about
the
same
hours.
So
we
kind
of
just
like
chit
chat.
You.
F
You
build
relationships
that
way,
of
course,
also
through
regular
one-on-ones
and
now
on
my
team
because
of
time
zones
like
it
would
be
quite
difficult
to
do
regular,
one-on-ones
and
then
that's
true
also
for
people
across
the
organization.
So
I
I
think
in
my
first
six
months
here
have
been
a
little
bit
lazy
about
setting
those
up
and
have
just
been
like
doing,
work
and
doing
the
execution
pillar
really
hard,
but
definitely
like
want
to
focus
more
energy
on
the
build
relationships
aspect.
I
G
The
meeting
folks
in
in
various
slack
channels
and
things
around
various
interests
and
I
think
that's
a
good
way
to
connect
too.
So
it
does
still
exist,
but
it's
definitely
very
different
here.
You
know
I'm
in
all
caps
I'm
in
the
Emojis
Channel,
you
know,
there's
all
kinds
of
fun
places
to
to
goof
off
and
see.
Oh,
who
is
who
is
that?
What
do
they
do?
G
I
I
feel
with
like
the
remote
set
up
here
it
it's
harder,
it's
definitely
harder
and
it
requires
more
energy
and
in
previous
roles,
where
I
was
on
site,
you
know
it's,
it's
less
anxiety,
less
stress
to
just
meet
someone,
incidentally,
or
walk
by
them.
Now
it's
like
you,
have
to
make
an
effort,
and
so
I
don't
know
about
the
rest
of
you.
A
B
A
A
Minute,
there's
five
minute,
chats
that
you
have
like
in
the
hallway
are
super
hard
to
replicate
at
gitlab
like
schedule,
coffee
chats,
but
it's
kind
of
like
you're,
trying
to
commit
to
a
half
hour
of
chatting
with
someone
which
is
really
hard,
I
mean,
and
sometimes
they
only
they
don't
go
for
that
full
time,
which
is
fine,
but
it
is.
It
is
awkward
to
try
to
create
those
relationships
in
a
like
a
specific
way.
H
Yeah
I
was
gonna
segue
into
kind
of
time
management
and
being
intentional
about
how
much
time
you
spend
well
in
in
coffee,
chats
or
meetings
in
general
and
I
the
way
that
I
approach
it
is
I,
try
and
put
all
of
my
meetings
on
one
single
day
in
the
week,
which
can
be
a
lot
at
times,
but
it
sort
of
gives
me
a
quota
in
a
sense
and
I
can
look
at
my
calendar
and
say
well:
Wednesday
do
I
still
have
some
space
or
is
it
completely
empty?
H
Maybe
maybe
I
do
want
to
get
to
know
someone
and
say
I
can
sort
of
schedule
it
very
meticulously
and
intentionally
that
way
and
I'm
curious
to
hear
how
other
people
approach
that.
I
That's
an
interesting
concept:
I
think
that
maybe
raises
something
else
that
I
I
that
may
be
valid,
maybe
as
a
company
wide
concept,
we
can
further
encourage,
like
a
get
to
know
you
type
of
a
day
for
meetings
like
that
company-wide
and
that
might
encourage
others
to
more
proactively.
Do
it
too
I'm
not
sure.
A
Okay,
I
think
we
kind
of
covered
what
op-ed,
as
put
here
as
well
I,
don't
know
if
we
wanted
to
add
any
more
comments
about.
You
know
the
different
levels
and
how
the
reporting
works
at
gitlab.
E
I
just
wanted
to
add
on
that,
like
I.
Think
one
of
the
big
big
takeaways
for
me
from
this
is
Embrace.
Uncertainty
like
it's
gonna,
be
unclear.
That's
okay!
Do
it
don't
like
hide
away
from
it,
I
think
that
that
what
he
wrote
there's
one
example
of
the
uncertainty
that
comes
with
what
we're
all
talking
about.
E
I
Uncertainty
in
like
each
team
is
different
and
what
they
need
from
a
staff
engineer,
and
they
may
be
perfectly
tailored
to
who
you
are,
and
that
may
be
how
it
fits
too
and
and-
and
it
may
be,
that
you
bring
and
Define
that
role
more
specifically
as
well.
It
just
depends
on
this
on
the
situation
and
the
person.
H
I
I
feel
like
I
mean.
Maybe
this
depends
on
which
part
of
the
company
you're
in
and
other
factors
but
I
feel
like
a
gitlab
with
also
sort
of
the
the
manager
of
one
ideology
it
makes
it.
It
gives
you
a
lot
of
freedom
to
decide
how
you
want
to
structure
your
work,
and
it
gives
you
a
lot
of
opportunity
to
sort
of
broaden
the
scope
of
your
work.
H
If
you
want
to
and
I
guess,
one
idea
that
comes
to
mind
around
that
is
when
you're
looking
to
get
promoted
and
sort
of
be
like
get
to
the
next
level.
H
It'll
often
be
the
case
that
there
is
some
sort
of
expectation
that
you're
already
operating
to
some
extent
at
that
level
and
sort
of
that.
At
that
point,
the
promotion
becomes
a
formality,
more
or
less
right
and-
and
so
I
guess,
with
with
regards
to
reporting
structures
that
that
means
I,
wouldn't
see
that
as
limiting,
but
rather
a
boundary
that
you
can
push
on
and
say.
Well,
I'm,
not
reporting
to
so,
and
so.
But
I
do
I
am
interested
in
this
large
initiative
or
I.
A
I
agree
with
that
I
think
like
because
I
I've,
gotten
interested
in
things
outside
of
my
group
or
outside
of
my
area
and
or
I've,
been
interested
in
like
joining
in
some
meetings
that,
like
maybe
I,
wasn't
invited
to
or
I
wasn't
really
a
part
of,
and
my
experience
at
gilab
is
if
I
ask
it's
generally,
the
answer
is
sure.
If
you
have
time
and-
and
you
want
to
explore
this-
then
that's
totally
encouraged,
which
I
think
is
great.
A
All
right
Andy
did
you
want
to
go
over
your
comment.
G
Sure
I
one
small
preface
to
this
is
that
I
actually
put
this
in
the
wrong
group
before
and
there
were
more
stack
plus
people
in
that
group.
So
this
kind
of
weirdly
worded
but
I'm
gonna
ask
it
anyway,
because
I
think
it's
still
relevant,
which
is
that
I
I
was
struck
by
the
quote
that
technical
leadership
needs
to
be
part
of
the
job
description
of
the
person
doing
it.
It
isn't
a
distraction.
G
It
is
the
job
and
I'm
wondering
I'm
new
to
git
lab,
so
I'm
wondering
like
how
how
I've
seen
that
tension
at
other
companies
in
other
situations
for
senior
leaders,
you
know
have
to
balance
that
coding
and
the
balance
can
get
out
of
whack
I'm
I'm
curious
to
know
what
what
people
have
seen.
What
people?
G
Oh
and
I've,
got
a
meeting
tube,
but
so
yeah
I'm
just
curious
on
perspectives
on
on
on
how
that
balance
gets
struck
at
gitlab.
What
expectations
seem
to
be,
or
that
kind
of
thing.
I
Well,
I
can
speak
to
that
from
my
standpoint
of
where
I
sit,
I
don't,
but
it's
Unique
to
to
I
think
the
team
you
know
so
I'll
preface
it
with
that.
I
don't
have
any
reduction
in
the
coding
noticeably
between
my
previous
being
senior
and
staff,
but
there
is
because
it'll,
obviously
it
will
involve
more
trying
to
establish
guidelines
getting
buy-in
to
certain
Concepts
in
the
engineering
teammates
things
like
that
that'll
happen.
That
feels
like
it's
happening.
Naturally,
more
than
being
forced.
G
And
I'm
I'm,
actually
especially
wondering
about
kind
of
you
know,
is
there
space
given
to
the
non-coding
tasks.
You
know.
I
I
feel
like
it,
there
is,
but
it
goes
along
with
the
manager
of
one
concept
and
I've
always
been
bought
a
fairly
autonomously.
So
I
don't
look
for
someone
giving
me
space
I,
make
the
space
and
just
make
sure
the
product
managers
are
happy
with
the
workflow
and
then
I
do
with
my
time
as
I
I
I
see
fits
the
company.
A
That's
what
I've
seen
like
I
think
it
is
kind
of
team
dependent,
because
I've
seen
I've
seen
a
team
where
there's
only
two
engineers
and
one
is
a
staff.
So
the
thing
that's
needed
on
that
team
is
to
get
the
work
done,
and
so
that's
what
the
staff
does
and
then,
as
the
team
expands,
suddenly
their
time
gets
freed
up
to
work
on
other
things.
So
it's
a
it's
very
fluid
and
dependent
I.
Think
on
on
what
the
need
is
at
the
time.
H
Yeah
I
guess
my
experience
is
also
that
one
of
the
things
that
does
kind
of
come
with
the
territory
is,
as
you
establish
as
you
become
established
as
a
trusted
leader
or
just
trusted
person.
H
People
will
come
to
you
and
there's
I
get
pinged
on
so
many
random
things
every
week
and
it's
sort
of
part
of
the
job
to
to
triage
that
stuff
and
see
which
of
these
I
want
to
spend
an
hour
on
and
which
I
want
to
spend
two
minutes
on
and
which
I
can
ignore,
which
I
can
delegate
so
yeah
I.
Guess,
that's!
That's
sort
of
one
way
in
which
that
has
manifested
for
me
and
yeah.
A
All
right:
well,
we
are
right
at
the
end
of
gitlab
overtime
here,
so
I'm
gonna
have
to
cut
us
all
off,
but
I'm
really
glad
we
were
able
to
get
together,
and
this
is
a
great
discussion.
So
look
forward
to
everyone
joining
next
week
for
chapter
two.