13 ms·

What I Learned at Stripe

193 points by yarapavan 4y ago

AgentOrange1234 4y ago
The auto-collection of nice-job messages sounds completely awesome. I wish I had this for my team.
- ageitgey 4y ago
  We have that feature at our company through an employee review SaaS we use called Lattice. Our #praise channel works the same way and it has definitely been a nice surprise. It is really nice to be reminded of all the feedback at review time. Maybe other similar employee review systems have a Slack integration you can turn on - it sounds like maybe it is a common feature now.
tapanjk 4y ago
> This practice normalizes gratitude in the team, and sets a mild expectation for recognizing the people who helped you that week. Honest question if your team also does this. How do you differentiate real thanks from the thanks of the week? I ask because in my experience kudos at a regular interval works for a while when it is launched but stops being effective over time, in some cases producing the opposite of intended effect.
- francis-io 4y ago
  How are "real thanks" and "thanks of the week" different?
  - tough 4y ago
    One feels sincere and not scripted and the other well is company policy?
    - nbaugh1 4y ago
      Company culture and company policy aren't the same thing
      - eweise 4y ago
        Then why does the Company usually have five to seven cultural values they plaster on the wall and form the basis of employee reviews? Feels like Company policy to me.
  - jon-wood 4y ago
    I've definitely experienced similar, mostly when thanks are rolled up above team level into large all-hands type meetings though. In those cases you'll get senior managers polling everyone to submit some thanks so that their team isn't under-represented in case it looks like they're not pulling their weight.
- gary_0 4y ago
  At first glance, I definitely like the ideas to encourage positivity and gratitude. But I had the same worries as you: if things go wrong these same ideas could get twisted into toxic popularity contests and "pieces of flair" mandatory fun. People could start comparing how many kudos each employee profile has, then start pushily soliciting them, and then "kudos inflation" happens... Maybe things Just Work so long as you avoid hiring jerks, and people feel secure enough in their jobs that they don't see the need to anxiously compete with their teammates. (Some company cultures definitely go the opposite direction, favoring cold-blooded ambition over prosocial cooperation.)
- jt2190 4y ago
  You can’t, so you assume that all thanks are “performative” (insincere). The action thus becomes indicative of adherence to group norms for the performer, so more of a culture-fit test for the person giving thanks. There could also be an in-group acknowledgement by being thanked if the performative culture gets really strong.
- nahname 4y ago
  Something like this only works if your leadership team believes in it. If they give and receive feedback through the same system, align incentives to keep it going. Then this kind of feedback will thrive.
- xkjyeah 4y ago
  /++ are spontaneous. Any time your colleague makes a great presentation, does you a favour, you /++ them. If there are regular weekly kudos, it'd be a team-specific thing. /++ were really common before a couple of years ago, but I get the vague feeling it's usage is declining. It used to report the accumulated number of pluses you got... So you could tell who have been the really helpful folks (or really tenured folks) out there, and for great contributions, you'd really want to chime in to a wave of ++s to show your appreciation. Without the numbers, usage seems to have declined a bit, since there isn't the satisfaction of seeing a colleague's karma go up by, say, 10pts after a great presentation. Still, it's a great culture tool, and something I'd want to spread at my next employer's if I leave the company.
  - eweise 4y ago
    All these company games just seem like a way to get people to do more work. In addition to doing your regular work, you now have pressure to score really high cudo points on your presentation. Can't just throw together some bullet points. Will need to work the weekend coming up with some awesome graphics.
    - deleted 4y ago
      [deleted]
    - deelly 4y ago
      So, cynic inside me thinking this is just another metric to game in office games..
- ericmcer 4y ago
  Yeah I think this is a good idea but ignores that every piece of positive feedback is potentially negative feedback for someone else. We have all probably experienced working really hard on something that isn't very visible and receiving very little credit for. We have also probably experienced working on a flashy but relatively simple feature and getting lots of praise for it. It would be a good way to quantify small things like answering questions, giving good code reviews, etc. that can go unnoticed.
jack_riminton 4y ago
Really like the idea of Friction logs, it's so easy to become blind to things that don't make much sense
- zsteinkamp 4y ago
  Try it today :)
- emptysea 4y ago
  Friction logs are all well and good but only if you have the time to action on them At a past company we had a new lead designer come in and write a huge friction log but nothing happened because we’re already busy with tons of other higher priority stuff
likeabbas 4y ago
I learned there that if you build a successful startup on Ruby, your infrastructure costs are going to be insanely high trying to make it scale and you'd be better off using a typed language with true multithreading and a solid GC.
- faitswulff 4y ago
  You could learn the opposite lesson as well, that if you want to create a successful startup you need a dynamic language that responds to business needs and you can put off worrying about infrastructure costs until later.
  - likeabbas 4y ago
    Your argument is based on a fallacy that you can build something faster in a dynamic language than a typed one. IMO that argument fails when you need to onboard new people to read the codebase and contribute to it. I'd argue you will be able to onboard people faster to a typed codebase than a dynamic one. And for me personally, I don't see a difference in my ability to produce code between Java/Go and a dynamically typed language.
    - faitswulff 4y ago
      That's not my argument. My argument is that without more data, your original statement that "you'd be better off" is just as subjective. In fact, with data, we see rather the opposite picture: > Y Combinator, an accomplished investment fund, and startup incubator has published a list of its top 100 graduate companies ranked by valuation as of October 2019. 8 out of the 10 most valued companies in the ranking were built using Ruby on Rails. https://spreecommerce.org/ruby-on-rails-most-popular-among-top-y-combinator-companies/ https://spreecommerce.org/ruby-on-rails-most-popular-among-t... I'm not entirely convinced, but my main point is that polemic based on individual experiences is wholly subjective.
      - likeabbas 4y ago
        No it's not. You would objectively be better off in Java or Go than Ruby once you reach scale. Java and Go can truly utilize multi-core threading, and have superior garbage collectors. This matters a lot for latency requirements
rtpg 4y ago
the gratitude thing is kinda fun. I imagine that managers treat that as a "positive only" indicator (lack of gratitude markers should not be counted as a negative, but a lot of them should be counted as a positive), since it's dependent on coworkers who do that kind of thing. In a previous job I would always offer "e-bux" for fixes. I was half tempted to write a quick backend to track these e-bux, but gamifying that sort of stuff has its own consequences as well... > If there is an issue with a single deploy, it stops the whole company from shipping changes. This definitely feels odd to me. Monorepo shouldn't mean mono-artifact! Perhaps this is more theoretical/one point, but if Stripe engineers feel this and this person felt this after less than a year... Bazel is nice y'all. (EDIT: I'm being too harsh here, CD in particular probably makes the calculus on rollouts very tricky)
- cicdmonorepo 4y ago
  > If there is an issue with a single deploy, it stops the whole company from shipping changes. I don't agree with this characterization. There is a way to 'lock' an entire repo from deploys, but it's not very frequently used. Single-service deploy blocks are common (if an autodeploy fails, or a team is aware of an issue and actively fixing it). Stripe uses Bazel heavily. > there was a project well underway to pull some core product / business functions into specific repos This quote from the post is also not true to my knowledge: new repos are not allowed and teams are actively working to migrate small repos into the monorepo(s).
  - rtpg 4y ago
    Thanks for the feedback, and very glad to hear that there's a distinction going on between merging and deploying.
- ketchupdebugger 4y ago
  > the gratitude thing is kinda fun. I imagine that managers treat that as a "positive only" indicator (lack of gratitude markers should not be counted as a negative, but a lot of them should be counted as a positive), since it's dependent on coworkers who do that kind of thing. Depending on how it's done. I've seen similar systems where it became an additional metric to measure an engineer. Engineers became upset if they helped a coworker but did not receive any gratitude. (not receiving gratitude means that the help is not documented, so the helping engineer can't claim it during perf reviews)
