What it’s like to work for Stripe | Hacker News Reader

What it’s like to work for Stripe

blog.alexmaccaw.com

285 pointsrelation57 comments

There's a post below, which is [dead], but which raises an issue I was curious about. Is the daily group lunch treated as required, or is it totally OK to skip it? And even if it's not officially required, is there any sort of peer-pressure thing / shunning of people who don't participate?

IF it's optional and truly treated that way, it sounds like a great idea to me. Otherwise, I'd consider it downright toxic. At every job I've ever had, I treat my lunchtime as, well, mine. If I need to go run errands, or just want to be alone, or want to go sit at Starbucks and answer emails for the startup I'm working on on the side, whatever, I do it over lunch. Or sometimes I just plain feel like skipping lunch for some random reason. If I had that freedom denied to me, I'd be miserable.

Answer: I am currently skipping group lunch :).

Cool. Do most people pretty much do group lunch most days, or is it common for individuals, or small groups, to go off and do their own thing?

Just legitimately curious... not knocking the idea. Like I said, if it's not mandatory, I'm all for it. Just wondering how the culture has evolved around that.

I'd say probably 80% of the company is at lunch on any given day. Sometimes people will go and grab food from food trucks or restaurants in the area, though they'll also often bring it back and eat with everyone else.

Yes, agreed. All of these things at Stripe are optional, and more convention than anything else.

Participating in support, as the author mentions, is an incredible learning experience. I handle all incoming emails for the manufacturing business I work at. Even though I end up filtering and passing on most emails, I get to see what customers are saying, asking, wanting, etc. If something needs to be handled by a higher-up, they often include me on the following interaction with the customer. This has taught me a lot about the philosophies and decision-making process that has made the business successful. I am now at a point where I am handling more emails than I am passing on. I can't think of any way I could have learned as much as I have and had it make sense and really sink in.

"Every single engineer does support, on a bi-weekly rotation. Even the founders John and Patrick. We provide support over an IRC channel, email, and through Stripe answers."

This is one of the worst policies I've ever encountered. Companies that I've been involved with often do this at first, because at first, everyone SHOULD do support. After a few years, it's horribly unproductive. It creates a long term crisis culture that is reactive rather than proactive. Many days the entire development team will not be working on their individual development tasks and instead be ganging up on some perceived production crisis.

You need to introduce the concept of triage, not gang-support and no rotating support. Rotating support isn't just bad for your developers, it's a horrible way to support your customers. One week you have a problem that gets resolved quickly because the guy on support actually wrote the code that you are having a problem with. The next week, the same support call takes three days because the guy on support has no idea where that code even lives and has to learn the process. You might say 'oh, but that's how we cross train', to which I, as a customer, point out that those three days I had to wait for an answer were unacceptable, and you should have a better plan on cross training than 'wait til something breaks and throw completely clueless resources at it'.

> When you hire great people, you can afford to give them a lot of autonomy.

I think you have this completely backwards: in order to be great, autonomy is required. There's much written about motivations and what makes people happy in the workplace but micromanagement is one of the most easily recognizable anti-habits of a bad work environment. It breeds resentment and engenders an atmosphere of distrust. Bring out the best in people by giving them autonomy.

It's probably some measure of both, but from my experience there are some people you can't afford to give autonomy.

Then you can't afford to keep them around either, right?

The world is not black and white, keep an employee or fire them.

If an employee can perform well with the additional investment of some structure and management, then it might be a cost effective approach.

Depends who you are and how big you are. Not every company can have the very best employees in the industry.

Read the OP. Its not about the best it is about giving all people autonomy.

Not everyone has the right personality to work for places like Stripe or Valve. They are specifically picking people who can self-direct themselves in a way that is beneficial to the company.

I love the part about email transparency. That's been my ideal as well, so it's great to see that it actually works in practice.

One big question I have though is around compensation. How transparent are you guys with compensation, and what lessons have you learned there?

It's a tough question. We consider compensation to be confidential to both employees and the company -- in general, it's not our information to share.

Within the constraints of that, though, we try to be as open as possible. In particular, we share some information about current salaries at Stripe with new hires, and we share full details about all of Stripe's investment and the terms on which it was taken.

In considering doing something similar with my company, I'm wondering if there is an override for the auto CC that should be available to certain accounts?

I could be wrong but it doesn't sound like it's an "auto CC", but rather a "convention" as Alex said in another comment.

I worked at one start-up where a guy insisted on being on all email lists and then proceeded to bitch up a gigantic storm on every single issue.

That was more a personnel issue that a process one, though. His boss didn't have the backbone to fire him.

The truly interesting challenge will be how effectively they transition these policies as they scale. For example, the flood-of-email with filters works incredibly well for transparency at 40 people, but becomes an unmanageable deluge much past 100. The Capture the Flag runs, though, look like an idea that's both awesome and sustainable.

Yeah, we're pretty sure that what we do will require extensive tweaking as we scale. We did a bunch of things at 5 people that haven't scaled to 30. I'm optimistic the properties that we care most about can scale with us, though, even if the mechanism by which we accomplish them changes.

