Writing Clearly in the Age of AI: Lessons from Stripe’s Ryan Young

Gowri: Welcome everyone to the Knowledge Base Ninjas podcast. With me today, I’m very happy to introduce Ryan Young, Staff Technical Writer at Stripe. Hi, Ryan. Good morning. How’s everything?

Ryan: Hello. Good morning. Yeah, doing well. Thank you.

Gowri: Fantastic. So Ryan, you’ve spent over 16 years in technical writing, and now you’re Staff Technical Writer at Stripe. Before we talk anything further, just help us understand: how did you choose this career? Who was your mentor, or who was your motivator to take this as your career path?

Ryan: Well, I think, maybe, at least some technical writers I’ve met, this definitely wasn’t my intended path when I was in college. It was something I kind of fell into when I was taking a master’s program, and through a friend, fell into a job at a software company. I was doing more admin work in the sales department. Someone noticed I didn’t really have a sales personality, but my writing and communication was good.

So they suggested maybe either going into marketing or technical writing. I thought technical writing seemed a little more clear-cut, so I went with that, and then just learned on the job. I had a mentor there at that first place, and then just kept on going.

Gowri: The writing landscape has changed, I’m sure, during your career in the last few years to a larger extent. What makes writing a skill that continues to matter irrespective of the tool that anybody uses?

Ryan: I mean, at least I think for a lot of people, and I know it’s definitely true for me, a lot of my job is just writing text messages to people through Slack or email. So everyone’s writing all the time and reading all the time.

Obviously, what you write on Slack isn’t necessarily something you go and revise. It’s not like fine copy or anything like that. But I think that’s true even of the finished documentation that you put out for the public, for users.

Whatever tool you’re using, whether you’re using FrameMaker like I did at first, or what we’re using now, it’s still the same basic, fundamental supply of just being clear, being concise, understanding where your readers or your users are coming from.

And just making sure that you could cut across any noise of other competing messages. Users generally don’t want to read, so you have to contend with that. So yeah, I think writing well and writing clearly is maybe more important than ever.

Gowri: Absolutely. I think how quickly a reader can understand a small paragraph matters the most, right?

Ryan: Yeah, absolutely. They shouldn’t be lost, no matter where they are.

Gowri: I think you’ve given me a different way of thinking about this. You spoke about thinking in different content levels, like orientation, decision, and implementation, and how a reader understands what you write. How does understanding what a reader needs at each stage shape the way you write? Is that your primary criteria when you write any content?

Ryan: I guess it depends on the project and the exact situation. But overall, it’s just having situational awareness of what you’re writing for, who you’re writing for, and when they might be coming across what you’ve written.

Because if you’re writing an overview page or a landing page or something, you probably want to have less text and fewer details, or more finely selected details.

And then if a user’s trying to make a decision, if you’re trying to help them decide between two different paths, then again, you don’t necessarily want to overwhelm them with details. But you want to provide enough so that they understand how to match up what you’re presenting with what they’re bringing to the table.

So it’s just another form of progressive disclosure, knowing that writing an overview is quite different from writing a detailed instructional guide.

In a detailed guide, you’re providing all the examples, and you’re fairly confident that the user is like, “Okay, I know I want to install this thing,” or, “I want to configure this thing.” So you want to get into all the details and provide examples. But then you also don’t want to explain the conceptual overview again within that guide.

I just think of it as situational awareness and knowing where your words are going to end up.

Gowri: If you could hand every engineer at Stripe one writing habit to carry for life, what would it be?

Ryan: Honestly, most engineers at Stripe are pretty good writers. But in general, I would say: if you’re writing any kind of technical documentation, use active present tense as the default.

I think that’ll help clear up your writing quite a bit. Unless you really need to describe time relative to something else, just use active present tense. I think that’ll clear up a lot of writing issues.

Gowri: Now that leads me to the next question, nice and smooth. Have you ever rewritten something after watching someone actually try to use it?

Ryan: Yeah. I don’t know if it’s necessarily been quite like I watch a user go through the workflow and then immediately go and rewrite all that.

But I think at Stripe especially, there’s a really strong culture of going through and understanding what the user is trying to do and what they’re dealing with. So doing dogfooding exercises and getting actual user feedback, and just constantly, as much as possible, trying to understand what’s happening with users in a bunch of different ways.

I feel like we’re very lucky to have this constant feedback loop of other people at Stripe having gone through a workflow and explaining, “Hey, this little bit was unclear,” or maybe this was unnecessary, or getting that feedback from users. So I feel like we’re kind of constantly rewriting things all the time.