ctvo 4y ago
> Caught up in Stripe’s Nov 2022 layoffs, which primarily affected new hires like me. Both in the author's resume and in the article they felt the need to clarify that Stripe layoffs hit new hires primarily (... it wasn't due to their own performance). Is this true? ~6 people I know who were hired in 2021 and 2022 are still there.
- likeabbas 4y ago
  The majority of people laid off were hired in 2021 (including myself), and then 2022. There was a graph posted to Blind before we lost access
  - atomicnumber3 4y ago
    82% of the company was hired after March 2020, and the average tenure of a software engineer is what, 3 years?
  - metadat 4y ago
    How did you lose access to Blind? I thought once you are logged in once you pretty much stay authenticated on the device.
    - Keats 4y ago
      Companies can require a force re-auth on blind so laid off don't have access to it anymore.
      - metadat 4y ago
        Gross, it was better when companies had no control over blind. This way doesn't feel safe or anonymous, what's stopping Blind from cooperating with companies on other efforts? Thanks for the heads up.
      - nsenifty 4y ago
        Is this documented somewhere? As a data point, just a day after my last day at $FAANG, my blind required re-auth. I still have access to my older mid-size company blind via a separate account since 2019. Just wondering what other services Blind now offers to employers.
nvarsj 4y ago
VSCode on remote VMs is a really great DX. Preconfigured / managed environment with good links to local infra means anyone can work fully remote from any kind of device. And it makes setup time very short regardless of the project complexity. I suppose the main issue with this kind of approach is cost - a powerful enough AWS instance is really expensive. But you can get beefy dedicated servers from Hetzner for 100/mo that might be a good option for smaller shops.
- joshribakoff 4y ago
  Disagree, if you need to connect to a network to run the project locally your DX is the worst of the worst. You should be able to run the project locally with docker containers if not on the host machine, the only caveat is if you work at a company like Google where you’d need to spinup thousands of services, but even then you should be able to run the service youre working on locally, at least with unit tests or in isolation, your DX indeed is bad if not. If you cant even use your editor locally thats super cumbersome
  - clintonb 4y ago
    We can use editors locally. I’ve used RubyMine for my entire tenure. I find devboxes hold a few advantages over running Docker locally: 1. We can have multiple devboxes to aid switching between branches. 2. Services are more easily spun up and down as needed. If I’m only working on the API, I don’t have to waste local resources on the frontend. 3. Devboxes replicate more of the service networking (Consul) to aid debugging (versus using container networking).
  - zamnos 4y ago
    The problem with local dev, across a large developer org, is that it is local to each developer's machine. Which means that if there's some problem with it, that each developer has to spend time fixing it, or eventually end up going to IT or other devs and ask for help. And devs hate asking for help. The benefit of remote dev, along with standardizing on an editor, is that the company and IT department can say "here is a thing that works, use this one", instead of debugging weird issues on individual developer laptops. If you're IT and someone comes to you and says their mouse doesn't work, do you break out the screwdriver and open it up to try and fix their mouse, or do you just give them a new one that you know works, so they can get back to work while you look into the problem later. Local dev is great when you're at a small company and just starting out, no support, but once you're a software dev working alongside other software devs, most of whom are smarter than you, and then there's a whole other team of devs dedicated to your experience as a developer; local dev feels like a little folksy hometown sort of endeavor. Don't get me wrong, local dev has its place, and some things like writing firmware will always want that, but the industry's moving past it for big picture reasons.
shubhamjain 4y ago
I am glad author found the time at Stripe to be a great experience, but the points mentioned may not be rosy to everyone. This is not to say Stripe is a bad company, but what works for you, might not for everyone. > Keeping team channels public helps to keep everyone on the straight and narrow in avoiding badmouthing other people or teams in the company. Shit-talking was culturally unacceptable in the team. If a private DM conversation started to go in that direction, someone would speak up to take the conversation to a public channel, and things returned to a more constructive tone. The intention isn't bad here, but if it isn't said on Slack, it will mostly be left unsaid or will be said in closely knit groups. It's not always possible to be critical of someone on a public channel. The culture of everything must be public can easily result in perpetuating bad hires. Of course, no reason to worry if everyone is 10/10 employee, but this isn't always the case. I mean, are you suggesting that there were no mumblings of mismanagement after Stripe laid off 10% of workforce? > The Atlas team does track date estimations, but those dates are always accompanied with a confidence level in that date. It is understood and embraced that these numbers will change over time, and changes are always communicated clearly in writing, and sometimes discussed in weekly “Ships Review” meetings. This just becomes another field that employees have to fill, without adding any real value. Software development is simply a messy process. How can I estimate my chances of reaching the due date? It all depends on unexpected roadblocks, and the problem being more complicated that I initially estimated. > The Atlas team also reinforces this in their Friday wrap-up meetings in a segment called “Mad Props”. The /++ feedback is collected by the meeting DRI (see below) into a meeting doc, and others from the team can add their own kudos and mad props to that section. The person doing the thanking reads or mentions their items for the team to hear in the meeting. Again this isn't problematic, but a mechanism for gratitude isn't unique to Stripe either. In fact, I have only few companies where it wasn't there. The problem is that it quickly becomes where everyone is thanking everyone. And maybe even thanking for not the right reasons. Let's say Employee A thinks that creating lots of UML diagrams is a good quality and they thank Employee B for working that way. But I simply think it's a waste of time. Since you publicly thanked someone for that, it'll make everyone believe that's the ideal way to work. It's possible that I might be wrong, but public gratitude unintentionally signals what is valued at the company, which may or may not be in best interests of it.
hiidrew 4y ago
The direct user feedback sessions seem valuable. We do a lot of user research but often the findings only interest specific teams or individuals. The openness would be interesting to experiment with, same with the Twitter search bot. The friction logs also seem beneficial from a UX lens. Almost like a light version of a heuristic evaluation.
- zsteinkamp 4y ago
  Take the lead on starting it in your team :) Just invite a user to a Zoom call and ask them some questions.
pramodbiligiri 4y ago
Regarding "Dates have a % confidence", has anyone else used this system in practice? How has that worked out? Do current project management tools allow you to put a confidence interval next to estimates?
- jabart 4y ago
  I've used this phrasing in large consulting projects and it tends to help in the communication. It's all a made up number to just let someone know how the team is feeling about a date and if things are in trouble early enough. Business owners tend to understand it well compared to "the deadline looks tight".
- JohnFen 4y ago
  I always put on confidence level on projected dates (and that confidence level is never "100%"), both formally with my own companies and informally when working with others. I think it's incredibly useful for a number of reasons, but the primary benefit is in managing expectations. For instance, just today I was asked when I could finish a task. I answered "I'm 80% confident I can deliver in two days". If I leave my confidence measurement off of that and just say "two days", it could lead others to make inflexible schedules and a delay could derail things. Giving a confidence level gives them an additional bit of information that can be very useful. Sometimes, I've said something like "80% chance of 2 days", and the response was "what would it take to make that 90% (or whatever)." That's also very valuable, because then we can have a realistic discussion about tradeoffs/prioritization in scope or quality to gain more certain scheduling.
- grrdotcloud 4y ago
  Love it. Use it in many previously manager roles and personal projects. How I currently work on each Sprint. Anytime I'm tasked I make sure I understand exactly what's expected and when it's due. I get it in writing until we've established trust. Then I deliver. I'll agree to work that I know, barring any unforeseen circumstances, I can accomplish in two weeks. Thirty hours. Ninety hours? Whatever it takes to complete the work. I would ask people that were agreeing to work, that if they were comfortable quitting their job or refunding me all the contract money if they failed. Sometimes they would say yes, other times no, other times they would look at me with bewilderment. I would ask them only to take on work that they knew they could complete. Sometimes they would adjust the estimate, and I would thank them for it. Everyone wins when people hold their word. There have been times when I have had management, very upset, demanding to know why I did not complete a task. I asked them if I ever agreed to it? They would say no. And I would say then, why would you expect me to complete it? While I do not ask for a percentage completion, I look for a binary response. We can adjust the scope, we can adjust the timeline. We cannot adjust the completion status after the deadline has elapsed. I have agreed to work not knowing how to do it, only with the confidence that I knew I could get it done, or subcontracted out at zero gain. As for project management tools to capture this, no. I did develop my own team tracking methods. We had a internal facing fail board. If you failed, you made a public note. This was encouraged. We fail, we learn, we do not lie. Others would ask, how did you fail? We would tell a story and we would all learn. The goal was to have less fails than days in the week.
