Ask most people what a technical writer does and they’ll say writing.

Fair enough, it’s in the title.

Spend a few years doing it though, and you notice the writing is rarely what makes documentation succeed or fail.

Well written procedures nobody can find are useless.

Plainly written procedures organised sensibly get used every day.

The difference is structure, information architecture, then a strategy holding the whole set together.

That’s the part of this job nothing else owns.

🏗️ Structure inside a document

Every document type has a shape that works, one people expect without knowing they expect it.

A work instruction opens with what you’ll achieve, then prerequisites, then numbered steps, then what to do if it fails.

A reference guide is organised for scanning, not reading, so alphabetical or functional grouping beats narrative order.

A troubleshooting guide starts with symptoms, because that’s what the reader has, not causes.

Getting the shape wrong costs the reader time even when every sentence is correct.

A few structural decisions worth making deliberately.

• Whether this is 1 document or 4, since 1 long procedure covering 6 tasks helps nobody
• Where the prerequisites go, ideally before someone starts rather than at step 7
• How exceptions are handled, inline or separated out
• Whether steps need screenshots, or whether screenshots just date the document
• What the reader needs in the first 3 lines to know they’re in the right place

None of that is writing.

All of it determines whether the writing gets read.

🗺️ Information architecture across the set

This is the bigger job, the one that gets skipped on most programs.

Individual documents get written because someone asked for them.

Nobody asks for the structure that holds 200 documents together, so it doesn’t happen unless a writer takes it on.

The questions that need answering.

• What’s the top level organisation, by system, by role, by process, by task?
• Where does someone start when they don’t know what they’re looking for?
• How deep does the hierarchy go before people give up navigating?
• What’s the naming convention, so titles are predictable?
• How do documents link to each other without creating a maze?
• What happens at the moment of need, when someone is mid task with a customer waiting?

That last one is the test everything else should be measured against.

People don’t browse documentation, they search it under pressure.

So titles matter more than folder structures, since search behaviour beats navigation behaviour almost every time.

Worth running a small test before you commit.

Ask 5 people from different teams to find a specific procedure, then watch what they type.

Twenty minutes of that will tell you more than a month of structure debates.

🎯 Documentation strategy

Strategy sounds grand for what’s really a set of practical decisions made early rather than late.

It covers questions nobody else on a program will answer.

• What are we documenting, more importantly what aren’t we?
• Which audiences need separate material, which can share?
• Where does everything live, then who owns it after the project ends?
• What’s the review cycle, who triggers it?
• How does documentation get updated when the system changes?
• What’s the minimum viable set for go live, what can follow later?

That last question saves programs.

The instinct is to document everything before go live, which is never achievable.

A writer who can identify the 20 procedures that actually matter for day 1, then sequence the rest sensibly, is worth considerably more than one who writes 60 mediocre documents in a panic.

🧭 Why this can’t be delegated

Here’s the thing about structure work.

It requires knowing the product, the audience, the organisation, plus how documentation gets used in practice.

An SME knows the system but not what a reader needs.

A project manager knows the timeline but not how procedures should be organised.

A tool can generate a plausible outline, but it doesn’t know that this organisation calls it a service request while everyone else calls it a ticket, or that the night shift has different access.

So it falls to the writer, or it doesn’t happen.

When it doesn’t happen you get the familiar result.

Documents scattered across SharePoint, the intranet, a training folder, someone’s email.

Three versions of the same procedure, each looking official to whoever finds it first.

A knowledge base nobody trusts, so people ask the person next to them instead.

✅ What this means for the role

Drafting has become faster, which is genuinely useful.

The consequence is that production is no longer where a writer’s value sits.

Structure, architecture, strategy, those hold up fine, because they’re judgement calls rooted in understanding people.

If you’re an experienced writer wondering where to focus, it’s here.

Own the shape of the document, the organisation of the set, the plan for keeping it alive.

That’s the work that determines whether any of it gets used, which was always the only measure that mattered.

---

About the author

Aiver Ilaya is an IT consultant based in Melbourne. For 19 years he’s worked on enterprise digital transformation programs. His experience spans ITSM, HRIS, ERP, CRM, POS, KMS and EDRMS platforms, plus workflow automation. He has worked across government, healthcare, science and medical research, finance, education, telecommunications, infrastructure, aviation, construction and property, technology, retail, logistics, pharmacy, insurance and professional services.

His work covers business analysis, process optimisation, technical writing, knowledge management and UI / UX design. He has worked on multi-million dollar programs running years at a time, for national organisations and global firms, reaching millions of end users.

He has run his own consultancy for 12 years and works with a small number of clients at a time. Available for remote and hybrid contracts.

alisodigital.com