I left Stripe a little over 6 months ago to join an exciting startup with a number of my friends. What I miss most about working there is the culture of shipping. There are a number of 'shipped' email lists at Stripe where people can tout their accomplishments large and small. These lists are widely read and commented on, and folks put in a fair amount of effort making their "shipped" emails informative and entertaining.
That feeling you get when you finish a challenging project, write a great shipped email, and get a bunch of feedback from folks throughout the company is pretty amazing. Once I was invited to convert one of my shipped emails into a presentation for a company all-hands meeting. I had a less than a week to get it done, which was pretty hectic, but in the end it turned out great and it was perhaps my favorite memory of my time at Stripe.
I enjoy my current job, and those little dopamine hits I get from checking things off my list as well as the bigger ones from finishing projects, but now only my boss and some teammates notice when I finish something. One thing I learned about myself, is that I really do care about what other people think about my work.
If Stripe's HR department is reading this thread, I think they can pinpoint one crucial interview question that will determine culture fit in their organisation for future hiring - and that is "do you like talking about your accomplishments with the rest of your team?".
Seems to be a very polarising thing to be asked to do, judging by the replies on this particular comment.
EDIT: Curious about the downvotes? This is a real thing. I am sure they don't want to hire people that would hate to write shipped emails and publish them to the list if they actively hated writing them. It is simply not good culture fit, and I am sure they would want to identify that early on in the recruitment process.
That's certainly a reasonable concern given the information above. For what it's worth, though, I work at Stripe and I've never felt pressured to write a shipped email; I don't think others are either.
In fact, I think the only shipped emails I've written have been on behalf of colleagues since I was so excited about something they'd built/fixed (with their permission). Many (most?) Stripes aren't the type to brag about their work. But it is nice to share, and to let others know that X product is better now.
Possibly that such a recruitment filter would exclude a lot of people with depression or anxiety-related mental illness.
To clarify, I hate talking about my accomplishments, it makes me feel deeply anxious and uncomfortable, and will say as much if asked. But I’ll also do it if that’s what’s required of me.
And there are many companies that value humbleness.
I love sharing my accomplishments. I know what's socially expected from me, but not sharing feels really bad to me. It feels as all the work I've done and that cool accomplishment don't matter at all. Therefore I mostly share with friends, though most of them lack the necessary tech-knowledge to really understand it.
I also love hearing about others accomplishments in an easy to digest way. These shipped emails seem like great way to spread knowledge and a positive attitude of getting stuff done.
What I, and the comment you replied to want to say, everyone is different. Let me work at a company that encourages sharing accomplishments and go work for one that values humbleness. But at least please don't take it away from me, just because you don't like it, especially if it's optional.
I've been diagnosed with generalized anxiety disorder. I don't have a tech job yet (I have a hard time applying to jobs, for... obvious reasons), but I keep a public log of accomplishments for my weekend projects, announce them when other people might be interested in new features, and so on.
Different people are different. It'll exclude a lot of people, but not all of them, and it certainly wouldn't be clear-cut discrimination.
I mean, discussing your work with your coworkers is a pretty reasonable workplace responsibility. What's illegal about asking if someone was comfortable doing it?
I was wondering this, I thought the discrimination was about disability, particularly, and "depression and social anxiety" are casually considered illnesses rather than disabilities.
https://www.gov.uk/reasonable-adjustments-for-disabled-worke... says "Employers must make reasonable adjustments to make sure workers with disabilities, or physical or mental health conditions, aren’t substantially disadvantaged when doing their jobs."
and the examples given on the gov.uk site include a specific mention of an anxiety disorder "doing things another way, such as allowing someone with social anxiety disorder to have their own desk instead of hot-desking"
But I don't know where "reasonable adjustments" comes in with this. "I have social anxiety and don't want to present in front of a group, may I send an email instead" sounds reasonable to me. "I don't want to send an email, someone else will have to do this part of the job" doesn't sound reasonable. You don't reasonably hire one person to do a job, then hire another person to the parts the first person cannot do, right? But I'm no lawyer.
The key is to make your culture filter not cause people who actually would be a good fit to self-filter. Mental illness is insidious because it can make people who actually would enjoy something if given the right push instead think/assume that they don't want to do it. It affects a large enough percentage of the population that it's something companies need to be thinking about.
One of my friends worked for a company where one of the official values was "100%", and to me this was problematic because different people would understand it to mean different things. Some would assume that it just means that everyone works hard, that it's not a cushy job. Whilst others would interpret it to mean that everyone works crazy hours and is expected to give their life to the business at the expense of other commitments. My friend couldn't recognise that different people would interpret the value differently, so believed it was a perfectly reasonable way to get the wrong kinds of candidates to self-filter.
I think that's not as easy at it sounds (or I am misreading you).
Let's assume you're wary of talking about accomplishments - what reasons could be there?
Bad memories of trying to convey what awesome things your team did and were generally received really badly? Preferring to sit down and ship and not boast about it at all? Sure, never accomplishing anything might also be the case, but in my experience a lot of really good people weren't keen at all to talk about cool stuff they did in any official or formal form - only over beers between a few developers or not at all. I don't think this is necessarily tied to being an introvert.
I didn't downvote you but I think it's a bad idea. Also because the opposite is true. No matter how much they personally contributed, the loudest people will tell you everything their team did.
Why wouldn't you want to share your accomplishments with your team? If you are proud of what you did, you would want to share it! Then the team will be proud too! And you get feedback! And you give motivation to the rest to do like you did! I see no bad side. :)
Absolutely nothing like it. I'm not sure that you actually read the top post on this thread. We are talking about a company's particular way of ensuring that changes are documented and shared with the rest of the team. Their method is to encourage team members to share their ship details in an internal mailing list.
It's an internal procedure that helps build company knowledge and information sharing. It has a side requirement for acknowledgement for peers, but it is nothing like an optional purchase being high fived...
At work (Pivotal) there's a "Drumbeats" mailing list which I subscribe to. Various teams post there to describe what they're doing.
The company has grown so much larger since I joined that I have found the Drumbeats to be a godsend. It helps me feel connected to the breadth of what's going on, which would be physically impossible otherwise.
I guess a time will come when there are too many Drumbeat emails to keep up with (it sometimes feels that way -- I've gotten better at skimming). I don't know what I'll do then.
We also have a What We Learned This Week list. It's gone a bit quiet lately, which is a shame, because there were some amazing war stories posted.
I agree that release notes and credits are really important. My prior company's product manager made these herself for every release, and while other parts of the company weren't great, I (and others) really liked getting the recognition from the rest of the company.
It helps make a fuller product, since people have less pressure to always work on the flashier things, and can devote time/energy to things like developer tools that are also extremely important.
if you're at startup, you should feel the control to establish the culture you'd like to have. I'd say, introduce the emails, let the feedback be known. I think you have more control on your experience than you might think
It was optional, but it was definitely encouraged. A manager a level above my manager would rub his hands together and say things like "really looking forward to reading that shipped email!" whenever I told him about what I was working on.
They also made it fun. One manager conspiratorially told me were two schools of thought around what made a great shipped email; copious footnotes or funny gifs, and jokingly told me to make sure I had one or the other or even better both.
Stripes love their "footnotes" though, which are essentially links to things. Even though everyone had full HTML email, they were almost always formatted in the style of Hacker News[0] comment links. The people at the top can definitely set the communications tone for the rest of the company.
> A manager a level above my manager would rub his hands together and say things like "really looking forward to reading that shipped email!" whenever I told him about what I was working on.
That doesn't sound optional at all.
From my point of view, making things fun isn't fun. Watching a comedy routine is fun. Writing one isn't.
I agree with you - that said, it all depends on the situation. Good manager will present the same thing as almost mandatory to someone who is more extroverted, and as completely optional and not a big deal to someone who is not. Both of them will feel appreciated and will feel comfortable in the company, which is actually the whole idea. Some people need this kind of exposure, some don't. We just need to appreciate the fact that we are not all the same, and that we all need to have our own way to deal with the socializing rituals.
There are things you have to do for work, such as showcases. You can make them fun, or you can not. Yes, it dos not compare to a comedy routine or watching Airplane. That isn't really the point.
Agreed. This reminds me of office space when the waitress's has the appropriately listed amount of flair but is disparaged for not going above and beyond.
This is so absolutist. You must have a boring life. Sometimes it's about making things fun, sometimes it's about making fun things, and sometimes it's about both.
Driving a car is fun. Building a custom hotrod isn't.
Going to the museum is fun. Learning to paint isn't.
Playing a video game is fun. Writing a video game isn't.
> It was optional, but it was definitely encouraged.
I strongly doubt it was optional, if you wanted a positive career trajectory.
This is also the case in most other companies - it's just that different firms have different expectations for how their employees should market their accomplishments.
Same, but it sounds like it's required to the extent that visibility is required for promotion (no idea at Stripe, but at other companies visibility to upper management is more important than anything when it comes to promotions). To me it sounds like an improvement over the widespread practice of agile demo days / sprint reviews, where individuals on teams demo what has been "shipped" (or made dev-done at least) that sprint.
I can't speak to Stripe, but I expect that this is something that Engineers CAN do, but Product Managers MUST do. Letting the rest of the org know what's going on is a big part of the challenge in scaling a company.
There were much drier "snippets" style communication for just talking about what's going on. I'd say that folks who abhor shameless self promotion typically didn't write much and instead worked with with the annoying extraverts on their team and mostly focused on making sure that the technical details were accurate. These things were often team efforts.
Presumably it's just a forum for validation. If sharing your success with your peers doesn't get you off you can forgo the email, but you might lose some exposure.
Yeah, that's what I mean. It feels like it's just forcing everyone to increase the amount of time they spend on self-promotion (even if it's theoretically "optional").
Not ever seeing these emails, it depends on where you stand. I can see how it would benefit the organization to have people know what is being shipped in other areas of the org, and also provide valuable feedback loops from differing perspectives.
However if all the threads are just “great job on X!” I can see how that could be low-value self promotion.
Yeah, same here. Would have no Interest in writing those emails and setup a filter to send them to bin on receipt too.
I worked for a company that did cards, like thank you cards, or well done cards that you could give a colleague and these would get handed out each month to the recipients. It made me cringe. Can't believe people are so needy.
I really enjoyed that aspect too. I was an intern a few years ago, and at the end of my internship I sent out a 'shipped' email, with lots of positive feedback. It's easy to feel ignored as an intern, but Stripe at the time felt very cohesive.
In reply to foldr's comment, yes, they were totally optional (I can't imagine it's changed).
Don;t think of it as tooting your own horn, think of it as a useful description of something that has been developed, that co-workers could helpfully know about.
Reading this post made me think that while many companies advertise an entrepreneurial environment and the ability to do impactful work, the true test of this culture is 1) the ability to hire former founders and 2) those former founders loving their work.
Plenty of blue-chip startups have future founders working for them...yet it seems to me that having past founders is much more rare. An incredibly strong company endorsement.
I am glad to see we are now explicitly mentioning the aspects of Stripe culture that make it founder friendly.
- Huge transparency
- Management optimizes for autonomy & distributed decision-making
- Upwards review processes > downwards decision-making
- Level obfuscation
- Shipping culture
- People who are of the quality you'd normally only find by hiring them yourself (and frequently better)
My 3rd week at Stripe (around 7 months ago) Patrick just sat down next to me at lunch, knew my name, and started talking about what my team was working on in great detail. Asked me many direct, important questions and really listened.
As a former CEO of a VC-backed company, I knew he was 100% on his game -- and around you at work you can see that pretty much everyone trusts the execs to be insanely competent, because they are. My only wish is that they don't take as many solo plane rides, haha. :)
The most fascinating part of this article is the idea that Stripe is spending time thinking about unlocking potential in Internet businesses in Japan. A tough nut to crack. The revolution is happening in all these countries, but if Stripe can move the needle in Brazil and Japan and other places where entrepreneurship currently requires more grease/graft, that'll really be interesting.
I’m in Tokyo right now for work (my startup NumberBoost won an innovation competition with NTT Japan) and it’s so wild how simultaneously forward and backward things are here.
On the one hand, there are so many things they do here that make me feel like they’re in the future. On the other hand, every fifth person has a flip phone, the WiFi sucks, you can’t buy a travel SIM card at the mall, and there are CD/DVD stores everywhere.
I can’t help but feel part of their problem is how unwilling most local Japanese people I’ve met here are to break the rules.
I noticed this too, a lot of Japanese society feels like it's stuck in the 90's. Even the little things like the graphics made for ads. Probably has something to do with having a conservative culture and the demographics/economic issues that began becoming a problem around then
After living more than 7 years in Japan, I think it's that a lot of Tokyo's tech infrastructure is build around the persona of a 45 year old male office worker and his specific needs. For example, Pasmo cards can be used to buy drinks (and other things) at the train station in addition to paying for the tickets.
For example good luck getting mayonnaise with your fries at any of the fast food chains here. They have mayonnaise and they put it on burgers but they “CANNOT” give (or sell) it to you in a separate container for your fries.
This isn’t the reason you can’t get mayo with fries in Japan, though. It’s a cultural barrier against deviating from the “rules,” no matter how small. Mayo isn’t on the menu as a condiment; sorry!
Example: I once had to fill out a form (as a designated corporate representative) authorizing myself to access our racks in an NTT data center and then fax it to the DC manager (who I knew personally) before he would let me in. During this entire process we were standing in the same room.
It used to annoy me when I first moved to Tokyo, but you eventually learn to live with it.
I interviewed for a sales engineering position for Stripe APAC around December and they turned me down for only having existing commercial relationships in Japan (they were only interested in candidates with a strong commercial network in Singapore) and a little less management experience than they ideally wanted.
They offered me a role in Dublin instead, which I wasn't very interested on, and then ghosted me when I pushed to find out compensation before continuing (so I'm assuming they pay under market)
Not surprisingly, the position is still open 3+ months later
Patrick, I love Stripe's offering, but I have to pull teeth within my startup to justify why we use Stripe to non-technical people. In fact, when I put on my Product person's hat, I can see everything they tell me clearly.
Stripe just does not look or function like a credit card processor. It is nearly impossible for non-engineer folk to grasp - to the point of it not being a viable platform. The almost hermit-like reporting interfaces (the best that can be done is a bunch of paginated tables??), the lack of visibility into how charges break down at an aggregate level (how much do we pay Stripe in fees has to be pulled from a shudder export of all transactions), handling of disputes, no ability to generate monthly statements (for Connect accounts), no direct line access to an account manager etc etc - the list goes on unfortunately.
I love the simplicity, but I can tell you that Stripe is lagging far behind in functionality and ease of platform use for SMB and enterprise SaaS companies (specifically, in our case, a platform/service provider that runs payments for a bunch of small businesses). We're small, but not tiny, and growing - so the noise around the problems we face just keeps amplifying by the day. The moment we crossed a dozen customers and 100-200K in monthly processing, it’s as if Stripe just stopped working for us.
Stripe's clearly an extraordinary engineering-driven company, but solving for real business use-cases is key. From the outside, it feels like Stripe is solving all the back-end problems and optimizing it, but doing nothing about the front-end, metaphorically speaking.
I'm now having to get on calls with old-school card processing providers since Stripe just doesn't "scale" for us from a business use-case perspective. It's too catered to the devs.
Hope this falls on the right ear. I'm happy to chat more and provide my 2c of feedback if someone wants to listen.
I 100% agree with this. Stripe is fun for startups with <100'000 / year revenue, but then it gets ugly. The reporting can't be configured at all and is highly cumbersome, especially if you need something slightly different than they offer for comparability (e.g. last 7 days, last 28 vs last 30 days), and Stripe is not transparent about their fees at all in the back-end.
I'll add my 2c and say I disagree entirely. We ship mid-seven figures through Stripe yearly and I enjoy the back-end still to this day - have been using it right after it was /dev/payments and still kicking all these years on my main small business and small projects alike.
I don't see the need for "reporting" from the Stripe website as I think most businesses should be doing it on their own in their own tooling, but in the cases I want to quickly look things up, Stripe's back-end has been just fine as well.
And what is the business case and cost for "we should develop software to fill in the missing features of payment provider x instead of simply going with y"?
hi, same thought as above - if you're open to chatting about it, I'd love to learn more about how we can improve reporting for you. I'm at kathy@stripe.com
Hey blizkreeg, I'm the product manager on Reporting & Analytics at Stripe. Sorry to hear that your experience hasn't been great - mind sending me an email at kathy@stripe.com? I'd love to chat more and see if we can improve the reporting experience for you.
> The moment we crossed a dozen customers and 100-200K in monthly processing, it’s as if Stripe just stopped working for us.
This is odd. We have hundreds of monthly customers and ship physical + digital products, handle returns, disputes, and so forth fairly well.
Support has been good for us as well, if unconventional, so I'll agree with the lack of a direct line access to an AM/AE being annoying... but ultimately it hasn't stopped us from doing anything timely.
We have a SaaS product in addition to physical retailing and Stripe works very well for us and I don't see how it won't for years to come. We use third-party systems in addition to Stripe for inventory management, fulfillment, and we do reporting from pulling raw data into our own back-end and doing the work there (which... I'm pretty sure is standard with most small tech businesses, as you have much more granular control over things), so I guess we just almost entirely disagree with each other.
I think your suggestions are good... I just don't see them as being anything more than sustainment features for me.
> One of the things I enjoy most about Stripe’s work culture is the notion that “nothing is Not My Job.”
I’m very eager to know: If you want to be successful in such a culture, what mental habits/skills can you develop which let you know with confidence where to direct your attention?
How did patio11 develop these?
———
EDIT: How do you know that what you are working on is not a distraction?
Not patio11 but if he would be so kind as to allow me to hazard a guess I’d say intellectual curiosity and tenacity. Don’t stop asking why and keep digging. You’ll want to mix in emotional intelligence so when you communicate with stakeholders, you do so in a way that they feel a desire to assist you in your endeavor, perhaps finding ways to align everyone’s incentives for success.
I think you are spot on. I think a specific amount of hubris to go along with the intellectual curiosity and tenacity is important. It is the amount of confidence to say, "Hey, I can take this on. I'm not familiar with it directly but I understand enough of the context to help." You do have to be careful to not have too much confidence because then you will alienate your peers/management and be viewed as a know-it-all. It is a fine line that depends a lot on company culture. It sounds like Stripe really welcomes it, where other corporations are very "stay in your lane."
I wear an insane amount of hats at my company because 1) I'm confident/stupid enough to believe I can handle it [see the part above about hubris] and 2) I actually have a track record of being able to tackle whatever has been thrown at me. My curiosity helps me from getting bored because I'm fine jumping from researching DC EV chargers to file permissions issues to tax law to.... anything.
This is exactly true. Any tips how to identify companies that welcome this during interviews? (Or companies that don't.)
I wouldn't have considered myself as having "hubris" but I have a kind of semi-wild enthusiasm for being able to do things that people have reacted badly to before for exactly the reason you said. I'm not sure how to signal to companies "my deal is I want to do things; I will more or less literally jump off my seat to assist anyone and no job is beneath me and I will stay up and work 16 hours straight if I screw something up; but I'm not really good at hearing no".
> I'm not sure how to signal to companies "my deal is I want to do things; I will more or less literally jump off my seat to assist anyone and no job is beneath me and I will stay up and work 16 hours straight if I screw something up; but I'm not really good at hearing no".
"I have a proven track record of executing relentlessly, rapidly delivering value, and moving between internal roles effortlessly. What challenges are you facing I could contribute to in a meaningful way?"
Be more comfortable hearing "No". Trust takes time to build.
I'm very much like you, and I think startups/small companies with a flat management structure (i.e. level obfuscation as another commenter phrased it) or where most managers have engineering backgrounds.
In my experience at large companies, on teams that were technical and heavily collaborated with engineering, but were not overseen by engineering managers. Middle management was entirely focused on optimizing for metrics that were either assigned to them, or would result in career progress; instead of what was best for the company. Regardless of whether the companies claimed to have a "nothing is someone else's problem" culture. As a result, any embodiment of that principle, was either punished or perceived as creating problems by non-technical managers. Even if direct praise was often received from engineers and their managers for those actions. In that workplace dynamic, it inherently carries a lot of risk and easily puts a target on your back.
Besides posts like this that give first-hand accounts from employees. It's quite hard to identify what would be an honest signal of true dedication to that principle. Especially in interviews where you're a very qualified candidate, it's difficult to tell if interviewer is trying to selling you the idea of working there.
I don't think it's hubris that you need. Hubris often inflates and becomes the problem that you have in the next statement of being a "know it all".
Instead, I think the core of it is perpetuating "beginner's mind" - that is, you approach every problem with the enthusiasm of a beginner, not with conviction that something can or cannot be done. It's not necessarily pride or self-confidence as much as it is a belief that the thing can be done by someone, and it's just the knowledge you don't have that keeps you from accomplishing it.
Facebook culture makes a similar statement: "Nothing at Facebook is someone else's problem." I don't take it to mean that you are supposed to be the Atlas of the organization, but rather that when you see problems and issues that might arise, you don't ignore them because it's "not my job" or "not my problem" - you embrace it, escalate or forward it to the correct people, and then go back to what else you have to do.
This type of thinking stops issues from being buried when they're noticed by someone, even if it's something outside of what they are judged on in their responsibilities (and performance reviews). A good hypothetical example of this is a crash condition you may trigger as an engineer. You might not quite know what is going on but you have a reproducible testcase of a crash condition in someone else's stack, and saying it's not your job means the bug doesn't get fixed or reported. Had you submitted that crash condition and made it temporarily your problem, you could have indirectly helped patch a deserialization bug that could've led to code execution on that tier with a more malicious testcase (i.e. exploit).
In smaller companies, I think everything technical kind of ends up being your job, so your job becomes what you make of it at that moment. Do what needs to be done to ship the thing.
>I don't take it to mean that you are supposed to be the Atlas of the organization, but rather that when you see problems and issues that might arise, you don't ignore them because it's "not my job" or "not my problem" - you embrace it, escalate or forward it to the correct people, and then go back to what else you have to do.
Trying to really educate around this at my workplace.
I call it "throwing your hands up." If you run into a problem, or notice that something isn't working, what-have-you, if you throw your hands up instead of working to fix it, or find the person who should fix it, you are on my shit list.
It's hard to explain this part of ownership. But it's very obvious when you see someone doing it. Their first response is often to say something like "not my job," and they often think that Extreme Ownership or Question Behind the Question mentality covers it, but after it all shakes out in the wash, it's actually the opposite.
Maybe people need to do a better job of explaining ownership up front, or choose different words. IDK
I call it "throwing your hands up." If you run into a problem, or notice that something isn't working, what-have-you, if you throw your hands up instead of working to fix it, or find the person who should fix it, you are on my shit list.
My problem with this is that everything is always not working, or barely working, and nobody wants to hear about it. You're going to say "of course I mean important things", but wherever you look, if you look for problems, you see problems, there aren't a few things which are problems, there are oceans and oceans of problems and potential problems.
The only coherent response to this is blinders - do what everyone else does, and pretend everything is fine - until an incident forces people to face it. Then face the smallest possible case of it, and reassure each other it's fine now. I think you really mean "intuit the same judgement of importance that I have", but either you're so used to not-seeing-problems that you don't see how many there are, or you aren't willing to say that outright because it leaves the person with an escape from you putting the blame on them, and you don't want them to have an escape and you need someone to shitlist for .. I dunno what reasons. Why /do/ you have a shitlist instead of a "training" list?
"Everything broken, or barely patched together" is the norm.
Cynical people reading this, give a couple of minutes thought how many things you've experienced just today, which aren't right or could be a problem. I bet you'll pass a dozen in that time, right?
Then the rest of the organisation, including leadership hasn't embraced the approach. You can't do it unless the culture really baked in, or else you will break yourself.
What would you tell a junior engineer who feels so overwhelmed with the tasks he is supposed to be focused on that he decides not to switch task to solving this other thing that may-or-may-not be a real problem?
Also, are the phrases “Extreme Ownership” and “Question Behind the Question” from a US Navy SEAL book by Willink and Babin? Would you generally recommend that book?
Correct on the book for extreme ownership. The other book is "QBQ! The Question Behind the Question: Practicing Personal Accountability in Work and in Life" by John G Miller.
Note that isn’t the only cause of Suppression. In fact, suppression is the default as it requires mere inaction.
So another way that suppression can happen is, “oh that seems like it could be a problem. But is it? Who would I ask? Would asking about that be a distraction? {switches back to original task}”
Yet another way is, “this error email seems like this is a problem. But I’m new and nobody else is responding to it and there are like 30 of them. I should probably filter them out so as to avoid getting distracted. I wish I knew why we weren’t allocating time to dealing with these alarms. {switches to remain focused on original task}.”
I think what you call “passive suppression” is more important to pay attention to because I assume that sabotage is pretty rare but not-knowing-what-to-do and being-overwhelmed happens occasionally.
> you embrace it, escalate or forward it to the correct people, and then go back to what else you have to do.
How would you maintain this habit in a world where:
1) Time is limited.
2) Context-switching has a high time cost (see “manager time vs maker time”).
3) Communication takes effort. Describing issues conherently takes at least 15 minutes of focused time.
4) “Noticing an issue” is an event which happens at least 4x per hour? This includes seeing an alert come in via your error-reporting infra and determining if it is or is not spurious.
Your attention would be jerked this way and that. If you are in the process of reporting one issue and see another issue, do you report that first or second? How do you find time to defrag your working memory and to focus on your original task for the day?
We live in a tremendously noisy world.
Without a commitment to focus for 2 hours and ignore things other than your current task, How do you accomplish anything?
>Leaders are owners...They never say “that’s not my job".
You own your entire problem space, not just your solution. If something unexpected comes up, you're still ultimately responsible for dealing with it with the goal of solving your actual problem
In a large company it's tempting for people or teams to put up walls around what they think their job description should be. Invariably there are gaps no one wants to own and it turns toxic pretty quickly.
It's still surprisingly common for comments from ex-Amazon people to say how shoddy their infrastructure is, and for real-world outages to happen. From the outside, that doesn't seem like the result of an environment "everyone takes responsibility, and fixes the root cause of every problem" working well, does it?
I feel that in the past (present is TBD) Amazon under-indexed on developer experience, tooling, and infrastructure but I think it was caused by lack of investment, not lack of ownership. There's nuance between "Oh no, <shared_resource> broke, not my problem", and "<shared_resource> broke, I want to fix it but can't because <XYZ reason>". In my experience it's usually closer to the latter here.
Having worked for a tiny company, where this is pretty much inevitable, I'd say you define what your job is at the moment by what you commit yourself to do.
Spoiler: There are plenty of things that people avoid doing because it's not their job, it's just that this situation must sometimes be finessed a bit.
So, you don't avoid doing something because it's "not your job", you move it to another team who is better positioned to address the issue. Or maybe you deprioritize it because it doesn't fit in with your team's current priorities, etc. Eppur si muove.
> I also wrote a non-trivial amount of code because, fun fact, stripe.com spells CMS e-r-b, which didn’t optimize for writers’ ability to ship new words
> The parts of the job which I enjoyed the most were not my actual job (writing and selling software, filing taxes in a timely fashion, etc) but helping other software entrepreneurs optimize their businesses or engineers navigate career challenges.
This bit in the post about the author having previously been a founder of a business intrigued me.
As a founder myself, I know that there are bits of the business that don't fit into my natural skillset but have to be done. That is accepted as part and parcel of running a business.
The second point intrigues me though. In my decades of running my own software business, I have had a lot of staff come through as employees, get skilled up, then leave to start their own businesses using the skills they learned while at my company.
This actually gives me a great deal of pleasure and pride. I LOVE seeing people's career pathways take off, and I love it more if I had contributed in some way.
I was in a small company working on payments team as fullstack engineer. Given the big volume, stripe would be too expensive for us. So we built our own credit card processing service. We integrated with FirstData directly. While I was working on payments, I kept following news about stripe. I love their design and appreciate the deep care they put in their product, even the documentation. I like Patrick and John's inspiring stories and love watching their interviews. After 3 years, I was looking for a new opportunity. Stripe is my dream company. I was lucky to get a phone interview. The conversation went fine. The coding problem was easy. But I could tell the interviewer was not impressed. I couldn't figure out what and why. I was depressed when I got the rejection email. I'll definitely want to try again. Anyone advice or suggestions Stripe folks could offer would be greatly appreciated!
Did they give a plausible reason for their rejection? I am just interested if the trend for job rejection reasons is moving towards a more transparent model. In the past and present, it is extremely difficult/frustrating to get the real answers for being rejected.
They didn't give me any specific reasons. The recruiter called me one day after my video interview. She only told me they didn't think I was a good fit. In the interview, I finished the coding questions in 30 mins. Then I just had a chat with the interviewer. The conversation went fine. He told me he was full-stack eng and worked on frontend. I asked him whether he worked with Benjamin De Cock, a stripe designer I admire and if he could share some stories. He said yes but didn't want to share stories.
I like the remote coffee at the end. I'm remote and I want it to feel more like I'm having coffee when I'm talking to people I work with. Any suggestions on how to make remote conversations more like getting a cup of coffee?
At Twilio we use Donut. The TLDR is with our configuration every third Monday members of a slack channel (#soc-donut in our case) get randomly paired via DM. I've met people from offices around the world which I wouldn't have done otherwise, which has definitely been of personal and professional benefit to me
@patio11 could you elaborate on the internal communications structure at Stripe? I’m curious how employees these days balance the use of different communication tools, especially as Stripe has grown and begun embracing distributed work.
I heard [0] for a long time it was all about long form posts to a massive number of Google Groups mailing lists with custom tooling to manage subscriptions (bc the Groups UI is poor). I understand these lists range from general to hyper specific.
But then I’ve also heard much of the communication has shifted to Slack or other tools. Slack tends to degrade into chaos at a certain size, and at Stripe’s scale I’m curious if this is a big pain point or how you mitigate it.
I am not patio11, but I do work at Stripe. Both are true; we use a lot of email, typically with lists, and a lot of Slack.
Other tools, like a wiki, an issue tracker, Home[0], and a culture of "run" rotations (like on-call but for helping folks on other teams) help keep chaos manageable.
It might be interesting for us to write up another update on this, since many folks are curious...
As a Stripe customer processing about USD600K a year through them, I have to say they're an excellent outfit.
Their documentation is very clear. Their email and irc support is smart and responsive, with nary a "I can help you with that today" script recited by an agent to waste my time.
They set and meet expectations about the financial stuff, like how long it takes for transactions to hit the bank, and what happens with disputes and chargebacks and other parts of the world of serving real paying people.
It's not hard to guess that the things in this article are all true.
I like a lot of things about Stripe but this is by far the best part:
> Their documentation is very clear.
In a world where no one gives a shit about cleanly documenting processes - especially ones that are versioned or change - I really appreciate Stripe's dedication to this.
> (An example which is just a boggling fact about the world: what’s your finger-to-a-wind guesstimate about what percentage of credit card payments fail with error code I Don’t Know Sometimes Things Fail In Credit Card Land? Hint: it’s higher than you think. Those failed payments cost conversions at the margin. When Stripe fights that number down by a basis point, that creates value across our entire portfolio, forever.)
I have no idea what the percentage is but I recently had a decline I think may have been from Stripe itself.
A few months back I’d dropped my car off at the shop and tried to Lyft home. I’m a very infrequent Lyft/Uber user. Lyft refused to accept my payment. Tried with two different cards (Chase, AmEx) both directly, via Apple Pay and via PayPal. Couldn’t hail a car.
So then I try with Uber. Same thing! Payment rejected, no car for you.
I wrote to both Lyft and Uber customer support. Never heard back from Uber. Lyft claimed my card was denied (“It appears that the card is not working due to a decline from your bank. Because the information we receive about bank declines is very limited, you’ll need to reach out to your bank directly for more information as to why the transaction was denied.”) I contact both my card companies - they tell me there are no blocks on my card nor anything that would cause the payment to be rejected.
The only thing I could find Lyft/Uber had in common was they both used Stripe.
(But that doesn’t explain not being able to pay via Apple Pay/PayPal unless those somehow route through Stripe.)
Never did figure out what it was (“Jay, I had checked and verified that the last four of the card that you have provided is already added on this account. There shouldn't be any issues in requesting for a ride. If you had any issues with your Lyft request. Please kindly send a screen shot so that we will be able to see and rectify the issue.”) and haven’t had cause to use Lyft/Uber since.
This incident is the only time I can recall payments being rejected like that. I think Chase once temporarily blocked an Internet payment, sent me a notification immediately, I indicated the charge was legitimate, tried again and it went through.
Oh well. (I ended up getting a ride home in the shop’s customer service van.)
Not sure about their Paypal integration but worth noting that with ApplePay, they're likely still using stripe as the processor (ApplePay generates an authorized payment token which is then passed to Stripe for processing). So if there was a Stripe problem, ApplePay being busted too makes sense.
I think they use both according to some Googling I did at the tome. A common payment provider seems like the most likely explanation to me so unless Uber also uses Braintree that would rule it out. It's possible something about this purchase was triggering fraud detection on two completely independent systems, which would be dismaying since this was a legitimate charge.
It's huge. Like "you'd never believe it if you couldn't see it with your own eyes" huge.
As a data point, one business I work with offers subscriptions, and sometimes the majority of its entire churn is caused by unexplained failed card charges from Stripe. For comparison, where Direct Debit schemes are available in Europe and used by that business, they essentially never exhibit unexplained charge failures.
To put that in terms of somewhat realistic numbers, say you have a 97% retention rate on a typical monthly subscription for some SAAS offering. After 12 months, just from attrition, you have lost more than 30% of the subscribers you had at the start of the year. This is why improving retention for subscription business models is such a big deal. Now suppose you have a 92% retention rate, because you're losing an additional 5% of subscribers each month due to failed charges. After a year, you have lost over 63% of the subscribers you started with. That's a devastating difference.
Now suppose you are also attracting new subscribers at a respectable 10% per month. In the first case, you have net 7% growth per month, meaning your business will be around 125% bigger at the end of the year. That's more than double its previous size -- yay for hockey stick growth charts! But in the second case, with just 2% net growth per month, your business is only 27% bigger at the end of the year. The 5% losses due to unclassified failed card charges have basically cost you as much as your entire business made last year in terms of lost growth.
Stripe do seem to be aware of the problem, because they have rolled out a number of systems over the years for retrying failed transactions and the like. Unfortunately, these systems have often been rather complicated, incompletely documented, and most importantly almost entirely untestable before deployment, which seriously undermines their value.
In our experience, shifting subscribers to other payment methods can be an effective solution if it's an option, but of course in places like the US card payments still dominate. If that's where your customers are, you could probably save a lot of lost business by handling those failure flows better. Just be aware that with Stripe in particular, you may have to read between the lines in the documentation, put your first integration into production largely untested, and then rely on monitoring your logs to pick up and deal with problems if you've done anything wrong.
Sadly, your assumption is incorrect. Some of the time, as a merchant, you do get a specific indication of problems like insufficient funds or an expired card. The problem we're talking about here is all the other failures, where you just get some entirely unhelpful generic code that translates roughly to "declined, for reasons we're not going to tell you". From personal experience, this second group can often represent the much larger share of total failures.
When a generic code comes back, you don't get your money, but in a not insignificant number of cases, you do get an upset customer contacting you to ask why their payment didn't go through when their card should be fine and they've been using it with you for a year now and they just used it this morning at their local store with no problems. You can understand their frustration.
The reality is that most people don't realise how horribly unreliable the card payment infrastructure we rely on actually is. They can and will blame the merchant who declined their card if they don't know of any reason that it shouldn't have worked. Even if they don't blame the merchant explicitly, having their card declined causes a lot of people some embarrassment, and that is not a reaction you want associated with your store or service if neither you nor your customer has done anything wrong.
Disclaimer: I'm not familiar with these specific numbers.
Anecdotally I've had my own cards denied because I've reported my card missing and had to get new numbers. This is fairly common from what I've seen, many people I know have had issues because of this (late fees, etc.). Just another case I thought I'd add, as we sufficient funds and it wasn't fraud.
I’ve had Apple Pay payments get rejected due to internet issues — make sure you’ve a solid LTE signal, not on dodgy wifi, and perhaps flip back to airplane mode temporarily next time it happens.
Thanks, was on LTE. Had no trouble interacting with either app, adding payment method, using the Internet, etc. It was just the payment being rejected. I think this had to be a common payment provider issue, and who knows what fraud detection flags I was triggering for whatever reason.
> It also felt like it was constraining the absolute amount of impact I had for the world.
It's refreshing to see people thinking like this. Maximizing impact is undervalued. For instance a lot of companies restrict themselves to one country thus dramatically reducing the maximum impact.
Due to differences in regulation I would expect there to be instances where focusing on one country would have more of an impact than spreading your resources over multiple jurisdictions. I would even guess that this is true for most companies below a certain scale. Reduction/standardisation of regulation should reduce the value of scale for which this is true, though other factors such as geography would still play a role.
After reading all of that and thinking "Stripe sounds like a really cool place to work", I'm a bit disappointed that they don't have an office in my country and "remote" means "remote in North America".
Oh well, I'll keep working with them to build cool stuff for my clients :-)
I checked out the list of remote engineering jobs after reading your (fascinating) article but unfortunately they all seem to be restricted to North America. Is this a time zone issue or a legal issue? Are there plans to expand remote jobs to other regions (like Europe)?
As time goes to infinity we plan on having Stripes building products very close to as many of our customers as possible, which is (much) more widely distributed than the status quo, which is (much) more widely distributed than open recs on any given Monday. There will be more on this subject coming later.
> Stripe is headquartered in San Francisco, with offices in Dublin, London, Paris, Singapore, Tokyo, and more
That's probably the countries where they can hire remotely. It would seems in my experience with other companies that even if they don't advertise non-US remote roles (probably to prevent a large influx of applications from all over the world, most of which invalid due to no-offices there) they will accept candidates that are better than the US counterparts (but still US-based workers have an advantage).
I was surprised to see most (all?) remote roles are US-only. Are you working to change that, at least for countries where you otherwise have a legal+employment presence?
Definitely not my favorite credit card processor. For starters, I will not earn any money if I refer my customers to stripe. It's already a non-starter at that point.
I'm a Stripe employee & would like to know more about your POV here.
What other processors pay you for referring your customers, and whom are your customers?
Very curious. Since processing is a low-margin business, it's really rare to see referral bonuses, especially the type you're describing. If we do have room to open up a program like this, I could mention it internally.
I'm not sure it really matters - and not just because Dorsey isn't CEO of Stripe. Whatever you think of him, whether you'd agree with them or not, the advice is good: you may want to bear your thoughts in mind, whatever they are, before applying to work at a company for which he is CEO.
(Of course, if you're careful to frame it equivocally, as hopefully I've managed to do, it does come out sounding a bit, well... obvious. But that's fine. Sometimes good advice is obvious.)
> The font of the logo as we know it today, along with the yellow line, was adopted in 1998. The yellow line started out curving down and now it curves up.
That feeling you get when you finish a challenging project, write a great shipped email, and get a bunch of feedback from folks throughout the company is pretty amazing. Once I was invited to convert one of my shipped emails into a presentation for a company all-hands meeting. I had a less than a week to get it done, which was pretty hectic, but in the end it turned out great and it was perhaps my favorite memory of my time at Stripe.
I enjoy my current job, and those little dopamine hits I get from checking things off my list as well as the bigger ones from finishing projects, but now only my boss and some teammates notice when I finish something. One thing I learned about myself, is that I really do care about what other people think about my work.