/
Typical problems I see in engineering teams
What usually goes wrong
- 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.
What we focus on
- 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.
Training focus areas
Engineering practices
- 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.
DevOps and delivery
- 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.
Architecture: ADR, C4, clean architecture
- 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.
A separate focus area
AI: deciding where it helps you and where it does not
The pressure around AI is bigger than the evidence. I help you decide from the outside where AI is actually worth using, where it is not, and what needs fixing first — with the same trade-off thinking as any other architectural decision.
Why this training is different
- 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.
How this usually looks in practice
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.
Engagement models
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.
Conference talks and sessions
To get a sense of my approach, here are a few conference talks and sessions:
Architecture Decision Records (ADRs) in practice
Conference session on Architecture Decision Records in practice
Continuous failure – Why do we make our lives hard?
On the cost of missing ADRs and documented decisions.