Ozzie_osman 4y ago
One item folks may have glossed over is the DRI model. This is such a simple but transformative concept. I'd say the biggest benefit is speed of decision-making and execution, but it also increases quality of output and decreases centralization/top-down decisions. Gitlab, apple, and many other companies employ this model. I'm not surprised Stripe does too.
- candiddevmike 4y ago
  It's the roman dictator model applied within a business. I think the outcome is 100% dependent on the quality of dictator, much like anywhere else it is used. Personally, I think autonomous teams may be slower but tend to make better decisions/create better results over the long term when compared to a sampling of DRIs.
  - blululu 4y ago
    Not really. There are many DRI s at a variety of levels. Authority is distributed and non hierarchical. As the DRI you are responsible for one thing but it comes with no real authority beyond that. The main point of a DRI is that authority is clearly defined. The key advantage of this model is there is broad clarity on who that person is at any time.
    - emptysea 4y ago
      Yeah it ends up being a point of contact more than anything It’s still the PMs, Eng managers, and higher ups making most of the decisions* *At least at my current company
sleepybrett 4y ago
anyone a little disturbed by the 'open data warehouse'? Glad I'm not a customer of stripe.
- deleted 4y ago
  [deleted]
- zsteinkamp 4y ago
  I should have chosen my words better in the post. Of course, access is restricted to people whose jobs relate to the data (i.e. developers), and the data that is accessible is also controlled. The point I was trying to make was that there is a difference from other organizations where I've worked, where access to relevant product data in the warehouse is given by default to dev teams, and is accessible both interactively (for debugging or decision making) and from batch/cron jobs.
bigger_inside 4y ago
"If a private DM conversation started to go in that direction [i.e, not positive, not supportive/b_i], someone would speak up to take the conversation to a public channel, and things returned to a more constructive tone." This seems utterly unacceptable to me. Firstly, taking private things public is a breach of trust. There was a reason this wasn't public. Secondly, this seems massively counterproductive. I can't find the story here anymore, from a few weeks ago, where the guy who worked at a laser factory tried to tell people that their laser aim wasn't stable, and the company only fixed it after the customers complained - because the colleagues were aghast at such a "non-positive" attitude from the new guy. Also, I'm German, where all this US "be nice and smile all the time" thing seems at best naive, but also a form of torture and company overreach to try to emotion control employees into this drugged up alice in wonderland facade. "Crowdsourcing" company culture emotion control to a system of shaming and doxxing only makes this worse, as it removes the central point of responsibility for it and allows the company culture control to hide behind the employees for it. This is vile.
- noirbot 4y ago
  I think the question is how critical you can be in public channels. Your example (of being critical of a product) feels like something I'd be comfortable saying in most public channels at my company. What I would assume is more what they're talking about at Stripe is situations where 2 employees are complaining together about another team or coworker. There's more positive or constructive ways to raise that complaint, and I can see the value in not just having a toxic cycle where people are venting about other people in private with no actual action about it ever occurring. Constructive doesn't have to mean you're some drugged up worker drone that's ignoring security faults in a product, it just means actually trying to work out what to do about the issues you're seeing.
  - shubhamjain 4y ago
    Most people are afraid to say anything in public channels because they fear they might alone in feeling a certain way (often times they are not). It's through private conversations, they can feel confident about their view and actually do something about it. This "everything must be public" perpetuates the culture of a seemingly happy place simmering with unsaid complaints below the surface.
ketchupdebugger 4y ago
> The downside is that this is an exceptionally active repo. Hundreds of pull requests are merged each day, so any branch that you’re working on for more than a couple of days faces a large risk of merge conflicts or worse. This is only true if the branch touches things that other engineers are actively working on. Which shouldn't really happen since each team owns specific folders. If it does happen it means that the branch can be broken down to smaller deployable PRs. > If there is an issue with a single deploy, it stops the whole company from shipping changes. Unless the deploy is a giant monolith or the issue occurs in shared library/infra code, this shouldn't prevent shipping changes. If you are deploying microservices, if a single microservice have an issue, you can still deploy the other microservices since they can be deployed independently. (Unless of course the issue is with shared library or infrastructure code then it would affect all microservices that uses those library/code)
- clintonb 4y ago
  Services are deployed from a monorepo. Deploys are only allowed for main branch commits that have passed CI. If the main branch is broken, nothing can be deployed beyond the last successful commit.
dustedcodes 4y ago
> So many companies hire solely on technical aptitude, then design the role of the engineer as an implementer of others’ ideas. Stripe (and specifically the Atlas team) biases hiring much more strongly on aspirations, track record, taste, and potential. The team is filled with enthusiastic, energetic, fantastic communicators who are motivated to deliver ideal user experiences. In the right environment, people with these skills are able to produce a better product and build a better team culture than a dull, code-focused, command-and-control kind of environment. I really really hate this idea that the most important skill about an engineer is being a good communicator. I know why people say that, but honestly, being a good communicator is the _last_ thing that makes a good engineer. The best software engineers are good at - I know this comes by a huge surprise - writing code. It's strange, but people who's job is to mainly write code also should be mainly good at writing code. In fact, people who are good at communicating tend to turn everything into discussions, debates, meetings and do very little actual work. Software developers don't need to be good communicators. They stare at a screen and need to be good at being content by solving problems by writing code. If they get happiness from that and they are fast learners then they will be good developers. Managers need to be good communicators. Team leaders who need to explain concepts to juniors or discuss architecture with others need to be good communicators, but not your regular junior/mid/senior developers. If a software engineer is a good communicator they will quickly be put into a role which will make them something that is not a software engineer anymore, so it's arguably a skill that is important for other roles and not coding. EDIT: Lots of people here trying to berate me on effectively what boils down to being a normal person and describing it as a "good communicator". Sure I agree with that, you have to have some basic humans skills, being able to read things, understand basic shit and being able to speak to other people like every other normal person who functions in society. I personally don't call that a "good" communicator. Just a person. Just like I don't automatically assume that if someone is not a good/great communicator that they automatically are poor communicators. By the same measure that everyone berates me here we are all good athletes if we can run 10 metres or kick a ball down the hill. Personally I set the bar slightly higher than just being normal when I describe as something to be good or great but perhaps that is just me.
- tootie 4y ago
  Nah, the article is right. I see a lot of really smart devs who just write great code that nobody wants. They just disappear and go quiet for a week and then deliver some solution that was not specified by the product team because they think it's better. I've had to tell really smart engineers to straight up delete code they wrote because it's not what we want to show to users. Some of the best EQ/communicative developers are the ones that work collaboratively and frequently come up with trivial solutions by asking the right questions. Really, the best orgs have a mix of both or, ideally, individuals who can do both.
