I was interviewed by Sarah for a podcast.
Below is a machine generated transcription.
Sarah Chen interviews Adam Gordon Bell about his successful content creation strategies during his time at Earthly Technologies.
Sarah Chen: Adam, your articles consistently made it to the front page of Hacker News during your time at Earthly, with pieces like “We built the fastest CI and it failed” and “Don’t Feed the Thought Leaders” generating hundreds of points. What was your approach to selecting topics that would resonate with the developer community?
Adam Gordon Bell: Hi Sarah, I should clarify that I didn’t actually write “We built the fastest CI and it failed” - that was by Vlad. But yes, “Don’t Feed the Thought Leaders” was one of my early successes at Earthly. It’s kind of a complicated story how I ended up being able to spend so much time doing writing as part of my job, but it was a fantastic experience.
Sarah Chen: I apologize for the misattribution! You’re right, “We built the fastest CI and it failed” was Vlad’s piece, not yours.
Yes, I’d absolutely love to hear the full backstory of how you ended up being able to dedicate significant time to writing as part of your role at Earthly.
Adam Gordon Bell: I was working as an engineering manager, but I also had my podcast before I started at Earthly. Communicating with developers was already something I enjoyed. Then I got pinged by Vlad about this possible developer relations role. I definitely had experience on the engineering side in a similar area, so I took the role without too much forethought.
One of the issues was that neither Vlad nor I knew exactly how we could grow the market using developer relations. I had originally imagined we’d be giving a lot of talks, but this was also during COVID. I do recall us going to virtual meetups and trying to show off how Earthly worked.
One time I was at a virtual dev tools meetup—or perhaps it was DevOps, I’m not sure—and after giving a long demo of how to build things with Earthly, I asked for questions. There was only one guest besides the person who organized it, and he just said, “So this is a command line tool, right?” And I said, “Yep, it’s a command line tool.”
It was pretty painful. It was clear that talking one-on-one to people who didn’t even necessarily understand what I was talking about was not going to be effective. So Vlad and I met with a bunch of his investors one-on-one to talk about what would work and how we could garner attention with a low budget. There were just four people at the company at this seed stage.
Everybody had their own idea. Partnerships was a common suggestion—maybe if we could partner with AWS, that would be fantastic. No shortage of people saying try this, try that. But one of the investors was Mitch Weiner, who was the marketing brain behind early Digital Ocean, and he said something like, “Find out the problems that your customers have and write down the solutions for them.”
We were like, “What? And then what?” And he said, “That’s it. That’s the whole thing.”
It’s hard for me to know exactly what my recollection of this is because I’ve told the story so many times. But he explained that Digital Ocean had grown by creating tutorials—“How to do X on Digital Ocean.” At some point, he also explained that they needed to be vendor-neutral. You need to be creating something of value, not just “Here’s how you use our product.” It needs to address people’s problems.
He told us lots of other things, but that’s what stuck: you just need to create valuable content and put it out there. That started our focus on writing.
One of my early successful efforts was an article called “Intercal, YAML, and Other Horrible Programming Languages.” I specifically remember that this idea came from something I was reading by David Sedaris, where he was on a train and had interspersed his thoughts about the train ride with quotes from a person who was making bad jokes. I had the idea to combine that back-and-forth, breaking things up with jokes, and use it to talk about YAML and how it wasn’t good for programming languages.
It’s kind of an insane piece of writing for an early corporate blog if you think about it. But the funny thing is that it worked, specifically because of the title. People just wanted to disagree with the fact that I called YAML a programming language. If they read the article, they would understand what I meant, but in a way, it was like a kind of reader comprehension test.
This became a pattern that I used quite a bit—a title that seems inflammatory but actually means something else. That was one of the early successes, and by success, I mean it did very well on Hacker News and Reddit and even appeared in a couple of newsletters. We just needed people to know we existed. The article did have a point about YAML being a really bad idea for programming tasks, but in a way, it was just a piece of creative writing. I think that kind of set the formula.
Sarah Chen: That’s fascinating! So Mitch Weiner’s simple content advice completely shifted your strategy.
After finding this initial success, how did you decide which topics to tackle next? Was there a system you developed for identifying what would resonate with the developer community?
Adam Gordon Bell: Michael Lynch has this course on writing for Hacker News. It’s called “Get to the Top of Hacker News” or something like that, and it was super helpful. He covered a lot about what topics work and what topics don’t work. A big part of his advice was just to make sure you write something really good and spend a bunch of time on it.
Titles are important. I remember him saying that you want a title that a large majority of people who might be reading Hacker News or Reddit would want to read or respond to. YAML is one of those topics everybody is familiar with. If you write about something very fringe, it’s only interesting to a smaller amount of people. If you write about Git or VS Code or YAML, it has a much wider base of possible support.
Once you start having something succeed like that, you just want to keep repeating it. I’m not sure how much I had to brainstorm ideas because once you have something succeed, it’s just kind of top of mind and you think about it a lot.
The next thing I did that was a big success was “Green versus Brown Programming Languages.” In that case, I was not trying to be David Sedaris, but Scott Alexander, who would have these posts where he would look at stats, make a graph, and try to explain what he saw in it. For me, a great source of data was the Stack Overflow survey about what languages people liked or didn’t like. The cool thing about that is it ties into people’s interests. Everybody wants to see where their programming language fits or argue about it.
Among other things I was doing at the company—answering people’s questions, trying out new features, product work—the big impact turned out to be a lot of times on this writing, which often had nothing to do with Earthly at all. It was just a way to garner attention.
To a certain extent, that became my thing—try to write these posts that would do well on Hacker News, aim to have one on Hacker News a month. That was set as a goal for me. It worked better in the earlier days and got harder later on, but it was a lot of fun.
Sarah Chen: I’m curious about your actual writing process. Once you had a topic like “Green vs. Brown Programming Languages,” how did you approach the research and drafting? Did you have a specific method that helped you consistently produce content that resonated with developers?
Adam Gordon Bell: I would write in a markdown file, and hopefully during the writing process, it would flow out nicely. Then there would be the editing process where I would read back through. I spent a lot of time reading books with writing tips and tricks and trying to apply them. I would also use Grammarly a lot. I found it a challenge how much I didn’t know about writing.
In the early days, Cory, who was our DevOps/Ops Engineer, would review my drafts in Google Docs, and he was very good at pointing out places where the writing could be improved. He seemed to have a skill set at editing. After a while, that faded off—I don’t think he had time to provide feedback on all that stuff.
Much more time was spent editing these articles—reading it back, making changes, gathering feedback from people—than on the initial drafting. I also spent a bunch of time trying to come up with visuals, pictures and things that might keep it entertaining.
This was before there were really solid LLMs that could criticize your work, which I tend to use nowadays. They can be quite helpful, acting like Cory did before to a certain extent.
Sarah Chen: It’s fascinating to hear about your editing process. Given that your writing often had little direct connection to Earthly’s product, how did the company measure the success of these articles? Was there a way you tracked whether this exposure translated to business results?
Adam Gordon Bell: We had analytics so we could measure visits to the homepage and track signups. With one of those earlier posts, which I think was “Don’t Feed the Thought Leaders,” we ended up getting direct emails from at least one enterprise who was interested in using our product. They had read the blog post, wondered what Earthly was, then clicked around and investigated. So we were able to actually see the results in people emailing us occasionally, which was pretty cool.
Another big thing that started to happen was that the links we got based on that exposure helped us rank better for everything we did on Google. We started to get quite a bit of Google search traffic. And people had just heard of Earthly, that we existed and were a build tool. So the impact was definitely there.
Sarah Chen: That’s really valuable insight into how content translated to business outcomes. Among all your successful pieces during your time at Earthly, which one do you think had the biggest impact, and what did you learn from that particular article’s success?
Adam Gordon Bell: I wrote a blog post on “When to Use Bazel.” Bazel was one of our big competitors and really part of the inspiration for why Earthly was built. To write an article about Bazel, which was quite complex, I used some of my podcast interviewing experience to find a bunch of people who were familiar with Bazel, who had taken on big project migrations, and interviewed them.
I think I interviewed about six people and then extracted all this interview-style advice from them about when to use it and when not to use it. That, I think, was a very accurate portrayal of Bazel, but also showed that it’s a complex tool to use and not a fit for a lot of cases. That was kind of the message we wanted to get out there. So I think that was pretty impactful, but again, not in a direct way.
Sarah Chen: That’s a clever approach - using your interviewing skills to create balanced, authoritative content about a competitor. As your time at Earthly progressed, how did your content strategy evolve? Were there ways you had to adapt your approach as the company grew or as you gained more experience?
Adam Gordon Bell: Eventually, we tried to get more specific about converting people to be Earthly users. We tried lots of experiments to get people to convert more. I don’t think we ever really figured out some sort of secret sauce to get people from blog visitor to converting.
Internal team content worked really well though. Just talking about how we built something—writing an article with engineering and getting it out there—was really impactful. You’re able to talk more directly about the problem, but it still doesn’t come off as just a product pitch because you’re talking about building something. That worked quite well.
I don’t think it works as well now, but we also did a lot of work on outsourcing. We hired a full-time editor, brought in external writers, and had them focus on content that would do well in Google. That really brought us a lot of Google traffic. But that’s a totally different type of content that’s more straight tutorial-focused. That was towards the end of my time at Earthly.
Sarah Chen: Looking back at your time at Earthly, what do you think is the most counterintuitive lesson you learned about technical content creation that other developer advocates or technical writers might be surprised by?
Adam Gordon Bell: What seems to be really lacking is focusing on being interesting, entertaining, and informative without triggering people’s feeling that this is just marketing content for your new product.
I think there’s a firm understanding that if you’re going to apply to speak at a conference, you can’t just be there to talk about your commercial product and how awesome it is. You need to talk about something that is entertaining for people and informative—not a straight product push.
But it feels like people throw away those instincts when it’s time to publish something on their corporate blog. The same goes for internal engineering content. When people write an interesting engineering story on their personal engineering blog, they include all the exciting details and lessons learned. Why not publish that at work as a team effort? Why not be plain-spoken about it and speak like a human?
Sometimes I feel like that type of broader educational entertaining content—there’s no reason it can’t be done by individuals within organizations. It doesn’t all have to be PR announcements about new features.
Sarah Chen: That’s a powerful insight. It seems like your success came from treating the corporate blog more like a personal engineering blog, focusing on being interesting, entertaining, and informative rather than purely promotional.
[This concludes part one of our interview with Adam Gordon Bell. Join us for part two where we’ll explore Adam’s transition to Pulumi and how his content creation approach has evolved in his new role.]