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

Welcome 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.

And 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

into 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

alters 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?

You 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.

You'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,

FedEx, 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.

You 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,

the 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.

An 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

bridge 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.

Structured 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.