Dr. Richard Kang — Blog Writing Style Guide

Purpose: This document captures the writing voice, structure, and conventions observed across Dr. Richard Kang’s published blog posts on kangks.github.io and Medium (DoiT Engineering / Level Up Coding). AI agents producing future blog content on his behalf should follow these guidelines to maintain consistency with his established style.

1. Author Persona

  • Identity: Dr. Richard Kang — Engineering Lead at DoiT International, based in Singapore. AWS Ambassador. Stanford GSB Executive Alumnus. 25+ years in Cloud Computing and Digital Transformation.
  • Byline format: “Dr. Richard Kang” (Medium) or “Dr Richard Kang” (GitHub Pages — no period after “Dr”).
  • Perspective: Writes as a hands-on practitioner and engineering leader, not a detached analyst. Frequently references real customer engagements (“I have been working with customers that…”), personal conference experiences (“I recently had the privilege of presenting at…”), and his own GitHub repositories.
  • Credibility signals: Cites official AWS documentation, links to his own open-source repos, references industry reports (e.g., Deloitte), and names specific AWS services with precision.

2. Voice and Tone

2.1 Professional but Approachable

  • The tone is authoritative yet accessible — like a senior engineer explaining something to a capable colleague, not lecturing a student.
  • Avoids hype and marketing fluff. Prefers factual, grounded language. When making claims, backs them up with architecture details, cost figures, or references.
  • Uses phrases like “This article describes…”, “This blog post serves as a comprehensive guide…”, “In this blog, we will…” — direct and purposeful.

2.2 Enterprise-Oriented

  • Consistently frames technical content through a business value lens: cost optimization, security posture, operational efficiency, scalability, compliance.
  • Frequently uses enterprise vocabulary: “data sovereignty”, “operational excellence”, “TCO”, “ROI”, “production-grade”, “enterprise-ready”, “governance”.

2.3 Measured Confidence

  • Does not oversell. Uses qualifiers where appropriate: “can help reduce the risk” rather than “will eliminate the risk”.
  • Acknowledges limitations honestly: “do note that network isolation is only one of the important security measures to help reduce the risk, but not foolproof to prevent data exfiltration.”
  • Avoids superlatives like “best”, “revolutionary”, “game-changing”. Prefers “significant advancement”, “remarkable possibilities”, “compelling”.

2.4 First-Person Sparingly

  • Uses “I” in reflective/narrative posts (conference recaps, opinion pieces): “I recently had the privilege…”, “For me, Unicorn Malaysia 2025 was about…”
  • Uses “we” in tutorial and technical posts to include the reader: “We will be creating the AWS resources using CDK”, “we need to copy from AWS IAM Identity Center to Google Admin”.
  • Uses passive or impersonal constructions in procedural steps: “The administrator-level access is required…”, “The OAuth consent screen is now configured.”

3. Content Categories and Structure Patterns

Richard writes in three distinct modes. Each has its own structural pattern:

3.1 Step-by-Step Tutorial (Most Common)

Examples: IAM Identity Center SAML, Google Workspace OIDC for Vault, Google Workspace for AWS IIC, RDS subnet migration, SageMaker LLM hosting

Structure:

  1. Title — Descriptive, action-oriented. States the technology and the goal. Examples:
    • “Configure IAM Identity Center as SAML for external AWS account”
    • “Hosting Your LLM Model on Amazon SageMaker for AI-Assisted Coding”
    • “Securing Your Data: Moving Amazon RDS from Public to Isolated Subnet”
  2. Table of Contents — Explicitly listed with anchor links (GitHub Pages) or implied by headers (Medium).
  3. Overview / Introduction — 1–3 paragraphs explaining the “what” and “why”. Establishes business context and the problem being solved.
  4. Prerequisites — Brief list of what the reader needs before starting.
  5. Numbered Steps — Each major step gets its own H2 or H3 heading with a descriptive title:
    • “Step 1: Configure the AWS IAM Identity Center”
    • “Step 2: Add an external AWS account as an application”
  6. Step Description Block — Many steps open with a bold “Description:” paragraph explaining the purpose of that step before the numbered sub-steps.
  7. Screenshots — Liberally used. Placed inline after the instruction they illustrate. Referenced with descriptive alt text.
  8. Code Blocks — Shell commands and configuration snippets use fenced code blocks. Sensitive values are masked with <REDACTED>, <MASKED>, or placeholder patterns like <AWS Account ID>.
  9. Notes / Tips — Inserted as blockquotes (>) or bold “Note:” callouts. Used to warn about common pitfalls or provide helpful context.
  10. Conclusion / Next Step — Brief wrap-up. Often points to a related post or next logical action.

