►
From YouTube: Darren Murph | Remote Team Essentials: How to build process and documentation into your culture
Description
A handbook-first approach to documentation is sneakily vital to a well-run business. While it feels skippable — inefficient, even — the outsized benefits of intentionally writing down and organizing process, culture, and solutions are staggering.
Conversely, avoiding structured documentation is the best way to install a low-level sense of chaos and confusion that hampers growth across the board. GitLab is intentional about documenting in a manner that creates a single source of truth.
Join Darren Murph, GitLab's Head of Remote, to learn how to build this into the fabric of your organization.
»SIGN UP FOR OUR NEXT EVENT«
http://bit.ly/2DGPnu0
» SUBSCRIBE FOR SIMILAR VIDEOS «
https://www.youtube.com/channel/UCpOiPAD4gNK0PifmtTOv6sQ?sub_confirmation=1
» REGISTER FOR THE LIVE EVENT DISCOUNTED TICKETS «
Get the Running Remote Conference 2020 pass with $200 OFF! https://runningremote.com/
» FOLLOW US «
Podcast: https://podcasts.apple.com/us/podcast/running-remote/id1364061071
Facebook: https://www.facebook.com/RunningRemote/
Twitter: https://twitter.com/RunningRemote
Instagram: https://www.instagram.com/runningremote/
LinkedIn: https://www.linkedin.com/company/running-remote/
A
A
So
Who
am
I
I'm
Darrin
now
I
work
for
a
company
of
over
1,200
people
spread
across
more
than
65
countries
with
no
offices
whatsoever.
So
even
our
executive
team
is
remote
and
I've
spent
my
entire
career
working
across
the
spectrum
over
them.
I've
worked
in
co-located
spaces
as
well
as
hybrid
remote
companies
and
now.
B
A
I've
learned
a
lot
about
documentation
over
the
years
and
just
how
vital
it
is
for
seamless
communication
in
a
remote
team
I'm
going
to
share
a
bit
about
how
github
does
that
and
then
parlay
that
into
how
you
can
use
some
of
those
best
practices,
no
matter
what
company
or
environment
that
you're
in.
So
let's
look
at
three
challenges
that
I
keep
very
often
when
it
comes
to
transitioning
to
a
remote
workspace.
The
actual
home
workspace
is
usually
a
challenge.
A
If
there's
not
a
physical
separation
between
work
and
life,
there's
the
communication
side
of
it
and
then
of
course,
mindset.
This
goes
to
the
reality
that
it's
only
a
part
about
tooling.
The
other
point
is
about
culture
and
mentality
around
implementing
it
and
trusting
the
team
that
you
cannot
physically
see
today.
A
We're
going
to
focus
on
that
middle
section,
communications,
so
process
and
documentation
is
all
wrapped
into
this
and
I
think
this
is
really
important
to
focus
on,
because
when
a
team
is
transitioned
into
remote
or
thrust
into
a
work
from
home,
environment
comms
are
one
of
the
first
things
to
fail.
You'll
see,
communication
silos
be
created
and
you'll
see
fragmentation
of
information
where
people
don't
know
where
something
is
happening.
A
projects
will
start
and
slag
picked
up
an
email
and
so
on
and
so
forth.
Without
a
really
sound
documentation
strategy,
communications
can
be
a
nightmare.
A
A
remote
team
to
document
document
document,
if
you
let
everyone
document
in
their
own
way,
you
create
this
kind
of
wild-west
of
documentation
where
some
people
were
documenting,
Google
Docs,
maybe
some
other
teams
at
notion.
Some
people
just
like
to
keep
a
running
draft
and
an
email
and
the
problem.
There
is,
if
you're,
not
prescriptive
about
what
communication
happens
in
what
channel
and
what
the
single
source
of
truth
is
for
team
line
documentation.
A
All
of
our
protocols
and,
of
course
there
are
1,200
people,
regardless
of
what
continent
they're
in
or
what
time
zone
they're
currently
in.
They
always
know
that
the
latest
and
greatest
information
is
in
that
single
source
of
truth.
So
we
have
a
culture
of
self
service
and
self
learning
where
you
don't
even
have
to
tap
someone
on
the
shoulder,
because
you
know
you
can
go
to
the
handbook.
A
The
handbook
is
what's
going
to
be
most
current,
we
actually
empower
everyone
in
the
in
the
company
to
make
a
merge
request
to
create
a
proposal
to
update
or
change
the
handbook,
and
then
it's
up
to
the
code
of
honor
or
the
directly
responsible
individual
of
that
section.
To
look
at
those
merge
requests
merge
what
is
relevant
tweak
what
might
need
some
tweaking
and
reject
what
is
available.
So
why
do
we
do
this?
The
biggest
reason
is
to
minimize
confusion
and
dysfunction,
and
if
you're
a
newbie
remove
team.
This
should
be
your
top
priority.
A
Stabilization
should
come
before
anything
else
and
there's
no
better
way
to
stabilize
a
team
than
to
rally
around
how
you're
going
to
document
how
the
actual
company
functions
as
well
as
what
the
values
are
and
what
the
culture
is
and
we'll
touch
on
that
in
a
bit.
So
what
do
we
do
with
this?
Well,
the
most
sizeable
challenges
when
you're
going
remote
was
keeping
everyone
informed
in
an
efficient
way.
A
So
the
one
here
is,
we
document
it
so
that
people
know
where
to
go
and
what
they'll
find
there
is
the
absolute
truth
until
it
has
changed
and
proposal
is
given
next
I
mentioned
this
earlier,
but
we
enable
everyone
in
the
company
to
contribute
to
documentation,
and
this
is
key.
This
transparency
may
feel
a
bit
unusual.
A
But
there's
great
power
and
empowering
everyone
to
contribute
to
making
the
handbook
better.
What
this
does
is
it
ensures
that
the
handbook
is
a
living,
breathing,
evolving
document
and
everyone
is
invested
if
only
the
executives
can
make
changes
to
the
handbook
and
anyone
else
kind
of
feels
like
it's
being
thrown
at
them,
instead
of
something
that
they
can
actually
contribute.
And,
of
course,
if
you
can
contribute
to
something
you're
more
likely
to
use
it
as
an
actual
reference
point.
So
how
do
we
do
this?
A
We
use
get
lab
the
product
we
use,
merge
requests
so
that
everyone
in
the
company
can
create
a
request
proposal,
key
word,
being
requests
and
then
assign
it
to
the
directly
responsible
individual
and
they
can
take
a
look
at
it
and
then
merge
something
to
the
handbook
or
edit.
It
ask
for
more
feedback,
so
on
and
so
forth.
A
So
one
other
thing
that
you
should
think
about
the
mindset
you
should
have,
if
you
really
want
to
make
documentation,
work
should
always
strive
to
answer
with
a
link.
So
let
me
explain
how
this
works.
In
practice,
we
have
a
new
hire
and
get
lab
and
they
join.
Then
someone
pings
me
on
slack
and
me
asking
you
a
question.
My
goal
is
to
be
able
to
find
it
in
the
handbook
copy
the
link
and
paste
it
back
to
them.
I
want
to
answer
them
with
a
link.
This
serves
many
purposes,
it's
very
efficient.
A
To
anyone
being
asked,
the
other
thing
is
it
pays
it
forward
and
it
plugs
knowledge
gaps,
because,
if
I'm
able
to
answer
with
a
link,
imagine
how
many
other
people
may
have
the
same
question
and
they're
also
able
to
find
the
information.
Not
only
are
they
able
to
find
it
quickly,
but
is
the
exact
same
answer
that
you
give
to
anyone
else?
So
you
don't
get
this
watered-down
answer,
or
maybe
an
answer
that
lacks
context.
Everyone
gets
the
exact
same
answer
so
by
default.
A
Everyone
is
on
the
same
page
because
they're
quite
literally
reading
the
same
page
as
the
answer
and
if
ever
you're,
given
a
link
as
an
answer,
it
creates
this
positive
flywheel
where,
if
ever
you
are
asked
to
question
the
order
of
events
is
answer
the
question
and
if
it's
not
documented,
let's
create
a
place
in
the
handbook
for
this
to
be
document.
It's
such
that
going
forward.
You
can
always
answer
with
a
ring,
so
I
want
to
walk
you
through
an
actual
real-life
example
here.
A
So
if
you
see
here
some
of
these
speech
bubbles,
these
are
pretty
common
questions
that
you
might
get
in
an
organization.
How
do
I
give
a
presentation?
What's
our
mission
statement?
What's
our
vision?
Do
you
have
time
to
walk
me
through
something
who
approves
this
I've
got
a
client
that
wants
to
know
about
something
it
does
anybody
have
a
slide
deck
or
does
anybody
have
a
template
and
the
typical
office?
These
kinds
of
questions
fly
around
the
room
at
rapid
speed
and
it's
very
inefficient
to
just
answer
these
one-off,
every
single
person.
A
So
we
solve
for
that
by
answering
it
through
a
documentation
process,
a
systematic
approach
to
documentation.
Then
we
disseminate
so
again
that
it
all
begins
with
a
merge
request,
and
so
the
screenshot
you
see
here
is
me
actually
answering
some
of
those
earlier
questions.
I
was
being
asked
about
evangelism
materials
and
I
wanted
to
be
able
to
answer
every
one
in
the
exact
same
way.
I
realized
that
this
didn't
exist
in
the
handbook
would
only
exist
in
hearsay
or
various
Google,
Drive,
folders
and
so
I
needed
to
solve.
For
that.
A
Systematically
answering
these
questions
and
I
was
careful
to
put
this
in
the
right
handbook
section
so
that
you
could
find
it
if
you
started
from
scratch
or
if
you
went
searching
for
it.
So
I
created
the
merge
request,
which
is
simply
a
proposal
to
add
something
new
or
change,
something
within
a
handbook
section
now
I
am
the
code
owner
for
that
section.
So
I
was
able
to
merge
this
request,
and
then
this
is
what
that
code
looks
like
now
that
it's
been
merged
in
the
handbook.
A
A
People
outside
of
get
the
transparently
see
how
we're
thinking
through
this-
and
these
are
the
assets
that
we're
giving
our
employees
that
transparency
is
really
key.
It's
a
core
value
it
get
lab.
Not
every
company
is
going
to
feel
comfortable
enough
to
put
their
entire
handbook
online.
There's
power
in
transparency,
even
if
it's
just
transparency
within
your
team
is
again.
This
ensures
that
every
employee
knows
that
they're,
seeing
the
same
thing
as
everyone
else
and
a
remote
team.
A
Everyone
on
a
level
playing
field
when
it
comes
to
knowledge
and
dissemination,
is
incredibly
important
in
getting
cohesion
across
the
team.
So
why
build
a
handbook
first
mentality
into
your
culture?
The
positives
are
numerous
to
begin
with,
remembering
stuff
is
really
hard,
so
writing
it
down
once,
instead
of
rehashing
it
a
hundred
times,
it's
just
a
better
way
to
live.
It
will
simply
heighten
your
quality
of
life.
It'll
make
your
company
a
lot
more
efficient
lots
of
meetings
paying
it
forward
and
it
actually
creates
a
self-service
approach.
A
So
you
want
to
implement
documentation
such
that
people
think
to
go,
find
the
answer
themself
first,
instead
of
interrupting
someone
else's
day-
and
this
goes
back
to
number
two
that
enables
people
to
have
more
time,
less
interrupted
time
for
deeper
work
and
as
your
team
scales
and
time
zones
become
fractured.
This
allows
people
to
get
access
to
things
24/7.
Instead
of
having
to
waiting
for
someone
to
wake
up,
it's
also
really
inclusive.
So
from
an
accessibility
standpoint.
A
Something
that's
written
down
is
much
much
easier
to
translate
and
it
also
allows
people
that
maybe
it's
not
their
native
language,
they're
able
to
sit
with
it
and
process
it,
whereas
in
a
verbal
conversation,
you're
usually
constrained
by
time,
solves
communication
silos,
it
solves
knowledge
gaps
and
it
solves
discoverability
issues
now
I
would
say
if
you're,
if
you're,
if
you
don't
have
a
handbook
right
now,
you
can
stand
one
up
that
will
typically
easily
you
give
you
skill,
add
pages
you
could
use
notion.
You
can
use.
A
Ask
all
that
I
would
encourage
you
to
look
for
one
that
involves
continuous
integration
and
development,
merge,
request
type,
because
that
empowers
everyone
to
make
a
change,
and
that
way
everyone
will
be
invested
in
it
and
don't
be
daunted
by
the
fact
that
you're,
starting
from
scratch
get
labs.
Handbook
is
over
5,000
pages
now,
but
it
wasn't
always
that
way.
It
started
as
one
page
and
writing
down
our
values.
A
A
Faq,
what
are
the
common
questions
that
people
have?
Maybe
it's
connecting
to
a
VPN
or
getting
access
to
certain
software
or
what
is
the
expensing
policy
if
you
now
beat
noise
cancelling
headphones
or
certain
urban
amick
equipment
to
work
well
at
home,
write
these
things
down,
give
people
a
resource
to
turn
to
and
also
create
a
feedback
mechanism
where
people
can
document
and
reversed
document
what
their
challenges
are.
A
All
remote,
not
info
so
here
you'll
find
our
remote
playbook,
which
is
a
PDF
with
a
starter
guide
on
emergency
planning,
as
well
as
a
starter
kit
for
workers
on
what
you
need
to
know
and
the
five
things
you
need
to
implement
right
away.
If
you've
been
thrust
into
a
work
for
the
moment
and
then
beneath
that
there's
a
lot
of
deeper
reading,
there's
over
30
guides
on
how
get
lab
thinks
about
everything
related
to
remote.
A
How
we
approach
asynchronous
workflows,
how
we
do
meetings,
how
we
look
at
hiring
and
compensation
across
the
globe,
everything
you
should
need
to
acclimate
and
actually
build
remote
into
your
plan.
Your
operational
strategy,
your
talent
strategy,
I,
know
a
lot
of
you
may
be
trying
to
stabilize
right
now,
but
working
through
that
stabilization
actually
lays
the
groundwork.
A
And
I'm,
going
to
close
with
this
I'm,
actually
really
really
optimistic
about
the
future
of
remote
I.
Think
that
we're
going
to
look
forward
in
six
or
twelve
months
and
we're
going
to
see
that
people
have
actually
taken
this
opportunity
to
be
couple
geography
and
work,
an
introspectively
look
at
what
their
identity
has
been
tied
to
and
if
it's
been
tied
too
tightly
to
work,
I
think
this
is
going
to
be
a
boon
for
communities.
A
I,
think
small
and
mid-sized
cities
are
going
to
see
people
transition
away
from
major
urban
centers
to
find
a
higher
quality
of
life,
better
air
quality,
better
schools
for
their
children
and
really
invest
in
some
of
these
towns,
where
they've
seen
their
population
erode
to
the
major
urban
centers.
But
people
have
moved
there
just
because
their
location
is
there.
I.
A
Think
what's
going
to
happen
in
this
process,
is
that
many
people
will
break
down
the
myth
that
this
job
can't
be
done
remotely
turns
out
a
lot
of
digital
jobs
actually
can
be
done
remotely,
and
if
companies
lay
the
right
infrastructure,
people
can
even
thrive.
Then
we
gain
that
time
that
they've
been
losing
to
their
commute.
I'll
spend
more
time
with
their
family
they'll
spend
more
time
in
their
community.
A
They
can
focus
on
things
like
getting
good
rest
and
exercising
and
cooking
hobbies
that
we've
sort
of
let
go
to
the
wayside
when
we
focus
so
tightly
on
weaving
our
identity
to
work.
So
I
obviously
am
very
optimistic
about
the
future.
I
think
what
happens
in
the
next
six
months,
it's
going
to
be
key
and
how
remote
is
viewed
henceforth
and
anyone
that's
in
a
remote
industry.
We
have
a
responsibility
to
show
the
way
to
those
who
have
been
thrust
into
this
environment.
C
A
Conflicting
info
submitted
by
different
people,
so
the
short
answer
is
get
labs,
get
lab.
The
product
is
core
to
our
handbook
being
the
way
that
it
is,
and
the
reason
for
this
is
source
control
and
version
control.
So,
if
you're
attempting
to
use
a
typical
wiki
as
a
company
handbook,
the
two
issues
that
you'll
find
as
we
try
to
scale
are
that
you
can't
really
have
a
safeguard
on
what
goes
in
it's
either
in
there
or
it's
not.
A
And
the
second
thing
is
because
of
that
most
of
the
time
it's
just
the
executive
team
that
has
access
to
it.
So
you
basically
have
the
executive
executives
adding
to
your
company
wiki
and
then
it
starts
to
decay,
because
not
a
lot
of
people
feel
invested
in
it.
So
with
git
lab
by
using
git
lab
the
product
to
actually
build
our
handbook,
we
actually
submit
a
merge
request
to
change
the
handbook,
and
this
is
how
we
control
whether
or
not
information
is
good
or
bad,
because
you
cannot
just
merge
something
into
the
handbook.
A
Unless
you
have
maintainer
access,
you
have
to
first
submit
the
merge
request,
which
is
a
proposal
to
change
something
in
the
handbook,
and
then
you
assign
it
to
the
code
owner.
So,
for
example,
if
I
wanted
to
propose
a
change
in
the
finance
section
of
the
handbook,
I'm
not
in
the
finance
team,
I
can
make
the
proposal,
but
then
I
have
to
assign
it
to
the
ultimate
directly
responsible
individual
in
the
finance
team,
and
this
could
be
a
couple
of
people.
A
Maybe
several
people
would
have
access
to
this,
the
control
or
the
CFO
things
like
that,
and
then
they
would
take
a
look
at
the
proposal.
They
could
then
edit
the
proposal
they
could
just
merge
it
if
it's
a
hundred
percent
ready
to
go
where
they
could
reject
it.
Give
me
feedback
something
like
that.
This
version
control
this
source
control
is
vital
to
making
the
idea
of
a
handbook
work
across
the
entire
company.
A
We
empower
everyone
to
make
proposals
and
changes
and
updates
to
the
handbook,
and
then
we
ensure
that
the
directly
sponsible
individuals,
the
code
owners
of
different
sections
of
the
handbook,
ultimately
have
the
power
to
merge.
So
that's
the
the
short
answer
and
we're
actually
building
a
suddenly
remote
handbook
for
companies
that
want
to
use
this.
If
you
Google,
suddenly
remote
handbook,
you'll
see
it
all
remote
dot
info
is
the
shortcut
to
get
there.
A
All
right,
the
next
question:
how
did
you
manage
to
keep
everyone
on
board
on
maintaining
the
documentation
and
making
sure
updates
to
their
updates
to
outdated
information?
This
comes
back
to
the
culture
that
everyone
is
invested
in
the
company
handbook,
and
this
is
absolutely
vital.
If
you
only
let
a
small
portion
of
your
company
add
changes
to
the
handbook,
it's
unlikely
that
everyone
is
going
to
feel
invested
in
it
that
everyone
is
going
to
feel
like
that's
where
they
should
go
for
information.
A
The
second
piece
here
is
that
the
handbook
is
get
lab
single
source
of
truth,
so
we
can't
actually
do
anything
at
get
lab
unless
we
read
it
in
the
handbook.
It's
the
single
source
of
truth
for
all
of
our
processes,
protocols
for
our
benefits
for
vacation
policies.
Everything
is
in
one
place,
company-wide.
A
So
what
happens
in
a
lot
of
companies
is
the
finance
team
will
have
a
handbook,
and
the
engineering
team
will
have
a
handbook
so
on
and
so
forth,
but
no
one
actually
communicates
between
departments.
So
the
finance
team
can't
see
what
the
handbook
looks
like
in
the
engineering
team,
an
HR
team,
etc.
So
a
lot
of
times
there's
do
there's
duplicate,
'iv
efforts,
so
the
engineering
team
documents
how
they
do
an
expense
report
and
then
the
HR
team
documents
they
actually
could
look
very
different.
A
And
now
you
have
double
effort
going
on,
so
how
we
ensure
that
it
is
an
active
living
breathing
thing.
Is
we
force
it
to
be
the
only
single
source
of
truth
and
that's
really
really
really
important,
and
for
companies
that
have
been
thrust
into
remote
I
get
it?
It's
gonna
be
a
little
bit
difficult
if
you've
kind
of
let
people
all
document
on
their
own,
but
getting
to
that
single
source
of
truth
is
horn.
A
A
If
we
don't
catch
this
internally
oftentimes
we
catch
it
internally,
just
because
it's
updated
hundreds
of
times
a
day,
so
somebody
inevitably
will
see
two
copies
of
it
and
then
they'll
just
make
sure
that
the
one
stays
is
the
single
source
of
truth.
So
in
this
case
you
would
make
a
merge
request
to
remove
a
duplicate
entry,
but
we
actually
have
a
handbook
team.
We
have
a
static
site,
editor
team
and
it
is
actually
part
of
their
job
to
make
the
hem
look
better
to
innovate
on
it.
A
C
A
Next
question:
how
do
you
know
what
the
right
amount
of
information
is?
This
is
a
great
question,
so
the
gate
lab
handbook.
It's
a
fully
open
source.
We
don't
have
an
internal
handbook
and
an
external
handbook
there's
only
one
handbook:
it's
publicly
accessible,
if
you
go
to
all
remote
info
that'll,
take
you
into
the
remote
section
of
our
handbook,
but
you
can
get
down
deep
in
the
rabbit
hall
from
there.
A
If
you
were
to
print
it
out,
it
would
be
over
5,000
pages,
which
is
a
lot
and
oftentimes
people
will
ask
me,
isn't
that
too
much
information
and
then
I
in
that
to
respond
to
that
I
say:
do
you
think
the
internet
has
too
much
information
which,
of
course
the
answer
is
no,
because
we
know
how
to
use
Google
to
find
the
information
that
we
need
when
we
need
it.
The
gait
lab
Handbook
is
no
different.
A
We
actually
have
a
gitlab
handbook
page
on
how
to
search
the
get
lab
handbook
like
a
prop
pretty
meta,
but
as
the
company
has
scaled,
we
have
heard
that
from
new
people
coming
in,
like
how
am
I
ever
gonna
read
5,000
pages.
So
we
have
to
remind
people
and
onboarding.
We
don't
expect
you
to
actually
read
all
5,000
pages.
We
want
to
just
make
sure
you're
equipped
with
the
right
search
tools
to
find
what
you
need
easily,
when
you
need
to
find
it.
A
You'll
find
it
get
lab
that
we
try
to
offload
as
many
things
as
possible
from
humans
to
documentation
across
the
company.
So
we
want
people
to
rely
on
the
handbook
and
reduce
their
mental
load
so
that
they
can
actually
use
their
mental
loeb
to
be
creative
things
that
only
humans
can
do
anything
that
can
just
be
written
down
and
documentation.
We
want
to
offload
that
it
frees
people
up
to
do
more
creative
things,
instead
of
just
remembering
where
something
is.
A
Where
do
I
start
in
building
a
handbook
where
things
can
be
missing
at
the
beginning?
So,
as
I
mentioned,
if
you
google
handbook
first
documentation
on
gitlab,
you
will
see
a
link
there
to
a
small,
rudimentary
project.
It's
called
the
suddenly
remote
handbook
where
you
can
basically
copy
that
repository,
create
a
git
lab
account
and
start
building
your
own
handbook
for
free,
using
that,
and
we've
already
laid
out
some
of
the
templates
that
you'll
need
to
get
that
done.
But
then
there's
the
the
thought
of
well.
What
do
I
write
down?
A
First
I
tell
people
don't
get
overwhelmed,
get
labs,
handbook
became
5,000
pages
over
years.
It
started
as
one-page,
and
so
even
if
you
start
with
one
page
you're
in
a
good
spot,
I
would
start
with
two
things.
First
is
write
down
your
values
in
a
remote
setting
a
company's
culture.
Are
the
values
they're
one
in
the
same,
because
when
you
don't
have
an
office
to
go
into
and
culture
isn't
defined
by
things
like
decor
or
personas
and
auras
in
the
room?
The
only
thing
you
can
ever
go
back
to
is
the
North.
A
Star
is
your
values.
So
if
you,
google,
get
lab
values,
you'll
see
that
we
have
six
core
values,
but
they
don't
stop.
There
you'll
find
thousands
of
words
in
between
all
of
those
values
called
sub
values
that
exemplify
what
a
value
looks
like.
How
do
you
live
a
value
in
a
remote
setting?
We
write
all
of
that
down.
That
is
key,
because
any
process
and
protocol
that
you
would
then
right
after
needs
to
always
map
back
to
the
values.
You
should
never
create
a
process
or
a
protocol
that
is
in
misalignment
with
your
values.
A
So
if
you
don't
write
the
values
down,
first,
you
have
no
foundation
in
which
to
build
process
and
protocol
on.
The
second
thing
is
just
an
FAQ,
especially
for
suddenly
remote
teams.
The
biggest
problem
you're
going
to
have
is
people
spread
out
everywhere.
Now
have
no
idea
who
owns
what
or
where
to
look.
So
a
communication
can
break
down
really
quickly,
so
it
could
start
as
a
simple
FAQ.
A
A
After
all,
this
is
over
and
I
assume
this
being
coded
19.
Where
do
you
think
remote
work
will
be
so
I
shared
a
little
bit
about
this
in
the
presentation,
but
I
actually
think
this
is
going
to
be
seen
as
a
pretty
incredible
pause,
a
pretty
incredible
Awakening
and
a
reset
button
that
humanity
as
a
whole
and
been
looking
for
for
a
really
long
time.
I
think
that
this
is
actually
accelerating,
accelerating
the
embrace
of
remote
by
at
least
10
years.
A
You
have
you
have
a
lot
of
companies
that
have
suddenly
found
themselves
able
to
continue
doing
business
remotely
and
if
you
would
have
asked
them
a
year
ago,
if
this
were
possible,
they
probably
would
have
said
no
or
it
would
have
taken
one
or
two
or
three
years,
but
because
we
were
put
in
this
situation,
humans
are
incredibly
adaptable
and
I'm
actually
quite
proud
of
humanity.
For
how
fast
a
lot
of
companies
have
adapted,
you
got
to
understand.
Companies
are
working
remotely
now
in
the
worst
of
circumstances.
A
It's
like
you
wouldn't
build
a
road
just
to
drive
on
it
for
three
months
and
so
I
think
people
that
are
paving
their
own
path
on
remote
right
now,
they're,
not
just
gonna,
stop
using
it
in
three
or
six
months,
I
think
it's
going
to
massively
democratize
work,
I
think.
The
second
order
of
this
is
people
will
start
questioning
whether
or
not
they
actually
need
to
live
in
a
very
dense
urban
center.
If
they
were
only
there
for
work,
they
can
move
somewhere
else
and
kind
of
invest
in
a
smaller
or
mid-sized.
A
Community
I
actually
see
this
longer
term
being
a
key
part
of
the
solution
around
reversing
world
depopulation.
I
think
this
is
massive.
We've
lost
so
much
culture
because
people
have
just
had
to
flock
to
urban
centers
for
work.
What
I'm,
seeing
now
is
the
the
antidote
to
that
I
think
we're
gonna
start
to
see
that
unwind
and
longer
term
much
I
think
that
people
are
going
to
not
soon
forget
how
important
community
is.
A
Next
question:
do
you
think
remote
focused
companies
are
more
innovative
than
non
remote
companies?
I,
don't
think
it's
I,
don't
think
it's
necessarily
dependent
on
remote
or
non
remote
in
terms
of
innovation
and
here's
the
real
reason
for
that
I
think.
For
the
most
part,
companies
have
been
remote
for
the
better
part
of
10
or
20
years,
even
companies
or
co-located
company.
A
But
the
truth
is:
we've
been
doing
virtual
work
for
years
and
years
we
just
haven't
been
calling
it
that
so
I
think
the
language
around
it
is
going
to
begin
to
shift.
All
companies
are
going
to
realize
that
there's
a
element
of
remote
to
what
they
do,
even
if
they
have
a
headquarters
and
I
think
this
is
a
really
good
moment
for
companies
to
be
honest
with
themselves
and
say
you
know
what
we
probably
should
implement
some
remote
first
practices.
We
should
force
ourselves
to
have
better
meeting
hygiene.
A
A
Next
question:
how
do
you
work
this
into
your
onboarding
so
that
new
staff
feel
comfortable
making
changes
and
requests
to
the
handbook
from
the
very
beginning,
so
at
gate
lab
you
actually
cannot
be
added
onto
the
team
page
until
you
do
it
yourself,
so
you
actually
have
to
make
a
change
using
get
lab
to
merge
your
own
face
and
profile
into
the
team
page.
So
we
start
you
pretty
pretty
early.
The
other
thing
is
we
utilize
something
called
an
onboarding,
buddy
and
I
actually
recommend
this
strongly
for
suddenly
remote
companies.
A
You
may
take
you
a
little
while
to
document
enough
of
your
processes
to
onboard
someone
in
a
way
where
most
of
the
burden
has
been
shifted
to
documentation.
But
the
thing
you
can
do
right
now
is
pair
any
new
hire
with
a
mentor
accompany
veteran.
That's
been
there
for
a
while.
You
share
one
zoom
link,
one
slack
name,
and
then
the
new
hire
can
ping.
A
This
person,
it's
their
onboarding
buddy
non-stop
24/7
as
long
as
they
need
to
onboard,
and
it
prevents
the
anxiety
of
who
to
ask
I'm
pinging
too
many
people
just
set
them
up
with
one
buddy.
You
build
that
rapport
and
then
that
person
connects
the
rest
of
the
dots
around
the
organization
and,
as
part
of
our
onboarding,
we
actually
have
the
buddy
ask
the
new
hire.
Is
there
anything
you
would
want
to
change
about
onboarding?
A
Is
there
anything
that
you
read
in
the
documentation
of
onboarding
that
wasn't
clear
or
you
think
could
be
better
and
that
is
actually
part
of
onboarding
is
to
take
a
hard
introspective
look
at
what
all
was
consumed
and
what
can
be
made
better
I
actually
helped
my
onboarding
buddy
add
a
new
requirement
for
onboarding
buddies,
believe
it
or
not.
She
joined
the
company
and
said
you
know:
I
really,
love
this
documentation
around
onboarding,
but
I
kind
of
missed
the
new
hire
orientation
and
it
dawned
on
me
that
we
have
a
new
lab
rachet
week.
A
A
You
essentially
create
the
virtual
Lobby
that
you
would
have
walked
around
in
a
co-located
space
and
she
loved
it
and
it
went
really
well,
and
so
we
added
that
now
it's
an
onboarding
buddy
responsibility
to
check
in
when
the
new
hire
and
and
basically
ask
them
hey
if
you
do
a
more
social
onboarding
experience.
If
so,
let's
start
up
start
a
zoom
link
and
get
the
other
new
lab
resume.
This
channel.
A
Next
question:
what
typical
turnaround
time
for
a
suggestion,
so
I'm
assuming
for
a
suggestion
in
the
handbook
totally
depends
there's
some
new
features
that
we
ask
that
we
add
to
get
lab
the
product.
We're
a
merge
request
will
be
started
with
just
a
nugget
of
an
idea
and
then
it'll
be
iterated
on
and
iterated
on,
and
changes
can
go
for
days
and
days
and
eventually
weeks
before
it's
actually
merged
into
production.
We
try
to
do
we
think
about
NBC's,
Minimum,
Viable
Change
and
we
really
embrace
iteration.
A
A
So
obviously,
that's
going
to
take
a
couple
of
seconds
where
some
of
the
product
features
might
take
a
couple
of
weeks
totally
dependent
on
what
you're
after,
but
we
try
to
make
it
as
easy
as
possible
to
for
people
to
work
handbook
first.
It
is
absolutely
a
challenge
to
continue
to
remind
people
to
work
handbook.