►
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
Well,
thanks
everyone
for
joining
another
week
of
the
staff
Engineers
path
book
club
this
week
was
an
interesting
read
regarding
creating
that
big
picture
that
they've
been
talking
about
so
far
and
I
added
something
just
to
start
off
the
conversation
that
what
I
quite
liked
about
this
chapter
was.
It
was
all
about
writing
and
that's
so
much
of
what
we
do
at
gitlab,
because
the
the
value
of
transparency
encourages
us
to
actually
practice
the
writing.
And
what
I
appreciated
about
this
chapter
was.
B
I
was
more
looking
at
blueprints
simply
because
that's
what
I'm,
mostly
familiar
with
but
kind
of
made
me
think
about
the
engineering
strategy,
because
they
did
mention
the
engineering
strategy
as
well.
I
did
a
did,
link
to
some
resources
around
engineering
strategy
that
got
me
really
interested
about
how
you
build
a
strategy
and
like.
C
B
It's
on
a
micro
level,
on
a
team
level
or
on
an
organization
level,
so
I
I
do
agree
with
gitlab's
transparency
and,
like
writing
things
down.
It's
really
useful,
but
I
don't
see
it
on
a
macro
level.
For
example:
I
don't
know
this
feature
and
gitlab
how
we
envision
it's
working
in
the
future.
We
can
have
epics
and
backlogs,
but
sometimes
I
find
the
backlog
for
something
really
hard
to
grok
and
go
through
and
shift
through.
So
I
I.
B
Like
the
mission
statements,
I
mean
it's
product,
but
sometimes
I
still
find
it
hard
like.
Oh,
what
was
the
idea
behind
this
piece
of
block
of
code,
for
example
like
where
we're
envisioning
an
iteration
in
the
future,
and
we
never
got
to
it
or
was
this
just
never
thought
to
kind
of
thing,
and
sometimes
the
people
are
not
there
anymore
to
answer
the
question
or
they're
not
in
a
different
department.
So
it
happens
a
lot
at
gitlab
but
also
feel
like.
B
A
Yeah
and
I
think
what's
really
helpful,
sometimes
is
like
there
are
some
cases
where
you
go
through
it
and
you
can
link
it
back
to
the
merge
request
where
that
was
added
and
you
can
see
well.
This
was
the
intention
behind
some
of
this
adding
and
hopefully,
there's
often
there's
links
out
to
the
issues
as
well.
A
But
what
I
find
sometimes
is
that
that
higher
level
of
why
we're
going
to
do
something
is
sometimes
missing
at
the
Epic
Level
and
it's
it's
really
easy
to
communicate
with
people
about
why
projects
are
important
when
all
of
that
information
is
there
at
the
epic
level,
but
sometimes
it's
such
a
desire
to
get
on
with
the
problem
and
get
on
with
fixing
things.
And
surely
people
must
understand
why
this
is
important
and
then
people,
just
you,
know,
Blaze
off
into
actually
getting
things
committed
and
done
and
it
actually
it
feels
like.
A
B
And
yeah
writing.
The
intention
is
hard
as
well,
because
the
intention
for
engineering
and
the
intention
for
product
and
the
intention
for
business
are
completely
different
intentions.
Right,
for
example,
let's
pick
sidekick,
one
of
them
is
like,
oh
from
a
from
a
technical
point
of
view,
it's
because
of
a
scalability,
but
what?
What
does
sidekick
mean
from
a
business
point
of
view
right
and
that's
a
lot
harder
to
calculate?
B
A
Yeah
that
does
make
sense.
It's
like
you
again,
it's
it's
talking
to
the
audience
as
well
and
trying
to
pitch
what
you
want
to
do
or
what
has
been
done
from
from
all
of
those
different
levels,
and
that's
quite
that
takes
quite
a
lot
of
practice
as
well
to
be
able
to
tailor
your
message
to
each
and
it's
very
difficult
to
then
capture
that
in
the
epics
too,
to
be
able
to
say
you
know
as
a
product
manager.
A
You
should
care
about
this
because,
and
you
know
it
can
get
quite
long-winded
if
you're
going
to
suddenly
list
out
every
Persona
that
that
you
feel
is
going
to
be
impacted
by
the
project.
A
Yeah
I
think
what
I,
what
I
also
find
interesting
with
the
chapter
is
they
were
talking
about
blueprints
like
they
were
talking
about,
creating
this
large
documents
and
then
working
with
people
to
get
buy-in
and
and
acceptance
of
that
and
I
feel
like
here.
A
There's
different
levels
of
that
buy-in
like
we,
don't
always
jump
to
a
technical
blueprint,
because
it's
not
always
necessary
and
I
appreciated
that
they
actually
said
that
in
the
book
like
do
what's
necessary
for
your
organization
and
I
feel
like
a
lot
of
the
writing.
That
we
do
is,
is
it's
in
an
epic
sorry,
it's
in
an
issue
or
a
discussion
issue,
and
then
that
will
get
condensed
down
and
created
into
an
epic
and
the
point
at
which
it's
an
epic.
It's
a
project.
We
have
the
buy-in
and
we
proceed
with
that.
A
A
B
I
think
one
problem
we
have
right
now
is:
maybe
there's
not
a
clear
distinction,
one
that
needs
to
be
an
epic
and
when
it
needs
to
be
a
blueprint
either
my
current
mental
model,
if
it's
like
a
year,
long
or
multi-year
project
with
multiple
teams
that
needs
to
be
a
blueprint.
But
if
it's
like
two
three
quarters
it
might
not
be,
but
what
I
struggle
at
is
like.
Okay,
the
Epic
is
for
two
or
three
quarters
right,
but
then
you
can
iterate
more
on
top
of
it.
B
So
do
you
write
the
blueprint
with
a
haze,
Division
and
then
like
have
like
this
short
term
in
an
epic
or
like
that's
one
thing:
I
was
hoping
they
touch
a
bit
upon,
but
like
the
haziness
of
a
a
vision,
sometimes
like
you
can't
really
know,
what's
ahead
in
three
years
time
right
so.
A
Yeah
and
equally
so
it's
quite
difficult
when
we
have
this
value
of
iteration
too,
because
the
a
technical
blueprint
feels
like
it's
the
end
goal
like
you've
already
iterated
to
the
end
and
you're
done.
But
often
we
just
do
the
next
thing.
That's
in
front
of
us
and
like
we
iterate
that
far
great
and
then
we
iterate
that
we
do
the
next
piece
and
I
felt
like
there
was
some
kind
of
conflict
there
between
having
this
longer
term,
large
technical
vision
and
just
sort
of
iterating
towards
it.
A
And
how
do
others
find
it?
Have
you
been
exposed
to
to
blueprints
or
do
most
people
find
that
they're
doing
their
writing
in
in
epics
and
issues.
D
So
far,
I'm
mostly
working
in
issues
but
I'm
in
support,
so
not
so
much
dealing
with
technical,
Blueprints
and
and
stuff.
D
What
I
found
interesting
in
this
chapter
was
maybe
more
the
I
guess
politics
involved
in
in
getting
support,
finding
a
sponsor
and
and
the
importance
of
all
that,
in
my
experience,
that's
something
that
a
lot
of
technical
people
don't
really
enjoy
very
much
and
then
get
into
it
with
kind
of
this
well.
But
my
idea
makes
sense,
and
it's
the
right
thing
to
do.
D
A
Perhaps
that's
also
one
of
the
differences
then
with
like
why
this
is
being
put
into
the
staff
engineer
book
is
because,
at
the
levels
before
staff,
you
would
be
contributing
to
these
types
of
documents,
but
you're
not
actually
responsible
for
selling
it
like
getting
the
the
buy-in
from
people
and
I.
Guess
that's
what
changes
when
you
become
a
staff
engineer?
Is
you
now
have
to
take
on
that
action
to
go
and
get
the
buy-in
and
I
suppose
that
takes
a
lot
of
practice
as
well
and
yeah?
C
Yeah,
it's
a
whole
new
set
of
skills.
I
thought
it
was.
It
was
good
that
daring
that
that
it
was
kind
of
all
the
steps
were
really
clearly
laid
out,
and
then
there
was
a
case
study
because
I
do
agree
with
Manuel
that
the
the
very
like
any
sort
of
change
within
an
organization
requires.
C
You
know
it's
political
and
there's
nothing
wrong
with
it.
Being
that
way,
like
I,
think
it
sort
of
makes
sense
that
it
is
that
way
and
I
think
developers
can
often
sort
of
have
negative
feelings
towards
what
we
call
politics,
but
you
know
they're
just
a
reality
and
learning
learning
how
to
sort
of
navigate
them,
because
every
company
is
different
as
well
is
not
a
bad
thing.
C
You
know,
I
mean
there's
politics
everywhere:
power
underlies
everything
like
every
relationship
we
have
yeah
and
it's
just
you
know
if
you
think
of
it
as
energy
rather
than
power,
I
guess,
because
power
has
such
a
bad
connotation
that
that
maybe
that's
an
easier
way
to
engage
with
it.
A
Another
way
of
engaging
with
it
is
to
think
about
it
in
terms
of
goals
as
well,
like
people
support
or
reject
an
idea
based
on
what
they're
trying
to
achieve
in
their
Department,
like
they
have
their
specific
goals
that
they're
trying
to
that
they
are
measured
against
or
they
that
that
they
have
to
report
on
and
when
they're
approached
with
an
idea.
They
have
to
think
well.
Does
this
align
with
what
I'm
trying
to
do
or
not,
and
you
it's
up
to
you
to
then
convince
them?
A
Well,
it
aligns
in
this
way
or
or
it
doesn't,
and
that
does
then
become
the
word
politicking
or
power,
but
I
think
it.
It's
come
from
the
intention
of
the
goals
of
the
department
and
we
have
to
assume
best
intent
for
for
the
for
those
goals
as
well.
Yeah.
C
C
And
I
think
that
sort
of
thing
about
assuming
positive
intent
is
also
just
if
you
sort
of
think
about
like
try
to
take
ego
out
of
the
equation
so
yeah.
You
know
they're
like
if
you're
trying
to
convince
someone
like
their
goals,
may
just
be
the
their
goals
as
they
understand
them
to
be.
C
You
know
it's
not
necessarily
some
kind
of
personal
mission,
it's
more
that
they're
just
trying
to
do
their
job,
and
so
their
goal
is
the
goal
that
you
know
has
has
sort
of
been
assigned
them
and
it's
a
good
way
also
to
think
about
your
own
work
if
it
doesn't
resonate
with
others
or
you
don't
get
support
that
you
need
it's
not
a
personal.
A
B
C
A
It's
live
and
it
can
be
hard
when
you're
doing
something
for
for
many
hours
each
day
and
you're
getting
it
like.
It's
a
lot
of
time
and
effort
that
you
put
into
something
so
it's
natural
that
one
would
feel
personal
about
it
if
you've
spent
hours
and
hours
and
hours
on
this
blueprint
that
people
don't
that
that
doesn't
resonate
with
people.
B
Yeah
and
maybe
another
way
to
frame
it
rather
than
politics
would
be
collaboration
right.
It's
not
like,
oh-
and
this
also
reminded
me
of
another
book
software,
engineering
and
Google,
and
let's
say
one
of
the
chapters
it
says
there
are
no
Geniuses.
It's
not
like
one
person
works
on
a
product
on
on
a
piece
of
code
or
on
a
product
for
six
months
comes
out
of
their
cave
and
say
here
is
the
best
product
ever.
B
This
is
the
best
thing
like
it's
most
of
them
are
from
collaboration,
so
they
brought
up
examples
of
like
even
the
Linux
Linux
Linus.
Yes
liners
that
create
the
first
version,
but
then
they
opened
it
up
to
the
public
and
also
announced
the
pre-alpha
stages
and,
like
the
collaboration,
helped
out,
make
it
to
the
pro
better
product
or
or
a
better
piece
of
software.
So
even
your
blueprint
or
our
efficient,
it's
not
just
politics.
It's
collaboration
because,
like
you,
don't
have
a
full
view
of
the
company
at
a
certain
stage.
B
You
never
like
it's
impossible
to
have
a
full
view,
so
getting
sponsored
from
someone
else.
I
I
see
it
more
of
getting
collaboration
as
well
or
a
different
perspective
about,
like
oh
I,
never
thought
about
customer
support,
for
example,
I
never
thought
this
will
increase
load
on
customer
support
people,
but
if
I
never
got
a
sponsor
from
it,
I
would
have
never
known
about
that,
for
example.
So
it's
also
a
form
of
collaboration
rather
than
politics.
I
see
it
like
at
least
here
at
gitlab
I
know
for
other
companies.
D
I
mean
one
thing
that
is
constantly
on
my
mind:
is
these
stable
counterpart
system,
which
which
naturally
exposes
you
to
other
parts
of
the
organization
and
by
that
trains,
your
muscle
for
thinking
outside
of
your
own
sphere
and
and
just
having
constant
reminders
of
all
right?
There
is
like
this
other
group
that
has
these
priorities
and
that's
what
they
are
working
on.
D
C
Richard,
do
you
mean
how
to
get
senior
Engineers
to
be
better
at
sort
of
following
that
process,
like
the
sort
of
the
political
side
of
stuff
of
kind
of
understanding
that
it's
necessary
to
you
know
kind
of
get,
support
and
communicate
and
yeah.
A
To
get
support
and
communicate
there
because
like
for
me,
one
of
the
clearest
distinctions
is
like
the
the
senior
engineer
is
inside
of
the
team
and
as
soon
as
they
start
to
expand
themselves
out,
they
start
to
be
able
to
influence
more
people,
and
then
that's
where,
when
promotion
becomes
more
likely
is
because
suddenly
they've
they've
broadened
out
what
they're
able
to
achieve
with
the
time
that
they
have.
A
A
C
Think
what
Manuel
said
was
was
kind
of
pretty
pretty
good,
like
I
think,
if,
if
the
sort
of
attaching
yourself
or
following
along
with
an
engineer
who's
experienced
in
doing
that
and
is
working
on,
something
currently
can
be
a
good
way
of
of
sort
of
getting
some
transparency
into
the
process
of
what's
involved
and
the
the
senior
developer
doesn't
necessarily
have
to
contribute
to
that.
But
can
just
watch
along
to
understand?
Oh
okay,
this
is
what
needs
to
happen.
E
One
thing
which
I
haven't
heard,
which
I'd
suggest
is
a
route
in
that
direction,
is
in
particular,
has
been
really
good
at
trying
to
build
up
this
sort
of
architecture.
E
Practice.
If
you
want
for
lack
of
a
better
term
at
gitlab
and
there's
a
slack
Channel
called
hash
architecture,
and
then
from
there
you
can
click
through
to
the
handbook
and
the
documentation
and
there's
a
lot
of
kind
of
more
strategic
thinking
that
happens
through
that
channel
and
particularly
through
the
the
blueprints
that
are
in
there
and
one
of
the
ways
to
sort
of
see
and
kind
of
get
it
get
involved
in
that
is
actually
through.
E
You
know,
even
if
you're
not
producing
the
blueprints
yet
like
reading
through
them
and
trying
to
understand
them,
and
you
know
adding
suggestions
and
also
just
seeing
how
they
evolve
over
time
and
how
you
know.
Different
stakeholders
are
going
to
try
push
it
in
different
directions
and
and
just
be
involved
in
that
process,
because
that
is
kind
of
because
coming
established
as
the
way
that
we
do
a
lot
of
that
work
at
gitlab.
E
A
It
feels
like
it's
really
like
aligned
with
the
previous
chapters
that
we've
been
reading,
like
keeping
yourself
informed
and
where
the
places
are
to
look
so
suddenly.
I
feel
less
informed
because
I
did
not
look
there.
E
E
Mean
the
the
blueprints
have
been
around
for
a
while,
and
you
know
it
really
depends.
Obviously,
there's
a
very
wide
range
right,
there's
some
blueprints
that
are
only
really
going
to
impact
one
team
and
then
those
blueprints
are
you
know
the
buy-in
that
you
need
in
order
to
get
those
blueprints
through
is
is
relatively
small,
but
then
other
blueprints
are
going
to
kind
of
affect
the
entire
organization
right,
and
so
obviously
the
buy-in
that
you
need.
There
is
much
bigger
and
also
the
you
know
it
might
extend
beyond.
E
The
main
problem
we
have
really
is
is
the
ones
that
extend
beyond
just
engineering,
because
it's
fairly
easy
to
get
engineering
buy-in
on
a
good
idea.
You
know
if
it
makes
a
lot
of
sense.
The
problem
comes
in
when
those
those
ideas
are
going
to
take
a
lot
of
time
and
expense,
and
we
need
to
justify
that
outside
of
engineering,
and
so
that's,
where
kind
of
you
know,
there's
a
lot
of
extra
work
that
needs
to
go
in,
and,
interestingly,
your
own
mentioned
this
week.
E
That
kind
of
one
of
the
way
ways
that
we
could
use
as
a
yardstick
for
that.
But
this
is
there's
still
going
to
be.
You
know
this
still
needs
discussion,
so
there's
very
early
days,
but
I
really
like
the
idea
of
it,
which
is
that
if
we
can
kind
of
amortize
the
cost
of
these
changes
over
a
year
and
it's
going
to
save
us
money
as
opposed
to
taking
like
as
opposed
to
not
doing
it,
then
we
that's
kind
of
how
we
can
start
building
up.
E
You
know
whether
this
is
the
the
right
thing
to
do
so.
You.
E
Team
is
building
rate,
limiting
I'm
just
going
to
use
that
as
a
random
example
like
it
doesn't
apply
or
not
but
say,
every
team
in
the
company
is
building
their
own
rate
limiting
infrastructure,
and
then
we
decide.
You
know
if
we
got
one
team
and
they
built
a
really
nice
rate
limiter
for
everyone
to
use.
E
And
then
we
found
that
we
could
kind
of
estimate
that
over
one
year
period,
having
one
team
build,
a
really
good
rate
limiter
is
going
to
save
us
more
more
money
than
having
10
teams
each
build
a
rate
limiter.
Then
we
can
start
justifying
it.
So
I
really
like
that
idea
of
like
amortizing
over
time
and
then
taking
that
to
the
to
the
groups.
A
Yeah
I,
like
that
idea
too,
it's
I
mean
I'm,
always
supportive
of
having
hard
data
to
to
validate
choices
and
decisions,
and
that's
also
what
I
look
for
in
blueprints
as
well
like.
Why
is
this
important
to
do
and
what
numbers
can
you
use
and
at
a
previous
company
we
were
encouraged
to
take
out
any
like
fluff
words
out
of
out
of
our
writing.
Like
you
couldn't
say,
things
like
this
is
a
vast
improvement
over
the
previous
situation
and
the
advancement
like
this
is
an
incredible
technical
advancement
to
achieve
X.
A
Like
sorry,
this
decreased
latency
by
10
across
the
seven
week
period
that
was
measured
like
you,
had
to
be
really
specific,
with
the
writing
that
what
that
specific,
writing
did
was
it.
It
gave
people
actual
numbers
and
real
data,
and
not
just
warm
fuzzy
feelings
about
things
so
I
I
liked
it
and
I
try
to
put
that
into
into
the
writing
as
well,
and
so
that's
why
I
like
the
amortization
idea,
because
you're
actually
talking
about
real
numbers,
it's
10
teams,
it's
one
team.
This
is
how
much
it
costs.
F
E
But
but
sort
of
just
getting
back
to
the
blueprints,
like
not
all
blueprints,
have
to
kind
of
be
organization,
spanning
kind
of
changing
the
world's
blueprints
right
like
that,
you
can
start
off
with
smaller
ones
that
maybe
impact
a
team
or-
or
you
know,
department
and
then
kind
of
you
know.
So
everyone's
welcome
to
create
These
Blueprints
that
doesn't
have
to
be
kind
of
like
decomposing,
postgres
right,
which
is
like
obviously,
one
of
the
biggest
ones
I
can
think
of
offhand.
A
E
E
I
think
some
of
it's,
if
you
need
to
get
buy-in
from
multiple
stake
stakeholders
right
so
you're
trying
to
get
like
you
know
if
the
stakeholders
are
just
your
team
and
you
can
kind
of
talk
in
a
team
meeting
and
get
by
and
then
just
put
an
epic
together.
But
if
the
stakeholders
kind
of
extend
a
little
bit
beyond
that,
and
you
need
other
people
to
use
what
you're
doing
and
buy
into
what
you're
doing
and
adopt
it
as
well,
then
maybe
a
blueprint
is,
is
more
appropriate.
F
Let
me
share
my
own
impression
here:
what
is
a
blueprint
here?
I
I
think
it
also
means
like
it's
like
an
architectural
change.
Maybe
it's
like
an
well
so
one
team,
multiple
one
or
maybe
touches
multiple
projects,
and-
and
it's
actually
means
that
it
changes
architecture
and
like
also
requires
other
people
to
have
a
look
at
those
changes
and
an
epic,
on
the
other
hand,
can
be
just
a
set
of
issues
of
of
it.
F
A
A
Well,
thank
you.
Everyone
for
participating
in
the
book
club
today,
much
appreciated
for
everyone
joining
in
and
looking
forward
to
seeing
you
all
next
week
to
talk
about
the
next
chapter.