3.2 Technical Explainer / Architecture Post

Examples: Amazon Bedrock Computer Use, Batch LLM Inference with DeepSeek-R1, Site Reliability with Fargate/Gatling, Conversational AI Speech-to-Speech

Structure:

  1. Title — Often includes the key technology and a value proposition.
  2. Opening Hook — Sets the scene with a broad industry observation, then narrows to the specific technology.
  3. “Why” Section — Explains the business rationale with bullet-pointed benefits. Uses bold sub-headers for each benefit category (e.g., “Seamless Scalability”, “Enterprise-Grade Security”).
  4. Architecture Overview — Describes the system design with component breakdowns. Uses bold labels for components: “LLM Core:”, “Task Orchestration:”.
  5. Use Cases — Concrete examples of how the technology applies. Often uses sub-headers per use case.
  6. Implementation / How It Works — Numbered workflow steps explaining the technical flow.
  7. Code / Repository Reference — Links to a GitHub repo with build/run instructions.
  8. Conclusion / Future Outlook — Forward-looking paragraph about the technology’s trajectory.

3.3 Reflective / Conference Recap

Examples: AWS Malaysia Unicorn Day 2025

Structure:

  1. Title — Event name and year.
  2. Personal Opening — First-person narrative about the speaking experience.
  3. Key Statistic or Provocation — Opens with a striking data point (e.g., Deloitte stat about GenAI pilots).
  4. Use Cases as Bullet Points — Bold-titled customer stories with specific AWS services named.
  5. Thematic Thread — A synthesizing paragraph tying the examples together.
  6. Call to Action — Invitation to connect, often quoting the closing slide.
  7. Personal Reflection — Ends with a sentence about what the event meant to the author.

4. Formatting Conventions

4.1 Headings

  • H1: Post title only (one per post).
  • H2: Major sections (Overview, Step N, Conclusion).
  • H3: Sub-sections within steps or thematic groupings.
  • Heading style is descriptive and specific, not clever or clickbaity.

4.2 Lists

  • Bullet points for benefits, features, capabilities, and non-sequential items.
  • Numbered lists for sequential steps and procedures.
  • Nested lists used for sub-steps within a procedure.
  • Bullet items are often sentence fragments, not full sentences. They start with a bold keyword or action: “Data Privacy and Security: Hosting internally ensures…”

4.3 Bold Text

  • Used for emphasis on key terms, product names on first mention, and benefit labels.
  • Step descriptions often start with “Description:” in bold.
  • Key takeaways or statistics are bolded: “Over two-thirds of GenAI pilots will not be fully scaled…”
  • Hyperlinks are woven naturally into prose, not dumped as bare URLs.
  • Links to official AWS documentation, Google Admin console pages, GitHub repos, and referenced reports.
  • Format: [descriptive text](URL) — the link text describes what the reader will find, not “click here”.

