"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.
Earlier the author talked about Slack, so I take that to mean "public channel" or some other in-company "public." Then "private" in this context may also be a description of a feature of the conversation, not necessarily an expectation of privacy. If your company culture accepts that a private DM conversation may be pulled into a public conversation, there's no breach of trust.
To be charitable, "speak up to take the conversation" could actually mean "I propose we move this conversation to #public_channel."
Personally, I don't even consider it unhealthy. DMs are for convenience, work conversations are better off with more visibility.
Anything that is private is assumed to be private. Trust is a 2 way street. Could at least just ask the other party. Why does it have to be automatic? Whatever is the company culture it is respected for the person at the other end.
> Anything that is private is assumed to be private
Have you been involved in a deposition or a legal hold? If you're worried about your colleagues seeing your DMs, then perhaps ponder on the consequences of the same messages becoming part of the public record via the courts or regulatory body.
Nothing communicated in the execution of your duty is truly private: check the fine print in your organization's policies.
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.
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.
My first foray into big tech was met with a culture that disallowed any private discussion. If I had a question, take it public and see what people think. If I had a complaint, take it public.
It was terrible and I hated it. Sometimes I just want to talk with one person instead of the entire engineering org.
My next job I assumed they would be the same so I defaulted to never talking to anyone, which caused its own problems, as you can imagine.
I think I mostly agree with it, but I think having a culture that inclines towards trying to talk things out in public is probably better, but you're right about there being value in also being able to talk to your manager or your teammmate in private to share your thoughts or build consensus.
In general, I think it's one of those policies that can absolutely be toxic, but can also be healthy, and it's dependent on the surrounding culture and team and how absolute the policy is.
Things in the US up till about 10 years ago were much more like the German way of doing things.
The excessive positivity and no one being accountable for anything were conscious adaptations US management brought in around 2010 or so after there was so much press and academic pressure that everything had to be changed or millenials would refuse to work at any company that didn't change. It's possible the whole thing was a charade and that none of it was necessary to attract millenials or a more diverse/equitable employee mix.
Things in software are utterly unrecognizable compared to the 90s and early 2000s when people would yell at people for failures and there was far more accountability around failures and analysis of why things weren't working. It used to be a very "tell it like it is" culture. The way it is now there's pressure to sweep everything under the rug because of a fear that low performing employees will be offended.
Everything is hush hush and weird and the low performing employees are allowed to skate until they suddenly disappear.
The weirdness IME has even extended to where you're not allowed to talk about someone making a colossal mistake even if everyone knows who made the mistake due to a git blame or something. Not talking about it just leads to the mistake being made again and again till management makes the offender mysteriously disappear.
I'd somewhat suspect this trend in the US is probably not as prevalent in some sectors like maybe defense, though I have heard some crazy stories about useless employees being allowed to skate in that sector as well. Those are often huge companies where lots of this stuff happens.
A lot of Elon Musk's antics at twitter are basically just clumsy attempts to roll things back to the way they used to be. A lot of the excess of modern tech companies would have been unimaginable before the first .com boom. My early experiences were almost nothing was free in the office except coffee. When the team had a massive success there would be a big party, but other than that the company wasn't giving away all the free stuff all the time.
How does this solve problems more effectively, aside from making a few people feel bad?
> there was far more accountability
Do you have a source or any kind of metric for this, or is this based on gut feel?
> you're not allowed to talk about someone making a colossal mistake even if everyone knows who made the mistake
IME why are mistakes allowed to get through the codebase in the first place? The whole idea is that we should now have processes to catch and deal with these mistakes (code reviews, pull requests, automated tests, different environments). If your co-workers are cowboy coding and committing, then sure, have at them.
If the only lever you have to keep people from slacking off is "yell at them", you're a bad manager.
The free stuff in the office isn't meant just to coddle employees. At scale, perks are cheaper than higher comp. It becomes hard for smaller companies to compete on them. It also improves productivity. Free lunches mean people are back their desk within 30 minutes, instead of taking an hour to drive off-campus. If you have the profit margins to fund this stuff,
and a scarcity of talent, it's a no-brainer.
You must be speaking about some specific subset of the US. Very little of what you've said here describes anywhere I've worked, including in the last 10 years.
Look up the memo from the founder of Waze that he wrote to list all the reasons Google culture of babysitting people changed his employees in to nonproductive weaklings.
> 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.
In my experience, the required performative cheeriness is a feature of newer companies that have over-hired. I’ve worked with several US companies with established international presence where being direct and honest was the expectation.
I’ve also worked at smaller startups where toxic positivity was basically company policy. I’ve been reprimanded for my tone not being positive enough in a meeting where we were discussing a serious and urgent issue. I’ve had an employee who couldn’t handle even the slightest bit of feedback that wasn’t glowingly positive. These experiences were rare, though, and they were all associated with companies that had hired a lot of middle managers with vague directives who had little to do other than attend meetings and cheerlead. In each case it was a sign that the company valued perceptions more than reality, and it led to poor company performance.
Step outside of those companies, though, and it’s common for moderately high pressure environments with blunt, direct feedback. I’ve also had several outright abusive bosses who would disparage me personally, threaten firing at the slightest issue, and one CEO who even fired people on the spot if he was in a bad mood. The US doesn’t have a uniform work culture.
The first stage of this is almost always executives that get comfortable smiling while lying to your face in townhalls. Next is when people start talking about "culture" as if its a tangible, ownable thing. Once the dominoes start falling it's hard to stop them
Excessive enforced positivity goes hand in hand with easy firing. They're both indicative of companies where the management can't handle criticism, or are fundamentally scared that their success will crumble if anyone sees that the emperor is wearing no clothes.
My God, yeah. Preach. Also European here and this expectation in US companies that you describe, that you gotta be perpetually chirpy and upbeat, absolutely sets my teeth on edge. Being in that environment feels like experiencing sugar overdose all the time.
How I'd love for the default expectation to be just "get the job done," do it professionally, and that's it. Sachlich, to use a German term.
Problem is the constant push for more and more. They don't want to hire mediocre 'getting the job done' people. They want people who stay up until midnight working on some project that a partner mentioned at a dinner, just so that they are recognized for their effort 6 months later in a review.
While people like me try to do their job itself as best as possible, while maintaining a healthy work-life balance and don't get burned out.
"Private" vs "public" are just Slack settings, both refer to professional communication, not to a private chat between friends. People often start conversation in private chats to avoid producing noise for wider audience, not because they intend to be mean and fear repercussions.
How is it just a Slack setting? As in if you were to talk in the office and suddenly the other side shouts out loud so everyone on the same floor can hear it that's also just a setting?
People start private chats for whatever reason they like but they assume it's private. Until there is an agreement by both sides for it to be public it shouldn't. It shouldn't matter whether that's online (via Slack) or in person (via a private room).
As a European who moved to USA almost 8 years ago, the positivity still grinds on me. Yes it’s _pleasant_, even nice, but it isn’t kind. Give me a person who speaks their mind any day.
At least it’s kinda okay in engineering land. We have our wry jokes and witty remarks. But poke your head outside that bubble and the amount of verbal gymnastics you have to wade through just to figure out what someone was trying to say … urgh.
edit: This reminds me of when my sister came to visit and we went to a farmer’s market. Someone bumped into her and said ”Excuse me” and she later said ”Aw Americans are so nice!” … no dear, that means “get out of my way asshole”
Wow, that is... a very cynical way to view that interaction. Obviously you were there to hear how they said it, but I'll apologize if I bump into someone on accident and earnestly mean it.
What would you think is more honest? Someone bumps into you and cusses you out? Says nothing and ignores that the may have hurt you or caused you to drop something?
Oh no, this was a very San Francisco interaction. My sister was definitely in the way, had no idea what she was doing, and got an “cough excuse me” after not noticing the person awkwardly trying to get around her for the prerequisite 10 seconds.
And yeah in a crowded place with people having very little personal space? Just ignore it and move on. It’s not a big deal. Obviously there are levels of crowdedness, but somewhere between empty room and front row at a concert, you stop acknowledging small bumps.
Either way, I don’t think I’ve seen anyone use “excuse me” as an apology in SF. It’s more like the Minnesotan “ope” – said while you’re already shoving your way past someone purposefully. An apology sounds more like ”Shit, I’m sorry! Are you okay?”
So, in that case, what would have been the more "honest" way for that person to have gotten your sister to move? "Will you please move out of my way" is honest, but feels like it has just as much of an implied "You inconsiderate asshole" while taking far more words and time.
I'm mostly curious because I've been living with a variety of German travelers in the US for the last 10 years for reasons and have, if anything, found them to be overly polite to the point of annoyance relative to my American instincts.
I had a similar reaction when I moved to Canada when I was a kid.
It's just cultural norms. Inability to know what someone was trying to say is a feature, not a bug.
Sure, in engineering and science, it is a bug, but in everyday life, what a great feature. It forces people to translate vague-speak into my-worldview-speak, which helps bridge the culture/worldview gap. You can always drill down and double-check that you've interpreted correctly but communicating in vague-speak avoids so many sharp corners people tend to have - it's great stuff.
Can you imagine what hell places with lots of immigrants would be if all of them thought their culture was the way to go and looked down upon all that is unfamiliar and foreign?
> 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.
I believe you’re referring to this comment, from the discussion about normalisation of deviance:
I sometimes simplify social interactions by dividing them into two sets: friendly-social and engineering.
In friendly-social environments, it is all about avoiding overly negative topics. It is not lying, but just keeping the conversation track on things that are positive and interesting.
In engineering environments, logic is king. You need to be able to tell an engineer that their rocket designs will not fly and put ego's aside.
> Firstly, taking private things public is a breach of trust. There was a reason this wasn't public
There is no breach of trust if there is no expectation of privacy: we are at work, everything is logged and recorded[1] and you shouldn't be ashamed to stand by your work/words. Depositions, subpoenas, a lowly HR complaint or a curious IT drone can blow away the illusion privacy. As the saying goes: Don't write anything you dont want published in the New York Times
> Also, I'm German, where all this US "be nice and smile all the time" thing seems at best naive
Hard disagree: you don't have to smile - but you have to meet a baseline of professionalism. I had a non-American colleague who loved to criticize my work in public but requested that I send my critical feedback to him via 1:1 emails. His aggression only stopped when I continued to make all our conversations public - warts and all. Sunlight is the best disinfectant.
1. Go ahead and read your organizations electronic communications policy if you think I'm wrong.
Funny since in my experience, germans are usually a lot "faker" than americans. Like, by a huge margin. Americans are overly positive, but they aren't necessarily deceptive.
Ah this was the biggest learning for me too as I moved here. Didn't know it had a name. Passive aggressive behavior! I don't know if this is a big co thing. I felt in startups (I mean real ones - not the let us wait 15+ years without going Public with hundreds of employees) there is little time to be passive aggressive and you just speak your mind. Ofcourse the challenge here was how to be candid without being an ahole!
Agree. I would add that "Shit-talking" is necessary in any healthy organization. Employees needs a space in which they can talk openly with other peers (usually, their equals) about what they don't like at the organization. If you cannot have private DMs for that, well, employees will use other channels (e.g., Telegram).
Yeah, that really rubs me the wrong way in a "virtue police" sense. However, from a company PoV, it may be an exercise in Japanese values where you are taught to suppress your public persona to become more agreeable or else be the squeaky nail that gets hammered.
> 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)
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.
> 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.
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?
It's very clear the numbers do not support the idea that tech has "gone woke." Even the large orgs with strong DEI initiatives have a long way to go to achieve a diverse workplace.
I personally don't see the reason for fear mongering about diversity.
Assuming you're asking the question in good faith. As an example here[1] is Google's yearly diversity report. They've done a good job at hiring diverse candidates. Black+ (google's terminology) is up from 5.5% to 8.8% of hires, a 60% increase YoY from 2020 to 2021.
On the other hand, when I see "track record","taste","potential" I immediately get the feeling that there's plenty of room for elitism.
Taste is highly objective, and in the professional setting that's a huge pitfall for people being in the in- or outgroup.
Track record could go either way, but I have yet to see companies that for example value steep positive progress after a downturn. Whenever track record has been mentioned at other companies, they've expected it to be monotonically increasing aka "steady performers".
Potential is notoriously difficult to judge. Aspirations are easy to BS.
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.
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?
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.
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.
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.
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.
> 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.
/++ 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.
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.
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.)
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.
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.
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.
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.
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.
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.
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
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.
I guess it depends on what to prioritize. In a world of high speed internet, I prioritize fast onboarding time and common developer environments with minimal friction. But yes, it does add a network requirement. However VSCode remote dev works well even with a poor connection ime (coffee shop wifi).
I guess it's less important when working in mostly hermetic languages/runtimes like Java. But for things with native dependencies or lots of required tooling where local setup can be a large pain, it really does help a lot.
For the dev it becomes: Install VSCode, request VM, done.
I had a friend who was dealing with this exact issue of not being able to connect, even though he had perfectly good internet. Apparently the VPN wasn't working recently, for him specifically, and he literally could get nothing done. He talked to his boss to allow him to set up the dev environment locally. Personally I'd hate having to have an always online connection just to do my own work.
> 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.
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.
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.
Stripe has a large perf cut every year. Layoffs were mostly done by product areas / teams / orgs. I think layoffs being performance-based is true in some minority of cases but false overall.
Layoffs being perf based is a projection by engineers on how they think management and layoffs work, to which I say, there's a reason they're engineers and not managers.
I think he's saying your metrics don't fundamentally matter to the people who ingest them, and that thinking your metrics matter means you don't understand management's point of view.
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)
> 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)
> 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).
Plus-plus-bot does not impact reviews. It’s just a nice way to show gratitude publicly. Folks can use a feedback form to leave review-impacting feedback that is actually delivered to the manager.
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
> 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.
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.
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.
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. :)
> 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.
An ability to communicate is the bare minimum to be effective in almost all jobs. A team of mediocre anythings who communicate effectively will achieve more than a team of exceptional anythings who communicate poorly.
The way you’re characterising communication shows that you’ve been unfortunate enough to work in environments where volume of communication has been mistaken for a measure of quality. Good communication is characterised by the ability to share in the understanding of others, effective communication makes a group of people more than the sum of their parts. Effective communication leads to less communication.
I hope someday you’re fortunate enough to find yourself in a positive environment that is able to demonstrate all of this to you, because effective communication will improve your output more than any programming experience ever could.
> will achieve more than a team of exceptional anythings who communicate poorly
Not being a good communicator doesn't make you a poor communicator. My point is that you don't have to be a good communicator, I never said you can be a poor communicator. Just being normal, not poor or good at communication, but just being normally capable of speaking and good at coding is better than being a great communicator with average coding skills.
> [...] just being normally capable of speaking [...]
I think you may be confusing a medium (speaking) with communication itself. Successful communication is as much about the choice of medium as it is what you're communicating. Communication is the method through which we extract thoughts from our own brain and share them. Code is a form of communication! You can be a fantastic speaker and a terrible communicator, likewise you can be a terrible speaker and a fantastic communicator. The right environment for you is an environment in which you're able to choose to communicate in the medium that has the best outcomes.
For example, spoken communication is my weakest form of communication and yet it has not hindered me at all, in fact, I am considered an excellent communicator by the people I work with. Sometimes, you have[1] to use a method of communication that you're not confident with, so you can develop strategies to help you communicate more effectively in that situation. When I'm speaking, I take notes in advance to flesh out my thoughts, and if I find myself struggling during a conversation, I'm honest about it and recommend next steps -- e.g: "I'm not sure about that off the top of my head, so after this call I will put together some thoughts and get back to you by the end of the day".
The people you work with benefit most when you succeed :) You're clearly a very capable communicator based on your comments here, you don't need to argue against the fundamental importance of communication, rather, you need to find an environment where you're encourage and rewarded for embracing the communication methods that work best for you.
I couldn't have spoken this comment out loud and that has zero impact on my communication ability.
[1] Dyslexia is a common example of this that I've encountered. If a colleague prefers listening to reading due to dyslexia, I will choose to speak with them because even though I'm bad at it that is the most effective means of communicating with them.
The median communicator is a very poor communicator most of the time. Communication takes active focus and effort and the default is zoning out or making assumptions about what the other is saying.
It depends. If you are on a team with full support, designers, product management, project management, etc., then sure.
But as soon as you lose one of those engineers (e.g., internal tools teams often pick up those tasks and so to build the right thing requires better than average communication skills.
The job of a software engineer at Stripe is not solely code. The job is to deliver business value, and that requires communicating with others across and outside of the organization. I’ve been at Stripe for over five years. I would not have lasted five months if I just sat at my desk and coded all day.
Engineers at Stripe wear many hats, depending on the project. My best example is Paper Checks. I’ve been an engineer, project manager, sales support, designer, support personnel, docs writer, and even visited lockbox facilities. I learned and did a lot on the project, and loved it. None of that happens if engineers just sit and code. We don’t get all the information about the flow of data and paper, and we build a poor product.
The same goes for internal projects. I was a DRI for a complex rewrite of our system. I regularly worked with six other teams to ship that project. That project doesn’t happen without communication.
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.
> 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.
That has nothing to do with communication but either with an inability to read and understand the specification which is an issue with intelligence or they have an attitude problem thinking they know everything best. None of this can be fixed by them being a good communicator, you will have the same just with a lot of extra debate.
The best engineers disappear for 1-2 days in quiet and then deliver exactly what you needed, do a bit of review/refinement with 1 or 2 other team members to tidy things up and polish the quality and then they'll pick up the next task and disappear again for a day.
The what? Sorry? If you had the specification you could just give it to the latest ChatGPT et al and it would create 90% of the code for you (just kidding, but kinda not).
No, the most important task of a software engineer is to help gathering requirements, understanding them and then translating them to code, considering internal and external constraints. Actual coding is usually the smallest part of this process. Communication may not be THE most important, but it certainly is important.
> That has nothing to do with communication but either with an inability to read and understand the specification
I must have a different definition for the word "communication" than you. If person A writes a spec, and then person B reads the spec, isn't person A communicating with person B about the specifications?
If persons C D and E also read the spec and only person B doesn't get it, wouldn't you say person B has a communication problem?
> an inability to read and understand the specification
I'd say that being able to read and understand what others want is part being a "good communicator", alongisde understanding reviews and comments from other devs and addressing those.
Also, good code is good at communicating what it does to future readers, via comments, variable names, and structure. And if you do that, you're being a good communicator.
If just being a normal human being who can read and understand normal stuff makes you immediately a "good communicator" then I also agree that being a "good communicator" is important for any job really. I personally think of someone as being a good communicator as somethign more than just normal basic humans skills and abilities to function around other people. I mean by that measure we are all good athletes if you can run 10 metres or kick a ball down the hill.
Communication is both sending and receiving. If you are only good at sending, you're not a good communicator. You have to be able to listen, both to what is said/written and what is not to be a good communicator. It's not a common skill with most engineers.
> The best engineers disappear for 1-2 days in quiet and then deliver exactly what you needed
Communication is hard, and what someone communicates what they want is very rarely exactly what they actually want (or need). Sure, sometimes the stars align and you have perfect communication of exactly the needed specification and a dev who can perfectly translate that to code. But in most real world conditions you need good communication skills at both ends. Language is full of ambiguities, and it's possible to have a perfectly reasonable interpretation of something that is totally wrong.
I've worked with plenty of competent people who have had plenty of bad ideas. If I wasn't competent at communicating my issues with these ideas I would have spent many more weeks of my life on unnecessary or poorly thought out features.
out of curiosity, how many YOE do you have? a lot of the stuff you've written reads like exactly how i felt 2-3 years into my job and thought everything was bs except the code. "screw sales, what do they even do, code is all that matters", "screw PMs, their jobs is just spreadsheets and docs, code is all that matters"
i'm over a decade in at this point and couldn't disagree more with all of your points. nothing makes me want to run away faster than dealing with some genius who "disappears" or argues around a ton of things/has no EQ.
> inability to read and understand
> or they have an attitude problem
These just sound communication problems. Every failure to understand is also a failure of the explainer.
This is a good example of what the author calls a code-focused attitude. I'm not going to judge anyone for wanting to work that way, but there's a lot of roles where it's just not very useful.
Stripe Atlas, to take the author's example, is in the fundamentally communication-based business of helping new companies legally incorporate. The vast majority of their technical challenges are going to sound less like "how do we write code that does X" and more like "should the code do X or Y"? So people who see only the former as "actual work" are going to have a hard time producing any value.
If you are not a good communicator, you will build the wrong thing. You will not fully understand what matters in what you building or be building something that is a lower priority. If you are still a good listener, which is 80+% of the way to being a good communicator, you will end up being the right thing but you effort will not be used to their full extent. People will now know about the improvements or align with what you are doing.
Agree completely. People want to work in a way they are good at so if you hire good communicators you will get a lot of communication. If you want to ship a lot of products hire people who are good at building products.
It seems people misinterpret you as saying you don’t need any communication skill which is clearly not what you meant.
> 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
Surely you're not measuring how good the engineer is based on number of lines of code he produces per day.
If LOC is not the metric, what is the difference between 1000 LOC written by good engineer vs 1000 LOC written by bad engineer?
"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I edited my response from "Without more data, your original statement that "you'd be better off" is just as subjective" to the more fully fleshed out comment you see now while I was looking for a link for my sources.
I'm not moving goal posts. I never said you could not be successful with ruby. All I'm saying is that once you hit scale, you would have an easier time cutting costs in a language that could better utilize less infrastructure and thus lowering your operating costs.
Probably because your original comment doesn't say anything about scale and instead says specifically "you'd be better off," which implies "better off from the start." I'm not saying that's what you said, but that's what it reads as.
Yes, 2-4 web servers. And it's not like they are using most expensive configuration, just 4 vCPU per node. CPU utilization is below 20%, so it could even run on a single node, but that's not good for availability.
Why is that so surprising? Nobody sane does anything CPU-intensive in their webapps.
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
I am not GP but the argument that typed language is always better to start with has its own fallacy. What if I don't have experience with a typed language and I need to get to Product Market Fit first where most startups fail ? You need to look at it from a business perspective as well. If I only know say Ruby and I can get something up and running with it, I would use that. I wouldn't worry about Typed Language or whatever.
I'm not saying it's not possible to build a successful start up with the language. My argument is just that the language can become a major expense and limiting factor once you reach scale. Many programmers know multiple languages, and if they have a choice then it may be wise to opt for a language that could help you avoid some of these problems later.
I work at a company that does ruby “at scale” too (10mil b2c users). Yes we need more web instances than we would have in go(or whatever). No, it doesn’t really matter at all - web process compute is a tiny fraction of our AWS bill, and a meaninglessly tiny % of overall op-ex. We’re talking sub sub 1%. It doesn’t matter, really.
Of course if we had a few billion users , diff story, but approximately no one does.
What proof is there that companies built on dynamic typed languages struggle with server costs, payroll, or development velocity, though?
Looking from the outside, all I can say is that both Github and especially Stripe have continued to churn out features and entire product lines well after they reached global scale…
Regarding their economics, I’d have to see a serious study proving that that the effect in infra and server costs is not only real but also non-negligible, ie, it has a real impact on the bottom line, shareholder value, company efficiency, competitiveness, or what-have-you…
> What proof is there that companies built on dynamic typed languages struggle with server costs
The proof is in the limitations of the language. If you have a 4 CPU server and you want to run a web application, you would be able to process far more transactions per second in a Java or Go application than Ruby. This is because Ruby has a GIL which means it can't truly multithread, so to get parallelization you need to multiprocess. These days kernels can spawn threads in 5ms (or with Green threads that can be in nanoseconds), but a new process takes 50ms to spawn. Then, there's the issue of Garbage Collection pauses. Java is one of the best with some very low latency (<10ms) GCs. Ruby far from the state of the art GCs. Then there's the runtime, which Ruby can be 10-100x slower than Java or Go.
It's just a matter of this logic being scaled to big levels
Rewriting a huge software base from one language to any other is going to cost a lot more than throwing money at scaling infrastructure. If performance is actually a customer observable pain point, a company would be better off investing in performance tuning their own software as well as investing in people to work on Ruby itself.
Engineers love to pull out the "it doesn't scale" card with alternative language suggestions that usually align with whatever pet/fad language they've been playing with because its new and shiny (I accuse myself here as well). At some point a business is successful enough, like Stripe, where the risk of changing out an entire tech stack outweighs any perceived benefit.
Stripe already invested in performance tuning and people to improve Ruby. Ya gotta give people some credit for thinking of the first most obvious thing.
Your biggest expense will be people. Rails is ancient at this point, but I regularly see people ship product with it in fractions of the time. You can also re-write parts in rust later, when you need to.
Once you reach scale, Ruby can be a limiting factor depending on how much latency impacts your revenue. And it's not so easy to remove that dependency as I've seen.
Rails can easily serve up pages in <100ms. If you do have an endpoint that is CPU-bound to where you can’t meet your SLA goals, you can serve up just that endpoint in Rust or Golang. But that’s rare.
Usually what happens at scale is that the SQL database starts slowing down as more data is loaded in. Partitioning, indexes and painful refactorings aren’t prioritized. Engineering will champion “a faster language”—that incidentally allows them a new data model where they add in proper indexes at the start. They aren’t really incentivized to realize they could see the same gains by just improving their existing data inside the Rails monolith.
Source: experience improving performance (including latency) with multi-billion-dollar Rails monoliths
There’s vanishingly few businesses that need <25ms. What business did you have in mind? Outside of trading , which yea of course that’s the wrong choice.
Latency is important to sales and it hasn't been an issue for Shopify. In my experience, you need people that understand how to scale things more than you need a scalable language.
This ignores internal efforts to speed-up Ruby and make it concurrency safe. Facebook took this method and did well with it. Hack is typed, and its perf is fast. Shockingly fast.
This does seem to at least rhyme with twitter's experience, and maybe also github, at least as observed from outside, where a pretty innovative initial product has difficulty progressing after a period of massive scaling.
But also: Is the lesson maybe just knowing when to pivot to more efficient runtime environments? For instance, I believe facebook had a similar experience with php, and pivoted to running it on a custom vm. Did stripe wait too long to do that kind of pivot? Or perhaps you were just there in the middle of it, which is bound to be a messy time.
Go is pretty much a better-in-every-way replacement to that entire cluster of developer-friendly languages like Ruby, Python, Node.js etc. A startup in 2023 would need to have pretty good reasons to not start in Go.
Humorously I was just in a conversation within "a startup in 2023" about how Go is not working all that well. Of course opinions vary, but I thought it was an interesting counterpoint to your comment.
For my part, my intuition is that my last project, in java, seemed to be more productive than the current project in go, and another current project, in python, also seems to be working better. But there are so many variables, it's impossible to untangle causality.
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?
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.
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.
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".
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.
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.
> 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.
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.
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.
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.