About Mark

1. Mark’s LinkedIn
2. During his college days, Mark didn’t have many options to choose from. He discovered technical writing and loved it because it combined the two worlds of writing and technology. Eventually, he secured his first job as a junior writer.
3. Later, Mark discovered Tom Johnson’s blog, “I’d rather be writing”, which inspired him and made him feel like technical writing was a perfect fit for him. As he delved deeper into the field, he came across Tom’s API documentation course, leading him to switch his focus to API documentation.

Key Takeaways

• In normal phases of documentation, you have requirements gathering, user research, drafting, reviews, and publication. Whereas with API documentation, there’s ‘developer experience’ which is almost like user experience. And it involves all the different things that you normally would do with user research such as interviews, remote usability tests, crowdsourcing surveys, questionnaires, and reviews, too.
• “One most common types of API documentation is swagger documentation, which is documentation that’s automatically generated from what’s called the Open API specification. Open API is the overall structure of the API, that says how the API is coded.” Mark adds.
• While speaking about different aspects of API documentation, Mark says “One aspect of it is writing intensive, i.e., conceptual documentation, which is mostly user guides in a sense as far as structure. It starts out as a boarding/gets started document where the developer is taken through the quickest route possible to using the API.”
• “The most challenging aspect of technical writing, especially if you are in a very large organization, is the operational silos of customer-facing teams and documentation teams. You are getting second-hand information because they give it from their perspective.
  In addition, API documentation experts should get familiarized with Git, Markdown, Static Site Generator, etc. Technical writers are trying to get as close to developers as possible, using their tools and processes from them. There’s a learning curve and it can be quite challenging.”, He continues.
• Responding to a query about whether good quality documentation reduces your workload, Mark says, “It doesn’t really reduce your workload, but it just means you can focus on other things besides writing. Say, adding features to your website or researching technologies or spending more time on strategy, you might outsource your writing to other stakeholders and become the reviewer.”
• “Having good quality documentation is a good thing because it allows you to sort of put on different hats and switch roles.”, Mark says.

Rapid fire with Mark Wentowski

• Highly recommended resource 

Astro docs, an all-in-one web framework for building documentation.

• One word that comes to your mind when you hear documentation.

Mark feels that there’s a whole world around it- Not just requirement gathering and writing.

• A piece of advice you would give your 20-year-old self  

“Stay curious and ask more questions to establish a relationship with people who has knowledge on the topic that you are interested in and wish to pursue.”

Subscribe to Knowledgebase Ninjas: 

1. Apple 
2. Spotify 
3. RSS 

The post API documentation: Components and Best Practices with Mark Wentowski, API documentation specialist at Techwritex appeared first on Document360.

About Mysti

1. Mysti’s LinkedIn
2. She has a bachelor’s degree in Linguistics from University of California, Santa Cruz
3. She got her first technical writing job at a party where she was one of the only two girl geeks at tech. One of her friends at the party referred her to a technical writing job. 
4. When Mysti started off in technical writing, client – server was a big deal and then SaaS came along. She feels lucky that she had been in the Salesforce during that revolution.

Key Takeaways

• Speaking about the documentation process at mParticle, Mysti says, “We have multiple processes depending on what is being documented the most, that takes most of our time, and gets most of our focus.
• “When a feature is new or it’s being potentially enhanced, we get involved very early with the product manager. We would like to know how this feature is going to work before it is handed off to engineering department. Hence, the writing team along with UX is involved at the same time, attending meetings, and following the progress of the project.” Mysti says.
• Mysti adds “It is always such an interesting challenge to measure how well the content is being consumed by the audience. In documentation, how do you know how long a customer should be looking at a page before they’re like, not finding their answer. We have some direct measures like how many new bugs closed compared to bugs opened. Additionally, we watch the page views, to make sure that people aren’t failing to find the most important content.” 
• “At mParticle, we have a tool called indicative. It lets us measure things. Bounce rate is the leading indicator of not finding what you’re looking for. Unless it’s a tutorial, which is designed to go step one, step two, step three.”, quips Mysti. 
• As a great community leader and influencer, Mysti thinks it’s so important to share information across corporate boundaries, as appropriate, so that you can grow your knowledge of technical writing, in general. So, you know where you’re headed and what you should be doing because technical writing is a bit of a black box to many software companies. 
• “We live in our individual silo solving the same problem over and over. If we shared more information, which happens a lot on the community channels and conferences, we can improve standards. “, she continues. 
• She believes that the main problem concerning knowledge sharing is when you have many kinds of users, how do you structure the information so that everybody is getting just what they want and not too much. 
• “The only solution to this problem is finding the right way to structure information or maybe even publishing it twice, you know, once for a non-technical person and once for a technical person. You do need standards and you do need to make decisions about it so that you do it consistently” Mysti says.

