Rebrand: 'technical writing' -> 'docs engineering' across site

35 substitutions across 14 files via case-preserving regex:
  Writing portfolio        -> Docs Engineering Portfolio
  Lead Technical Writer    -> Lead Docs Engineer
  Technical Writer         -> Docs Engineer
  technical writing        -> docs engineering
  technical writer         -> docs engineer
  tech writer              -> docs engineer

Covers home page job titles, meta description, /docs/intro overview,
and every role-specific page under docs/ably, docs/couchbase,
docs/cdw, and docs/atlas-copco. Site copy in CheatSheetSeries (OWASP
upstream clone) intentionally left alone.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Author: franrob-projects

docs/ably/sse-documentation.md

@@ -42,4 +42,4 @@ This connected directly to the developer journey mapping work I was doing simult
 
 The revised SSE documentation became one of the most-referenced pages in Ably's developer resources. More importantly, it reduced support ticket volume for SSE-related issues and improved successful implementation rates for developers choosing this protocol.
 
-The systematic approach to troubleshooting and the focus on production-ready code examples influenced how I approached other protocol documentation at Ably. The principles I developed here - layered complexity, practical examples, and systematic troubleshooting - became central to all my subsequent technical writing projects.
+The systematic approach to troubleshooting and the focus on production-ready code examples influenced how I approached other protocol documentation at Ably. The principles I developed here - layered complexity, practical examples, and systematic troubleshooting - became central to all my subsequent docs engineering projects.

docs/ably/webhooks-security.md

@@ -4,7 +4,7 @@ sidebar_position: 2
 
 # Webhooks security documentation
 
-When I took on rewriting Ably's [webhook security documentation](https://ably.com/docs/general/webhooks), I faced a classic technical writing challenge: how do you make security concepts practical without compromising safety? Security documentation typically falls into two traps - either it's too simplistic to be useful, or so complex that developers skip the security altogether.
+When I took on rewriting Ably's [webhook security documentation](https://ably.com/docs/general/webhooks), I faced a classic docs engineering challenge: how do you make security concepts practical without compromising safety? Security documentation typically falls into two traps - either it's too simplistic to be useful, or so complex that developers skip the security altogether.
 
 The existing documentation had become a collection of theoretical concepts with few practical examples. Developers were implementing webhooks without proper security, not because they didn't care about security, but because they couldn't figure out how to implement it correctly from the documentation.
 

docs/atlas-copco/flow-drill-fastening.md

@@ -40,4 +40,4 @@ Similar to how I restructured information architecture at Ably, I organized this
 
 The tape feed documentation became a model for other Atlas Copco product lines. The modular structure made it easy to adapt for different markets and applications. More importantly, it reduced the learning curve for new installations and improved troubleshooting efficiency when production issues arose.
 
-This project taught me that industrial documentation requires the same user-centered thinking as software documentation, but with much higher stakes. The principles I learned here - clarity, safety-first thinking, and global accessibility - influenced how I approached every subsequent technical writing project.
+This project taught me that industrial documentation requires the same user-centered thinking as software documentation, but with much higher stakes. The principles I learned here - clarity, safety-first thinking, and global accessibility - influenced how I approached every subsequent docs engineering project.

docs/atlas-copco/index.md

@@ -4,7 +4,7 @@ sidebar_position: 4
 
 # My work at Atlas Copco
 
-I worked as a Technical Writer at Atlas Copco from 2018 to 2021, writing documentation for industrial manufacturing equipment. My job was translating complex joining and fastening technologies into guides that engineers and factory workers could actually use.
+I worked as a Docs Engineer at Atlas Copco from 2018 to 2021, writing documentation for industrial manufacturing equipment. My job was translating complex joining and fastening technologies into guides that engineers and factory workers could actually use.
 
 
 ## About Atlas Copco
@@ -90,6 +90,6 @@ You can see the results of this work in Atlas Copco's current resources:
 
 ## What I learned
 
-Working at Atlas Copco taught me that technical writing isn't just about explaining how things work - it's about enabling people to do their jobs safely and efficiently. When your documentation goes to factories around the world, you realize how important clear, practical writing really is.
+Working at Atlas Copco taught me that docs engineering isn't just about explaining how things work - it's about enabling people to do their jobs safely and efficiently. When your documentation goes to factories around the world, you realize how important clear, practical writing really is.
 
-The manufacturing industry showed me documentation at its most critical - where unclear instructions don't just frustrate users, they can shut down production lines or hurt people. That experience shaped how I approach all technical writing now.
+The manufacturing industry showed me documentation at its most critical - where unclear instructions don't just frustrate users, they can shut down production lines or hurt people. That experience shaped how I approach all docs engineering now.

docs/atlas-copco/industrial-dispensing.md

@@ -4,7 +4,7 @@ sidebar_position: 4
 
 # Henrob blow feed riveting documentation
 