What did you do at 5 people?

FWIW, Google also does the flood-of-email with filters thing, and it still works at 30,000 employees. People don't subscribe to every single mailing list anymore, but most e-mails are CC'd to at least a team mailing list, as are (usually) every code review and every bug.

I get about 300 emails a day, several of which are mailing list digests with 25 emails apiece. I actually skim them all; I'm one of two people I know who doesn't use filters, and I think the other one gave up recently. For someone who's an informationavore like me, though, it's paradise, and a great way of keeping up the illusion of knowing everything.

It is probably good to have someone in this role, if everyone were doing it it would probably be a productivity drain. But as the only one doing it you may be able to spot issues that no one else has the same total oversight to catch.

> every email at Stripe is CC-ed to lists that go to either the entire company or to any particular team. This includes internal person-to-person correspondence

I recently watched an 1990 Steve Jobs interview[1] in which he gushed about this very idea as being a workflow of the future. Since the "desktop revolution" was old news, he was moving on to the "business process revolution" (something like that), enabled by networked computers. Companies would love it because it removed the friction of traditional employee work roles/titles and geography, and allowed managers to observe communication and measure stuff. It's interesting to see a company actually doing pretty much exactly what Jobs described in the video.

Although obviously, open source has used that model with great success.

[1] http://video.pbs.org/video/2151510911/

A lot of these awesome things (weekly standups, together lunches, socials etc.) are feasible when the team is still small. As the team scales, this starts getting more and more difficult and ultimately, silos form among the different functions (sales/support/eng etc.). Probably this might not be felt to such an extent given that stripe is (and will be) engineering heavy (I presume). But I've witnessed this first hand at the startup where I work. Things were awesome when the team size was about 20-25. As we grew to ~150 folks over the last 2 years, a lot of the things start to break.

I enjoy the occasional social as much as they next guy, but as I get older, my family becomes more important. Is it the case that the majority of employees have fewer external social attachments? Do you (OP, or anyone else here) think the idea of socials, which long term might have a tendency to become de facto mandatory, is sustainable as the workforce ages (and starts families)?

I'm married too (no kids yet) and have a long commute. Most of my colleagues are single, male in the 23-30 age demographic and live in the city. They obviously go out way much more than I do. Family is important to me, but every once in a while, I make a conscious effort to socialize outside of the work environment. I do think that socializing every once in a while is important to build camaraderie among colleagues. Of course, when booze is involved (more often so than not), people tend to loosen up a bit and chat more openly. Even if you have a family, I would suggest making time once a month to socialize (be it a social events@work or other professional meetup events).

A number of people at Stripe have families or have other social attachments. We try hard to ensure we're not making lifestyle assumptions when we hold social things. Some of this involves giving good advance notice, other times it's around timing. Trivial example: recently, we moved an internal talk series from dinner time to 4pm, so that people who don't stay for dinner aren't excluded. I think explicitly keeping things like that in mind helps.

But this would eventually converge to the 9-5 frame of things, wouldn't it? This is the only time of day that everyone is absolutely certain to have no other commitments other than working.

Also, the fact that you had the talk initially set for the dinner time basically means that your culture is already incompatible with the lifestyle of those who value family over work. I am not saying it's a bad thing, I used to actually sleep at work when I was younger, but it is an indication of problems you'll face once your team gets over a certain size. Diversity has a smaller common overlap.

Love the idea of a paper reading group. In case anyone missed the link in the article, they've put a bunch of the recently read papers up at https://github.com/gdb/stripe-prg/wiki/Papers

I have been trying to get a group of people together once a month to read a paper. We have a google group at https://groups.google.com/forum/?fromgroups#!forum/papers-in..., and meet over Hangouts. Anyone interested should join up and suggest papers!

This is a neat idea. I think I'll sign up :).

I like that people outside of academia do this :)

From the article, emphasis mine:

  > None of this would matter if Stripe didn’t have 
  > fantastic people. Hiring well is the key to all of this,   
  > and people are the foundation of any company’s culture.
  > Frankly, I’ve never seen a team like Stripe’s; *** we 
  > have the best people in the industry ***.

Stripe's current success allows them to be very selective about who they hire, which allows them to be fussy about all of the qualities that they think makes a great employee.

There are a number of factors that could "flip" the company's hiring from very selective to less selective. For example:

  * Parts of their culture might not scale indefinitely.
  * They might start running short of cash, and have to
    settle for less expensive hires, or cut some of the
    office luxuries.
  * They might have to start hiring so fast that they can't
    be as selective about their hires.
  * Their tech stack will grow old, and unappealing to 
    energetic self-starters who want to work with the hot
    new thing.
  * Their current employees will get older, start families,
    and have other equally (if not more) important things
    than work.

Clearly, Stripe cares about their culture, and I'm sure that they'll do everything they can keep their workplace experience great, however, cultures are as much an art as they are a science, and what works well for a small group doesn't necessarily work for a large one.

(edit: formatting)

