I am a technical writer with strong web dev skills that designs and builds modern and engaging developer documentation for SaaS products.
I am a freelance technical writer with over 11 years of experience working in high-energy, Agile teams. I am a digitat nomad that writes and develops for clients around the globe.
| Name | Mark Wentowski |
|---|---|
| mark.wentowski@saashelp.net | |
| www.linkedin.com/in/markwentowski | |
| Skype (Personal) | mawentowski86 |
LinkORB Engineering consists of over 30 talented developers, operations specialists, writers, and other dedicated engineers, all working collaboratively to create cutting-edge solutions using the latest technologies.
As a technical writing lead, I am responsible for overseeing LinkORB's tech writing team that creates content for internal and external audiences to enhance the onboarding experience for new team members, foster alignment across teams regarding technical standards and best practices, educate and share insights on the utilization of both established and emerging technologies within the LinkORB ecosystem, highlight our contributions to the open source community, and drive the growth of our engineering blog through the development and implementation of effective strategies and tasks.
The role includes:
Document360 is a documentation software company that recently added an API documentation feature to their knowledge base product.
They hired me as a freelance Technical Blog Writer focusing on writing articles about API documentation.
As part of this role, my primary task was to create engaging and informative blog posts based on trending Google searches related to API topics. This involves conducting research on relevant topics, organizing information, and writing compelling articles that cater to your target audience.
Summa is an investment management company in the FinTech space. They hired me as a freelance API Documentation Specialist.
As part of this role, I worked with the Product and Development Teams and was primarily responsibile for consolidating disparate documentation and API sample coding into the Redocly platform. I was able to help Summa deliver world class API documentation that has accessibility for both business users and developers.
Deliverables included:
SITA is the IT provider for the air transport industry.
As a senior technical writer, I was responsible for creating a wide variety of web-based documents, primarily for the company’s Flex API Platform that allowed airline developers to build applications using their customers’ mobile devices as data interfaces. Deliverables included REST API Reference documents, API conceptual/process documents, and other developer-related documentation.
Lockheed Martin is an US aerospace defense company.
As a Technical Author in the C-130 Technical Publication Support Group, I was responsible for writing a wide range of aircraft maintenance and flight manuals, providing support for the content management system, and collaborating with QA to ensure document quality of all materials prior to publication. My role included the following:
Program focused heavily on advanced expository writing and methods for critical analysis of complex subject matter.
Onboarding and standards
Onboarding and standards
LinkORB Engineering consists of over 30 talented developers, operations specialists, writers, and other dedicated engineers, all working collaboratively to create cutting-edge solutions using the latest technologies.
Redocly Migration
Redocly Migration
Summa is a FinTech company that specialises in reporting solutions for investment accounting.
The goal of the project was to consolidate, improve and publish Summa's API Docs to the new platform, Redocly. The API documentation needed to be consumable by both business and technical users. The project required me to create standards and processes for ongoing documentation maintenance, including the creation of style guides, templates, and training for new employees. Summa also requested the creation of custom React components such as a linking component that allows for automatic creation of links between articles.
There were several deliverables for each milestone of the project:
I worked with members across the organization (primarily Product Management and Dev) to gather missing Open API descriptions for endpoints, schemas, parameters, etc. Since non-technical users were contributors, we created a solution using Google Sheets that allowed users to enter descriptions in a table rather an external markdown file. The Google Sheet then could be applied directly to the Open API spec.
I then imported the documentation from the disparate systems into Redocly. This required checking the content grammatically and also cleaning up the markdown formatting. I configured the Redocly UI to meet the client's requirements and created custom components for them such as a Permalink and a Popover.
I worked with the Product team to document writing standards for the style guide. This included both instructions for Open API descriptions as well as knowledge article standards. I also revamped Summa's training material to make onboarding more painless.
Summa's primary client was impressed with the new output and recognized it as a significant improvement. Summa was satisfied that I met the project requirements and delivered the project exactly on time according to the project plan. The client indicated they would like to work with me in the future if there was an opportunity.
Technical Blog Writing
API Documentation
API Documentation
SITA is one of the world's leading specialist in air transport communications and information technology companies that has products covering all major operations at airports.
I had the opportunity to take part in a dev team developing an API from the ground-up using the "spec-first" philosophy that involved writing an Open API spec by hand prior to developing the API. The team adopted this approach after delivering an API that severely lacked user input when it came to the endpoints and parameters so there were many things the users felt they could not accomplish in the way they would like to. The goal was to make the Open API Spec a contract for developers to build their API against.
Because the spec was being written from the ground up, I had a chance to be involved in the user research. I was on all calls with the customer to help build personas based on their unique needs for the different personas.
I actively participated in the creation of the Spec. This effort also got me involved in taking an active part in adding descriptions to the endpoints and parameters in the Spec.
Defining the endpoints and chronology of how the APIs were used, I was able to contribute to the user experience of the API. I was involved in the ground up to help write these descriptions as opposed to later.
After the developers had developed the API to match the Open API Spec, they then could render the spec using a tool like Swagger.
API Documentation
API Reference docs
SITA is one of the world's leading specialist in air transport communications and information technology companies that has products covering all major operations at airports.
I had the opportunity to take part in a dev team developing an API from the ground-up using the "spec-first" philosophy that involved writing an Open API spec by hand prior to developing the API. The team adopted this approach after delivering an API that severely lacked user input when it came to the endpoints and parameters so there were many things the users felt they could not accomplish in the way they would like to. The goal was to make the Open API Spec a contract for developers to build their API against.
This portfolio item is based on the hand-written spec and demonstrates my knowledge of the Open API spec, facility with its concepts, and how to render that data in a branded documentation website.
Because the spec was being written from the ground up, I had a chance to be involved in the user research. I was on all calls with the customer to help build personas based on their unique needs for the different personas.
I actively participated in the creation of the Spec. This effort also got me involved in taking an active part in adding descriptions to the endpoints and parameters in the Spec. Defining the endpoints and chronology of how the APIs were used, I was able to contribute to the user experience of the API. I was involved in the ground up to help write these descriptions as opposed to later.
After the developers had developed the API to match the Open API Spec, they then could render the spec using a tool like Swagger.
I apply the tools, practices, and mindset of software development to modernize my client’s documentation to scale with their products.
Documentation that gives the reader a greater understanding of your API, its unique benefits, and how to build an application against it.
Docsites that look beautiful and engage the user through features like advanced search, commenting, ratings, and polling.
'Docs-as-code' tooling and workflows that automate many of the mundane tasks associated with maintaining traditional documents.
“ Mark has a knack for writing documentation that guides the user on the journey of using an API, condensing the endless tables of data into an overall conceptual framework that 'clicks' in the user's mind. There's so much API information that may be 100% factually correct but lacks the ability to build intuition in the user's mind about the value of an API. ”
“ Having worked with Mark in a former life, I can attest to his effort in really understanding his users, oftentimes navigating the hurdles of bureaucracy to access them and build lasting relationships. He saw the value in these relationships of utmost importance to delivering quality documentation, and I believe his work speaks for itself. ”
“ Mark thinks like a developer in terms of automating many of the mundane tasks associated with maintaining tradition documents. Having worked on many development projects over the years, I understand how the maintenance of documentation can be a burden to dev teams and, more importantly, a risk impacting deliveries. Mark listened to our pain points (rather than diagnose) and helped us build a process to address them. ”
If you have any suggestion, project or even you want to say “hello”, please fill out the form below and I will reply you shortly.