-The Henrob blow feed riveting system presented a unique technical writing challenge at Atlas Copco. This was energy-efficient technology - achieving just 7Wh per rivet while delivering setting forces up to 85,000 N. The engineering was impressive, but making it accessible to production teams required a completely different approach.
+The Henrob blow feed riveting system presented a unique docs engineering challenge at Atlas Copco. This was energy-efficient technology - achieving just 7Wh per rivet while delivering setting forces up to 85,000 N. The engineering was impressive, but making it accessible to production teams required a completely different approach.
 
 ## Understanding the technology first
 
@@ -52,7 +52,7 @@ I created modular documentation that could be adapted for different markets whil
 
 Blow feed riveting didn't exist in isolation - it was part of Atlas Copco's complete joining portfolio. I made sure the documentation clearly explained when blow feed was the right choice versus tape feed or other methods.
 
-This systems thinking became central to how I approached technical writing throughout my career. Individual technologies are just components in larger solutions, and documentation needs to help users understand those connections.
+This systems thinking became central to how I approached docs engineering throughout my career. Individual technologies are just components in larger solutions, and documentation needs to help users understand those connections.
 
 ## Results and continuous improvement
 

docs/atlas-copco/self-pierce-riveting.md

@@ -142,4 +142,4 @@ The comprehensive documentation served critical business functions:
 - **Consistent training.** Standardized learning materials for global training programs.
 - **Continuous improvement.** Documentation framework supporting ongoing process optimization.
 
-This SPR documentation project demonstrated how technical writing can directly impact manufacturing quality, efficiency, and global standardization in advanced automotive joining technologies.
+This SPR documentation project demonstrated how docs engineering can directly impact manufacturing quality, efficiency, and global standardization in advanced automotive joining technologies.

docs/cdw/index.md

@@ -14,7 +14,7 @@ The documentation challenge was helping customers understand not just what techn
 
 ## Writing for multiple decision makers
 
-Unlike the technical writing I had done at Atlas Copco or would later do at Ably, CDW documentation needed to serve multiple audiences simultaneously. A single cloud migration project might involve IT directors, compliance officers, finance teams, and technical implementers - each with different concerns and information needs.
+Unlike the docs engineering I had done at Atlas Copco or would later do at Ably, CDW documentation needed to serve multiple audiences simultaneously. A single cloud migration project might involve IT directors, compliance officers, finance teams, and technical implementers - each with different concerns and information needs.
 
 I developed a modular documentation approach that provided different levels of detail for different roles while maintaining consistency across the overall solution architecture. This experience later influenced how I approached developer journey mapping at Ably.
 
@@ -40,7 +40,7 @@ I developed templates for solution architecture documentation that showed custom
 
 ## Supporting the sales process
 
-Unlike pure technical writing, my CDW work required understanding how documentation fits into the sales process. Technical materials needed to support proposal development, customer education, and post-sale implementation planning.
+Unlike pure docs engineering, my CDW work required understanding how documentation fits into the sales process. Technical materials needed to support proposal development, customer education, and post-sale implementation planning.
 
 I created reusable content libraries that sales teams could adapt for different customer situations without starting from scratch each time. This improved proposal quality and consistency while reducing preparation time for complex technical sales.
 
@@ -60,10 +60,10 @@ This specialization taught me the importance of understanding vendor ecosystems
 
 The documentation frameworks I developed had measurable impact on CDW's sales process. Standardized technical materials improved proposal quality, reduced preparation time, and increased win rates by helping customers understand complex solutions more clearly.
 
-More importantly, the documentation improved implementation success rates by setting clear expectations and providing practical guidance that customers could follow during project execution. This showed me how good technical writing directly impacts business outcomes in enterprise environments.
+More importantly, the documentation improved implementation success rates by setting clear expectations and providing practical guidance that customers could follow during project execution. This showed me how good docs engineering directly impacts business outcomes in enterprise environments.
 
 ## Enterprise writing lessons
 
-Working at CDW taught me that technical writing in enterprise sales is fundamentally about building confidence. When customers are investing millions in technology implementations, they need to believe that the vendor truly understands their operational realities and can deliver successful outcomes.
+Working at CDW taught me that docs engineering in enterprise sales is fundamentally about building confidence. When customers are investing millions in technology implementations, they need to believe that the vendor truly understands their operational realities and can deliver successful outcomes.
 
-The documentation skills I developed at CDW - modular content architecture, audience-specific information design, and business outcome orientation - became central to how I approached all subsequent technical writing projects. These principles proved essential when I later worked on developer experience optimization at Ably.
+The documentation skills I developed at CDW - modular content architecture, audience-specific information design, and business outcome orientation - became central to how I approached all subsequent docs engineering projects. These principles proved essential when I later worked on developer experience optimization at Ably.

docs/couchbase/index.md

@@ -4,7 +4,7 @@ sidebar_position: 3
 
 # My time at Couchbase
 
