Stage 7 · Master
Platform Engineering Fundamentals
Cognitive Load & Golden Paths
Understand how platforms reduce cognitive load through abstraction, and how golden paths encode organizational best practices as defaults.
Cognitive Load Theory
Cognitive load is the mental effort required to complete a task. In software delivery, high cognitive load means developers spend energy on incidental complexity (YAML, networking, CI syntax) instead of business logic. Team Topologies identifies three types of cognitive load — platform engineering targets all three.
Three Types of Cognitive Load
| Type | Definition | Platform Mitigation |
|---|---|---|
| Intrinsic | Fundamental complexity of the domain (e.g., distributed consensus) | Can't eliminate, but can provide libraries/frameworks that encode patterns |
| Extraneous | Complexity from poor tooling, docs, processes (e.g., manual K8s YAML) | Primary target: abstraction, automation, golden paths, self-service |
| Germane | Effort to learn new concepts/skills (e.g., learning Helm, PromQL) | Reduce via: intuitive APIs, embedded docs, interactive tutorials, good DX |
Every manual step, every undocumented convention, every 'ask in Slack' adds extraneous load. The platform's job is to eliminate extraneous load so developers spend germane load on learning the domain, not the tooling.
How Platforms Reduce Load
- Abstraction: Hide K8s, cloud APIs, networking behind intent-driven APIs (
platform db create postgresql) - Defaults: Sensible, secure, observable configurations baked into golden paths
- Automation: Scaffold → CI → CD → Observability → Runbook in one command
- Documentation: Co-located with code, generated from APIs, interactive examples
- Feedback: Fast CI, preview environments, policy checks in editor (not just CI)
- Discoverability: Portal catalog shows what exists, who owns it, how to use it
Golden Path Design for Low Load
A well-designed golden path minimizes decisions without removing agency. It answers: 'What do I need to do to get a production-ready service?' with a single command.
# What the golden path DECIDES (developer doesn't choose)
decisions:
- language: go (or java, python - per org standard)
- framework: gin/chi (standardized)
- build: Dockerfile + buildpacks
- ci: GitHub Actions (org template)
- cd: ArgoCD + Kustomize
- observability: OpenTelemetry + Prometheus + Grafana
- logging: structured JSON + Loki
- security: Trivy scan + cosign sign + Kyverno policies
- secrets: External Secrets Operator + Vault
- networking: Istio sidecar (if service mesh enabled)
# What the developer CHOOSES (via scaffold parameters)
choices:
- serviceName: string
- capabilities: [postgresql, redis, kafka, blob-storage]
- team: string (ownership)
- repoVisibility: private/internal/public
Golden paths decide the 'how'; developers choose the 'what'.
Measuring Cognitive Load
- Time to First Deploy: New hire → scaffold → production deploy (target: <1 day)
- Context Switches: Count of tools/contexts to deploy a change (target: ≤3)
- Documentation Searches: How often developers search for 'how do I...' (target: decreasing)
- Slack Questions: '#platform-help' volume per sprint (target: decreasing)
- Onboarding Survey: 'How overwhelmed did you feel?' 1-5 scale (target: ≤2)
- Golden Path Adoption: % of new services using golden path (target: >80%)
Treat cognitive load like a budget. Every new platform feature 'costs' germane load to learn. Only add features that save more extraneous load than they cost in germane load. Measure before and after.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.