tootie 4y ago
My team has a slack bot for giving positive encouragement very similar to what he describes. Can confirm that it's nice, but does zero for retention.
- JohnFen 4y ago
  Do you find that reduces how meaningful those comments are? I'm thinking that it might make it like gifts given on "mandatory gift events" vs gifts given just because someone thought of you. The former is nice, but much less meaningful than the latter. I've never worked at a company that required this sort of thing, so I'm just trying to wrap my head around it. It seems odd to me.
  - tootie 4y ago
    It's not mandatory. It's encouraged. And most people don't need to have their arm twisted to show a little appreciation.
    - JohnFen 4y ago
      By "mandatory", I mean "socially expected". > most people don't need to have their arm twisted to show a little appreciation. Absolutely. This was the point I was trying to make -- someone expressing appreciation because they felt moved to do so means a whole lot more than someone expressing appreciation because there is a social expectation that they do so.
      - tootie 4y ago
        It's anonymous. We don't even know who's posting or who isn't.
umaar 4y ago
I remember using Splunk (where the author used to work) at a previous job. In the spirit of sharing What I learned at X, here's What I learned at Shazam: Part 1: https://umaar.com/blog/lessons-learned-from-working-at-shazam-part-1/ https://umaar.com/blog/lessons-learned-from-working-at-shaza... Part 2: https://umaar.com/blog/lessons-learned-from-working-at-shazam-part-2/ https://umaar.com/blog/lessons-learned-from-working-at-shaza...
- zsteinkamp 4y ago
  Great posts! More engineers should read and write such things :)
  - umaar 4y ago
    Thank you!
specialist 4y ago
Good writeup. Stripe (Atlas) sounds like a high(er) functioning organization. A project in the Atlas team was considered done when a Shipped email was sent. ... It’s not uncommon for a project to begin with writing (but not sending!) the Shipped email, serving as a north star for understanding the scope and goals of a project. This is The Correct Answer™. Front load as much as possible. Transmute product releases from fire drills to just another boring day at the office. Back in the day, my team's first (draft) deliverables, in rough order, would be press release, release notes, demo, installer, misc docs, .ISO image. The press release and release notes would be socialized to all stakeholders at project kickoff. Early feedback, expectation setting. The (scripted) demo would become "more live" as features were implemented (merged). Our docs were part of the build process. eg Automatic screen shots. As the UI firmed up, the manuals, training material, etc. were always current (ready to ship). Direct user feedback Again, The Correct Answer™. I've only experienced problems when "business analysts" fully mediate between customers and teams. Something always gets lost in translation. aka Game of Telephone. Additionally, everyone on my teams would rotate thru every other role, over time. So (most) anyone could build the product, run meetings, do a demo, answer tech questions, etc. This started as a way to bridge the gulf between developers and tech supp/QA/test. But it evolved into something fun, cross training, and career building. Like having a marketing person run the Go-NoGo meetings for a release, or a tech supp person running a release's post mortem. Empowered everyone, built trust, created high emotional engagement, greatly reduced drama. Compared to our other product teams/groups.
- computing 4y ago
  this is very interesting, thanks for sharing!
- zsteinkamp 4y ago
  I'm happy to hear this isn't a new thing! I just wish more people/companies would embrace the practice. Once you've experienced it, it just feels like common sense. :)
elevenoh 4y ago
[dead]
iLoveOncall 4y ago
> Stripe is the fist place I’ve worked where the data warehouse is open to everyone to query and extract information. It’s quite common for batch or cron jobs to execute a warehouse query to extract their working set of data. This is something extremely scary when we know the data that Stripe deals with, not something I would classify as a positive.
- zsteinkamp 4y ago
  Sorry if I wasn't super clear in the post. There are still controls over visibility of data, and data access is very tightly logged and audited. This is data the team needs to do an excellent job for the customer. The difference from other companies where I've worked is that in other places the dev team would have to create their own mini-warehouse, or suffer through months-long project management flows to get on the data team's roadmap.
ed25519FUUU 4y ago
> Hiring for growth, diversity, and EQ … Stripe (and specifically the Atlas team) biases hiring much more strongly on aspirations, track record, taste, and potential. Really cool that Stripe considers something other than gender or race when hiring for diversity. Every tech company I’ve worked for has a very specific definition of diversity and it was considered and weighed even before the interview.
- billllll 4y ago
  You're statement sounds like co-opting the term "diversity" to mean something else, then patting yourself on the back that you reached "diversity." I really don't see what is being achieved here.
  - ed25519FUUU 4y ago
    Here's[1] Google's annual diversity report. What's in the report generally aligns with my understanding of diversity and inclusion, none of which is mentioned by Stripe. Is your definition something other than what's in this report? 1. https://static.googleusercontent.com/media/about.google/en//belonging/diversity-annual-report/2022/static/pdfs/google_2022_diversity_annual_report.pdf?cachebust=1093852 https://static.googleusercontent.com/media/about.google/en//...
- ravagat 4y ago
  Cool, right? What the author listed out is exactly the type of diversity that existed before the current adaptation. It's a better sign to see this in a company with high performance like Stripe.
- dumb_fool 4y ago
  I've seen this take a lot, but as NYC based black/male software engineer w/ 10+ yrs experience, I can count on one hand how many other black engineers I've ever worked with (engineering orgs from 30 - 250 pp). Where are all of these race based "diversity" hires working?
  - 4y ago
tempsy 4y ago
TBH Stripe sounds like an insufferable place to work.
steno132 4y ago
The author forgot the most important part. Everyone at Stripe is nice, we show gratitude, we value diversity, the founders sit at open desks and eat lunch with the employees but at the end of the day, it's all a thin facade. A thin facade masking the fact that Stripe is a company, like any other company is. For all the talk about wellness, the founders of the most valuable private company in the US brutally fired 10% of their workforce a couple weeks ago. The Collisons did not give up their equity, they did not take a pay cut, their executives did not take a pay cut, their executives were not laid off. People like patio11, Jeff Weinstein, the author vocally and repeatedly praise Stripe. But Stripe doesn't reciprocate their adulation. It doesn't feel the same way. They 're intelligent people, so this should be obvious, but I guess it's not. Stripe doesn't care about them at all outside of their ability to produce for Stripe. And if they stopped producing, sure, the Collisons would give them some grace period. But then they would fire them mercilessly (as they have already done).
- zsteinkamp 4y ago
  Hard disagree. Stripe the business decided to cut costs for whatever reasons. While I was shocked the morning of the layoffs, I don't think anyone could have been given a softer landing by the company. I don't think a business needs to be a charity, just as I don't donate my time to the company outside of a normal work week. It's business and I think they handled their business decision very well.
gorgoiler 4y ago
I wonder: in what files were the monorepo merge conflicts happening? For any language with explicit imports the typical hotspots are the top parts of large, shared files. Git can resolve all the mid file edits but needs a diaper change when it encounters conflicts in the header. For example: if two people edit stripe/utils/common.py to add def f(x) and def g(y) then you’re likely to encounter a merge conflict not in the function definitions, but in any new imports each function requires. The solution is to break this file up into many smaller modules. The same goes for any overly large bazel dependency, or common go file, etc.
- mcqueenjordan 4y ago
  The problem the author is describing is not really intrinsic to monorepos, and it’s probably a symptom of a specific problem that Stripe has in its implementation. As the saying goes, the only thing worse than a monorepo is two monorepos.
Jiger104 4y ago
Thanks for your post, I was also at Stripe in this same time frame and got laid off. Lots of great systems, people and processes I learned as you described.
- zsteinkamp 4y ago
  I hope you've found a suitable replacement job! LMK if I can help.
thenerdhead 4y ago
Stripe has always been a model of the ideal remote/async/build in public workflow many people on HN seem to desire(including myself). The culture seems to reflect with the systems created. Conway's law applies heavily here. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law
digianarchist 4y ago
I'd love to read more about Stripe's feature-flag system. I found a client [0] but I don't think they've open-sourced the backend. [0] - https://github.com/stripe/goforit https://github.com/stripe/goforit
ravagat 4y ago
Thanks for sharing. A good read. I liked what Stripe is doing, it's clearly effective. With the mention of the Atlas team, it's good to see resources going towards there. It's a great product and I'm a satisfied user and referrer.
- zsteinkamp 4y ago
  It's a truly phenomenal group of people who are building it too! :D

