Meet the writers in tech
By: Alexandra Gifuni
Tags: Careers, Writing, Technology, UX, Communication

The industry’s dark horses formally introduce themselves.

The tech industry has become a disruptive force in every aspect of our lives. Almost all modern work relies on at least one tool that was the brainchild of some Silicon Valley enterprise. It’s even in our homes. “Smart” has become this qualifier we place before anything that has been graced by tech. Televisions, refrigerators, cars, even toasters can be “smart”. With this omnipresence of tech, there has emerged a sort of collective allegory that exists around who makes up a tech company. We imagine these companies as being founded by either an innovator or a tech genius (sometimes both) who has a disruptive idea and manages to develop it into a huge enterprise. We imagine rows of developers using SCRUM boards to track their progress. We imagine designers hunched over their MacBooks, working on the UX. We imagine support people typing furiously as they reply to user questions. But what very few people (at least in my experience) imagine, is writers. Maybe it’s the fact that the industry is so dev-centric, or maybe we were just told too often that writing does not lead to a “real” career, but it seems a lot of people don’t know how many jobs there are for writers in tech. It shouldn’t be surprising, there is writing involved in each aspect of a product lifecycle. From planning, to design, to development, to delivery. Writers don’t just happen to exist in this space, the industry needs them.

It’s time to pull the curtain, and talk to the writers in tech.*

Quinn Mason | Content Writer, Marketing

Interviewer: How exactly did you get into content writing?

Quinn: I kind of fell into it by accident — a happy accident, I guess you could say. I went to school and got a degree in English. And at the time I didn’t know exactly what I wanted to do with that, but I did know I wanted to travel. So, after I graduated, I started looking for freelance work. And as it turned out, content writing is one of the easiest jobs you can do remotely. I started working on little assignments here and there and realized that I liked it. I got to write about a whole bunch of different topics. And then, just kind of got more and more involved and wound up in writing about tech full-time.

Interesting. So, how have you found this transition from freelance to working a full-time job at a tech company?

It’s really great because there’s so much more interaction instead of being in your own silo. When you’re doing research on your own, then you might not even get that much constructive feedback or criticism. Whereas working as an in-house content writer, you get to actually talk to people in the different departments. So you get to talk to the Devs, and the product team, and sales, and you’re working with a lot of different people. It’s more of a collaborative process.

The other side that I really enjoy is getting to track and see the impact of what I’m writing. When you’re freelancing, you’re just sending your article back to someone — you don’t get to know how it’s performing. When you’re working full time at one place and you have access to all those analytics, what’s interesting to me is figuring out what works well with the piece, how to make it better, how to be continually optimizing things. And you can actually track the impact that your writing is having in terms of moving people down the funnel or getting them to take a desired action. Which is pretty cool, that something you write can result in actual, tangible actions.

Two questions to follow up on that… What metrics are most important to you in terms of what you track? And how do you assess what needs to change in a piece to improve it?

There’s some metrics that I track more for the writing and the piece itself, so in terms of page views and the amount of time that someone spent on the page. Did they actually read it through until the end? Were they losing interest somewhere near the beginning?

And then, as a marketing writer, a lot of your objectives — actually all of your objectives — have to do with working towards goals that are bigger than one piece of content. So, that’s more metrics around questions like: Did this piece of writing convert? As in, did it get someone to click through to another piece of content, or even a product page? Did it alert them to a problem, as well as possible solutions they weren’t aware of before? Now they’re moving down the funnel, they’re becoming educated and aware at the same time as, hopefully, they’re enjoying what they’re reading, and finding the answers that they are looking for.

And then what about in terms of optimizing?

And then, in terms of optimizing…I think part of it has to do with if you’re coming from a purely journalistic or academic writing background into digital writing. There’s just a few best practices that are different. And it goes into psychology of the user, or in this case the reader. People want to be able to find what they’re looking for fast. They tend to scan more than read very closely. So, you need to think about what’s going to help them find what they’re looking for: shorter sentences, lots of white space, putting in different jump links so they can skip further down the page to find exactly what they want. You really want to be thinking about how to make it ‘snackable’, more easily consumable.

