Knowledgebase Ninjas · 2026-09-09 · 16 min
Key moments - from our scoring
Substance score
45 / 100
Five dimensions, 20 points each
Ryan Young draws from his 16-year career in technical writing - including roles using FrameMaker and now at Stripe - to explain why writing clarity has become more critical, not less, in the age of AI and LLMs. He stresses that technical documentation serves readers who actively resist reading, requiring aggressive clarity over eloquence. The core principle Young advocates is situational awareness: tailoring content depth and structure to the reader's stage (orientation, decision, or implementation). He champions active present tense as a universal writing habit that resolves most clarity issues, and describes Stripe's culture of constant user feedback loops and dog-fooding that keep documentation in perpetual refinement. Critically, Young warns against offloading thinking to AI tools, arguing that the act of writing itself is how writers discover and validate their ideas. His message resonates with technical writers, product managers, and engineers who own documentation: good writing is a skill that transcends tooling, and documentation quality compounds when grounded in real user behavior rather than theoretical scenarios.
Use active present tense as the default. Ryan Young recommends this as the most impactful habit because it clears up most writing clarity issues without requiring additional effort or revisions.
Release early and maintain constant refinement through user feedback loops and dog-fooding exercises. The product, users, and technology change constantly, so waiting to perfect everything before publishing wastes resources.
No. While AI is a powerful tool with valid use cases, Ryan warns against offloading thinking entirely to it, because writing is how you discover and validate your ideas - letting AI handle that defeats the purpose.
Practice situational awareness of what your reader needs at each stage: overview pages need less text and finer details, decision pages need just enough information without overwhelm, and implementation guides need examples and depth.
Start by understanding user intent and workflows through testing and feedback, use clear language without being precious about phrasing, and focus on conveying information succinctly rather than creating elaborate prose.
Our reviewer’s read on each dimension, with quotes from the episode.
The episode contains some solid practical advice on technical writing (active present tense, progressive disclosure, situational awareness) and a useful framing around user-centered documentation. However, much of the conversation is surface-level or repetitive - the same core principles are restated multiple times without deepening them. The AI commentary toward the end is generic. A B2B operator would gain a few actionable takeaways but not substantial novel thinking.
use active present tense as the default. And I think that'll help clear up your writing quite a bit
progressive disclosure, I think. Think of just kind of knowing that
The advice is sound but well-trodden in technical writing circles: clarity matters, know your audience, test with users, avoid AI over-reliance. None of these are contrarian or fresh. The 'write the docs' community and 'active present tense' are established best practices, not novel insights. There is no first-principles thinking or counterintuitive argument that would surprise someone moderately familiar with technical writing.
being clear, being concise, kind of understanding where your readers or your users are coming from
the write the docs community in general
Ryan Young is a legitimate practitioner - a staff technical writer at Stripe with 16+ years of experience in the field, which is genuine seniority. However, Stripe's documentation excellence is well-known, and the episode doesn't probe deeply into what makes Stripe's approach distinctive or how Ryan has shaped it. The guest is credible but not positioned as a major strategic voice or operator influencing large-scale outcomes beyond his immediate function.
staff technical writer at Stripe
over 16 years in technical writing
The episode lacks concrete data, metrics, or specific examples. Ryan mentions 'dog fooding exercises' and 'user feedback loops' at Stripe but provides no actual examples of docs that failed, specific user pain points, or measurable improvements from applying these principles. There are no named products, time frames, or numbers. Most claims remain abstract ('this changes how you present things').
doing kind of like dog fooding exercises and getting actual user feedback
maybe this was unclear or maybe this was unnecessary
The host asks open-ended questions but rarely pushes back or probes deeper. When Ryan offers a principle, the host tends to affirm it rather than challenge it or ask for specifics. The 'rapid fire' section feels obligatory. There are no moments of productive tension, disagreement, or sharp follow-ups that would extract richer detail or nuance from the guest.
All right, now that leads me to the next question. Nice and smooth
Yeah. Yeah. Great. A piece of advice you would give to your 20 year old self
Computed from the transcript - who did the talking, and the words that came up most.
In this episode of the Knowledge Base Ninjas podcast , host Gowri Ramkumar speaks with Ryan Young, Staff Technical Writer at Stripe , about the fundamentals of technical writing and how they continue to matter in an evolving technology landscape. Ryan shares his journey into technical writing and explains why clarity, conciseness, and understanding the reader remain essential, regardless of the tools writers use. He also discusses writing for different stages of the user journey, using progressive disclosure, and refining documentation based on real user feedback. The conversation also touches on AI and LLMs. Ryan believes these tools have powerful use cases, but writers should not outsource their thinking to them. For him, writing is part of the thinking process itself. Human judgment therefore remains essential to producing clear and useful documentation. Thank you for tuning in! In the meantime, if you're ready to explore Document360, a knowledge base platform that can help your customers and teams get instant answers, we’d love to invite you to try it first-hand. Simply use this link - to start your free trial.
Transcribed and scored by The B2B Podcast Index.
Speaker A: It was in the sales department they noticed I didn't really have like a sales personality, but my writing and communication was good. So they suggested maybe either going into like marketing or technical writing. And so I, I thought technical writing and I think that'll help clear up your writing quite a bit. Like, don't worry about. Unless you really need to describe time relative to something else. Uh, yeah, just use active present tense. And I think that'll clear up a lot of writing issues. You're writing for people who don't usually want to actually read. So you kind of have to like fight against that all the time. It's not, you know, you're not writing like an essay or a story where people are coming to it and like, want to like dig into it and kind of revel in your words and phrasing and things like that. It's, you're trying to convey information succinctly and clearly. Uh, 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. Welcome to the Knowledge Based Ninjas podcast where Gauri Ram Kumar of document360 finds the best SaaS self service knowledge bases in the world and then interviews their creators. Let's get started with today's episode.
Speaker B: All right, let's start. Welcome everyone to the Knowledge Base Ninjas podcast with me today. I am very happy to introduce Ryan Young, staff technical writer at Stripe. Hi Ryan. Good morning. How's everything?
Speaker A: Hello M. Good morning. Yeah, doing well, thank you.
Speaker B: Fantastic. So Ryan, uh, You've spent over 16 years in technical writing and now uh, your staff technical writer at Stripe. Before we talk anything further, just help us understand how did you choose this career? Who was your uh, mentor or who was your motivator to take this as all of your career path?
Speaker A: Yeah, well, I think like maybe. Well, at least some technical writers I met. I definitely. This wasn't kind of my intended path. Like when I was in college, it was something I kind of fell into when I was going to, I was taking a master's program and kind of through a friend kind of uh, fell into ah, a job at a software company. And then there I was kind of doing more kind of admin work and someone noticed that um, you know, it was in the sales department, they, they noticed I, I didn't really have like a sales personality, but my writing and communication was, was good. So they suggested maybe either going into like marketing or technical writing. And so I, I Thought technical writing seemed a little bit more clear cut. I guess. So I went with that and then just kind of uh, learned on the job, uh, had kind of a mentor there at that first place. And then, uh, yeah, and then just kind of um, kept on going.
Speaker B: Nice. I know it's 16 years is a long time to remember, but uh, yeah, quite a long memory lane. Yeah.
Speaker A: Yeah.
Speaker B: Great. Now, without saying, uh, the writing landscape has changed I'm sure, during your career in the last few uh, years to a larger extent now. What makes writing. Well, a skill that continues to matter irrespective of the tool that you, that anybody uses?
Speaker A: I mean, at least I think for a lot of people, um, at least I know it's definitely true for me is that a lot of my job is just writing text messages to people through Slack or email. And so it just. Everyone's writing all the time and reading all the time, so they're, you know, um, obviously what you write on Slack isn't necessarily like, you know, you don't go and revise that and it's not like buying copy or anything like that. But um, but I think that's true even of, you know, kind of the finished documentation that you put out for like in the public for users is that um. Yeah, whatever, whatever tool you're using, um, if you're using Framemaker like I did at first or you know, um, what we're using now, like it's. Yeah, it's still the same kind of basic fundamentals apply, of just being clear, being concise, kind of understanding where your readers or your users are coming from and yeah, so just kind of making sure that you could get cut across any, any noise of kind of uh, other competing messages or you know, users generally don't want to read. So you have to kind of contend with that. So yeah, I think writing well and writing clearly is. Yeah, maybe more important than ever.
Speaker B: Absolutely. I think uh, how quickly can a reader understand from, from a small paragraph matters the most? Right?
Speaker A: Yeah, absolutely. Yeah, they shouldn't. Yeah. Readers shouldn't be lost no matter where they are.
Speaker B: Yeah, I think you've given me a different way of thinking this. So you spoke about thinking in different uh, content levels like orientation, decision and how it is implemented and how a reader understands what you write. How does um, understanding what a reader needs at each stage shape the way you write? Is that what your primary criteria is when you write any content?
Speaker A: Yeah, I mean, I guess it depends, you know, kind of on the project and the exact situation, but I think overall it just kind of maybe having kind of situational awareness of what you're writing for and who you're writing for and when they might be coming across what you've written. Because I think, you know, if you're writing like kind of an overview page or a landing page or something, like, you probably want to have less text and maybe like fewer details or more finely selected details. Uh, 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 go. You don't want to overwhelm them with details, but you want to be able to provide them with 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 kind of another form of progressive disclosure, I think. Think of just kind of knowing that. Um, yeah, so, like, if you're. Again, like, yeah, if you're writing an overview, it's quite different than writing, like, a detailed, you know, instructional guide where you're providing, like, 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 be, you know, provide. Get into all these details, provide examples, and, um. But again, then you also don't want to explain the conceptual overview again within that guide. So, yeah, right. Like I said, I think I kind of just think of it as kind of situational awareness and kind of knowing where your words are going to end up.
Speaker B: Yeah. Now, if you could hand every engineer at stripe one writing habit to carry for life, what would it be?
Speaker A: I mean, honestly, like, the most engineers at Stripe are pretty good writers, but I think in general with engineers, I would say if you're writing any kind of technical documentation, use active present tense as the default. And I think that'll help clear up your writing quite a bit. Like, don't worry about. Unless you really need to describe time relative to something else. Uh, yeah, just use active present tense, and I think that'll clear up a lot of writing issues.
Speaker B: All right, now that leads me to the next question. Nice and smooth. Smooth. Which is, have you ever rewritten something after watching someone actually try to use it?
Speaker A: Yeah, I mean, I don't know if it's necessarily been quite like, I, you know, watch a user go through the workflow and then immediately go through and, like, I've got to rewrite all that. But I think at Stripe, especially, like, There's a really strong culture of like, kind of going through and understanding what the user's trying to do and what they're dealing with. So like doing kind of like dog fooding exercises and getting actual user feedback and just constantly, as much as possible trying to understand what's happening with users and you know, in a bunch of different ways. So I feel like there's very lucky to have kind of this constant feedback loop of either other people at Stripe kind of having gone through a workflow and kind of explaining that, hey, this little bit was unclear or maybe this was unnecessary or getting that feedback from users so that it's like. So I feel like we're kind of constantly rewriting things all the time. So it's uh, at some point, you know, when you're working, especially if it's something new like you, you go through like the usual process of like understanding the design, the intent, you test out stuff, talk uh, to engineers and whatnot. But like, at some point you just kind of like you have to put something out and see what actual users say and then, but then you're kind of in a state of constant refinement after that to some degree.
Speaker B: So, um, Absolutely, yeah. Rather than trying to think every single possible scenarios 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.
Speaker A: Yeah, because I mean, right, because even the product changes, users change, technology changes. Because now obviously with AI and LLM agents and whatnot, that changes a lot of things. So again, it changes kind of what you might want to be presenting on one page versus another page or how you link between things. And yeah, like, whereas before maybe like you want to insert like an option or something like that, but maybe, maybe, you know, maybe you want to put that somewhere else or present it in a different way. So, um, yeah, I mean, yeah, the more I think about it, the more I think I'm just constantly rewriting based on what users have done.
Speaker B: Yeah, I'm sure you've worked with different teams, uh, for various, uh, purposes. But uh, yeah. After working across different teams, technologies and documentation environments, what has changed most in the way you think about writing?
Speaker A: Well, I think, well, maybe this was especially like earlier in my career of just kind of learning kind of how to separate, not being too precious about it, I guess, where it's, you know, this is, especially with technical documentation, you're writing for a very clear, specific purpose almost all the time. You know, again, like it's Kind of a weird situation where you're writing for people who don't usually want to actually read. So you kind of have to like fight against that all the time. It's not, you know, you're not writing like an essay or a story where people are coming to it and like, want to like, dig into it and kind of revel in your words and phrasing and things like that. It's. You're trying to convey information succinctly and clearly. So I think that was uh, again, especially kind of initially coming to it. It's information. You're trying to convey information and it's, it has to be written well. You know, like at some point it's text that someone's going to be reading or an agent maybe. But uh, still, you just, you still have to be really clear. So I think, yeah, just kind of despite what, wherever it's appearing, it's still. You want it to be well written. Good, good clean prose.
Speaker B: Yeah. All right, let's move on to some rapid fire round questions. Uh, Ryan, so I'm sure you must have read a lot of uh, contents and must um, be contributing as well, but any, anything in particular that you'd like to share with our audience today
Speaker A: in terms of kind of resources or
Speaker B: um, particularly to documentation? Uh, field. Yeah, anything. Any blogs or any particular author you kind of like the most and you keep going back to, to the content?
Speaker A: Yeah, I mean, I don't know if there's any one particular like website or, or blog. I mean I, I guess just the write the docs community in general. I rely on a lot just to kind of like kind of get a sense of the industry and what other people are doing and then plus there's just a huge pool of resources from, from them. Uh, so, uh, you know, I'll use that kind of community a lot. Yeah. But to be honest, Yeah. I don't know if there's anything specific to technical writing that I would necessarily. Um.
Speaker B: Yeah, I know it's hard to the spot because I think write the talks is, is brilliant to have uh, sessions in London and uh, amazing, um, speakers we get uh, on a monthly basis. So. Yeah, that, that, that's a good resource. Yeah. Thank you. So if I can ask you what comes to your mind when you hear the word documentation? What would, what would that be? One word that comes to your mind, I guess.
Speaker A: Well, I think of two words, but I guess I would say technically accurate.
Speaker B: Okay.
Speaker A: Yeah, I mean, I think beyond anything else. I guess that's what I Would hope, you know, documentation to be is. That's, that's what I want from it is just to be technically accurate and then hopefully, you know, it's like follows the best practices of being, you know, clear and concise and all of those things.
Speaker B: Yeah. Yeah. Great. A piece of advice you would give to your 20 year old self.
Speaker A: Yeah. 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 very dumb and kind of, um, I was an English major, so I felt it was like very, I wanted to be very purely like, you know, English oriented. Um, so I stayed away from computer science and all that. But I really wish I had taken just at least one, one class, uh, and probably more. But, um, that's, that's what I would tell my. And yourself.
Speaker B: Yeah, why not? Fair enough. Thank you. Fantastic, Ryan. So is there anything else you would like to add to the audiences today if I miss. To ask anything in particular?
Speaker A: Yeah, just in general. I mean, I think I've mentioned it a few times. Just, uh, I feel like it's inevitable now of AI and LLMs and things like that, but I would just encourage people not to offload their thinking to it. It's, you know, they're very powerful tools. But like, especially when, when it comes to writing, I'd say as much as possible, try to do your own writing. Especially when you're trying to like work out ideas. Um, because I think this is definitely true for me, and I think it's true for everyone, is that you don't know what you're thinking until you've kind of written it down. So, yeah, I would say just. Yeah, don't offload your, your thinking, your, your writing to, um, to other, uh, uh, entities. Yes.
Speaker B: All right, that's nice. Yeah, I think, um, people now think AI could solve everything and anything. But uh, you're, you're correct. It's. At the end of the day you need to understand the code in order to validate what AI is written. Right.
Speaker A: Right. Yeah, I'm not. So it's, it's, it's. I use it, you know, it has very, there's some very powerful use cases for it, but I would say there, it's based on human output. So, um, it's, uh. We need to keep on producing human output, I guess.
Speaker B: Nice. 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 yeah, all I can wish you is all the very best in the upcoming journey. And, uh, thank you once again for taking your time and, uh, spending on this, um, podcast.
Speaker A: Okay, well, yeah, thank you so much for having me on. It's been really great, and it's great talking to you.
Speaker B: Thank you.
Speaker A: Thanks for listening to today's episode of the Knowledge Based Ninjas podcast.
Speaker B: M.
Speaker A: Please head to iTunes, rate and provide honest feedback on the podcast. See you next week.
Other episodes covering the same guests and topics, from across The B2B Podcast Index.
AI As Your Writing PartnerThe Future of Work · on Technical writing64 / 100
Ep. 53: Proactive customer support through community building at Drift [Feat. Ben Gardner, VP of Customer Support at Drift]Support Insights Podcast · on knowledge base63 / 100
Top 10 Customer Support Triage and Resolution AgentsAgentic AI at Work: The Future of Workflow Automation · on knowledge base57 / 100
Nobody Told Her To Build ItThe Ownership Advantage w/Tanner O’Brien · on knowledge base52 / 100
Design, Refine, Succeed: The Impact of Iterative ThinkingResults by Design: UX Insights for Business Leaders · on User feedback loops49 / 100
Product Ops: The 4 Foundations of Strategic PartnershipProduct Team Success · on Documentation46 / 100
From Python to Technical Writing: A Cloud-Native Documentation Journey with Michael Uzukwu62 / 100
Will AI Replace Technical Writers? The Future of Docs with Steev Kundukulangara75 / 100
Technical Writing Leadership in the Age of AI - with Ramesh Aiyyangar, TechWritePro59 / 100
From Developer to Tech Writer: How AI, Empathy & Localization Shape Modern Documentation51 / 100
Role of Cybersecurity Documentation: Beyond Compliance with Abhishek Sahoo42 / 100