►
A
B
B
B
From
the
company
I
was
working
at
a
lot
of
teams
were
geographically
dispersed,
and
so
it
created
this
tension
where
you
might
have
like
one
developer
in
washington
or
a
couple
developers
in
india
or
something
per
se,
and
you
had
the
rest
of
the
team
that
was
co-located
kind
of
doing
all
these
activities
and
stuff
next
to
each
other,
and
then
there's
this
gap.
There's
this
communication
gap,
this
knowledge
gap
between
different
team
members
and
then
extra
energy
has
to
be
invested
in
keeping
other
people
in
the
loop.
So
this
is
additional
synchronous
meetings.
B
A
Back
yeah,
so
yeah
two
two
key
aspects:
you're
sort
of
talking
about
there,
the
communication
aspect
so
getting
everyone
on
the
same
page
and
then
also
the
content
aspect
as
well.
So
the
creation,
the
sharing
the
collaboration
around
content.
So
I
suppose
it
would
be
interesting
if
you
sort
of
expanded
upon
the
differences
you
see
in
communication
styles
in
an
all
remote
company
versus
a
physical
company
and
also
the
difference
that
you
see
in
sharing
of
content
styles
as
well.
B
The
company's
coming
from
was
rather
restrictive
in
that
sense,
which
created
a
barrier.
So
you
know
it
took
like
a
year
just
to
get
envisioned,
so
it
took
a
while
to
be
able
to
remotely
collaborate
on
designs.
There
wasn't
really
a
method
to
do
so
other
than
sharing
sketch
files
back
and
forth,
which
was
fine.
B
It
was
just
a
lot
of
emails
and
it
was
hard
to
keep
up
with,
what's
the
most
recent
thing
or
running,
into
share
server
file
constraints
and
having
to
get
those
things
approved
so
not
having
some
of
the
easy
design
collaboration
tools
available,
made
cheap,
like
sharing
assets,
difficult,
a
lot
of
exporting
copy
pasting
screenshots
all
that
stuff,
which
we
still
have
to
some
extent
and
get
live.
It's
not
like.
We
don't
do
those
things
like
I'm
still
exporting
stuff
from
figma,
putting
it
into
a
gitlab
issue.
B
B
At
least
here
we
focus
on
trying
to
get
all
the
communication
within
git
lab
and
then
slack
kind
of
becomes
a
secondary
component
and
then
from
there,
it's
even
specifically
in
threading
in
different
channels
and
that
lack
of
understanding
of
how
to
use
the
platform
didn't
exist
in
my
last
company.
So
we
didn't
have
slack,
but
we
had
matter
most
that
pretty
similar
competitor
product
and
it
just
like.
Didn't
it
didn't
click
the
main
team
members
there
just
wanted
to
use
email
and
skype
messaging,
so
it
created
this
tension
of
like
well.
B
Where
do
we
talk
to
each
other
at
whereas
we
have
it
like
define
our
handbook,
how
everybody's
going
to
work,
but
there
it
was
kind
of
just
up
to
whatever
the
team
liked
to
do,
and
I
think
what
you
usually
found
was.
If
the
team
members
were
more
flexible
on
toolstack,
they
were
open
to
trying
things
like
mattermost
or
communicating
within
gitlab,
but
then,
when
it
came
to
other
teams,
you're
like
no,
we
just
like
email
and
skype,
and
so
that's
how
it's
going
to
be
so.
B
There's
that
aspect
of
it
and
then
obviously
there's
the
focus
on
synchronous,
in-person,
communication.
First,
I
think
one
of
the
unique
challenges
that
we
were
coming
up
against
was
we
had
a
lot
of
people
that
were
trying
to
transfer
domain
sets.
So
we
had
project
managers
trying
to
learn
how
to
become
product
managers.
B
We
had
front-end
engineers
trying
to
learn
how
to
become
designers
hell.
I
was
even
training
a
mechanical
engineer
how
to
be
a
designer
because
they
were
a
team
of
three
people
and
someone
had
to
at
least
appreciate
front
end
for
them
to
get
something
done,
and
so
that's
that's
partly
what
made
it
so
difficult
to
appreciate.
Asynchronous
collaboration.
B
A
Yeah,
don't
knock
engineers
becoming
designers,
because
that's
that's
how
I
got
into
it
anyway
yeah.
So
I
I
agree
with
you.
I
I
think
there's
sort
of
one
common
theme
that
sort
of
goes
across
all
the
different
topics
that
you're
just
talking
about.
There
was
sort
of
orthodoxy
so
like
deeply
held
beliefs
on
how
things
should
be
done.
A
So
I
think
there's
a
lot
of
hangover
that
you
get
in
from
different
disciplines.
Different
functions
within
different
companies,
which
are
like
email,
is
the
default
way
that
we
communicate
because
it
emails
is,
is
how
community
well
emails
and
meetings.
I
think
that
the
term
that
that
we
had
in
my
last
job
was.
A
Email,
email,
email,
meeting,
powerpoint,
that's
that's
like
the
bonus,
that's
the
modus
operandi
for
how
companies
collaborated
and
that
I
think
that's
like
a
really
it's
it's
just
something
that
a
lot
of
teams
a
lot
of
a
lot
of
different
individuals
held
on
to
and
it's
the
orthodoxy
that
deeply
held
belief.
That
needs
to
be
broken
or
re-evaluated
in
in
order
to
approach
remote
collaboration,
and
I
think
remote
collaboration,
there's
yeah.
A
You
need
to
sort
of
approach
it
from
first
principles
and
think
about
what
is
the
key
thing
that
we're
trying
to
achieve.
What's
the
job
to
be
done,
that
we're
trying
to
do
right
here
and
and
instead
yeah,
how
do
we?
How
do
we
not
replicate
that?
But
how
do
we
fulfill
the
same
job
in
a
remote
environment?
A
I
think
the
like
the
one
example
that
we
use
in
our
handbook
is
the
the
white
board,
like
the
there's,
no
good
replacement
in
the
in
the
remote
space
for
like
a
great
whiteboard
session
that
you
have
with
one
or
two
other
people.
However,
if
you
think
about
well,
what
does
that
whiteboarding
session?
Do
it
helps
you
to
in
a
low-fidelity
way,
get
some
ideas
out
and
communicate
some
concepts
in
ways
which
are
beyond
just
words,
you
can
visualize
stuff
quite
quickly.
What
does
it
help
you
to
do?
A
B
B
Helped
me
more
critically
look
at
my
own
work,
whereas
because
everybody
was
working
in
a
co-located
sense
in
my
last
company,
you
didn't
get
that
exposure,
so
you
were
just
kind
of
like
working
in
your
bubble
until
we
got
to
like
the
ux
showcase
situation
where
it's
like.
Oh
now,
people
are
showcasing
their
work
and
you
don't
get
to
you.
Don't
really
see
everything
else
that
happens
in
between
so
you're
missing
out
on
the
little
things
like.
How
did
this
designer
progress
on
this
idea?
B
How
did
they
work
with
their
product
manager
on
figuring
out
what
the
right
scope
was?
How
do
they
go
about
testing
with
users
and
informing
their
design
decisions?
That
way,
I
can
see
how
that's
happening,
because
everybody's
kind
of
sharing
that
either
through
different
forums
and
synchronous
meetings
or
even
asynchronously,
in
our
co-working
channel
or
within
issues-
and
so
that's
been
really
really
cool
to
see.
B
I
think
the
area
that
is
difficult
still
for
asynchronous
work
is
working
with
junior
designers
or
even
newer
people
coming
in
where
they
don't
have
the
skill
set
to
know
how
to
start
working
functionally
in
figma
right
off
the
bat.
Maybe
they
don't
even
understand
basic
design
heuristics,
you
know,
they've
talked
about
them
a
little
bit
at
work
or
sorry
at
school
or
something
and
they
like.
B
So
I
saw
a
lot
of
growth
in
the
novice
designers
that
I
was
working
with
at
my
last
company,
because
you
know
we're
going
from
zero
to
like
functional
pretty
quickly,
at
least
where
they
could.
They
could
even
work
in
this
type
of
environment,
but
I
think
it
might
be
a
challenge
to
see
someone
come
in
with
very
minimal
knowledge
at
all
at
the
domain
and
then
try
and
get
them
functional
without
having
a
dedicated
peer
to
work
alongside
them.
But
I'm
I'm
interested
to
see
what
you
think
about
that.
A
I
agree:
yeah,
I
think,
having
more
junior
designers
come
in
and
learn
the
craft
design
in
an
all
remote
context
is
actually
quite
a
challenging
thing
yeah
and
what
I
feel
or
why.
I
feel
that
is
there's
often
two
two
types
of
learning
that
people
describe
or
two
types
of
two
types
of
learning
through
communication.
A
There's
there's
explicit
knowledge,
which
is
knowledge
which
is
documented
and
written
down,
or
you
have
a
slide
deck
or
whatever
for
it,
and
then
there's
tacit
knowledge,
knowledge
which
sort
of
individuals
know
through
and
and
they
sort
of
display
through
their
actions,
but
they
don't
necessarily
sort
of
alright.
They
aren't
able
to
necessarily
like
describe
it.
So
this
is
why
designing
and
pairing
senior
designers
and
junior
designers
together
is
so
effective
because
it's
almost
like
a
an
apprenticeship.
A
Sometimes
they
you're
able
to
describe
to
them
some
of
the
some
of
the
the
heuristics
or
principles
that
you're
you're
talking
about,
but
then
through
just
action
and
practice
and
seeing
the
other
person
at
work.
They're
also
able
to
to
learn
some
of
the
more
tacit
areas
and
I
feel
like
in
the
remote
context,
we're
able,
like
we've,
got
the
explicit
down
and
in
fact,
we've
got
the
explicit
down
to
the
to
the
point
where
there's
the
the
issue
of
balancing
signal
and
noise,
but
the
the
tacit
areas.
A
The
areas
where
you're,
just
like
a
person
didn't
describe
to
me
what
I
should
be
doing
there.
But
I've
learned
something
because
of
the
way
that
they've
approached
a
problem
or
something
like
that
when
working
individually
and
working
remotely
that
sort
of
slips
between
between
the
cracks.
So
it's
an
area
that
I'm
interested
in
in
exploring,
but
I
I
just
don't
know
where
to
start
so
yeah.
I
wonder:
do
you
have
any
any
thoughts
on
that
distinction
that
I
made
there.
B
B
A
B
B
Yeah,
definitely
so
something
that
we
recently
got
approved
was
to
start
using
more
of
usertesting.com.
So
we
started
getting
some
seats
available
to
that.
I've
very
heavily
relied
on
the
in-person
qualitative
feedback
in
the
past,
because
it's
usually
well
at
least
my
last
company
is
very
easy
to
get
most.
The
apps
we
were
designing
were
internal,
so
you
know
it
was
like
shoulder
tapping
an
engineer
somewhere
getting
their
feedback
and
continuing
on
which
was
super
great.
The
challenge
now
is
with
gitlab,
because
it's
a
much
more
scalable
product.
B
B
B
What
might
that
be
worth,
and
mike
had
reminded
me,
even
that
it's
not
even
even
necessarily
about
the
fact
like,
oh
yeah,
this
idea
is
validated
or
invalidated,
but
like
what
are
the
learnings
that
come
alongside
it?
Sometimes
those
are
even
hard
to
quantify
so
consider
that
when
you're
doing
these
on
moderate
tests,
even
if
you
don't
change
your
design
direction
at
all,
you
might
have
learned
something
along
the
way
and
that
in
itself
is
valuable.
A
B
Yeah
sure
so
I
think
asynchronous
collaboration
works,
super
great
for
design.
I
think
some
really
cool
ways
that
I've
seen
it
are
just
these
threads,
that
we've
built
within
gitlab
issues
to
solicit
feedback
and
the
way
that
we
can
carry
in
designs
to
and
from
figma
helps,
simplify
like
the
workflow
for
sure,
and
these
tools
will
only
continue
to
get
better
over
time
as
users
use
them
more
and
provide
that
feedback.
B
It's
obviously
like,
if
you're
using
our
figma
plugin
to
work
with
gitlab,
please
continue
giving
us
feedback
on
design
management,
and
likewise
you
know,
I
think
it
does
a
really
great
job
in
trying
to
make
it
a
goal
and
a
value
for
people
to
grow
their
remote
skill
set.
I
think
that's
something
that
my
last
company
didn't
focus
on
at
all.