►
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
All
right
so
in
recording
yeah,
so
thanks
for
taking
us
Kyle
thanks
for
putting
up
with,
am
I
not
doing
the
best
practice
of
setting
up
meetings.
I
was
late
on
Friday
I
was
too
excited,
but
that's
not
an
excuse.
So
the
process
is
I'm
supposed
to
send
you
agenda
doc
attached
and
everything
into
that
so
which
I
had
done
and
thanks
for
doing
some
of
the
work
there.
A
So
what
I
wanted
to
talk
about
is
engineering
process
at
your
lab,
but
maybe
me
maybe
I
just
have
some
of
the
background
is
that
I'm,
a
product
manager
working
on
VSM
and
so
at
Kidd
lab
so
you've
been
here.
What
like
over?
Is
it
happy?
You
know,
it
seems.
You've
been
two
months
only
two
months
or
two
months:
oh
wow,.
A
B
A
A
We
put
a
premium
on
that,
often
going
out
of
our
way
to
use
really
half-baked
features
and
say
release,
try
to
say
no
to
external
tools,
because
we
put
such
a
bias
on
that,
believing
that
that
will
help
us
improve
the
product
or
make
us
feel
pain
you
or
dogfooding
101,
and
so
a
big
part
of
that.
My
job
in
particular
I
tell
people
it's
it's
doubly
hard
because
I
most
everybody
uses
the
features
of
the
planned
stage
of
which
I'm
in
the
primary
job,
so
I
get
a
lot
of
feedback
in
particular,
I.
A
A
We
didn't
have
a
lot
of
engineering
process
in
depth
in
the
past
and
we
we
just
an
even
have
the
role
of
engineering
manager
as
a
title,
even
when
we
had
leads
as
well
and
then
I
think
it
was
at
that
point.
That
was
the
philosophy.
I
remember
many
times
sitting
like
people
should
self
manage,
or
something
like
that
and
say
specifically
batiment
and
so
obviously
I
think.
We've
got
a
long
way
from
that
from
beyond
that
philosophy,
and
we
have
engineering
managers
and
I.
A
Don't
think
that
quickly
we
have
team
meets,
or
maybe
that's
part
of
the
the
career
path
to
me.
But
you
know
you
can.
Let
me
know
about
that.
But
we
have
engineer
managers
and
we
have
been
on
the
entropy
of
director
levels
and
we
have
folks
like
yourself
and
then
we
have
Erik
Johnson
and
Erik
Johnson
to
me
was
the
one
who
really
kick-started
this
once
we
hired
him
and
really
built
out
this
philosophy
and
the
teams
which
which
I
really
like
and
then
on
the
product
management
side.
A
I've
been
really
pushing
to
have
engineering
department,
do
engineering
management
and
have
product
management
do
less
and
less,
and
maybe
I
did
leave
zero
project
management,
because
when
we
were
in
the
team
leave
world
that
a
lot
of
product
managers
have
been
doing
that
and
so
even
with
new
product
folks
coming
in.
Unfortunately,
in
my
opinion,
a
lot
of
that
culture
has
has
stayed,
and
so
a
lot
of
disconnect
I
personally
see
is
product
wants
to
do
this.
We
think
we
have
all
these
great
ideas
in
terms
of
process
and
project
management.
A
A
Another
piece
of
background
would
offer
you
is
what
MEC
and
the
quality
team
had
been
doing.
So
what
I've
observed
with
Eric
bringing
mint
in
is
that
very
early
on
the
quality
team
was,
and
they
continue
to
be
tasked
with
formalizing
a
lot
of
the
process
and,
in
terms
of
you
know,
just
reading
in
handbook,
but
also
making
the
tools
inside
kit
lab.
A
So
an
obvious
one
is
good,
lab
triage
and
then
the
insights
inside
the
project
which
is
now
being
moved
into
gate
lab
so
that
team
has
been
involved
heavily
with
defining
the
process,
making
sure
it's
the
institution
inside
the
product
and
driven
and
going
forward.
So
there's
a
lot
of
background
there
and
since
I
have
a
really
bad
cop,
I'm
gonna.
Let
you
respond
to
any
of
the
head
before
I
talk
about
like.
Why
am
I
even
coming
to
you.
B
Yeah,
you
said
a
couple
things
that
are
kind
of
interesting,
which
is
you
know,
and
this
is
the
this-
has
always
been
a
thorny
issue
between
a
product
management
and
development
or
software
development,
which
is
you
know,
who
runs
the
projects
and
what
we've
done
this
year
is
we've
kind
of
guess.
So,
first
of
all,
to
my
knowledge,
we
don't
have
really
concept
of
technically
we
have
senior
engineers
and
we
have
managers.
You
could
argue
that
engineering
managers
could
be
considered
a
tech
lead
usually.
B
Lead
when
you
have
engineering
managers
who
need
to
scale
above
a
smaller
size,
but
if
you
look
at
most
of
our
teams,
our
goal
is
this
year's
is
to
basically
effectively
have
teams
between
I
would
say
four
and
six
reporting
to
a
single
manager.
You
know
some,
some
teams
needs
maybe
a
little
larger.
Some
teams
fail
right
and
that's
still
back
in
for
then
separate
as
sort
of
the
default.
Correct,
that's
correct,
and
what
I
think
is
going
to
be
true
is:
is
the
project
management
for
a
given
area?
It's
going
to
be.
B
If
it's
contained,
you
know
if
the
effort
associated
with
the
particular
activity
is
contained
within
that
area,
it's
gonna
be
very
straightforward
and
that's
usually
where
you
know
the
engineering
managers
can
self
self
control
it
and
they
can
contain
it
and
effectively.
Do
it,
I
think
where
it
becomes
really
hard,
as
only
it's
durable
winning
features,
which
requires
some
type
of
cross
team
not
front
end
back
end.
B
B
A
A
A
B
A
Yeah
that's
interesting,
I've
been
just.
This
cannot
be
putting
together
some
issues
and
talking
their
plan
folks,
because
I
know
we're
getting
planned
product
managers
and
so
selfishly
I,
don't
one
a
p.m.
what's
officially
for
me
as
a
plant
p.m.
in
and
for
the
new
pm
I
don't
want
PM's
having
to
share,
not
have
a
dedicated
team,
because
I
think
that's
always
really
difficult
for
P
I
mean
even
for
a
new
p.m.
A
to
say,
like
you
know,
you
have
all
these
great
ideas,
but
you
can't
really
execute
on
them,
because
you
have
to
wait
on
this
other
p.m.
so
so
I've
been
selfishly
wanting
to
have
team
split
already
within
plan,
but
anyways.
So
so,
that's
great,
so
an
area
that
the
planned
side
of
the
product
is
working
on
which
I'm
working
on
is
figuring,
inventing
really
the
future
of
agile
devops,
and
so
that's
a
old.
A
A
We
have
one
product,
category
called
value
stream
management,
and
you
know
something
I'm
sure
you've
heard
of
a
sort
of
a
buzzword,
type
thing
that
that
I
would
say-
and
within
this
framework
of
value
stream
management
of
which
we
participated
in
a
Gardner
report
last
year
and
we
scored
actually
pretty
high.
But
we
haven't
really
made
additional
headway
and
that's
something
that
we
want
to
do
and
so
the
way
we
think
of
balance
tree
management
somewhat
closely
is
associated
with
what
the
industry
things
about
it.
A
What
these
analyst
reports
and
and
I
just
wanted
to
talk
about
that
and
see
if
that
aligns
with
what
you're
thinking,
because
where
I'm
stuck
is,
there's
this
framework
out
there
I,
don't
know
if
I'm
100%
on
board
with
it
I,
don't
want
to
just
build
a
feature
into
your
lab.
Because
that's
what
you
know
these
analyst
reports
say
and
I
want
to
check
in
with
our
customers,
which
I've
done,
but
when
checking
in
with
gitlab
I
can
go
a
little
bit
more
detailed
than
say
another
customer,
and
so
how
this
framework
is
or
what?
A
A
So
that's
already
one
red
flag,
and
so
once
you
have
this
workflow
according
to
DSM,
you
can
know
how
long
each
stage
is
taking,
and
so
the
name
of
the
game
in
DSM
is
really
making
the
entire
intent
end
stage
as
small
as
possible,
because
the
SM
and
I
and
the
industry
agrees
that
if
we
compress
the
into
n
cycle
time
it's
of
direct
business
benefit
because
agile
teaches
us
the
faster
you
ship,
the
more
deploys
you
have.
And
then
you
know
all
these
criteria.
Then
you
could
have
better
business
outcomes.
A
So
you
can
sort
of
draw
and
logic
to
that.
It's
you
know,
it's
pretty
pretty
obvious.
I
would
say
it's
not
it's
not
exactly
scientific,
but
I've,
seen
some
work
in
the
industry
where
they
did
correlate
high
performing
teams
with
like
three
or
four
things,
and
one
of
them
is
which
is
unsurprising
just
like
look
high
morale
and
low
burnout,
which
is
sort
of
weird,
but
they
characterized
that
which
is
really
cool.
Another
one
is,
is
high
frequency
of
deploys,
which
is
again
so
that
people
are
not
annoyed.
A
So
then
the
infrastructure
there
and
then
the
other
one
is
a
short
cycle
times.
So
what
I
really
want
to
focus
on
is
the
short
cycle
times,
especially
in
the
case
of
Gil
lab,
because
our
frequency
of
deploys,
you
can
argue,
is
constant
ish.
You
know
morale,
we
can
sort
of.
How
do
you
put
that
into
the
products?
I?
Don't
I,
don't
I
don't
attack
on
that
just
yet.
So
I
really
want
to
focus
on
short
cycle
times,
and
this
is
where
I'm
sort
of
hitting
a
wall,
because
a
good
lab.
A
It's
not
actually
a
really
metric
that
a
lot
of
people
talk
about,
and
it's
actually
not
something
that
we're
officially
optimizing
for
in
a
handbook,
because
we
say
something
about
velocity
over
predictability
which
I'm
not
a
hundred
percent
on
board
with.
But
you
know,
if
that's
a
handbook,
I'm
gonna
roll
with
that,
and
so
the
handbook
seems
to
be
saying
things
like
high
number
of
murder.
A
Quests
and
saying,
like
you
know,
ten
merge,
requests
per
developer,
I
think
is
a
good
thing
and
then
he
wants
people
to
game
it,
because
they,
then
people
will
actually
make
small
emerging
because
I
actually
agree
with
that.
I
think
that's
a
really
really
great
incentive.
So
so
there's
that
where,
where
I?
A
Can
that
we're
saying
more
merge
request
because
we
sort
of
a
fixed
Freight
and
we
don't
really
use
these
workflow
stages
in
any
ways,
because
you
know
we
have
technically,
we
have
two
labels
called
in
dev
and
in
review,
and
some
teams
use
them
and
I
think
plan
uses
them
sporadically
and
but
it's
not
like
we
have,
you
know
in
review
in
uit
in
QA.
We
don't
have
that,
and
so,
even
if
we
were
to
invent
all
these
tools,
would
we
even
care
about
those
stage,
those
things
so
I'm
I'm
like
do
we
really?
A
Should
we
really
build
this?
What's
going
on
so
I'm
I'm
sort
of
really
cautious
about
that
right
now,
and
so
what
I'm
coming
to
you,
I'm,
not
only
asking
you
should
rebuild
that
I'm
asking
you
more
broadly.
You
know
of
course,
comment
on
that,
but
maybe
from
your
perspective
from
your
experience,
what
has
worked,
what
hasn't
worked?
A
What's
your
vision
of
gitlab
internals
in
terms
of
just
engineering
excellence,
and
that's
why
I
was
trying
to
stay
broad
and
not
like
force
you
into
a
conversation
when
you
get
your
great
ideas
more
broadly
about
how
you
think,
we
should
scare
how
we
should
do
engineering
and-
and
hopefully
we
can
take
all
that
feedback
and
inform
victory
and
the
next
step,
but
yeah
I
wanted
to
take
that
purposely
paint
a
really
broad
picture
and
invite
you
to
pick
and
choose
whatever
area
that
you
want
to.
Okay,
talk
about:
okay,
yeah.
B
So,
let's,
let's,
let's,
let's
back
up
here
and
kind
of
start
at
the
high
level
and
then
I
can
kind
of
get
in,
maybe
specifics
here
in
a
few
minutes,
so
when
I
think
about
value
stream,
what
I
actually
think
about
is
is
I,
don't
think
about
cycle
time.
What
I
think
about
is
is
how
fast
is
it
from
when
something
is
produced
to
win?
Customer
adoption
is
right
so
like
what's,
the
real
value
is
not
is
not
in
just
pushing
out
features
the
real
values
and
customers
actually
using
the
features
right.
B
Though,
if
you
said
to
me
that
value
stream
is
about
cycle
time,
I
could
I'll
just
have
to
change
my
mental
model
but
like
when
I
was
looking
at
this
originally
I
said.
Well,
really,
you
know,
is
this
more
about
adoption,
or
is
this
more
about?
You
know
how
fast
we
can
go
feature
out
the
door.
It's
really
tricky
because
we're
in
theory
building
a
general-purpose
system
where
people
can
create
their
own
workflows,
associate
with
things
and
because
of
that,
it's
you
know.
You
have
this
model.
B
Cross
teams,
so
you
know,
team
team
has
a
workflow
that
they're
working
another
team
has
a
different
workflow.
Another
team
has
a
different
workflow
and
some
of
its
you
know
this
is
gonna
sound
crazy,
but
some
of
its
you
know
you
end
to
the
point
of
what's
in,
could
review
versus
just
saying
you
know,
here's
a
whole
bunch
of
stuff,
and
then
it
goes
to
done
right
know.
What's
in
code
review
versus
what's
in
test
versus,
you
know
that
aspect
of
it
and
some
of
this
actually
may
be
dictated
by
the
business
right
so
like.
B
One
thing
that
we've
seen
with
our
metrics,
so
we've
been
looking
at
the
past
couple
months,
is
our
merge
request
and
the
past
six
months
have
gone
up
as
far
as
the
e
fifth
percentile.
So
if
you
look
at
the
average
average
hasn't
gone
up
a
lot,
but
even
percentile
is
like
gone
up
from
like
that.
What.
B
A
time
time
times
the
time
time
to
merge,
so
this
is
from
when
the
merger
quest
was
created
to
when
it
was
merged
at
so
like
those
times
and
like
if
you
look
at
those
times
between
those
which
will
see
as
us
go
from
under
ten
days,
I
think
was
like
eight
or
six
or
eight,
or
something
like
that.
So
over
14
and,
like
you
know,
like.
B
A
B
B
It
is
right
so
like
120,
these
are
suppresses,
so
then
the
question
becomes
is
what
are
we
doing?
You
know
what's
causing.
That
is
because
reviews
is
because
you
know
our
testing
infrastructures
really
broken,
we're
like
a
lot
of
build
and
that
generally,
what
happens
is
that
most
organizations,
what
they'll
do
is
they'll,
say:
okay,
what's
really
slowing
us
down
and
in
what
generally
we
try
to
do
as
developers
we
say
well
we'll
go
to
assess
the
developers,
and
that
is
the
that
is
a
option,
but
it's
not
the
preferred
option.
B
The
reason
why
it's
not
perforation
is
because
I
hate
to
say
this
way
and
I'm
guilty
of
this
as
well.
You
talk
to
a
developer
about
our
software
engineer
about
what
the
problem
is
that
Slone
them
down.
They
will
pick
on
whatever
pet
peeve
issue
that
drunk
crazy.
You
know
like
like,
like
our
code
reviews,
are
too
stringent
around
our
style
coding.
You
know
which
meanwhile,
like
the
builds,
are
failing
50%
of
the
time,
and
that's
really
what's
slowing
things
down
right.
You
know
it's
like
you
know
those.
B
Those
are
the
kinds
of
things
that
you
have
to
really
look
at
the
data,
especially
when
you're
talking
about
programming.
You
know
an
organization
of
say,
20,
people
and
and
say:
okay,
what's
really
slowing
things
down
and
then
how
do
we
basically
effectively?
You
know
push
push
it
from
a
perspective
of
you
know:
how
do
we?
How
do
we
adjust
what
what
projects
we
put
in
place?
B
So,
when
I
look
at
this,
if
we're
talking
about
cycle
time,
that's
that's
kind
of
like
I'd
love
to
say:
okay,
we're
gonna,
make
a
workflow
everybody's
gonna
use
that
workflow,
but
I
just
I've.
Seen
too
many
groups
like,
even
if
you,
even
if
you
give
four
teams
the
option
of
okay,
create
your
workflow
they'll
come
over
for
different
workflows,
it's
just
it's
just
the
nature
of
people.
I
guess
is
maybe
the
right
way
to
put
it,
and
you
know
you
can
force
that
as
an
organization.
B
But
then
you
know
the
perception
is:
is
that
you're
putting
too
much
rigidity
in
the
system
right
from
that
perspective?
So
the
other
thing
to
note
here
is
is
that
you
were
talking
about
velocity
over
over
predictability.
So
estimation
I,
think.
If,
yes,
if
you
asked
around
I,
think
what
you'll
get
is
feedback,
because
is
that
the
main
reason
why
we
chose
velocity
over
predictability
is
because
we
didn't
want
to
have
to
ask
me:
why
don't
we
want
to
estimate?
B
Because
estimation
is
hard,
it
takes
a
lot
of
time
and
it's
problematic
and,
more
importantly,
we
don't
have
data
that
helps
us
with
that
estimation.
At
this
point,
if
we
put
the
right
things
in
place
to
actually
start
measuring
this
stuff,
we
may
actually
find
we
may
actually
find
a
way
to
to
do
that
without
having
to
maybe
maybe
be
as
laborious
as
as
people
think.
It
is
ironically
enough.
We
put
that
in
our
document
and
then
a
lot
of
engineering
managers
are
still
doing
some
level
of
estimations
right.
B
So,
like
there's
a
little
bit
of
there's
a
little
bit
of
given
takes
here,
that's
happening
associate
with
it,
so
that
leads
to
the
other
point
I
wanna
make,
which
is
you
know,
we're
talking
about
cycle
time,
we're
making
things
smaller,
but
the
other
thing
to
look
at
with
VSM.
This
is
you
know,
like
complexity.
You've
changed
right
so
like
as
you
go
through
in
theory,
they're
suppose
to
get
smaller,
are
they
actually
getting
smaller,
or
are
they
actually
getting
bigger?
A
B
B
A
B
You
know
just
dumped
in
a
database
and
think
of
it,
as
you
know,
much
like
we
do
with
our
other
API
statistics
and
those
kinds
of
things
where
we
basically
provide
that
information.
It's
the
same
model,
it's
just
the
the
numbers
are
probably
smaller.
What
can
I
just
want?
This
kicked
out
of
the
samples
you
get?
Does
it
help
urge
that
it.
A
B
By
the
way,
it's
extremely
relevant,
if
you
want
to,
if
you
want
to
team,
to
move
fast,
this
is
a
type
of
information
that,
like
okay,
like
if
you
want
to.
If
you
want
to
seem
to
move
fast,
and
you
want
like
the
one
more
one
question
that
I
asked
people
in
my
interviews
is,
is
how
do
you
know
a
team
is
performing
well
right.
I
get
the
answer.
Well,
everybody's
kind
of
happy
all
our
objectives.
B
A
A
The
first
one
is
what
is
sort
of
been
assumed
which
to
me
is
not
that
exciting
and
I
think
we
have
to
build,
but
is
the
one
that
I'm
worried
about,
which
is
we
have
the
concept
of
a
workflow
and
then
you
show
the
stage
times
and
then
you
showed
them
also
the
end-to-end
time,
and
so
you
can
say
you
know
if
we
were
to
have
QA
be
a
stage
and
then
you
can
see
QA
is
the
bottleneck.
Then
you
would
focus
on
that.
A
So
that's
sort
of
the
really
obvious
one
which
I
don't
like
precisely
of
the
because
of
the
things
you
were
saying
is
that
so
many
caveats,
but
it's
almost
like
we're
almost
forced
to
build
that,
because
there
is
some
value
and
there's
a
good
story
in
get.
There
will
be
some
customers,
so
so
I
almost
want
to
not
do
that
right
now,
with
the
event
one
which
is
really
interesting.
Is
that
precisely
was
thinking
about
events
last
week
I'm,
so
it's
great
that
I
didn't
bring
it
up,
and
then
you
talked
about
it
too.
A
So
that's
that's
like
a
checkbox,
it's
something
that
that
verifies
that
my
crazy,
which
is
what
I
see
the
plan
team
or
any
other
team
at
your
lab.
They're,
not
using
workflows
like
in
these
stages
and
things
are
just
being
merged.
So
so
there
are
stages
or
there
are
perhaps
goalposts
events
that
just
happen,
which
is
issue
is
open,
may
be
issue
gets
assigned
to
somebody
issue
is
merged,
I
mean
it's
eventually
deployed
for
us,
I
get
lab.
You
know
it's
deployed
to
the
Ortz
moritz
bridge,
the
the
dot.
A
Zero
release
branch
is
an
event
as
well.
I
mean
there's.
Maybe
like
our
season.
You
can.
Those
are
the
events
as
well,
but
there's
other
interesting
events
that
I
think
you
are
talking
about,
which
is
as
a
business.
Stakeholder
Victor
I
will
go
into
the
issue
and
or
merger
quest
and
participate.
Am
I
doing
a
lot
that,
at
the
beginning,
during
the
process
to
work
the
end
as
a
QA
stakeholders
same
as
a
security
stakeholder?
A
You
mentioned,
like
a
health
industry,
there's
going
to
be
a
lot
of
compliance
stakeholders
along
the
way,
and
so
good
luck
can
we
can
actual
track
those
events
relatively
easily,
whether
we
it's
gonna
be
assignee,
whether
it's
gonna
be
label
or
just
the
simple
back
that
Victor
just
had
some
comments.
You
know
early
on
and
later
on
and
that
so
my
feature
concept
is
you.
You
essentially
get
some
level
of
statistics
and
do
a
correlation
I
mean
it
could
be
very
easy
as
a
first
pass,
or
it
could
be
very
sexy
as,
like.
A
You
know
your
business
stakeholder
what
you
care
about,
because
you're
configuring
it
this
is
the
PM
they
participate,
often
at
the
beginning,
in
the
middle
on
the
end,
and
then
you
correlate
that
with
something
else,
maybe
like
the
merge,
the
time
to
merge,
or
maybe
some
other
metric
and
you
surface
that
to
a
team
and
then
they
take
that
away,
and
then
they
can
action
on
that
so
I'm,
seeing
a
lot
of
nodding.
So
is
that
the
type
of
feature
that
you
think
a
team
would
use
at
your
lab
or
that.
B
Is
definitely
the
type
of
feature
that
would
cause
a
team
to
evaluate
you
know
what's
going
on
in
a
given
situation,
the
question
would
be
is,
is
do
you
have
a
high
level
metrics
that
point
them
in
certain
direction,
because
there's
just
so
much
information
that
it's
hard
to
you
know.
So,
that's
why,
when
you
said
originally,
you
know
the
staging
timing.
B
But
if,
if
you
go
look
at
our
process,
my
guess
is
that
you
know
time
to
release
it's
going
to
be
very
fixed
in
regards
to
the
fact
that
most
people
are
driving
towards
code
freeze,
and
then
you
know
release
later
so.
Consequently,
you're
gonna
see
this
Delta.
That's
not
going
to
be
that
interesting
and
you
can't
really
change
that.
So,
like
you
know
from
when
feature,
is
conceptually
decided
to
when
we're
not
constantly,
but
when
features
actually
started
to
be
engaged
on,
working
on
to
release
is
going
to
be
somewhat
within
a
certain
boundaries.
B
Just
because
there's
an
arbitrary
are
terminus,
but
the
the
Delta's
we
already
have
built
into
the
system.
Sure
continuous
delivery
system
completely
different
story
like
that's,
that's
where
you
would
be
in
a
situation
where,
like
you
know
in
theory,
when
I
hit
the
merge
requests,
merge,
you
know,
there's
some
amount
of
machinery
that's
happening
and
I
may
want
to
optimize
for
that
right.
So,
like
that's,
that's
that's
probably.
B
One
of
the
questions
I
asked
in
the
back
of
my
head
is
this:
can
you
kind
of
predict
how
your
team's
gonna
do
you
know
next
month
and
if
you
know
the
answer
is
as
well,
we'll
just
have
to
wait
and
see
what
feature
requests
good.
You
know.
That's
not
necessarily
thinking
about
it
in
the
same
way
that
you
know
right
from
the
research.
Oh
yeah,
so
I
think
that
resonates
and
I
think
the
event
idea
is
is
the
right
way
to
go,
because
it's
gonna
have
to
be
somewhat
generic.
Just
be
right
right.
A
Yeah
yeah,
no,
no,
that
that
was
one
of
my
struggles
as
as
just
as
a
designer
of
the
product
like
what
you've
seen
cycle
analytics
by
now,
you've
seen
maybe
you've
seen
conversational
development,
or
maybe
you
haven't
seen
it
because
we
don't
really
use
it
and
that's
why
they're
not
great
features
of
gitlab
and
the
problem.
There
is
the
non
customized
ability
or
the
non
generalization
of
it.
A
You
just
document
fact
that
the
business
owner
went
into
the
QA
environment
and
had
a
comment
and
not
some
feedback
and
that
that's
an
event
that
you
can
track
him
and
index
on
later
and
from
statistical
point
of
view,
so
I
think
that's
very
powerful
and
to
me
that's
a
lot
more
generic
tracking
events,
because
there
it's
just
it's
a
role
and
they're,
taking
an
action
in
the
system
and
that's
easily
captured,
and
you
can
surface
that
and
that
can
be.
You
can
surface
that
information.
So
to
me,
that's
what
I'm
really
liking
the
about.
B
The
other
thing
that
I
think
is
important
to
note
here
is:
is
we've
been
talking
about
this
more
generically?
You're
gonna
have
two
tiers
of
this,
and
this
is
probably
where
I
have
some
strong
opinions.
I,
don't
I,
don't
know
if
I'm
necessarily
validating
them,
but
it's
just
been
what
my
experience
has
been
so
an
EM
are
when
you
create
an
M
R,
it
should
be
drive
to
merge
as
quickly
as
possible.
So
it's
pretty
easy
to
measure
from
creation
to
finish
right.
A
B
B
A
Well,
yeah
that
that
yeah
I
come
in
for
30
more
seconds
and
let
you
have
the
last
word
because
I
do
have
to
jump
in
a
minute,
but
that
comes
by
loops
all
the
way.
Back
to
your
very
first
poem,
which
is
like
what
we
you
asked
me
like:
the
SM
Victor.
What
does
that
mean
like
cycle
time
and
stuff
like
that?
So
one
of
our
party,
marketing
managers,
John
Jeremiah,
has
been
really
has
been
reminding
me
what
the
SM
should
be
about.
A
Is
he
didn't
focus
on
delivering
to
the
customer,
but
I'm
sure
that's
in
his
brain,
but
he's
focusing
on
when
the
customer
requested
it
there's
some
additional
time
that
before
the
team
actually
actions
on
it,
but
there's
so
much
great
there,
because
whether
you're
in
a
consulting
industry,
whether
you're
in
the
like
custom
development
or
a
good
lab,
where
we
just
have
crazy
ideas,
all
the
time
so
like?
How
do
you
quantify
that?
How
do
you
capture
that?
Do
you
so
from
a
product
perspective?
A
I
I
just
want
to
like
ignore
that
for
now
and
like
our
MVC
is
just
focus
on
engineering
excellence,
because
that's
well-defined
it
for
a
features
perspective
that
you
can
define
that
pretty
well,
because
you
know
you
agreed
to
do
it
and
this
friend
I
started
well,
would
take
that
started.
You
know
maybe
deploy
maybe
even
merge
is,
is
good
enough
as
a
first
MVC
so
but
but
I
didn't
really
think
about
going
to
the
customer.
A
B
Cool
so
good
conversation
you
gotta
go.
What's
do
we
have
next
steps,
or
is
this
like
a
continuing
conversation?
This.
A
Is
a
continuing
conversation.
This
is
super
helpful
for
myself,
because
I
really
Oh,
like
the
the
team,
olive
good
lab,
essentially
a
clear
vision
for
DSM,
which
I
we
have
one
I,
don't
like
it,
I'm
just
really
annoyed
on
myself.
So
this
conversation
is
super
helpful
for
me.
So
right
now,
I'm
leaning
towards
we
have
like
two
big
feature
areas.
One
is
the
event
driven.
So
the
next
step
is
for
me
to
really
carve
out
some
specifics
and
then
throw
that
one
specifically
at
yourself
and
the
entire
engineering
department.