Live data from Hacker News

Stripe’s fifth engineering hub is Remote

stripe.com

91–100 of 277 posts

Re: Stripe’s fifth engineering hub is Remote

#91

Earlier quoted context omitted.

Are you by chance just noticing all of the empty space that was previously filled with non-productive time in an office? I've worked remotely for about 5 years now. Without the water cooler talk, chit chat, and misc distractions, I can easily fit a 8+ hour day into less than 6 hours when I work from home.

I think it just depends on the person. I work full time remote for a 100% remote consulting company. Some people come in and do very well. Others don’t seem to be able to make the transition into remote. I’ve worked with new hires that literally take entire days off and give excuses why they were unreachable. Sadly they are just shuffled around the company instead of disciplined but that’s another topic. But I figure…

I work almost entirely remote today and definitely prefer it. (The people I work with are scattered all over the place anyway.)

But I can't really imagine how I would have done well working remotely towards the beginning of my career. It was a different time with far fewer communication tools but, even taking that out, it would have been very difficult both socially and in terms of work discipline.

Re: Stripe’s fifth engineering hub is Remote

#92
post #8

Earlier quoted context omitted.

If you want to test out workers outside of USA but not have to solve the timezone related issues I recommend Colombia. There is at least one interested person there.

As someone who's worked remote with "timezone issues" before they're not for the company to solve. If you live in Europe but work for a US company that requires you to work US times, it's simple, you work US times. This is how I've worked before and it's worked out perfectly. In fact, I'm a bit of a night owl so I much preferred it.

No, this is not how the timezone should be solved, and great if it works for you, but this is just not sane for most people.

To solve the timezone issue, you put in place as much tools and processes as possible around working asynchronously instead of having meetings all days. This is why most remote setups work better in fully remote companies - they are more incentivised to put those things in place.

Re: Stripe’s fifth engineering hub is Remote

#93
post #8

Earlier quoted context omitted.

As someone who's worked remote with "timezone issues" before they're not for the company to solve. If you live in Europe but work for a US company that requires you to work US times, it's simple, you work US times. This is how I've worked before and it's worked out perfectly. In fact, I'm a bit of a night owl so I much preferred it.

I work at a company where everyone is expected to be in the office. But we have early birds and night owls employed by the same company to work together. We don't have a formalized solution as night owls do as you described and get on up if they have work due in the morning. Or the early birds will stay up late to help the night owls finish. But a lot of companies take on "Core hours" and essentially solve the timezo…

if you are interested and want to solve this for your company, look into Gitlab. They are solving it and have very good public documentation on this.

Re: Stripe’s fifth engineering hub is Remote

#94
post #48

Earlier quoted context omitted.

What metrics do you use to realize that you are less productive?

I was a lead/senior developer of a team of ~10 (in a startup of 30). I was involved heavily in the direction of the company, as well as the day to day running of my team. I now work remotely with a 15 hr time difference. Nowadays I feel extremely left out of the direction of the company, the direction technically, and what my team is up to day to day. I try to close these gaps during calls with my team every day, but…

The work package that you are assigned to yourself is not necessary a problem with remote per se. It sounds like that the work package is not matching the skills/knowledge for assigned team. But you are correct, the ramping up of knowledge is much easier when the teams are close together where sharing of know-how is much lower.

Re: Stripe’s fifth engineering hub is Remote

#95
post #48

Earlier quoted context omitted.

What metrics do you use to realize that you are less productive?

I was a lead/senior developer of a team of ~10 (in a startup of 30). I was involved heavily in the direction of the company, as well as the day to day running of my team. I now work remotely with a 15 hr time difference. Nowadays I feel extremely left out of the direction of the company, the direction technically, and what my team is up to day to day. I try to close these gaps during calls with my team every day, but…

I can easily imagine other side of the world being tough. +/- 5 hours or so, you can reasonably time shift a bit so there's significant overlap in the course of the day. But you get into 12 hours and you're into one or the other ends of the call being well outside normal work hours. So it doesn't happen a lot on a regular and casual basis.

Re: Stripe’s fifth engineering hub is Remote

#97
post #79

Earlier quoted context omitted.

> So it is a A versus B for those people - people who are having to commute for hours to work, mandatorily sit at their computer screens . Versus others who wake up late (because no commute) and can walk about the house in their pyjamas. It's a false dichotomy. It's not commute + "mandatory" screen time vs. sleeping in and wearing PJs. When I worked in offices, I enjoyed commuting, it gave me time to listen to podcas…