Rapid fire with Mysti Berry 

• Biggest influence 

Andrea Lez, she was Mysti’s first boss at Salesforce

• Highly recommended resource 

Write the Docs – Slack channel

• A piece of advice you would give your 20-year-old self  

“Be prepared to forget everything you learned and replace it with something new about every five years.”

Subscribe to Knowledgebase Ninjas:   

1. Apple 
2. Spotify 
3. RSS 
   
   

The post Knowledge sharing and documentation metrics with Mysti Berry, Principal Technical Writer at mParticle appeared first on Document360.

About Yael

1. Yael’s LinkedIn
2. Yael is a trained psychologist. She has a master’s in clinical psychology but decided not to pursue a career in therapy.
3. She saw an advertisement for a technical writer that said they didn’t require any prior experience, they just needed good English and good writing skills- And that’s how she ended up in technical writing about 10 years ago.
4. Before Akamai, she worked for Britannica, Wix, and BMC Software as well.

Key Takeaways

• “Working for a global team of technical writers is amazing. We all help each other, consult with each other, and share what we’ve learned. I work with stakeholders, and I get feedback on existing articles from them. I implement the feedback and change the documentation. And sometimes I get requests for a whole new article that we’ve never written before. In that case, I must speak to a different set of stakeholders. And as a technical writer, I get feedback from the stakeholders who have some sort of interface with users.” Yael says.
• “You have limited feedback when working with a smaller team. When I started, I was the only technical writer in the small company. I had a wonderful manager who explained everything about software, say, how software company works, what is SaaS, etc. However, the scope of collaboration and exposure is huge when working with bigger teams.” Yael says.
• Also sharing her experience working in a cybersecurity team, she says the goal was to educate users and be a single source of truth. The content we develop would be mostly educational material, in addition to step-by-step material, explaining cybersecurity and computing concepts.
• According to Yael, when you’re a technical writer, you write for users, and you need to understand what the user knows already and what the user doesn’t know what the user expects to see. And, to best present the information for different kinds of learners- visual learners and text learners. So, it’s always thinking about the user, and that’s psychology in essence.
• She believes that technical writing is a way to get a foot in the door into a big global company. And it’s a way for people who are not developers or coders to also take part in software development.
• When asked about the biggest innovation until now in the technical writing space, she says, “Cloud-based content management system (CMS) was one step further for us because we could implement content updates immediately. It’s what you see is what you (WYSIWYG) get kind of a management system that I feel was the biggest innovation that I’ve seen.”

Rapid fire with Yael Basford

• Biggest influence

  Yael’s first manager, Yossi Ben Ishay

• Highly recommended resource

  It’s a blog on how technical writing contributes to usability. The blog is owned by someone who oversees API at Wix’s technical writing guild.

• A piece of advice you would give your 20-year-old self

  Be inquisitive and humble because there’s always a lot more to learn.

Subscribe to Knowledgebase Ninjas:

1. Apple
2. Spotify
3. RSS

 

The post Navigating Team Dynamics in Technical Writing with Yael Basford, Senior Technical Writer at Akamai appeared first on Document360.

About Avi

1. Avi’s LinkedIn 
2. When the pandemic hit the world, he was working in incoming tourism. As the industry looked dim at that point, he didn’t have many options there.
3. During that time, he spoke to a few technical writers and liked how they were engaged in their profession. He then pursued technical writing the following year and is glad that he did.
4. His first job as a technical communicator was for BMC- a legacy software that was moving from On-prem to SaaS.

Key Takeaways

