Interview with Celeste Horgan¶
Celeste is a Canadian technical writer based in Berlin and has been writing documentation related to ecommerce for 4 years.
Key takeaways¶
- Technical writing is a job with global demand.
- Don’t forget the technical stack when creating documentation.
How did you find technical writing?
I kind of stumbled into technical writing. My degree was actually in interaction design or user experience design. But I was always very focused on how we were communicating the projects that we were designing when I was in school. But I kind of got to a point in second or third year where I looked at my career and I thought, “I don’t know if I want to be a designer full time.” I really enjoy user experience. I enjoy thinking about things from the perspective of the user, but I didn’t necessarily enjoy the design part of it. So when I was looking for co-op positions, I saw BlackBerry, the mobile phone company, had an application for a technical writer. So I clicked on the job description. It was kind of about describing code and helping people use things. And I thought, “Oh, I think I could probably do this.” When you’re in design school, you typically end up writing briefs or documents based on your designs as well as actually producing the design. So I sent in a few of my design documents as samples. I got an interview, and I more or less learned on the job. I was there for about eight months out in Waterloo, Ontario, working with the BlackBerry team on their Java SDK.
I was one of 600 co-ops they took in that semester. Because they took in so many, they had a pretty rigorous training program in every department. I was one of about 5 or 10 in a 40 person technical writing department. They put us all through a training program where they taught us what DITA was. They taught us about single source authoring. That’s kind of where I started. After I graduated university, I worked as a web designer for a year or two, but it was mostly stubbornness on my part. Because I had done this degree I was like, “No, I’m gonna do it! I’m gonna go be a designer!” But I really didn’t like it. My initial thoughts when I was in school were correct. It just wasn’t that interesting to me. So I switched back into technical writing in 2016, and that’s what I’ve been doing ever since. I’m at my second job now as a technical writer. Since then I’ve worked at a company called Elastic Path, in Vancouver. And now I’m in Berlin at a company called commercetools.
What was it like searching for jobs outside of Canada?
You know what? It was almost comically easy. I just dropped my resume in people’s inboxes, using the forms on their websites. I wasn’t going out of my way to network or anything, and there was a surprising amount of interest. I was also applying quite globally. I applied for a few places in the U.S. and got responses. I think technical writing is kind of a funny of job in that I think technical writers in organizations often feel very undervalued. I’ve done quite a bit of interviewing. And it’s so funny, because you see so many people who just don’t seem to have a lot of self-confidence or passion. So if you’re even a little bit passionate or a little opinionated, or you kind of just got something going on, you stand out in an interview so quickly. And people are willing to take you abroad for that, which is really cool.
What is it like working outside of your home country as a technical writer?
Yeah, it’s interesting as a writer especially. When you’re in North America, in Canada and the United States, the people that you work with are native speakers. So when you’re having a conversation about ensuring that a sentence communicates the essence of what was implemented technically, you are quite literally both speaking the same language. If you as a writer decided to reword something using simpler words, maybe using present tense, your subject matter expert or developer that you’re working with knows enough English to say, “No, that’s not what I meant at all.” So it’s a a high level conversation.
Commercetools is a very diverse company. For most of the people that I work with English is not their first language. It might not be their second language. It’s sometimes their third, fourth, or fifth language; because that’s how Europe works. So when I work with developers, if they’re writing the first draft of something in particular, it takes a lot more work to get it to the state that I would be comfortable releasing it in. I have to be a lot more forward in how I speak to and question about a feature, because I know that they might not be able to correct me if I misinterpret something that they say. So there’s a lot more responsibility on me. I would actually say for anybody else that’s looking to move abroad that there’s a lot of demand, particularly in Berlin. It’s not a bad place to be a technical writer, because there’s extra value on you. You’re not only a technical writer, not only the person taking care of documentation that developers don’t want to write; you’re the person doing that with the authoritative voice of a native English speaker.
What advice would you give to new or aspiring tech writers in the community?
The thing that I would say to a new writer in the community, or to any new writer in general, is to not to ignore your tech stack or your user experience. I meet a lot of writers when I’m interviewing, and all they want to do is write documentation. And I admire that focus, but that’s not me. That is not how I approach my job. I admire people who just want to sit down and write, and they’re super happy about it. But I think documentation is so overlooked in so many companies. It is low priority for a lot of product teams, and it’s not something a lot of people like to do. But it is a really key component of a developer’s or a customer’s experience with the product, because they come to it when they’re stuck. They come to it when they’re at the low point in their journey with the product, and it’s your job to take them higher.
It’s not just the content that matters in that regard. It’s also how people perceive things visually that has an effect on how they feel about things. So as much as we would like to believe that good content saves the day every single time, we have in our minds an idea of what a professional looking layout looks like. If you’re displaying your documentation on something that isn’t a professional looking layout, that changes people’s perception of what they’re reading. It changes the emotions around it. And they may not take what you’re writing as seriously.
And I would say don’t ignore the tech stack, because if you want to foster collaboration, you need to have a tech stack that other people in your company want to contribute to. For example, for us, our current static site generator is Jekyll. It’s written in Ruby, and it’s nice. It completely does the job we need it to do. But we don’t have any Ruby developers in our company. That means if anybody wants to make any changes or additions to the website beyond just text updates, they have to learn Ruby. And that’s just not going to happen. You own the entire process, and your tech stack affects your release velocity. More and more companies are trying to go for continuous delivery cycle type release for software. And you can’t let documentation be the thing that slows down release velocity, and the tech stack will 100% of the time slow down your release velocity if you don’t pay attention to it.
Celeste goes by Celeste on the Write the Docs Slack group. You can find her in the #career-advice and #docs-as-code channels.
