►
From YouTube: PMs on collaboration | GitLab Design Talks
A
B
A
B
Oh,
she
leaves
okay,
I'll
I'll,
say
something
okay.
So
I
think
in
my
experience-
and
I
was
a
bit
shocked
to
be
in
a
positive
way
when
I
started
the
kid
lab
when
I
started
it
was
sort
of
two
days
before
the
contribute
conference
in
new
orleans,
and
it
was
all
very
exciting.
But
the
first
thing
that
I
really
noticed
is
that
you
can
collaborate
across
the
company
essentially
anywhere
it's
encouraged
and
things
are
editable.
B
So
I
think
that
is
sort
of
my
that
was
my
my
first
impression
of
gitlab
and
I
guess
by
now
I'm
pretty
used
to
it
and
I
didn't
don't
really
think
about
it.
But
when
I
tell
other
friends
of
mine
who
work
in
different
companies
that
you
can,
I
don't
know,
go
into
the
finance
handbook
and
make
a
change
and
then
collaborate
with
whoever
is
responsible
on
on
that
and
explain
it.
That's
just
fine
people
are
a
little
bit
blown
away
as
like
this
is
possible.
C
Gitlab
is
my
first
remote
job,
so
collaboration
gitlab
is
doing
a
really
nice
job
and
it
I'm
used
to
a
work
setting
where
not
only
do
you
need
to
go
to
actually
physically
to
someone
to
get
them
to
collaborate,
you
usually
need
to
to
show
them.
What's
in
it
for
them,
and
in
gitlab
it's
a
little
bit
different
everyone's
just
really
happy
to
collaborate
together.
C
I
think
the
fact
that
we
have
a
single
product-
and
everyone
understands
that,
every
effort
that
we
do
ultimately
benefits
our
users,
which
are
all
the
same
regardless
to
whatever
stage
we're
in,
is
also
a
different
mindset
in
that
sense.
I
also
love
the
fact
that,
besides
that
you
can
collaborate
with
anyone
inside
the
organization,
so
not
only
your
team
cross
stage,
etc.
C
You
can
also
collaborate
with
with
the
community,
which
is
amazing,
and
it's
a
very
unique
experience
to
have
all
this
insight
and
conversations
with
the
actual
users
that
use
it
in
a
day-to-day
and
not
only
conversations,
people
contribute
code
and
they
contribute
to
our
product
to
make
it
better.
So
I
think,
that's
a
very,
very
unique
situation
in
gitlab
and
one
that
I
am
blown
away
at
like
every
single
day
that
I
that
I'm
working
here.
B
Yeah,
I
second
that
I
think
community
contributions
are
kind
of
magical,
sometimes
folks
come
in
and
you
know
assign
an
issue
to
themselves
and
then
start
working
on
it
because
they
feel
it's
important
to
them
or
they
enjoy
it,
and
there
may
be
many
different
reasons
for
doing
it
and
as
a
product
manager
a
little
bit
like.
Okay,
that's
that
has
not
happened
to
me
at
a
different
company.
A
Nice
yeah
this
is
this-
is
sort
of
like
a
common
theme
that
keeps
on
popping
up
in
these
discussions.
Around
collaboration
is
that
our
our
values
are
like
so
drastically.
Our
other
values
are
so
drastically
related
to
collaboration.
So
you
talked
about
before
the
fact
that
you
can
sort
of
create
an
mr
and
then
everyone
sort
of
collaborates
around
that,
mr
as
they're
reviewing
it
and
so
on.
A
So
the
fact
that
results
is
sort
of
like
we
have
such
a
bias
for
action
and
results
ties
into
collaboration
is
such
a
big
deal
for
us,
and
the
fact
that
we're
also
working
with
an
audience
and
that
audience
is
participating,
transparency
and
and
collaboration
is
is,
is
huge.
So
it's
really
interesting
and
it's
something
which
I
found
quite
unique
as
a
t
like
in
the
team
context,
but
as
also
as
a
designer
like
designing
with
an
audience,
is
also
really
interesting.
A
So
yeah
totally,
it
totally
agree.
So
I'd
love
to
get
both
of
your
insight
on
how
you
how
you
feel
collaboration
between
the
different
disciplines
happens
within
gitlab.
So
how
do
your
teams
particularly
collaborate
when
we
have
a
setup
of
six
to
eight
engineers,
one
product
manager
and
one
designer
in
each
sort
of
feature
team?
How
does
that
typically
work
within
within
each
year?
Teams
and
we'll
start
with
worries.
C
Yeah,
so
I
think
within
the
team,
there's
still
a
sense
of
a
team,
so
you
know
when
we
go
into
the
agile
aspect.
Every
team
member
contributes
to
the
team,
so
the
discipline
doesn't
it's
not
that
important
everyone
is
is
working
to
towards
a
common
goal
according
to
their
skill
sets.
So
I
think
that's
very
natural
also
when
they
setting.
What
I
think
is
you
know.
C
Extra
bonus
points
that
we
get
from
working
at
gitlab
is
the
collaboration
that
we
get
from
different
teams,
which
may
be
due
to
the
fact
that
we're
dog
fooding
our
own
features.
So
we
have
another
team
working
on
our
own
features,
asking
or
even
contributing
to
to
a
common
goal
that
they
need
and
and
work
to
improve
the
products,
regardless
of
what,
if
it's
released
to
users
already.
C
So
I
think
dog
footing
aspect
is
super
interesting
and
specific
to
gitlab
and
also
again
because
we're
a
single
tool,
our
users,
don't
really
differentiate,
they
don't
know
what's
in
the
release
stage
or
what's
in
geo,
maybe
they
do,
but
but
it's
really
there's
a
lot
of
gray
areas
that
could
be
considered
any
stage
or
multiple
stages.
So
we
get
brought
into
a
lot
of
conversations
for
other
stages
and
also
to
customer
calls
that
may
not
be
specific
to
our
specific
domain.
A
Nice,
like
a
lot
of
t-shaped
knowledge,
where
you
have
a
very
specific
set
of
expertise
in
in
one
in
one
area,
but
also
general
expertise
in
in
the
rest
of
the
product
as
well,
and
I,
I
suppose
within
git
lab.
We
have
an
interesting
balance
when,
when
sort
of
how
we
prioritize
work
and
the
way
that,
like
the
the
different
trade-offs
that
we
make
in
order
to
prioritize
like
the
throughput
and
stuff
that
we
have
so
I
wonder
I
we
have
while
collaborating
with
other
teams.
A
Often
you
can
get
lots
of
different
information,
lots
of
different
perspectives,
but
sometimes
that
that
can
also
slow
down
the
pace
of
implementation.
So
I
wonder
how
do
you
strike
the
right
balance
between
collaborating
across
teams
whilst
maintaining
throughput
efficiency
and
sort
of
collaboration
within
your
team?.
B
It's
a
good
question.
I
think
one
thing
that
that
helps
is
that
I
think
collaboration
in
in
gitlab.
Is
you
ask
for
people's
input
and
their
suggestions,
and
that
is
extremely
valued,
but
gitlab
does
generally
and
teams
don't
either
decide
on
consensus.
Necessarily,
I
think
if
you
need
to
move
fast
and
you
have
a
lot
of
input
from
different
forces
because
we
have
directly
responsible
individuals,
people
can
still
say
this
is
the
way,
and
so
we,
I
think
that
helps
to
keep
us
move
fast,
because
we
also
iterate
that's
easier
to
correct
right.
B
It's
like
if
you
make
a
gigantic
change
right.
It's
often
the
cost
is
really
high
of
making
a
wrong
call.
But
if
you
make
small
changes
in
small
iterations
you
can
you
can
collaborate
and
then
you
you
can
make
a
decision.
You
know,
depending
on
where
the
decision
is
and
then
actually
move
move
forward,
and
you
know
because
you
often
try
to
make
a
minimal
change.
You
can
course
correct
and
you
know,
move
in
into
a
different,
a
different
direction
as
well,
but
it
can
happen.
B
We
have
team
members
in
ukraine
and
in
brazil
and
on
the
west
coast
in
the
us
and
on
the
east
coast
and
in
europe,
and
so
currently
you
need
to
wait
a
little
bit
because
otherwise
you
can't
and
if
you
can't
wait,
you
need
to
be
transparent
about
that,
because
then
maybe
you
can't
actually
have
everybody
everybody's
input.
But
that
is
quite
rare
in
my
experience,
and
so
it
sometimes
takes
a
little
while
longer,
but
you
still
do
get
a
lot
of
sort
of
asynchronous
collaboration.
C
And
in
terms
of
how
this
affects
priority
and
other
things,
it's
not
very
different
than
what
we
as
pms
have
to
deal
with
anyway,
because
we
have
so
much
information
coming
to
towards
us
in
terms
of
functionality.
What
competitors
are
doing
some
new
emerging
technologies
that
we
need
to
do
you
know
market
cases,
macro
things
that
know
the
fact
that
it's
cross
stage
wouldn't
necessarily
affect
its
priority,
but
we
spms
have
to
be
always
in
listening
mode
to
know
what's
going
on,
and
then
we
need
to.
C
B
It
is
true,
though,
and
I've
experienced
that,
with
with
geo,
we
are
one
product,
and
so
sometimes
you
have
very
clear
dependencies
within
or
across
stages,
as
in
geo
can
do
something,
because
we
are
waiting
for
somebody
else
to
do
something
first
and
so
there.
Obviously,
you
need
to
have
a
discussion
about
priorities
and
be
very
transparent
on
why
you
know
another
team
is
required
to
do
something
and
how
that
affects
your
stage,
and
I
think
that
is
that
is
critical,
because
and
also
in
an
ideal
world.
B
These
dependencies
are
sometimes
like.
You
try
to
minimize
them
because
it
is
harder
to
organize,
and
so
ideally,
a
team
is
also
able
to
make
changes
without
having
to
rely
too
heavily
on
on
everything
else,
because
then
they
can
operate
a
little
bit
more
independently
as
well,
but
that's
not
always
a
reality.
A
Nice,
so
you
both
you
both
sort
of
highlighted
a
little
bit
about
our
asynchronous
working
style
there,
and
you
talked
a
little
bit
about
the
challenges
that
that
sort
of
comes
along
with
it.
I'd
love
to
know
a
little
bit
more
about
yeah.
What
are
some
of
the
pros
and
cons
that
you've
both
found
of
of
working,
asynchronously
and
remotely
at
gitlab.
C
Sure
I'll
start
so
the
pro
is,
you
can
work.
You
know
at
any
time
that
you
that's
convenient
for
you
and
you
don't
have
to
be
at
a
set
hour.
So
it's
really
really
good
to
be
flexible,
especially
during
coven.
Another
thing
is
that
everything
is
written
down
so
if
you're
brought
in
late
into
the
conversation-
or
this
happens
very
often
that
issues
move
from
one
team
to
another.
But
it's
like
a
two-year-old
issue
and
it's
really
easy
to
catch
up
because
everything
is
written
down.
So
I
think
that's
a
huge
advantage.
C
I
think
the
biggest
con
is
the
amount
that
nothing
is
immediate
and
you
need
to
wait
until
someone
answers
and
even
if
someone
answers
the
next
day,
you
know
sometimes
you're
in
the
flow
and
you're
focused,
and
you
just
really
need
really
quick
answers
and
in
a
regular
office
setting
you
would
just
tap
the
person
on
the
shoulder
and
say:
hey.
Can
you
just
help
me
out?
C
I
need
something
very
small,
so
that's
something
that's
we
can't
do
it
synchronously
and
I
think
that's
the
biggest
con
and
sometimes
things
get
too
complicated
to
discuss
asynchronous
and
and
then
you
need
to
have
a
synchronous
discussion.
So
not
only
did
you
pay
the
fine
of
waiting
for
the
answer
you
also
at
the
end
of
the
day,
need
to
follow
up
with
the
thing.
B
You
know,
look
at
this
gigantic
hair
ball
and
talk
with
each
other
for
15
15
minutes
and
get
onto
the
the
same
page,
but
that
is
sometimes
just
tricky
because
of
time
zone
differences.
So
if
that
happens,
for
example,
for
me
with
the
team
member
that
is
12
hours
ahead
of
me,
then
all
of
a
sudden
you're
looking
at
really
odd
times.
So
that
can
be
a
challenge.
B
I
think
there
again
having
some
consensus
and
a
good
understanding
of
how
to
approach
those
things
in
in
your
team
is,
is
important
and
also,
I
think
we
say
this
often
assume
positive
intent.
You
know
sometimes
sometimes
somebody
may
not.
You
know
be
in
the
right,
like
mindset
for
various
reasons
that
have
nothing
to
do
with
it,
and
you
know
having
a
a
quick
meeting.
Can
really
you
know,
get
you
on
the
on
the
same
page
quicker.
You
know
and
that's
context,
that's
not
so
apparent
in
written
statements
and
yeah.
B
A
I
think
individuals
have
a
responsibility
to
not
only
think
about
how
they're
communicating,
but
also
summarizing
and
synthesizing
some
of
the
information
as
they're
going
along
as
well,
because
some
of
these
threads
can
become
pages
long.
So
yeah
really
really
great
points.
I'd
love
to
just
we've
got
a
few
minutes
left
I'd
love
to
just
ask
you
both
around
a
little
bit
more
about
collaboration
with
design.
So
where
are
the
typical
sticking
points
that
you
feel
you
see
between
pms
and
design
collaborated
in
our
context?
B
B
I
think
sometimes
we
have
a
too
narrow
definition
of
what
design
means
right.
It's
like
the
designer
you
know
name,
you
know
like
creates
our
user
interface
and
that's
kind
of
it
and
they
deal
with
pyjama
issues,
but
I
think
we're
learning
and
getting
also
better
saying
well
designing.
You
know,
means
really
to
to
define
the
user
experience
that
you're
looking
for
right
and
that
has
to
do
with
how
how
the
product
feels
right,
how
certain
flows
work
right.
B
It's
not
only
the
graphic
of
user
interface,
it's
the
entire
experience
and
I
think
I
think
getting
that
perspective
in
sort
of
every
aspect
of
what
we
do
is
is
really
valuable
and
I
think
designers
can
bring
that
to
the
to
the
table
and
if
they
feel
empowered
to
contribute
and
collaborate,
not
only
on
sort
of
what
you
may
perceive
as
the
standard
design
problems,
but
in
other
areas
as
well.
I
think
that's
hugely
valuable.
C
C
C
It's
a
little
bit
more
challenging
this
relationship
because,
yes,
there's
a
lot
of
virtual
ways
to
do
this,
but
you
know
in
the
past,
when
you
just
go
into
a
room
and
start
writing
on
a
whiteboard
and
just
like
hanging
around
away
at
something
it's
very
short
and
the
asynchronous
aspect
is
more
challenging
and
and
it
takes
longer
to
understand
what
the
other
person
meant.
I
had
this
experience
and
I
joined
gitlab.
C
I
I
went
to
co-working
day
in
the
netherlands,
and
hayana
was
my
designer
at
the
time
and
we
sat
down
in
that
co-working
day
and
in
like
two
hours
we
sat
together.
We
hashed
out
what
what
would
take
us
at
least
three
weeks
asynchronous
to
doing
like
it
was
amazing.
So
I
think
that's
a
challenge
and
an
opportunity
that
we
still
need
to
figure
out
because
that
the
design
stage
does
take
longer
than
it
would
in
an
office
setting.
C
C
I
don't
know
if
there's
a
good
way
yet,
because
the
synchronous
meetings
are
never
good
for
everyone
in
time
zones,
but
I
think
if
we,
if
we
can
get
a
that's
an
opportunity
to
find
something
to
get
that
better
but
yeah,
I
think
I
think
the
designers
at
gitlab
are
amazing.
I
think
they're
gonna
do
an
amazing
job.
A
Nice
and
a
little
sneaky
tip
as
well.
We
have
a
slack
channel
called
ux
co-working
and
you
can
post
little
design
problems
there
and
you'll
get
the
perspective
of
of
any
designer
there.
And
then
you
can
also
like
spin
up
a
quick
zoom
meeting
as
well.
If
you
want
to
make
it
synchronous,
so
that's
that's
a
little
tip
and
we
have
two
minutes
left.
So
I'd
love
to
hear
just
if
you
have
any
advice
for
new
people
joining
gitlab
on
things
to
consider
around
our
value
of
collaboration.
C
B
Yeah,
there's
not
much
to
add,
I
think,
take
it
one
step
at
a
time
it's
going
to
be
very,
very
overwhelming
at
the
beginning,
but
everybody
is
helpful
and
also
if
you
feel
that
you
can
make
a
contribution
and
improve
something
wherever
it
is.
Just
do
it.
You
know,
don't
don't
feel
like
you,
don't
have
enough
knowledge
or
you
you're,
unsure,
there's
likely
going
to
be
some
some
discussion
and
collaboration
on
it.
It
may
or
may
not
happen,
but
definitely
just
do
it.