I provide free mentorship for aspiring and motivated technical writers of all seniority levels.

You can book a session for free on ADPlist. I use this platform to manage my calendar and booking.

Before you book a slot, consider the following information:

• All mentorship is completely free.
• All mentorship is done by me personally.
• Please respect my time and effort: I’m not here to work instead of you. You will be doing the work, and I will be guiding you. The work can be your real-life documentation-related work, or just working on improving yourself and your public profile.
• This can be a single mentorship session if you have specific questions or want to try whether mentorship works for you.
• However, I recommend considering one of the following specialized mentorship programs.

Everything is completely free of charge but will require some time and effort commitment from both you and me.

For that reason, before enrolling into a mentorship programme, you need to check that you meet the following common and specific prerequisites, and then book a screening call (one hour) with me via ADPlist.

The mentorship sessions are booked in advance outside of ADPlist for those who are selected to join one of the programs.

Common prerequisites

For all the programs below, the following common prerequisites are required:

• English or Russian language proficiency for working and collaboration:
  • Verbal: conversational.
  • Written: reading and writing technical text with minimal external help.
• Personal computer user skills with any OS: enough to work with files, text editors, web browsers, and occasional command line tools.
• Aspiration to work as a technical writer or any other documentation-specific role.

Career start (Technical Writer)

Mentor: Vladimir Izmalkov
Estimated duration: 4 Months
Format: Bi-weekly synchronous sessions + structured asynchronous work
Commitment: ~2-3 hours per week (Mentee self-study & assignments)

Specific prerequisites & selection criteria

To ensure the highest impact, admission to this program is selective. Applicants must meet the following criteria:

• Demonstrated Writing Aptitude Applicants must submit one of the following:
  • a portfolio of technical writing samples,
  • a technical blog with several substantial posts, or
  • evidence of meaningful open-source documentation contributions.
• Technical Curiosity Applicants should demonstrate a basic understanding of software development concepts, or equivalent familiarity with another professional or scientific domain (for example, biology, astronomy, mechanical engineering).

Program objectives

By the end of the programme, mentees will:

1. Build a solid foundation in skills for creating and improving technical documentation.
2. Understand what day-to-day work as a technical writer involves, including expectations and professional standards.
3. Leave with a personalized development plan to strengthen skills and gain relevant experience.

Curriculum

The curriculum includes the following topics:

1. Introduction to technical writing (1 hour online, 5 hours self-study)
2. Tooling overview (2 hours online, 3 hours self-study)
3. Documentation types (2 hours online, 5 hours self-study)
4. Documentation processes (1 hour, 2 hours self-study)
5. Soft-skills (1 hour online, 2 hours self-study)
6. Job hunting (2 hours online, 5 hours self-study)

Flexibility

Time for online sessions can be booked in advance, either in the evening hours or during weekends (UTC timezone).

Session pacing (length and frequency) may be adjusted by request for mentees who demonstrate strong consistency and progress.

Docs-as-code

Mentor: Vladimir Izmalkov
Estimated duration: ~5 months
Format: Bi-weekly live sessions (1 hour) + structured asynchronous work
Time commitment: ~2-3 hours per week (Mentee self-study & assignments)

Specific prerequisites & selection criteria

Admission is selective to ensure the programme remains high-impact. Applicants must meet the following criteria:

• Demonstrated Writing Aptitude Applicants must submit one of the following:
  • a portfolio of technical writing samples,
  • a technical blog with several substantial posts, or
  • evidence of meaningful open-source documentation contributions.
• Basic technical expertise Some familiarity with Git, text editors, web sites, and CLI usage.
• Motivation to adopt workflows Willingness to learn and consistently apply version-controlled, review-based documentation practices.

Program objectives

By the end of the programme, mentees will:

• Build confidence working with documentation as code: version control, reviews, and CI-friendly workflows.
• Learn to structure documentation repositories for maintainability and collaboration.
• Deliver a publishable docs project (or a meaningful improvement to an existing one) that demonstrates industry-standard practice.

