Interview with Lana Brindley

Lana is a technical writer at SUSE. Her work has primarily been with open source software, and she has been writing technical documentation and leading writing teams for 12 years.

Key takeaways

  • Write whatever you can to build and show off your skills.
  • Make connections. “No matter where you are in your career, always choose at least one mentor and one mentee. There is always something you can learn, and something you can teach.”

What is the story of your career so far?

So I started out working as a general dogsbody at a very tiny startup that made RFID tracking devices. The startup failed before it got going, but I formed a close relationship with the CTO there, who recognised my writing skills and introduced me to the world of technical writing. I had always been fascinated by open source, so when I landed a tech writing job at Red Hat, it was like a dream come true for me. After six years at Red Hat, and leading a team of 13 writers, I was asked if I wanted to start a new tech writing team from scratch at Rackspace, which was an amazing experience. During that period, I was also elected to run the OpenStack documentation team, and I honestly learned more about leadership in this community setting than I ever could have in the corporate world. Unfortunately, Rackspace laid us all off in 2017 and, because of an injury that happened about the same time, I spent about a year out of work. I used that time to study my MBA, which I have just completed, and landed on my feet last year when I joined SUSE. Definitely more good luck than good management, though, I think!

Did you have a technical background prior to working at that startup?

I have always been a writer at heart, but had no idea how to turn that into a career. I enjoyed the creative aspects of programming, and I have always loved the challenge of pulling things apart to see how they worked, but I also knew I wanted to work with words somehow. So when I got to university, I did a Bachelor of Business Management with a double major of Marketing and Information Systems, which gave me a basic grounding in software development. During university, I made friends with a lot of people who were studying IT subjects, so I ended up spending a lot of my spare time in the computer lab with those people, which is where I first learned about open source as well. Later, when I discovered the field of technical writing, it felt like it was the job I had been looking for all that time.

Had you been contributing to open source projects before working for Red Hat?

No, I hadn’t. While I was familiar with the concept of Linux and open source from my university days, Red Hat was my real introduction to the community. While I was working there, I contributed to the Open/Libre Office community, and became involved with linux.conf.au (which I am still involved with), and the Open Source Developer’s Conference (which is now defunct). I also got to know various people in the open source documentation world, including Anne Gentle, who I eventually ended up working with at OpenStack. I also started working with some women in tech groups during that period, especially Girl Geek Dinners.

When you were applying for that job at Red Hat, what were you showing in terms of a portfolio?

I had put together a portfolio from my work at the RFID startup when I applied to Red Hat. It included a lot of mostly marketing material, but I also had a few technical whitepapers, and some technical specification documents. I didn’t have any end user documentation because our product never made it that far. I had taught myself how to use LaTeX while I was there, and I was quite proud to deliver my resume typeset in LaTeX and TeX. I later found out that my manager at Red Hat showed my resume around the office exclaiming about that! Sadly, while LaTeX is a truly beautiful language, I didn’t have another professional use for it after that.

Can you talk a bit about what it’s like to lead a technical writing team?

So leading a team is difficult but I find it very personally satisfying. It’s certainly not for everyone, though. I think the most important thing is what I refer to as the difference between management and leadership. I wrote fairly extensively about this after I stood down as the OpenStack PTL (program technical lead) in 2017, because I found the difference between managing a corporate team and leading a community of volunteers to be quite stark. In a corporate sense, the people on your team are there because they really have to be: you are responsible for their livelihoods, so they do what you tell them to do. In a corporate environment, if you get a bad manager (and we all have, let’s face it), you either have to find a way to move out of that team, or you have to put up with it. Community teams are completely different: bad leaders simply don’t have any followers. In a community environment, you have no way of enticing or rewarding people for doing hard work, but the hard work still needs to be done, so you have to rely on charisma, persuasion, and handing out the occasional sticker or T-shirt. It was therefore very interesting to me to be able to look at those periods with hindsight while I was studying the MBA, and be able to draw the lines between management theory and why certain things I tried as both a manager and a leader either did or didn’t work.

What advice you might have for new writers trying to break into the field, especially for those looking to contribute to open source?

For new writers starting out, my best advice would be to just start writing. You need to have something to show prospective employers, but you can create that in any number of ways. If you don’t have anything from your current work, then go and install some bit of software and write about that, even if it’s been written about a thousand times before. Also, remember that for a writer your resume is a writing sample. Make sure that you show that you can write prose as well as dot points, and be really mindful of the words you choose, and the layout and design.

As for contributing to open source, I know that documentation is often held up as a good way to get started, but I can appreciate that it’s not always easy. That said, most larger open source groups (especially those that are backed by organisations like SUSE and Red Hat) have some kind of mentoring program that can help you with your first contribution if you really don’t know where to start. And that’s probably my other big tip: no matter where you are in your career, always choose at least one mentor and one mentee. There is always something you can learn, and something you can teach.

Lana goes by loquacity on the Write the Docs Slack group, and @Loquacities on Twitter. You can find her in the #australia, #managing-writers, and #remote channels.

Glossary

dogsbody
A person who is given boring, menial tasks to do.