In our latest episode on the Knowledgebase Ninjas podcast, we have Avi Chazen from Sage discussing various aspects of technical communication. He also shares thoughts on the recent rebranding of the content team within the organization.
- Avi’s LinkedIn
- 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.
- 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.
- His first job as a technical communicator was for BMC- a legacy software that was moving from On-prem to SaaS.
- 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: