/
Consulting and training for engineering teams.
I help software engineering teams ship faster with consistent engineering practices.
I look at your system, your pipeline, and your decisions from the outside, then tell you what to fix first. I work remotely: video sessions with a shared screen on your codebase, and a written deliverable at the end.
What participants said
Feedback from a company development team after a 2-day, tailored system design workshop.
“Really great training, Krisztián is a really great trainer.”
“I like that we focused more on how to think rather than this is the right answer.”
„Ránk volt szabva, mégis általános patternekkel, megoldásokkal találkoztunk, amik bármelyik projekten hasznosak lehetnek.”
Translation: It was tailored to us, yet we came across general patterns and solutions that can be useful on any project.
“The best part for me was the reliability part. I was able to learn new terminologies and practices there which I haven't heard of yet.”
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 work on together
- 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.
Ways to work together
The format follows your goals and the team's maturity. Common options:
- Review: 2–3 weeks, three sessions, ending in a written document on what slows delivery down and what to tackle first. This is the usual way in.
- Ongoing consulting: a monthly arrangement with regular sessions — for decisions, for rolling out new practices, or for support while direction changes.
- Decision support on one specific question: comparing architecture options and capturing them as an ADR, or a second opinion on what your team or a vendor proposes.
- 1–2 day focused workshops: going deep on one or two areas (e.g. ADRs and C4, or CI/CD and safe releases) with experienced teams.
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 work with me
- 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.
Conference talks and sessions
To get a sense of my approach, here are two conference talks — one on ADRs, one on what makes a real AI agent:
Architecture Decision Records (ADRs) in practice
Conference session on Architecture Decision Records in practice
You call that an AI agent?
Cloud Native Days Austria talk: what makes a real AI agent?
Let's talk about where you stand
If you have a recurring delivery or architecture problem, a short call usually makes it clear whether an outside perspective is worth it.