193 points by yarapavan 4y ago

AgentOrange1234 4y ago

The auto-collection of nice-job messages sounds completely awesome. I wish I had this for my team.

ageitgey 4y ago
We have that feature at our company through an employee review SaaS we use called Lattice. Our #praise channel works the same way and it has definitely been a nice surprise. It is really nice to be reminded of all the feedback at review time. Maybe other similar employee review systems have a Slack integration you can turn on - it sounds like maybe it is a common feature now.

tapanjk 4y ago

> This practice normalizes gratitude in the team, and sets a mild expectation for recognizing the people who helped you that week. Honest question if your team also does this. How do you differentiate real thanks from the thanks of the week? I ask because in my experience kudos at a regular interval works for a while when it is launched but stops being effective over time, in some cases producing the opposite of intended effect.

francis-io 4y ago
How are "real thanks" and "thanks of the week" different?
- tough 4y ago
  One feels sincere and not scripted and the other well is company policy?
  - nbaugh1 4y ago
    Company culture and company policy aren't the same thing
    - eweise 4y ago
      Then why does the Company usually have five to seven cultural values they plaster on the wall and form the basis of employee reviews? Feels like Company policy to me.
- jon-wood 4y ago
  I've definitely experienced similar, mostly when thanks are rolled up above team level into large all-hands type meetings though. In those cases you'll get senior managers polling everyone to submit some thanks so that their team isn't under-represented in case it looks like they're not pulling their weight.
gary_0 4y ago
At first glance, I definitely like the ideas to encourage positivity and gratitude. But I had the same worries as you: if things go wrong these same ideas could get twisted into toxic popularity contests and "pieces of flair" mandatory fun. People could start comparing how many kudos each employee profile has, then start pushily soliciting them, and then "kudos inflation" happens... Maybe things Just Work so long as you avoid hiring jerks, and people feel secure enough in their jobs that they don't see the need to anxiously compete with their teammates. (Some company cultures definitely go the opposite direction, favoring cold-blooded ambition over prosocial cooperation.)
jt2190 4y ago
You can’t, so you assume that all thanks are “performative” (insincere). The action thus becomes indicative of adherence to group norms for the performer, so more of a culture-fit test for the person giving thanks. There could also be an in-group acknowledgement by being thanked if the performative culture gets really strong.
nahname 4y ago
Something like this only works if your leadership team believes in it. If they give and receive feedback through the same system, align incentives to keep it going. Then this kind of feedback will thrive.
xkjyeah 4y ago
/++ are spontaneous. Any time your colleague makes a great presentation, does you a favour, you /++ them. If there are regular weekly kudos, it'd be a team-specific thing. /++ were really common before a couple of years ago, but I get the vague feeling it's usage is declining. It used to report the accumulated number of pluses you got... So you could tell who have been the really helpful folks (or really tenured folks) out there, and for great contributions, you'd really want to chime in to a wave of ++s to show your appreciation. Without the numbers, usage seems to have declined a bit, since there isn't the satisfaction of seeing a colleague's karma go up by, say, 10pts after a great presentation. Still, it's a great culture tool, and something I'd want to spread at my next employer's if I leave the company.
- eweise 4y ago
  All these company games just seem like a way to get people to do more work. In addition to doing your regular work, you now have pressure to score really high cudo points on your presentation. Can't just throw together some bullet points. Will need to work the weekend coming up with some awesome graphics.
  - deleted 4y ago
    [deleted]
  - deelly 4y ago
    So, cynic inside me thinking this is just another metric to game in office games..
ericmcer 4y ago
Yeah I think this is a good idea but ignores that every piece of positive feedback is potentially negative feedback for someone else. We have all probably experienced working really hard on something that isn't very visible and receiving very little credit for. We have also probably experienced working on a flashy but relatively simple feature and getting lots of praise for it. It would be a good way to quantify small things like answering questions, giving good code reviews, etc. that can go unnoticed.

jack_riminton 4y ago

Really like the idea of Friction logs, it's so easy to become blind to things that don't make much sense

zsteinkamp 4y ago
Try it today :)
emptysea 4y ago
Friction logs are all well and good but only if you have the time to action on them At a past company we had a new lead designer come in and write a huge friction log but nothing happened because we’re already busy with tons of other higher priority stuff

likeabbas 4y ago

I learned there that if you build a successful startup on Ruby, your infrastructure costs are going to be insanely high trying to make it scale and you'd be better off using a typed language with true multithreading and a solid GC.

faitswulff 4y ago
You could learn the opposite lesson as well, that if you want to create a successful startup you need a dynamic language that responds to business needs and you can put off worrying about infrastructure costs until later.
- likeabbas 4y ago
  Your argument is based on a fallacy that you can build something faster in a dynamic language than a typed one. IMO that argument fails when you need to onboard new people to read the codebase and contribute to it. I'd argue you will be able to onboard people faster to a typed codebase than a dynamic one. And for me personally, I don't see a difference in my ability to produce code between Java/Go and a dynamically typed language.
  - faitswulff 4y ago
    That's not my argument. My argument is that without more data, your original statement that "you'd be better off" is just as subjective. In fact, with data, we see rather the opposite picture: > Y Combinator, an accomplished investment fund, and startup incubator has published a list of its top 100 graduate companies ranked by valuation as of October 2019. 8 out of the 10 most valued companies in the ranking were built using Ruby on Rails. https://spreecommerce.org/ruby-on-rails-most-popular-among-top-y-combinator-companies/ https://spreecommerce.org/ruby-on-rails-most-popular-among-t... I'm not entirely convinced, but my main point is that polemic based on individual experiences is wholly subjective.
    - likeabbas 4y ago
      No it's not. You would objectively be better off in Java or Go than Ruby once you reach scale. Java and Go can truly utilize multi-core threading, and have superior garbage collectors. This matters a lot for latency requirements

rtpg 4y ago

the gratitude thing is kinda fun. I imagine that managers treat that as a "positive only" indicator (lack of gratitude markers should not be counted as a negative, but a lot of them should be counted as a positive), since it's dependent on coworkers who do that kind of thing. In a previous job I would always offer "e-bux" for fixes. I was half tempted to write a quick backend to track these e-bux, but gamifying that sort of stuff has its own consequences as well... > If there is an issue with a single deploy, it stops the whole company from shipping changes. This definitely feels odd to me. Monorepo shouldn't mean mono-artifact! Perhaps this is more theoretical/one point, but if Stripe engineers feel this and this person felt this after less than a year... Bazel is nice y'all. (EDIT: I'm being too harsh here, CD in particular probably makes the calculus on rollouts very tricky)

cicdmonorepo 4y ago
> If there is an issue with a single deploy, it stops the whole company from shipping changes. I don't agree with this characterization. There is a way to 'lock' an entire repo from deploys, but it's not very frequently used. Single-service deploy blocks are common (if an autodeploy fails, or a team is aware of an issue and actively fixing it). Stripe uses Bazel heavily. > there was a project well underway to pull some core product / business functions into specific repos This quote from the post is also not true to my knowledge: new repos are not allowed and teams are actively working to migrate small repos into the monorepo(s).
- rtpg 4y ago
  Thanks for the feedback, and very glad to hear that there's a distinction going on between merging and deploying.
ketchupdebugger 4y ago
> the gratitude thing is kinda fun. I imagine that managers treat that as a "positive only" indicator (lack of gratitude markers should not be counted as a negative, but a lot of them should be counted as a positive), since it's dependent on coworkers who do that kind of thing. Depending on how it's done. I've seen similar systems where it became an additional metric to measure an engineer. Engineers became upset if they helped a coworker but did not receive any gratitude. (not receiving gratitude means that the help is not documented, so the helping engineer can't claim it during perf reviews)

ctvo 4y ago