-I was Lead Technical Writer at Couchbase from 2022 to 2023, focused on their mobile database platform. The main challenge was making NoSQL databases approachable for mobile developers who were used to simpler storage solutions.
+I was Lead Docs Engineer at Couchbase from 2022 to 2023, focused on their mobile database platform. The main challenge was making NoSQL databases approachable for mobile developers who were used to simpler storage solutions.
 
 ## The problem I inherited
 

docs/couchbase/repository-consolidation.md

@@ -4,7 +4,7 @@ sidebar_position: 3
 
 # Repository consolidation project
 
-When I joined Couchbase as Lead Technical Writer, I inherited a documentation system that had grown organically over years of product development. What started as separate documentation efforts for different products had become a maintenance nightmare that made it nearly impossible for developers to understand how Couchbase's ecosystem worked together.
+When I joined Couchbase as Lead Docs Engineer, I inherited a documentation system that had grown organically over years of product development. What started as separate documentation efforts for different products had become a maintenance nightmare that made it nearly impossible for developers to understand how Couchbase's ecosystem worked together.
 
 The [repository consolidation project](https://github.com/couchbase/docs-server) became my largest undertaking - not just moving files from one place to another, but redesigning how technical content could scale with a multi-product platform. This project taught me that information architecture isn't just about organizing content - it's about enabling developers to understand complex systems.
 

docs/intro.md

@@ -2,9 +2,9 @@
 sidebar_position: 1
 ---
 
-# Writing portfolio
+# Docs Engineering Portfolio
 
-When I started my career in technical writing, I thought documentation was just about explaining how things work. After years of working with developers at companies like Ably, Couchbase, and Atlas Copco, I've learned that great documentation is really about enabling people to succeed with complex technology.
+When I started my career in docs engineering, I thought documentation was just about explaining how things work. After years of working with developers at companies like Ably, Couchbase, and Atlas Copco, I've learned that great documentation is really about enabling people to succeed with complex technology.
 
 My focus has been on taking complicated systems - from real-time messaging platforms to industrial manufacturing equipment - and creating documentation that developers and engineers can actually use to solve real problems. Each project taught me something different about how people learn and implement technology.
 
@@ -80,7 +80,7 @@ Led comprehensive information architecture overhaul to improve developer experie
 
 ## My time at Couchbase
 
-As Lead Technical Writer at Couchbase from 2022 to 2023, I worked on making NoSQL databases approachable for mobile developers. The challenge was explaining distributed database concepts to developers accustomed to simpler storage solutions, while maintaining the technical depth needed for production implementations.
+As Lead Docs Engineer at Couchbase from 2022 to 2023, I worked on making NoSQL databases approachable for mobile developers. The challenge was explaining distributed database concepts to developers accustomed to simpler storage solutions, while maintaining the technical depth needed for production implementations.
 
 <div className="work-item">
 
@@ -120,7 +120,7 @@ Consolidated fragmented documentation repositories into unified GitHub monorepo
 
 ## My work at Atlas Copco
 
-Working as a Technical Writer at Atlas Copco from 2018 to 2021 taught me that manufacturing documentation can be life-or-death. When your documentation goes to factories worldwide, unclear instructions don't just frustrate users - they can shut down production lines or cause injuries.
+Working as a Docs Engineer at Atlas Copco from 2018 to 2021 taught me that manufacturing documentation can be life-or-death. When your documentation goes to factories worldwide, unclear instructions don't just frustrate users - they can shut down production lines or cause injuries.
 
 <div className="work-item">
 
@@ -165,7 +165,7 @@ Developed technical manuals for Henrob blow feed self-pierce riveting systems, f
 
 ## My work at CDW
 
-My time as a Technical Solutions Specialist at CDW UK from 2021 to 2022 showed me how technical writing works in enterprise sales. Unlike developer-focused documentation, enterprise customers needed materials that helped multiple stakeholders - from IT directors to compliance officers - understand complex technology implementations.
+My time as a Technical Solutions Specialist at CDW UK from 2021 to 2022 showed me how docs engineering works in enterprise sales. Unlike developer-focused documentation, enterprise customers needed materials that helped multiple stakeholders - from IT directors to compliance officers - understand complex technology implementations.
 
 <div className="work-item">
 
@@ -215,6 +215,6 @@ Good documentation enhances learning through low effort and helps people problem
 | **Tested** | If the code doesn't work, the documentation is useless |
 | **Visual when needed** | Strategic use of images and diagrams to clarify complex concepts |
 | **Workflow-oriented** | Create maintainable documentation workflows that scale with teams |
-| **AI-assisted** | Implement AI systems for grunt work, freeing technical writers and UX teams to focus on user experience optimization |
+| **AI-assisted** | Implement AI systems for grunt work, freeing docs engineers and UX teams to focus on user experience optimization |
 
 </div>