• Avi says, at the end of the day, a technical writer must write as little as possible because more than consuming the content, users must get the answers and move on with their work. That’s the reason why he likes to call himself a technical communicator and not a writer.
• In fact, his team at Sage has just been rebranded to content-experienced writers, as they are responsible for taking customers through the entire product experience.
• Speaking about audiences and persona, he explains a persona would be a theoretical person who would be looking at our content. For example, for an accounting tool, the personas can be a CFO or an accountant, or a bookkeeper who is working with the product. Whereas an audience is a collection of all the personas that we are writing our content.
• He further adds that while creating ideal personas, it must be in conjunction with other departments, like marketing, development, etc.
• “At Sage, we listen to customer conversations (recordings), their pain points, and to what they’re going through. And when I’m writing, I consider myself a user and not a writer. I will ask myself questions like, what stage am I at with the product? Am I a new customer? Am I reading the introduction section? Am I a more intermediate or an advanced user?”
• So, when the sprint finishes, everybody is up to date with the changes. The features are released when all have their input. In that way, they aren’t alienated from or siloed from one another.
• “I think some companies fall into danger of reaching out to the writers at the end when they have done all their work, and they’ll work on documentation sites which no one looks at. But at Sage, it’s a completely different approach altogether. Here we follow a model where communicators are embedded into, say, dev, product management UX, etc. Each team has a little representation of all the different departments that go into the product”. clarifies Avi.
  
  

Rapid fire with Avi Chazen

• Biggest influence 

Avi’s previous manager at BMC

• Highly recommended resource 

Madcap’s documentation help resource

• A piece of advice you would give your 20-year-old self  

“Keep on learning all the time.”

Subscribe to Knowledgebase Ninjas: 

1. Apple 
2. Spotify 
3. RSS 

The post Discussing technical communication with Avi Chazen, Technical communicator at Sage appeared first on Document360.

About Isa

1. 1. 1. Isa’s LinkedIn 
      2. She has a Master’s in Technical Communication from Université-Paris-cité
      3. In her opinion, having a background in academia, research, or teaching can be helpful for technical writing as there’s a lot of transferable skills that one can bring into the field.
      4. Before joining Nexudus, she worked as User Assistance Developer at SAP

Key Takeaways 

• Isa has a different take on when asked what’s easier, content creation for customer acquisition or retention. She says, “for customer conversion, content needs to be super impactful, you have about 8-12 seconds to make an impression. However, in customer retention, since they have a certain grasp of the platform already, it’s a matter of getting them from point A to point B.”
• “At Nexudus, we have a very rigorous and robust single sourcing-content reuse. Hence, whenever there is an update, we can do that as quickly as possible. It is crucial because the knowledge base is not only used by our customers but also by our support team. And it is a central knowledge hub that everyone using our software is bound to use at some point.”
• “The main challenge I have faced w.r.t documentation is keeping the knowledge base up to date and that’s just something that you can find in every company making sure, especially for software, it’s a constant battle to make sure that everything is up to date and our users have the latest information.”
• Isa says “Keeping our knowledge base up to date has helped customer retention a great deal. Having an issue or not being able to do something and being able to browse the knowledge base, find a solution, get going instead of waiting, you know, 24 hours for their tickets to be solved.”
• It’s also a reflection of knowledge bases in general or the reflection of how companies feel about their customers in a lot of ways. Being able to answer their needs is already a sign that you sort of care and you’re doing your research in terms of knowing who you’re serving.
• Adding further to the knowledge base update, she explains, “At Nexudus we have an agile model within the company. So, whenever we need to update something where we have a ticket, we update it right away. If it’s a third-party integration and we don’t have a lot of input on the product or feature, we go with the review process. We usually have a 90-day period where we review the documentation for third-party platforms and see if it lines up.”
• “To make sure the content is well received by the users, the main metric we use at Nexudus is ‘click to read’. It tells you exactly when customers are engaged. If you’re consistent with your content, the metric value should be somewhere between 60 and 65. It’s a good indicator to know people are clicking as well as engaging with the content.”
• Another metric to note is the number of tickets that you get, the number of tickets that are sold with just a link to the knowledge base.

Rapid fire with Isa

Biggest influence  

“My tech writing professor in my master’s program was one of the people that helped me grow the most because he was so demanding. “

Highly recommended resource  

Passo uno/about/ by Barcelona-based tech writer, Fabrizio Ferri Benedetti

A piece of advice you would give your 20-year-old self. 

Ask away. Ask as many questions as possible until you’re 100% sure. And connect with loads of people, as much as you can, because everyone will help you paint a better picture of the users we’re serving, and your documentation will be better if you know who you’re talking to.

Subscribe to Knowledgebase Ninjas:  

1. 1. 1. Apple  
      2. Spotify  
      3. RSS  

The post Documentation as Customer Success and Retention Tool with Isa De Abreu, Lead Technical Writer, Nexudus appeared first on Document360.

About Jonathan