And then also staying up to date on what search engines are up to. What is best practice in Google’s eyes? How can I be continually SEO optimizing things? Part of optimizing is just keeping things up to date — especially in technology, where things change so quickly. So making sure that facts are still correct, that everything is still as relevant as it can possibly be.

So we’ve been talking a lot about what goes into the job. What about a typical day for you? What does that look like?

A typical day is a nice mix of collaborating — brainstorming ideas with other people — and doing work alone, which I mentioned before was a big difference between freelance and full time. It might be a meeting with my PO (product owner), our web designer, and our web developer to check in on a marketing campaign we’re running. Depending what projects I’m working on, I might also meet with a product marketer to explain the messaging and value props. Or maybe someone from the product team will update me on what’s next on up the product roadmap, and then explain those new features. So a mix of meetings where I’m getting expertise from other people, where I’m learning.

And then in the times when I’m working alone, I sort of take everything I learned through my own research and through talking to other people, and I synthesize everything into a cohesive end product: a piece of content that hopefully helps the reader.

Very cool. So let’s switch gears a bit. What’s one of the biggest challenges in your role?

I guess one of the biggest challenges is just being able to admit that there’s so much that I don’t know. You can do keyword research, you can talk to the product team — there’s things you can do to sort of try and guess what your audience wants, but I think that it’s crucial to actually do user research and try and talk to your audience. Go talk to subject matter experts who have more expertise than you and let them tell the story through quotes within your piece. So acknowledging that even with all of the research I can do online on my own, it will never be as good as what I can learn from actual people.

What would you recommend for someone going into this role?

I would recommend talking to as many people as you can, getting other viewpoints. Again, interviewing subject matter experts, not being afraid to ask questions. Because I think that writers are so used to being able to do things on their own and take pride in that independence. Don’t be afraid to reach out, talk to other people.

Also, understand that the intent is different with marketing writing than if you’re writing an academic or purely journalistic piece. The have different end goals.

And stay curious. Because one of the best things about this job is that you get to learn new things every day. When I try to explain content writing to friends who don’t know what I do, I say that my job is to explain really technical, complex topics in a way that makes sense. When you can actually sort out this puzzle in your head and understand how it works, that’s a really cool moment. That moment where everything finally clicks.

Probably also stay interesting.

Yes, stay interesting as well. But yeah, I think that’s it.

Victor Millette | Technical Writer, Technical Support

Interviewer: Could you explain a little bit what a Technical Writer is?

Victor: Mainly what I do is write the user-facing technical content for the various products we have. It can be instructions or technical specifications. I basically uncomplicate things for our users.

Okay. And how did you get into technical writing?

I come from a customer service background and I have many years of customer service experience. The last three years was working as a Support Agent for ShareGate, the division of GSoft I write the technical content for, and the three years before that was working as a customer service agent for a bank.

And I don’t know, I was always solution oriented and I was getting tired of answering the same things over and over again.

At some point, over three years ago, ShareGate brought in Alexandra, who’s now our Technical Content Manager, as a Technical Writer.

At first Alexandra was mandated to work with the Devs, but after a while she became part of the Technical Support Team.

I then realized that she was very open-minded about us making suggestions, and I began constantly communicating new ideas for the product’s documentation.

Customers tend to believe something that’s written in the documentation more easily than something a support agent tells them.

Sometimes when I would be on a call, it would be so much more efficient if I could tell them, “Hey, go in the documentation and check so and so article. It has all the answers you’re looking for and more.”

It’s a good thing for the customers because they have everything they need, and a good thing for support, because it keeps these calls short and more clients can be helped.

That’s true. So, you came from the Support side where you were actually talking with the customers on the phone every day answering tickets. Having switched into the technical writing side of it after, do you think that there’s any specific skills that you brought with you from Support that you find really useful in your day to day job now?

