Caveat: All of these opinions are my own and do not reflect that of my employer, or any community/organisation that I am associated with. 

From tens to hundreds and thousands (and I am not talking about those tiny, multicoloured sugar sprinkles used mainly as edible decorations for desserts, cakes).

From big cloud providers to service management tech, from design management tools, to a recent data cloud tech company.

I am unfortunately referring to the number of technical writing and tech content roles made redundant/axed across a range of organisations globally, including Australia.

It has been a pretty grim picture since the pandemic, particularly in the last few years.

The reasoning: AI should be able to pick this up.

The real truth: No real understanding of what these disciplines do, or how they weave into the rich tapestry that is technology.

---

As far as I remember (I have been tech writing since 2005), there’s always been a underlying, quiet frustration in Australia’s technical writing community, and it’s not hard to understand why. Despite documentation being one of the most visible faces of any product, technical writers are routinely undervalued, misunderstood, and shoe-horned into roles that were clearly designed by people who have never actually worked in the discipline or have no context of the nuances involved in this craft.

If Australian companies want to build world-class products, it’s time to have an honest conversation about how they treat the people who explain those products to the world.

That one time they didn’t actually need a technical writer!

This is a true story from around 2009. I was pretty early in my technical writing career, and after a couple of years of working in permanent roles across technical product teams, was looking at contract roles to expand my knowledge of technical writing, but also documenting systems across different industries.

I applied for a contract gig that advertised for a Technical Writer, but the job description was somewhat confusing. Nevertheless I persisted, and was asked by the recruitment agency to come in for an interview. After getting the pleasantries out of the way, I was asked by the recruiters on some of the work I had previously done and to provide examples of softwares I had used for documentation.

They didn’t seem satisfied with my responses somehow, and so I started probing them more on the client requirements and what was expected out of this role. Once they had run me through this, and some highly niche tools the clients were using, I was pretty convinced they were not after a Technical Writer at all, and told them that they would probably be better served if they sought professionals with a Systems Analysis background.

Instead, they reprimanded me for wasting their time, and doubted my claims of ever having worked as a Technical Writer before. I politely ended the interview, and left. The next day, the very same role was re-published on their site with the title “Systems Analyst”.

It was my first taste of how misunderstood, and ignorant the tech world was on the value technical writers bring to teams.

As Jared, a lead technical writer based in Brisbane points out “At [previous employer], they “didn’t know what a Tech Writer actually does but knew they needed one”, which should’ve been a red flag.”

The expectation gap

Scroll through any Australian job board and you’ll find technical writing roles loaded with contradictions. Employers want someone who can write with clarity and precision, but also manage the documentation pipeline, own the information architecture, build the toolchain from scratch, handle localisation, and while they’re at it, moonlight as a UX writer and a business analyst. The salary on offer? Often pitched closer to a junior writer than a senior knowledge specialist.

This misalignment isn’t just a budgeting problem; it reflects a deeper confusion about what technical writers actually do. Many hiring managers, particularly in mid-sized Australian software firms, treat documentation as an afterthought, something you bolt on before a release, rather than a discipline that runs alongside development from day one.

The result is that technical writers are brought in too late, given too little context, and then held responsible when the documentation doesn’t land well with users.

Good technical writers are, at their core, advocates for the reader. They ask the questions your engineers have stopped asking because they’re too close to the product. They identify gaps in logic, inconsistencies in terminology, and assumptions baked into interfaces. When given the space to do that work properly, they don’t just produce documents, they improve and influence the product itself. That’s a contribution that rarely appears in a performance review.

Jean, a tech writer based in Melbourne has often found this is the case. According to her, “Recruiters tend to assume you’re not a good fit if you don’t match their keywords.”

A large tech company didn’t consider me for a second interview because they assumed I wouldn’t be able to keep up with their monthly release cadence—monthly! I work in a startup environment that practices CI/CD.”

Show me the money

Another thing of concern is the lack of a strong career progression path for technical writers in Australia. Over the years, being involved in, and a part of a technical writing communities in Oceania, it is very apparent that Australian companies have limited to no knowledge of how to promote someone in the role. This very often also translates into a disappointing gap in salaries, especially when compared to professions/roles with a similar background.

What does a healthy career path look like? Writer -> Senior Writer → Lead → Manager? Principal Writer? Documentation Architect? We rarely see Principal or Lead roles actively in the job market, because again, it comes down to understanding how this progression looks like for writers. In the last 20 years that I have been employed, I can count the number of Principal or Managerial level roles come up in the market, on one hand.

If you look at the broader Australian employment landscape (aggregating data from multiple sources like PayScale, Levels.fyi, UIUXJobsBoard, Talent.com, and Paxus & Think and Grow)

• Average Australian salary ranges from $80-$100K, with a more accurate median around $74-90K. Compared to other similar roles, this is at least $20K-$25K lower to someone in a comparable role with experience.
• The Australian job market has softened slightly over the past year, with online job advertisements down 6.7% year-on-year. 
• Advertised salaries are up 3.5% year-on-year.
• The tech sector has seen salary corrections after the post-pandemic boom, with pay rises mainly concentrated in niche skillsets.

The progression is equally concerning. An early-career technical writer earning AU$70,000 reaches only AU$93,000 after 5-9 years which is a mere AU$23,000 increase despite accumulating significant domain expertise, mastering complex toolchains, and developing deep product knowledge. Meanwhile, a product manager with similar tenure can expect to earn AU$150,000+, and a UX writer often surpasses AU$100,000 well before the five-seven-year mark.

