Where I Actually Shine
Ten pillars, each explained twice — plainly, and precisely.
AI & ML
In plain terms: I help you tell the difference between a genuine AI opportunity and a vendor pitch — most of what gets sold as "AI" is a decision tree with better marketing.
For engineers: AI ⊃ ML ⊃ DL ⊃ transformers/LLMs is a nested hierarchy, and knowing where your use case sits in it is the first question before choosing a vendor or a model. Build order: prompting, then RAG, then fine-tuning — in that order, because each step adds cost and most problems never need the third.
The word "AI" in a vendor pitch tells you nothing about which level of that hierarchy is actually involved.
RAG chat systems
In plain terms: A chatbot with a 35% resolution rate and one with an 85% resolution rate are almost never running different AI models — they’re running on different data.
For engineers: RAG turns a closed-book exam into an open-book one: retrieval, indexing, and generation, each of which can fail independently. Parent-child chunking, contextual retrieval, and hybrid search close most of the gap before the model is ever touched.
The AI is a commodity. The knowledge base is the only genuinely proprietary part of the stack.
Agents & automation
In plain terms: The hard part of an AI agent is never the model. It’s the guardrails — the limits that stop it from running away with your Azure bill or doing something you didn’t ask for.
For engineers: Hard iteration caps, token/time budgets per run, explicit completion criteria, and human-in-the-loop checkpoints are mandatory production controls, not polish. Model Context Protocol (MCP) is becoming the standard way agents reach tools and data — I design for it.
Single-agent architectures handle roughly 80% of real cases. Multi-agent adds cost and non-determinism most problems don’t need.
Process engineering
In plain terms: Most expensive project mistakes aren’t technical failures. They’re scope decisions made before the technical work even begins — or never made at all.
For engineers: Cynefin for method selection (the most damaging error is treating a Complex problem as merely Complicated and over-planning the unknowable); structured interviews as the highest-yield requirements technique; Event Storming and Example Mapping to surface bounded contexts before a line of code is written.
No single methodology wins. Context-fit and execution discipline win.
Scrum & Agile
In plain terms: I run Security-First Scrum: secure, working, tested, clean code, in that order — never traded away for speed.
For engineers: Certified ScrumMaster. Threat modeling belongs in backlog refinement (a 5–10 minute STRIDE pass), not a waterfall gate. Retrospective action items get a single named owner and become backlog tickets, or they die — most retros fail because nobody follows through.
Psychological safety is a security control. Teams without it hide vulnerabilities instead of reporting them.
Software architecture
In plain terms: Every architecture decision is a trade-off. If you think you’ve found one that isn’t, you haven’t found the trade-off yet — I’ll help you find it before it costs you six months.
For engineers: Start with a modular monolith, not microservices — roughly 80% of microservices’ benefits come from logical boundaries, not independent deployment, and the infrastructure cost runs 3.75–6x higher. Split along business boundaries, not technical layers.
A dedicated "release coordination manager" role is the tell-tale sign of a distributed monolith, not a real microservices win.
Onion / clean layering
In plain terms: I build systems where the core business logic doesn’t know or care what database or framework is running underneath it — so swapping either one later doesn’t require a rewrite.
For engineers: Hexagonal, Clean, and Onion architecture are the same idea in three vocabularies: a dependency rule pointing inward to a framework-independent domain core, with adapters at the edges. Domain has zero dependencies on API or infrastructure — no exceptions.
Dependencies point inward only. The moment they don’t, you have a distributed monolith wearing an architecture diagram as a costume.
Microservices
In plain terms: I don’t reach for microservices by default — I reach for them when a specific business boundary or compliance requirement genuinely demands independent deployment.
For engineers: Event-driven patterns via Azure Service Bus (ordering, transactions, DLQ), Event Grid (reactive pub/sub), and Event Hubs (the log, not the queue) are complementary, not competing. The Outbox pattern is mandatory wherever a business change and an event need to land together — never two independent writes.
Redundancy is architecture; resiliency is behavior. Size failover capacity for full load, not half.
Azure cloud
In plain terms: I’ve spent thirteen-plus years building on Azure and Microsoft’s cloud stack — Service Bus, Functions, Key Vault, App Config, AKS — and I know which of its 250-plus built-in roles actually maps to a data-plane action you need.
For engineers: Control-plane "*" in Actions does not grant DataActions — the single most common source of production RBAC incidents. Managed identity, zero stored secrets, OIDC federation for CI/CD. Cosmos DB partition key is an irreversible decision; get it wrong and it’s a re-platform, not a config change.
Owner can fully manage a storage account and still not read a single blob without a separate data-plane role assignment. This catches even experienced engineers.
Data & integration pipelines
In plain terms: I connect the systems that don’t want to talk to each other — HubSpot, SharePoint, Snowflake, Salesforce, legacy APIs — without building a fragile spaghetti of point-to-point scripts.
For engineers: ELT is the production default on modern warehouses; idempotency is non-negotiable so re-running a failed job never double-writes. dbt three-layer discipline: staging views with no joins, intermediate as ephemeral, marts capped at 4–6 joins.
Watermark storage belongs in an audit table in the target database, not just an orchestrator variable — or it’s undebuggable when it breaks at 2am.