►
From YouTube: Plan group weekly meeting
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
Yeah,
so
I
wanted
to
share
that
we
have
metrics
I
shared
this
on
chat
earlier,
I
think
last
week.
So,
if
you
click
on
the
first
link,
you
will
see
how
long
our
child
epics
are,
and
so
we
have
data
from
pretty
much
one
release
ago.
So
that's
why
I
didn't
put
it
into
a
chart
because
it
wouldn't
look
very.
A
It
would
actually
look
more
confusing,
but
you
can
see,
for
example,
in
that
link
in
them
all
the
way
to
the
bottom
left
of
that
dashboard
there's
a
table,
and
so
you
can
see
in
January
those
are
counts
and
then
in
February
we
have
counts
and
what
those
counts
are
are
how
we
look
at
this
usage
pic
data.
Every
time
we
get
a
usage
ping
from
any
instance.
It
will
give
us
a
number
for
the
specific
metric.
A
It
will
either
give
us
no,
which
is
all
the
way
to
the
right
and
do
we
have
liquor
credentials.
Yes,
so
if
you
so
what
I'll
actually
do
so?
Actually,
people
can
see
this
I'll
actually
screenshot
this
right
now.
But
if
you
click
on
the
second
link
there
there
is,
there
is
a
coup
shot.
There
is
instructions
on
how
to
get
get
access.
A
Thank
thanks
for
reminding
me
of
that
crucial.
Thank
you.
So
I'll
just
put
a
screenshot
of
what
I'm
talking
through
right
now
in
the
agenda.
So
if
you
look
at
all
the
way
to
the
rites,
there's
some
null
things,
but
basically
I
double-checked
and
Shawn.
You
can
correct
me
if
I
got
this
wrong,
but
for
seee
instances
they
do
not
send
in
a
number
for
this
particular
metric,
which
is
called
like
deepest
epoch
tree
or
something
yeah.
A
Okay,
thank
you,
Shawn
and
so
we're
definitely
not
getting
any
data
there
for
EE
instances.
We
are
getting
data
and
then
for
e
instances
that
are
not
ultimate.
They
shouldn't
be
using.
They
shouldn't
be
using
epics
anyways
right.
So
then
that's
why
you're
going
to
have
a
bunch
of
nulls
and
I
and
I
think.
The
reason
we
don't
have
is
I
believe
there's
a
bug
which
is
I
believe
we're
sending
one
so
I
already
logged
a
bug
to
to
get
that.
A
Rest
I
should
have
linked
it
here,
but
that's
that's
sort
of
just
breaking
down
why
you
there's
some
of
that
weird
data
there
in
particular
as
well,
for
every
single
instance
we're
not
sending
and
how
many
we
are
sending,
how
many
epochs
they
are.
So
that's
in
a
different
you
know
chart,
but
we're
sending
them
one
number
and
that's
the
longest
epoch
tree
they
have
for
that
particular
instance.
A
So
if,
in
their
entire
instance,
you
have
one
five
lengths
tree,
then
we're
gonna
send
in
number
five,
even
though
maybe
all
your
epochs
are
one
so
we're
just
looking
at
the
max,
and
we
I
mean
I
thought
about
this.
A
lot
and
it's
it
would
be
crazy
to
try
to
send
even
more
data,
and
we
just
want
to
start
with
this
course
data.
So
but
anyways.
A
What
you
see
is
in
the
month
of
January
in
February
we
got
that
many
usage
pings
of
people
sending
in
whether
they're
1,
2,
3
or
5
and
then
so
sort
of
not
surprisingly,
most
of
them
are
one.
You
know
you
have
some
twos
and
then
you
have
barely
have
any
3s
and
you
have
a
five
and
then
so
nobody's
using
five
except
Caleb
comm
right
so
again
that
that's
pretty
much
expected
and
everybody
is
doing
for
the
Rocchi.
Like
so
far
exactly
one
two
three
there's.
C
B
A
Is
exactly
that
idea,
even
though,
is
that
that's
that's
crazy,
but
yeah,
so
that
that's
that's
it'll,
be
interesting
to
keep
looking
at
that
particular
metric
over
the
next
couple
of
months
and
and
so
forth,
and
since
we
get
this
data
as
refresh
every
week.
So
if
you
actually
click
on
the
link
now
it
will
it's
still
the
same,
so
it
might
change
over
time,
so
I
feel
free
to
keep
track
of
that.
Since.
C
A
B
B
A
We
have
plenty
of
really
dirty
data
and
then
also
this
data
specifically
is
coming
from
post
ETL
jobs
of
everything,
so
I
again,
I,
don't
think
that's
daily,
but
I'd
have
to
check.
So
if
you
look
at
all
the
way
at
the
source
data
for
sure
it's
like
every
Sunday,
like
Sean
said
you
should
see
a
bump,
but
the
these
dashboards
I
would
have
to
go
double-check
and
see
when
they're
being
refreshed
because
they're
being
fed
from
additional
one
at
least
one
additional
stage
of
data
transformation.
C
We
do
Victor
sure
I'm,
just
I
stumbled
on
this
earlier
today
doing
I
was
looking
for
something
else
in
looker
and
I
found
this
I
love
it
that's
in
your
agenda.
This
is
absolutely
beautiful
and
brilliant.
Thank
you
for
doing
it
I.
Hopefully,
your
peers
are
real
kind
of
follows
along
and
I'm
already
thinking
about
the
counts,
of
instance.
By
features
is
just
awesome.
Thank
you.
Yeah.
A
A
Definitely,
and
what's
what's
interesting
for
this
pod,
some
more
color
here
is:
we
do
when
we've
done
usage
ping,
like
the
word
literally,
is
usage
and
all
we've
done
since,
like
maybe
three
years
ago
already,
when
we
started
introducing
and
maybe
like
three
and
a
half
years
ago,
we've
always
just
counted
objects
in
the
database
and
and
in
the
past
year.
So
we've
we
finally
realized.
We
need
to
do
something
a
little
bit
better,
we've
toyed
with
know.
Are
we
going
to
snap
shot?
A
A
Is
it
going
to
be
technically
possible
and,
and
so
just
counting
objects
counts
at
first
I
thought
that
was
that
didn't
seem
really
smart
but
like
and
now
I
think
it
makes
sense,
because
it's
it's
something
to
start
with,
it's
really
coarse,
but
we
got
to
start
somewhere
and
we
have
that,
and
so
what's
interesting
the
past
year
is
we.
We
we've
started
to
have
data
to
do
marking
stuff
as
active
or
no
that
that's
from
the
day.
A
How
do
you
measure
like
this
length
of
tree
right,
and
so
we
thought
a
lot
I
mean
we
didn't
think
a
lot
about
it
and
we
just
took
a
stab
it
in
dark
and
like
just
just
send
this
like
max
number,
and
you
know
like
you,
could
think
of
like
amazing.
We
can
send
all
the
numbers,
you
can
send
every
single
number
you
can
calculate
like
a
percentile
and
then
have
the
have
the
instance
and
a
percentile
and
I
thought
that
was
like
too
crazy.
So
that's
that's.
What
we're
doing
here?
Well,.
A
C
How
you'd,
actually,
here,
what
I
love
about
it,
but
whatever
the
the
things
I
love
about
this
just
so
we
can
all
see
it.
When
I
saw
this
the
instances
using
ethics
tells
us
about
people
who
adopted
or
using
premium
instances
using
JIRA
integration.
We're
anticipating.
You
know
a
campaign
where
we
look
at.
How
do
we
compete
head-to-head
with
JIRA
we're
actively
looking
at
that,
and
so
that
data
is
incredibly
useful,
Service
Desk
I
mean
this
is
just
so
helpful
and,
frankly,
I
think
the
instance
is
using
assignee
lists
and
milestone.
C
Lists
is
something
that
Victor
and
I
need
to
blog
about
it
right
about,
because
it's
been
nobody's
doing
it
so
I,
don't
know
this
is
awesome
and
I'll
be
taking
more
time
during
this
offline,
but
I
just
wanted.
Since
it
came
up
on
this
meeting.
I
don't
want
to
hijack
it
with
this
lovefest
on
this
board,
but
yeah.
C
Need
to
publish
it
because
there's
only
a
hundred
instances
or
120
130
instances
using
a
sign
list
and
milestone
list
yep,
you
know
the
usage
of
Service
Desk
is
interesting.
You
know,
I've
talked
about
that
JIRA
integration
fascinating
data-
this
is
this
is
fantastic,
so
I
thought
out
of
my
chair
when
I
saw
it
this
morning
and
immediately
asked
for
access
to
become
an
explorer
and
looker.
So
I
can
start
to
build
some
more
stuff.
That's.
A
Awesome
John
and
if
you
asked
you
can
become
a
developer
too
and
so
another
that
that
I
found
helpful
here
is
I've
been
telling
the
other
product
managers
that
you
don't
have
to
wait
for
the
date,
because
the
data
team
at
git
lab
right
now,
just
especially
for
new
folks
who
are
joining
I'm
just
for
information.
We're
we're
I
think
the
plan
is
to
get
more,
not
more
just
have
an
embedded
product
data
person
per
whatever
like
whether
it's
per
group
or
per
stage.
Usually
we
keep
changing
this
taxonomy,
but
anyways.
A
So
if
I
said
to
say,
like
data
folks
are
not
product
focus
right
now
and
I
think
they
report
to
even
like
finance
right
now.
Technically
so
folks,
like
Taylor
who's,
been
here
for
a
long
time
Emily.
You
know
that
that
team
there
they
report
to
finance
and
but
they
set
up
this
amazing
infrastructure
that
product
gets
to
play
with.
So
one
things
that
I
found
really
useful
is
that
lookers
pretty
easy
to
learn,
and
so,
when
the
development
team,
the
planned
development
team
is
able
to
get
this
user
screen
into
our
database.
A
It
takes
essentially
just
to
murder
quests
to
have
it
show
up
on
looker.
One
of
them
is
to
update
the
ETL
jobs,
and
then
one
of
them
is
update
the
looker
ml
files
and
that's
pretty
easy
to
learn
because
there's
examples
already
and
if
you
ask
the
data
team
to
do
it,
it
might
take
a
little
while
for
them
to
do
it
because
they're
doing
finance
work
as
appropriate,
but
they'll
always
review
your
code
because
everybody
can
contribute
so
I
found
a
lot
of
success
there.
A
So
so
what
I'll
do
is
talk
about
really
quickly,
product
categories,
prioritization
and
strategy,
so
the
plan
area-
that's
a
neutral
word
of
gitlab-
is
a
stage
in
the
DevOps
lifecycle,
as
Gil
lab
defines
it,
and
we
have
many
stages
and
plan
is
one
of
them
and
we've
done
a
lot
of
iterations
in
the
past
month
or
two
to
hammer
out
what
the
product
categories
are.
I
mean
the
reason
we're
doing
that
is
not
just
to,
for
you
know,
organizations
sake
it's
not
just
for
you
know
it
all.
A
Those
are
important,
but
there's
additional
reasons
so
from
from
the
from
the
internal
reason
or
from
the
organization,
organizing
company
reason,
it
helps
us
grow
the
organization,
because
we
have
plans
for
additional
headcount
we
have
to,
but
we
have
to
tell
like
our
investors
and
people
who
pay
the
checks.
Like
you
know,
we
plan
to
have
this
additional
head
count
to
do
this
job
and
so
on
and
so
forth.
A
So
it
aids
in
that
it
needs
in
hiring
to
tell
people
specifically
we
like,
when
we're
hiring
for
engineers,
program,
managers,
program,
markers
or
whoever
that
you
know
this
is
a
specific
area,
we're
looking
to
grow
and
so
on
and
so
forth.
So
being
a
transparent
company
is
actually
pretty
easy
because
you
just
do
this
once
and
then
you
don't
have
to
really
consider
the
ramifications
almost
or
like
you
like,
I'll,
write,
something
and
then
I'll,
just
like
ping,
John
and
say
like.
Oh
can
you
please
have
like
a
review
of
this,
like
that?
A
I
didn't
royally
screw
up
something
for
a
marketing
perspective
and
most
of
the
time
that
most
he
needs
to
tweak
a
little
bit
something
small.
And
so
that's
just
a
sidebar
note
about
you
know
us
being
transparent.
We
just
write
something
down,
that's
true
and
factual,
and
then
you
know
the
communication.
Just
out
grows
from
it,
and
so
we
have
three
product
categories
and
those
are
the
areas
that
we
want
to
move
forward
in
and
then
so.
A
For
example,
we
have
a
very
ambitious
maturity
model,
something
that
the
product
leadership
has
been
working
very
hard
on
iterating,
so
I'll
link
to
that
again
here
at
the
top
of
the
agenda,
as
you
can
see
there,
and
so
these
are
just
really
ambitious
goals.
So,
if
you
look
at
that
table,
you
can
see
those
are
telling
you
in
those
particular
categories.
A
We
want
to
be
in
those
places
by
those
timelines
and
then
so
you
see
that
we
have
minimal
viable,
completely
unlovable
and
we
have
you
know
definitions
of
those
at
the
top,
so
these
are
I.
Think
it's
supposed
to
be
tangible
to
the
point
that
it's
you
know,
there's
a
use
case
of
this
thing,
but
it's,
but
obviously
it's
not
not
to
the
detailed
feature
level,
for
example,
and
in
particular
these
are
very
ambitious
goals
that
take
into
account
of
future
growth
right.
A
We
have
a
future
growth
of
headcount
for
2019,
and
this
is
accounting
for
that.
So
if
we
were
to
do
nothing,
this
would
be
almost
impossible.
If
we
were
to
meet
our
hiring
goes
on
a
hundred
percent.
We
would
barely
scrape
by
and
barely
achieve
these
goals.
So
is
that
that's
like
the
level
of
ambition,
so
some
of
these
things
seem
like
ridiculous
right
now,
like
we'll.
Never
like,
we
barely
even
like
looked
at
these
things.
Yeah,
that's
that's
purposeful
and
in
particular
many
of
the
folks
on
this
call
myself
included.
A
We
might
not
even
be
looking
at
some
of
these
in
detail
right,
probably
John
well,
but
because
the
product
and
engineering
gift
will
probably
grow
a
little
bit
faster
than
say
product
marketing
in
2019
and
and
then
so
you
might
be
as
an
engineer
or
engineering
manager
or
a
product
manager.
You
might
be
focused
on
a
specific
category
before
the
year
is
out,
so
we're
a
fast-growing
company.
A
That
also
means
we're
quickly
changing
in
a
lot
of
our
things
internally,
so
do
do
look
out
for
that
and
then,
as
Eric
Johnson
always
says,
like
it's
a
good
problem
to
have
that
we
were
constantly
changing
so
that
that's
how
I
look
at
it
and
then
so,
jumping
back
to
product
categories.
Right
now
we
have
three.
We
have
team
planning,
enterprise
planning
and
certify
team
planning.
A
So
so
that's
how
we've
broken
those
things
out
and
so
enterprise
planning
is
really
focused
on
you
know
beyond
developers,
it's
going
to
be
the
business
analyst
and
product
managers,
the
engineering
managers
that
directors
the
executive
level.
Folks,
that's
our
breath,
plate
as
I
call
it,
and
then
certify
is
really
wrapping
up
the
rest,
and
we
really
haven't
made
a
lot
of
strides
in
there
except
service.
That's
we've
done
one
iteration
like
over
a
year
ago,
but
we
really
haven't
moved
forward
there
and
so
that
likely
will
be
moving
more
quickly.
A
Once
again,
we
expand
the
teams,
are
split
up
to
teams,
so
with
team
planning
we
have
Kanban
boards.
We
have
issue
boards
and
to
me
the
the
the
most
difficult
part
is
salient
part
of
team
planning.
For
us,
as
an
organization
is
you're
constantly
getting
bombarded
with
people
inside
key
elapsing.
I
want
this
feature.
I
need
this
feature
like.
Why
don't
you
have
this
feature
picture?
It's
ridiculous.
A
And
so
I
approach
when
I,
just
you
know
like
a
sign
or
whatever
you
hear
that
as
a
member
of
the
plan
team,
you
know
I
see
people
slacking
our
plan,
China
all
the
time
asking
about
things
and
I
love
when
you
folks
respond
right
away
and
give
context-
and
thank
you
for
for
that-
that
that's
super
helpful
and
then
I
love
it.
When
you
guys
say
like
you
know,
I
agree.
This
is
a
great
idea.
A
You
know,
Victor
will
have
more
context
and
when
it's
gonna
be
shipped
and
stuff
like
that,
so
you
know
you
can
send
them
a
link
to
the
Rome
app.
But
ultimately
you
know
I'm
responsible
for
scheduling
things
and
and
I
gladly
took
the
brunt
of
the
the
complaints
and
the
negative.
You
know
emotions
therein.
If
it's
you
know,
oh
it's
going
to
be
done
in
a
20-19.
Something
like
that.
A
A
It's
released
to
the
public,
so
so
that
type
of
workflow
that
that
is
obviously
the
future
right.
And
so,
when
I
as
a
product
team
and
developing
features
in
the
plan
area,
we
have
plenty
of
people
that
say
like
oh
I
need
to.
You
know,
do
some
moderate
folly,
type
thing
or
I
even
need
to
like
ramp
them.
Make
mix
prints
better
and
for
these
reasons,
and
so
on
so
forth.
A
So
as
a
team
and
if
you
click
on
strategy
later
you'll
see
that
we
have
to
be
really
careful
in
picking
the
features
that
we
develop
and
supporting
the
customers
in
the
right
way,
so
that
we
push
them
toward
the
future
and
but
we
don't
leave
them
behind
and
and
then
we
have
to
strike
that
balance.
So
team
planning
I
think
that's
the
hardest.
A
That's
the
the
risk
of
their
Enterprise
planning
is
definitely
the
future
and
it's
almost
it's
less
risky
in
the
sense
that
we
nothing
right
like
we
don't
have
any
basis
for
it,
and
so
we
have,
we
barely
have
any
customers
to
so
they
can,
you
know,
say:
I
need
XYZ,
so
so
we're
almost
able
to
be
a
little
bit
more
strategic
and
support
the
customers.
We
want
to,
of
course,
we'll
take
any
customer
we
can
get.
But,
for
example,
we've
partnered
with
you
know
a
bunch
of
strategic,
not
really
part.
A
When
I
say
partner,
I
don't
mean
like
there's
no
official
relationship.
I
just
mean
more
generally
how
we
partner
with
all
customers
again
lab.
We
take
calls
with
them.
Would
we
we
learned
their
needs?
They
did
raise
issues
and
so
on
and
so
forth,
and
so
it's
we're
really
focused
on
the
future
of
building
the
future
of
AD
report.
A
Folio
management
and
we
don't
really
are
not
we're
less
held
back
by
legacy,
use
cases,
legacy
existing
features
inside
the
product
and
we
can
focus
on
the
future
and
so
I
already
started
paying
folks
and
so
I
thought
portfolio
capacity
planning
is
next,
and
so
you
can
click
that
link
and
see
what
all
that
is
about,
but
basically
I
want
to
get
a
good
snapshot
of
what
is
beyond
epics
and
roadmaps
right.
So
we
have
this
work
breakdown
structure.
A
Obviously
it's
going
to
take
a
long
time
for
us
to
get
it
to
a
really
good
usable
place.
But
what
is
the
next
thing
beyond
that?
Is
it
going
to
be
like?
Are
we
going
to
be
able
to
allow
accountants
to
to
log
in
to
your
lab
and
and
put
dollars
and
cents
or
or
if
you
are
in
North,
America
or
or
pounds
and
pence,
I,
guess
I'm,
but
well
what
word
like?
What's
the
next
thing?
Is
it
gonna
be
financial
management?
Is
it
going
to
be
putting
like
our
o
eyes?
A
Is
it
going
to
be
quantifying
risk
isn't,
but
it
going
to
be
putting
a
lot
of
like
red
green
and
what
is
it
orange
inside
things?
And
so
it's
not
a
hundred
percent
clear
to
me
what
that
is,
so
that
thread
talks
about
what
is
the
next
big
area
and
so
I
reference.
A
discussion
I
had
maybe
like
half
a
year
ago,
asking
is:
are
we
supposed
to
be
working
on
work
breakdown
structure
and
the
clear
answer
was
yes,
we
need
to
work
on
work
breakdown
structure.
A
A
Excuse
me,
and
so
value
stream
management
is
also
a
big
thing
there.
It's
sometimes
it's
weird,
because
people
ask:
why
is
that
in
enterprise
planning?
Isn't
that
across
all
of
gitlab
and
the
way
I
see
it?
Is
that
we're
really
strategic
inside
plan?
So
in
the
future
it
might
actually
move
to
a
different
stage.
It's
not
clear,
but
right
now,
I
think
it
makes
sense
how
we
planned
it.
A
What
I'd
like
to
tell
people
is
that
we've
done
psycho
analytics
two
years
ago
and
so
we're
ahead
of
the
market
and
the
industry
and
how
companies
think
about
these
things.
We
already
knew
that
you
need
to
focus
on
in
cycle
time.
You
need
to
have
this
ability
in
other
stages,
you
need
to
understand
how
how
each
stage
progresses-
and
we
knew
about
these
things,
because
that
that
was
our
play
right.
That
is
our
play.
A
So
so
we
realized
this
that
it's
important
almost
by
not
by
accident,
but
like
we're
cheating
right,
because
if
we
believe
in
the
whole
thing
that,
of
course,
we
believe
in
individual
stages,
I,
don't
think
what
we
realized
was
that
it's
important
for
customization
for
enterprises,
customization
is
important.
I
think.
Maybe
we
over
indexed
on
the
you
know
not
not
doing
configuration
in
a
hospital
has
to
be
convention,
and
here
are
the
five
stages
that
that
we
present
to
you.
I
saw
I.
Think
we
over
indexed
on
that
and
then
think
about
customization
enough.
A
So
unfortunately
we're
behind
from
that
aspect
or
we're
not
behind.
But
if
we
don't
execute
in
2019
on
value
stream
management,
then
we
will
be
behind,
but
we
have
the
benefit
of
having
I
would
say,
done,
psycho
analytics
and
that
got
all
that
customer
feedback
and
learning
and
then
now
we
could
move
forward
and
why
plan
is
relevant
is
because
you
know
we
have
issue
boards.
A
We
have
issues,
love
that
makes
sense
within
plan
anyways,
but
but
we
have
to
figure
out
how
that
integrates
with
merger
quest
with
security
with
CIC
and
so
on
and
so
forth.
So
that's
why
value
stream
management
is
critical
for
for
gitlab,
I,
think
in
2019
and
then
Service
Desk
quality
management
requirements
management.
Those
are
things
that
just
have
been
for
a
variety
of
reasons
have
been
put
into
the
plan
stage
and
then
that
there
are
additional
growth
categories.
A
I
think
they
make
sense
because
they
are
just
crazy
ideas
outside
of
what
is
obvious,
that
the
market
needs
and
what
is
obvious
that
Gilliam
would
be
good
at
and
so
the
way
I
see
it
is
that
service
test
is
the
least
risky,
because
you
know
it's
a
clear
feature
set
and
we
can
do
it
and
then
we
can
leverage
our
own
users
to
to
test
it
and
use
it.
Quality
management
similar
because
we
have
we
have
a
team
to
test
the
Obree
of
quality
team
requirements.
Manages
is
the
highest
risk.
A
Category
I
think
an
ala
plan.
We
have
no
users
and
if
we
implement
requirements
management
we
have
to
figure
out
how
Gil
Abers
will
use
it.
We
like
it's
not
clear
to
me,
like
hunky
levers,
will
use
a
requirements
management.
Some
of
you
might
even
know
what
requirements
management
is
because
that's
such
an
old
concept,
some
in
the
waterfall
sword
realm.
A
Why
it's
relevant
is
that
we
have
a
lot
of
prospects
and
customers
in
in
certain
industries
where
they're
building,
not
just
software,
maybe
they're,
building
hardware,
maybe
they're,
building
like
bridges
and
then
there's
a
software
component
involved,
because
all
companies
of
the
future
aren't
going
to
build
software
so
they're
all
the
customers.
I've
talked
to
that
need
requirements,
management,
they're,
not
saying
I
only
do
requirements,
management
and
waterfall
and
I.
Don't
do
any
type
of
you
know,
agile,
scrum
thing:
it's
always
they
want
both.
A
So
to
me,
that's
a
good
sign
that
we're
not
serving
the
customers
of
the
of
the
past.
We
are
serving
customers
of
the
future,
but
there
is
this
market
there's
this
particular
industry,
where
they
need
certain
requirements,
more
rigorous
requirements
management,
because,
if
you're
building
a
bridge
or
a
spaceship-
and
you
make
a
decision
to
use
this
material,
you
cannot
change
that
decision
later
on
or
if
you
do
decide
to
change
that
decision,
then
you
have
to
track
that
and
manage
that
very
carefully.
A
B
Added
one
to
the
dock
and
I
just
realized
I
completely
missed
whether
you
answered
it.
Just
then
I.
B
So
you
mentioned
that
custom
fields
and
micro
stages,
but
on
to
value
stream
management.
So
my
question
was
I
thought
about
you.
Stream
management
was
about
sort
of
getting
that
data
out
of
stuff.
So,
like
is
that
right.
First
of
all
is
value
stream
management,
but
you
said
sort
of
earlier
about
the
thing
that
isn't
necessarily
just
planned,
but
about
getting
the
data
on,
like
you
know
how
you,
how
you
get
those
cycle
times
down,
is
that
right,
first
of
all,
a.
A
Good
question
and
for
the
for
the,
if
you
don't
mind,
sure
I'll
step
back
and
before
answering
a
question
for
the
benefit
of
the
audience
and
just
this
video
and
gives
I
mean
your
publisher,
obviously,
and
so
I'm
going
to
click
on
value
stream,
management
and
I'm
gonna
should
I,
quit
slack
does
not
quit
and
then
I'll
share
my
screen
and
then
so
value.
What
is
value
stream
management,
so
the
the
concept
with
value
stream
management
is
that
we
want
something
like
this
ultimately.
A
So
this
is
a
really
rough
draft
right,
but
the
idea
is
that
we
believe
you
know
I
believe
at
least
that
the
way
to
do
agile,
devops
in
the
future
of
creating
software
for
big
enterprises
is
shipping.
As
fast
as
you
can
that's
pretty
much.
The
answer
in
a
nutshell.
Obviously,
there's
more
nuance
to
that
and
the
background
is
I'm
not
pulling
that
out
of
my
behind,
like
with
no
data
or
anything,
it's
been
proven
by
Silicon,
Valley
style.
A
Tecton
said
this
is
the
way
to
the
future
and
where
we
are
positioned
as
an
organization
as
gitlab
is
that
we
need
to
go
after
the
market
for
the
rest
of
the
world.
That
will
make
this
transformation
right.
So
so
all
the
the
big
Silicon
Valley
tech
giants.
They
they
figure
this
out
this
science,
that
this
is
how
you
develop
software
that
develops
over
how
you
develop
products
in
a
fast
iterative
way
and
win
the
market
and
the
business.
A
If
you
think
about
it,
that's
actually
a
very
small
market
for
us
because
there's
like
a
handful
of
those
companies
right,
but
the
the
market
we're
going
after.
It
is
all
these
medium
and
large
enterprises
now
and
that
they
are
figuring
out
how
to
do
this
transformation
in
the
future,
and
we
have
to
go
after
that
market
because
that's
that's
we're
in
that
business,
and
so
that's
where
our
growth
is
and
so
we're
that's.
Why
I
said
like
these
are
the
businesses
in
future.
A
We
have
to
go
after
them
one
by
one
and
we
have
to
hold
their
hand
along
the
way
we
build
the
Builder
product
and
so
on
and
so
forth,
and
the
the
theory
or
the
thinking
here
is
that
you
know
any
sort
of
product
development
101
is
you
need
to
get
iterations
out
as
quickly
as
possible
right?
If
you
get
iterations
out
quickly
as
possible,
then
you
get
customer
feedback.
You
can
have
some
feedback,
a
customer
feedback.
A
That's
like
technical
feedback,
something
broke,
you
can
fix
it
right
away
and
or
mark
your
feedback
and
you
can
pivot
blah
blah
blah
and
so
getting
your
software
out
as
quickly
as
possible
is
the
key,
and
then
that
also
demands
small
iterations,
because
you
need
small
iterations
to
make
sure
things
go
quickly
and
if
things
are
small
and
iterations
are
small,
it
means
you're.
Metric
is
always
going
to
be
speed.
You're
metric
doesn't
have
to
be
in
the
in
the
in
the
theory
of
VSM.
At
least
you
don't
have
to
worry
about.
A
Did
my
conversions
go
up
by
50%?
Didn't
I,
you
know
than
I
did
I
just
tanked
my
conversions
that
are
there
more
signups.
Now
is
more
people
using
this
particular
set
of
features
instead
of
that
particular
set
of
features
all
those
metrics
are
relevant,
but
in
the
VSM
world
it
almost
doesn't
matter
because
we,
the
VSM,
purposely
extracts
away
those
things
and,
from
a
you
know,
building
a
tool
perspective
like
your
lab.
It's
also
a
good
thing,
because
we
less
things
to
track
right.
A
You
know,
for
example,
the
monitoring
group
is
starting
to
build
out
those
metrics
like
memory
increases
and
so
on
and
so
forth.
So
those
things
are
important
and
we'll
get
to
those,
but
from
a
DSM
perspective,
what
is
one
metric
that
we
can
use
for
all
teams
in
all
industries
that
is
comparable
for
you,
internally
in
organization,
across
teams
and
even
comparing
across
companies
within
your
industry
and
even
compare
across
industries,
and
that
number
is
time
and
not
in
fists
specifically
end-to-end
cycle
time.
A
So
how
long
does
it
take
from
your
software
from
your
idea
into
production?
So
if
you've
been
a
good
lab
for
a
while?
That
used
to
be
like
our
mantra
idea
to
production.
So
that's
why
I
keep
saying
we
knew
about
this
two
years
ago.
We've
just
you
know
we
just
haven't
executed
in
the
way
that
the
market
needs,
and
so
we
just
need
this
number
and
so
value
stream
mapping.
The
the
end
goal
is
to
reduce
this
number
as
as
as
small
as
possible,
and
what
value
stream
mapping
provides.
A
A
I
need
to
optimize
this
particular
stage,
because
it's
way
too
long
for
no
apparent
good
reason
or
we
need
to
hire
more
people
to
do
this,
we
need
to
use
more
technology
to
address
it.
So
value
stream
management
and
nutshell
is
two
points
recognizing
that
intense,
like
one
time,
needs
to
be
reduced,
and
that
is
the
metric
that
everybody
should
care
about
and
we
should
push
people
to
care
about
it
and
number
two
providing
the
framework
of
those
stages.
A
So
that's
visible,
which
stage
is
the
worst
and
allowing
you
to
optimize
and
improve
that
stage
so
that
that's
essentially
what
value
stream
management
is
is
from.
A
conceptual
point
is
really
simple
and
then
back
to
Shawn's
point.
We
need
workflow
stages
as
an
implementing
inflamation
design.
To
do
this
right
so
right
now
we
don't
have
these
customized
stages
inside
Gill
lab.
A
A
Our
current
designs
and
please
participate
on
issues
is
to
allow
teams
to
create
those
customized
stages
some
way
and
then
link
them
all
together
surface
that
the
metrics
again,
which
is
going
to
be
time
and
then
show
that
you
know
this
particular
stage
you
took
10.1
days
and
then
additional
granularity
that
we
want
to
produce
is
that
of
those
tempo
and
one
days.
Was
it
actually
useful
time
or
were
you
just
you
know,
sitting
on
your
behind
and
you
know
doing
something
else,
and
then
it
was
a
bottleneck
so
helping
customers
optimize.
A
That
is
the
name
of
the
game
for
value
stream
management,
and
that's
why
workflow
stages
in
particular
supports
that
as
important
and
so
that's
why
we
or
I
have
put
custom
workflow
per
group
as
part
of
the
value
stream
mapping
category
but
custom
fields.
I
have
not
and
that's
separate
and
if
I
put
that
somewhere
or
said
that
that's
incorrect.
B
A
Exactly
and
it's
the
way
the
reason
I
put
in
that
product
product
category
is
more
for
organizations
sake,
but
you
know
it's
like
yeah
like
like
the
vision
is
there
or
another
way
to
think
about.
It
is
we're
building
all
these
features
up
one
by
one,
but
with
what's
really
the
coherent
story
from
a
product
perspective
or
like
from
a
customer
making
their
business
more
awesome
perspective
right
like
ultimately
we're
not
shipping
features,
ultimately,
where
we
want
to
get
customers
we
want
to
improve.
B
B
B
A
A
A
That's
a
great
point:
I
would
I
would
say,
for
example,
certified
right
now.
I,
don't
see
well
certify
like
because
they're
so
like
separate,
like,
of
course,
we
would
put
them
in
a
higher
tier,
because
you
know
we
believe
that
they
belong
in
those
higher
tiers
and
then
we
can,
you
know,
get
value
from
them.
But
what's
interesting
is
the
community
member
just
said
like
I
want
to
work
on
quality
management.
A
I
haven't
seen
an
M
R
from
them
yet,
but
they
said
explicitly
that
I
need
this
to
be
in
C
and
I'm
like
okay,
great
that's
going
to
be
in
C.
So
if
you
look
at
her
stewardship
pages
and
all
those
things
like
it's
unlikely,
we
would
reject
that.
So
that's
sort
of
an
interesting
counter
example
for
enterprise
planning
and
team
planning.
I
could
see
a
lot
of
core
things
there
anyways
for
enterprise
planning.
Right
now
we
have
epics
and
well
no
actually
I.
Take
that
back.
B
So
just
you
know
it's
not
a
big
concern
for
me
right
now.
It
was
just
something
I
was
thinking
about,
and
then
I
was
thinking
about
the
other
back-end
team,
specifically
that
we
have
so
because
every
front-end
teams
working
on
open
source
code
because
our
front-end
is
open
source
just
because
that's
that's
easier
to
license
and
easier
to
manage.
B
A
B
Exactly
and
just
you
know,
people
on
those
teams
wouldn't
be
doing
zero.
Open-Source
work
anyway,
because
there's
maybe
a
bunch
of
stuff
that
needs
to
be
refactored
in
both
well,
you
might
just
pick
up
an
issue.
That's
like
you
know
applies
to
both
or
whatever
so
yeah.
We
can
move
on.
May
I.
Just
no
I,
don't
my
mind.
No.
A
You
know,
thank
you.
Thank
you,
bring
bringing
that
up
chart.
So
if
you
click
on
strategy
that
link
you
actually
see
a
lot
of
things,
I
just
said
are
actually
written
down
and
the
reason
I
said
all
those
things
is
because
I
wrote
this
like
two
days
ago,
and
it's
on
my
mind,
but
that
the
summary
of
the
strategy
is
we
have
to
go
for
the
consumers
and
customers
of
the
future.
A
We
cannot
compete
with
the
competitive
with
our
competition
now
because
we're
not
in
well
positioned
to
do
so,
and
it's
also
not
not
a
good
strategy,
because
if
you
compete
with
the
customers
now
and
then
you're
building
the
features
of
today
and
then
your
customers
go
through
this
digital
transformation.
That
I
just
described
all
the
features
that
we
have
are
no
longer
relevant.
So
to
me,
it's
a
matter
of
focusing
on
the
future.
How
do
we
bring
our
customers
along?
A
How
do
we
mitigate
the
risk
so
that
we
still
have
a
you
know
which
get
like?
Even
if
we
were
to
royally
screw
up?
You
know
Gil
lab
will
still
be
around,
but
you
know
like
how
do
we
retain
our
usage
and
customers
in
the
plan
area,
specifically
while
we
get
to
the
future
so
that
that's
how
I've
articulated
that
strategy
I
mean
it's
it's
not
in
the
handbook.