Curriculum

The curriculum includes the following topics:

1. Docs-as-code basics
2. Information architecture and single-sourcing
3. Build systems and local previews
4. Git usage for documentation
5. PR reviews for documentation
6. Automated documentation testing
7. CI/CD for documentation
8. Releases
9. Feedback gathering and improvement loops
10. Portfolio building

Each topic roughly requires one hour online and 4 hours of self-study. Both times can be flexible and adopted to interests of a particular mentee.

Flexibility

Time for online sessions can be booked in advance, either in the evening hours or during weekends (UTC timezone).

Session pacing (length and frequency) may be adjusted by request for mentees who demonstrate strong consistency and progress.

AI-assisted technical writing

Mentor: Vladimir Izmalkov
Estimated duration: ~8 months
Format: Bi-weekly live sessions (1 hour) + asynchronous practice and assignments
Time commitment: ~2–3 hours per week (Mentee self-study & assignments)

Specific prerequisites & selection criteria

Admission is selective to ensure responsible, effective use of AI in professional writing. Applicants must meet the following criteria:

• Demonstrated Writing Aptitude Applicants must submit one of the following:
  • a portfolio of technical writing samples,
  • a technical blog with several substantial posts, or
  • evidence of meaningful open-source documentation contributions.
• Basic technical expertise Some familiarity with Git, text editors, web sites, and CLI usage.

Program objectives

By the end of the programme, mentees will:

• Learn AI tools to accelerate drafting, editing, and research—without compromising accuracy or trust.
• Establish a repeatable workflow for AI-assisted documentation that includes verification and human judgment.
• Produce a portfolio-ready documentation deliverable demonstrating responsible AI use and measurable improvements.

Curriculum

The curriculum includes the following topics:

• Introduction to AI-writing in technical documentation
• Prompting for documentation work:
  • Result-oriented approach and quality control
  • Outlining and information design with AI
  • Drafting workflows
  • Proofreading, editing, rewriting
  • Working with SMEs
  • Transformations at scale
  • AI for docs maintenance
• Confidentiality, compliance, responsibility
• Metrics
• Portfolio representation

Each topic is designed to take roughly one hour online and 4 hours of self-study. Both times can be flexible and adopted to interests of a particular mentee.

Flexibility

Time for online sessions can be booked in advance, either in the evening hours or during weekends (UTC timezone).

Session pacing (length and frequency) may be adjusted by request for mentees who demonstrate strong consistency and progress.

🚀 The Future of Documentation: Ultra-Fast UX Meets AI Integration 🚀

The demand for quick, efficient learning solutions has never been higher. As a professional technical writer, I’ve observed a significant shift towards ultra-fast learning—a modern trend where documentation is optimized for the fastest possible user experience (UX). This isn’t about the traditional, comprehensive journey through learning materials. Instead, it’s about delivering concise, immediately actionable knowledge with good navigation—perfect for the professional on the run. This approach caters to the modern learner’s desire to solve the task at hand rather than learn a new tool, enabling them to apply new knowledge without skipping a beat in their busy schedules.

🔮 But what does the future hold?

As we stand on the cusp of the next big trend, it’s becoming clear: the optimization of documentation for training AI to answer user’s product-related questions. Imagine a world where your search for answers is met not just with text, but with an intelligent, conversational agent ready to guide you through the product in real-time. This isn’t just about faster learning; it’s about smarter, more interactive, and deeply personalized experiences.

💪 The potential benefits are immense:

Reduced Learning Curves: Users can jump straight into using products with minimal upfront learning. Increased Productivity: Immediate, AI-driven responses mean less time searching for answers and more time focusing on what matters. Enhanced User Satisfaction: Personalized, AI-driven support can significantly enhance the user experience, leading to higher satisfaction and loyalty.

