RTS Questionnaire · Question 50 of 52 · file: answers/q50.html
Have you been responsible for creating or maintaining technical/application design documentation?
DocumentationDesignLeadership
✅ Yes — documentation ownership has been part of nearly every role, and I treat it as an engineering deliverable with an owner and a review.
Technical detail
- 🏛️ Architecture documentation — high-level and low-level design documents, C4-style context/container/component diagrams, layer and module maps, integration/data-flow diagrams and deployment topology, kept as code (PlantUML/Mermaid) where possible so they version with the repository.
- 📌 Decision records — ADRs capturing context, options, decision and consequences, so future teams understand why the system looks the way it does and can revisit decisions deliberately.
- 🔌 Contracts and data — OpenAPI/GraphQL specifications, event schemas, ER diagrams, data dictionaries, migration and rollback procedures.
- 🛠️ Operational documentation — runbooks for deployment, monitoring, incident response and disaster recovery; onboarding guides and READMEs that let a new developer run the stack locally in hours; environment/configuration references.
- 📊 Delivery documentation — requirement traceability, test strategy and evidence, release notes and change logs for stakeholders and auditors.
🧭 How I keep documentation alive: single source of truth per topic, docs living next to the code, documentation tasks included in the definition of done, periodic review as part of release preparation, and diagrams generated automatically where possible — because stale documentation is worse than none.
🧾 CV evidence: CV: extensive documentation responsibility across roles (risk-platform analytics documentation and operational support at ScotiaGBS, founder-level platform documentation, technical assessment records with full docs folders); CV highlights structured documentation as a working style.