Classroom training and consulting for software engineering teams.

I help software engineering teams ship faster with consistent engineering practices.

I work with mid–senior teams on DevOps, architecture, and everyday practices that reduce friction instead of adding process overhead.

Typical problems I see in engineering teams

Delivery slows down as the codebase grows; releases feel risky and fragile.
Different teams (or even individuals) follow incompatible conventions and tooling.
Architecture decisions are undocumented; new engineers have to reverse-engineer intent from code.
Infrastructure and deployment scripts are tribal knowledge instead of shared practice.
People "know" good practices in theory, but they don’t apply them consistently under pressure.

Safer changes: tests and pipelines that catch problems before production instead of after.
Faster delivery: fewer bottlenecks, clearer handoffs, and less rework from inconsistent practices.
Visible architecture: boundaries and decisions documented so the next person can pick them up.
Repeatable practices: versioned infrastructure and shared conventions instead of tribal knowledge.
Confidence in refactoring: modular design and dependency rules that make change predictable.
Delivery feedback you can trust: CI/CD that gives fast, reliable signals so releases stop feeling risky.

Code review as a consistency and learning lever, not a gate.
Branching and integration strategies that keep main releasable and reduce merge pain.
Modular design and boundaries that keep the codebase navigable as it grows.
Definition of done and quality gates that teams can actually sustain under pressure.

CI pipelines that give fast, reliable feedback and fail in a way that blocks broken builds.
Trunk-based development vs. long-lived branches: trade-offs and when each fits.
Environments and deployment practices that support safe, repeatable releases.
Pragmatic monitoring and observability so the team can detect and diagnose issues.

ADRs: when to write them, what to capture, and how to keep them lightweight and useful.
C4 diagrams: a shared visual language to reason about systems at different levels.
Clean architecture: dependency rules and boundaries that keep business logic decoupled from frameworks and infrastructure.
Structuring systems so that future changes don't require rewrites or heroics.

Senior-led: you work directly with me, not with a junior trainer reading from slides.
Hands-on: we work through real examples, code, and architecture from your world.
Opinionated: I share what tends to work in practice, not just what looks nice in a slide deck.
Context-aware: formats and exercises are adapted to your team’s maturity and constraints.

Work is done on your codebase, pipelines, and architecture—not generic examples. Typical formats include:

Architecture reviews: walking through your system, identifying boundaries and coupling, and agreeing next steps.
ADR sessions: capturing decisions in a lightweight format so they survive beyond the current team.
CI/CD redesign: reviewing your pipeline and deployment flow, then designing changes for faster, safer feedback.
Refactoring workshops: guided work on real modules to introduce or tighten boundaries and dependency rules.

Formats are adapted to your goals and team maturity. Common options:

1–2 day focused workshops: sharpen one or two areas (e.g. ADRs and C4, or CI/CD and safe release) with an experienced team.
Short diagnostic engagements: review architecture and practices, identify high-impact improvements, and hand over a clear summary and next steps.
Ongoing advisory: periodic sessions to support decision-making, rollout of new practices, or course-correction as you change.
Longer-term partnership: multi-phase work when you want sustained support for a broader transformation, with scope and rhythm agreed up front.

To get a sense of my approach, here are a few conference talks and sessions:

Conference session on Architecture Decision Records in practice

On the cost of missing ADRs and documented decisions.