> Caught up in Stripe’s Nov 2022 layoffs, which primarily affected new hires like me. Both in the author's resume and in the article they felt the need to clarify that Stripe layoffs hit new hires primarily (... it wasn't due to their own performance). Is this true? ~6 people I know who were hired in 2021 and 2022 are still there.

likeabbas 4y ago
The majority of people laid off were hired in 2021 (including myself), and then 2022. There was a graph posted to Blind before we lost access
- atomicnumber3 4y ago
  82% of the company was hired after March 2020, and the average tenure of a software engineer is what, 3 years?
- metadat 4y ago
  How did you lose access to Blind? I thought once you are logged in once you pretty much stay authenticated on the device.
  - Keats 4y ago
    Companies can require a force re-auth on blind so laid off don't have access to it anymore.
    - metadat 4y ago
      Gross, it was better when companies had no control over blind. This way doesn't feel safe or anonymous, what's stopping Blind from cooperating with companies on other efforts? Thanks for the heads up.
    - nsenifty 4y ago
      Is this documented somewhere? As a data point, just a day after my last day at $FAANG, my blind required re-auth. I still have access to my older mid-size company blind via a separate account since 2019. Just wondering what other services Blind now offers to employers.

nvarsj 4y ago

VSCode on remote VMs is a really great DX. Preconfigured / managed environment with good links to local infra means anyone can work fully remote from any kind of device. And it makes setup time very short regardless of the project complexity. I suppose the main issue with this kind of approach is cost - a powerful enough AWS instance is really expensive. But you can get beefy dedicated servers from Hetzner for 100/mo that might be a good option for smaller shops.

joshribakoff 4y ago
Disagree, if you need to connect to a network to run the project locally your DX is the worst of the worst. You should be able to run the project locally with docker containers if not on the host machine, the only caveat is if you work at a company like Google where you’d need to spinup thousands of services, but even then you should be able to run the service youre working on locally, at least with unit tests or in isolation, your DX indeed is bad if not. If you cant even use your editor locally thats super cumbersome
- clintonb 4y ago
  We can use editors locally. I’ve used RubyMine for my entire tenure. I find devboxes hold a few advantages over running Docker locally: 1. We can have multiple devboxes to aid switching between branches. 2. Services are more easily spun up and down as needed. If I’m only working on the API, I don’t have to waste local resources on the frontend. 3. Devboxes replicate more of the service networking (Consul) to aid debugging (versus using container networking).
- zamnos 4y ago
  The problem with local dev, across a large developer org, is that it is local to each developer's machine. Which means that if there's some problem with it, that each developer has to spend time fixing it, or eventually end up going to IT or other devs and ask for help. And devs hate asking for help. The benefit of remote dev, along with standardizing on an editor, is that the company and IT department can say "here is a thing that works, use this one", instead of debugging weird issues on individual developer laptops. If you're IT and someone comes to you and says their mouse doesn't work, do you break out the screwdriver and open it up to try and fix their mouse, or do you just give them a new one that you know works, so they can get back to work while you look into the problem later. Local dev is great when you're at a small company and just starting out, no support, but once you're a software dev working alongside other software devs, most of whom are smarter than you, and then there's a whole other team of devs dedicated to your experience as a developer; local dev feels like a little folksy hometown sort of endeavor. Don't get me wrong, local dev has its place, and some things like writing firmware will always want that, but the industry's moving past it for big picture reasons.

shubhamjain 4y ago

I am glad author found the time at Stripe to be a great experience, but the points mentioned may not be rosy to everyone. This is not to say Stripe is a bad company, but what works for you, might not for everyone. > Keeping team channels public helps to keep everyone on the straight and narrow in avoiding badmouthing other people or teams in the company. Shit-talking was culturally unacceptable in the team. If a private DM conversation started to go in that direction, someone would speak up to take the conversation to a public channel, and things returned to a more constructive tone. The intention isn't bad here, but if it isn't said on Slack, it will mostly be left unsaid or will be said in closely knit groups. It's not always possible to be critical of someone on a public channel. The culture of everything must be public can easily result in perpetuating bad hires. Of course, no reason to worry if everyone is 10/10 employee, but this isn't always the case. I mean, are you suggesting that there were no mumblings of mismanagement after Stripe laid off 10% of workforce? > The Atlas team does track date estimations, but those dates are always accompanied with a confidence level in that date. It is understood and embraced that these numbers will change over time, and changes are always communicated clearly in writing, and sometimes discussed in weekly “Ships Review” meetings. This just becomes another field that employees have to fill, without adding any real value. Software development is simply a messy process. How can I estimate my chances of reaching the due date? It all depends on unexpected roadblocks, and the problem being more complicated that I initially estimated. > The Atlas team also reinforces this in their Friday wrap-up meetings in a segment called “Mad Props”. The /++ feedback is collected by the meeting DRI (see below) into a meeting doc, and others from the team can add their own kudos and mad props to that section. The person doing the thanking reads or mentions their items for the team to hear in the meeting. Again this isn't problematic, but a mechanism for gratitude isn't unique to Stripe either. In fact, I have only few companies where it wasn't there. The problem is that it quickly becomes where everyone is thanking everyone. And maybe even thanking for not the right reasons. Let's say Employee A thinks that creating lots of UML diagrams is a good quality and they thank Employee B for working that way. But I simply think it's a waste of time. Since you publicly thanked someone for that, it'll make everyone believe that's the ideal way to work. It's possible that I might be wrong, but public gratitude unintentionally signals what is valued at the company, which may or may not be in best interests of it.

hiidrew 4y ago

The direct user feedback sessions seem valuable. We do a lot of user research but often the findings only interest specific teams or individuals. The openness would be interesting to experiment with, same with the Twitter search bot. The friction logs also seem beneficial from a UX lens. Almost like a light version of a heuristic evaluation.

zsteinkamp 4y ago
Take the lead on starting it in your team :) Just invite a user to a Zoom call and ask them some questions.

pramodbiligiri 4y ago

Regarding "Dates have a % confidence", has anyone else used this system in practice? How has that worked out? Do current project management tools allow you to put a confidence interval next to estimates?

jabart 4y ago
I've used this phrasing in large consulting projects and it tends to help in the communication. It's all a made up number to just let someone know how the team is feeling about a date and if things are in trouble early enough. Business owners tend to understand it well compared to "the deadline looks tight".
JohnFen 4y ago
I always put on confidence level on projected dates (and that confidence level is never "100%"), both formally with my own companies and informally when working with others. I think it's incredibly useful for a number of reasons, but the primary benefit is in managing expectations. For instance, just today I was asked when I could finish a task. I answered "I'm 80% confident I can deliver in two days". If I leave my confidence measurement off of that and just say "two days", it could lead others to make inflexible schedules and a delay could derail things. Giving a confidence level gives them an additional bit of information that can be very useful. Sometimes, I've said something like "80% chance of 2 days", and the response was "what would it take to make that 90% (or whatever)." That's also very valuable, because then we can have a realistic discussion about tradeoffs/prioritization in scope or quality to gain more certain scheduling.
grrdotcloud 4y ago
Love it. Use it in many previously manager roles and personal projects. How I currently work on each Sprint. Anytime I'm tasked I make sure I understand exactly what's expected and when it's due. I get it in writing until we've established trust. Then I deliver. I'll agree to work that I know, barring any unforeseen circumstances, I can accomplish in two weeks. Thirty hours. Ninety hours? Whatever it takes to complete the work. I would ask people that were agreeing to work, that if they were comfortable quitting their job or refunding me all the contract money if they failed. Sometimes they would say yes, other times no, other times they would look at me with bewilderment. I would ask them only to take on work that they knew they could complete. Sometimes they would adjust the estimate, and I would thank them for it. Everyone wins when people hold their word. There have been times when I have had management, very upset, demanding to know why I did not complete a task. I asked them if I ever agreed to it? They would say no. And I would say then, why would you expect me to complete it? While I do not ask for a percentage completion, I look for a binary response. We can adjust the scope, we can adjust the timeline. We cannot adjust the completion status after the deadline has elapsed. I have agreed to work not knowing how to do it, only with the confidence that I knew I could get it done, or subcontracted out at zero gain. As for project management tools to capture this, no. I did develop my own team tracking methods. We had a internal facing fail board. If you failed, you made a public note. This was encouraged. We fail, we learn, we do not lie. Others would ask, how did you fail? We would tell a story and we would all learn. The goal was to have less fails than days in the week.