Everything in the post seems positive. Is there anything that is not so great about working at Stripe or could be improved? Alex may be too new to answer but it would be great if other Stripe employees could weigh in.

You just had to make the rest of us jealous, didn't you.

Yes, I read this sort of thing, then look back at the desk I am chained to, and want to weep.

I think they're hiring!

I'm curious about hours of operation. Are you folks 9-5? How flexible is it?

All the communication channels may seem like information overload, but I would welcome it. I really like the part of open email (no more elite side bar conversations between people that don't know as much as they thought they did)

The best part is the IRC channel for chat that has a bot to log my status report (optional) and record for posterity and put it on the shared dashboard as encouragement, recognition and engagement.

sigh... I need coworkers that know what IRC is..

I'd really like to learn more about your usage of irc and how the bots were set up. Did someone create the bots for different tasks by hand or are there good libraries for setting them up? Does everyone have irc open all day? And if so isn't it incredibly distracting?

Huge fan of Stripe and love the part about email transparency - we have similar practices here as well.

I'm curious to hear if people at Stripe have given thought to just having all emails sucked into a searchable CRM versus having to manually add cc's each time?

We have a good way of doing that with our product GrexIt (http://grexit.com) - GrexIt helps you share Gmail labels. So you can just address an email to who you want it to address it to, and add a Gmail label to it to share it with a set of people. They get the email in their inboxes cleanly filed under the corresponding label.

Thanks for the article! Gives me hope :D

... all I wonder though is what it's like to use Stripe (no, we are not in the US).

Use it? You spend 30 minutes integrating it and then move on with your life =)

+ years waiting for it if your company is in Europe... We are still in the waiting phase.

some people have knack of building great teams.

All emails CC'd.

IRC!

Wow, that must be a pretty shitty job. Not to mention the time wasted with Allhands meetings.

Enjoy it while you can, it will all go downhill when you start hiring sales/marketing people ... ;-)

[Disclaimer: Stripe cofounder.]

I know you probably mean this at least in part in jest, but I've found this to be a pretty common perception in the tech industry. It's probably worth addressing directly.

We want to work with the best engineers, but it's arrogant to assume that that's all that we'll need, or that hiring non-engineering people will cause our culture to deteriorate.

That's not to say that that doesn't happen at some companies (obviously). If you view sales/marketing people as second class, and don't put the same thought into that part of the culture, it'll inevitably be worse. Without a lot of care, it's very easy to build a bad engineering culture too.

While building great software is at the very core of what we do, we won't be able to do everything that we want to accomplish by just hiring engineers. We need people who like talking to users, and people who can describe what Stripe is doing to the world at large, and people who'll help build the countless parts of Stripe that aren't purely about code.

If companies choose to ignore sales, marketing, partnerships, support, and everything else, they should be pretty explicit about the compromise: they're trading off success for narrow-minded solipsism.

We've hired people who aren't full-time engineers, and we'll hire lots more. We want people who can craft both kernel exploits and memorable prose. Those who spend their days working with people instead of code are just as important as anyone else, and their contributions are just as large.

At Parse.ly, we find an easy way of making sales and product teams co-exist nicely is to encourage actual collaboration. For example, some of our engineers built the sales team an engagement dashboard that allows them to track customer usage analytics unified across many of our tracking systems. This makes it clear that the teams have a shared goal and that we can leverage each other's skills to the fullest.

Anthropology 101 [:\]

In my experience where this has happened (mostly, but not exclusively at larger companies) the following observations have been true...

Engineering staff have been hired with a range of work experience, i.e. some college hires, some self taught, some with industry background, any combination of the above - the (engineering) corporate culture grows organically as the team matures and works together

Marketing, BizDev, &c staff have been hired with significant industry experience, I don't know where they serve their apprenticeships, but it isn't here wherever here is - they bring a view of corporate culture with them from their previous experience, this doesn't seem to meld well with the growing culture on the engineering side.

I'm sure this isn't ubiquitous, but the tech industry seems to be very keen on nurturing engineers and, in a sense, taking a responsibility for the quality of the engineering community at large, but for other job functions is happy to be, for want of a better word, parasitic, relying on someone else to train those people, whether they be HR, Marketing, BizDev or whatever.

This is really about getting the right people no matter what the role.

If you are a tech company with marketing/sales/BD teams, I have news for you: those people are working at a tech company _for a reason_. They want to be involved in (or at least near) technical things even if they can't contribute in the same way.

Resist the urge to develop isolated tech@ lists. Keep your discussions company-wide even as you grow in non-technical areas. Invite _everyone_ to your technical workshops and reading groups.

At Knewton I've grown tremendously as a marketer, but I've also become interested in the CAP theorem and automated deployment services, learned Git and created some projects, and really sharpened my front-end coding, among other things. I've also had the joy of working with a single developer over a hack weekend to launch a variation of a service that quickly become our top revenue generator and stayed that way for a while.

Get the right people and there's magic waiting to happen.

Being an interactive producer that loves chilling with the engineers, I abhor this comment! That said, we hired a sales guy once that was old school sales, and it didn't end well...

Reply on news.ycombinator.com