> Having remote coworkers allows us to engage more thoughtfully with each other, and often pushes us to write more (and more useful) documentation so that we _aren't_ expecting immediate answers from any specific human. this is very interesting - is this emergent behavior or have you guys figured out some todos that makes this an effective tool ? for example, do you consciously allocate more time for documentation by…

In my experience, this has been both an emergent behavior that has worked out well, and subsequently a culture/process that has been encouraged by management for new members (both remote and in-office) of the team.

There hasn't necessarily been a need to allocate more time for documentation, except for everyone getting in the habit of default communication modes being easily accessible documentation (common wiki/docs that all decisions, specs, and proposals go into) ... so it's not a "more time" thing, as much as it's a "don't send an email, but instead update the docs"

Re: Stripe’s fifth engineering hub is Remote

#98
post #26

Earlier quoted context omitted.

Why would you expect remote to be less efficient? Working in an open office is incredibly distracting—of course there’s productivity gains from going remote.

its not about less productivity... its about perceived unfairness about quality of life by the in-office team. this is a very tenuous issue when you have one company with an inhouse and remote team at the same time. I made another comment to patio11's response up the thread.

As someone who works at a company with a lot of remote workers but also people who regularly work out of offices, I haven't personally experienced this. I'm sure there are people who feel forced to come into an office even though it's not their preference and resent those who don't have to. But I find that there are a lot of people who like coming into an office, people who mostly like working remote, and people who like doing a bit of each. So I don't see any sort of widespread resentment of people who choose/are allowed to work at home.

Re: Stripe’s fifth engineering hub is Remote

#99
post #37

Earlier quoted context omitted.

We use Slack, Zoom, Google Docs, Github, and a handful of other widely-adopted technologies. They're really good and we couldn't do this without them, but they're probably not the lynchpin to making this work at scale. We're working constantly on improving the integration of peers throughout the company. Something Stripe Atlas does, for example, is schedule time for the team to low-key socialize without an explicit a…

@patio11 - thanks for your reply. > I cannot conceive of a reason we'd track screen time for employees, remote or otherwise. I can model why a company which had an adversarial relationship with employees might want to do that (to discourage shirking). We do not have an adversarial relationship with our employees, and (hopefully) have more interesting utility functions than that. its not about the company. See you guy…

Probably one question that would directly answer this is—can Stripes who live in SFBA transfer from the SF hub to the remote hub?

Re: Stripe’s fifth engineering hub is Remote

#100
post #79

Earlier quoted context omitted.

> So it is a A versus B for those people - people who are having to commute for hours to work, mandatorily sit at their computer screens . Versus others who wake up late (because no commute) and can walk about the house in their pyjamas. It's a false dichotomy. It's not commute + "mandatory" screen time vs. sleeping in and wearing PJs. When I worked in offices, I enjoyed commuting, it gave me time to listen to podcas…

> Having remote coworkers allows us to engage more thoughtfully with each other, and often pushes us to write more (and more useful) documentation so that we _aren't_ expecting immediate answers from any specific human. this is very interesting - is this emergent behavior or have you guys figured out some todos that makes this an effective tool ? for example, do you consciously allocate more time for documentation by…

This is my experience at the company I'm currently at which has offices in SF and other US locations, as well as a significant number (as a % of the Eng team) of remote people across the country. I don't know the origin story, as the practice was in place when I joined this team, but it's proven its value time and time again. We do consciously make time to document and discuss how to make that information more useful/discoverable/accurate.

* Use the tools - ticket tracking, chat rooms, wikis or other documentation repositories

* Own it - engage in the conversation, do the work, help the whole team get better, accept responsibility, acknowledge your own mistakes, and acknowledge others' wins and contributions

* Do it in public - @mention people in tickets, etc., use PUBLIC chat spaces, use org-wide sharing of documents

A company I worked for in the past, which had a SF office and a smaller number of remote engineers, did not embrace the value of thoughtful written communication, and ultimately didn't see the value of remote engineers. It fostered a culture of "need-to-know" conversations where they felt if you couldn't be "in the room" then you simply weren't going to have the information you needed. They didn't value recording (video, text, etc.) the agenda, discussion, or outcomes of these discussions, so it only lived on in the individuals involved. This artificially stunted the remote engineers, and in turn it backfired on the entire team's productivity.

Post reply on HN