In my last post I answered who a technical communicator is. This one answers the harder question: what do they actually need to know to do the job well?
Going through tekom’s training material, I found the answer split into four dimensions. Not four job titles, four kinds of knowledge that live in the same person at the same time.
Dimension 1: Knowing the Process Chain
Every piece of documentation moves through a chain of steps before it reaches a user. Information gathering comes first: talking to engineers, reading specs, understanding what the product actually does.
Then planning, deciding what the document needs to cover and how it should be structured. Then drafting, the part most people picture when they think of this job.
Then validating, checking the draft against the real product to make sure nothing is wrong or missing. Then maintenance, because a document is never really finished. Products change, and the documentation has to change with them.
I recognized this documentation process immediately from my own background, even though nobody ever called it that where I worked.
Every piece of content I managed moved through the same stages: gather, plan, draft, check, update.
Knowing this chain isn’t just useful, it’s what keeps a documentation project from turning into chaos halfway through.
Dimension 2: Knowing the Product
You can’t explain what you don’t understand. A technical communicator needs real knowledge of the product, service, or subject matter they’re documenting: its features, its technical specs, how it actually works.
How deep that knowledge needs to go depends on the product. For consumer goods, a technical communicator usually needs enough technical understanding to describe the functions clearly, paired with strong documentation skills.
For industrial products, installations, and complex systems, the documentation is often produced by staff who combine deep technical expertise with technical communication skills, sometimes an engineer who writes, sometimes a technical communicator paired closely with an engineer. Either way, the product knowledge has to be real, not surface level.
Dimension 3: Knowing the Tools
This one surprised me the most, because it’s less demanding than most tool comparison articles make it sound.
A technical communicator needs a good working overview of the commonly used tools in the field: writing tools, software tools, and production tools.
That’s the baseline that applies everywhere. Many of these tools rely on structured authoring principles, even if a new hire doesn’t touch that terminology on day one.
Beyond that baseline, you pick up the specific tools your organization uses once you’re actually working there.
Nobody expects a new hire to already know every content management system, every authoring tool, and every publishing platform on the market.
What matters is being comfortable enough with the category of tool that learning a specific one doesn’t take months.
Dimension 4: Knowing the Information Types
The last dimension is about matching the right format to the right situation. A product’s lifecycle produces a lot of different kinds of information: quick start guides, full manuals, warning labels, help screens, maintenance instructions, and more.
A technical communicator needs to know these types exist and, more importantly, know when to use which one.
The same product might need a one page quick reference for a first time user and a detailed manual for a technician doing repairs.
Picking the wrong format doesn’t just look sloppy, it makes the information less usable, which defeats the entire purpose of the job.
Why All Four Matter Together
None of these four dimensions works well on its own. Knowing the process without knowing the product gets you a well organized document that’s technically wrong.
Knowing the product without knowing the process gets you accurate information delivered late, or delivered badly.
Knowing the tools without knowing the information types gets you a beautifully formatted document that’s the wrong document for the job.
This is really the answer to “what makes someone good at technical communication,” a question worth asking alongside professional bodies like the Society for Technical Communication.
It’s not one skill. It’s four kinds of knowledge, held at the same time, applied to the same piece of work.
