►
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
Hi,
my
name
is
Christopher
illa
faults,
I
am
senior
director
development
here
at
gate,
lab
and
I
am
with
said,
C
/
nd
our
CEO,
and
we're
going
to
talk
a
little
bit
of
what
it
means
to
be
iterative
thanks
for
taking
time
said,
I
really
appreciate
you
being
able
to
spend
some
time
with
me
on
this
topic.
Yeah.
Thank
you
for
organizing
this
sure
thing.
Let's
start
with,
what
did?
What
does
it
mean
to
be
additive?
I
live.
B
B
It
helps
with
coordination
and
feedback.
So
in
a
company
when,
especially
if
it's
getting
larger
one
of
the
hardest,
things
is
coordinating
with
the
other
people
in
the
company
and
getting
feedback
from
the
customers.
If
you
ship
something
it's
much
easier
for
everyone
to
kind
of
understand
what
you're
doing
and
to
respond
to
it.
So
if
I
have
a
project
and
I
want
to
go
I'm
planning
nine
months
out,
everyone
has
to
spend
a
lot
of
time.
Thinking
about
that,
there's
going
to
be
a
lot
of
back-and-forth.
B
If
the
plan
is
going
to
change
substantially
as
people
get
feedback,
it's
super
hard
to
know.
What
do
you
even
want
to
end
up
whether
you
even
can
end
up
there
and
then
I'm,
gonna
I'm,
not
gonna,
have
any
feedback
for
nine
months.
Instead,
if
I
take
a
step,
that's
only
a
week,
long
I'm,
my
colleagues
won't
even
care
what
I
do,
because
it's
gonna
be
such
a
small
step.
They
will
see
it
and
they
can
say
something
Dan
or
later
and
I'm
gonna
get
feedback
from
users.
B
The
hard
thing
is
like:
if
you
have
a
lot
of
sign
offs
and
other
considerations
you
do
have
to
ship.
So
I
like
you,
do
have
to
ship
it
in
a
month
and
they
do
another
month
and
do
it
on
a
month.
So
you
get
a
reduced
the
cycle
time
the
time
it
takes
you
to
between
deciding
to
do
it
and
getting
it
out
there.
If
you
can
reduce
that,
you
can
take
smaller
steps.
A
Very
cool
one
of
the
things
I
would
love
to
do
is
walk
you
through
an
example
where
we
thought
we
were
to
have
and
kind
of
get
your
thoughts
on
it.
I
feel
like
that's
a
good
way
to
kind
of
show
our
viewers
that
thought
process.
Are
you
up
for
that
yeah
for
sure?
Thank
you,
okay,
great
all
right.
So
what
I'm
gonna
do
is
I'm
gonna
share
my
screen
here
really
quick.
This
is
an
example
and
I'll
try
to
give
you
a
high-level
overview
of
this.
A
With
this
part
of
the
product
called
century,
one
of
the
things
that
would
be
great
to
do
is
be
able
to
create
an
issue
based
off
the
error
that
you
see
and
there's
a
description
here.
We
talked
about
the
problem
we're
trying
to
solve
intended
users
associated
with
this
and
further
details
in
particular,
what
I
want
to
talk
a
little
bit
about
is
kind
of
the
general
idea
here
or
the
design
associated
with
this.
A
So
as
an
example,
the
idea
here
is
obviously
create
an
issue
populate
with
information
associated
with
it
as
part
of
this
overall
epic.
Now
one
of
the
things
that
the
team
decided
to
do
as
a
first
step
is
just
simply
create
a
button
to
go,
create
an
issue.
So
in
this
particular
example,
the
button
is
just
creating
the
issue
and
it's
not
populating
with
any
information
which
is
actually
a
fairly
trivial
thing.
A
A
Seem
like
a
good
first
step.
It
seems
like
a
great
first
step
yeah
and
it's
important
to
note
here
that
there
no
back
end
work
to
be
done
with
this,
so
this
is
a
good
example
of
giving
the
customer
opportunity
to
see
it
up
front.
So
what
might
be
the
next
thing
we
might
look
at
to
do
as
a
step.
Well,
the
next
step,
which
actually
started
just
two
three
days
later,
was
just
just
pass.
The
information
and.
A
B
That's
a
great
step
and
I
know
that
I
think
you
can
populate
our
issues
from
the
URL,
so
this
is
pretty
easy
to
make
in
that
regard.
An
even
smaller
step
would
be
to
put
a
button
next
to
it,
the
create
issue
and
say
copy
information
to
clipboard,
and
you
press
the
create
issue.
You
have
to
paste
the
information
in
yourself
that
way
we
could
still
I
suppose
this
would
need
back-end
work.
You
could
do
still
do
it
without
any
backend
work.
B
A
A
good
observation
that
sometimes,
when
we're
moving
information
in
the
tool,
if
we're
not
ready
to
build
a
table
or
different
things,
copying
asking
the
customer
to
copy
to
to
a
clipboard
and
then
paste
it
in
is
a
great
way
to
kind
of
move
information.
So
it's
a
great
mechanism
that
we
need
to
be
thinking
about
leveraging,
particularly
what
we're
thinking
incremental
okay,
so
we've
gotten
to
that
point.
Next
thing
is
actually
passing
the
actual
information
in
a
stylized
form.
This
actually
didn't
have
them
too
much
later.
A
A
A
We
actually
started
the
backend,
which
is
actually
to
create
a
table
to
match
up
with
the
issues
that
we're
creating
based
on
this.
So
we
can
have
some
reference
around
this
to
basically
search
associated
with
this,
so
it
started
even
started
a
little
bit
later.
From
that
perspective
and
just
creating
the
table
took
a
few
more
days,
it
was
from
the
22nd
through
the
9th,
but
you
know
a
good
example
of
now
we're
actually
populating
data
that
the
reference
to
make
it
more
efficient
does.
B
A
A
One
of
one
of
my
observations
really-
and
it
was
a
good
exercise
for
me
to
kind
of
work
through-
was
the
you
know
the
aspect
of
being
able
to
start
front
and
work
even
before
back
and
work
actually,
even
as
done
obviously
we're
not
an
API
first
company
and
companies
that
work
on
that
fashion
would
obviously
think
in
terms
of
okay.
What's
the
database
going
to
look
like
those
those
kinds
of
things
associated
with
that?
Do
you
think
we
talked
about
this
much
or
there's
other
aspects?
A
B
My
what
I
would
add
is
that
I
love
front-end
first
I
love
interface,
first,
also
because
it
helps
everyone
think
about
it
like
if
you
have
something
in
the
interface,
it's
easier
to
understand,
for
customers
for
back-end
people
etc.
So,
in
the
end,
what
the
customer
sees
is
the
is
the
product
like
one
way
to
develop
is
start
with
the
readme
or
start
with
the
press,
release
I.
Think
they're
close
after
that.
B
A
A
A
great
thing
for
our
folks
to
kind
of
be
thinking
about,
as
as
they
are
on
this
journey
with
us
now
cool,
so
I'm
gonna
switch
gears
a
little
bit
and
talk
about
slightly
more
difficult
wine.
I
don't
have
broken
down
quite
as
crisply,
but
I'd
be
curious
to
also
walk
through
one,
that
I'll
start
at
the
top
and
I'll
just
kind
of
give
a
high
level.
So
so
this
one
issue
was
opened.
Two.
A
B
A
That's
a
good
observation,
because
that'll
actually
help
with
the
second
problem
they
had,
which
was
one
of
the
things
that
they
ended
up
doing,
was
giving
it
some
scope
around
it
as
far
as
a
number
projects
environments
by
instead
of
focusing
on
the
stylization
of
it
or
how
its
viewed
and
just
Junius
less.
While
those
could
be
ugly
and
not
look
very
good,
you
could
actually
have
unlimited
scope
there,
which
would
be
get
a
good
example
of
getting
feedback
from
customers.
Is
that
kind
of
your
thinking
there?
From
that
perspective,
yeah.
B
A
B
I'm
not
sure
it's
this
one,
but
I
think
what
also
happened
here
is
that
you
were
able
to
kind
of
find
I
know.
Add
things
to
this
dashboard.
That
was,
it
had
a
different
like
we
have
projects
and
they're
sorted
by
groups,
but
I
think
here
you
could
select
environments
across
many
groups
that
made
it
many
many
more
times
more
complex
because
it
didn't
fit
with
anything
stuff
like
that.
We
should
really
wait
until
we've
shipped
the
first
iteration
and
then
see
what
customers
ask
for
yeah.
B
A
A
B
So
you
see
this
is
scheduled.
You
think,
hey
I
might
not
be
able
to
finish
this
in
one
release,
so
you
go
back
to
the
project
manager
and
say:
hey.
Can
you
cannot
schedule
this
for
this
milestone
because
I
am
afraid,
I
cannot
do
it.
Please
select
something
else,
and
then
hopefully
the
product
manager
removes
it
from
the
milestone.
B
Add
something
else
because
we
always
have
enough
work
has
never
heard
of
like
our
project
managers,
don't
have
any
ideas
of
what
ship
and
then
you
can
take
some
time
with
check
manager
over
over
there
three
weeks
you
can
have
a
call
about
it
and
try
to
try
to
fix
it.
So,
instead
of
trying
to
fix
it
like
in
in
a
rush
just
say:
hey,
this
is
not
working,
it
gets
unscheduled
and
put
something
else.
That's
smaller
on
the
on
the
schedule
and
work
to
reduce
the
scope.
B
A
B
Maybe
we
should
be
more
explicit
about
this
because
we
always
say
product
managers
schedule
engineers,
time
which
I
think
is
super
important
to
have
it,
but
I
think
we
should
say
engineers
can
Phaedo
things.
Engineers
cannot
put
something
in
the
sprint,
but
they
can
veto
things
because
they're
too
large
yeah.
A
That's
a
good
observation:
I'll
have
to
go
back
and
check
how
we
word
that
in
the
handbook
and
see
if
there's
an
update,
we
can
do
there
around
that.
That's
it!
That's
the
appreciate
you
taking
the
time
to
talk
about
that
because
that's
that's
a
that's
a
that's
a
learning
for
me
to
think
about
as
well.
You.
B
A
A
B
B
A
B
A
A
I
want
to
change
gears
now,
a
little
bit
in
a
truly
inner
inner
of
environment.
One
of
the
things
I've
been
thinking
about
is
is
what
has
to
work
well
for
us
to
succeed,
I'm
extremely
logistical
in
my
mindset.
So
of
course
I'm
thinking
about
all
those
things
things
I
thought
about
is
you
know,
obviously,
good
customer
feedback
reasonable
release
cycles,
while
working
pipeline
of
testing
are
all
super
important,
particularly
as
we
get
our
armor
rates
up
to
2,000
3,000
and
4,000
M
hours
a
month,
but
are
there
other
things?
A
B
Think
it's
all
about
cycle
time.
So,
if
you
wanted,
if
your
cycle
time
is
long,
you
will
have
to
fit
more
work
in
there
because
otherwise,
you're
not
gonna
get
to
the
overall
velocity
you
want.
So
it's
just
a
function
of
cycle
time
and
cycle
time
is
like
how
many
permissions
do
you
need
if
you
need
the
database
team
to
sign
off
and
the
security
team
and
the
user
interface
team
and
the
templating
team
and
the
user
management
team
and
the
admin
interface
team
and
pajamas
team
that
does
our
UX
library
and
and
operational
team.
B
Just
saying
some
things
that
you
could
do
all
those
a
teams
need
to
sign
off,
plus
a
maintainer,
that's
overburdened.
That
needs
to
review
your
code.
Your
cycle
time
is
going
to
be
long,
so
you'll
have
to
fit
more
things
in
it.
So
it's
so
important
to
realize
that
for
all
those
teams
we
need
to
get
from
approvals
to
automated
mitigation.
Our
database
team
they're
doing
an
awesome
work.
Awesome,
work,
they're,
understaffed
and
they're
now
doing
code
reviews
where
they
sign
off
on
the
code.
B
We
should
go
to
something
where
your
migration
is
just
going
to
run
on
a
copy
of
the
production
database
and
if
it
doesn't
migrate
quickly,
then
you're
gonna.
You
can
hear
about
it
from
that
automation,
maintainer
if
they're
not
available,
and
maybe
we
should
accept
things
by
default-
that's
not
pretty,
but
it's
it's
better
like
we
should
never
slow
people
down
and
we've
taken
a
lot
of
care,
defining
our
categories
in
making
sure
that
there's
no
overlap.
We
don't
have
a
team
for
the
administrative
that
interface.
B
We
don't
have
a
team
for
the
project
setup,
there's
no,
there's
a
team
that
this
projects,
but
you
don't
need
our
sign
of
The
Pajama
seem
like
if
you
want
to
add
something
to
pyjamas.
You
can
just
do
that.
You
don't
have
to
wait
for
their
approval.
Their
mission
is
to
kind
of
continually
refactor
the
UX
library
and
make
it
better
not
to
kind
of
approve
any
additions
to
it.
So
our
mission
is,
everyone
can
contribute
that
needs
to
go
as
fast
as
possible.
People
should
be
allowed
to
change
things.
B
A
That's
also
a
great
observation.
One
of
the
things
that
I
know
that
we
debate
quite
frequently
internally
is
is
how
to
structure
teams
such
that
we
don't
have
a
bottlenecks
in
the
organization.
So
it's
really
important
that
we
continue.
That
and
I
want
to
make
sure
that
if
anybody
sees
that
happening,
they
they
talk
to
our
leaders
as
quickly
as
possible
about
it,
because
those
are
the
types
of
things
that
we
need
to
remove
quickly.
Yeah.
A
Cool
I
have
a
few
more
questions,
just
if
you
have
a
little
bit
more
time,
one
is
is,
is
kind
of
the
counter
to
this.
Are
there
any
situations
where
you
wouldn't
want
us
to
be
here
too
rough
I
can't
think
of
any,
but
I'd
be
curious
if
you
had
thought
of
any
cases
that
gosh
this
is
the
time
when
we
don't
want
that
to
happen.
Yeah.
B
So
there's
a
there's
things
that
are
kind
of
a
one-way
door
and
things
that
come
to
my
mind
is,
for
example,
a
reorganization.
If
we're
gonna
reorganize
the
company,
you
don't
want
look
on
Monday
I'm
moving
these
two
people
on
Tuesday
we're
moving
these
two
people
as
well
Oh
like
you're
laughing,
because
you
know
that
that's
gonna
create
a
hole.
You
want
to
be
clear
on
Monday.
You
want
to
say
this
is.
This
is
how
the
new
org
is
gonna.
B
Look
like
so
everyone's
on
there
there's
no
confusion
about
it,
and
people
don't
have
to
guess.
Another
thing
would
be
a
pricing
change.
You
can't
go
to
your
customers
and
yeah
we're
gonna
raise
the
price
by
two
percent
and
two
days
later,
we're
gonna
raise
the
price
for
two
percent.
In
addition,
and
like
first
of
all,
we're
not
it
and
I'm
not
saying
we're
raising
prices,
but,
like
you,
it's
a
one-way
door.
B
You
have
to
be
clear
about
what
you're
gonna
do
so
there's
some
things
that
don't
lend
themselves
iteration
I,
think
95%
of
things
do
lend
themselves
and
I
think
it's
what
we
maybe
not
use
enough.
It's
just
saying
hey
this
is
this
is
early.
This
is
alpha
or
beta,
for
example,
with.
If
you
just
give
an
ugly
list
of
the
environment
you
could
put
at
the
top
like
this
an
alpha
feature,
it's
gonna
be
ugly.
We
don't
expect
anything
else.
A
B
Maybe
I'll
detail
where
iteration
came
from
so
when
we
were
in
Y
Combinator,
we
were
in
a
peer
group
and
every
two
weeks
we
had
to
sit
down
and
say
what
we
achieved
over
the
last
two
weeks
and
what
we
were
gonna
do
and
the
second
time
we
had
that
meeting.
The
first
time
we
had
to
kind
of
report
on
what
we
did.
B
We
did
weigh
less
than
everyone
around
us
and
Dimitri
and
I
drove
home,
and
we
were
like
we
could
be
gonna
up
our
game,
so
we
told
like
we
gotta
go
faster
and
we
took
our
three-month
plan.
We
try
to
do
as
much
of
it
in
the
next
two
weeks
and
obviously
we
could
do
only
10
or
20%
of
the
effort,
but
we
got
we'd
learned
so
much
and
we
got
so
much
of
your
result.