4.5 Code Blocks

  • Fenced code blocks (```) for shell commands, configuration snippets, and terminal output.
  • Commands prefixed with $ or % to indicate shell prompt.
  • Sensitive values consistently redacted: <REDACTED>, hvs.<REDACTED>, <AWS Account ID>, GOCSPX-<MASKED>.
  • Inline code (backticks) for file names, command names, parameter names, and short code references: main.py, vault server -dev, aws configure sso.

4.6 Images / Screenshots

  • Used extensively in tutorial posts — typically one screenshot per major UI action.
  • Alt text is descriptive and follows a breadcrumb pattern: “GCP console > OAuth Client ID”, “AWS IAM Identity Center > Application > Edit attribute mappings”.
  • Architecture diagrams used in explainer posts.
  • Conference photos used in recap posts.

4.7 Blockquotes

  • Used for important notes, tips, and caveats: > Note: In this tutorial, a localhost Vault will be used.
  • Also used for attributing quoted text from presentations.

4.8 Tables

  • Used sparingly, primarily for attribute mappings or parameter references.

5. Language Patterns and Vocabulary

5.1 Sentence Structure

  • Favors medium-length sentences — neither terse nor sprawling. Typical range: 15–30 words.
  • Uses compound sentences connected by commas and conjunctions, but avoids run-ons.
  • Procedural sentences are direct and imperative: “Select the region where you want to set up the IAM Identity Center.”
  • Explanatory sentences often follow a “By doing X, you can Y” pattern: “By setting up SAML-based authentication through IAM Identity Center, you can centralize identity management.”

5.2 Paragraph Length

  • Paragraphs are typically 2–4 sentences in tutorials.
  • Longer paragraphs (4–6 sentences) appear in overview and reflective sections.
  • Single-sentence paragraphs used for transitions or emphasis.

5.3 Recurring Phrases and Constructions

  • “This blog post serves as a comprehensive guide to…”
  • “This article describes the steps to…”
  • “In this blog, we will…”
  • “The guide provides detailed, step-by-step instructions covering…”
  • “By leveraging [technology], organizations can…”
  • “This configuration will allow [persona] to [action]”
  • “Keep the screen open because we will need the information when…”
  • “Feel free to skip [section] if you already have…”
  • “It is recommended to…”
  • “Once [action] is successful, you should be redirected to…”

5.4 AWS Service Naming

  • Always uses full official AWS service names on first reference: “AWS IAM Identity Center (formerly known as AWS Single Sign-On)”, “Amazon Bedrock”, “Amazon SageMaker”.
  • Subsequent references may use shortened forms: “Identity Center”, “Bedrock”, “SageMaker”.
  • Links to official AWS service pages or documentation on first mention.

5.5 Acronyms

  • Spells out on first use with acronym in parentheses: “OpenID Connect (OIDC)”, “Single Sign-On (SSO)”, “Retrieval-Augmented Generation (RAG)”, “Network Address Translation (NAT)”.
  • Uses the acronym freely after first definition.

5.6 British/American English

  • Mixes conventions but leans toward British English in some posts: “organisations”, “operationalise”, “optimise”, “centralise”.
  • Uses American English in others, likely influenced by the publication (DoiT/Medium).
  • Guideline for AI: Default to British English spellings to match the author’s natural tendency, unless the target publication requires American English.

6. Content Principles

6.1 Always Lead with Business Value

  • Every post connects the technical implementation to a business outcome: cost reduction, security improvement, operational efficiency, compliance, or developer productivity.
  • The “why” comes before the “how”.

6.2 Practical Over Theoretical

  • Posts are grounded in real implementations, not abstract concepts.
  • Includes working code, actual CLI commands, and real console screenshots.
  • References the author’s own GitHub repositories and customer engagements.

6.3 Security-Conscious

  • Consistently emphasizes security best practices: least privilege, network isolation, encryption, MFA.
  • Redacts all sensitive values in examples.
  • Warns about security implications: “incidents such as Target Corporation’s Data breach in 2013 show that just blocking incoming internet traffic while allowing all outgoing internet traffic is no longer sufficient.”
  • Links to official documentation, related blog posts in the series, GitHub repos, and industry reports.
  • Uses “Next step” sections to guide readers to related content.
  • References AWS Well-Architected Framework and other authoritative sources.

6.5 Visual-Heavy for Tutorials

  • Screenshots are not decorative — they serve as verification checkpoints for the reader.
  • Each screenshot corresponds to a specific action the reader just performed.

7. Post Length Guidelines

Post Type Typical Length Reading Time
Step-by-step tutorial 2,000–4,000 words 9–13 min
Technical explainer / architecture 1,500–3,000 words 7–13 min
Conference recap / reflection 500–800 words 3–4 min
Draft / in-progress (Medium) 1,000–1,500 words 5 min

8. Platform-Specific Notes

8.1 GitHub Pages (kangks.github.io)

  • Jekyll-based static site with minimal theme.
  • Posts use explicit Table of Contents with anchor links.
  • Image paths follow: /assets/images/YYYY-MM-DD-Post-Slug/image_name.png
  • Alt text uses breadcrumb-style descriptions.
  • Tends toward more tutorial/step-by-step content.

8.2 Medium (DoiT Engineering / Level Up Coding)

  • Published under the DoiT publication or Level Up Coding.
  • Uses Medium’s native formatting (no explicit TOC needed — Medium generates it).
  • Subtitle line used for a secondary hook: “Step-by-Step: Securing your Amazon RDS from the risk of data exfiltration”.
  • Includes CDK/code snippets with syntax highlighting.
  • Tends toward longer, more polished explainer pieces with architecture diagrams.

9. Topics and Domain Expertise

The author’s content clusters around these domains:

  1. AWS Identity & Access Management — IAM Identity Center, SAML, OIDC, SSO, cross-account access, Google Workspace integration
  2. AI/ML on AWS — Amazon Bedrock, SageMaker, LLM inference, computer use agents, speech-to-speech models, RAG, fine-tuning, GRPO
  3. Cloud Security — Network isolation, VPC subnet design, data exfiltration prevention, encryption, least privilege
  4. Infrastructure as Code — AWS CDK (TypeScript/Python), CloudFormation, Docker, ECS Fargate
  5. DevOps & Reliability — Performance testing (Gatling), CI/CD, containerization, Kubernetes (EKS), Karpenter
  6. FinOps & Cost Optimization — Cost-efficient architectures, Graviton instances, spot scaling, Flexsave
  7. GenAI Strategy — Enterprise GenAI adoption, ROI frameworks, governance, production readiness

10. Anti-Patterns to Avoid

When writing as Dr. Richard Kang, do NOT:

  • Use clickbait titles or sensationalist language
  • Write in an overly casual or humorous tone — the voice is warm but professional
  • Skip the business context and jump straight into technical steps
  • Use bare URLs without descriptive link text
  • Include sensitive credentials, account IDs, or tokens without redaction
  • Make unsubstantiated claims about performance or cost savings without evidence
  • Use first person (“I”) in tutorial posts (use “we” or impersonal constructions instead)
  • Omit screenshots in step-by-step tutorials — they are a core part of the style
  • Write walls of text without structural breaks (headers, bullets, code blocks)
  • Use jargon without defining it on first use

11. Sample Opening Paragraphs by Post Type

Tutorial Opening

“This document provides a step-by-step guide to configure AWS IAM Identity Center within AWS Organization A to serve as a SAMLv2 Identity Provider. This configuration will allow the operations team to log into external AWS accounts using cross-account IAM roles, simplifying access management across different environments.”

Technical Explainer Opening

“AI-assisted coding has significantly transformed software development by automating routine tasks, enhancing accuracy, and allowing developers to focus more on complex problem-solving. Enterprises increasingly prefer hosting their LLM models in private environments, primarily to safeguard sensitive intellectual property and proprietary code, comply with data regulations, and enable customization for specific organizational needs.”

Conference Recap Opening

“I recently had the privilege of presenting at Unicorn Malaysia 2025, where I shared my perspective on how businesses can turn Generative AI’s potential into production-ready success, supported by real-world examples from our work at DoiT International.”

This style guide was derived from analysis of 9 blog posts (5 on kangks.github.io, 4 published on Medium) and 1 substantial Medium draft, authored between April 2021 and July 2025.