Absolutely. My knowledge of the product, being solution oriented for so long, and my understanding of our users help me figure out the best way to write concise articles to guide our customers.

And what’s been your biggest challenge since you became a Technical Writer?

The biggest thing that I had to adapt to was that the concept of productivity was so different.

Before I could write like, I don’t know, thirty more or less complex emails in a day. Now, it’s a good day if I can write or improve three articles.

It’s a very good day when you create three articles?

Yah. Communicating with customers in Tech Support, I could give them broad guidelines to help them find the cause or solution to their issues or concerns. There was a lot of requests and I was constantly engaged in my work.

With technical writing I have to make sure what I write down is accurate so I end up having to fetch information, run many tests, and consult subject matter experts until it makes sense for me and what I would imagine our customers need. I also have to pay more attention to my grammar and stay concise with my writing.

And how would you validate those things day to day? What other departments are you working with to make sure that what you’re writing is accurate?

The main one is Tech Support. I know the people in the Support team who like working on stuff like this, so I really have fun bringing those challenges to them.

I also use my own judgment a lot because I know the product and I know what works and what doesn’t for the customer, so that helps.

I also talk to the Devs to confirm the inner workings of the apps.

We have an open Slack channel for each product with a bunch of different people within the company than can answer our questions.

Okay. And what would you recommend for someone else that was interested in becoming a Technical Writer?

Be curious, open-minded, and patient.

If you’re from a Support background like I am, try to realize how important documentation is, and how awesome a tool it can be for yourself and your customers.

If you realize how powerful good documentation is, try it!

Get involved. Try to talk to your friendly neighborhood Technical Writer if you can, and yeah, try to write an article that solves a recurring problem your customers face.

If you could go back and tell yourself when you were just starting out as a Technical Writer one thing that you just had no idea then but that would’ve really helped you, maybe something that surprised you about the job or a best practice that you figured out on your own since, what would that advice be?

Read books on writing. Some of the best writers out there will teach you not to worry too much about the stiff essay structures you learned in school and how anyone can create amazing pieces of content. I particularly enjoyed Everybody Writes: Your Go-To Guide to Creating Ridiculously Good Content by Ann Handley and On Writing: A Memoir of the Craft by Stephen King. When you are from a support background like me, these reads can definitely help you build your confidence.

Very good. Thank you, Victor.

Thank you.

Alexandra Gifuni | Technical Content Manager, Technical Support

Interviewer: How did you get into this role?

Alexandra: What a long story that is. Do I start at the beginning?

Wait, let’s maybe, say, explain the role first.

Oh, explain the role?

Yeah, I think that might be a better segue. Could you explain to me what exactly a Technical Content Manager is?

Sure. Technical Content Manager can be called by a different name depending on the company. In some companies, it’s called a Technical Content Strategist or a Technical Content Architect. Essentially, I’m the person who plans, designs, and assigns everything that goes into the customer-facing technical content. It is a lot of strategizing and making decisions on what the priorities are. I get the final say on what goes into the technical content. Out of what makes the cut, I decide on the priority of the tasks — so what gets written first, versus what we put on the back burner. And I say “I decide”, which is true, but I wouldn’t get anywhere without the input from the Tech Support team and the help of my Technical Writer, Victor, really. You can’t really lead effectively if you don’t listen. I also still do a lot of writing. We are only two in the team, and when there’s a deadline, we do what we need to and make it happen.

Okay, and how did you get into this?

So, I mean, years ago, when I was just a university student, I was graduating with a B.A., double majoring in English Literature and Philosophy. And the joke when you have an English Literature and Philosophy degree is that you’re going to end up working at McDonald’s. We all know the joke and it’s not funny. What wound up happening is that I went through a little existential crisis before graduating, because I really thought I wasn’t going to get a job. But then I applied for a position called “Technical Editor” at a software company. For that role, that meant I was going to be working under a Senior Technical Writer, and just editing the content that they put out. I wasn’t going to be writing any content. I got the job, and I really wound up loving it. And then I got promoted to Technical Writer, and actually began writing technical content. I worked there for four-and-a-half years before getting recruited by GSoft. I was the first-ever Technical Writer here at GSoft.

