Victoria Lazarus Newsletter Review: Hidden Skill Every Tech Writer Must Master

0:00Welcome to the Technical Writing Success podcast from Kurt Robbins, where we help you get smarter than your competition. Higher Kurt to coach you or your employees in AI to avoid a pink slip or having your competition eat your lunch. This is episode 190. I am your host, Fred Jones. And I am your expert guide, Dacni Blake. This episode reviews an informative newsletter from senior technical writer, Victoria Olucci Lazarus in Nigeria entitled, the hidden skill every technical writer must master those published on February 23. And, you know, we're really focusing squarely on your career toolkit today. Right. Because we want to explore why mastering grammar or having a deep technical understanding of a product or even knowing industry standard tools, like notion or mad cap flair, all the standard stuff. Exactly. Why all of that is simply not enough to succeed in technical writing. Okay. Let's unpack this because Victoria's main argument here is that the real job of a technical writer isn't just to, well, document a product. No, not at all. The job is to organize reality.

1:00And let's be honest, reality in the software development world is, uh, it's absolute chaos. It really is incredibly messy. I mean, you have engineers who view the product entirely through the lens of the code base, right? Oh, for sure. And then you have product managers focused on business outcomes, plus the end users who just want to get a specific task done without pulling their hair out. Right. They just want it to work. Yeah. So to navigate that chaotic intersection, you need this invisible capability that she calls structured thinking, structured thinking. Right. It's basically the ability to take all of that raw, disorganized complexity, synthesize it internally and then present it externally as something clear and logical. But I am going to push back on that phrase a bit because structured thinking sounds highly intellectualized. Okay. Isn't it just a fancy philosophical way of describing formatting? I mean, like if I'm applying a strict style guide and organizing my thoughts

2:01into bullet points, right, making it look nice. Exactly. Have an eye structured by thinking, well, not exactly. And that is a really crucial distinction to make formatting is purely visual, you know, it happens on the screen, but structured thinking is purely cognitive. It happens in your brain. It's like, um, think of it like cartography map making. Yeah, formatting is just choosing the color of the highway lines on the map or picking a nice font for the city names. But structured thinking is the actual surveying of the terrain. Precisely. It's figuring out how the road network connects, determining which paths are one way and like understanding where a traveler might get lost. So if you draw a beautifully formatted road that leads directly off a cliff, the font you chose really doesn't matter. The underlying logic is broken. Okay. That makes perfect sense. A beautifully styled document that forces a user to jump back and forth between three different pages is still a failure. It's a total failure. The tools just can't fix a broken thought process. What's fascinating here is how applying this mental framework fundamentally

3:04alters your day to day workflow. The article actually highlights three superpowers of this. Let's hear them. So the first superpower is asking better questions because without structured thinking, a writer often falls into the trap of just, you know, asking unstructured things like walking up to a lead developer and asking, Hey, how does this new authentication feature work exactly, which is a terrible question. It really is because the engineer is going to answer you truthfully from their perspective, which means they'll give you a highly technical, completely disorganized brain dump. Right. They'll start talking about how the token hashes through assault bypasses the middle where you're just frantically taking notes completely overwhelmed and you walk away with a timeline of the code's execution rather than an actual guide for the user. Exactly. But a structured thinker doesn't ask that open-ended question. They map the context first. They asked things like what specific user problem does this feature solve for who is this for? Right. And what needs to happen immediately before the user reaches this step?

4:08You establish the why and the who before you ever touch the how you're essentially interrogating the boundaries of the feature before you let them talk about the internal mechanisms. Yes, because you're preventing the chaos from entering your notes in the first place, which naturally solves one of the biggest frustrations readers face. Right. Creating actual flow. Oh, absolutely. That's the second super power because as a reader, there is nothing more exhausting than reading a paragraph, feeling completely lost and having to reread it three times just to decipher the basic context. That friction happens because the writer didn't provide a mental anchor. They just dump facts onto the page. But when you structure your thinking, the reader never has to guess the next logical step. It's the difference between being handed a box of puzzle pieces with no picture on the cover versus being handed the pieces already sorted by color and border. That's a great way to put it. You did the heavy lifting in your brain. So there's doesn't have to struggle. But this brings up a delicate tightrope lock.

5:09You're constantly tasked with explaining highly complex systems. How does this help you break down complexity without oversimplifying it? Because that's the third super power, like handling complexity. It is. And it allows you to control the altitude of the information. You don't start at ground level in the weeds of the code. You started at 30,000 feet exactly to establish the broad landscape. What the system is and why it exists. Then you methodically drill down. You show the relationships between different pieces before you explain the pieces themselves. You aren't just transcribing facts. You are actively designing, understanding, designing, understanding. I love that. Let's take a brief break for a special message from our producer, Kurt Robbins. Hi, this is Kurt Robbins. First, thanks for listening. I truly appreciate your support. I want to let you know that I'm currently accepting new clients. My rates are affordable and I have more than 25 years of experience working for enterprise companies like Microsoft, Northrop Grumman, Oracle, PNC bank,

