About Mick

1. Mick’s LinkedIn
2. He started his career as a freelance journalist working for newspapers and magazine stories. After several years, he found an office job, where he started writing paper-based training materials and eventually got into writing user manuals and technical manuals for software.
3. Mick is a technical author in the development team at Aussie Broadband.

Key Takeaways

• According to Mick, 30 years ago, documentation was fully paper-based and PDFs. Searching for specific information from those documents was a real challenge.
• Tools like wikis eventually helped to overcome this difficulty. These tools made formatting much easier and allowed technical writers to focus more on content creation. In addition, they enable collaboration and knowledge sharing.
• Mick points out that the advancements in AI and tools like Bard and ChatGPT have made the research part easier for technical writers, enabling them to access a wealth of information and build content rather than searching the internet and getting bits and pieces of information.
• “Technical writing and documentation groups in LinkedIn are such a great resource. If technical writers these days get stuck, they can ask people out there for help. Whereas before 20 years ago, I was a lone writer, if I got stuck, there was virtually nowhere to go for help”, says Mick.
• According to Mick, the biggest challenge for technical writers is that the department is often overlooked, as the developers and technical people are under pressure to get things done since they bring money to the table.

Rapid fire with Mick Davidson

• Highly recommended resource

LinkedIn is a good place to find resources

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

User manuals

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

Be more assertive and confident

Subscribe to Knowledgebase Ninjas:   

1. Apple 
2. Spotify 
3. RSS 

The post The Changing Landscape of Technical Writing with Mick Davidson, Aussie Broadband appeared first on Document360.

About Eduarda

1. Eduarda’s LinkedIn
2. She started her career as a customer service representative, where she began documenting the company’s procedures for her reference. And later she started to share the same with her colleagues.
3. Her managers realized the importance of documentation, and eventually assigned her sole responsibility for the company’s help center, articles, and internal operation materials.

Key Takeaways

• According to Eduarda, documentation means the entirety, which includes organization, sharing knowledge, and decentralizing knowledge from an individual standpoint.
• “Once you get the documentation centralized and well organized you end up helping different departments in your company like the customer service, the product, and the tech. Everything becomes faster as you don’t depend on people to understand things”, says Eduarda.
• The most significant impact of effective knowledge management is the ability to decentralize information from people and create a single source of truth (SSoT).
• With the implementation of SSoT, you will have faster processes, thereby achieving organizational success.
• By optimizing the knowledge base for SEO like adding titles, subtitles, bullet points, and keywords, technical writers can organize the document and enhance the searchability and accessibility of the document.
• Eduarda feels to keep up with current trends, it is important to integrate AI into the knowledge management platform so that users can get quick and accurate responses.

Rapid fire with Eduarda Raddatz

• Highly recommended resource

I’d Rather Be Writing Blog

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

Organization and information, these two words together bring a perfect definition of documentation

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

Stay curious and stay up to date.

Subscribe to Knowledgebase Ninjas:   

1. Apple 
2. Spotify 
3. RSS 

Also, Check out our podcast on Crafting quality product documentation with Sofia Emelianova, Senior Technical Writer at Google

The post Knowledge Management for Organizational Success with Eduarda Raddatz, Technical Writer at Matera appeared first on Document360.

About Sofia

1. Sofia’s  LinkedIn 
2. She wanted to become a software engineer or a linguist, or a translator. In her opinion, she solved the problem brilliantly. In her first job, she helped customize an enterprise resource planning system for the needs of a logistics business. As part of the job, she wrote instructions for the internal users.
3. Tom Johnson’s blog called I’d Rather Be Writing inspired her to get formally into technical writing.
4. Currently, at Google, Sofia is responsible for the whole content production of documentation for Chrome developer tools. 

Key Takeaways 

• Sofia says the biggest challenge in a technical writing career is the curse of knowledge which comes with constantly gaining context on the thing that you are writing documentation on. When you’re in context, your vision kind of blurs a bit. Hence, it’s very difficult to put yourself in the shoes of the user.
• Her solution to this is to seek out opportunities to get direct feedback from the reader of her documentation or her coworkers who are out of context to read her documentation and see if it makes sense to them.
• “Another challenge is the whole velocity of development. I’m the sole technical writer for the developer tools. Sometimes I get help from my peers at Google technical writers or vendors. However, when I’m doing it on my own, I must improve the pace of my context switching to keep up with everything.”, says Sofia.
• She adds that we can’t focus on several things at once, so what people perceive as multitasking is very rapid context switching.
• “When it comes to creating quality documentation, my go-to person is always subject matter experts. To speed up and ease communication, I spent an hour researching the topic and compiling a set of questions for the subject matter experts.” Sofia adds.

Rapid fire with Sofia

• Highly recommended resource  

Google developer documentation style guide  and The Elements of Style – a book that contains insightful advice that can be effectively applied to technical writing.

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

Education

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

Do not get intimidated by complexities and always try to learn something new.

Subscribe to Knowledgebase Ninjas:     

• Apple   
• Spotify   
• RSS  

Also, Check our Podcast on Technical Documentation with Tom Johnson of Amazon

The post Crafting quality product documentation with Sofia Emelianova, Senior Technical Writer at Google appeared first on Document360.

About Beatriz

1. Bea’s LinkedIn
2. She started her career as an English teacher. Since her teenage years, she always had a strong connection to the language and a desire to do something creative with the language.
3. Bea landed her first technical writing job through a colleague of hers who shared the opportunity with her. She gained valuable experience in the role, and it marked a fantastic beginning to her journey as a technical writer.

Key Takeaways

• According to Bea, one of the most important skills that are similar in both teaching and technical writing is the ability to translate complex subjects and topics. As a teacher, one must think about teaching different types of learners, and the same understanding will make things easier in the technical writing role.
• “The role of technical writers in technology companies is crucial as they advocate for users. Project managers and developers often become deeply immersed in the technical aspects, so writers and UX teams can assist them in delivering a better product”, says Bea.
• The greatest benefit of switching to a technical writing job is the flexibility to work from different locations, which allows individuals to balance their personal lives with their careers. It is also important to conduct regular research, connect with people, ask the right questions, and be creative.
• The most challenging thing in technical writing is documenting a complex product. A piece of advice for writers here would be to speak up and ask questions. And with experience, one can learn how to come up with the right questions.
• “In addition, try to find stakeholders who are more interested in documentation, and this will help you get allies to work on your side. When you have these people, you can deep dive into research, get more comfortable and you don’t get overwhelmed with complex documentation”, explains Bea.
• Bea points out that it is very important to understand what type of learning style fits each one of us. This will be a game-changing experience because we can take advantage of the style, thereby contributing to both professional and personal growth.
• “In today’s fast-changing world, continuous learning is crucial for one’s professional growth. Technology advances too fast and especially with the AI learning tools out there, one can easily get upskilled.” Bea adds.

Rapid fire with Beatriz Mejia

• Highly recommended resource

Google Writing Style Guide

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

Structure

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

“Be patient and don’t get too attached to small things. Work hard with the right mindset, stay dedicated, and with time, things will work out.”

Subscribe to Knowledgebase Ninjas:   

1. Apple 
2. Spotify 
3. RSS 

The post Transition to Technical Writing from Diverse Backgrounds with Beatriz Mejia, Technical Writer at Ben Fatto appeared first on Document360.

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.