Naturally, the role of technical writers and content creators should evolve. We’ll not only create documentation but also design and refine the content that fuels these AI systems. Maybe even help train and test artificial intelligence. It’s a thrilling prospect—bridging the gap between human knowledge and artificial intelligence to create a seamless, intuitive learning experience.

We’re laying the groundwork for a future where AI-enhanced documentation revolutionizes how we acquire knowledge and interact with technology. The journey from rapid consumption to interactive, AI-driven learning is just the beginning, and it promises to reshape our approach to knowledge acquisition in profound ways. 🤖

💪The Power of Git for Technical Writers

Git is a formidable tool known for its capacity to track changes and manage versions across all file types, especially plain text documents. For technical writers, Git opens up a world of possibilities, significantly boosting the efficiency and quality of documentation workflows while providing a dependable reference for software product details. Let’s delve into the top reasons why Git is so beneficial for technical writers.

1. Keeping Pace with Fast-Changing Products 🚀

In today’s fast-evolving technological landscape, software-related products undergo rapid changes. Git allows technical writers to keep documentation in sync with product updates in the most efficient way. By integrating documentation into the development cycle, writers can update docs concurrently with product changes, ensuring accuracy and relevancy.

2. Collaborating Seamlessly with Other Authors 🤝

Git’s robust collaboration features, like PRs, forks, and branches, facilitate a seamless process for teamwork among technical writers, engineers, and other stakeholders. Whether you’re merging changes from multiple authors or reviewing edits, Git provides a transparent and efficient basis for collaborative writing, reducing overlaps, and solving content conflicts.

3. Leveraging Scalability of the Process 📈

Git’s infrastructure supports teams and documentation projects of any size, making it easier to scale your documentation efforts as your product grows.

4. Ensuring Transparency and Accountability 🔍

With Git, every change to the documentation is tracked, including who made the change, what was changed, and when it was changed. This transparency fosters a culture of accountability, making it easier to review historical changes and understand the evolution of your documents.

5. Embracing the Docs-as-Code Approach 📚

Adopting a docs-as-code methodology means treating documentation with the same reverence and scrupulosity as code. Git enables technical writers to apply software development practices like version control, issue tracking, single-sourcing, and automation to their documentation. This approach not only streamlines the workflow but also ensures consistency and quality in technical documentation.

6. Leveraging Software Engineering Tools 🛠️

Technical writers working on software documentation can benefit immensely from using Git, as it allows them to use the same tools as developers. This shared toolset facilitates better communication and understanding between writers and developers, leading to more accurate and effective documentation. Especially so if the targeted audience is also related to software development.

7. Utilizing Continuous Integration/Continuous Deployment (CI/CD) 🔄

By integrating documentation into CI/CD pipelines, technical writers can automate parts of the documentation process, such as testing links or code snippets, deploying updates, and checking for mistakes in grammar, stop-words, common typos, and style guide compliance. This ensures that the documentation is always up to date and reduces the manual effort required for updates.

🏁 Conclusion 🏁

The versatility of Git extends far beyond its roots in software development, offering technical writers a powerful tool for managing documentation. By learning Git, technical writers can not only enhance the effectiveness and quality of their work but also collaborate and communicate with other content creators and engineers more easily. Embrace Git, and unlock a new level of precision and efficiency in your technical writing endeavors.

What has been your experience with Git in technical writing? Do you see it as an essential tool in your documentation toolkit? Share your thoughts and experiences in comments to my LinkedIn post!

In the innovative landscape of technical writing, the Docs-as-Code approach revolutionizes how we create, manage, and publish documentation. Central to this paradigm shift are three lightweight markup languages: Markdown, reStructuredText, and AsciiDoc. Each brings its unique strengths to the forefront, enabling seamless integration of documentation into the software development workflow.

• Markdown stands out for its simplicity and widespread adoption. From GitHub repositories to blogging platforms, its straightforward syntax ensures that documentation is easily readable by humans and machines alike, making it the go-to choice for quick, effective content creation.