So, I was basically trailblazing the role here, and they really started to understand the importance technical writing has, especially for Technical Support, meaning as part of the customer service and for self-service experience. The work kept building, and about two years into my time here, we knew it was time to hire another Technical Writer. That’s when my role evolved to Technical Content Manager.

Great. So, what does your job look like day-to-day, then?

So what winds up happening is that I come into work and I talk with the Technical Writer, Victor, about what we are prioritizing for the day. We have a backlog of tasks. The way that backlog builds up is through customer feedback or people assigning us tasks internally. Usually, it’s the Tech Support team, because they’re the ones who are working closely with the customers, and they’re the ones who are getting repeat questions from the customers. So, they wind up flagging when something’s important to the customers, or when there’s a question customers keep asking that could be useful to answer in the online content. We look at those tasks and assign them a priority in the backlog, and decide what gets done first. And then there’s other types of tasks that always get the highest priority. We’re working with a SaaS product so there’s multiple product releases. Whenever there’s a new release, there’s going to be new features in the product, and those new features often need new content to explain their functionality. And we need to also anticipate the kind of questions customers will have about those features.

So, for instance, if there’s a feature that requires a customer to login with their personal info, then we know they are going to be concerned with how secure their information is. So through customer empathy we anticipate those kinds of questions, and answer them in the online content. Because the way we always see it is that if the customer is asking Tech Support a question that could have been answered in the online content, we failed somewhere. We don’t want that to happen.

Going off of that, I know that you are really great at tracking all sorts of metrics to track your impact. What are some things that you track? What are some indicators for you that you’re being successful?

I mean, not trying to do product placement, but we use a product called Hotjar. And that tracks basic feedback in the documentation. So, whenever a customer finishes reading any article on our online help center, they can “vote up” or they can “vote down” the article. Once they do, a pop-up prompts for extra feedback. So, what winds up happening is that whenever there’s a vote down, we’ll get a feedback saying maybe, oh, they didn’t find “step three” clear. And also positive feedback as well, whenever there’s a vote up, surprisingly they’ll let us know why they liked the article. And that’s really awesome to see. Obviously, it feels good. They can also offer general feedback on the help center experience as a whole.

There’s another metric that’s a view-to-ticket ratio, that lets us know per views of the help center, how many customers opened a ticket with a support agent. Right now for every five views of the help center, one customer opens a support ticket — it’s very good. It’s actually improved since last year.

That’s the question I was going to ask you. How you judge the success in relation to the support team. So, I think that’s great. What is your biggest challenge or some of your biggest challenges?

One of our biggest challenges we have, especially as the company grows, is basically navigating the waters of well-intentioned people who will try to assign us tasks that don’t have to do with technical writing. A lot of people never worked with a Technical Content team and don’t understand that what we’re doing is specifically for the help content, for the customers, for the goal of self-service. So, we’ll wind up getting assigned tasks that are more marketing-oriented, or perhaps more in line with what Janice does, which is, doing the actual writing for the UX. And then we’ll have to kind of poke back and say, “No, that’s not our team’s responsibility. We have a large enough backlog with all these other tasks that we’re managing.” We’re already busy, and it’s unfortunately time-consuming to have to deal with requests like that. But anyway, I still do always take the time needed to explain it because it’s important to make people fully understand. Best to explain it once and it’s not a repeat problem.

So, what are some of the main differentiators between marketing writing and technical writing?

Well, I’m not in marketing writing so I can only answer so far, but from what I’ve seen, a lot of it is letting the customer know the value of the product. You are telling the customer why they should purchase the product, what makes it good. And you’re allowed to put personality into it, you’re allowed to be quirky, even though you need to stay on brand. With technical writing, it’s very dry. It’s to the point. It’s concise. It’s simple. You’re letting the customer know how the product works, what a feature does, how it benefits them at the most, and that’s where it ends.

