In case you’re new here, Railway is an infrastructure company that provides instant application deployments to developers.

We’re doing a series on Scaling Railway that covers various parts of the company, from Platform to Infrastructure, as well as Support, Product Updates, and everything else. In this blogpost we’re taking a look at How We Work.

Two years ago we published How We Work to document some of our processes: no daily stand-ups, minimal recurring meetings, internal comms on Discord, fanatical use of RFCs and PRDs to communicate engineering work, minimization of meta work, maximization of real work, and a bunch more.

That blogpost still gets a ton of views and people mention it during our recruiting pipeline all the time. But we’ve learned some lessons and some things have changed since then.

In particular, we’ve doubled down on remote work, codified our belief in autonomy, extended our commitment to craft, ditched OKRs, and improved a bunch of remote systems along the way.

This is the story of How We Work, Volume II.

Remember when everybody was all-in on remote work? That seems like forever ago.

Now, I love Flo. He referred me to Uber and we worked together for a while on Jump. But I think he’s got it twisted.

Maybe I’m personally biased because Railway is an entirely remote company, but I think the issue is that if you try and transpose the office to the metaverse, you’re gonna have a bad time.

The ONLY way remote works is if you have clear boundaries, strong alignment, clear communication, and a strong culture of autonomy.

That last point in particular most companies simply don’t have — so let’s start there.

We recently wrote about supporting 250K developers with one support engineer and we can only do things like this by building tools to extend our own capabilities.

To put it candidly, we don’t carry passengers on our team. Our goal is to support 1B developers with a team of ≤ 100, so leverage is a key part of everything we do. And leverage isn’t possible without autonomy.

We’re a team of 14 at the moment (and hiring!) and the only way we can build the platform we want is to have directly responsible individuals (DRIs) to own things from start to finish. We don’t babysit people, we don’t look over people’s shoulders, we don’t apply sticky layers of management to problems that we can automate.

If we have to ask people for status updates, we think we’re doing it wrong.

The key enabler of autonomy for us is helping each employee become the subject matter expert for their superpower at Railway. Think Star Trek — when there’s a problem with the core, you call Scotty. When it’s cryptography or linguistics, you call Uhura. And so on.

As an example, a single person was the DRI (directly responsible individual) for rolling-out horizontal scaling two weeks ago. A single person is the DRI for persistent storage volumes. A single person is the DRI for standing-up private networking and a single person is the DRI for building-out Changesets, which we started releasing last week.

Here are some more examples of how we promote autonomy:

• We keep meetings to a couple hours on Monday and Friday — the rest of the week is for deep work. This is a necessity for us that’s really hard to come by in an office setting
• We do quarterly planning by P0 (”Holy moly! This is going to burn the company down if we don’t fix it!”), P1 (”We’re shipping this unless a meteor hits us”), and P2 (”This would be nice to have”) — and use this to prioritize throughout the quarter. This works better for us than OKRs
• We do Daily Wraps in Discord because we don’t want a culture of people breathing down our necks asking for project updates
• We favor async nonblocking workflows, so PRs don’t need a stamp (just to pass CI) to merge but we have a review queue built into Discord to ask for 👀
• We open all channels internally by default and favor open non-DM tagging to be mindful of people’s focus work

It’s been written about before that craft is a key component of making good software. For us craft means delivering something above reasonable expectations because that’s where the magic is.

Value happens when you exceed expectation, but magic happens only when you far exceed expectation

Why is craft important? For one, it’s the ultimate growth lever. Secondly, it keeps us bound to each other and to our work. We exist to bring about a world where developers ship without friction. This means bringing human-design standards somewhere they haven’t been before — internet infrastructure.

Craft is the thing we share together. It’s the joy and sense of communal accomplishment we share when something moves the needle for our users.

We share screencasts in a Progress Pics channel. It’s a super joyful and motivating thing.

We share ongoing projects with each other as video Progress Pics

We also have an open, non-judgmental culture where people feel comfortable sharing how they feel. In fact, we overshare often and encourage each other to overshare.

We favor open communication in a remote environment

Here are some more examples of how we promote craft:

• We strive to be courteous but direct because we’re all trying to do our best work
• We do meetings in Discord voice channels where rooms are public[1] — anyone on the team can hop in and join if they want to or need to
• Everyone gets unlimited PTO, and is required to take at least 2 full weeks off every year and 1 full week at a time
• Everyone gets a company credit card they can use for purchases that makes their work and work life easier

[1] We have a dedicated meeting rooms for 1:1s where this is the exception

The number one remote misconception, in my opinion, is that everything can be async. We need core meeting hours because that’s our opportunity to discuss things synchronously.

People crave human interaction. They NEED it. And hopping up to higher bandwidth mediums makes decisions go faster — that’s a fact.

This immediately presents some concerns for some people. If we have our meetings in US AM, won’t it be really late for the people in Asia?

Yes, yes it will be. And that’s okay. In fact, for some people, this is preferable.

Our goal was to figure out the optimal amount of meeting time and work backwards to make this as effective as possible. For us that means we mostly meet in the mornings PT on Monday and Friday.

What else does remote help us do?

• We index on topics not on people — this means people can look at messages at their own pace
• We raise our hands on video chat. It’s a polite way to make sure everyone who has something to say is heard
• We can time travel — hand off something to someone on the other side of the world, and it can be done by the time you wake up!
• We write everything down so we have a forced, infinite, indexable history
• We hire from and work from anywhere so as not to block out talent for visa or other reasons
• We don’t directly ping people in the middle of the week unless it’s urgent. We either call an incident or put something in the triage board to return to by Friday

Hands raised during a meeting

Remote work is a double-edged sword. If you run your remote company like an office and expect to be able to tap people on the shoulder all the time, you’re not going to create the space needed to ship massive things.

By creating space for both collaboration AND autonomy you in essence create a set of APIs that doesn’t just “work around” remote work but instead unlocks something greater.

Your mileage may vary, but for us, autonomy, leverage, craft, remote work are all symbiotic concepts. We protect these principles because that’s how we feel like we can get the most out of ourselves and deliver the best product possible.

We promise to keep you updated on how it’s going — so see you next time in Volume III!