In my experience, Stripe is full of very smart, interesting people, but most of what's described here is an aspirational view of how the current executives think product should work at Stripe. That's OK, in some sense any view of the "self" is going to be aspirational, but it seems naive/koolaidy to believe that all of the following things can be true at the same time (these are all quotes from the article):
- "it’s an incredibly deep-thinking culture. It’s a written culture really focused on getting to the right answer"
- "The company is especially dedicated to moving very, very fast."
- "deep thinking and speed are combined with a substantial amount of user focus and user empathy."
- "We talk a lot about building multi-decade abstractions."
- "Quick-thinking, quick-acting people do really well here."
- "It’s craftsmanship and a huge amount of dedication to getting all of the details right."
- "There is just the feeling that it should all be exceptional. We should push for an extreme quality bar on all of the fronts."
This seems like a pretty standard fluff piece that's aimed at recruiting PMs who want to identify as near-super-human talent. Stripe is a fantastic place to work but this kind of communication does them and their employees a disservice -- that said I'm not a recruiter and can't say what kind of tactics work best for finding PMs.
I can see how many of those items fit - at times I thought they were literally describing me.
Founder that got into products at first using CompSci skills - but finally realized it is the problem solving through business that kept me engaged and pulling me back.
The 30 year vision helps stretch the mind from what is around us (pulling from what is know) to creating an ideal solution and working backwards.
While it’s true we are always hiring, this wasn’t meant to be a recruiting piece—it’s a personal interview Ken (the author) asked me to do based on demand from his readers.
It’s fair to say this is how we want product building to work, and we certainly don’t always live up to it. But I do think it’s broadly reflective of the operating model our product managers, engineers, etc. aspire to and what we hold ourselves accountable to. Do we fall short of our own aspirations regularly? Absolutely.
The interview is certainly useful in that it reflects Stripe's aspirations as a product team. I would have found this interview much more interesting if you had been able to go into detail about the reality of working on a product team where you're holding yourselves to a set of mutually incompatible constraints -- what tradeoffs you tend to make, how you think about making them, what are the common failure and success modes. Maybe a good follow-up post; consider this a single reader's suggestion, not a demand :)
I think little of zeal outside of close-knit groups. It takes too much effort, it's easily misdirected, and it can be faked. At scale, it incurs a deficit between input and output, willpower and reality, and eventually achieves its close cousin and exact opposite, cynicism. In the world after zeal, trying becomes pretending, enthusiasm becomes opportunism; anything done the cause becomes suspect in the eyes of those who had to suffer the cause.
The inability to control zeal seems common to communist republics[1], "rocket-ship" startups, and other half-baked endeavors that don't know how to get work done without demanding religious fervor/perfection from their unfortunate subordinates.
I hear this “fast is slow, slow is fast” type culture perpetuated a lot in product. What they’re describing is lots of experience, practice and general intelligence. Always feels pretty masturbatory when you write it out.
Am I alone here in feeling like that all sounds incredibly exhausting and like a pretty draining place to work, and not-so-subtly seeks to attract workaholics?
It's like there's lip-service to things that we as software engineers enjoy about our profession (eg craftsmanship, deep thinking, high-quality work), but it comes across as just throat clearing before hammering in "moving very, very fast". I read that constant repetition of "moving fast" as "you will always have an endless backlog of work that you will nonetheless have to endlessly crank through with all your energy, and our hiring/retention policy only selects for that"
> Am I alone here in feeling like that all sounds incredibly exhausting and like a pretty draining place to work, and not-so-subtly seeks to attract workaholics?
Yes, but if someone loves what they do why wouldn't they want to immerse themselves in it and get paid well for it?
How to burnout 101. Setting an unrealistic performance expectation by doing what you love is fine, but that expectation won’t cease once you are asked to do something uninteresting or frustrating.
Get used to it because with product+agile that is how everything is going. Bunch of MBA middlemen trying to make your hour as productive as possible for the product. You get little say in your day to day, constantly managed and keeping admin productivity sites up to date so they can allocate you for what they see fit. RIP tech jobs, enjoy it while you can.
'Moving very, very fast' for me personally doesn't imply breakneck speed, burning bridges, breaking things, etc. You can still take time to think AND move quickly. Far too many (software) engineers can dwell endlessly on 'The Best Solution' and never get anything done.
That said, I'm pretty sure if you are a tech company, time and timing is of the essence to get your products to market and find out what needs to be changed asap.
Also, there will always be a never-ending backlog. That's why you make decisions and prioritise.
Stripe doesn’t “need” to do anything - you get what you pay for - pick a cheaper gateway with an inferior product if you’re willing to pay less for a lower quality outcome
I often hear about this concept of deep thinking and deep drive into user stories. My experience sadly is much of the work in companies is dominated by smaller tasks. I'd love to know how stripe handles this balance between big feature developments and smaller issues.
One thing that stood out to me was the aspect of having a strong culture of writing. Could anyone talk about how Stripe's culture of writing works a bit more? How does this manifest in things like product decisions/direction, setting technical direction, designing systems/APIs, etc?
In particular I'd like to know how document management happens, are these just Google Docs? I've participated in some OSS projects with Googlers and they love to put together crazy heavy Google Docs.
Do you mind sharing some examples of these Google Docs and what their contents are? My current workplace seems to be running on the mantra of "do first, document later... make that never" and I'm trying to change it by stressting high-quality documentations and clearly documented requirements.
1) >>> Stripe runs on written long-form documents in a way that I haven’t seen before. <<<
2) >>> The product shaping document will come at it from the perspective of a user. <<<
When you combine bullets 1 & 2, it makes for very good documentation. It was one of the things I loved about Stripe when I first tried to use them (plus the simplicity of the product at that time).
However, my latest experience with Stripe is that their documentation is becoming similar to Google documentation i.e. multiple pieces of documentation describing the same thing but the different documentation is not consistent especially when they are using the same scenario. For example, you might see 2 different documents (from Stripe) that talk about embedding an online payment form and those 2 would have the same example but one would give the impression that you only need to deal with X attributes while the other one will show you that you actually need Y attributes. Some of the attributes could also be named differently (the name has probably changed and one document has not been updated while the other has or was written after the attribute was changed).
This is similar to my experience. My company <redacted> is doing a stripe integration and I wasted a week playing with the multiple different sample apps that were provided "as is" and only made significant progress by ignoring them and building my prototype up section by section from the "getting started" documentation.
Hi! I'm Jordan, a manager on the Documentation team at Stripe. Thank you (and thank you to others on thread) for sharing this valuable feedback. It would be great to get more details about your experience. This kind of feedback allows us to make specific changes that will help you (and likely many other users) in the near term. Drop me a line at jordan@stripe.com and I'd be more than happy to chat.
31 comments
[ 2.5 ms ] story [ 87.8 ms ] thread- "it’s an incredibly deep-thinking culture. It’s a written culture really focused on getting to the right answer"
- "The company is especially dedicated to moving very, very fast."
- "deep thinking and speed are combined with a substantial amount of user focus and user empathy."
- "We talk a lot about building multi-decade abstractions."
- "Quick-thinking, quick-acting people do really well here."
- "It’s craftsmanship and a huge amount of dedication to getting all of the details right."
- "There is just the feeling that it should all be exceptional. We should push for an extreme quality bar on all of the fronts."
This seems like a pretty standard fluff piece that's aimed at recruiting PMs who want to identify as near-super-human talent. Stripe is a fantastic place to work but this kind of communication does them and their employees a disservice -- that said I'm not a recruiter and can't say what kind of tactics work best for finding PMs.
Founder that got into products at first using CompSci skills - but finally realized it is the problem solving through business that kept me engaged and pulling me back.
The 30 year vision helps stretch the mind from what is around us (pulling from what is know) to creating an ideal solution and working backwards.
While it’s true we are always hiring, this wasn’t meant to be a recruiting piece—it’s a personal interview Ken (the author) asked me to do based on demand from his readers.
It’s fair to say this is how we want product building to work, and we certainly don’t always live up to it. But I do think it’s broadly reflective of the operating model our product managers, engineers, etc. aspire to and what we hold ourselves accountable to. Do we fall short of our own aspirations regularly? Absolutely.
The inability to control zeal seems common to communist republics[1], "rocket-ship" startups, and other half-baked endeavors that don't know how to get work done without demanding religious fervor/perfection from their unfortunate subordinates.
[1] https://en.wikipedia.org/wiki/New_Soviet_man -> https://en.wikipedia.org/wiki/Homo_Sovieticus
It's like there's lip-service to things that we as software engineers enjoy about our profession (eg craftsmanship, deep thinking, high-quality work), but it comes across as just throat clearing before hammering in "moving very, very fast". I read that constant repetition of "moving fast" as "you will always have an endless backlog of work that you will nonetheless have to endlessly crank through with all your energy, and our hiring/retention policy only selects for that"
Yes, but if someone loves what they do why wouldn't they want to immerse themselves in it and get paid well for it?
That said, I'm pretty sure if you are a tech company, time and timing is of the essence to get your products to market and find out what needs to be changed asap.
Also, there will always be a never-ending backlog. That's why you make decisions and prioritise.
That actually pisses me off. Makes me feel like I have been wasting money
2) >>> The product shaping document will come at it from the perspective of a user. <<<
When you combine bullets 1 & 2, it makes for very good documentation. It was one of the things I loved about Stripe when I first tried to use them (plus the simplicity of the product at that time).
However, my latest experience with Stripe is that their documentation is becoming similar to Google documentation i.e. multiple pieces of documentation describing the same thing but the different documentation is not consistent especially when they are using the same scenario. For example, you might see 2 different documents (from Stripe) that talk about embedding an online payment form and those 2 would have the same example but one would give the impression that you only need to deal with X attributes while the other one will show you that you actually need Y attributes. Some of the attributes could also be named differently (the name has probably changed and one document has not been updated while the other has or was written after the attribute was changed).