I mean, imagine you’re trying to find help on anything. Imagine your iPhone stops working and you’re looking up “Why did my iPhone stop working?” If you’re going to get this article that starts off with, “Oh darn, your iPhone stopped working suddenly? Let me tell you about the time that happened to me…”, you’re going to be like, “Are you kidding me?!” You just want it to be very simple, to the point, a “This is how you fix this.” article.

It’s like those food blogs that tell the whole story of the person’s life before you get to the recipe.

Yeah, those are the worst!

Oh, drives me nuts.

Why do they do that?

Last question. What do you recommend for someone that would be interested in going into this type of role?

I would recommend to them to just go for it. Just try it out. I know that speaking for myself, when I hire a Technical Writer, I just look for any kind of writing experience. When I hired Victor, he was working as a support agent before, and I was able to look at his emails to customers and see that he had a really good mastery over the English language. The way he wrote his responses were very much in line with the way you would write a technical article. He had all the right impulses. So that was such a good indicator. Like, you don’t need to actually have studied English or be a Technical Editor, a Technical Writer before. You just need to show that you have the impulses to do the job and, of course, the mastery of the English language that’s required.

Sounds great. Thank you so much.

Thank you.

Janice LaGiorgia | UX Writer, Product Design

Interviewer: How did you get into this?

Janice: My career path is actually quite eclectic. Actually, most of the UX Writers I know have very interesting backgrounds and you’d never think they would have ended up in UX writing. And even then, what really defines UX writing? It’s a growing field. Every one of us is defining it as we go, with all of our eclecticism.

I started off studying Psychology in University where I spent a lot of time doing research, and I found that very exciting — to delve into the human psyche and understand why people do what they do. And in some ways, I do inject that in my day-to-day. For example, when designing an experience, it’s important to understand how humans process information and how much information someone can handle at once. So, what I learned in my undergrad serves me well.

I also completed a diploma in marketing, to diversify my knowledge. And even then, I never really thought UX writing was for me until it landed in my inbox one day, when someone in my network reached out for a position at GSoft.

Before GSoft, though, I explored technical writing and account management. I also began exploring the world of design five years ago, and I completely fell in love with it, despite not directly working in the field until three years ago.

So, yeah, I became a full-time UX Writer and content designer three years ago, when there was barely anything on the topic. Most content strategists and UX Writers I knew of were operating in the shadows and no one was really writing about it yet. It wasn’t publicized, so there was barely anything. I learned a lot through experience, research, and my community.

As the months went on, I realized how crucial design knowledge is for me and others in this role, so I spent time completing trainings in UX and in behavioral design. These helped me level up, although my true learnings were still mostly happening on the job.

To build off of that, because you said that UX writing is so new and so many people don’t really understand what it is, how would you explain your job to someone, and what a typical day looks like?

So, normally, my catchphrase is, “I’m a designer of words.” It means so many things. I break it down in two parts. Keep in mind that I’m a one-person team here. So, first, there’s the UX (user experience) stage, or the actual content design. During this stage, I’ll find myself wireframing an experience along with UX designers, stamping how you’ll present information, so what the information architecture is, but also your content architecture and the terminology that needs to be define. This is where defining your taxonomy is key. At the UX stage you’re building the foundations for your experience. And then, there’s the other side of it, which is the UI (user interface) stage, which is more so about bringing it all together into its visual interface. This is where I add in the voice and tone. So, I take my functional copy, that was generated during the wireframing process, and I plug in our software’s personality to create delightful conversations throughout the experience.

Now, keep in mind that UX writing is not the sexiest thing in the world. We often say, between ourselves as UX Writers, that we are “boring” writers because we repeat terms. Our content needs to be accessible and understood by everyone. It needs to be very simple, simple and powerful, and employ our customers’ terms. We do this because customers are more able to relate to us and our software if we speak in their terms. So, I tend to repeat a lot, and it’s completely fine. After that, all of my content goes through a QA process, to ensure that my standards are all checked.

