►
Description
GitLab E-Group and the Learning & Development team discuss strategies on Making Decisions.
Learn more about how GitLab Makes Decisions: https://about.gitlab.com/handbook/leadership/making-decisions/
Learn more about GitLab Leadership: https://about.gitlab.com/handbook/leadership/
GitLab's value hierarchy: https://about.gitlab.com/handbook/leadership/
A list of topics covered are below:
1. Living our Transparency value when making decisions
2. How to improve our ability to Iterate
3. Applying the GitLab values hierarchy in making decisions
4. How the DRI enables decisions making
5. When to use consensus when gathering information and when to use hierarchy when making decisions
6. Importance of making team members feel safe when making decisions
7. Why team members making the most mistakes are likely to be the highest performers
8. Making decisions in the face of uncertainty
A
If
there's
any
big
points
you'd
like
to
discuss
so
making
decisions
at
gitlab,
it's
a
lot
different
than
a
lot
of
other
organizations
that
I've
been
a
part
of,
and
I'm
sure
everybody
else
has,
and
you
know
looking
at
the
making
decisions.
Leadership
page,
you
know
what
rings
true
to
how
we
currently
operate.
C
Yeah
to
answer
your
question
josh,
I
think
we're
doing
a
really
good
job
of
taking
decisions
transparently.
I
think
a
lot
of
decisions
are
open
for
everyone
to
comment
on.
I
think
we're
doing
a
less
good
job
on
iteration,
for
example,
people
call
sometimes
say:
oh,
it's
an
iteration
while
they're
just
revising,
have
another
revision
of
a
draft,
and
I
think
the
thing
that
gets
called
out
here,
like
the
very
counterintuitive
thing
about
our
process,
is
that
we're
gonna
invite
everyone
to
contribute.
C
But
that
means
that
you
don't
always
get
acknowledgement
or
feedback
on
your
comments.
That
is
counter-intuitive
and
I
think
people
still
struggle
with
that.
I
struggle
with
that.
If
I
don't,
if,
if
someone
doesn't
acknowledge
my
my
comment
or
my
opinion
and
and
mine
probably
get
a
lot
more
attention
than
others,
so
I
think
that
that
we
call
that
out
as
a
as
something
that's
hard
and
it
is
really
hard
to
do.
B
I
think
one
one
thing
that
I've
noticed
is
the
values
hierarchy
is
really
important
and
when
we
have
a
discussion
about
tension
between
those,
we
tend
to
get
a
healthy
result
in
the
decision.
So
you
know
results
versus
efficiency,
collaboration
versus
efficiency.
Those
debates
are
usually
pretty
healthy
and
making
sure
we
get
the
best
decision.
B
I
do
think
that
there
are
times
that
we
don't
have
that
debate
and
that
leads
to
a
problem
where
you
know
different
people
involved
in
the
process
will
be
thinking
about
the
the
elements
of
the
hierarchy
with
different
weights
in
their
own
mind,
but
didn't
come
together
and
actually
discuss
it
and
come
to
an
agreement.
So
I
think
continuing
to
drive
that
and
use
the
values
as
a
framework
is
important
to
make
sure
we
actually
get
the
right,
the
right
inputs
and
quickly
make
the
right
decision.
D
Another
thing
that
rings
true
for
me
is
that
the
notion
of
the
dri
is
is
commonly
understood
and
almost
all
the
time
followed
and
usually
the
dri
is
pretty
clear,
and
I
think
people
who
think
of
themselves
as
the
dri
on
a
specific
project
or
action
tend
to
exhibit
the
right
behaviors.
So
that's
awesome.
You
know,
for
example,
the
product
development
flow
outlines
who
owns
what
throughout,
and
I
think,
we've
done
a
pretty
good
job
of
making
it
clear
who
the
dri
is
given.
D
What
the
where
you
are
in
the
flow
where
it
gets
harder
is
when
the
dri
isn't
immediately
clear.
For
example,
a
large
cross-functional
project,
where
maybe
multiple
levels
and
multiple
functions
are
involved
when,
when
people
at
a
higher
level
need
to
be
consulted
before
moving
forward,
I
think
the
dri
in
those
types
of
situations
gets
a
little
murkier.
So
we
may
want
to
clarify
how
to
handle
situations
like
that,
where
maybe
multiple
levels
or
multiple
functions
are
involved.
C
What
we
don't
want
is
to
be
in
the
middle,
where
we
find
the
balance
between
the
two.
We
want
to
be
like
a
digital
signal
where,
in
the
information
gathering
phase
we're
completely
consensus
and
in
the
decision-making
phase,
we're
completely
hierarchical,
we
want
to
we're
splitting
those
two
things
so
that
we
don't
have
to
find
a
balance,
because
you
can
never
get
that
balance
right
and
lots
of
companies
have
tried
and
it
it
doesn't.
C
You
get
the
worst
of
both
worlds.
If
you
try
to
find
a
balance,
we're
trying
to
split
it
and
say
hey
in
the
information
gathering
phase,
it
is
consensus,
as
in
everyone
gets
to
see
it,
and
everyone
gets
to
provide
input
in
the
decision-making
phase.
It
is
that
single
person
deciding
and
getting
the
best
of
two
worlds.
C
E
And
to
that
point
josh,
I
think
the
the
company-
this
is
an
observation.
Being
a
relatively
new
to
the
company.
Is
a
lot
of
companies
have
values,
but
it
don't
really
incorporate
them
into
their
day-to-day
decision-making
framework,
and
here
I
think
everyone
does
a
great
job
of
having
those
those
values.
First
to
drive
the
decision
and
to
think
about
the
decisions
around
those
values,
and
so
team
members
have
been
great
about
bringing
up.
You
know
what
the
values
are
referring
back
to
the
values
and
it's
it's
in
the
day-to-day
sort
of
every
meeting.
F
There's
this
tension
between,
like
we
talked
about
extreme
ownership
yesterday
and
like
executives,
have
to
own
everything-
and
I
think
that's
still
true,
but
that
makes
us
like
the
responsible
individual,
not
the
directly
responsible,
individual.
The
dri
is
usually
someone
deeper
more
in
the
org,
more
local
to
the
problem
and
someone
that's
meant
to
kind
of
like
centralize
everything
that
needs
to
be
learned
about
the
problem.
F
Sort
of
done
all
the
work
they've
they've
set
the
table.
I
think
mcbride
highlighted
david
santos
ability
to
do
this
yesterday,
which
I
thought
was
very
very
apt,
where
he'll
just
kind
of
create
this
gravity
around
something-
and
you
know
people
above
and
below
him
in
the
org
chart-
are
kind
of
working
for
him
in
that
context,
and
that's
that's
the
ideal
way
it
should
work.
B
I
think
one
thing
that
I
would
add
is
there's
confusion,
sometimes
about
isolation
of
individual
decisions
and
really
what
we're
trying
to
do
is
get
a
successful
outcome
and
that's
an
on
an
ongoing
basis
and
the
dri
is
not
just
responsible
for
any
one
individual
decision,
but
the
collection
of
those
decisions.
So
if
they're
responsible
for
a
product
for
a
result
for
a
particular
outcome,
they're
responsible
for
the
collective
inputs
and
outputs
that
result
that
sorry,
that
accumulate
to
that
result
for
the
business,
and
that
means
there's
going
to
be
trade-offs.
B
That
means
some
of
the
decisions
might
have
to
go
one
way
in
order
to
balance
out
some
others
to
get
that
best
possible
result
for
for
gitlab
and
our
customers.
So
I
think
an
important
part
of
dri
is
that
it's
not
just
for
a
particular
project
or
a
particular
decision.
It's
ownership
of
that
result
that
comes
from
that
collection
of
decisions.
A
That's
great
insight,
thank
you.
So
much
michael
and
eric.
Is
there
anything
that
like
causes,
you
pause?
Is
there
something
that
doesn't
feel
right
or
isn't
happening,
and
is
there
something
we
should
be
doing
differently?
You
know
right
now
at
gitlab
when
it
comes
to
making
decisions.
Just
from
from
your
all's.
D
D
C
Yeah,
I
think
it's
like
claim
to
space
and
I
think
sometimes
decisions
get
deferred
to
the
e-group.
I
think
it's
really
important
to
sometimes
say:
oh
either.
This
is
my
proposal
and
just
wait
for
the
yes,
but
many
times
it
could
just
be.
I
made
this
decision
like
it's
good,
to
be
people
in
the
loop,
but
that
doesn't
mean
you
have
to
wait
for
a
decision
and
most
things.
C
H
G
I'll
flip,
you,
I
wonder,
if
it's
possible,
to
introduce
into
the
onboarding
different
sort
of
rubrics
for
making
decisions
for
folks
that
might
be
new
to
this
concept,
who
haven't
had
the
ability
or
empowerment
prior
jobs
to
make
decisions
in
their
role
so
that
we
can
kind
of
give
them
a
couple.
Different
frameworks
to
choose
from
they
can
eventually
develop
their
own
style,
but
they
don't
feel
like
the
first
time
this,
the
first
time
they
have
to
go
through
this,
that
they're
kind
of
out
in
the
cold.
G
I
mean
I'm
speaking
personally
from
legal
most
of
the
times
legal
folks,
don't
necessarily
make
they
make
a
ton
of
decisions
in
legal
documents.
They
don't
necessarily
make
a
ton
of
decisions
in
other
roles
or
coming
out
of
law
firms.
Usually
it's
deferred
to
the
client
and
I'd
like
to
figure
out
a
way
to
teach
folks
how
to
do
that.
A
I
think
that's
a
great
point.
I
think
that's
something
I've
heard
across
the
organization,
just
the
concept
of
being
a
manager
of
one
like
that's
a
very
new
concept
for
a
lot
of
people,
especially
if
you
come
from
a
very
top-down
organization.
So
I
think
a
lot.
Some
team
members
do
struggle
with.
How
do
I
actually
be
a
manager
of
one
and
apply
that
into
my
role?
So
I
would
love
to
include
some
on-boarding
work
to
improve
that
new
team
member
experience.
G
H
Which,
actually
is
a
good
segue?
I
was
wondering
sid
if,
if
you
thought
we
could
use
one-way
and
two-way
doors
as
sort
of
a
way
to
say
basically
make
as
many
two-way
door
decisions
as
you
want
as
being
managed
everyone.
If
it's
a
one-way
door
decision,
you
might
want
to
ask
somebody
you
might
want
to
get
some
feedback
from
your
boss
or
something
like
that
to
give
people
some
guard
rails,
yep.
C
I
think
that's
a
super
helpful
framework
and
it's
much
better
than
say:
oh,
is
it
an
important
decision
or
not
because
that's
not
that's
not
helpful
at
all
the
reversibility
and
the
ability
to
adjust
later
is
is
much
more
important
and
if
you
take
a
bad
decision,
but
it's
small
and
in
two
weeks
we
can
do
something
different,
that's
a
very
different
thing
than
something
where
we're
locked
in
for
the
next
two
years,
yeah.
What
mcbee
said.
D
B
I
don't
need
to
repeat
what
todd
said
there,
but
in
point
l
there.
The
whole
framework
is
key
if
you're
the
dri
for
a
decision.
It's
key
to
know
that
you
have
to
define
it
clarify,
as
todd
mentioned
some
one
way
or
two
day
door
to
a
door
and
use
that
to
frame
to
the
whole
team
that
what
that
means
for
the
path
of
decision,
and
so
we
can
move
quickly.
It's
a
two-way
door.
B
B
C
Yeah
I
I
can.
I
will.
I
totally
agree
having
an
argument
for
like
what
options
did
you
consider
because,
frequently,
when
I
see
a
decision,
I'm
like
oh,
but
I
really
think
they
should
do
x
or
y
and
I
come
in,
and
I
see
they
consider
that
option
that,
like
80
to
90
percent
of
the
time
they
considered
it,
they
probably
have
a
better
grasp
on
that
I'd
be
worried.
If
they
haven't
considered
that
alternative,
then
I
then
I'd
stop
should
always
be
a
recommendation.
C
C
F
A
H
Those
aren't
the
same
as
I
made
a.
I
made
a
call
and
the
call
was
wrong.
That's
a
mistake
we
don't
want
to.
I
think
people
are
confusing
performance
with
mistakes
and
I
want
to.
I
think
we
should
get
really
clear
about
that.
It
would
help
in
a
lot
of
conversation
like
performance
discussions
that
that
I
have.
C
C
And
if
you're
not
making
mistakes,
you're,
probably
making
decisions
too
late,
you
collect
too
much
data
and
you
make
too
few
decisions
and
to
probably
make
them
too
late,
and
we
have
to
make
decisions
in
the
face
of
uncertainty.
That
means
a
certain
percentage
is
wrong.
Important
thing
is
find
when
it's
wrong,
acknowledge
it
try
to
fix
whatever
you
can
and
communicate
it
and
and
move
on
and
high
performance
is
not
making
zero
mistake.
It's
ins,
in
fact
like
if
you're,
making
zero
mistakes,
I
can
guarantee
you're
not
highly
performing.