Bonded by Love for Product
We’re scratching our own itch by making all developer documentation a joy to use!
Everyone has felt the pains of poor developer documentation. It causes headaches for makers and users, and this frustration is what ultimately led us to build ReadMe. In fact, the company started when our founder, Gregory Koberger, was retreating in Costa Rica. He was supposed to be building another company with his friends, but kept finding himself reimplementing ReadMe’s functionality whenever he had to write documentation. This was in 2014… and we’ve been building ever since.
We love what we do because it’s so much more than just docs. We’re providing tools for teams to create and manage beautiful documentation with ease. We give customers the ability to login their users via JWT, we support custom variables to create personalized guides, and we have an interactive API Explorer, which allows users to try out APIs in the browser (check out our demo site!).
Documentation edits normally take days to push through, but companies can push out updates in seconds using ReadMe. Technical writers don’t need to learn how to use XML data models or make GitHub pull requests to author content anymore - they can simply make edits in our dash and save. For larger companies with stricter review processes, we have the suggested edits workflow to iterate on updates and deploy when they’re ready.
We serve customers of all sizes and love being able to help teams grow their developer communities by answering their questions and notifying them of changes. (Our product also provides companies with metrics about how their customers are using their API!)
Creative + Innovative
We pride ourselves on being able to develop elegant solutions that solve multiple requests at once.
Customer feedback guides our product roadmap, which is not only public, but it also allows users to upvote features. We are constantly listening to our users and synthesizing what they’re reporting back. While this is how all good businesses should operate, we are especially proud of how well we can tackle multiple issues at the same time. Creativity, in addition to truly listening to our customers, is where the magic is.
As a small engineering team, we have a lot of agency and each member heavily contributes to the direction of our product. For example, Sean and Marc love that in some apps and websites you can use `cmd+k` to load up a search bar which allows you to quickly navigate around an app - the main example in mind being Slack’s “Jump to...” UI. We sat down and had a discussion about it as a team, Sean got to work, and within 2 weeks we had a fully functioning Quick Switcher deployed inside our Dash.
As an engineer at ReadMe, if you have a particular pain point with using the product, you can write a proposal and present it to the team. If we see the value, you can build it. Similarly, if you want to use a new technology, do some research and pitch it to the rest of the team. Examples: React, Next.js, Asana, Prettier, etc.
Flexible Work Arrangements
No strict butt-in-seat rules here.
Even though we have a somewhat distributed engineering team (with members in San Francisco, Seattle, and Minneapolis), we’re focusing on growing our team in San Francisco where our office is. That said, we will always have flexible working hours. Everyone has flexibility to create their own schedule, though most people tend to hover around a “10am - 6pm” schedule. We don’t have any strict butt-in-seat rules and believe that doing good work is independent of which hours you do it in. We also make sure to celebrate together, no matter where people are.
You can meet our whole team here!
Wears Many Hats
Backend, frontend, public npm modules, heroku, nginx – you’ll do it all!
At this point, given our company’s size, everyone has their hands on everything. It’s not required that new hires come to ReadMe with a wide breadth of experience, but a willingness to jump in and learn different parts of our stack is important. We suspect we’ll hire for more specialized roles to take responsibility and fully own different parts of our stack as we grow, but for now, we’re looking for folks with some level of “full-stack”-ness.
We also host an API conference every year called API Mixtape. Everyone in the company travels to San Francisco to attend and is encouraged to engage with our community. Engineers also have opportunities to speak! In the past, Marc has presented ReadMe’s new features and Dom gave a talk on best practices in API documentation. We have fun with the event and built a light display for the stage that changes color based on the current speaker’s company. The light display has been repurposed for our office wall and is editable via an API. (Ask for the web address if you want to change the lights in our office!)
When you’re given a task or a feature to complete, it’s yours until you deploy to production.
We’re a small team which means that everyone doesn’t just get to be an owner, everyone has to be one. One task may consist of touching both the backend and frontend, implementing designs, writing database migrations, and updating nginx server configs. Once your work is deployed though, the entire team is then responsible for maintaining it.
A few examples of how much ownership each team member has:
- Sean built out our enterprise product. He met with sales, completed calls with clients, gathered requirements, designed the UI, and coded everything. He’s also never afraid to take on the big challenges in some of the older parts of our codebase: single handedly rewriting our whole routing layer in ~3 weeks.
- Kanad revamped the key functionality on the user-facing part of our developer sites. He made suggested edits iterative and more like GitHub pull requests. He owned all of the development, wrote the database migration, deployed and ran the migration, and was there to firefight when an issue occurred.
- Marc redesigned our homepage. He met with designers, discussed feedback with them, built the whole frontend, and refactored it so our homepage code is deployed separately from our app code. He was also responsible for creating the Heroku servers, updating DNS records, and switching to a Cloudflare backend.
- Dom rewrote the first version of our new API Explorer (which is open source). He took it from an untested garble of spaghetti code to an open source React component. It took a little over a year from start to finish: refactoring, removing cruft and turning on for some customers via feature flags until the major issues were ironed out. It is now much faster, easier to work on and supports much more complex Swagger/OAS files.
We protect our weekends and everyone works from home on Wednesday!
We want you to enjoy all aspects of your life at ReadMe, not just your work. Sean, who is based in Seattle, loves riding his motorcycle and going on hikes. Kanad lives in Minnesota, cycles (when the weather permits), and often goes to local concerts. In San Francisco, Marc likes standup comedy and has plenty of time to play with his cats (Toothless and Tesla, who of who have their own emojis on our Slack channel). On weekends, Dom is an amateur sourdough baker and an even more amateur guitar player.
Our friends, families, health, and hobbies are important to us, too! You don’t need an excuse to work from home and we genuinely encourage everyone to take advantage of their $150/month gym membership stipend.
Last but not least, we also go on quarterly offsites to make sure we mix play and work together as a team. In the past, we’ve gone to Hawaii, Chicago and Lake Tahoe. We have a tradition of getting custom prints for each location we go to and having everyone who was there sign them.
High Quality Code Base
All new code has to have tests.
Increasing code quality is a high priority for us. We are given the capacity to do things right, even if it takes longer. Everything is a trade-off: if we can spend a week fixing technical debt now to save us time in the future, then we’ll do it. We’re striving to increase test coverage across our codebase and we’ve increased coverage from 36% in November 2018 to 51% in March 2019.
By using feature flags inside of the product, we can ensure that new customers use the latest and greatest features, while leaving older customers on stable grounds without changing things. Our Customer Success team actively works to migrate customers to the latest version of features so they can be deprecated and removed from the code. Examples: hub1 -> hub2 migration; new API explorer and auto generation of SSL certificates.
We shield engineers from unnecessary meetings wherever possible.
On Mondays, we have a company-wide 30-minute meeting in the morning where everyone lists one thing they hope to complete that week. We reconvene every Friday afternoon for another 30 minutes to report back on whether you’ve completed your one task. We also have people answer a random “Mary Question™” chosen by Mary, our operations manager. Some recent questions include “What movie would be better if it were made into a musical?”, “Describe yourself in high school in 3 words”, and “What is your favorite vacation memory?”.
Engineers will also have a 1:1 with Dom on Mondays to quickly catch up on current assigned tasks. The engineering team as a whole meets once every two weeks. Aside from this, engineers are shielded from calls with customers and support and we default to asynchronous communication via Slack – no one minds if you set yourself to Away for the afternoon, you can reply tomorrow! We recognize the cost of context switching and do what we can to reduce it. As big fans of Jason Fried's Rework, we keep meetings to their expected range and actually give everyone a copy of the book when they start.