From Linguistics to Product Content

What 2020 meant for my career

In March 2020, as the world screeched to a halt, I was rejected at the last stage of a year-long hiring process for my dream job. It was a hard hit. I loved everything about the idea of getting that job. The position sounded fun and creative, it was in New York City, and the people I’d met during the process seemed like the perfect teammates. Most of all, I would work as a linguist.

A bit of necessary context. I had been a linguist all my life. My background is in Computational Linguistics. For years, I’d been part of a Natural Language Processing team at Google; then I’d taken up a job at a mid-sized Machine Translation startup in Lisbon, Portugal. Being a linguist in New York just sounded like such a natural, beautiful next step in my career.

Until I didn’t get the job (and I received that call on my wedding day, no less). Shit happens, I say now. Back then, it threw me into a full-blown existential crisis. I knew I wanted to go somewhere, I just didn’t know where. The INTJ in me made me sit down, lay out the problem, and all of the solutions I could come up with. But in the end, it all boiled down to a person on the brink of turning 30, wondering who she wanted to be when she grew up.

One month later, I got laid off. So those questions went from philosophical to pressing: did I want to go get that Ph.D.? Did I want to look for another linguist position? Did I want to throw my career as a linguist out of the window and finally become a photographer? These sounded like perfectly interesting solutions, and to a certain extent, viable, but none of them felt right. I was at a loss.

And then I remembered. A few months earlier, I had stumbled upon a job opening for technical writer, and I remember feeling weirdly fascinated by it. The requirements made my eyes sparkle, much to the bewilderment of the other linguists in my team — who in their right mind would want to write documentation for a living? I ended up applying, passing the challenge and being rejected after the first round of interviews. But those job requirements put a thought in the back of my mind.

Could I already be a technical writer at heart?

For better or for worse, now I had all the time in the world, and that thought resurfaced. I decided I’d take a technical writing course on Udemy. And then another. I started applying for technical writing positions, and recruiters started calling me back. I started interviewing.

I am now six months into my first job as a technical writer, and I’m having one of those how could I ever consider doing something different kind of moments.

What does a linguist know about technical writing?

As a linguist, I soon realized, I had read and written thousands of pages of what we can consider a specific form of technical content: annotation guidelines. Applied linguists in industry very often classify natural language for the purpose of improving all sorts of algorithms — think search engines, chatbots, virtual assistants, you name it. Mostly, that means classifying bits of language by describing them for what they are. Is that a noun? A preposition? A proper name? A multi-word expression? This process of labeling bits of text is called annotation.

It is not as easy as it sounds. As we know, language is not exact. It is a living, mutating creature, and as such, it doesn’t fit into clear-cut categories. It just doesn’t. But clear-cut categories are the only thing algorithms will digest. As a linguistic annotator, your job is a constant compromise between the set of categories you are allowed to apply, and the weird exceptions language constantly throws at you. The more consistent you are with yourself and your fellow annotators, the cleaner the annotated data will be in the end. Consistency is key to a well-trained algorithm.

But how to ensure consistency? So much of the cleanliness of the end result relies on the annotation guidelines I mentioned above. Having to classify human language according to badly written, unclear, or incomplete guidelines is a nightmare. Linguists are also painfully aware that writing good guidelines is difficult — no finite set of guidelines will ever account for the countless complexities of human language. Good guidelines do not try to cover the highest number of irregularities in language. Instead, good guidelines teach you how to navigate what linguists refer to as the gray areas in language where your interpretation will be required. It is amazing what clear explanations, adequate examples, and a digestible layout can achieve.

I loved writing those guidelines. I loved categorizing, simplifying, and explaining things. Again, the INTJ in me used to seize every opportunity to write a report, a presentation, an internal document, anything that needed organizing and prettifying. I would gladly take on these tasks so that my teammates could focus on things they actually liked.

What do I do now?

What is asked of a technical writer widely depends on the company or department that hires you. In my case, I’m a technical writer for a suite of products in the field of network security. Now, to say that I knew nothing about network security when I started out would be an understatement — and to say that this didn’t scare me would be an outright lie. But I was up for the challenge.

I am embedded in a product team. This is such a huge reason why I love the job. I get to think of documentation as a product in itself, and this helps me have a vision for it. For what documentation should be, for how it should serve users. And as the owner of documentation, my job is to ensure it’s effective. Here’s where my experience with guidelines comes in handy — I get to categorize, structure, explain, and simplify. Naturally, the biggest difference was and still is my lack of familiarity with the domain. While I can easily describe what an adverb is to a group of linguists, six months ago I had no idea what a DNS request even was (yes, really). But in time, knowledge has come naturally.

To me, having a vision for documentation means being conscious of what I do and who I do it for. In my view — and this applies to product content in general, I think — documentation is a constant dialogue with our users. For any given feature I explain, there are users out there reading and trusting the documentation for it. And just like poor annotation guidelines, poor documentation doesn’t help users manage the gray areas. Poor documentation leaves users wondering. They’ll be confused with the product itself, and that will translate into frustration.

The way I see it, my goal is to do everything I can to make the user’s experience with documentation seamless. I try to balance simplicity with complexity and reduce cognitive load wherever possible. Every idea I may come up with (a progress bar showing them how long until a task is completed, a tooltip showing the definition of a technical term, a chatbot asking users what they need and replying with the exact page they were looking for — hey, a girl can dream) ultimately aims at reducing the gray areas and having users go “oh, this feels familiar, everything’s under control.”

Conclusion

If you caught me off guard and asked me what do you do?, I’d likely still reply oh, I’m a linguist, and then realize the mistake. But at the end of the day, I’m starting to think it may not be that big of a mistake. In my very personal experience, working on product content is the perfect realization of working as a linguist in a company. I can hardly think of another position that would suit me better, that would put my expertise at better use, and ultimately, that would be more fun than what I’m doing today.

Here’s to 2020, for showing me the path.