►
From YouTube: Geo PM/EM Discuss Collaboration and Empathy
Description
Fabian (Group Product Manager, Enablement) and Nick (Engineering Manager and Acting PM, Geo) discuss cross-functional collaboration and empathy-building on the Geo team.
A
Yeah
you're
doing
it
all
and
you're
doing
amazingly
well,
so
we're
here
to
talk
about
how
we
work
with
each
other
as
a
product
manager
and
an
engineering
manager
who
also
is
working
a
little
bit
as
a
product
manager.
So
it's
going
to
be
a
little
bit
all
over
the
place,
if
you're
interested
in
learning
how
to
use
a
more
sort
of
kanban
style
of
working,
we
have
another
video
on
our
process
or
planning
process
how
we
use
our
kanban
board.
A
So
I
think
there
are
a
couple
of
interesting
things
to
talk
about,
because
I
think
this
came
up
as
a
question
regarding
how
do
we
prioritize
feature:
work
against
tech,
debt
and
things
that
are
maybe
sort
of
a
little
bit
more
sort
of
closer
to
the
engineering
organization?
And
how
do
we?
How
do
we
make
that
work
and
how
do
we
make
these
calls
together?
Because
it
is,
I
think,
often
thought
of
that.
Sometimes
engineering
and
product
management
has
a
bit
of
tension.
A
B
It's
often
viewed
as
as
there
being
some
tension
between
product
and
engineering,
and
I
think,
ideally,
it's
a
healthy
tension
where,
where
product
is
the
dri,
for
I
often
hear
it
as
product
is
the.
What
and
engineering
is
the?
How
and
I
think
that's
that's
true
to
some
extent,
but
I
don't
think
we
should.
B
Engineering
is
the
dri
when
it
comes
to
how,
but
I
think
ultimately,
both
functions
are
working
towards
the
same
goals
of
of
improving
the
product
and
and
delivering
value
to
our
customers
and
and
therefore
both
both
functions
should
have
empathy
for
for
what
the
other
is
is
doing,
and
I
think
if
I
were
to
boil
it
down
to
one
word,
to
summarize
how
an
effective
em
pm
or
product
engineering
collaboration
should
look
like
it
would
be.
Empathy.
A
A
I'm
you
know
somebody
like
a
software
engineer.
You
know,
proposes
to
work
on
a
specific
item
of
technical
debt
and
I
have
these
grand
plans
for
a
new
feature.
That
is
really
important
and
product
produces
value,
and
it's
it's
not
hard
for
me
to
understand,
or
it's
hard
for
me
to
understand
why
somebody
would
even
care
about
it.
It's
clearly
not
very
exciting,
but
when
we
allow
opportunities
to
ask
questions
and
learn
about
that
perspective,
sometimes
what
happens?
Is
you
start
to
see?
A
A
You
know
there
are
tons
of
issues,
things
are
brittle
and
then,
when
you,
when
you
gain
this
understanding,
it
makes
it
all
of
a
sudden,
maybe
like
a
lot
more
valuable
to
address
in
the
short
term
or
in
the
long
term,
and
I
think
if
you
you
know,
if
you're
not
in
a
position
where
you
are
interested
in
those
perspectives,
then
you
know
it
becomes
a
a
fight.
It's
like.
Why
are
we
not
looking
at
these
bugs?
Why
aren't
are
we
not
doing
this
faster?
B
Yeah
yeah,
I
I
agree,
I
think
it's
you
have
to
view
the
the
team's
work
and
and
the
product
groups
work
holistically,
and
so
I
think,
there's
a
subtle
mind.
Shift
mindset
shift
to
be
made
in
changing
this
thinking
around
our
priorities
and
their
priorities
or
my
priorities
and
their
priorities
to
our
priorities.
So,
even
recently
in
in
some
discussion
about
this,
I
it
may
have
been
a
survey
question.
I
think
it
was
something
along
the
lines
of
like
do.
B
Might
might
be
the
thing
to
prioritize
over
this,
this
refactoring
that,
yes,
would
have
some
improvements,
but
maybe
could
be
delayed
a
little
bit
longer,
because
it's
because
there
could
be
a
bigger,
immediate
impact
from
delivering
on
this
improvement.
I
think
it
just
has
to
be
this
open
dialogue
where
there
is
shared
understanding
and
empathy
to
ultimately
come
to
some
sort
of
prioritization.
Of
of
these
different
factors.
A
I
think
that
that
goes
a
very
long
way
actually,
and
I
think
it's
that
does
not
mean
that
I,
as
a
product
manager,
get
to
decide
how
something
is
to
be
implemented
right.
I
think
that's
those
are
still
things
where
I
trust
the
engineering
organization
to
do
their
best
and
deliver
that
work
just
as
much
as
I
trust
our
designer
to
make
the
right
design
decisions,
and
I
think
I
think
that
also
helps
to
you
know-
develop
this.
A
This
trust
that
you
know
people
act
with
good
intentions
to
you
know,
do
the
the
right
thing
for
our
customers
and
I
think
that's
that's,
really
important
and
then
sorry.
The
other
thing
I
wanted
to
say,
which
is
something
that
you're
doing,
which
I
think
is
super
super
amazing,
is
we
have
a
rise
framework
for
prioritizing
work.
A
For
example,
we
use
it
mainly
for
longer
term
initiatives,
and
you
know
I
can
I've
used
that
for
myself
in
the
past
as
a
pm,
because
you're
looking
at
you
know
reach
impact,
confidence
and
effort,
and
it's
useful
in
that
way.
But
we've
we've
opened
that
up
now
in
an
asynchronous
way
to
the
entire
team
and
we're
trying
to
take
in
the
assessments
from
from
everyone
and
we've
had
a
team
member
raisin,
a
new
epic
that
they
believe
is
going
to
be
valuable.
A
That
is
protected
and
I
think
see
why
they,
that
is,
to
allow
the
space
to
actually
express
those
opinions
without
sort
of
repercussion
in
in
a
negative
way.
I
think
that
is
that's
really
important
and
I
think
we've
had
a
number
of
of
instances
in
geo
where
that
actually
has
led
to
some
very
significant
positive
outcomes
for
our
customers.
B
Yeah
yeah,
that's
a
great
example,
and
I
think
it
also
goes
to
highlight
in
that
specific
example.
It's
tech
debt,
but
it's
also
potentially
simplifying
the
installation
of
geo.
If
we,
if
we
can
get
rid
of
this
tech
debt
and-
and
I
think
from
I
think
often
it's
sometimes
it
can
be
viewed
like
well
tech
debt.
Is
it
really
this
you
know?
Should
it
really
take
priority?
B
It
could
probably
wait
a
little
longer,
but
I
think
if
we
take
the
longer
term
view
on
things
and
and
consider
tech
that
type
of
work
in
in
that
context,
it
often
does
translate
to
a
business
case
right
like
improving.
These
queries
now
potentially
saves
us
a
lot
of
trouble
down
the
line
and
makes
the
product
a
lot
better
in
the
long
run,
even
if
you
could
have
put
it
off
for
a
couple
more
months.
A
You
know,
serve
our
customers
better
and
we
would
accelerate
overall
increased
velocity
and
yeah.
That
was
balanced
with
delivery
along
the
way
of
of
things
and
features.
But
sure
you
know
it's
it.
You
know
it
prioritized,
maybe
some
things
that
you
could
traditionally
think
of
as
take
that
or
or
with
that
lens.
A
A
A
B
B
Yeah
I've
appreciated
sitting
in
on
those
calls
and
gaining
an
appreciation
for
for
the
job
that
product
not
only
product
but
also
the
sales
organization,
does
in
in
communicating
the
value
of
gitlab
to
our
customers
and
trying
to
understand
what
they're,
what
they're
trying
to
accomplish,
and
I
think
on
the
flip
side
of
that
I've
appreciated
you
as
a
product
manager
trying
to
understand
the
technical
aspects
of
the
product
a
little
better,
and
it's
not
that
you're
getting
like
super
deep
into
the
code
or
anything.
But
you
are.
I.
B
I
think
I've
noticed
that
you
you've
tried
to
understand,
what's
happening
in
geo
at
a
deeper
level
than
then
you
maybe
need
to,
but
it
really
helps
that
you
that
you
put
in
that
effort
and
then,
when
you
are
then
talking
through
some
of
these
some
of
these
debt
type
of
issues
that
that
are
being
raised
by
the
engineering
team.
I
think
you
you
gain.
You
have
a
better
appreciation
for
what's
being
communicated
and
how
that
ties
to
value
ties
to
customer
value.
B
So
so
I
think
it
definitely
goes
both
ways
and
the
other
example
I
will.
I
will
point
to
that.
That's
kind
of
tactical
and
that
I
think
I
think
people
could
try
out
is
that
you
also
have
done
a
nice
job
of
in
our
weekly
calls
having
this.
We
we
mentioned
that
we
walk
the
board
and
we
have
a
video
about
how
we
do
that
about
how
we
go
through
our
kanban
board
every
week.
But
at
the
end
we
turn
off
the
recording.
B
And
then
you
give
a
quick
10
minute
debrief
on
the
most
notable
customer
and
support
things
happening
that
week
or
over
the
or
what
happened
the
week
before
and
maybe
what
what's
up
coming,
and
so
everybody
on
the
team
gets
a
sense
of
yeah.
Just
what
are
some
of
the
things
our
customers
are
facing?
What
what
are
some
items
that
that
might
need
our
attention?
If,
if
support
escalates
them-
and
I
think
it
just
further-
strengthens
that
relationship
between
the
engineering
team
and
product.
A
A
You
mentioned
you
had
a
great
call
with
a
professional
services
engineer
who
was
able
to
contribute
a
lot
to
you
know
their
like
explain,
sort
of
their
experience,
building
a
complex
deployment,
and
you
know
those
things
matter,
and
I
think
that
that
is
really
really
important
and
so
investing
the
time
in
in
those
relationships
ultimately
will
help
us
get
better
prioritization
and
so
that's
by
building
empathy
and
so
and
then
use
kanban
or
or
whatever
else
works
the
tools.
You
know,
I
think,
that's
the
that's.
The
the
other
thing.
B
But
I
I
do
think
yeah,
it's
yeah
you
can
think
of.
You
can
try
to
think
of
the
the
best
processes
to
make
your
prioritization
and
collaboration
really
efficient.
But
if
you
don't
sort
of
have
that
baseline
level
of
empathy,
building
and
trust
with
your
counterparts,
I
don't
think
you're
going
to
get
as
much
out
of
those
types
of
tools
like
our
kanban
board
and
weekly
scheduling
process
yeah.
I
agree.