Ozzie_osman 4y ago

One item folks may have glossed over is the DRI model. This is such a simple but transformative concept. I'd say the biggest benefit is speed of decision-making and execution, but it also increases quality of output and decreases centralization/top-down decisions. Gitlab, apple, and many other companies employ this model. I'm not surprised Stripe does too.

candiddevmike 4y ago
It's the roman dictator model applied within a business. I think the outcome is 100% dependent on the quality of dictator, much like anywhere else it is used. Personally, I think autonomous teams may be slower but tend to make better decisions/create better results over the long term when compared to a sampling of DRIs.
- blululu 4y ago
  Not really. There are many DRI s at a variety of levels. Authority is distributed and non hierarchical. As the DRI you are responsible for one thing but it comes with no real authority beyond that. The main point of a DRI is that authority is clearly defined. The key advantage of this model is there is broad clarity on who that person is at any time.
  - emptysea 4y ago
    Yeah it ends up being a point of contact more than anything It’s still the PMs, Eng managers, and higher ups making most of the decisions* *At least at my current company

sleepybrett 4y ago

anyone a little disturbed by the 'open data warehouse'? Glad I'm not a customer of stripe.

deleted 4y ago
[deleted]
zsteinkamp 4y ago
I should have chosen my words better in the post. Of course, access is restricted to people whose jobs relate to the data (i.e. developers), and the data that is accessible is also controlled. The point I was trying to make was that there is a difference from other organizations where I've worked, where access to relevant product data in the warehouse is given by default to dev teams, and is accessible both interactively (for debugging or decision making) and from batch/cron jobs.

bigger_inside 4y ago

"If a private DM conversation started to go in that direction [i.e, not positive, not supportive/b_i], someone would speak up to take the conversation to a public channel, and things returned to a more constructive tone." This seems utterly unacceptable to me. Firstly, taking private things public is a breach of trust. There was a reason this wasn't public. Secondly, this seems massively counterproductive. I can't find the story here anymore, from a few weeks ago, where the guy who worked at a laser factory tried to tell people that their laser aim wasn't stable, and the company only fixed it after the customers complained - because the colleagues were aghast at such a "non-positive" attitude from the new guy. Also, I'm German, where all this US "be nice and smile all the time" thing seems at best naive, but also a form of torture and company overreach to try to emotion control employees into this drugged up alice in wonderland facade. "Crowdsourcing" company culture emotion control to a system of shaming and doxxing only makes this worse, as it removes the central point of responsibility for it and allows the company culture control to hide behind the employees for it. This is vile.

noirbot 4y ago
I think the question is how critical you can be in public channels. Your example (of being critical of a product) feels like something I'd be comfortable saying in most public channels at my company. What I would assume is more what they're talking about at Stripe is situations where 2 employees are complaining together about another team or coworker. There's more positive or constructive ways to raise that complaint, and I can see the value in not just having a toxic cycle where people are venting about other people in private with no actual action about it ever occurring. Constructive doesn't have to mean you're some drugged up worker drone that's ignoring security faults in a product, it just means actually trying to work out what to do about the issues you're seeing.
- shubhamjain 4y ago
  Most people are afraid to say anything in public channels because they fear they might alone in feeling a certain way (often times they are not). It's through private conversations, they can feel confident about their view and actually do something about it. This "everything must be public" perpetuates the culture of a seemingly happy place simmering with unsaid complaints below the surface.

ketchupdebugger 4y ago

> The downside is that this is an exceptionally active repo. Hundreds of pull requests are merged each day, so any branch that you’re working on for more than a couple of days faces a large risk of merge conflicts or worse. This is only true if the branch touches things that other engineers are actively working on. Which shouldn't really happen since each team owns specific folders. If it does happen it means that the branch can be broken down to smaller deployable PRs. > If there is an issue with a single deploy, it stops the whole company from shipping changes. Unless the deploy is a giant monolith or the issue occurs in shared library/infra code, this shouldn't prevent shipping changes. If you are deploying microservices, if a single microservice have an issue, you can still deploy the other microservices since they can be deployed independently. (Unless of course the issue is with shared library or infrastructure code then it would affect all microservices that uses those library/code)

clintonb 4y ago
Services are deployed from a monorepo. Deploys are only allowed for main branch commits that have passed CI. If the main branch is broken, nothing can be deployed beyond the last successful commit.

dustedcodes 4y ago

> So many companies hire solely on technical aptitude, then design the role of the engineer as an implementer of others’ ideas. Stripe (and specifically the Atlas team) biases hiring much more strongly on aspirations, track record, taste, and potential. The team is filled with enthusiastic, energetic, fantastic communicators who are motivated to deliver ideal user experiences. In the right environment, people with these skills are able to produce a better product and build a better team culture than a dull, code-focused, command-and-control kind of environment. I really really hate this idea that the most important skill about an engineer is being a good communicator. I know why people say that, but honestly, being a good communicator is the _last_ thing that makes a good engineer. The best software engineers are good at - I know this comes by a huge surprise - writing code. It's strange, but people who's job is to mainly write code also should be mainly good at writing code. In fact, people who are good at communicating tend to turn everything into discussions, debates, meetings and do very little actual work. Software developers don't need to be good communicators. They stare at a screen and need to be good at being content by solving problems by writing code. If they get happiness from that and they are fast learners then they will be good developers. Managers need to be good communicators. Team leaders who need to explain concepts to juniors or discuss architecture with others need to be good communicators, but not your regular junior/mid/senior developers. If a software engineer is a good communicator they will quickly be put into a role which will make them something that is not a software engineer anymore, so it's arguably a skill that is important for other roles and not coding. EDIT: Lots of people here trying to berate me on effectively what boils down to being a normal person and describing it as a "good communicator". Sure I agree with that, you have to have some basic humans skills, being able to read things, understand basic shit and being able to speak to other people like every other normal person who functions in society. I personally don't call that a "good" communicator. Just a person. Just like I don't automatically assume that if someone is not a good/great communicator that they automatically are poor communicators. By the same measure that everyone berates me here we are all good athletes if we can run 10 metres or kick a ball down the hill. Personally I set the bar slightly higher than just being normal when I describe as something to be good or great but perhaps that is just me.

tootie 4y ago
Nah, the article is right. I see a lot of really smart devs who just write great code that nobody wants. They just disappear and go quiet for a week and then deliver some solution that was not specified by the product team because they think it's better. I've had to tell really smart engineers to straight up delete code they wrote because it's not what we want to show to users. Some of the best EQ/communicative developers are the ones that work collaboratively and frequently come up with trivial solutions by asking the right questions. Really, the best orgs have a mix of both or, ideally, individuals who can do both.

tootie 4y ago

My team has a slack bot for giving positive encouragement very similar to what he describes. Can confirm that it's nice, but does zero for retention.

JohnFen 4y ago
Do you find that reduces how meaningful those comments are? I'm thinking that it might make it like gifts given on "mandatory gift events" vs gifts given just because someone thought of you. The former is nice, but much less meaningful than the latter. I've never worked at a company that required this sort of thing, so I'm just trying to wrap my head around it. It seems odd to me.
- tootie 4y ago
  It's not mandatory. It's encouraged. And most people don't need to have their arm twisted to show a little appreciation.
  - JohnFen 4y ago
    By "mandatory", I mean "socially expected". > most people don't need to have their arm twisted to show a little appreciation. Absolutely. This was the point I was trying to make -- someone expressing appreciation because they felt moved to do so means a whole lot more than someone expressing appreciation because there is a social expectation that they do so.
    - tootie 4y ago
      It's anonymous. We don't even know who's posting or who isn't.

