We’re doing something ambitious at Fly.io: a new public cloud, running on our own hardware around the world, designed to make it easy to run distributed and real-time apps close to users wherever they happen to be.
We do love writing here at Fly.io. Outside of docs, we write:
- On our engineering blog, in long- and short-form pieces about how our product works, with an audience of basically all the nerds on the Internet.
- On our framework blogs, where our Framework Specialists share guides and blog posts for the benefit of devs in their respective communities.
- In conversations with our users on our community forum and social media.
Our readership is software developers; our product and the kinds of problems we work on are very technical and can be somewhat subtle.
We said “aside from docs,” up there. Docs are an important part of our product. We ship things for thousands of developers, and they use our platform in exceedingly clever ways. In many cases, docs are the only features that matter to these users. No docs, no product.
Our documentation is all public and online. If there are gaps, it’s because there aren’t enough hours in the day, not because we don’t care. That’s why we need you and your hours!
The job
Here’s what you’d be doing in this role:
- Surveying our existing documentation, identifying and closing gaps (learning whatever random technical stuff it takes to write that stuff).
- Working with our whole team to spot opportunities for public writing, about features we’re working on, or the inner workings of our stack, or the technology ecosystem we fit into, or whatever interesting thing is bugging someone on a particular day.
- Working with our design team to create materials that communicate deeply technical ideas in cogent and appealing ways.
- Interacting with users on the community forum. This is a great way to learn about how customers are experiencing our platform and where we could communicate better through docs.
- Not gonna lie, you’re going to be asked to do some proofreading and copy editing.
Technical writing at Fly.io isn’t an anonymous cost-center role. We are emphatically not the kind of place where writing is seen as a necessary evil, something to get out of the way with the minimum possible investment.
Our writing tools
The vast majority of our public writing right now — that’s docs and articles — goes through Middleman, a Ruby static site generator.
For new articles, we’ll typically share a draft on Slab, discuss it on Discourse (we’re big on async communication), and format it in Markdown and ERB. We publish by merging a pull request on a GitHub repository.
You may be a good fit for this role if you:
- Can write excellent English, but know when to break the rules. You won’t, like, flinch when you see “like” in the middle of a sentence.
- Relish the challenge of arranging a pile of technical information into a logical, easy-to-digest package.
- Get very suspicious when someone uses marketing buzzwords at you.
- Enjoy having autonomy within a collaborative environment.
- Are comfortable with programming in general, and comfortable with a high-level language like Ruby, Python, or Javascript.
- Are happy diving into GitHub repos and talking to busy devs to get the goods.
- Love learning new things. You won’t be confined to a single focus, and you’ll want a solid understanding to make sure the finished product is coherent.
- Like the idea of a high-profile role working in public communicating directly with our users.
- Want to work in a diverse and respectful team that values communication, glue work, and small, autonomous teams making decisions for themselves.
Mostly, we want to work with people who love to write and who find the problems we work on exciting. Global Anycast, modern language frameworks like Elixir/Phoenix, containers and virtualization, and security are all part of our beat.
Things to know about us
- We’re remote-first and hire around the world. That means a lot of asynchronous communication—and flexible hours.
- We’re still small, but growing fast. We’re still building structures and processes. This can be good, and bad.
- The vast majority of our communication is written, in English. This will probably suit you fine, if you’re reading this.
- We love what we do. But it’s not our entire lives. We offer flexible time off, with a minimum.
How we hire people
If this sounds like an awesome gig (it is) but you’re not sure if you should go for it because maybe you don’t have the background we’re looking for, you should go for it.
We are weird about hiring. We’re skeptical of resumes and we don’t trust interviews (we’re happy to talk, though). We respect career experience but we aren’t hypnotized by it, and we’re thrilled at the prospect of discovering new talent.
The premise of our hiring process is that we’re going to show you the kind of work we’re doing and then see if you enjoy actually doing it; “work-sample challenges”. Unlike a lot of places that assign “take-home problems”, our challenges are the backbone of our whole process; they’re not pre-screeners for an interview gauntlet.
For this role, we’re going to give a couple of writing assignments. We’ll ask you to write up a how-to and a feature reference doc, adapting existing reference materials, and then have you hammer out a draft blog post about a hypothetical new feature.
You can read some of this again and more, over at our hiring documentation. It was written for software engineering positions, but all the good stuff applies to us in Content too.
If you’re interested, mail jobs+techwriter@fly.io. You can tell us a bit about yourself, if you like. Either way, include a paragraph or two about the most frustrating technical blog post or article that you’ve read recently. Bonus points if we wrote it.