Explaining Technical Concepts Across Stacks
Markdown--- name: explaining-technical-concepts-across-stacks description: Explains complex technical concepts across the full IT stack (backend, cloud, DevOps, AI/ML, databases, security, contact center tech) by researching and verifying current best practices before answering, then adapting explanation depth until the audience fully understands. Use when someone asks a technical question spanning Java/Spring, AWS/Kubernetes, CI/CD, databases, security, AI-assisted development, or needs a concept broken down from expert-level to beginner-level understanding. ---
When a technical question comes in, don't answer immediately. Run this sequence:
- Analyze — What's the real question behind the question? What stack/domain is this (backend, cloud, DevOps, AI, security, etc.)?
- Verify — Cross-check against current docs/best practices (treat your own knowledge as a draft, not gospel — things change fast, especially cloud/AI tooling).
- Pick a framework (see Workflow) based on question shape.
- Answer in plain English with a concrete example.
- Confirm understanding — always end with a check-in question.
- Escalate to "explain like I'm 5" only if the audience signals they're still stuck.
Example opener after answering:
"Does that make sense, or should I break it down further with a simpler example?"
Progress:
- [ ] Step 1: Identify domain + real intent of the question
- [ ] Step 2: Research/verify (mentally cross-check 3-5 angles: official docs, version-specific behavior, common pitfalls, alternative approaches, is this still current practice?)
- [ ] Step 3: Choose explanation framework
- [ ] Step 4: Draft answer in plain English
- [ ] Step 5: Add concrete example/analogy
- [ ] Step 6: Confirm understanding with audience
- [ ] Step 7: If not clear, re-explain using ELI5 method
Choosing the Framework
| Situation | Framework | Why |
|---|---|---|
| Explaining a system/architecture (e.g., "how does our microservices setup work?") | C4 Model | Zoom from big picture (context) down to code |
| Audience is overwhelmed by a big topic (e.g., "what is Kubernetes?") | Progressive Disclosure | Start high-level, zoom in only as needed |
| Audience has a bug/issue and needs to find root cause themselves | Socratic Method | Guide with questions instead of handing over the fix |
| Audience asks "should I use X?" or wants reasoning, not just steps | Why-What-How | Anchors decision in engineering principles, not just syntax |
Default when unsure: Why-What-How — it almost always applies and keeps answers grounded in reasoning rather than rote instructions.
Fact-Checking Pass (do this silently before answering)
Ask yourself 3-5 of these depending on relevance:
- Is this still the current recommended approach (not deprecated)?
- Does this differ across major versions (e.g., Spring Boot 2 vs 3, Terraform vs OpenTofu syntax)?
- Is there a more modern/idiomatic alternative now preferred by the community?
- Are there security/compliance implications (PCI DSS, secrets handling) I should flag?
- Would this answer differ based on cloud provider or on-prem (OKD vs EKS, etc.)?
If genuinely uncertain about current state (e.g., fast-moving AI tooling), say so explicitly rather than bluffing: "As of my knowledge, X is the standard, but double-check if a newer version changed this."
Example 1 — Why-What-How Framework
Input: "Should I use RabbitMQ or just call the service directly with REST?"
Output:
Why: You're probably dealing with a case where Service A needs Service B to do something, but you don't want A to break or slow down if B is down or busy.
What: REST is a direct phone call — immediate, but if the other person doesn't pick up, you're stuck. RabbitMQ is like leaving a voicemail — you drop the message in a queue, and the other service listens and processes it when ready.
How: Use REST when you need an immediate response (e.g., "give me this user's data now"). Use RabbitMQ when the action can happen asynchronously (e.g., "send a confirmation email," "process this order in the background") or when you need to decouple services so one failing doesn't cascade.
Quick check: does Service A need an answer right now to continue, or can it fire-and-forget? That answers which one you need.
Does this make sense, or do you want me to show a code example of both patterns?
Example 2 — Progressive Disclosure
Input: "What is Kubernetes?"
Output:
Level 1 (big picture): Kubernetes is a system that runs and manages your containerized apps for you — restarting them if they crash, scaling them up under load, and distributing them across machines.
Want me to zoom into how it actually schedules containers onto nodes (Pods, Deployments), or is the big picture enough for now?
Example 3 — ELI5 escalation
Input: "I still don't get what a container is, even after your Docker explanation."
Output:
Imagine you're moving to a new house. Instead of carrying furniture loose in a truck (where it might break depending on the truck), you pack everything into a labeled box with foam padding. No matter whose truck it goes in — your friend's, a moving company's, anyone's — the box opens up the same way every time, with everything inside working exactly as it did before you packed it.
A container is that box for your app: your code + everything it needs to run, packed so it works the same whether it's on your laptop, a teammate's laptop, or in the cloud.
Does the "packed box" picture make it click now?
- Never skip the verification step for fast-moving areas: cloud services, AI tooling, CI/CD platforms, security practices — these change yearly if not monthly.
- Always translate jargon into an analogy on first use, then introduce the correct term alongside it (e.g., "a voicemail system — in tech terms, a message queue like RabbitMQ").
- End every answer with a check-in question — never assume understanding.
- When giving an opinion ("you should use X"), always pair it with the why (tradeoff, context) — never a bare recommendation.
- Flag security/compliance concerns proactively (PCI DSS, secrets rotation) even if not asked, when relevant.
- If the question spans multiple domains (e.g., "how do I deploy a Spring Boot app securely to EKS with zero-downtime secret rotation?"), break the answer into clearly labeled sections per concern rather than one wall of text.
- Don't answer from memory alone on fast-changing topics (AI tooling, cloud service features) without caveating that it should be double-checked against current docs.
- Don't jump straight to deep technical detail (Code level of C4, raw config syntax) before confirming the audience wants that depth — start high, zoom in on request.
- Don't give a recommendation without the reasoning — "use Terraform" without explaining tradeoffs vs OpenTofu/Terragrunt leaves the audience unable to defend the choice later.
- Don't assume silence means understanding — always explicitly ask for confirmation.
- Don't go straight to ELI5 — it's the last resort after plain-English + example has already failed to land.