This isn’t just about market rates though, it’s about how Australian companies value the discipline. When a role demanding technical accuracy, user empathy, information architecture expertise, and cross-functional collaboration pays 30-50% less than adjacent roles, it signals a fundamental misunderstanding of what technical writers contribute.

Documentation has real, measurable value

There’s a tendency to treat documentation as a cost centre rather than a value driver, but the evidence doesn’t support that view.

According to the recently published State of Docs 2026 report, “Eighty percent of decision-makers review documentation before buying. The case that docs matter commercially is settled. What isn’t settled is whether the teams behind those docs are treating them accordingly.”

Poor documentation increases support ticket volumes, slows down onboarding, and erodes user trust in ways that are genuinely expensive. Conversely, organisations with mature documentation cultures, see reduced churn, faster developer adoption, and stronger community engagement.

For companies building APIs, developer tools, or enterprise software, documentation is often the first real interaction a potential customer has with the product, because a lot of products have no flashy user interfaces, and are often command-line only.

A confusing getting-started guide doesn’t just frustrate; it costs you the sale. Treating a technical writer as a luxury hire rather than a strategic one is a false economy. The writer who prevents a hundred support calls a month is delivering value that’s easy to quantify if anyone bothers to look.

The tools fetish

Perhaps no issue irritates experienced technical writers more than the industry’s obsession with specific tooling. Job advertisements across Australia frequently list proficiency in a particular platform: Confluence, MadCap Flare, RoboHelp, or whatever the hiring manager used at their last company, as a hard requirement, sometimes ranked above actual writing abilit, domain knowledge or the ability to extract information from technical teams.

Tools are learned; craft takes years. A writer who understands structured authoring principles, content reuse strategies, and how to design documentation for different audiences will become productive in a new tool within weeks. A writer who is fluent in every feature of MadCap Flare but can’t structure an argument or adapt their skills for a non-technical audience is not a technical writer; they’re a software operator.

The fixation on tools also reveals how little some organisations understand the docs-as-code movement, which has shifted much of modern technical writing toward lightweight markup languages like Markdown and AsciiDoc, static site generators, and version-controlled workflows that sit inside the same repositories as the code they document. A technical writer comfortable with Git, familiar with CI/CD pipelines, and capable of collaborating in a developer environment is extraordinarily valuable, and no single proprietary tool certification tells you whether someone has those skills.

When Jean was interviewing for a role,

“A large tech company didn’t consider me for a second interview because they assumed I wouldn’t be able to keep up with their monthly release cadence—monthly! I work in a startup environment that practices CI/CD.”

What team/s does a technical writer sit in?

Over the years, I’ve been a part of core technical writing teams, but also larger product, quality assurance, change management, training, and support teams.

Similarly, both Jean and Jared have been part of the Product teams at their various workplaces. It’s hard to exactly pinpoint what the best place for technical writers is, but there is some data around this in the State of Docs report.

From the State of Docs 2026 report findings on documentation team structures,

What actually drives quality and sustainability is how the team is embedded: whether writers are close enough to the product to catch what others miss, whether the organization has thought clearly about who owns what, and whether they have other writers with whom they can collaborate and share best practices.

That question of ownership is more urgent in 2026 than it’s been before. AI is compressing product cycles, which means documentation timelines compress with them. Teams without clear structure feel that pressure most acutely, and the data reflects it.

It is not uncommon in Australia to see solo technical writers who support wildly unrealistic number of teams, sometimes upto 100 people spread across 5-6 teams. That kind of ratio is not only unhealthy for the product, but also begs the question on how tech companies view the role of documentation specialists.

What can we do as technical writers?

As technical writers, we need to do better, in terms of advocating, and showing value beyond traditional documentation deliverables.

• Take every opportunity to educate, share and promote the profession, beyond your role itself. I’ve often seen a lot of tech writers get into a stasis mode once they get into a role, lacking the passion to upskill, advocate any further.
• In large companies, if you have access to any meaningful data, use it to build dashboards that shows resolved tickets, support metrics, and product satisfaction improved via documentation.
• Engage in communities outside your comfort zone, and use every opportunity to share your skills and knowledge.
• Build networks that go beyond just technical communication, and you will find supporters and champions for the profession everywhere. (I work with a Senior Manager who not only strongly advocates for good documentation, but also believes that “having a technical writer to question everything is awesome in product teams“). Look out for these folks!

Technical writers who are embedded in product teams from the beginning (intentionally), who attend standups, read pull requests, and have direct access to engineers and product managers, produce better and more complete documentation. It’s not magic; it’s just what happens when you treat a discipline seriously instead of as a compliance exercise.

Final thoughts

I strongly feel we need to almost have a “one-page” cheatsheet on all the amazing skills and value technical communication specialists bring to organisations, and also work with recruiters and organisations on amplifying these skills to fit in a modern landscape.

The Australian tech industry is maturing rapidly, and there are genuine pockets of excellence. But broadly, companies need to start hiring technical writers earlier, paying them commensurately with the complexity of the role, and resisting the urge to define the position by the tools in the job description rather than the outcomes they’re trying to achieve.

We are not exactly in a “it’s too early to tell” phase with AI anymore. Any reductions in force (around technical writing roles) associated with AI need to be strongly challenged.