►
Description
For more information, see https://about.gitlab.com/handbook/leadership/book-clubs/#high-output-management
A
Okay,
cool
recording,
so
yeah,
so
we're
doing
a
book
club
about
the
book,
high
output
management
by
Andy
Grove.
It's
the
first
book
listed
on
our
leadership
books
page.
So
we
thought
it
would
be
interesting
to
go
through
that
and
either
Rachel
or
I
have
read
it
before.
So,
if
you
have
you're
definitely
ahead
of
us
so
far
as
we
just
talked
about,
you
know
put
this
on
youtube:
if
possible,
we
will
have
a
segment
at
the
end
that
is
not
recorded.
A
B
One
of
the
things
that
attracted
me
to
this
to
this
particular
book
very
much
as
Intel
is
a
very,
very
successful
organization,
and
since
this,
since
Andy
Grove
is
one
of
the
first
set
of
employees
to
be
part
of
their
company,
I'm
really
interested
to
just
see
his
observations
about
a
company
that
is
this.
This
truly
successful
and
any
insight
that
he's
able
to
share
I
think
would
be
exceptionally
valuable,
so
I'm
just
looking
to
learn
what
he
thought
was
important.
A
Great
and
I
should
say
as
well
if
anybody
else
wants
to
jump
in
any
point
feel
free
to
do
so.
Rachel
and
I
decided.
We
would
start
this
as
a
conversation
between
us
hours
with
the
intention
that
it's
easier
for
other
people
to
join
a
conversation
rather
than
picking
people
who
are
perhaps
not
ready
to
jump
in
and
say
something.
So
if
you
want
to
join
in
feel
free.
This
is
a
conversation
for
me
personally
yeah.
A
It's
pretty
similar,
also
I
like
that,
so
well
from
what
I've
read
so
far,
but
also
from
what
I
understood
about
the
book.
Initially,
it's
it's
gonna
like
quite
a
specific
focus
on
the
high
output
part
of
the
title.
It's
it's
not
a
completely
generalist
book.
It
is.
It
has
a
very
specific
focus
on
processes
and
output
of
those
processes
and
how
you
measure
those
how
you
improve
the
output
as
well,
so
that
was
that
was
interesting
to
me.
I'll
give
a
couple
of
seconds
for
anybody
else
to
jump
in
with
anything.
That's
specific
they're.
C
Okay
on
seeing
obviously
I'm
training,
yeah
sure,
first,
no,
of
course,
the
book
of
self
I'm
trying
to
get
out
of
the
book
club,
but
the
reason
why
we're
doing
this
is
a
book
club
is
because
I
also
hope
to
learn
from
other
people's
stories
and
experiences
and
perhaps
knowledge
and
wisdom
from
other
books.
I've
read
otherwise.
You've.
Just
you
know,
read
this
by
yourselves
without
this
book
club,
so
there
you
go
I'm,
hoping
to
learn
a
lot
from
all
you.
A
Also
me
yeah
and
that's
good
point,
so
Rachel
and
I
have
I'm
pretty
sure,
I'm
right
in
saying
I
think
we
discussed
this.
Neither
of
us
have
ever
run
a
book
club
before
so
you'll
probably
be
able
to
tell
that
as
we
go
through,
but
we
have
some
sort
of
a
flake
general
plan
here
and
then
we
will
sort
of
try
and
make
each
edition
of
this
book
club
better
than
the
last
one.
A
To
start
with,
we
had
some
things
that
jumped
out
to
us
from
the
introduction
and
from
the
first
couple
of
chapters.
So
for
this
this
part
of
the
book
club.
We
read
the
first
part
of
the
book,
which
is
the
first
two
chapters.
It's
actually
quite
short,
we've
split
this
book
called
into
pass,
excuse
me
and
it
turns
out
that
the
first
and
third
parts
are
much
shorter
than
the
second
and
fourth
parts
I
think.
A
But
the
introduction
itself
was
really
interesting
to
me
because,
first
of
all
from
the
introduction,
at
least
in
my
version,
it's
apparent.
This
book
was
written
a
long
time
ago
because
the
introduction
is
talking
about
how
email
is
changing
the
world
of
work
and
that's
interesting
in
a
couple
of
ways.
First
of
all,
it
sort
of
helps
date,
its
historical
artifacts-
and
it's
also
talking
about
globalization-
was
the
other
thing
that
some
changing
the
world
of
work.
A
A
The
the
interesting
thing
to
me,
though,
is
that
in
the
introduction
where
Andy
Grove
talks
about
is
how
does
change
some
of
the
specifics,
but
it
doesn't
actually
change
a
lot
of
fundamentals
which
again
is
sort
of
like
a
I
mean
it's
the
book
talking
about
itself.
So
it's
not
an
unbiased
source
for
that.
That
sort
of
recommends
it
to
me
that,
like
these
are
skills
or
techniques
that
are
specific
to
a
specific
type
of
technology,
or
anything
like
that,
and
then
some
interesting
things
there.
A
So,
first
of
all,
I
don't
think
every
single
person
on
this
call
is
a
manager,
but
most
people
are
one
thing
it
did
mention
in
the
introduction
which
you
might
call
a
subject
matter,
experts
perhaps
sometimes
or
like
you
know,
we
have
a
technical
path
in
engineering
for
people
to
have
significant
influence
on
the
engineering
organization
without
being
managers.
Is
this
idea
of
know-how
managers
who
are
sources
of
knowledge,
skills
and
understanding
to
people
around
them
in
an
organization?
A
B
Thinking
how
to
frame
what's
my
answer,
because
I
wasn't
quite
expecting
the
question.
I
think
that
one
of
the
things
you
know
it's
it's
it's
important
for
people,
also
to
recognize
that
you
know
there.
It
is
we
might
talk
about
this
later,
but
that
there
is
leadership
and
management
and
I
think
that
both
different
types
of
people
exhibit
those
traits.
But
when
we're
looking
at
know-how,
managers
in
the
context
of
the
first
chapter,
I
think
I
was
I'm
interested
to
know.
B
The
management
trait
but
I,
yeah
and
I
think
that
I
also
appreciated
very
much
that
he
called
out
the
specific
difference
between
the
kinds
of
people,
because
I
very
much
appreciate
that
over
the
past
couple
of
years,
there's
definitely
been
this
trend
that
the
correct
career
progression
for
engineers
is
not
just
to
make
their
managers,
because
it's
a
very
different
type
of
job,
that
you're
doing
and
for
a
long
time
I
think
engineers
felt
that
the
only
way
to
advance
was
to
become
management,
and
then
you
stopped
coding,
and
you
stopped,
you
know,
being
part
of
the
day-to-day
of
how
the
tests
run,
and
you
know
they
can
be
quite
frustrating
for
some
people.
B
A
There
is
some
way
in
which
these
people,
who
are
more
senior,
who
are
are
not
managers
make
the
rest
of
the
organization
better,
not
just
the
selves
and
I
think
I
think
that's
that
sort
of
the
the
key
parts
of
me
here
but,
like
you
said
I,
did
find
it
interesting
that
this
book
sort
of
explicitly
called
that
out.
Given
that
it's
it's
something
that
very
much
fits
into
our
model
today
and
here's
the
thing
we
actually
talked
about
Oh
contributes
term
in
a
in
a
plug
for
the
workshop
I
helped
you
run
so
yeah.
D
Know
how
managers
and
having
indicators
and
things
for
themselves
I
previously
was,
at
my
other
job,
had
a
team
that
I
was
managing
so
now,
but
now
I,
don't
and
before.
We
have
lots
of
indicators
and
when
I
read
that
part
in
the
book,
I
thought
oh
I
could
do
that
for
myself
too,
especially
around
productivity
I
feel
the
remote
environment.
This
is
my
first
time
working
remote
I've,
been
at
three
months
tomorrow
and
so
I
feel
my
productivity
has
really
gone
down
to
be
honest
and
so
I
think
putting
some
indicators
in
place.
D
E
A
No
that's
interesting
actually,
because
I
felt
very
much
the
same,
like
I'm
literally
on
you
read
the
first
two
chapters:
I'm
not
read
ahead
at
all
yet,
but
even
then
I
was
like
oh
wait.
Maybe
maybe
I
should
do
some
of
the
stuff.
That's
already
like
you
know
in
these
first
two
chapters.
So
it's
interesting,
that's
like
a
few
of
us
have
had
that
or
at
least
a
couple
of
us
have
had
that
reaction.
I
think
Rachel
mentioned
something
similar
as
well.
F
Yeah
and
I
like
knowing
your
metrics
and
tracking,
is
accordingly
in
marketing.
That's
something
that
we're
doing
and
we're
now
trying
to
go
down
a
few
few
layers
deeper
as
we
further
segment.
You
know
between
sales,
so
I've
known
that,
but
it
was
always
a
good
reminder
and
the
other
thing
that
I
thought
was
interesting
too.
It
was
around,
you
know,
kind
of
the
burndown
charts
and,
and
then
the
black
box,
where
you
can
inspect
your
process
and
look
at
at
different
points
throughout
throughout
your
process.
B
The
other
thing
I
wanted
to
add
is
also,
and
with
out
they
talked
about
leading
indicators
and
in
my
previous
well
in
one
of
my
previous
jobs.
I
had
much
more
involvement
with
the
sales
organization
and
the
head
of
sales
would
often
talk
about
leading
indicators
and
I
could
never
really
make
it
properly
fit
and
make
sense.
B
So
it
was
really
interesting
to
now
read
it
in
this
context
and
actually
have
a
much
better
understanding
of
what
they
were
actually
trying
to
achieve
then
and
then
also
interesting
that
Leslie,
you
would
talk
about
the
burndown
charts,
because
I
can
admit
I
mean
from
an
engineering.
We
use
those
all
the
time.
So
I
can
see
how
different
people
reading
this
book
will
be
getting
different
things
out
of
it
for
sure
I.
F
A
Yes,
sorry,
just
one
thing:
I
wanted
to
know
about
the
quotes
that
Rachel
and
I
picked
out
here
or
two
things.
First
of
all,
sorry
one
we
just
picked
out
these
quotes,
like
you
know,
we're
welcome
to
like
go
off
these.
These
are
more
like
a
framework
for,
if
we're
not
really
getting,
you
know
if
the
discussion
starts
to
slow
down.
A
So
I
think
I
assume
that
it's
the
same
in
marketing
Lesley
that,
like
across
gate,
lab
as
a
whole,
we
are
focusing
more
on
getting
solid
KPIs
key
performance
indicators
like
in
and
reporting
and
having
that
like
access
dinner
in
a
consistent
way
across
the
organization
is
that
is
that
something
that
marketing
are
working
on
as
well.
Yeah.
F
A
Yeah,
have
you
found
it
so
one
of
the
quotes
that
it
mentioned,
which
I
felt
like
I
disagreed
with
and
I
could
see
a
way
in
which
I
could
agree
with
it
is
where
it
says
a
measurement.
Any
measurement
is
better
than
none
and
I
feel
like
you.
You
can
take
really
bad
measurements,
like
you
can
measure
totally
the
wrong
thing,
but
I
can
see
the
argument
that
maybe
what
the
book
is
trying
to
say
is.
A
F
Yes
and
I
think
you
know
we
had
one
tool
that
we
were
using
to
build
out
our
dashboards
from
now
we're
in
the
process
of
switching.
So
as
long
as
you
understand,
I
think
so
we
went
through
an
exercise
of
pulling
out
measurements
and
like
we
don't
really
know
that
this
is
accurate
or
that
we
agree
with
it.
So
we
didn't
make
any
big
decisions
based
on
that
data.
F
It
was
more
or
less
going
through
the
exercise
of
getting
all
the
parties
involved
in
and
pulling
in
data
and
actually
looking
at
something
and
iterating
from
there.
So
I
think.
As
long
as
you
have
that
context,
in
the
understanding
of
you
know
this
is
this
is
a
first
measurement.
This
is
an
MVC
of
a
measurement.
I
mean
will
make
any
any
rash
decisions
on
them.
I
think,
but
I
did
struggle
with
that
Shawn
as
well.
It's
like
do
I,
do
I,
agree.
H
So,
just
a
bit
of
an
observation:
there
I
think
it
was
circa
2006,
one
of
the
CTOs
actually
bought
a
vineyard
I
think
it
was
2004
out
in
Napa,
Valley
and
I
got
the
opportunity
to
go
visit.
It
was
pretty
interesting
to
see
how
this
particular
person
had
optimized
some
of
their
processes
around
around
actually
making
wine
in
the
kind
of
similar
fashion.
H
In
particular,
they
they
actually
installed
sensors
every
five
feet
in
recording
every
five
minutes:
air
pressure,
water,
vapor
temperature
around
that
so
like
and
the
the
quote
that
was
given
was:
is
it
Intel?
You
know,
there's
something
that's
measurable
will
measure.
It
is
kind
of
a
philosophy,
so
it
was.
It
was
a
different
mindset
of
don't
worry
about
thinking
in
terms
of
a
bad
measurement,
think
in
terms
of
just
measuring
everything
and
then
looking
at
the
data
after
the
fact
and
kind
understanding.
H
What's
going
on
if
it's
technically
feasible
to
measure
something
measure
it
from
that
perspective,
which
sounds
sounds
like
you
know,
like
yeah,
you
could
have
bad
measurement
get
data,
but,
like
it's
the
interpretation,
the
data,
that's
the
power.
The
key
aspect
there
is
that
that's
my
observation,
yeah.
A
I
think
I
think
my
wariness
around
this
is
probably
like
more
on
me.
That's
a
book,
but
also
I,
just
looked
it
up
whose
lore
it
is
because
one
of
these
that's
like
named
after
someone
which
is
a
good
heart
slaw,
which
is
when
a
measure
becomes
a
target.
It
ceases
to
become
a
good
mode,
good
measure,
or
you
know.
A
H
I
think
it's
it's
more
of
discerning
between
optimization
measuring
right.
So,
like
the
challenge,
this
is
on
a
lot
of
situations.
You
don't
know
going
into
it.
What's
the
right
measurements,
you
have
to
actually
discover
that,
and
actually
they
change
over
time
as
well,
and
how
you
want
the
organization
to
move
and
be
effective.
H
So
consequently,
that's,
that's
kind
of
what
I've
seen
is
I've
actually
seen
where
you
know,
like
one
measure,
will
be
a
great
measure
for
two
or
three
years
and
then
the
team
will
actually
change
based
on
the
fact
of
understanding
the
fact
that,
like
we've
no
longer
want
to
optimize
this,
but
we'll
still
have
it,
but
we
just
don't
want
to
do
that
to
be
the
leading
indicator.
Optima
optimization.
A
That's
interesting,
yeah,
I,
guess
that
can
also
happen
with
like
the
organization
maturing
right,
like
you
know,
the
less
mature
it
is
the
sort
of
like
the
broader
the
measures
can
be
and
then,
like
you
know,
you
might
have
it
almost
solved
that
problem
and
it's
something
you
want
to
keep
an
eye
on.
But
it's
not
it's
no
longer
I
guess
a
key
performance
indicator.
It's
just
a
performance
indicator.
Maybe.
I
A
very
loaded
question
to
ask
and
I
know
it
going
into
it,
but
I'm
going
to
I'm
going
to
I
want
to
do
it
anyway.
So
on
the
topic
of
measuring
what
you
can
and
on
the
observation
of
measure
output
rather
than
activity,
if
we
were
to
turn
this
into
a
very
engineering
specific
conversation,
noting
that
we
very
closely
monitor,
merge,
requests
and
number
of
merge
requests
per
engineer,
are
we
convinced
that
we
are
measuring
output
rather
than
activity?
I
D
E
No,
it's
a
really
really
good
question,
and-
and
we
could
talk
to
death
about
this
so
I'm
not
gonna.
Do
it
but
I
put
in
a
quid
because
I've
been
thinking
about
this
as
everyone's
been
talking
this
morning.
I
really
like
that.
As
he's
talking
about
measures,
he
also
talks
about
measuring
quality.
So
so
I
agree
with
you.
Throughput
does
measure
activity
to
some
extent.
E
The
way
I
like
to
look
at
throughput
is
paired
with
quality
metrics.
So
what
I
say
is
I'd
like
the
team
to
go
small
and
fast,
but
we
need
to
monitor
quality,
because
if
quality
is
going
down,
then
all
we're
doing
is
that
the
activity
so
I
very
much
buy
into
engineering
metrics
is
more
than
one
data
point
and
the
way
you
get
visibility
into
the
health
of
the
team
is
having
these
different
measures
come
together
and
put
in
a
view
of
the
health
of
the
team.
All
right,
let.
I
I
Should
it
be
more
of
an
encouragement
to
break
issues
down
rather
than
to
break
it
into
multiple
merge
requests
itself,
because
then
it
becomes
a
more
nuanced
status,
reporting
conversation
and
I'm.
Sorry
for
turning
this
into
directly
into
an
engineering
conversation,
but
I'm
I
was
really
thinking
about
this
over
the
weekend,
yeah.
H
It's
an
interesting
question.
First
of
all,
this
gets
back
to
you
know
is
mr.zhou
right
things
like
you
could
put
lines
of
code
you
could
become
hours
commits.
You
could
take
issues
right,
like
all
those
are
appropriate
things
and
I
think
I.
Think
right
now
we
sailed
on
em
ours,
but
you
know
like
over
time.
We
may
actually
choose
to
move
it
based
on
on
where
we
see
the
actual
meaning
where
we
see
the
need
to
move
the
needle.
H
G
H
We
were
using
to
evaluate
how
we're
doing
as
an
organization
and
so
whether
we're
doing
a
good
job
or
not
I
wouldn't
characterize
it
as
we're
encouraging
people
to
break
down
in
march,
because
the
metric
we're
encouraging
people
to
break
down
in
March,
because
we
think
it's
the
right
thing
to
do
so.
It's
not
it's
not
contradictory,
because
that's
the
big
things
people
say:
oh
well,
I'm
gonna
have
to
make
some
metric
I'm
gonna
just
break
down
marks
when
we
say
that's
a
good
thing
like
that's,
not
a
bad
thing
right.
H
H
H
Don't
you
have
anything
add
I,
know
that's
kind
of
slightly
contradictory,
but
it's
it's
a
I
could
just
like
that.
That's
a
very
subtle
point
that
I
think
is
important.
That
kind
of
recognizes
that
you
know
breaking
dynamic
rock
on
Mars
is
a
great
thing.
We
should
concur
to
do
that,
regardless
of
yeah.
E
E
Yes,
is
it
the
measure
that
we're
getting
some
value
out
of
I
agree
with
Christopher
right
now?
I
think
that
is
the
case.
We
can
revisit
it
again
without
diving
too
much
into
it.
The
background
here
is
that
we
found
that
working
with
the
gait
lab
product.
It
was
much
easier
to
break
down
to
multiple
m
RS
instead
of
multiple
issues,
because
it
was
really
nice
to
have
the
issue
have
the
full
context
of
what
you're
trying
to
implement
and
have
flexibility
to
break
your
M
R's
to
very,
very
small
deliverables.
E
B
A
So
I
think
we
talked
about
the
sort
of
general
measurement
stuff
and
also
about
pairing
the
indicators
where
I
think
Talia
mentioned
this
as
well,
but
the
book
specifically
says
like
it's
good
to
pair
indicators
and,
ideally
so
in
fact,
I
Leah's
question:
that's
perfect,
ideally
you're
pairing,
something
that
measures,
quantity
or
output
with
an
indicator
that
measures
quality
in
some
way
and
Rachel.
You
had
some
thoughts
on
the
different
types
of
inspection
and
monitoring.
The
book
talked
about
yeah.
B
But
it
also
then
impacts
what
type
of
quality
we're
producing
and
we
need
to
be
mindful
of
both
of
those.
But
at
least
it's
got
me
thinking
about
what
what
actions
were
taking
for
what
reasons
so
I
thought
that
that
was
a
really
that
perhaps
one
of
the
biggest
things
that
I've
taken
away
from
from
this
first
part
of
the
book.
A
H
It's
interesting
because
I
don't
know
if
I
could
articulate
I
let
my
last
job
I
could
have
clear,
articulate
what
her
critical
path
was
and
what
we
were
trying
to
optimize
to
at
least
for
an
organization
which
I
don't
know
if
I
could
articulate
that
right
now
for
this
organization
over
the
company.
So
if
anybody
has
any
suggestions,
are
those
do
your
feedback
on
that?
From
that
perspective,
as.
H
I
I
can
name
three
okay
planning,
because
we're
trying
to
do
too
big
of
a
chunks,
even
with
monthly
releases,
maintain
a
review,
because
it's
too
scarce
of
a
resource
onboarding
of
new
engineers
to
make
them
fully
productive.
I
I
would
argue
that
different
argue
they're
different
planes
so,
but
but
if
I
were
to,
if
I
were
to
articulate
trying
to
get
mean,
if
you
were
to
try
to
optimize
around
throughput,
it
would
be
around
maintainer
review.
Yeah.
H
G
A
B
It
looks
pretty
interested
so
I'd
be
really
interested
to
hear
from
from
outside
of
the
engineering
organization
to
what
blocking
steps
might
be.
I
find
it
interesting
to
find
out
about
processes
and
other
teams,
because
it's
so
often
they
actually
do
encourage
us
to
think
inside
of
engineering
as
well
about
how
things
are
related.
So
yeah
I'd
be
very
interested
to
hear
from
from
others
as
well.
F
J
I'm
still
pretty
new,
so
it's
been
really
interesting
to
hear
everyone
talk
from
outside
of
sales.
I
would
say:
ask
me
again
in
a
couple
weeks,
because
I'm
still
trying
to
even
coordinating
we're,
trying
to
coordinate
a
bit
onboarding
there's
so
many
new
people,
starting
that
have
started,
but
it's
pretty
insane
so
like
this
week,
I'm
trying
to
work
on
setting
up
a
process
to
get
all
of
these
people
that
have
I
think.
F
That's
a
that's
gonna
be
like
one
of
the
biggest
blockers.
Yes,
sales
standpoint
and
kind
of
marketing
to
we
have
processes
that
I
I
will
say
from
Field.
Marketing
I
would
not
take.
I
will
not
say
this
for
anyone
else
in
marketing,
but
we
could
learn
from
engineering
in
terms
of
how
well
you
all
document
everything
we
are.
We
are
getting
better,
but
we're
building
processes
as
we
go
so
I
think
that's
a
big
blocker
right
now
on
internally.
J
I
would
agree,
I
mean
there's
nothing
documented
in
a
handbook,
so
that's
been
my
biggest
struggle,
so
I
mean
that
sort
of
something
that
I'm
hoping
to
work
on
is
because
there's
no
resource
if
there's
nowhere
to
go,
and
so
basically
you
know
when
I
defer
back
to
my
manager.
Ryan.
Oh
now
he's
like
well,
we
have
to.
We
have
to
build
it.
People
forget
how
new
this
company
actually
is
and
what's
left
to
be
done.
A
So
would
you
say
there
that
having
things
in
the
handbook
is
unblocking
people,
because
so
my
my
reaction
would
be
from
an
engineering
perspective
that
unblocks
people,
because
they
don't
need
to
wait
for
someone
to
respond
to
them.
So
you
can
just
go,
look
it
up
themselves
and
they
can
move
on
with
their
day
and
also
if
they
have
a
question
about
that,
they
can
refer
back
to
it
in
the
future.
Is
that
what
you're
thinking
of
there
Marsha
or
is
there
some
fake.
J
A
Right
I
see
so,
like
you
know
not
even
knowing
not
having
that
overview
of
like
how
everything
fits
together
as
well.
That's
interesting,
thank
you,
so
yeah
I
did
think.
When
you
said
ask
me
in
a
couple
of
weeks,
I
was
like
well,
the
next
book
club
said
a
couple
of
weeks.
Maybe
I
should
make
a
note
to
come
back
to
you
there,
but.
A
F
In
line
with
our
value
of
iterations,
which
is
probably
one
of
the
values
that
I
struggle
the
most
with
personally
I'm
a
perfectionist
and
so
I
always
I
try
to
get
information
out
there
as
soon
as
possible,
but
I
keep
noticing
that.
Maybe
it's
like
not
soon
enough,
so
I'm
working
on
that,
but
I
think
you
know
that
way:
you're
not
spending
more
time
and
effort
on
something.
That's
not
it's
not
going
to
produce
what
you
think
it's
going
to
produce!
I,
don't
know
if
anybody
else
has
experienced
that
or
has
any
thoughts
on
that.
A
So
I'm
just
gonna,
while
people
think
about
if
they
have
any
thoughts
on
that
I'm,
just
gonna
sort
of
so
what
I
remember
from
the
book
was.
This
was
talking
about
the
breakfast
factory
and
I
will
do
that.
It
uses
all
the
way
through
and
it's
saying
if
you
have
a
bad
egg
in
your
batch,
like
the
oil,
you
know
in
your
process
pipeline
the
early
you
find
that
the
cheaper.
A
J
G
It's
bad
code,
it's
bad
idea
in
the
program,
so
my
question
to
try
to
help
answer
is
like
what
monitoring
you
have
in
place
for
that,
where
you
go,
cleaning
up
the
egg
cartons
and
checking
for
the
bad
eggs
beforehand,
saying
sometimes
it's
the
application
of
you're
doing
some
kind
of
measure
there,
because
most
of
the
time
we
just
aren't
we're
just
shipping.
You
know
they
say
it,
but
we're
shipping
minimum
while
increments
all
the
time
and
codes
for
us
in
engineering.
So
how
are
we
inspecting
our
code
and
verifying
that
for
shipping
good
code?
G
You
know
for
me
I
care
about
comm.
So
how
do
we
prevent
that
bad
piece
of
code
from
growing
the
comm
have
the
same
problem
with
prior
companies
like
there's?
Another
part
of
me
that
the
reaction
of
some
of
the
cyber
liability
folks
is
to
just
monitor
as
much
as
we
can
so
that
as
soon
as
they
can
stop
calm,
that's
causing
a
problem.
You
can
get
back
to
engineering
and
provide
this
feedback
as
soon
as
possible.
F
Field
marketing
standpoint
a
lot
of
times
it's
getting
on
site,
choosing
one
type
of
event,
a
workshop
to
run
and
going
through
and
running
that
and
then
what's.
The
downside
of
that
is
well.
Sales
needs
more
than
once
more
now.
So,
if
I'm,
if
I'm
waiting
to
see
the
output
of
one
of
my
events,
then
you
know,
can
I
can
I
afford
to
take
the
time
to
do
that
and
what's
the
what's,
the
result
of
that
gonna
be
so.
A
F
F
So
those
are
two
completely
different
different
territories,
so
you
know
David.
Your
point
is
really
bad
at
in
terms
of
where
you
inspected
but
and
I
think
just
kind
of
pointing
out,
like
you
mentioned,
what
what
are
you
holding
back
if
you're?
What's
the
not
holding
back
both?
What
is
the
company
potentially
missing
out
on
if
you're
not
moving
borders
as
quickly
and
of
course,
sales
always
wants
more
now.
B
You
know
adding
to
the
handbook
and
documenting
everything,
because
that's
essentially,
what
makes
a
process
like
this
successful
and
what's
also
I
found
really
interesting
and
working
at
gitlab
is
that
anyone
can
go
and
contribute
to
how
to
make
this
process
better
from
each
side
flowing
down
into
the
product
back
up
into
this
inter
cells
and
yeah.
So,
just
coming
back
to
that,
I
think
it's
it's!
It's
a
it's
interesting
to
say
that
and
I
have
heard
that
installed.
Enlightened
yeah.
A
Yeah
I
think
I
was
just
thinking
as
well
like
because
in
Intel's
case,
like
you
know,
they've
had
some
issues
recently,
in
fact,
which
are
incredibly
expensive
to
fix
because
of
the
work
they
do,
because
it
involves
hardware
because
it
involves
large-scale
manufacturing
and
almost
they
feel
like
to
what
Dave
was
saying.
Sometimes
when
we
have
something:
that's
not
that
expensive
to
fix
it.
A
It's
easy
to
underestimate,
like
oh,
it
doesn't
feel
like
expensive
to
fix
it's
easy
to
underestimate
the
cost
of
that
getting
through,
because
they,
you
know,
you
feel,
like
you're,
just
sort
of
dealing
with
code
and
stuff
like
you
know,
you
can
patch
it
you
can.
You
can
fix
it
next
time
like
it
can
be
easy
to
string
too
far.
A
Basically,
we
weren't
really
sure
what
the
demand
for
this
would
be.
On
the
previous
book
club
that
former
director
of
engineering
around
and
get
lab,
it
was
about
Crucial
Conversations
at
the
book,
which
you
know
a
lot
of
what
you
talk
about.
There
is
like
by
nature
like
emotionally
charged
situations,
difficult
situations
to
deal
with,
so
it
was
helpful
to
have
that
not
be
public.
A
E
Sure
I
just
wanted
to
highlight
it,
because
I
found
I
really
related
to
what
he
was
saying
about.
You
know
black
box
and
peering,
like
looking
in
so
in
in
my
previous
practice.
Just
looking
over
engineering
metrics,
that's
very
much.
What
we
do
week
to
week,
which
is
you
know,
throughput,
is
high.
We
could
ask
questions
and
having
some
of
these
debugging
type
of
numbers
has
been
really
helpful,
so
you
can
dive
in
and
figure
out.
E
What
is
what
is
this
data
telling
you
so
I
just
wanted
to
call
it
out
and
Shawn
to
what
you
were
talking
about
in
the
previous
comment,
one
of
the
ways
that
I
found
with
having
multiple
data
points
is,
you
were
talking
about
like
the
cost
of
making
a
change
and
measuring.
So
we
one
of
the
things
we
would
use
because
again
back
to
why
you
would
like
to
track.
E
Multiple
data
points
is
that
if
a
team
cycle
time
to
turn
around
a
fixed
was
extremely
low,
that
team
could,
by
nature,
was
able
to
take
much
more
risk
than
a
team
that
needed
multiple
days
to
turn
around
a
fix
in
production.
So
that
made
the
cost
of
going
fast.
And
you
know
yes,
we
its
code,
we're
gonna,
make
mistakes,
and
it's
perfectly
fine.
As
long
as
the
the
impact
was
really
really
low,
and
we
could
turn
it
around
fairly
quickly.
E
A
Know
that
that's
interesting,
thank
you.
Yeah
I
think
I.
Think
that
sort
of
point
about
being
able
to
correlate
those
different
things
is
very
useful
like
and
I
might
go
back
to
Christopher's
point
as
well
lit
and
Dave's
as
well.
If
you
measure
it,
you
might
not
need
it,
but
you'll
be
glad
if
you
do
need
it
and
you
already
were
measuring
it
rather
than
like
being
like.
Oh
I
wish
we
started
measuring
this
six
months
ago,
so
we
could
know
what
the
trend
was
here.
A
A
This
section
is
management.
It's
a
team
game.
The
first
chapter,
I
just
noticed,
was
about
managerial
leverage,
which
was
one
of
the
quotes
we
didn't
get
to
they're
about,
like
the
three
ways
of
increasing
productivity,
increasing
the
rate
of
work,
leverage
and
work
simplification.
That
section
is
longer,
as
Thomas
pointed
out,
so
you
know
you've
got
two
weeks
to
read
it,
but
please
bear
that
in
mind
when
you're
going
through
so
yeah.
Thank
you
very
much.
Everyone
I
really
appreciate
it
and
we'll
speak
to
you
all
in
two
weeks.
F
A
Sorry
I
should
have
said
so.
This
isn't
working
exactly
like
a
regular
get
lab
meeting
agenda.
We
just
thought
we'd
seed
it
with
some
stuff.
But
yes,
if
something
jumps
out
to
you,
please
go
ahead
and
add
it
straight
to
this
agenda
just
as
you're
reading
it,
and
then
we
can
sort
of
corral
that
closer
to
the
time
as
well,
because
basically
it
makes
Madame
Rachel's
job
easier.
So
we
really
appreciate,
if
you
do,
that.