Being user-obsessed is key to effective documentation: Lynne Thompson

Transcript:

• • • 01:34–4:35 — How Lynne Accidentally Found Her Way Into Technical Writing

      Gowri:

      Stop. Great. So if all is good, I’m going to start the podcast. Good. Good day, everyone. Our guest today is Lynne Thompson, technical writing consultant. She’s got ample experience and is the perfect guest to have on this podcast. Welcome, Lynne, to the Knowledge Base Ninjas podcast. How are you doing?

      Lynne: Thank you, thank you, Gowri, so much. It’s great to be here.

      Gowri: Great, great. So I’m just going to take you many years backward. Tell me—how did it all start?

      Lynne: Many, many years. It started funnily. I don’t think it would happen the same way today. Technical writing was so new as a profession back then. People always did the writing—engineers did it, secretaries did it—but it wasn’t really defined as a profession.

      I was finishing college, and my friend—who graduated early—got a job through a recruiter at AT&T as a technical editor. As I was graduating, I wondered what I was going to do. I had majored in English, I loved books, and I lived close to New York City, so I thought I’d just take the bus to New York and work in a publishing house. I would have been happy doing that.

      But I found out how much it cost to commute into New York, and how little publishing paid. I had college loans. So my friend Kim said, “Why don’t you call my recruiter? Maybe you can get a job at AT&T as a technical editor.” So I did. That was the start. I owe her.

      I ended up working on a huge FCC filing. AT&T hadn’t been fully broken up yet, and they were filing giant sets of documentation to prove financial viability. I had to edit those. Strange introduction to the field—but I worked at it and enjoyed the independence the work gave me. It grew from there.

      I worked at Western Electric too. In another podcast I shared how we used to assemble books—pasting typeset onto boards! Even then it was old-fashioned. But yes, I kept moving around within AT&T in New Jersey—great place for that. Got more technical, developed skills, took courses. That’s how it all began.

    • 04:35–07:17 — Ensuring Documentation Accuracy Through Cross-Team Collaboration

      Gowri: Wow. I know we won’t do full justice today because it’s such a short podcast, but let me try. From your experience, how can technical writers gather accurate information about their audience’s skill level, background, and expectations?

      Lynne: It’s always been hard, though easier now. It depends on the company. In some places, you’re plugged into marketing, sales, or implementation teams. On one project, I heard salespeople’s concerns directly, and I’d ask, “Would it help if I add this to the document?” They’d say yes.

      In other places, you’re not plugged in, so you have to try harder. If there’s a feedback mechanism—review it. If there’s a knowledge base—look at ratings, look at what people visit the most.

      You can talk to product owners.

      Basically—talk to everyone. People want to help make the product better. They don’t always realise documentation is part of that.

      I always say: when I start a job, invite me to everything. I’ll decide what to drop later. Some people still think technical writers don’t need to be in meetings. But you learn so much simply by listening.

      At Verizon, I insisted on joining the daily scrum. They asked, “Why do you need to be here?” I said: “I need to hear what developers are struggling with so I know how to document it.” That helped enormously.

      Plug in early—that’s the best strategy.

    • 07:18–10:11 — Why Research Is the Key to Simplifying Complex Concepts

      Gowri: Fantastic. Now, what strategies help simplify complex concepts?

      Lynne: The classic one: interview the right person. But first—do your research. If you show up prepared, SMEs respect that. They want to talk about their work. Everyone’s busy, so show respect for their time.

      You also have to be inventive. Once, a product owner kept avoiding my calls because he was too busy. This was back when we had physical desk phones—he could see my extension and wouldn’t pick up. I really needed a key piece of information. So I went next door and called from another phone. He answered immediately. I was polite—“Hi Joel, just need a quick moment”—and he was fine. People get stressed and deprioritise documentation, but it’s critical.

    • 10:12–11:27 — Don’t Start Writing Yet—First Understand the Whole Product

      Gowri: Absolutely. Next—what common mistakes do technical writers make that complicate documentation?

      Lynne: Jumping in too quickly without understanding the big picture. It’s important to know where your little piece fits—otherwise, the user doesn’t know why they’re doing something.

      I’ve made that mistake. Now I dig deep into the product. Sit with people. Try the application. Become obsessed with the user. That perspective changes everything.

    • 11:28–13:41 — Metrics That Matter for Documentation

      Gowri: Great. Now—what specific metrics or user behaviours indicate documentation success or failure?

      Lynne: I often work contract roles, so I don’t always have access to company-level metrics. But I track what I can—Grammarly scores, improvements over time. I check knowledge base analytics, stars, feedback, support tickets. Look at what people visit and what they avoid.

      There aren’t always metrics, but you can still gather insight.

      Gowri: Very true. We tell customers to track support tickets, onboarding conversations, and engagement. Things are changing though.

      Lynne: Yes, and a lot is automating. I love digging into help desk tickets when I can—it’s so satisfying to write something that directly reduces confusion.

    • 13:42–14:54 — Valuable Resources on Technical Writing

      Gowri: Great. Now a quick rapid-fire round. Resources you find valuable?

      Lynne: I love reading Michael Clark from the UK—his blog is practical and immediately useful. I also rely on LinkedIn groups for technical writers and business analysts. Lots of expert-level discussions, especially on AI.

    • 14:55–16:21 — Documentation Does Not Have to Be Boring

      Gowri:

      One word that comes to mind when you hear “documentation”?

      Lynne: Boring.

      Gowri: I didn’t expect that from you!

      Lynne: Just picturing huge stacks of books. But my goal is to make it not boring.

    • 16:22–17:02 — Why Continuous Learning Is Essential for Technical Writers

      Gowri:

      One piece of advice you would give your 20-year-old self?

      Lynne: Take courses. Things change fast. Be thoughtful but keep learning. Tech writers are paid to learn—we learn new things constantly. And you need to like the process of learning, not just the topics.

      Gowri: Fantastic. Anything else you’d like to share?

      Lynne: No, you did a great job. Good luck to everyone—the job market is tough. And happy holidays!

      Gowri: Thank you so much. Have a lovely holiday season.

      Lynne: You too—this was fun!