From Writers to Engineers: The Evolution of Product Content Engineering

 Beth Lemesany and Dawn Bunting, of ServiceNow, noted that we weren't just just supporting content, but engineering the systems behind it. Writers wear a lot of different hats. Important to have clarity in your role. 

Do you troubleshoots content issues, build content, use scripts? Do you consider how content scales, or work with engineers or tool admins? You might be an engineer already. 

When yo rebrand to an engineer, there is less context shifting, get to focus more on strategy and scale, getting pulled into the right conversations, and get built-in efficiencies. 

Product Content Engineering engineered conversion from wiki, built DITA-OT transforms, and supported writers with DITA training. 

Eventually moved from support to tools, become proactive instead of reactive. Started to think about scaling. Generated a classification map for search taxonomy. Created automated tests. Exposed to "engineering" without yet calling it that. 

Leared to think like engineers, started to deliver like them. Didn't just level up, but re-orged up. Learned to think in terms of projects, automation, scalability, and maintainability. Team had a PM, which helped in visibility. 

As scope grw, so did structure. Identifies type of work through mandatory ticketing. Split work into categories, such as support work, project work, and technical debt (later adding technical wealth), and leaned into agile, which allowed planning for capacity. That allowed respect for capacity, allowing us to say "no" more often, and allowing the ability to advocate for headcount. 

Best practices provide consistency and efficiency. Architecture diagram creates visibility and collaboration to help understand how the systems work, creating shared understanding and clarity and accountability. A change management framework protects the user experience, creates alignment across teams, and scales. Recurring meetings and ceremonies allow for structure and focus, helps catch and fix real problems, and makes work easier to sustain. Coding best practices keeps code maintainable, supports collaboration, and reduces risk. 

When we faced resistance and skepticism, we turned it around by building credibility through delivery.  

Scaling is harder than solving. That's why you give the work structure.