Technical Writing Chat with Nathan Driver

This is the second interview in Technical Writing Chats, a series where I speak with technical writers about their day-to-day role and how they got started in their career. Today’s interview is with Nathan Driver, a Technical Writer for the UK Government Digital Services team. I sincerely hope you enjoy!

Can you tell me a bit about yourself and what role you are in now?

I’m a technical writer at Government Digital Service (GDS) in the UK government. Within GDS, I work on GOV.UK Pay, a platform that helps government services of any size take payments from members of the public. I write the documentation that developers in government services use to integrate with GOV.UK Pay’s API.

What is the story behind how you became a technical writer? What appealed to you most about technical writing as a career path?

I studied English at university and sleepwalked into being an English teacher at GCSE and A-level. I taught for 5 years and, as amazing as the good days were, there were fewer and fewer good days as time passed. Teaching is hard!

I’d always been into tech growing up but I’d only really excelled in English at school, so I wrote a career in tech. I entered teaching without much thought so, after I burnt myself out in teaching, I had to have the “What do I want to be when I grow up!?” conversations as a dusty old 28 year old. I loved tech and was good at English, so technical writing was a bit of a Goldilocks discipline.

I had some blind luck that helped me break in to tech writing. I found a technical writer, Georgie Jones, in my area that had previously been an English teacher. I messaged her, her company was recruiting, and my application was successful. The job itself wasn’t amazing, but Georgie built a great technical writing team that has gone on to work at some amazing companies. I owe Georgie and that team a lot!

What does the average day look like in your role? How is your time split between writing and non-writing tasks (i.e. mentorship, coordinating teams and projects, editing)?

I’d say 75% of an average day is taken up with non-writing tasks.

I usually start by checking Slack and my emails to see if any new work has arrived. I’ll immediately tackle any small bits of work.

Next is stand up with my development team, where I give updates on my work and support the team’s work if they need me.

Then I’ll start gathering information. If I’m working on something specific, I’ll pair up with a subject matter expert (SME) to get whatever I need to write the docs. If I don’t have something specific to work on, I try to better understand my users through feedback, research, and interviews. Once I have all that information, I can start outlining and writing my documentation.

Most days also involve reviewing content from other people at GDS, usually documentation from other technical writers. I also work closely with our product and delivery management team on communications with services.

I also like to contribute to our API design when I can. Typically this involves working with developers to name new endpoints, parameters, or attributes in our API. I think this is a really undervalued and underused skill that tech writers have. We know the APIs well and we’re great with words - it’s far better to involve us early in the API design process and avoid bizarre API naming conventions!

How do you work with other internal stakeholders in your organisation – both people on your team and outwith your team – on technical writing projects?

This varies depending on who I’m working with and their preferred way of working. A lot of people in GDS have a ‘Manual of Me’ in their Slack profile, which can be really useful. These manuals outline how that person works best, whether they prefer to jump on calls, exchange DMs, or leave comments on a document. Making sure that the person I’m working with is comfortable and able to contribute to the best of their ability is really important to me.

Beyond that, we have a great culture of working out in the open. All of our products are hosted on public GitHub repos where it’s possible (here’s the GOV.UK Pay documentation), and we have fortnightly show and tells at team, departmental, and organisational levels. We also have lots of show and tells within disciplines, so I get to see what other technical writers and content designers are working on and share good practice.

UK Government has extensive style guides for use in web development, accessibility, and other technical areas. Can you tell me more about the style guides for technical writing and how they influence your work at GDS?

Technical writers at GDS follow 2 style guides:

• the all-purpose GDS style guide that informs all written content on GOV.UK
• the technical content style guide that covers more niche topics encountered when writing for technical users

I can’t express enough how important it is to have rigorous, extensive style guides. They are records of years of style decisions, referees in debates about boring minutiae, and a North Star for new writers in an organisation. Having such a comprehensive style guide when I started at GDS meant that I wasn’t just writing docs based on vibes and hope - I had an anchor to base everything around.

Style guides are a great defuser, too. Feedback can feel personal and, if someone isn’t used to it, they can feel attacked. Style guides can take the heat out of feedback by giving the reviewer something to point to and say “This isn’t an attack - we all need to follow rule X in style guide Y!”

Style guides are also a great way of building a technical writing community and engaging with other parts of an organisation. Rather than a single person making arbitrary style decisions, you can open up the discussion and make everyone feel part of it. The technical writing team at GDS are trying to practise what we preach and are currently figuring out a mechanism to get feedback on the technical style guide I linked to, so watch this space and contribute!

What is your favourite part of being a technical writer?

Learning! It’s scary when you’re given a piece of work and you have no idea how the technology works or what your documentation will eventually look like. However, I love the process of speaking to my developers, reading comparable docs, and figuring out what my users need from me.

**What advice do you have for someone who is interested in technical writing as a career path?

Read documentation critically. There’s a lot of bad documentation out there, so don’t presume a page is perfect just because it’s from a big organisation. Seek out publicly available docs and consider a few things:

• Why did the writer structure the page this way?
• If this is the first page of docs a user has ever seen for this product, does it still work?
• If I didn’t find what I wanted on this page, is it clear where I should look next?
• Has the writer been consistent in:
  • how they talk about concepts?
  • how they structure pages?
  • how they organise information?
• What would you do differently if you had to rewrite this page?

Do it with my documentation! You can read the GOV.UK Pay documentation here and raise issues with it in our GitHub repo.