umaar 4y ago

I remember using Splunk (where the author used to work) at a previous job. In the spirit of sharing What I learned at X, here's What I learned at Shazam: Part 1: https://umaar.com/blog/lessons-learned-from-working-at-shazam-part-1/ https://umaar.com/blog/lessons-learned-from-working-at-shaza... Part 2: https://umaar.com/blog/lessons-learned-from-working-at-shazam-part-2/ https://umaar.com/blog/lessons-learned-from-working-at-shaza...

zsteinkamp 4y ago
Great posts! More engineers should read and write such things :)
- umaar 4y ago
  Thank you!

specialist 4y ago

Good writeup. Stripe (Atlas) sounds like a high(er) functioning organization. A project in the Atlas team was considered done when a Shipped email was sent. ... It’s not uncommon for a project to begin with writing (but not sending!) the Shipped email, serving as a north star for understanding the scope and goals of a project. This is The Correct Answer™. Front load as much as possible. Transmute product releases from fire drills to just another boring day at the office. Back in the day, my team's first (draft) deliverables, in rough order, would be press release, release notes, demo, installer, misc docs, .ISO image. The press release and release notes would be socialized to all stakeholders at project kickoff. Early feedback, expectation setting. The (scripted) demo would become "more live" as features were implemented (merged). Our docs were part of the build process. eg Automatic screen shots. As the UI firmed up, the manuals, training material, etc. were always current (ready to ship). Direct user feedback Again, The Correct Answer™. I've only experienced problems when "business analysts" fully mediate between customers and teams. Something always gets lost in translation. aka Game of Telephone. Additionally, everyone on my teams would rotate thru every other role, over time. So (most) anyone could build the product, run meetings, do a demo, answer tech questions, etc. This started as a way to bridge the gulf between developers and tech supp/QA/test. But it evolved into something fun, cross training, and career building. Like having a marketing person run the Go-NoGo meetings for a release, or a tech supp person running a release's post mortem. Empowered everyone, built trust, created high emotional engagement, greatly reduced drama. Compared to our other product teams/groups.

computing 4y ago
this is very interesting, thanks for sharing!
zsteinkamp 4y ago
I'm happy to hear this isn't a new thing! I just wish more people/companies would embrace the practice. Once you've experienced it, it just feels like common sense. :)

elevenoh 4y ago

[dead]

iLoveOncall 4y ago

> Stripe is the fist place I’ve worked where the data warehouse is open to everyone to query and extract information. It’s quite common for batch or cron jobs to execute a warehouse query to extract their working set of data. This is something extremely scary when we know the data that Stripe deals with, not something I would classify as a positive.

zsteinkamp 4y ago
Sorry if I wasn't super clear in the post. There are still controls over visibility of data, and data access is very tightly logged and audited. This is data the team needs to do an excellent job for the customer. The difference from other companies where I've worked is that in other places the dev team would have to create their own mini-warehouse, or suffer through months-long project management flows to get on the data team's roadmap.

ed25519FUUU 4y ago

> Hiring for growth, diversity, and EQ … Stripe (and specifically the Atlas team) biases hiring much more strongly on aspirations, track record, taste, and potential. Really cool that Stripe considers something other than gender or race when hiring for diversity. Every tech company I’ve worked for has a very specific definition of diversity and it was considered and weighed even before the interview.

billllll 4y ago
You're statement sounds like co-opting the term "diversity" to mean something else, then patting yourself on the back that you reached "diversity." I really don't see what is being achieved here.
- ed25519FUUU 4y ago
  Here's[1] Google's annual diversity report. What's in the report generally aligns with my understanding of diversity and inclusion, none of which is mentioned by Stripe. Is your definition something other than what's in this report? 1. https://static.googleusercontent.com/media/about.google/en//belonging/diversity-annual-report/2022/static/pdfs/google_2022_diversity_annual_report.pdf?cachebust=1093852 https://static.googleusercontent.com/media/about.google/en//...
ravagat 4y ago
Cool, right? What the author listed out is exactly the type of diversity that existed before the current adaptation. It's a better sign to see this in a company with high performance like Stripe.
dumb_fool 4y ago
I've seen this take a lot, but as NYC based black/male software engineer w/ 10+ yrs experience, I can count on one hand how many other black engineers I've ever worked with (engineering orgs from 30 - 250 pp). Where are all of these race based "diversity" hires working?
- 4y ago

tempsy 4y ago

TBH Stripe sounds like an insufferable place to work.

steno132 4y ago

The author forgot the most important part. Everyone at Stripe is nice, we show gratitude, we value diversity, the founders sit at open desks and eat lunch with the employees but at the end of the day, it's all a thin facade. A thin facade masking the fact that Stripe is a company, like any other company is. For all the talk about wellness, the founders of the most valuable private company in the US brutally fired 10% of their workforce a couple weeks ago. The Collisons did not give up their equity, they did not take a pay cut, their executives did not take a pay cut, their executives were not laid off. People like patio11, Jeff Weinstein, the author vocally and repeatedly praise Stripe. But Stripe doesn't reciprocate their adulation. It doesn't feel the same way. They 're intelligent people, so this should be obvious, but I guess it's not. Stripe doesn't care about them at all outside of their ability to produce for Stripe. And if they stopped producing, sure, the Collisons would give them some grace period. But then they would fire them mercilessly (as they have already done).

zsteinkamp 4y ago
Hard disagree. Stripe the business decided to cut costs for whatever reasons. While I was shocked the morning of the layoffs, I don't think anyone could have been given a softer landing by the company. I don't think a business needs to be a charity, just as I don't donate my time to the company outside of a normal work week. It's business and I think they handled their business decision very well.

gorgoiler 4y ago

I wonder: in what files were the monorepo merge conflicts happening? For any language with explicit imports the typical hotspots are the top parts of large, shared files. Git can resolve all the mid file edits but needs a diaper change when it encounters conflicts in the header. For example: if two people edit stripe/utils/common.py to add def f(x) and def g(y) then you’re likely to encounter a merge conflict not in the function definitions, but in any new imports each function requires. The solution is to break this file up into many smaller modules. The same goes for any overly large bazel dependency, or common go file, etc.

mcqueenjordan 4y ago
The problem the author is describing is not really intrinsic to monorepos, and it’s probably a symptom of a specific problem that Stripe has in its implementation. As the saying goes, the only thing worse than a monorepo is two monorepos.

Jiger104 4y ago

Thanks for your post, I was also at Stripe in this same time frame and got laid off. Lots of great systems, people and processes I learned as you described.

zsteinkamp 4y ago
I hope you've found a suitable replacement job! LMK if I can help.

thenerdhead 4y ago

Stripe has always been a model of the ideal remote/async/build in public workflow many people on HN seem to desire(including myself). The culture seems to reflect with the systems created. Conway's law applies heavily here. https://en.wikipedia.org/wiki/Conway%27s_law https://en.wikipedia.org/wiki/Conway%27s_law

digianarchist 4y ago

I'd love to read more about Stripe's feature-flag system. I found a client [0] but I don't think they've open-sourced the backend. [0] - https://github.com/stripe/goforit https://github.com/stripe/goforit

ravagat 4y ago

Thanks for sharing. A good read. I liked what Stripe is doing, it's clearly effective. With the mention of the Atlas team, it's good to see resources going towards there. It's a great product and I'm a satisfied user and referrer.

zsteinkamp 4y ago
It's a truly phenomenal group of people who are building it too! :D