The first thing you notice about Dom might just be his British accent. But, after a while you’ll notice that he always shows up at team Zoom chats. He’s always willing to answer questions or ask you about your day (despite having an ultra-packed schedule). And, he’s got a pretty humble approach to his role as engineering manager at ReadMe.
Dom Harrington has been at ReadMe for almost four years, and he started when ReadMe was just a team of five. Now he’s the manager of a team of almost ten engineers, and it’s been a bit of a wild ride to get there—starting with a trip to Thailand.
Dom was working at a tech company in London when he came across some docs hosted on ReadMe and saw we were hiring. He was interested in moving to the U.S. and was curious about the problems ReadMe was solving, so he decided to apply. At his delight, the team flew him out to Thailand for his interview! (They were working there for a month since they didn’t have a San Francisco office.) He spent a couple days in the summer of 2016 interviewing with the team, and a few days on the beach. Then two months getting a visa and packing, and finally he made the move to San Francisco!
Early Technical Challenges at ReadMe
During his early years at ReadMe, one of Dom’s biggest projects was to find a way to generate SSL certificates for users’ custom domains. The team recently migrated from Dom’s homegrown solution to Cloudflare, but in 2017 it wasn’t as common to create custom SSL certificates. So Dom created a solution using Let’s Encrypt—and now it’s one of his fondest engineering achievements.
Dom ended up writing about this project in an article on the ReadMe Blog: How We Generate SSL Certificates for Custom Domains using Let's Encrypt.
Engineer → Engineering Manager
There was something gratifying about coding for 40 hours a week and pushing code and new features every week as an engineer, but Dom now has equally as much experience as a manager, and says he’s gotten used to the slower, more strategic pace.
"There aren't so many quick wins, there aren't so many dopamine hits. It's a lot slower moving, it's a lot more finding people's passions, finding what’s engaging, and looking at things from a higher level.”
Now that the team’s grown from two to ten, engineers now start new initiatives because they’re passionate about a specific project, and those ideas are democratically approved by the rest of the team. Dom says he’s all for any change an engineer brings in if they’re willing to put in the work and prove its viability.
Being in charge of a team has allowed him to extend the reach of his abilities and empower others. Even though he’s not coding as much as he used to, he’s able to accomplish much more now that he has a whole team working toward the goal of creating a stellar developer experience platform.
Creating a Magical Developer Experience
“Polish the product” is one of ReadMe’s core values—we’re a small team, but it doesn’t show. The engineering team has recently been able to completely overhaul search within ReadMe to include everything from better design to improved search relevance. Dom says his biggest goals are to have his team ship clean, simple, and stable code.
Some of our bigger plans allow custom CSS and javascript, so we constantly question the best ways to keep their sites stable while we make big improvements to the product. Early on, we didn’t need to be as careful about what we shipped, but as our core product grows we’re considering the best ways to roll out big releases.
His team has established numerous procedures recently for improved reliability, and is working on more now. We’ve switched to a weekly rollout schedule, release new features to plans that don’t allow customization first, and our enterprise team is working to produce staging sites. This would allow enterprise customers to remain on a version of ReadMe that fits their specific needs.
“We have the ability to make really complex interactions appear to be really simple. When you import an OpenAPI file to us, we do a lot behind the scenes with that file. But we hide a lot of that complexity away. That’s what I like best about ReadMe’s product: it appears really simple on the surface, but there is a lot of complexity and user customizability.”
For example, when you upload an API description file to ReadMe, we construct web pages from it, and deploy them to a public site. After just a single interaction, users get an automatically-generated API Explorer where anyone can try out the API in a browser.
Growing the Team
We’re now hiring more engineers with specific areas of expertise instead of generalist full-stack engineers (who make more sense to hire in the beginning of a startup’s journey). That’s one of the most exciting parts of growth for Dom, because with more breadth and depth in knowledge, the team can come up with creative ideas for what to work on, and produce a more polished and high-quality product.
“That’s been one of my favorite parts about the growth [of the team],” Dom says, “is seeing changes to the codebase that I had nothing to do with.”
When an engineer begins at ReadMe, Dom spends time with them sharing context and information about the product and company culture, or pairing with them on projects. For engineers who’ve been at ReadMe longer, he’s more likely to ask them for suggestions and ideas because they are more experienced in their areas of expertise.
“It's kind of a bit of a reversal where, instead of me telling them how to do it, it's them telling me how they're going to do it,” he says.
🌱 If you’re interested in working with Dom and the rest of the ReadMe team, he wants you to know: we’re hiring! Check out our careers page to see if anything sparks your enthusiasm.