1. Jonathan’s  LinkedIn 
2. While working in the UK Insurance industry, he went through a career change process and discovered that technical writing would be more aligned to his goals and skills.
3. Initially he worked as a legal technical writer. While in that role, he was able to do some software documentation. Later he worked with government digital service on their software documentation.
4. Recently, he moved to Gitlab as a senior technical writer.

Key Takeaways 

• According to Jonathan, the essential skill in any profession is being able to communicate with people regardless of the communication used.
• “However, in technical writing, I always look for someone who can build relationships with subject matter experts as you’re talking to get the information from them to then build the documentation you need to build to serve these needs you need to serve,” he says.
• Another skill is attention to detail at the fundamental level. It is not just paying attention to Starguide, it’s also making sure you correctly follow, say, workflows that help make your remote setup work.
• It’s tempting to always get focused on the hard skills and even the words on somebody’s CV or resume. But if a person is less open to learning new skills or tools, it will be difficult for them to contribute or add value to the team or any organization.
• Jonathan believes that being able to use the command line is a very good transferable skill now. This will place you in good stead in the technical writing space.
• Docs-as-code is an intuitive tool and very responsive when it comes to help and support. It is one of the desired skills to focus on in the documentation.

Rapid fire with Jonathan

• Biggest influence  

“I am lucky in my career to work with some brilliant folks who have inspired me to be a better technical writer. Learned so much from tech writers at GDS and GitLab- Laura Hiles, Jen Lamborn, and Rosalie to name a few from whom I have learned a lot. “

• Highly recommended resource

The ‘Write the docs’ community is great, as well as I’d Rather Be Writing by Tom Johnson.

• A piece of advice you would give your 20-year-old self.

“Write down everything that you achieve in your job because it makes it easier when it comes to reviewing time. It might sound a bit traditional, but unfortunately, in the world we live in, documentation with good detail will help you so much in life.” 

Subscribe to Knowledgebase Ninjas:  

1. Apple  
2. Spotify  
3. RSS 

The post Hard skills vs soft skills in technical writing with Jonathan Glassman, Senior Technical Writer, GitLab  appeared first on Document360.

About Jessica

1. Jessica’s LinkedIn
2. She never realized it was a career option until she joined Zapier in 2017.
3. She has a background in graphic design and has worked in domains such as HR, SEO, support and finally moving into documentation.
4. At Zapier, initially, her role was focused on writing articles for the help center, then transitioned into hybrid, and then eventually became a full-time technical writer there.

Key Takeaways

• Speaking about the documentation process, Jessica explains that at Zapier, the technical writers are placed across different areas of the product. Earlier, the documentation team used to heavily rely on the relationships with different product teams. Teams must be frequently notified of any internal communications or any potential things coming down the pipeline.
• However, with this shift (of having technical writers within different areas of the product), the documentation team is much more aware of changes since they are a part of the product development cycle.
• “Another aspect of our documentation process is the internal knowledge of Zapier’s support knowledge base. Here, we lean on the methodology of KCS. KCS stands for Knowledge Center Service. It integrates the knowledge base into an organizational workflow.
• For the majority part of the Document Development Life Cycle (DDLC), I’ve taken inspiration from GitLab as their documentation is publicly accessible. Under DDLC, there are 3 different phases in general. The first one is discovery; the second one is shaping and the last one is delivery. At the discovery stage, we are kind of informed that something is coming down the line. Moving towards shaping and delivery, we try to understand what the documentation requests will form and look like.
• With this process model, it’s an opportunity for us to collaborate a little bit more versus knowing about it. It can help us to give timely feedback to the product teams. I think before we used to heavily rely on someone saying, hey this needs to be updated and we weren’t necessarily part of the process and then from there, we had to kind of figure out how best to kind of translate that in a way that would make sense to the customer. But now, kind of being a part of the process, we’re able to kind of share our insights and improve the product and experience of the user.”
• According to Jessica, good documentation enables the users to find the answers they are looking for at the right time. If the documentation can cover the fundamentals of say, what the product does, it can help reduce the redundancies of support and success teams a great deal.
• “To measure documentation effectiveness, we track a lot of different data. Apart from users and sessions, we track how readers are coming in and out. We also look at searches with no results. Say, if someone is searching for a piece of information, and if there’s nothing kind of pulled up, that is also an indication that the information is missing or maybe the article itself not written in the way that the customer expects.” She adds.

Rapid fire with Jessica

