Technical writers are the unsung heroes of the API space. These creators often manage documentation, tutorials, sample code, and blog content and even sometimes partake in developer advocacy, making them a pivotal marketing arm for any API product.

Ken Cenerelli, Senior Technical Writer, Google will speak at Austin API Summit 2024 about how to engage technical writers.

According to Ken Cenerelli, Senior Technical Writer, Google, technical writers often oversee content for multiple API programs and have a broad perspective. Engaging with technical writers is also becoming more of an important element for creating APIs with quality developer experience.

Ahead of Austin Summit 2024, we’re syncing with a few speakers to learn what they’re working on and to get more background on their upcoming sessions.

Ken spent 14 years as a software developer and is currently a senior technical writer at Google Cloud, where he works on API documentation that receives millions of page views each year. Naturally, Ken has a unique perspective on the role of a technical writer and the value they bring to an API initiative.

We caught up with Ken to explore the role of technical writers in APIs, the theme of his upcoming session at the Austin API Summit. Read on for the interview with Ken below, and be sure to attend the Austin API Summit for more insights on this topic and plenty of others.

What does the job of a technical writer encompass in the scope of APIs?

Being an API technical writer generally means we write “how-to” guides on using the APIs. I’m not sure how other companies structure their technical writing roles, but at Google, the job also contains a few more tasks, including writing and editing the code comments on the API reference docs, developing overview articles to introduce concepts to users, and liaising with developer relations to build tutorials and code samples. We also work with product managers to document new endpoints and to determine if there are any content gaps.

API technical writers are also becoming more polyglot in the sense that we now produce videos, speak at developer conferences, and even write prompts for LLMs.

Why is engaging with technical writers important for marketing APIs? How can they take things to the next level?

Technical writers are one of the few groups within an organization that can see the breadth of an organization’s APIs. Developer teams may work in silos and might not know how all the pieces fit together. However, technical writers often work across multiple APIs and can see the big picture. They often know where API endpoints overlap and what data each endpoint is delivering. By engaging with technical writers, we might be able to save developer teams time by highlighting existing products that solve a problem or by bringing together disparate teams.

Additionally:

1. We are also one of the few groups who understand the entire developer journey on how to develop an API on the system we’re documenting.
2. Technical writers can capture a lot of API use cases and then share how developers can leverage them.
3. We can instruct developers on how to bring separate endpoints together to better their applications.

What are some things you often see developer-facing services getting wrong or lacking on the writing side of things?

API developers move at a fast pace, so they often want more tutorials and code samples. It’s a question we get a lot and it’s something technical writers are trying to put more resources into. In the future, I think this is where AI might be truly helpful to the technical writer. We’ll be able to generate and verify code samples a lot faster to meet developer demand.

Other things I see some docs needing is a better explanation of the basics of their API. There can often be a lot of assumptions of knowledge (such as what acronyms mean) or not enough explanation of the fundamentals. Technical writers often walk a fine line between catering to both the beginner and advanced developer.

Finally, API developers like to be able to test the endpoints to see what they return. So, either providing curl samples or having a built-in API sandbox is a must.

What are some examples of great developer documentation?

There is lots of good developer documentation out there, but the effectiveness of it can only be truly gauged by the developers using it.

Stylewise, though, I think the financial APIs by both Plaid and Stripe are visually appealing and easy to follow. Likewise, developer documentation for productivity apps like Box and Trello are laid out very well. Finally, I’m also partial to the Google Workspace APIs managed by my colleagues and I.

Do you see any difference between crafting developer-related content for internal users as opposed to writing for an external-facing audience?

During my career, I’ve only ever crafted documentation for external audiences, so they are who I traditionally focus my writing on. However, with internal users, I think the writer can assume a certain level of knowledge and familiarity with the product. This could mean that certain prerequisite steps could be skipped. Also, most companies have jargon or acronyms that everyone might know, so you could probably use these words within your docs.

What is your take on style expectations for technical writing?

Style and style guides really divide technical writers. Some people follow them strictly while others interpret them loosely. I think some feel that paying heed to style somehow inhibits their content writing. For me, style and style guides provide me the framework I need to craft docs. As I draft new words or edit existing ones, I do so with style in mind. This actually saves me time as I then receive fewer edits from the editors and it also makes their job easier.

Why are you excited for the Austin API Summit? Assuming you are 😉

I’m excited to give my talk for the second time. It’s always nice to educate people on the role of technical writers, and the Austin API Summit is the perfect opportunity to do that. I’m also looking forward to catching a few of my fellow speakers’ talks to learn more about how they are tackling issues with their APIs.

Finally, it’s been many years since I’ve visited Austin, so I’m thrilled to see the city again. Google also has a large presence in Austin, so I’m also curious to drop by our offices since each one is decorated in the style of its locale.

What takeaways do you hope to leave with attendees to your session?

I hope attendees will come away with some ideas on why technical writers are important to creating APIs and how to work with technical writers in general. I’m also hoping they come away with impressions on how to incorporate tech writers into their entire development process and view us as an important part of their teams.