• reStructuredText (reST), deeply entrenched in the Python community, offers a rich set of features and flexibility, making it ideal for technical documentation that requires detailed structuring and cross-referencing. Its compatibility with Sphinx turns complex documentation projects into navigable, well-organized web pages.

• AsciiDoc, with its robustness and versatility, bridges the gap between the straightforwardness of Markdown and the complexity of reST. It excels in scenarios where the documentation needs to be converted into multiple output formats, such as HTML, PDF, and EPUB, without sacrificing the depth or quality of content.

The Docs-as-Code approach, empowered by these languages, not only streamlines documentation workflows but also enhances collaboration between writers and developers, ensuring that documentation keeps pace with software updates. By adopting tools and practices from software development, such as version control, continuous integration, and automated testing, we can produce documentation that is more accurate, accessible, and aligned with user needs.

📝✨ In the world of sophisticated open-source products, we often find ourselves walking a tightrope between two seemingly conflicting goals: crafting comprehensive and accurate documentation and ensuring that it’s engaging and inspiring for our readers. This balancing act presents a unique set of challenges that I’ve come to appreciate in my journey as a technical writer.

🔍 Precision vs. Engagement: The core challenge lies in presenting technical information in a precise, comprehensive, yet captivating way. When documentation for an open-source product becomes overly intricate and packed with specifics, we risk losing those readers who may lack the time or motivation to delve deep. Yet, we risk alienating readers and losing their trust by making it less accurate and more engaging. At the heart of good technical writing is the delicate task of weaving together technical accuracy with engaging educational content. It’s about finding that sweet spot – where comprehensiveness meets readability, making the reader feel confident and interested, not overwhelmed.

👥 Understanding the Audience: A key aspect is knowing your audience. The approach for experienced professionals differs vastly from that for novices. Tailoring the content to meet the reader’s expectations and level of understanding without compromising on technical integrity is a skill that develops over time.

🔄 Feedback and Continuous Improvement: The process doesn’t end at publication. Feedback is a crucial element. Gathering metrics, engaging with the readers, understanding their pain points, and continuously refining the content based on real-world usage make the documentation a living, evolving entity.

💡 Gain trust: Building trust with your reader is important, especially for tech-savvy audiences like engineers and scientists. Any errors, including inaccurate or outdated information, reduce the trustworthiness of the documentation as a source of truth.

In conclusion, the journey of creating good documentation for a sophisticated open-source product is about much more than just documenting facts. It’s about inspiring confidence, igniting curiosity, and simplifying complexity. This challenging yet rewarding path continuously teaches the importance of balancing detailed accuracy with engaging storytelling.

As a technical writer with more than a decade of experience in software development, I’ve come to embrace the Docs-as-Code methodology as my preferred approach. This technique, borrowing best practices from software development, transforms the way we handle documentation, treating it much like we do code. It usually involves storing the content in a Git repository as a text file. Our user-facing documentation needs to undergo a building process to create the output format(s) needed: HTML (web page), PDF, .docx, etc.

There are several alternatives to this approach, such as:

• Text Processors (e.g., Microsoft Word),
• Dedicated Technical Writing Software (Adobe FrameMaker, MadCap Flare),
• Knowledge Base Management Tools (Confluence, MediaWiki),
• Content Management Systems (WordPress, Joomla),
• Document Collaboration Platforms (SharePoint, Quip),
• In-Code Documentation (Doxygen for code comments).

Here are my thoughts on the Pros and Cons of the Docs-as-Code approach:

Pros:

• Version Control: very transparent, reliable, and accountable process of managing version/changes with VCS like Git.
• Collaboration: SMEs (like software engineers) are familiar and experienced with VCS (like Git). The usage of VCS lets us scale the documentation development process to any size of the documentation team.
• Consistency: features like single sourcing, transparent change history, merging changes, forking, and branching let us preserve the consistency of documentation during any changes. Additionally, splitting content from design enables consistent representation of documentation.
• Automation: a DevOps specialist can set up CI/CD for the documentation building pipeline that will publish updated documentation in any number of formats to any number of platforms from just a single commit. This pipeline can even include automated tests for the documentation content and output.
• Single Source of Truth: maintaining all content in one place, avoiding discrepancies, and having a reliable change process.
• Popularity in Open Source: most tools used in Docs-as-Code are open source, and the approach itself is very popular in open-source documentation.
• Open formats: simple text formats are usually easily converted. No vendor locks.