• Biggest influence 

I started as a lone writer and whatever I have learned since then, I owe it to Write the Docs community. They have an amazing slack community and they organize good number of conferences to participate virtually and in-person.

• Highly recommended resource 

- https://everypageispageone.com/the-book/ by Mark Baker

• A piece of advice you would give your 20-year-old self.

My advice would be to always focus on progress over perfection. Not every single piece of documentation will be perfect, and this is something I picked up from learning KCS.

Subscribe to Knowledgebase Ninjas: 

1. Apple 
2. Spotify 
3. RSS 

The post Document Development Life Cycle with Jessica Valero Gil, Senior Technical Writer at Zapier  appeared first on Document360.

About Domi

1. Domi’s LinkedIn 
2. She’s an accidental technical writer- She interviewed for a job as a business solution analyst, but they offered her a role as a technical writer
3. Later, she found a job at a company that she was familiar with and grew from there
4. She says writing has always been her passion, along with technology and academia. Before joining Collibra, she worked as a Technical Writer at Totara Learning

Key Takeaways

User empathy is extremely relevant when it comes to documentation. We need to understand how our audience is feeling- are they curious, are they frustrated and trying to get things to work? The documentation should be the thing that unblocks them.

If users are frustrated when they are coming to something, they don’t want a load of extra fluff. Your goal is to make their life easier. That’s the reason why it is important for documentation teams to talk to users to know how they are feeling.

Documentation teams need to be accessible to teams like the customer success teams so that they can give us feedback on, you know, any places where users are feeling stuck or frustrated so that we can, you know, be that lubrication that helps make the user journey much easier.

At Collibra, the team is bringing the culture of empathy right at the beginning of the design stage of the project. The documentation team works closely with UX/design team to create synergy in the writing experience and the use of language. They work with the product managers and have regular sync-ups with the ones responsible for specific areas to make sure they document everything that they work on. They have a peer review process within the team as well.

According to Domi, these collaborations can give you that extra push that you need to clarify yourself with respect to the usage of certain words, language, etc that you don’t think is going to translate well to the customer who may not be that technical.

“The term technical writing can be so broad and there are so many different types of technical writing, audiences, processes, etc. It is important to find the way that works for you so that you can enjoy it and I think that is only going to improve your writing. That’s going to create a better customer experience.”, says Domi.

Rapid fire with Domi Sinclair

Biggest influence 

“My husband is one of the people that I’ve learned a lot from. He works within a product, and he’s one of the people that’s really helped me with customer empathy.”

Highly recommended resource 

It’s called Content Design by Sarah Winters.

A piece of advice you would give your 20-year-old self  

“Make sure that you’re asking a lot of questions to understand what you’re documenting and cover any possible questions that customers or users might have.”

Subscribe to Knowledgebase Ninjas: 

1. Apple 
2. Spotify 
3. RSS 

The post User empathy while creating customer support documentation with Domi Sinclair appeared first on Document360.

About Marty

1. Marty’s LinkedIn
2. Marty started his professional career in the entertainment space, spending around 30 years before the transition to technical documentation.
3. Before CrowdStrike, he worked for Google and ServiceTitan and assisted in developing In-App copy and standardizing writing styles and formatting guidelines for the documentation team.

Key takeaways

• “I think as you evolve as a technical writer within your company, a good wiki or style guide is kind of essential as you are providing a good customer experience by having consistency throughout the knowledge product.”
• Style guides are a tough thing to build, especially when you’re first starting your small group, you’re working quickly, and it’s hard to come to get the group together as a consensus and have a solid style guide.
• The time invested in building a good style guide can save a lot of time later. It eliminates the decision fatigue for other writers trying to decide whether to do the Oxford comma or not.
• One of the things they do within the documentation team at CrowdStrike is to build the style guide. It’s like community practice. They have smaller groups within the writing teams, the ones that decide what words we use, another group that decides what our style guide is, one about accessibility, and so on.
• It’s a great way to build things because someone must make that decision and having a small group to do it aids delegation and gives them a sense of ownership. And it breeds a lot of interconnectedness and unity within the teams.
• Along with creating In-App copy, Marty contributes to customer-facing content as well. He suggests ‘relying on customer interviews’ while building user-facing documentation.
• “I watch customer interviews to try to get a sense of why a customer would need a particular feature. That’s where you start. You must also trust your empathetic instincts to put yourself in the customer’s shoes. Once you get the metrics and feedback, you can adjust your documentation to make sure what customers need.”, he says.
• During the interaction, he briefly touched upon technical writing community space as well. In his opinion, there are a lot of amazing communities out there worth exploring and by engaging with them, one can be a better technical writer.

