Technical documentation in an economic crisis is a topic that is on the agenda in many technical writing departments right now. Here is what really matters in practice, beyond marketing claims and tool promises.
When companies come under pressure, the staffing discussion always follows the same sequence. First the direct production areas are scrutinised. Then sales and marketing. And then — by the second round of cuts at the latest — technical documentation lands on the table. Often with the remark that surely it could be outsourced more cheaply to Poland, India, or Ukraine.
I consider that a mistake in reasoning. Not as a matter of principle, not across the board, but very often.
Technical documentation in an economic crisis: what counts in practice
What outsourcing really means
Outsourcing to best-cost countries (BCC) is a legitimate tool. There are tasks that lend themselves well to being outsourced because they require little context, little product knowledge, and little interface work. That should be stated honestly, rather than reflexively condemning every thought of outsourcing.
The only question is: which tasks are those really, in technical documentation?
Conversion work — transferring Word documents into XML or HTML according to clear rules — formally checking checklists for completeness, preparing standardised translation orders: all of that can be outsourced if the process is well defined and quality assurance stays in-house. These activities require care, but no deep product understanding. Saving here means saving in the right place.
But that is a very small subset of what technical writers actually do. And this is exactly where the problem begins.
What you really lose when you go too far
I keep seeing companies underestimate the scope of technical documentation because, from the outside, it is barely visible. An operating manual does not come about because someone describes a product. It comes about because someone understands how the product works, what risks it carries, what the user needs to know to operate it safely, and which legal requirements apply. That is expertise built up over years of working on projects — and it cannot be transferred to an external provider in a briefing document.
When you replace an experienced technical writer with a cheaper external solution, you first lose the person. But what you lose in the medium and long term is the institutional memory: the knowledge of your products, your standards, your terminology, your specific regulatory requirements, your customers and their language. That knowledge cannot be restored from a file server.
I remember one case — a mid-sized mechanical engineering company — that, two years after an outsourcing move, found that the externally created documentation could no longer be used for the next generation of machines. Not because it was badly written, but because the external provider did not know, and could not understand, the design decisions of the new product line, because it had not been involved during the development phase. The result: the entire documentation had to be created from scratch, at a higher cost than if the internal capacity had been preserved.
The transfer of knowledge out of the company is not an abstract danger. It is concrete, hard-to-reverse damage.
The legal dimension that is missing from the cost discussion
What irritates me most about most outsourcing discussions: the cost side is calculated precisely, the risk-coverage side is not.
In legal terms, technical documentation is part of the product. That is not stated explicitly in the law, but it follows from the Machinery Directive, the German Product Safety Act, and the Product Liability Directive. As long as the documentation is not complete and standards-compliant, a product may not ship in many industries — at least not without liability risk. An incomplete or faulty operating manual can be considered a contributing cause in an accident.
What does a product recall cost? What does a liability case cost? What does a delivery stop cost when the documentation is not CE-compliant and the product may not be moved out of the warehouse?
These figures do not appear in the spreadsheet that lists the staff costs of the technical writing department. But they should.
My experience: anyone who regards technical documentation as a pure cost factor has never quantified its contribution to risk coverage in concrete terms. Once you have calculated that through — really calculated it, including liability scenarios and delivery delays — the maths usually looks quite different.
What works instead of blind cost-cutting
There are better ways to extract efficiency from technical documentation in an economically difficult phase. Not through job cuts, but through process optimisation.
The first lever is content reuse. When the same company maintains the same warning, the same safety instruction, or the same assembly procedure separately across ten different documents, that is not surplus staff — it is process waste. A well-configured CCMS with modular authoring can reduce this effort drastically without cutting a single position.
The second lever is smart automation. AI-supported terminology checking, automated formatting rules, assisted translation preparation — these are tools that are available today and bring genuine time savings. No magic bullet, but a realistic efficiency gain of 20 to 30 % in the right areas. Anyone who tells me AI solves all documentation problems is overstating. Anyone who says AI brings nothing has not yet engaged with it seriously.
The third lever is the hybrid model: keep core tasks in-house, selectively outsource genuinely repetitive and low-context work. That requires leadership work — defining clear interfaces, a clean briefing concept, a quality-assurance procedure for external services. Anyone who does not put in that work, who simply hands tasks outside and hopes it will turn out fine, will be disappointed.
Restructure, don’t downsize
In an economic crisis, technical documentation should not shrink — it should get smarter. That is the more realistic alternative, and it is no contradiction to cost discipline, unlike an approach that reduces budget lines in the short term and produces liability risks in the medium term.
What I advise those responsible in this situation: start with an honest analysis. Where in your documentation process does inefficiency really sit? Where is work done twice because systems are not integrated? Where is something maintained manually that could be automated? And where — quite concretely — would a staff cut create a risk you would not want to explain in a liability case?
These questions are uncomfortable. But they are the right questions.
Whoever does not move with the times moves with the times anyway — that applies here too. But the way to move with the times is not to dismantle expertise. The way is the professionalisation of processes and the targeted use of technology, so that the existing know-how achieves more than before.
Further standards and industry information are available from tekom — the German professional association for technical communication.
You can find more on concrete real-world cases in our article series on Artificial Intelligence and Technical Documentation.