►
From YouTube: Leader to leader collaboration | GitLab Design Talks
Description
Iain and Nick discuss leader to leader collaboration at GitLab.
A
B
Everyone
I'm
ian
camacho,
I'm
a
product
designer
for
the
package
stage
here
at
git,
lab
I've
been
here
for
about
a
year
and
a
half
which
is
pretty
cool,
bringing
a
product
in
the
package
site
from
pretty
minimal
up
to
some
more
lovable
categories,
which
is
cool
and
have
about
a
decade
of
experience
in
creative
and
design.
Before
that.
B
That's
a
really
great
question,
I
think
in
all
of
my
experiences
beforehand,
between
agency
work
and
in-house
product
design,
the
product
design
team
tend
to
be
junior,
and
so
the
collaboration
effort
from
the
design
side
is
twofold.
Half
of
it
is
just
delivering
designs
and
getting
everyone
on
board
with
doing
something.
The
other
half
of
what
I
used
to
have
to
do
is
just
prove
that
the
design
process
was
worthwhile.
B
B
In
contrast,
when
I
joined
get
lab,
everyone
was
on
board
with
that
already
I
just
walked
in
and
they
were
like.
You
need
to
do
this
because
you're
a
designer-
and
I
was
just
like
wow-
okay.
Yes,
we
definitely
need
to
do
that.
Let's
go
so.
It
actually
has
been
a
lot
easier
to
have
that
robust
design
conversation
and
then
encouraged
empathy,
driven
development
and
design-oriented
strategy
and
stuff,
like
that,
that's
been
the
big.
A
Difference
yeah,
it's
it
it's
so
much
more
efficient
when
the
legitimacy
of
design
has
been
already
agreed
upon
and
you
can
just
sort
of
go
ahead
and
start
exploring
and
having
a
good
time
with
your
team,
and
I
think
you
bring
up
a
really
good
point.
I
mean
I,
I
came
from
agency
and
consulting
background
as
well,
and
one
of
the
big
differences
I
found
is:
is
the
the
role
of
design
within
like
project
oriented
work
versus
product
and
oriented
work,
so.
B
B
I
100
agree
when
I
worked
at
consultancies.
It
was
about
proving
the
value
before
the
contract
started
and
then
delivering
on
the
contract
at
the
end,
and
that
was
the
whole
conversation
since
moving
to
get
lab
after
you're
done
with
your
first
design
project
as
it
were,
that
goes
through
the
whole
process.
The
problem,
validation,
design
solution,
validation
over
to
engineering.
B
B
I
had
answers
and
I
had
data
to
help
provide
that
kind
of
strategy,
but
I
had
never
really
been
asked
that
question
before
what
does
design
think
we
should
work
on
next,
as
opposed
to,
I
guess,
in
the
consulting
background,
is
what
does
the
next
contract
engagement
say?
We
should
work
on
or
what
has
leadership
or
stakeholders
said?
Is
the
next
thing?
I
have
a
lot
more
voice
in
what
we
should
be
talking
about,
because
I've
talked
to
users.
B
A
So
there
is
a
a
bit
of
a
challenge
that
I
had
when
first
adapting
to
that
in
that,
as
a
designer
I'd
never
been
used
to
writing
my
own
briefs,
which
is
effectively
what
you're
doing
when
you're,
when
you're
doing
like
the
strategy
and
thinking
about
what
we
should
be
doing
next
and
I
think
that's
a
bit
of
a
gap
that
I
see
in
a
lot
of
junior
designers
as
well.
I
wonder:
do
you
have
any
tips
on
how
how
you
could
potentially
or
how
you
found
you
adapted
to
that
transition
of
effectively?
B
B
Product
management
tends
to
walk
in
with
what
the
market
is
doing
and
what
the
business
says
they
should
be
doing,
and
you
may
have
heard
a
couple
of
things
from
users
about
what
they,
what
else
they
like
walk
in
with
questions
with
your
product
manager
about?
What's
the
next
most
impactful
thing,
what
can
we
bring
value
to
our
customers
as
quickly
as
possible?
This
is
what
I've
heard.
Have
you
heard
the
same?
Is
there
a
market
for
this?
B
I
have
a
perspective
that
can
lean
into
that
strategy,
and
you
start
thinking
a
little
bit
longer
term
and
that
especially
at
gitlab,
helps
you
move
into
the
iteration
idea
of
this
is
what
will
deliver
value
quickest
for
git
lab
as
a
business
for
our
customers
and
then,
if
you
pair
this
with
this
other
design
feature
that
delivers
value,
that's
a
new
iteration
and
then
we
can
bring
it
together,
and
that
creates
this
really
robust
experience
that
will
help
the
business
stand
out.
You
start
having
a
much
more.
B
A
Yeah
yeah,
I
think
that
sort
of
speaks
to
the
fact
that,
when
you're
working
on
these,
these
sort
of
product
oriented
teams
as
a
as
a
designer
you
become
a
little
bit
more
t-shaped,
become
quite
quite
of
a
generalist
as
well,
and
you
need
that
generalist
approach
and
understanding
at
a
at
a
you
know
relatively
shallow
level,
compared
to
your
understanding,
the
user
or
something
you
need
an
understanding
of
some
business
concepts.
You
need
some
technical
concepts
in
order
to
communicate
and
collaborate
more
effectively
with
with
the
other
people
on
your
team.
A
So
I
forgot
what
direction
I
was
going
with
there,
but
yeah.
I
think
what
I,
what
I'm
trying
to
say
is
that
generalism
also
means
that
it
stops
you
from
having
this
chuck
and
over
the
fence
attitude
where
someone
writes
the
brief.
The
designer
does
the
designs,
and
then
they
chuck
the
designs
over
to
to
the
the
development
team
and
they
they
implement
it.
Instead,
it's
it's
much
more
of
a
a
blended,
a
blended
approach
at
the
different
stages
of
the
of
the
process.
A
Work
from
taking
the
idea
to
to
implementation-
and
I
think
this
sort
of
brings
up
the
concept
that
you
talked.
You
talked
to
me
about
that.
You
wanted
to
sort
of
focus
this
conversation
around,
which
is
leader
to
leader
collaboration.
So
maybe
you
can
sort
of
introduce
what
this
means
and
we
can.
We
can
dive
into
that.
B
For
sure,
I
think
you
did
an
excellent
job
team
that
up
so.
Thank
you.
One
of
the
things
that
I
noticed
is
that
when
you're
a
designer
and
you're
used
to
getting
a
brief
and
then
tossing
it
over
the
fence
to
engineering
you're
following
kind
of
a
leader
follower
mentality,
so
in
this
instance,
the
product
manager,
who
really
does
have
the
agency
and
is
responsible
for
the
whole
product,
telling
you
what
needs
to
what
to
do
next,
and
then
you
put
it
together,
which
is
basically
putting
the
description
together.
B
What
we
did
on
package
is,
after
a
couple
of
milestones,
of
realizing
that
I
was
never
going
to
get
ahead
of
the
front
end
team.
I
was
always
going
to
be.
They
were
going
to
need
more
work.
I
was
going
to
need
to
put
more
comps
together
more
designs
together.
We
realized
that
I
was
answering
kind
of
the
same
questions
in
different
ways.
B
B
B
When
you're
doing
the
leader
follower
mentality,
those
values
tend
to
get
lost
because
you're
just
prescriptively
putting
out
work
by
moving
to
leader
leader
and
everyone
walking.
In
with
expertise,
we
discovered
that
product
management
could
say,
here's
our
large
scale
vision
and
here's
all
the
reasons
why
I
talked
to
customers.
They
said
this
was
important
if
we
build
these
five
things.
This
is
what
our
users
start
to
think.
This
is
what
our
customers
will
val
will
value.
B
This
will
move
us
from
being
under
our
competition
to
being
next
to
them
with
the
least
amount
of
work,
those
kinds
of
conversations
and
when
you
start
sharing
the
vision
in
terms
of
that
standpoint
and
everyone
can
walk
to
the
table,
saying
I'm
an
expert
in
this
area.
I
understand
the
vision.
Now
I
have
the
authority
to
say
this
is
how
we
should
do
it.
This
has
helped
tremendously.
B
Tim
is,
as
the
product
manager
is
not
responsible
for
writing
every
single
issue
that
could
possibly
be
built
with
perfectly
detailed
instructions
on
how
everything
needs
to
be
articulated
moving
down
the
chain.
I
don't
have
to
create
a
comp
for
every
single
state
of
every
single
issue
that
I
need
to
create
for
each
of
the
engineers
that
I'm
working
with
that
doesn't
work
very
effectively.
B
I
end
up
falling
behind
really
quickly
and
from
an
engineering
standpoint,
they're
less
stifled
if
they
understand
the
vision
and
they
have
all
of
the
technical
competencies
they
have
the
authority
and
agency
in
our
group
to
say
you
said
last
week
that
this
was
a
major
priority
to
get
this
done
from
the
technical
side.
We
could
do
it
by
building
these
three
steps.
B
Instead,
what
do
you
think
having
everyone,
collaborate
and
work
together
on
a
unified
and
shared
vision,
means
that
everyone
is
working
together
and
the
advantages
from
the
design
side
and
I'm
totally
fine
being
selfish
about
this?
Is
I
have
to
produce
less
cost?
I
can
create
one
big
vision
that
just
says
this
is
where
we
want
the
dependency
proxy
to
be
in
six
months.
Here's
the
features
our
users
have
tested.
They
said
they
want
it
engineering.
B
How
do
we
get
there
and
then
from
there
instead
of
reacting
to
product
management
and
trying
to
feed
engineering
engineering
now
has
a
large
vision
and
can
build
towards
it,
and
my
job
then
becomes
the
smaller
scale
where
front-end
engineers
feel
like
they
could
build
something,
and
then
they
check
with
me.
Is
this
good
ux?
Does
this
work?
How
does
this
feel
as
an
iteration?
Does
it
deliver
value
on
what
we
said?
This
creates
a
group
conversation
that
everyone's
working
towards
the
same
thing.
B
So
as
part
of
the
strategy
side,
I
have
to
produce
less
detailed
instructions.
Everyone
feels
better.
They
have
agency
and
able
to
discuss
things
at
a
broader
level
and
that
helps
tremendously
because
we,
as
the
team
of
10
people,
are
putting
it
all
together
instead
of
tim,
is
telling
the
designer
to
make
comps
to
tell
engineering
to
build
this
and
hope
we
get
there
eventually.
A
Yeah,
that's
that's
a
really
beautifully
illustrated
concept
on
on
how
teams
work
here.
You
know,
there's
there's
a
lot
of
people
within
a
team
who
have
agency
to
do
work
and
bring
their
area
of
expertise,
but
they
rely
on
other
team
members
to
sort
of
fill
in
the
gaps
of
the
things
that
they
don't
necessarily
know,
but
the
the
way
that
it
comes
together
is
very
pragmatic
so
that
we
are
prioritizing
throughput
of
of
the
features
and
things
that
we're
continuously
shipping.
A
A
That's
something
I
actually
struggled
with
quite
a
bit
is
being
the
single
designer
within
a
team
and
managing
the
workload
compared
to
the
eight
other
engineers
in
my
team.
So
I
was
wondering:
do
you
have
any
advice
for
me
and
other
people
in
the
team
for
how
we
designers
can
be
a
little
bit
more
efficient,
with
the
way
that
we
collaborate
so
that
we're
not
constantly
doing
a
comp
or
a
design
for
every
single
request?
That
comes
from
a
from
an
engineer.
How
do
you
actually
go
about
doing
that.
B
B
The
greatest
thing
that
we
did
on
package
is:
we
took
a
quarter
to
go
through
the
whole
design
process
of
something,
so
that
was
three
milestones
to
do:
research
to
figure
out
the
problem
design
in
order
to
put
comps
together
solution,
validation
and
move
forward.
We
did
a
higher
level
design,
so
we
put
designs
out
there.
That
was
the
six-month
strategy
for
the
dependency
proxy,
for
example.
B
I
kind
of
talked
about
that
at
different
showcases,
and
we
have
already
seen
that
there
are
many
different
states
and
iterations
that
I
didn't
have
to
be
involved
in
directly
or
put
clumps
together,
where
engineers
knew
what
we
were
trying
to
build.
They
knew
where
we
were
trying
to
go,
and
so
they
were
able
to
just
check
in
with
me
and
say:
I
want
to
build
this
first
and
then
this
next
step
does
that
deliver
value
to
users
in
the
media
in
the
interim.
B
Is
it
a
good
ux
and
then
I'm
able
to
answer
them
as
the
expert
of
ux
saying,
the
idea
is
really
good.
If
you
tweak
these
two
details,
I
think
it
creates
a
really
powerful
experience
now
and
in
the
next
stage,
and
it
lightens
my
workload.
I
don't
have
to
create
those
comps
for
every
iteration
between
now
and
the
next
six
months
I
needed
to
create
a
big
one
and
then
from
there
I
can
help
engineers
whenever
there's
an
in
between
step
that
might
need
some
design
effort.
B
They
work
with
me
in
a
way
that
they
understand
that
that
is
my
area
of
expertise.
Just
like
theirs
is
the
technical
side
of
things
and
when
they
have
questions
or
they're
unsure
of
things,
they
know
that
I
am
here
as
a
resource
for
them
to
understand
better
and
build
better
solutions
instead
of
the
opposite,
which
is
that
I
have
to
prescribe
every
step
along
the
way.
A
Interesting,
so
not
only
participating
as
a
designer
further
left
of
of
the
of
the
process.
Also
getting
buy-in
and
alignment
with
the
engineers
further
left
as
well
is
what
helps
to
direct
them
in
in
the
solutions
that
they
take.
So
your
role
in
some
of
the
smaller
more
tactical
decisions
is
more
of
a
reviewer,
as
opposed
to
a
designer.
B
Exactly-
and
I
think
one
of
the
benefits
that
if
I
were
to
give
someone
advice
on
how
to
start
doing
this
is
bring
engineers
and
have
them
shadow
research
sessions,
especially
when
you
are
doing
moderated
testing,
and
so
you
get
a
lot
of
contextual
data.
If
you
bring
in
an
engineer
to
sit
on
one
or
two
of
those,
suddenly
they
move
from
a
reactive
building
style,
which
is,
I
need
to
check
the
boxes
in
the
issue
to
empathy
driven
engineering.
B
They
understand
what
they're
trying
to
accomplish
for
the
user
and
at
gitlab
we
have
a
unique
opportunity,
because
in
most
cases
our
engineers
are
also
our
users.
So
they
have
a
direct
path
to
that
empathy
and
that's
what
we
do
a
lot
in
package.
Is
I'm
not
an
expert
in
packages.
I've
used
a
couple
every
now
and
then,
but
I'm
not
a
technical
expert.
I
instead
gave
them
the
background
and
context
of
what
our
customers
are
saying
and
what
our
users
are
saying
and
as
experts
they
were
able
to
build
towards
that.
A
I
see
I
see
so
you
mentioned
that
you
you
as
a
team,
you
you
invested
three
months
and
going
through
the
entirety
of
the
design
process
from
research
all
the
way
to
implementation,
and
I
wonder
that
that's
that's
a
lot
of
investment.
That's
a
lot
of
a
lot
of
time
to
invest,
regardless
of
whether
it's
just
you
or
the
engineers
in
your
team
that
that
equates
to
quite
a
bit
of
money.
A
B
That's
a
really
good
question.
We
did
have
a
little
bit
of
hesitation.
This
is
when
problem
validation,
design
and
solution.
Validation
were
formalized
in
the
handbook,
and
everyone
on
the
team
was
just
getting
used
to
the
idea
of
how
that
works.
It
was
a
very
large
investment,
but
from
our
engineering.
Actually
I
discussed
this.
Is
they
asked
the
question
during
one
of
our
syncs?
B
I
don't
quite
remember
which
one
what's
the
value
of
doing
all
these
steps,
and
so
I
kind
of
walk
through
problem
validation
means
that
we
actually
understand
the
full
problem,
the
complexities
of
it.
What
our
users
are
expecting
design
is
the
chance
for
us
to
put
together
a
solution
and
then
solution.
Validation
means
that
we're
able
to
ask
users.
B
Does
this
actually
solve
your
problem
before
you
go
off
and
build
it
and
the
reason
we
do
all
of
these
steps
is
because
it
gives
you
all
of
this
data
and
it's
really
valuable
and
to
make
sure
that
you
are
building
the
right
things.
So,
instead
of
investing
in
a
solution
that
you
may
have
to
change
later,
you
have
a
much
greater
confidence
that
you're
building
what
needs
to
be
built.
B
They
really
like
the
facts
and
I'm
quoting
one
of
our
front-end
engineers.
I
don't
have
to
worry
about
doing
something
twice,
because
I
know
I
got
it
right,
the
first
time
because
you
tested
it,
you
checked
it
and
I
saw
you
do
it
and
I
saw
the
areas
where
users
got
stuck
and
I'm
now,
as
the
leader
leader
model,
I'm
able
to
come
in
and
say
I
think
we
should
fix
it
this
way,
because,
as
an
engineer,
this
makes
more
sense
to
me.
B
That's
how
we
kind
of
got
that
initial
buy-in
is
instead
of
engineers.
Your
job
is
to
build
the
thing
we
tell
you
to
build.
It
turned
into
all
of
us
need
to
come
together
to
build
a
thing
for
our
users
and
investing
in
this
process
seems
like
a
lot
adverse.
But
when
you
take
three
months
to
build
the
dependency
proxy
strategy,
which
is
what
we
did
there's
six
months
of
work
that
the
engineers
need
to
put
together
to
do
it.
That
doesn't
require
my
full
attention
anymore.
A
What
I
love
about
the
way
that
you
just
described
it
there
is
you
used
language
and
terminology
which
wasn't
isolated
to
the
to
the
domain
of
design.
You
used
it
and
you
pitched
the
value
of
of
problem
validation
in
a
way
that
anyone
could
understand
it,
and
specifically,
you
pitch
the
value
of
it
to
engineers
in
ways
that
would
would
benefit
them
rather
than
saying
problem.
Validation,
helps
you
understand
the
problem
space
and
build
empathy
and
understanding
and
using
design
language,
which
can
sometimes
be
quite
off-putting.
A
B
Yes,
when
you're
thinking
of
collaboration
as
a
designer
bring
everyone
together
will
yield
better
results
for
your
team,
but
will
also
make
your
life
easier.
So
inclusion
include
people
in
research,
make
sure
every
iteration
of
the
design
engineers
have
a
chance
to
look
at
it.
Even
if
they
don't
leave
feedback,
including
everyone
makes
it
a
much
smoother
process
people
buy
in
more
when
they're
included
in
the
beginning.
A
Sagely
advice,
beautiful
beautiful-
and
this
is
sort
of
a
theme
that
I
keep
on
coming
across
when
discussing
collaboration,
is
the
way
that
we
collaborate
at
gitlab
is
very
dependent
on
the
other
values
that
we
have
at
gitlab
as
well.
So
diversity,
inclusion
and
belonging
sort
of
is
exactly
what
you
talked
about
there.
So
it's
the
way
that
we
uniquely
blend
these
values
that
we
have
at
gitlab
with
collaboration
that
makes
it
so
special.
So
I
really
appreciate
that.
Thank
you
very
much
and
have
a
have
a
good
day
see
you
later
bye.