Today we talk to Pablo de Eguileor, technical communicator, an unknown profession in Spain, which is the world of manuals. In this talk, Pablo tells us the keys to the drafting of these documents that are as unnoticed as they are essential.
How does someone become a technical writer?
I came to this, like many others, not directly, I did not train for it. I am an engineer by training. I studied in Germany and there they put a lot of emphasis on writing documents well during my studies, and when I came back to Spain, I found this profession. There was a demand here nearby, in Vitoria-Gazteiz, in a Mercedes factory, for writers for vehicles, and that’s where I started, around 1997. From then until now I have worked in this world of content creation both for manufacturers of physical products and for companies that make digital products.
Is having good documentation a technical or administrative requirement, or is it simply necessary to communicate well to the customer what our product or service does?
In our world, a technical writer would always like to make his ideal manual perfect, but it all depends on the resources at his disposal and the product, in what range or at what level it is placed in his sector.
That is, if you are offering a product that gives you a lot of service, whose end users are demanding because they have paid for a quality product, then the accompanying content, including technical content, must also be of quality, but this is not usually the case.
In general, these high-level companies tend to be few, there are some, even here in the Spanish market, but there are also many companies that without having a very high demand from the end user to have a high quality content, they do have the obligation to deliver technical documentation, and this is especially in physical products.
Felipe Rebollo and Pablo de Eguileor.
When does the technical writer enter the projects?
There is a legal compliance obligation for the safety of people in the handling of the product. And handling the product is not only operating it, that is, it is also installing it, if it has to be installed, transporting it before, commissioning, operation, as I said… but also all the maintenance operations. All the maintenance activity also affects the safety of the users who are handling that product, and that safety aspect is what the law obliges the residual risks, to give an instruction for safe handling. In many cases it is thought that in order to improve a documentation it is necessary to go to new formats or very sexy issues, very sexy content, and this is not usually the main case that I find when I have to do consulting work.
Do large companies have the technical writer’s work more in mind or is it something that is left to the last minute?
The biggest pain is usually precisely the one you mentioned, which is that there is no time, there is no time to get it out because it is left to the end. In advanced companies, which have the figure of the technical writer within, it is first a question of organization, that there are people who can dedicate a high degree of their time to create content or coordinate the creation of internal content, so that when the project begins, at a relatively early stage, they already begin to program the development of content.
It is not left to the last minute. You start to see how it works, because in many projects the milestones are eaten up, they are delayed and in the end the spectacle can be excellent: we have to produce the manual in six languages by yesterday, that is a classic, and obviously there are companies that can suffer penalties for this, because they are obliged to bring the product to the market now. And if the documentation does not accompany it, the clients can penalize them by contract, I have cases of that type.
If we are talking about companies with a large volume of publications and, in addition, their technical publications are quite demanding, then there is probably an easily identifiable need for one or more people who can be fully dedicated to managing technical publications.
In the case of medium-sized or small companies, it is usually said that between 1 and 3% of the time, depending on the value of the technical documentation, should be devoted to these publications. In an industrial company that benchmark may even be higher, but that is a benchmark. So, if there is a company of 100 people, at least 1% of the time dedicated to the company should be for these issues.
What three pieces of advice would you give to an SME that has to write a technical document?
The first is to think about the end user, to understand what the end user of our documentation is like. Or the different end users, because there can be many. The product life cycle has different stages and different users are going to need content. I recommend getting out of our product, which is what permeates the day-to-day in the company, which is product, product, product, product, and put ourselves in the user’s shoes, that would be a question.
Another would be to have a minimum writing guide, a set of rules, to work to have an internal agreement on what deliverables we are going to do, how we are going to structure them… even at different levels, not only chapters, but also how we want to write the contents, that is an investment in the future.
Finally, to have training, which is what is lacking. This is a discipline that already exists in several countries such as the United States and Germany, where it is already established. These are already mature markets and there is academic training. What we have worked on at Isten has been to create a small academy to provide basic training in the Spanish-speaking world. You have to know the discipline and, based on that, be prepared to advance and improve. That would be the third leg.
