►
From YouTube: MECC example iteration series: Fast Decisions
Description
MECC is a new management philosophy to speed up company progress by creating the environment for better decisions and improved execution of them. GitLab pioneered MECC and continues to steward its development.
MECC (Managing so Everyone Can Contribute): https://about.gitlab.com/handbook/mecc/
This call is focused on the third tenet, Fast Decisions: https://about.gitlab.com/handbook/mecc/fast-decisions/
A
Hey
all
this
is
two
of
four
in
our
ongoing
mech
iteration
sync
sid
is
joining
me
today.
We're
going
to
be
talking
about
fast
decisions
and
our
first
one,
which
is
also
on
gitlab
unfiltered.
We
went
over
informed
decisions
and
you
can
look
at
that.
One
see
where
it
was
and
the
new
changes
have
been
merged
into
production
on
that
page.
So
if
you're,
just
catching
up,
mac
stands
for
managing,
so
everyone
can
contribute.
A
So
this
is
a
management
philosophy
to
speed
up
company
progress
by
creating
the
environment
for
better
decisions
and
improved
execution
of
them.
Gitlab
pioneered
mech,
and
we
continue
to
steward
its
development
and
we're
using
these
sessions
to
provide
transparency
into
how
we're
iterating
on
it
and
building
towards
an
awesome
certification
that
we
hope
to
have
stood
up
soon
for
both
internal
team
members
and
the
wider
community.
So
with
that,
I
will
toss
it
over
to
sid
he'll
screen
share
the
fast
decisions.
B
B
I
think
well
relevant,
like
making
small
merge
requests
it
links
to
our
value.
So
again,
I
don't
think
it's
really
an
example.
That's,
let's
link
to
like
we
were
planning
to
do
x,
but
then,
after
y
we
changed
it
into
that.
For
example,
there's
I
think
five,
maybe
ten
recordings
of
iteration
office
hours,
which
are
just
chock
full
of
great
examples.
B
So
I
think
this
really
could
use
a
link
to
iteration
office
hours.
I
think
we
should
have
a
real
example
and
I
think,
making
small
merge
requests.
It
kind
of
sounds
easy.
I
think
it
might
might
need
a
little
bit
more
like
when
you
tell
people
to
make
small,
what's
a
merch
request,
but
when
you
tell
people
to
make
smaller
changes,
won't
they
game
the
system.
Actually
they
will
and
it's
great
and
it
makes
people
it
makes
things
better
because
they
happen
faster.
B
B
B
I'm
a
ceo
like
everything
is
my
domain.
Basically,
that's
it's.
It's
certainly
not
appear
making
making
a
horizontal
proposal
so
well.
I
think
it's
a
good
example
of
maybe
low
ego
or
don't
get
too
attached
to
your
things.
I
think
it's
the
this
is
the
best
example
of
kind
of
speak
truth
to
power
like
don't
in
the
end,
the
best
opinion
should
win,
not
the
highest-paid
person.
That's
what
this
is
an
example
of
not
of
short
toes,
so
I
think
we
should
have
a
a
different
example
here.
B
B
Gathering
input
before
taking
action,
I
I
think
we're
not
anti-brainstorm,
I
think,
there's
literature
that
shows
that
brainstorming
is
more
effective
if
everyone
does
it
on
their
own
and
you
pull
all
the
proposals.
So
it's
better
to
do
it
async
we're
not
we're
not
saying
that
just
make
a
proposal
is
an
alternative
for
create
expansion.
Thinking
or
something
like
that.
It
seems
almost
like
make
a
proposal
as
an
alternative
to
brainstorming
which
it's
not
for
brainstorming.
Just
do
it
async,
don't
do
it
in
a
meeting
you'll
get
fewer
proposals.
B
A
I
agree
with
that.
I'll
give
you
some
context
from
my
side.
I
think
async
proposals,
or
I
agree
with
you
on
that.
I
think
where
I
was
going
with
the
example
was
not
group
brainstorming
versus
async
brainstorming.
It
was
complaining
or
griping
about
a
certain
thing
without
offering
a
proposal
in
concert
with
it
and
that's
so.
If
you
read
the
example,
that's
there
when
a
team
member
disagrees
with
a
given
policy,
so
instead
of
complaining
with
no
nothing
to
bounce
off
of
no
no
written
proposal.
Does
that
make
sense.
B
To
a
certain
extent
like
I
don't
want
people
kind
of
not
complaining
because
we
use
like
oh,
you
should
have
a
proposal.
Well,
sometimes
it's
somebody
else.
Something
is
really
broken
and
someone
else's
job
to
to
figure
it
out,
like
you,
can't
have
like
our
salespeople
you're,
not
allowed
to
question
the
reliability
of
gitlab.com
without
making
an
infrastructure
proposal.
That
would
be
ridiculous.
B
So
I'm
not
a
big
fan
of
that.
Okay,
I'm
a
big
fan
of
is,
like
you,
don't
get
to
like
it's
super
inefficient
to
be
in
a
meeting
and
trying
to
figure
something
out.
So
it's
much
more
efficient
for
one
person
to
do
some
homework
beforehand
and
at
least
have
a
proposal
to
give
feedback
on
for
that
meeting.
That's
a
much
better
use
of
everybody's
time.
That's
what
proposals
are
about.
It's
not
about
a
license
to
complain!
It's
about!
B
B
B
Thanks
for
being
open
to
the
suggestion,
dri
great,
a
team
member
wishes
to
change
something
they
are
chosen
and
they
are
chosen
as
the
dri
there's
no
relationship
between
these
two
things.
The
dri
is
the
person
who's
kind
of
whose
result
metric
is
affected
or
the
person
who
has
to
do
the
work.
I
think
the
person
who
does
the
work
frequently
is
well.
We
set
short
toes
like
you
can
make
a
proposal
about
somebody
else's
works.
Our
whole
point
is
that
those
two
aren't
the
same.
B
A
B
Most
of
the
time,
it's
just
the
person
whose
result
metric
is
related
right.
If
it's
stop
time
of
gitlab.com,
it's
infrastructure,
it's
steve,
and
if
it's
I
don't
know,
making
sure
that
our
messaging
is
compliant
with
legal
standards
is
rush
me
like
it's.
It's
most
of
the
time,
there's
already
a
person
whose
job
that
is,
and
if
it's
a
judgment
call
management,
can
help.
B
B
B
B
B
So,
what's
an
what's
a
one-way
door
decision,
for
example,
a
pricing
change,
it's
a
one-way
door.
I
think
you
can't
really
retract
that,
but
what
you
can
do
is
like
test
it
out
with
a
coupon.
You
send
to
a
select
number
of
people
to
see
whether
they're
interested
now.
Suddenly
you
can
test
it
without
being
bound
to
it.
B
Yeah
because,
like
there's
suppose
every
decision
has
a
chance
of
failure,
and
it's
always
it's
suppose.
It's
always
20.
If
it's
a
one-way
door
decision,
you
want
to
do
more
diligence,
because
you
can't
reverse
the
decision
like,
if
suppose,
your
company,
your
time
frame,
is
like
five
years
or
something
like
that.
If
it's
a
two-way
door,
you're
gonna
be
stuck
if
it's
a
one-way
door,
you're
stuck
with
that
decision
for
five
years,
it's
a
one-way
door.
You
can.
That
decision
is
only
in
place
for
five
for
five
months,
only
ten
percent
of
the
time.
B
So
it's
20
versus
20
times
10
of
the
time,
which
is
two
percent
like
if
there's
a
two
percent
chance
of
failure,
that's
much
lower
and
you
you're
hey
the
data
you
collect
can
go
down
by
an
order
of
magnitude.
The
data
you
collect
up
front
to
support
the
decision
can
go
down
by
an
order
of
magnitude,
so
you
can
make
it
faster
because
there's
less
diligence
needed.
B
Making
a
shorter
time
between
deciding
to
do
something
and
getting
the
result
out
there,
I'm
not
sure
how
to
kind
of
apply
that
to
a
management
framework
like
it
shouldn't
be
like
hey,
you
should
use
a
platform
everywhere
or
something
like
that,
but
there's
some
energy
there.
I
just
don't
know
how
to
how
to
add
it.