Rapid fire with Marty Yu

• Biggest influence

“I must give due credit to my sister- she’s a technical documentation writer, she got me my first job and explained everything about Technical Writing that I needed to hear. “

• Highly recommended resource

Modern Technical Writing by Andrew Etter

• A piece of advice you would give your 20-year-old self

“Talk less, listen more.”

Subscribe to Knowledgebase Ninjas:

1. Apple
2. Spotify
3. RSS

The post How to build style guides that enhances the customer journey with Marty Yu, Senior Technical Writer at CrowdStrike appeared first on Document360.

About Lindsey 

1. Lindsey’s LinkedIn 
2. Before joining Paradox, she worked for R365 as a technical writer and the University of Indianapolis as an English Adjunct Professor.
3. She has got a bachelor of secondary education in creative writing, literature, and literary studies, and a masters in English.  
4. Lindsey always had a dream about being a teacher since she was a kid and so after graduation, she tried her hands at teaching – both secondary and post-secondary classes for about two years. 
5. She loved working with students one on one, talking about their writing and giving them feedback but realized that she didn’t have a good work-life balance. But also thought there should be a way to still teach in some capacity, and kind of work a little bit more and have a better work-life balance, and that’s when she fell into technical writing.  

Key Takeaway 

• Lindsey feels that people from a variety of areas can get into the technical writing field and don’t want to have any specific degree for it.  
• “There’re so many ways that one can go into technical writing. I’ve seen people who had technical writing degrees and I’ve seen others who may be started in a specific area at a technical or at a software company and from there moved into technical writing because either they didn’t have a technical writer and they needed someone to do it or, they just were low on resources and had to kind of hold the weight in different areas.”  
• Before getting into the technical writing space, I enrolled in English literary studies and creative writing for my undergraduate degree. To take up teaching at a higher level, I applied to the University of Louisville to be a graduate teaching assistant. The benefit of working as a graduate teaching assistant is that you can work in multiple capacities.  
• For my level, I would work with students in the writing center, review and provide them feedback on their work. And I interacted with students from all levels- from the very first year of college to, doctoral students.  
• For the second year, I worked as a copy editor for the Louisville Logistics and Distribution Institute. There, I was able to provide students (whose first language was not English) feedback on their writing and research. Along with that, I was an adjunct instructor and taught two sections each semester of inter-level English at the college level. It was a great experience and helped to give me a better insight into the world of writing and communication. 
• I also studied a little bit of linguistics, and it was helpful to get more of a bigger sense of languages and how we communicate. I believe through those experiences I was able to help push myself forward into technical writing because without it, I don’t think I would have been able to kind of make the career jump to being a technical writer.  
• “As a technical writer, apart from writing, I do research and figure out what our team needs and decide on the best software solution that can benefit the company and our clients. In addition to that, I will be kind of paving new ways and creating new processes for a technical writing team, which in the future can bring more technical writers to build up and support the company in a variety of ways. “ 
• Reporting structure for documentation teams varies from company to company. Typically, technical writers work with the engineering portion of our team, but for client-facing documentation and release notes teams, they communicate directly to the client success and product marketing team. 
• Talking about Paradox, she says, “our client success team has been doing a fantastic job at building relationships with clients and providing them with the documentation they need. In addition to that, the product team has been creating internal documentation to help educate our client’s success team on products that are being released.” 
• “The role at Paradox has given me the ability to create a support center essentially from scratch with the help of course of our amazing team and their previous knowledge and documentation that has been created and maybe even see it grow and become a leader in this area one day.” 

Lindsey’s biggest influence  

Her biggest influence is her previous boss.  

Key Resources  

‘The obstacle is the way’ by Ryan Holiday- even though, it is not directly related to documentation, it provides a great perspective on challenging obstacles, especially in this realm.  

1. What documentation-related advice would Mary give to his 20-year-old self? 

“I would say spend more time learning screenshot editing tools that are an area I’ve had to expand in my career. So learning that would be super powerful”. 

Subscribe to Knowledgebase Ninjas: 

1. Apple 
2. Spotify 
3. RSS 
    
    

The post Discussing technical writer career path with Lindsey Gilbert, Technical Writer at Paradox appeared first on Document360.