We sat down with Idan Englander, Manager of Technical Writing at Anaconda, to discuss how he scaled from being a solo writer, what documentation processes actually work, and where AI fits (and doesn’t) in the writing workflow. If you’re curious about more of Idan’s writing principles, check out our Guide to Technical Writing.

Building out documentation from 0 → 1

What was your plan of attack when you joined as a solo writer?

I first joined Anaconda just as the last writer was departing the company, giving me sole responsibility over a massive and ever-growing knowledge base.

The company was growing fast (headcount nearly doubled from 80 to 150+ in my first year), and I had to ramp quickly—both to understand the existing state of documentation and to support a steady stream of new product work.

Thrown into the deep end, I needed a clear prioritization strategy. This unfolded as such:

1. Creating new docs for new releases
2. Fixing issues in existing docs
3. Improving style and consistency across the broader documentation

This structure allowed me to set priorities, deliver on time, and fight burnout.

Of the issues that arose, how did you prioritize which to fix first?

To triage, I asked myself two questions for every request:

1. What is the severity? If someone follows these instructions as written, will it block them—or worse, break something?
2. How visible is it? I looked at traffic data, but also at qualitative signals. Was the page linked in prominent places? Was the product in beta?

Weighing both helped me push back on minor asks that could easily consume my time and pull focus from higher-impact work.

How did you introduce consistency for scalability?

Once I got through the initial wave, I focused on building a foundation to prevent new ones—starting with a writing guide.

I started small by just creating rules for myself. I leaned heavily on the Microsoft Style Guide and only deviated when it made sense for our audience. As I spotted inconsistencies, I documented them and slowly built a living style guide.

That groundwork made scaling easier. By the time the team grew, we already had a shared source of truth for voice, structure, and formatting.

The key is that the style guide isn’t just shelfware. We still revise the guide regularly. When we change a rule, we follow it up with cleanup efforts to align existing content, too.

That’s how we maintain consistency across the user experience.

Note: For more information about writing & style guides, check out Idan’s principles in our Guide to Technical Writing.

Anaconda’s most (and least) effective processes

What is your end-to-end flow and tools for writing docs?

Each writer is embedded with a specific product team. We attend syncs when needed, but our real work starts once there’s internal documentation, whether that’s PRDs, Confluence pages, or even just rough outlines.

That internal documentation is the critical unlock. It gives us the context we need to start, and from there, being hands-on in the product is non-negotiable for our writers. We go through the experience ourselves, just like our users will. That not only helps us write clearer documentation, but also lets us flag gaps or usability issues the product and engineering teams might not have noticed.

For tooling, we follow a docs-as-code flow. We track work in Jira, use VS Code or Cursor for writing the markdown, and manage content through Mintlify.

One thing we particularly value is Mintlify’s preview deployments. They give the team and external stakeholders an instant view of the drafted docs, allowing for quicker feedback cycles before final publication.

What processes have been most effective to scale documentation?

The most effective process for scaling documentation has been making it a formal part of the product development lifecycle. We did that through a New Product Introduction (NPI) framework, which explicitly includes documentation in the definition of done.

This checklist has done more than just simplify workflows—it’s driven a cultural shift. By requiring documentation alongside engineering and product deliverables, we’ve made it clear that documentation isn’t an afterthought, but an integral part of the product.

We also created an "Ask Docs" Slack channel to centralize improvement requests, and scripted an automated intake form for streamlined ticket creation. It’s made it easier to track and prioritize needs across the organization, especially as more teams have come to see documentation as a shared responsibility.

What processes haven’t worked as well?

It’s not effective having writers join every engineering standup. In theory, it’s nice to keep us in the loop; in practice, it eats up a ton of time, as much of those standups are spent on internal engineering concerns that don’t impact user-facing content.

We’ve had better luck with targeted 1:1s with PMs or engineers and working asynchronously through tickets and Confluence. It’s not perfect, but it’s proven to be a better use of our time.

We’ve also struggled with documentation getting brought in too late—“Hey, this launches tomorrow, can you write something?”—which is where the NPI process and improved visibility help. The more we embed up front, the higher quality we can make the final docs and end-user experience.

How Anaconda approaches AI documentation

We’ve definitely integrated AI into a few parts of our workflow—mostly the heavy, repetitive tasks.

One project involved retroactively tagging hundreds of pages with metadata for improved search. At first, it felt unscalable. But with Cursor, we were able to script out the structure, then use it to go file-by-file, identify the appropriate keywords, and apply the metadata directly in MDX.

Another teammate used it to audit how a product name was used across thousands of docs. In the past, that would’ve been a painful manual job. Now we can generate a structured spreadsheet straight from the repo, review usage at scale, and decide what’s worth keeping or pruning.

That being said, it’s far from perfect. Hallucinations are a headache, like sections randomly removed or content restructured when the instructions were simply to “add a keyword”. There’s a lot of back-and-forth, clarifying instructions, and even asking separate AI chatbots how best to communicate with their own kind.

Still, it’s been a useful accelerant. Some writers might be hesitant to admit using AI, but now it’s just part of how we work.

AI won’t replace technical writers, but technical writers who use AI will absolutely outpace the ones who don’t.

The next chapter

Anaconda’s documentation journey reflects what many teams experience: starting with one person juggling priorities, and steadily building the systems, practices, and team needed to support growth.

They recently migrated their documentation to Mintlify as part of that evolution. It gives their writers the space to focus on content, not upkeep—and it shows in the quality of what they’re publishing.

If you’re curious about up-leveling your technical writing, or if you’re thinking through how to scale your own docs practice, chat with a Mintlify docs expert today.

‍