It seems like maybe the marker of really great UX writing would be invisible and so much of what’s interesting is happening on the back end. Like, you’re talking about the psychology, and the behavior, and all the thought that goes into creating something that should be seamless. Is that kind of how you see it?

Yeah, totally. The way I see it, the software or the product is what stands in between me that’s writing the copy, as well as the designers that are designing with me, and the person using the software. So, I put a lot of effort into designing software conversations that feel human. Software will never replace humans, in my opinion, but you can definitely approximate human conversation. I’ve got a few tricks up my sleeve!

So you were telling me about how you see your job, about you in between the user and…

Right. Right. I think that was it. I was talking about products being like the middlemen between the people building it and the people using it.

Well, let’s maybe talk about you being the middlemen between the people building them because Dave mentioned designers.

Ah, yeah. That’s important.

You’ve mentioned a few different groups. Who do you interact with on a daily basis?

I interact with many people and many teams, so I sometimes say that although I have assigned tasks, I seem to be responsible for nothing and everything at the same time. What I mean here is that the content I produce is a result of many peoples’ collective intelligence, end-user feedback, and design reviews with my peers. It’s rare that I write anything on my own, in a silo. It’s important that I sample expertise from Technical Writers I work with, from Marketing Content Writers, from Product Owners, from Product Marketers. So many people. So, it’s very important that UX Writers — and one-person teams for that matter — have the ability to hold their ground, are able to communicate with people, and be held accountable. There’s definitely an interpersonal component to our work that’s non-negotiable and very important for success and growth in this role. So yes, I work with everyone. I work more closely with designers as they’re my immediate team. But it’s important that I work with everyone and that I understand everyone’s needs so I can relay things appropriately. And sometimes it’s a headache to work with that many people, but I wouldn’t have it any other way.

So going off with that, in terms of your biggest challenges, it sounds like that might be one of them, interpersonal relationships. Are there any other challenges?

Yes, a very omnipresent challenge, which is writing for the end-user. It’s important to test absolutely everything at the wireframe level and even at the prototype level, and then afterwards as you ensure the scalability of your content. This is constantly a challenge for me, and it keeps me on my toes. It’s so easy to write something in a silo with everyone designing the experience. Testing our work is a challenge because you need to find the people, you need to make the time, you need to be ready to kill your darling and start from scratch. It takes maturity. So, this is always on my radar.

So if you’re testing everything that you’re doing, how do you judge whether something is working or something’s not working?

I mean, ideally, we’ll test as we’re building the experience or improving it. We do have success criteria there. Afterwards, when reviewing experiences and perhaps performing content audits, you can return to your end-users and see if you’re still on the right path. As a general rule, I abide by what Socrates said: “I am wise because I know that I know nothing.” This mindset is crucial because products are constantly evolving and so are your users. And as UX Writers, we are not writing for ourselves. We are writing for the end-user. So if you want to be poetic and creative, this is not the place to be, but you can be that person elsewhere and that’s what I do outside of work.

You addressed this a bit before. So what do you recommend for someone going into this role? You mentioned the interpersonal skills, being able to stand your ground. Was there anything else that you’d recommend if someone was interested in becoming a UX Writer?

There’s a lot that you can learn on the job — including design acumen. When I look to hire someone on my team, I mostly look for people that have writing backgrounds because that’s a bit more difficult to teach over time, as opposed to UX skills. If someone has solid copywriting experience or seems to have a propensity towards writing well or understanding personas and their readers, it’s easier to hire someone at that stage and teach them the UX side of things and how the product ecosystem works. Ideally, some experience working in a software or SaaS company is very important. Honestly, our field is so eclectic. Like, you could be someone who’s done screenwriting and be a great candidate because you’re able to write from someone’s point of view and you understand character development, which is also very important. So if you want to get hired as a UX Writer, do your research, let your work speak for itself, and convince me!

Sounds good. Thank you.

*The interview questions were asked by a third party.