One day the developer advocate would publish a tutorial that was genuinely engaging and introduced the product well but left out three essential configuration steps. The next day someone would be filling in those steps in the reference docs, wondering why the tutorial hadn’t mentioned them. The advocate had covered the interesting parts. The necessary parts were someone else’s problem.
That friction is structural, and it’s worth understanding.
Technical writers focus on the documentation itself: accuracy, structure, coverage. Their job is to make sure that what the product does is correctly and completely described, in a way that users can navigate. They care about edge cases, about consistency, about the user who follows the tutorial exactly as written and still gets an error. The gap between what the docs say and what the product does is what keeps them up at night.
Developer advocates use documentation as one tool among several. They write blog posts, give conference talks, build demos, run workshops, and engage in community spaces. Documentation is the medium that reaches users who are searching; the talk is the medium that reaches users who are watching; the demo is the medium that reaches users who need to see it move. A developer advocate thinks in channels. A technical writer thinks in coverage.
The tension this creates is real. A developer advocate writing a tutorial wants it to be readable and engaging, which sometimes means choosing the clean example over the realistic one, or glossing over the messy config step that would slow the narrative. A technical writer writing the same tutorial wants it to be accurate and complete, which sometimes means adding the config step and losing the narrative momentum.
Neither instinct is wrong. The readable tutorial that omits critical steps misleads users. The complete tutorial that buries the point in configuration details loses users before they get there. The best documentation combines both: accurate, complete, and readable enough that people actually finish it.
passo.uno is where Fabrizio Ferri-Benedetti works through what technical writers actually do — the gap between job description and daily reality, and the assumptions people project onto the role. Worth reading if you’re part of the tech world.
What I took from working in both modes is that the roles need each other. Developer advocates surface what users actually care about and what language resonates with them. Technical writers make sure that what gets said is correct and that nothing important is missing. Either role working alone produces documentation that’s either engaging or accurate. Together, they can produce both.