6:10FedEx, USA and Wells Fargo, among many others. If you want to improve your IT documentation and communications, hire me. I deliver fast. Know how to use AI to improve efficiency and accuracy and love going the extra mile to satisfy my clients. Thank you for subscribing and listening. Back to you, Daphne and Fred. Welcome back to the technical writing success podcast, where we help you get smarter than your competition by coaching you in AI. Thanks for staying with us. So what does this all mean for you listening right now? If you sit down at your desk tomorrow morning to document a messy new API, what is the practical application of this? Well, the most critical step is building a mental blueprint before your hands ever touch the keyboard. You have to violently resist the urge to just open a blank page and start typing chronological steps. Because chronological doesn't always mean logical, absolutely not just because a developer built the feature in a certain sequence doesn't mean a human brain wants to learn it in that sequence. Right. So to build this blueprint, you interrogate the info you have.

7:13You start by strictly defining the primary objective. If the user only takes away one thing, what is it? Okay. Then you determine the absolute prerequisites like what must they have already installed before step one even makes sense? This is how you spot those catastrophic gaps in logic. Exactly. If you're just typing out steps blindly, you're going to miss things. But with a blueprint, you suddenly realize, wait, step four requires a unique ID, but we haven't actually explained where to find that ID. And you catch that inconsistency while it's still just a thought rather than a publish error that generates 10 angry support tickets. Right. Did Victoria share any specific tips for strengthening this skill? She did. A great practical exercise is to take dense, existing paragraphs of technical explanation and ruthlessly convert them into clean bullet hierarchies. Oh, I find that exercise fascinating because it exposes terrible writing instantly. It really does. When you try to force a meandering paragraph into a strict hierarchy,

8:13the fluffy, unnecessary text has nowhere to hide. You realize half the paragraph was just filler. It's a phenomenal diagnostic tool. But the ultimate test of structured thinking, and she highly recommends trying this is practicing layered summarization, layered summarization. What's that? It's taking a complex technical concept and explaining it in three distinct layers, beginner, intermediate, and advanced. Oh, let's actually put that to the test right now. Let's roleplay it. Okay. Sure. Let's take a standard concept like an API key. Perfect. So if I am a complete beginner, say a non technical project manager, how do you structure that for a beginner, I'm omitting the technical mechanism entirely, I'd say an API key is like a digital ID badge for an employee. When your software tries to get data, it swipes this badge to prove it has the right security clearance. Okay. You anchored it to a real world concept, intermediate layer. I'm a junior developer. I know what APIs are, but I need practical context. We introduced the mechanics without the edge cases.

9:13An API key is unique string passed in the header of a request. It authenticates the client without needing a password every time. Mostly to track usage and prevent abuse. Notice how the structure shifted from analogy to functional mechanics, right? Okay, hit me with the advanced layer. I am a senior backend architect integrating our enterprise system with yours. Now we focus entirely on constraints and security. Our API keys are cryptographically generated UUIDs tied to specific permissions codes. You pass them via a bearer token over TLS 1.2. They have a 90 day rotation policy and rate limiting is enforced at 10,000 requests per minute. That is brilliant. The topic never changed, but the structural architecture completely adapted to my cognitive needs. If you can do that fluidly, it means you own the information. It doesn't own you that adaptability is amazing. If we connect this to the bigger picture, there was this truly profound comment on the original newsletter from a reader named a manual. What did a manual say? He pointed out that technical writing is essentially the vital load bearing

10:16bridge between raw, intimidating complexity and everyday usability. I love that visualization because a product could have the most elegant bug free code base in the world. But if the bridge connecting that code to the user is structurally unsound, right, if the docs are chaotic, the user will never experience that elegance. They'll just experience frustration and abandon the product. Exactly. The engineering of the product and the engineering of the explanation are equally important, which makes it incredibly ironic that this skill goes almost completely unrecognized. It is the ultimate invisible skill. I mean, no user is ever going to email you saying, wow, the cognitive mapping of this manual was exquisite and you're rarely going to see structured thinking listed as a mandatory requirement on a job description. Recruiters just ask for five years of experience with markdown or get because tools are easy to measure. You either know Jira or you don't, right? It's much harder to measure someone's ability to impose order on chaos. But the tools are just the paint.

11:17Structured thinking is the framing of the house exactly. And because it's invisible, it's drastically undervalued by writers themselves, which is a massive career mistake. The technical writing is about thinking clearly enough that others don't have to struggle. It really forces us to ask a much larger question. We spend so much time optimizing our software stacks and tweaking our style guides, right? But what other invisible cognitive skills in your daily workflow? Are you currently undervaluing that actually dictate your success? That's the real question. Thank you for listening to the technical writing success podcast from Kurt Robbins, where we help you get smarter than your competition. Hire us to coach you or your employees in AI to future proof your career or company. Subscribe now to never miss a career saving episode.