►
Description
One year ago, Stripe created a remote engineering hub - a virtual office for remote engineers, coequal with its physical engineering offices. Aditya Mukerjee, the Remote Hub Site Lead, will share the lessons that Stripe has learned while building a globally distributed engineering team. Whether your team is working remotely temporarily due to COVID-19 or whether you are investing in remote work as a long-term strategy, the discoveries Stripe made along the way can set your team up for success in building high-quality software at scale and working effectively across geographical boundaries.
GitHub Satellite: A community connected by code
On May 6th, we threw a free virtual event featuring developers working together on the world’s software, announcements from the GitHub team, and inspiring performances by artists who code.
More information: https://githubsatellite.com
Schedule: https://githubsatellite.com/schedule/
B
Yeah
you're
absolutely
right,
emoji,
it's
officially
about
time.
For
our
next
session,
it's
building
strike
remote
hub
scaling,
distributed
teams
which
is
really
timely.
Right
now,
with
everything
that's
going
on
with
covin,
that's
gonna,
be
presented
by
observability
engineer
and
remote
hub
site
lead
at
stripe.
Aditya
mukajee
the
jaw
has
tons
of
experience,
making
remote
collaboration
possible
at
the
TI
set
up
remote
engineering
work
policies
across
stripe,
as
it
grew
to
nearly
200
remote
engineers.
So
this
session
is
really
really
timely.
C
C
C
First,
why
should
remote
work?
Be
our
long-term
strategy
instead
of
just
a
short-term
contingency
and
that's
a
question
that
a
lot
of
companies
are
asking
at
the
executive
level,
even
if
you're
working
remotely
today
due
to
covered
19.
That
doesn't
mean
that
you're
necessarily
planning
to
continue
that
long
term,
once
it's
safe
to
work
in
offices
again.
C
So
for
those
of
you
on
the
fence,
I'm
here
to
tell
you
why
you
should
open
a
remote
hub
as
well,
why
you
should
actively
plan
for
remote
work
being
a
first-class
strategy
alongside
your
physical
offices
on
the
flip
side,
if
you're
sold
on
permanent
remote
work,
but
aren't
sure
how
to
convince
your
company
of
it.
This
is
also
the
talk
for
you.
The
second
question
is:
is
more
of
a
general
question.
C
C
Our
mission
is
to
increase
the
Jaypee
of
the
Internet
and
the
Internet
is
global.
So
we
need
people
who
understand
what
our
users
are
going
through
in
very
disparate
economies,
all
around
the
world,
but
there
what
it's
like
just
on
the
ground.
So
that's
a
great
reason
for
straight
to
build
a
remote
hub
and
have
people
all
around
the
world,
but
that
may
not
apply
to
everyone.
No,
maybe
you're
focused
on
a
local
market,
or
maybe
your
company
is
planning
on
growing
in
a
bootstrap
manner,
instead
of
taking
venture
money.
C
So
why
should
having
a
remote
hub
be
part
of
your
engineering
strategy
as
well?
If
you
take
away
nothing
else
from
this
talk,
I
hope
it's
this
slide
when
you're
forming
your
company's
cultures
and
norms.
Remember
that,
if
you
that
the
best
practices
for
operating
remotely
at
scale
are
also
the
best
practices
for
operating
at
scale
period,
if
you
want
to
create
an
efficient
resilient,
highly
available
engineering
organization
and
have
software
architecture
that
matches
that
you're
going
to
end
up
doing
at
least
80%
of
what's
needed
in
order
to
enable
remote
work
for
your
engineers.
C
In
the
end,
many
teams
will
actually
end
up
being
able
to
operate
remotely,
maybe
not
every
single
person
on
every
single
team,
but
a
lot
of
them
will
because
the
engineering
practices
that
you're
going
to
need
in
order
to
scale
will
set
you
up.
For
that
and,
conversely,
an
engineering
team-
that's
heavily
optimized
for
in-person
workflows,
is
going
to
need
to
adapt
those
strategies
in
order
to
maintain
that
same
level
of
flexibility
at
scale
and
as
it
turns
out,
those
adaptations
are
mostly
the
same
ones
that
facilitate
remote
work.
C
C
Now
sometimes
people
are
hesitant.
They
think
that
remote
work
causes
problems.
You
you'd
hear
this
often
especially
like
you
know,
six
months
a
year
ago,
that
will
be
tried,
remote
work,
but
it
led
to
communication
breakdown.
Led
to
you
know.
Culture
split
on
their
productivity
was
an
issue
and,
while
I
think
that
those
are
valid
concerns,
I
also
think
that
there's
a
more
constructive
way
to
look
at
it.
C
Your
company
is
a
dynamic
system.
Just
like
the
human
body.
You
have
multiple
organs
that
are
working
together,
just
like
to
use
in
your
in
your
company
to
accomplish
a
broader
goal,
and
sometimes
there
are
issues
either
with
an
isolated
organ
or
with
the
way
that
different
organs
work
together
with
each
other.
So
one
tool
that's
used
to
diagnose
those
issues
is
nuclear
medicine.
That's
actually
the
term.
C
So
let's
say
you
know,
there's
an
issue
with
your
with
your
kidneys,
your
renal
system,
how
your
body's
processing
water,
so
what
doctors
will
have
you
do
is
swallow
a
small
amount
of
basically
radioactive
water-
that's
somewhat
mildly
radioactive,
but
it's
technically
radioactive
water
and
your
body
will
treat
that
exactly
the
same
way
that
it
treats
all.
You
know
any
other
water
that
you'd
in
jest
you'll
swallow
it
it'll
go
through
your
stomach
I.
C
Don't
you
know
your
kidneys
will
process
it
and
so
forth,
but
with
one
key
difference,
because
it's
radioactive
that
water
will
show
up
right
in
fluorescent
on
a
certain
type
of
imaging
skin,
so
it
you
can
actually
see
if
there
are
any
issues
with
how
your
kidneys
are
functioning.
So
what
we
found
is
that
remote
work
is
like
having
these
fluorescent
indicators.
It
will
shine
a
light
on
any
scaling
inefficiencies
in
your
workflows,
like
undocumented
practices
or
low
bus
factors
and
they'll
become
visible
very
quickly.
C
It
doesn't
mean
that
working
remotely
causes
those
issues
or
that
working
remotely
as
an
issue
of
scale.
It's
on
the
contrary.
Adapting
to
remote
work
will
make
your
engineering
organization
more
elastic
and
scalable
by
shining
a
light
on
those
issues
earlier
on
in
the
process,
when
it's
still
much
easier
for
you
to
change
them
as
a
friendly
note.
C
Everything
we're
talking
about
here
is
an
example,
so
please
don't
actually
swallow
any
radioactive
water
or
for
that
matter,
anything
radioactive
unless
you
have
doctor's
supervision
and
while
this
other
note
might
sound
obvious
as
well
I
think
it's
worth
being
explicit
on
if
you're
running
into
issues
with
remote
work.
Today,
that's
expected-
and
that's
that's
normal-
you
probably
weren't
planning
for
this,
so
you're
still
currently
operating
in
reaction
mode
rather
than
in
planning
mode.
Even
at
stripe,
where
we
were,
we
were
planning
ahead
pheromone
at
work.
C
We've
still
had
hiccups
over
the
last
two
months,
trying
to
transition
that
to
habit
the
entire
organization
working
about
the
simultaneously
and
for
all
of
us
we're
not
just
working
at
home,
we're
at
home
during
a
global
pandemic
trying
to
work.
So
it's
easy
to
attribute
any
problems
that
we
encounter
to
remote
work.
But
really
there
are
a
lot
of
confounding
factors
here.
So
it's
important
to
cut
yourselves
and
also
your
colleagues,
some
slack
along
the
way.
C
Now
here
comes
the
interesting
part,
the
answer
to
that
second
question:
how
do
we
work
effectively
as
remote
teams?
So
at
the
beginning
of
last
year,
I
laid
out
three
key
goals
that
I
wanted
to
accomplish
in
our
first
year
of
having
a
remote
hub
at
stripe.
Now,
I
wanted
to
expand
the
breadth
of
teams
that
were
hiring
remote
engineers.
I
wanted
to
improve
the
remote
extra
work,
experience
for
remote
engineers
and
I
wanted
to
recruit
and
hire
more
remote
engineers.
C
At
stripe,
we're
meticulous
about
the
foundations,
we
like
to
reason
from
first
principles
and
we
collect
data
to
inform
our
decisions
and
then
that
data
also
helps
us
know
when
to
revise
or
shift
our
focus
along
the
way.
So
I
already
outlined
the
key
goals
that
I
wanted
to
accomplish
for
the
year.
So
then
we
begin
with
our
initial
hypotheses
about
those
goals.
We
then
collect
data
or
evidence
from
the
different
projects
that
we
that
we
bark
on
to
try
and
accomplish
those
goals.
C
You
know
those
are
basically
the
experiments
that
were
running
and
then,
most
importantly,
we
have
the
findings,
the
results
that
we've
learned
from
each
step
along
the
way.
So
by
sharing
with
you,
this
framework
that
we
used
and
that
we
still
use
and
showing
you
how
we
applied
it,
I
hope
I
can
give
you
something
practical
that
you
can
take
back
to
your
companies
and
apply
to
your
own
unique
situations
as
well.
C
C
You
know,
of
course,
they're
gonna
say
absolutely,
but
that
doesn't
mean
that
they're
actually
necessarily
going
to
go
out
there
and
start
posting
remote
roles
for
their
teams
or
actively
recruiting
remote
people
remote
candidates
to
fill
those
roles,
because
we
had
a
chicken-and-egg
problem.
Some
teams
had
been
remote
friendly
for
a
while,
but
some
also
had
zero
remotes,
and
so
we
needed
a
plan
to
transition
teams
from
going
from
zero
modes
to
one
or
more
remotes
on
on
a
team.
C
So
the
first
thing
I
did
was
to
co-lead
a
guide
of
the
common
practices
that
were
already
used
by
teams
that
were
working
remotely
at
stripe
and
the
this
wasn't
anything
that
they'd
coordinated
in
advance.
This
was
just
figuring
out
what
patterns
and
habits
they'd
settled
into
naturally,
and
finding
the
lowest
common
denominator
among
them.
We
plan
on
sharing
this
guide
in
the
future,
but
as
a
preview,
most
of
it
centered
around
the
team
communication
norms
and
especially
meeting
styles.
C
So
it's
a
level
playing
field.
Another
meeting
style.
We
recommend
for
teams
to
use
whenever,
whenever
it's
helpful
is
called
the
silent
meeting
so
good,
a
good
use
of
it
is
if
you're
reviewing
a
design
document
or
a
project
moved
together.
You
reserve
the
first
third
of
the
meeting
for
everyone
to
sit
on
a
conference
call
together,
but
in
silence
and
everyone
is
collaboratively,
editing
and
commenting
on
a
Google
Doc
together
and
they'll.
You
know
responding
to
each
other's
comments
and
and
working.
You
know
semi
synchronously
and
then
the
rest
of
the
meeting.
C
You
talk
about
the
stuff
that
you'd
edited
and
the
discussions
that
you'd
had
in
the
comments.
The
advantage
of
this
meeting
style
is.
It
gives
people
a
little
bit
more
time
to
collect
their
thoughts
and
respond
appropriately,
and
it
addresses
some
of
the
issues
you
sometimes
having
meetings
both
online
and
offline,
where
you
know
people
feel
are
interrupting
each
other
or
you
know,
feel
like
they're,
not
necessarily
getting
heard
and
get
which
get
amplified
over
the
latency
of
a
video
call,
and
this
instead
gives
people
a
an
asynchronous.
C
You
notice
or
a
semi-secret
is
way
of
talking
beforehand
and
then
a
basis
from
which
to
have
the
conversations.
So
we
took
this
and
then
I
gave
it
to
two
managers
were
interested
in
adapting
to
remote
work
and
he
told
them
to
adopt
these
practices
practices
as
a
team
as
a
prerequisite
to
opening
up
term
at
work,
because
in
order
to
be
successful,
you
need
everyone
to
be
on
board
whether
or
not
they
are
personally
working
remote.
It's
not
just
a
job
of
remote
engineers
to
make
sure
that
the
team
supports
remote
work.
C
Everyone
has
to
be
involved
as
well,
and
so
as
part
of
getting
everyone
on
board,
it
helped
that
we
were
able
to
show
them
how
our
existing
workflows
set
them
up
for
remote
work,
because
nobody
wants
to
feel
like
a
guinea
pig.
But
everyone
wants
to
feel
like
they're
trying
something
new.
So
we
could
truthfully
tell
them.
C
So
the
second
goal
I
had
was
to
improve
their
work
experience
for
remote
engineers,
and
we
have
the
hypothesis
that
having
a
remote
landing
team
can
help
cement
or
to
your
team's
culture
as
it
shifts
to
to
remote
work.
So
what
we
began
with
a
pilot
program
where
we
actually
offered
a
you
know,
we
told
a
small
number
of
Engineers
in
the
same
in
the
San
Francisco
office
that
they
could
work
remotely
from
their
homes
in
the
Bay
Area.
For
three
months
as
a
pilot
program,
it
you
know,
still
be
based.
C
In
fact,
I
believe
every
single
person
who
participated
in
it
opted
to
continue
working
remotely
even
after
the
pilot
had
ended,
and
they
set
us
up
quite
well
when
Cove
in
nineteen
eight,
because
we
already
knew
what
to
expect
when
asking
people
to
transition
to
working
remotely
from
working
in
an
office.
Of
course,
you
know
one
of
those
situations
as
voluntary
one
wasn't,
but
it
still
gave
us
a
baseline,
something
that
we
could
a
starting
point.
C
It's
the
same
barriers
of
with
video
conference
calls
it's
all
fun
functionally
the
same.
So
as
parting
as
part
of
learning
to
work
across
offices,
we've
already
adopted
both
the
tools
for
synchronous,
communication
across
distances
and
also
asynchronous
tools
for
most
of
our
work.
So
we
don't
do
code
review
by
looking
over
someone's
shoulder.
We
use
github.
We
don't
do
sprint
planning
by
using
post-it
notes
in
a
conference
room
we
use
JIRA.
C
We
don't
do
product
development
on
a
whiteboard,
we
use
Google
Docs,
and
these
are
things
that
we
all
that
we
adopted
long
before
we
created
a
remote.
We
did
them
because
they're
generally
good
development
practices,
but
also
because
people
needed
them
in
order
to
work
effectively
across
offices,
and
we
found
that
these
translate
very
directly
towards
remote
work
as
well.
C
C
So
as
he
became
more
rigorous
about
documenting
the
operations
of
our
systems,
that
people
everywhere
could
use
them,
our
incidents
response
process
quickly
became
distributed
as
well,
and
this
happened
even
before
long
before
the
creation
of
remote
hub.
It
was
just
a
function
of
what
we
needed
to
do
to
scale
and
it's
very
different,
difficult
to
scale
an
organization
remotely
and
still
have
a
low
bus
factor.
C
So
what
do
we
learn
from
our
efforts
to
improve
work?
Experience
remote
engineers?
Well,
it
became
clear
that
building
a
remote
hub
means
building
great
remote
teams.
It
means
setting
people
up
for
success,
regardless
of
where
they
happen
to
be
working,
and
fortunately
the
best
workflows
are
largely
the
same
both
for
remote
and
non
remote
teams.
C
So
final
goal
I
had
was
to
recruit
and
actually
hire
more
remote
engineer's
and
at
the
time
that
we
launch
the
remote
hub,
my
hypothesis
was
that
most
engineering
roles
can
actually
be
hired
remotely
as
long
as
the
team
and
the
manager
are
committed
to
it.
That's
the
key
prerequisite,
because
we
don't
view
the
responsibility
of
remote
work
as
a
one-way
street.
Remote
work
is
as
much
about
setting
people
up
for
success
as
it
is
about
the
people
who
are
working
remote,
pretty
good.
C
So
what
we
did
as
an
experiment
was
we
to
collect
date
on
this?
We
codify
to
me
simplify
the
requirements
for
working
remotely
previously
we'd
expected
candidates
for
remote
roles
to
have
prior
experience
working
remotely
at
another
company
earlier,
but,
as
we
just
saw
a
lot
of
the
skills
for
working
effectively,
wall
and
remote
are
really
just
general
engineering
skills.
So
knowing
how
to
use
code,
review
tools,
use
project
management,
software
or
you
just
communicating
effectively
and
clearly
in
prose
and
in
written
documents.
C
Those
are
all
things
that
are
essential
to
remote
work,
but
they're
also
essential
for
success
and
more
senior
engineering
roles
as
well.
So
instead
we
decided
that
for
engineering
roles
in
the
remote
hub
we
would
consider
more
experienced
or
senior
engineering
applicants,
regardless
of
whether
or
not
they
had
prior
remote
experience
for
new
graduates
people.
You
know,
for
example,
somebody's
fresh
out
of
school
and
accepting
their
first
full-time
job.
C
We
still
would
look
for
prior
remote
experience
when
applying
to
role
in
the
remote
hub,
and
that
doesn't
mean
that
we
believe
that
those
roles
couldn't
be
done
remotely.
It
just
meant
that
at
the
time
we
made
this
change
a
year
ago,
we
weren't
confident
that
we
would
be
able
to
provide
the
support
and
the
career
growth
resources
for
someone
who
is
new
to
both
full-time
employment
and
to
working
remotely.
C
The
data
here
speaks
for
itself.
By
the
end
of
the
year
we
had
nearly
200
remote
engineers
at
stripe,
accounting
for
one-fifth
of
the
engineering
organization
and,
of
course,
as
of
today,
all
of
stripe
engineers.
In
fact,
the
entire
company
is
working
remotely
as
well,
and
the
current
situation
isn't
permanent.
We
do
plan
on
reopening
our
offices,
but
the
fact
that
stripe
engineers
have
been
working
remotely
for
nearly
two
months.
Now
is
the
best
proof
from
this
hypothesis
that
we
can
imagine
in
fact,
we've
gone
even
further
our
2020
summer.
C
So
we
recognize
that
this
is
a
contingency
arrangement
and
not
our
first
choice,
but
the
global
situation
has
shown
us
that
it's
possible
to
open
up
remote
work
to
rules
which
we'd
never
consider
to
be
in
scope
when
we
launch
the
remote
hub
a
year
ago,
and
the
reason
that
we've
been
able
to
move
so
quickly
when
adopting
remote
work
in
response
to
Cova
19
is
because
we
already
had
the
gears
in
motion.
We
didn't
need
to
change
direction.
We
were
just
applying
the
turbo
booster
to
move
everything
that
we
already
had
even
faster.
C
C
A
Thank
You
Aditya
for
that
talk
on
remote
work,
I,
really
love
the
mitten
style
where
everybody,
even
though
some
people
might
be
the
physical
office
but
there'll,
be
some
mittens
where
everybody
is
fully
remote,
so
they
can
be
on
an
even
keel
and
and
absolutely
take
away
that
I
got
from
this.
That
I
think
I'm
gonna
actually
start
doing
myself.
It's
the
silent
beginning,
so
that
everybody's
on
the
same
page-
and
you
can
just
kind
of
compose
yourself
before
you
jump
into
the
work
they
all
are
doing
synchronously.
A
A
How
do
you
convince
your
company,
especially
one
which
is
quite
big
more
than
a
hundred
engineers,
to
support
an
initiative
like
yours,
how
your
remote
teams
can
work
efficiently
with
the
on-site
team
and
they
also
want
to
know
how
are
you
dealing
with
the
different
kinds
of
communication
channels
between
the
remote
teams
and
the
on-site
teams?
So,
let's
just
take
the
first
one:
how
do
you
strong
convince
a
company
with
a
large
engineering
group
of
more
than
a
hundred
people
to
take
on
work
in
the
curated?
A
remote
hub,
I
did
yeah.
C
So
that's
a
very
good
question.
I
I
think
that
the
answer
for
that
is
largely
going
to
be
situational
on
what
work
for
us
may
not
necessarily
be
applicable
to
you,
but
the
key
is
to
find
figure
out
what
your
company
actually
cares
about.
What
are
the
problems
you're
currently
having
and
you
know,
fit
in
and
figure
out
how
remote
work
is
going
to
help
or
amplify
those?
You
know.
One
way
is
a
career
mobility
or
retention.
C
Oftentimes
people
will
have
to
will
have
to
move
in
order
to
you
know
because
of
a
significant
other
or
family
circumstances,
and
you
know
it
really
sucks
to
have
to
lose
a
lot
of
institutional
knowledge.
That's
that's
been
accumulated
just
because
someone
has
to
make
someone
has
to
shift
locations.
Wouldn't
it
be
great
if
we
could
actually
that
along
and
support
and
provide
these
these
internal
mobility
options
for
them,
instead
of
forcing
them
to
have
to
seek
you
know
a
job
somewhere
else.
That's
one
angle
that
may
work
another
way
is
to
think
about.
C
B
C
C
That
doesn't
mean
that
you
don't
want
to
be
a
flexible
and
and
adaptable
company.
You
know
a
current
situation
has
shown
us
that
you
know
markets
can
change,
you
know
and
whether
that's
because
of
something
called,
oh
that's
happening
or
just
the
market
that
you're
tackling
or
just
where
you
happen
to
be
geographically
and
remote.
Work
will
free
you
from
some
of
those
limitations,
not
all
of
them
but
ill
for
you
from
a
lot
of
them,
and
it
will
allow
you
to
move
much
much
more
nimbly
at
whatever
scale
you're
operating.
C
Yeah
so
I
think
I,
don't
know
if
I'd
classify
this
as
a
downside,
but
something
to
be
aware
of
is
just
it,
not
it's
not
for
everyone.
In
fact,
it's
funny
because
remote
work
isn't
just
I
I
kind
of
completed
this.
It's
not
just
working
at
home.
It
can
also
be
working.
You
know
at
a
separate
space,
that's
not
your
home
and
there's
something
I
personally
have
struggled
with,
because
I've
been
working
remotely
for
five
years,
but
normally
in
a
co-working
space.
C
So
in
the
last
two
months,
adopting
and
working
out
of
my
apartments
been
a
big
shift,
so
you
have
to
keep
in
mind
that
people
need
to
people
need
the
flexibility
to
set.
Ideally,
people
need
the
flexibility
to
set
up
their
workspaces
and
their
work
situations.
The
way
they
want
and
some
people
might
might
still
prefer
a
physical
office,
but
that
doesn't
mean
we
can't
provide
both
options
to
people
depending
on
what
works
best
for
them.