Cons:

• Learning Curve: requires familiarity with Git and a particular lightweight markup language (e.g., Markdown, AsciiDoc), which can be challenging for non-technical contributors.
• Overhead: integrating documentation into the development workflow adds initial setup and maintenance efforts.
• Tool Dependency: relies on specific tools and platforms, which might limit flexibility in some cases.

In conclusion, while Docs-as-Code is not a one-size-fits-all solution, its alignment with agile practices and software development tools, as well as its emphasis on transparency and collaboration, make it a standout choice for software products and projects where documentation may be as dynamic as the software it supports.

Find a summary in my Resume.

Additional information is available in my LinkedIn profile.

If you need more information, feel free to contact me directly. My preferred methods of communication are Telegram, WhatsApp, and E-mail.

I have been working in IT and technical communication since 2008.

My first job was at my University, where I worked as a part-time technician, documenting educational projects and events and supporting some IT systems. I also worked as a part-time software developer during my university days.

After graduation, I joined the All-Russian Research Institute for Civil Defense and Emergencies as a post-graduate. I had my postgraduate studies, and after obtaining a PhD, I had a chance to start a new department in the same Research institute from scratch.

After 8 years in the Research institute, I wanted to try some enterprise software development. I didn’t want to pursue a software engineering career because I didn’t think this craft was interesting enough. Instead, I found that technical communication is much more rewarding and interesting. My years in research provided me with a lot of experience with documentation, a keen eye for detail, and a good understanding of software development life cycle and technologies.

In 2019, the Mail.RU Group (later renamed to the VK) recruited me to join its B2B unit, namely the Tarantool team, as a Senior Technical writer. VK is an IT giant in Russia that has many businesses, including the most popular social network in Russia. We were developing an open-source in-memory transactional database with a built-in application server in Lua, which I was documenting in English and later translating to Russian.

In 2020, I was promoted to the Team Leader of the documentation team for the VK Private Cloud product. That was a time of tremendous professional growth for me. I have recruited and trained my own cross-functional documentation team. I was learning people management, project management, agile methodology, and team management processes.

In 2022, I was promoted to lead a second documentation team. Since then, I have led both Private Cloud and Public Cloud documentation for VK.

Then, I migrated from Russia and was looking for a relocation opportunity in the EU region. I joined the Vaticle LTD as a Senior Technical Writer to pursue a career in the UK. I’m the company’s first and only documentation specialist. Now, I work with a great team of very talented and inspired engineers to create the very first polymorphic database.

In 2023, I joined the Institute of Scientific and Technical Communications. Now I’m the head of the London Group and organize our monthly meetings.

I graduated from the greatest technical university of Russia (Bauman Moscow State Technical University) with two degrees:

1. Master’s degree in Spacecraft engineering.
2. Bachelor’s degree in Computer science.

My first choice was a Spacecraft engineering degree, as I desired space exploration and engineering. In my later years at the university, I realized that my true passion is information technology and computer science. That’s why I got a second degree from the same university.

Right after University, I joined the All-Russian Research Institute for Civil Defense and Emergencies for my postgraduate studies. That is where I got my third degree:

3. PhD in Technology with a special topic on the Reliability of single emergency number systems in Russia.

My career continued with the research institute, as I became a researcher and later a Head of a Research department for Automated systems.

This will be a page with links to multiple examples of my dinest work. Unfortunately, it is not ready yet =D.

You see, most of my current documents are under NDA so I will try and do some test exercises without any confidential materials and publish it here.

But for now I would like to publish a link for one example of my open source contribution.