►
From YouTube: Empathy for engineers | GitLab Design Talks
A
A
B
Yeah,
it's
I
I
I
would
say
what
to
me.
It
stands
out
about
get
lab
and
collaboration
is.
Is
the
ability
to
voice
your
opinion,
which
sounds
like
a
novel
thing,
but
to
me
that's
one
of
the
things
I
love
most
about
gitlab
is
that's
not
always
the
case
right.
I
mean
that
that
seems
like
a
foregone
conclusion
here,
but
a
lot
of
places.
B
You
know
if
there's
political
things,
there's
things
you
say,
there's
things
you
don't
say,
there's
times
to
bring
things
up,
there's
times
not
bring
things
up
and
I
feel
like
none
of
that
exists
in
gitlab
right,
so
the
collaboration
happens
real
time
where
it
needs
to
happen.
You
know
it's.
It's
spread
across
everything,
you're,
not
waiting.
B
I
feel
like
in
my
years
previous.
You
would
be
like
okay.
I
have
an
opinion
on
that,
but
I'm
not
going
to
voice
that
until
that
meeting
next
week,
when
it's
appropriate
to
do
so
here
at
gitlab.
I
have
an
opinion
on
that.
It's
going
on
an
issue,
it's
going
in
slack,
I'm
reading
my
voice
at
a
meeting,
so
you
know
to
me
that's
what
stands
out
most
about
the
collaboration
here
is
that
anybody
can
do
it.
A
Yeah,
so
that's
that's
quite
interesting.
It
seems
like
that
perspective
on
collaboration
is
heavily
influenced
by
our
value
of
transparency
as
well,
so
the
ability
just
to
be
transparent
in
what
you're
thinking
in
order
to
sort
of
have
a
perspective
and
contribute
to
an
issue
and
mr
by
by
providing
some
direction
and
and
opinion
that
you
may
have
so
totally
agree,
and
I
know
that
you've
got
some
interesting
perspectives
on
how
iteration
and
collaboration
sort
of
inter
intersect.
B
Sure
so
get
a
quick
backstory
on
on
how
what
I'm
talking
about
came
to
be
so
we
previous
to
the
source
code
group,
I
was
in
the
editor
group.
One
of
the
big
things
we
were
working
on
was
snippets
and
particularly
version
control
of
snippets,
which
was
basically
taking
those
from
was
storing
those
in
a
database
model
tables
in
the
database
and
switching
that
over
so
they're
they're.
Getting
straight
it's
the
version
control
you
get
all
the
wonderful
things
that
come
with
git
now.
B
That
obviously
was
a
large
undertaking
that
wasn't
a
it
wasn't
a
one
milestoner
it
actually
spanned
almost
a
year.
So
at
the
end
of
that,
that
is,
that
has
now
been
implemented
in
its
place.
At
the
end
of
that,
we
did
a
retro
kind
of
look
back
on
on
how
we,
how
we
did
overall
and
one
of
the
things
that
came
up
was
was
the
iteration
of
it
and
we
actually
did
spend
a
great
deal
of
effort
breaking
things
down
into
small
things.
B
That
team,
in
particular
does
a
great
job
of
utilizing,
epics
and
issues
and
having
lots
of
small
things.
So,
on
on
surface,
it
would
seem
like
we
were
doing
a
great
job
of
iteration,
but
what
we
ultimately
kind
of
came
out
of
the
retro
was
that,
where
we
lacked
in
the
iteration
was
was
planning
so
both
from
a
little
bit
from
the
engineering
side
but
I'll.
Let
the
engineers
worry
about
that
from
the
product,
design
and
product
management
side
how
we
broke
down.
B
We
started
having
some
discussions
around
like
how
can
we
have
more
meaningful
conversations
with
engineering
to
spur
on
more
meaningful
iteration
because
it
doesn't
matter
if
you
break
an
issue
down
from
a
design
side
into
30
small
issues?
If
that's
not
how
it's
going
to
get
built,
you
know
the
efficiency
gains
that
you
get
out
of,
that
iteration
really
aren't
realized
so
trying
to
align
those
two
things
through
collaboration.
B
Yeah
a
little
bit
of
that
I
mean
there's
always
there
there
was
that
and
there's
always
the
you
know.
Nobody
has
the
crystal
ball
right.
So
I
think
a
lot
of
times
you
you
want
to
have
the
conversation
with
the
engineer
and
say
well,
hey.
How
can
I
break
this
thing
down
for
you
in
the
way
that
you're
going
to
build
it?
Well,
an
engineer
can
tell
you
that
easily
at
the
end,
when
they've
done
and
they're
building
it
right,
it's
very
difficult
to
take
a
year's
worth
of
work
and
say
here.
B
I
know
what
roadblock
I'm
going
to
run
into
six
months
from
now.
So
there
was
a
combination
of
that
of
of
just
like
what
is
the
mvc
like,
like
you
were
saying,
but
also
you
know
just
how
can
we
get
better
at
anticipating
those
kind
of
roadblocks
and
how
can
design
and
product
facilitate
a
world
where,
where
engineers
aren't
forced
into
more
roadblocks
than
they
would
naturally
run
into,
I
guess
is
the
best
way
to
put
it.
A
B
B
B
A
B
B
You
know
the
feature
set
that
you're
now,
inheriting
or
maybe
you
know-
maybe
it's
a
it's
a
new
thing
right.
Maybe
it's
a
new
feature
that
you're
talking
about,
and
this
would
also
apply
in
that
situation,
but
I
think
it
works
better.
As
an
example,
as
like
the
situation,
I've
been
where
I've
come
into
a
new
area,
new
set
of
engineers,
I
got
to
try
and
understand
how
to
work
with
them.
B
So
the
thought
was
was
to
find
a
template
to
facilitate
a
conversation
with
engineering
to
try
and
identify
pain
points
that
might
happen.
So
when
doing
design
work
you
can
you
can
then
design
around
those
things
or
at
least
know
what
they,
what
those
roadblocks
were.
So
really
all
that's
happened
was
that
was
a
was
a
little
bit
of
brainstorming.
Working
with
roman
and
marcel
roman
was
the
front-end
engineering
manager
on
editor,
and
we
came
up
with
with
a
series
of
questions
that
were
that
are
definitely
a
first
draft.
B
So
things
like
how
complex
is
the
code
base?
What
percentage
is
front
end?
What
is
back
end?
Is
it
broken
into
modules?
How
is
how
is
the
code
grouped?
What
areas
of
the
code
are
kind
of?
The
no
goes
right.
You
don't
touch
this
area,
it's
impossible
to
change.
What
areas
are
kind
of
open
for
interpretation
or
not
yet
defined
dependencies?
B
B
In
my
career,
where
you
have
like
a
list
page
and
you
have
you
know,
we
always
want
to
put
that
counter
at
the
top
right
like
say:
you're,
applying
a
filter
and
then
it's
you
know,
hey,
there's
367
issues
now
and
then
there's
always
that
conversation
three
weeks
later,
when
an
engineer
is
like
that,
will
ruin
the
performance
by
half
right.
It
will
or
double
the
time
the
ticket
loses
the
page
so
identifying
things
like
that.
You
know
up
front.
A
Yeah
this
this
makes
a
lot
of
sense,
and
I
this
certainly
something
that
I've
encountered
as
well
when
working
is
that
there's
a
number
of
technical
constraints,
there's
a
number
of
feasibility
issues
that
have
a
significant
impact
on
the
end
experience
especially
handling
data
whatever
it
may
be.
So
this
seems
like
a
really
nice
way
for
you
as
a
designer
to
sort
of
quickly
understand
those
those
constraints
up
front
in
order
to
incorporate
that
perspective
into
your
designs
to
start
out
with.
A
B
Okay,
so
the
first
one
like
how
complex
is
the
code
base?
That
one
is
it's
kind
of
a
ridiculous
question
right,
it's
impossible
to
answer,
and
the
answer
to
gitlab
is
always
it's
complex
right.
So
it's
kind
of
a
a
foolish
question
in
that
sense,
but
basically,
for
that
one,
I'm
looking
at
order
of
magnitude
you
know
is
this:
is
this
merge
request
right,
which
we
know
is
a
beast
or
is
this
like
feature
flags,
which
is
a
new
thing
and
it's
a
smaller
code
base
right?
B
So
it's
more
of
a
comparative
kind
of
thing.
Just
you
can
get
an
overall
sense
of.
Is
this
one
of
the
behemoths
here
in
get
lab
or
in
whatever
organization
that
you're
in
or
is?
It
is
a
smaller
thing
so
that
one's
really
just
kind
of
a
feeler
order
of
magnitude,
type
thing
percentage
of
front-end
and
back
end
that
one,
I
think
is
important
to
know
you
know
is
it?
Is
this
a
very
ui
driven
feature
right
if
it's,
if
it's
definitely
a
front-end
feature
or
front-end
heavy
code
base?
B
Well,
that
tells
you
that
you're
probably
going
to
have
a
lot
of
ui
associated
with
this,
and
if
it's,
if
it's
heavy
back
end,
you
know
a
lot
of
times.
Those
are
the
those
are
the
more
interesting
ones
right.
Those
are
the.
I
click
this
one
button
and
imagine
a
lot
of
magic
stuff
happens
behind
the
scenes.
You
know,
that's
that's
when
you
really
need
to
think
about
performance
concerns
and
understanding
the
flows
and
understanding
what's
happening
with
that.
B
B
B
If
you
can
start
understanding
what
modules
the
code
are
broken
into,
you
can
also
try
and
align
your
modules
to
that
or
actually
even
really
better
right
if
we
could
align
design
modules
to
code
modules
and
have
kind
of
a
reusable
thing.
You
know
you
start
thinking
about
like
well.
I
could
use
this
here
and
this
here
and
this
here
save
both
design,
effort,
engineering
effort
and
all
that
stuff.
So
that
was
really
about
more
that
kind
of
atomic
design
kind
of
thinking
the
areas
where
you're.
What
we're
talking
about
difficult
to
change?
B
B
Well
then,
it's
that
answer
of
yeah,
but
this
this
this
there's
this
technical
constraint
or
there's
this
historical
thing
to
that.
So
really
it's
just
identifying
those
areas
up
front
that
you
know
are
not
that
anything
can't
be
changed
right.
I
think
I
think
especially
here
at
get
lab
right
like
we're.
B
We'll
take
it
on
if
we
need
to
take
it
on,
but
just
know
that
some
areas
are
going
to
require
more
effort,
and
you
might
think
that
this
is
a
one
milestone
thing,
because
it's
not
that
big
of
a
change,
but
that
really
means
that
there's
four
milestones
of
additional
effort
that
that
would
generate
and
then
the
areas
that
are
easy
change
right.
Those
are
quick,
wins
right,
it's
like!
Where
can
I
live
in
a
world
where
you
know?
B
So
if
you
can
find
areas
like
that
great
and
then
what
are
the
dependencies
that
one's
great,
because
that's
an
engineer
telling
you
what
designer
you
need
to
go
talk
to
right,
because
if
that
engineer
knows
it's
dependent
on
this
area
well,
then
you
just
look
up
that
area.
You'll
find
that
designer-
and
you
know
when
I
touch
this.
I
need
to
go
talk.
You
know
to
that
associated
designer.
So
that's
that
to
me
is
a
great
driver
of
collaboration,
because
the
engineers
know
the
code
base.
B
They
know
what
depends
on
what
they
can
tell
you
a
lot
of
times.
You
know
you
might
not
know
that
this
was
affected
by
this,
but
it's
there
in
the
code.
You
know
there's
no
way
around
it.
So
that's
a
good
good
trick
to
get
some
insights
on
the
collaboration
and
then
perform
the
concerns.
I
think
talked
about
that
one
a
little
bit,
but
there's
always
those
gotchas.
B
A
B
I
would
think
like
if
you
know,
if
there's
a
new
feature,
there's
no
new
something
right.
Hopefully,
eventually
in
your
stage
group
you
would
have,
and
you
you
yourself,
a
designer
would
be
able
to
answer
these
questions.
So
I
guess
the
easiest
way
to
answer
that,
in
my
opinion,
would
be
whenever
you
don't
know
the
answers
to
these
questions
right.
B
B
A
Yeah,
that's
that's
really
interesting.
I
think
this
is
something
that
I'll
definitely
be
paying
close
attention
to
as
well,
because
I
think
my
team
would
definitely
benefit
from
it.
What
I've
noticed
here
is
that
this
actually
pairs
really
nicely
with
the
perspective
that
hayana
was
talking
about
in
in
our
previous
conversation,
and
what
this
is
doing
is,
if
you
have
design
and
implementation,
this
is
basically
bringing
some
of
that
implementation
knowledge
into
the
design
side.
A
So
you
as
a
designer
have
a
little
bit
of
that
in
your
head,
while
you're
making
the
designs
and
what
hayana
was
doing
was
saying
well
how
about,
if
we
create
an
easier
to
understand,
share
vision
that
all
the
developers
can
get
behind,
so
that
they
can
also
provide
input
further
up
on
the
on
the
design
side
on
how
implementation
may
go.
So
I
feel
like
this
is
like
a
really
interesting
combination.
A
Crossover
where
you
as
a
designer
are
able
to
empathize
more
effectively
with
the
engineers
and
what
they're
going
through
and
then
maybe
high
on.
His
side
is
more
like
here's,
how
you,
as
a
designer,
can
more
effectively
communicate
what
this
vision
should
be,
so
developers
feel
empowered
to
like,
as
you
were,
talking
about
before
be
transparent,
communicate
what
they
want
to
say
and
have
a
perspective
on
on
everything,
because
I
suppose
everyone
can
contribute
can
can
everyone
can
contribute,
and
that
means
that
design
everyone
could
be
a
designer.
A
Everyone
can
sort
of
have
a
perspective
on
on
some
how
something
should
be
shaped.
So
I
think
that's,
that's!
That's
really
complimentary.
So
I
really.
I
really
appreciate
that
so
got
a
couple
of
minutes
left,
I
suppose
I'd
love
to
know
like.
If,
if
there
is
a
piece
of
advice,
you
could
give
someone
around
collaboration
who's
a
new
joiner
coming
into
gitlab.
What
would
that?
What
would
that
advice
be.