When you’re working, especially if it’s something new, you go through the usual process of understanding the design, the intent. You test out stuff, talk to engineers and whatnot. But at some point you just have to put something out and see what actual users say. Then you’re kind of in a state of constant refinement after that, to some degree.

Gowri: Absolutely. Rather than trying to think of every single possible scenario and delay the content, you just first give your first draft or your first version and then see how it’s consumed. Then maybe you can make the tweaks.

Ryan: Yeah. Because even then, the product changes, users change, technology changes. Like now, obviously with AI and LLM agents and whatnot, that changes a lot of things. So again, it changes what you might want to be presenting on one page versus another page, or how you link between things.

Where before it may be you want to insert an option or something like that, but maybe you want to put that somewhere else, or present it in a different way. So the more I think about it, the more I think I’m just constantly rewriting based on what users have done.

Gowri: I’m sure you’ve worked with different teams for various purposes, but after working across different teams, technologies, and documentation environments, what has changed most in the way you think about writing well?

Ryan: I think, especially earlier in my career, it was just learning how to not be too precious about it. Especially with technical documentation, you’re writing for a very clear, specific purpose most of the time.

It’s a kind of weird situation where you’re writing for people who don’t usually want to actually read. So you kind of have to fight against that all the time. It’s not like you’re writing an essay or a story where people are coming to it and want to dig into it and revel in your words and phrasing. You’re trying to convey information succinctly and clearly.

So I think that was especially the case initially — it’s just information. You’re trying to convey information, and it has to be written well. At some point it’s text that someone’s going to be reading, or an agent maybe. But still you have to be really clear.

So despite wherever it’s appearing, you want it to be well-written. Good, clean prose.

Gowri: Let’s move on to some rapid-fire round questions, Ryan. I’m sure you must have read a lot of content and must be contributing as well. But anything in particular that you’d like to share with our audience today?

Ryan: In terms of resources or…?

Gowri: Particularly to the documentation field. Any blogs or any particular author you like the most and you keep going back to?

Ryan: I don’t know if there’s any one particular website or blog. I guess just the Write the Docs community in general — I rely on that a lot, just to get a sense of the industry and what other people are doing. And then plus there’s just a huge pool of resources from them. I’ll use that community a lot. But to be honest, I don’t know if there’s anything specific to technical writing that I would necessarily point to.

Gowri: I know it’s hard to remember on the spot. I think Write the Docs is brilliant. We do have sessions in London and amazing speakers we get on a monthly basis. So that’s a good resource.

Gowri: If I can ask you, what comes to your mind when you hear the word “documentation”? One word that comes to your mind.

Ryan: Well, I think of two words, but I would say “technically accurate.” I think beyond anything else, that’s what I would hope documentation to be. That’s what I would want from it — to be technically accurate. And then hopefully it follows best practices of being clear and concise and all of those things.

Gowri: As a piece of advice, what would you give to your 20-year-old self?

Ryan: I was quite dumb in college, so I think what I would tell myself is to take at least one computer science class. For whatever reason, I was an English major, so I wanted to be very purely English oriented. So I stayed away from computer science and all that, but I really wish I had taken just at least one class, and probably more. But that’s what I would tell my younger self.

Gowri: Fantastic, Ryan. So is there anything else you would like to add to the audience today?

Ryan: Just in general — I think I’ve mentioned it a few times — I feel like it’s inevitable now, AI and LLMs and things like that. But I would just encourage people not to offload their thinking to it.

They’re very powerful tools, but especially when it comes to writing, I’d say as much as possible try to do your own writing, especially when you’re trying to work out ideas. Because I think this is definitely true for me, and I think it’s true for everyone: you don’t know what you’re thinking until you’ve written it down. So I’d say just don’t offload your thinking, your writing, to other entities.

Gowri: That’s nice. I think people now think AI could solve everything and anything. But you’re correct. At the end of the day, you need to understand the code in order to validate what AI has written, right?

Ryan: Right. Yeah, and I use it. It has very powerful use cases, but I would say it’s based on human output, so we need to keep on producing human output, I guess.

Gowri: Alright, great. So thank you, Ryan. I know it was a very quick session, but it was great to know how your journey began and how it is shaping up now. And all I can wish you is all the very best in the upcoming journey, and thank you once again for taking your time and spending it on this podcast.

Ryan: Okay. Well, yeah, thank you so much for having me on. It’s been really great, and it’s great talking to you.

Gowri: Thank you. Take care, Ryan.

Ryan: Thank you. Bye.