Other than that: thanks for publishing this, I've often wondered why there isn't a central repository (like a wiki or something like that) with the various recipes you can use to tackle a given problem and what works and what doesn't in practice.
The internet currently provides more breadth in the area than a single person could possibly need. I laud the focus on depth.
I would expect that Increment will run less risk of burning through many important topics quickly and having their later issues tread the same ground, just shallower. We already have plenty of venues to get news about bleeding-edge developments in the tech world — HN, for instance! I wouldn't be upset if the topic of on-call weren't covered in Increment for another 2-3 years, so that the content can be more substantive and battle-tested.
Kudos and thank you, Stripe!
BTW, this is the same Susan Fowler of ex-Uber fame: https://www.susanjfowler.com/blog/2017/2/19/reflecting-on-on... Congrats on the new position, Susan!
I'd be interested in hearing what it's like moving from a code-focused job to a content-focused job. Seems like a very unique shift!
Stripe is my top design company these days. Just looking at their landing pages , , I'm deeply impressed by their effort on making the web beautiful.
Huge inspiration for me. Kudos to their front-end / design teams.
The noise the fan of my laptop made after 10s of that connect page. OMG. I do not approve of these useless animations.
Lucky I'm not running on low power mode or that would probably have frozen my browser for some time.
I'm in China atm, which is probably an area that Stripe would want to target with both atlas and connect (there's a ton of marketplace/ecommerce sellers based here, and a lot of tech innovation), and both those sites take a stupid amount of time to load.
That animation also destroys my mediocre laptop.
The pages look nice and are rich in content, but those animations and all the superfluous fonts and stuff cause them to be almost unusable if you're not on reasonably new hardware with a reasonably fast internet connection.
Tbf, I think their target for Connect is services that would be built to target those sellers by SV brats running mid/high-end laptops, but it's a good point nontheless.
Do you have an i3 or better? If not, it's slow.
You have an expensive intel core? If you're running in battery mode, it's slow.
Real case story: I have 10 cores Xeon at work with 32 GB of memory and the highest quality of IPS screens. Same thing for designers. They will never ship an application suitable to mobile/tablets/laptop. The gap in processing between mobile, desktop, workstations and servers is tremendous.
And people hate on table based layout ;-)
You're not making a good first impression if the only feedback you have is the site didn't load, and I speak from experience ;)
I wonder what the trade-offs of designing like this are, if any.
BTW on https://stripe.com/about I only found "Help us build the universal payments infrastructure of the internet." but it is listed on https://stripe.com/press
Disclosure: I'm interviewed in one of the pieces https://increment.com/on-call/the-benefits-of-transparency/
It says a lot about Stripe's workplace culture that they're not afraid of this.
I hope you're joking, because that seems like a very silly reason in the age of LinkedIn and recruiter databases. It's probably very easy to find a relatively up-to-date list of employees for any given company out there.
My guess is that most small companies don't do this simply because they don't even consider that it would be a nice gesture to publicly recognize more than just the top execs.
You are right that with things like LinkedIn you could probably get a lot of this information, but it's enough of a hurdle that execs still think it's worth it.
But in a growing company above a certain size keeping such a page up to date can be a pain.
Good point! We should clean that up.
Does that seem a bit... bubbly to anyone else?
It would be interesting to see a discussion of this topic, but I suppose this is expected if a publication is published by a company rather than by laborers directly.
Is there any evidence that on-call bonuses or compensation affects the quality of work that a team does? Maybe there is, but most of the research I've seen doesn't support that conclusion.
Intuitively, I suspect that a generous oncall compensation plan would mitigate a harsh rotation to a certain extent, but that engineers would still burn out eventually. But that's just my intuition, and I have only personal experience to back it up: I wanted to hear what other companies were doing, and was disappointed the topic wasn't covered in this otherwise comprehensive issue.
As a sort of mini-rant - with so much 'incident transparency' with Slack, Email, Dashboards, Hangouts, etc high-sev issues can devolve into all hands events if you haven't nailed the culture as well. These can be intensely political - where you got random managers/execs who haven't touched code in years in the Slack channel trying to look engaged and competent offering suggestions like, "Have we tried rolling back the release?" and the smart engineers who could actually fix the problem are afraid to do anything because everything they do is broadcasted to the entire company. It's relatively easy to adopt the tools and processes of successful tech companies but it's hard to get the culture.
(for most readers, putting just the domain should auto-detect)
However, you have to do this for each article, which takes some time.
Well... not as smooth a process, but the articles are long-ish and worthy of preservation on your Kindle.
Also, the introduction of putting down the rest of the industry while simultaneously extolling your own ideas is very off-putting, especially if we haven't heard them yet. The strength of the Stripe brand matters not; I do not know who you are.
That said, Stripe is a great company and I'd love to hear more about how they are doing things. But please, if you want me to pay attention to you, sans the hubris self-congratulatory tone.
What matters most is that the choices are consistent and coherent.
It's nice to read about practices that work in one environment, but you have to keep in mind how they integrate in to the big picture of all of the choices.
For instance, some teams branch everywhere, for everything. Which is fine, and some people do it to great success.
Some teams develop at head, for everything. Which is fine, and some people do it to great success.
But the tools you need to build around those two approaches are totally different. Reading about the tools and techniques, without understanding how they all fit together, and trying to adopt them because they work for other people, could be a recipe for disaster.
 : https://www.linkedin.com/in/will-larson-a44b543/
Made me chuckle.
 https://www.digitalocean.com/company/blog/update-on-the-apri.... (for anyone who missed them nuking the production db).
The hard part of running a start-up is to get to that point where if you fuck up enough people will notice that it makes the press.
It was just amusing timing.
> It was just amusing timing.
Ah ok. Your link doesn't work btw.
It also most likely isn't an off-the-shelf magazine theme because there's no credit to any external author of the design in either the website or the code.
Also, the source for the page is in 1 single line. Doubt any off-the-shelf theme would do that!
This might be a step in the right direction.
"The interdependent disciplines of Continuous Delivery and DevOps are of immense value to an organisation, but they are hard. We have seen Continuous Delivery and DevOps work in the wild, as have other practitioners. We want to help people on their own Continuous Delivery and DevOps journey, by sharing the experiences of those who have done it – what worked, what didn’t, and the highs and lows of trying to build quality into an organisation."
We are also expanding our coverage, you can sign up to get notified when we open up access to different methods here: https://stripe.com/payments.