For individual developers · 2 days · Budapest · in person only
You ship tickets. The system stays fuzzy.
You implement features, but you don't really see the whole picture. Bigger calls feel like guesswork.
Architecture discussions happen without you—or you're in the room without language that sticks. System design interviews feel improvised.
This workshop is two hands-on days on technical decisions, C4, and lightweight ADRs so you can explain what you built, defend trade-offs, and sound like the engineer who shapes the system—not only the one who codes it.
The problem
- You're deep in implementation, but dependencies, boundaries, and failure modes stay vague.
- Every meaningful choice (data model, integration, split services, "temporary" shortcuts) feels uncertain when it matters.
- You're not in—or not heard in—conversations where real technical direction gets set.
- When someone asks "why did we do it this way?", the honest answer is often "nobody remembers."
- System design interviews expose the gap: you know pieces, but not how to tell a coherent story fast.
If that reads like your week, you're the audience.
What this actually is
This is not a slide deck about "mindset." It's a small-group, in-person workshop where you work through real decision patterns: separating constraints from opinions, comparing options by risk and cost, and leaving a short paper trail when it counts.
ADRs show up for what they are: a small, repeatable format for "what we decided, what else we considered, what breaks if we're wrong"—not enterprise paperwork.
C4 is how you make the system legible: context, containers, components—so you and others align on boundaries and ownership instead of arguing from different mental models.
Together: decisions you can justify, diagrams you can point at, and a way to talk to product and leadership without drowning in jargon.
What you'll leave with
- A reusable decision checklist you can use on real tickets and design discussions—not a one-off theory.
- One or two C4 views (context, container, component) for your system or a concrete example from the room—artifacts you can drop into docs or interview prep.
- ADR drafts you wrote during the workshop (with feedback), so you've already done it once before you're back at work.
- The ability to walk someone through your system in a few minutes with a diagram plus a short decision story.
- Sharper prep for system design-style conversations and for being taken seriously when trade-offs actually get decided.
How it works
- Two days, Budapest, small group. In person only—shared whiteboard and modeling are core; no remote stream.
- Short inputs, heavy practice: you're comparing options, sketching, and writing—not passively listening.
- You bring your own mess: a system you work on, or a decision that still bothers you. We also use realistic examples so nobody is blocked if they can't share internals.
The day-by-day breakdown is in the Day 1 and Day 2 sections below. You leave with things you can paste into Confluence, Notion, or a repo—not a certificate and vague "insight."
Day 1 — Decisions under pressure
Clarify the real decision, compare trade-offs, and capture short records when it matters—ADR as a lightweight framework, not documentation theater.
Clarifying the real decision
- Separate constraints, assumptions, and goals.
- Define the core decision question in noisy environments.
Comparing options and trade-offs
- Compare alternatives by risk, cost, and change impact.
- Communicate rationale clearly to technical and business stakeholders.
Short decision records (ADR as framework)
- Decide when a decision should be captured versus kept verbal.
- Use a lightweight structure without turning it into documentation overhead.
Day 2 — Making it visible with C4
Model the system with C4, spot coupling and ownership gaps, and tie diagrams plus short decision notes into one narrative.
C4 context and container views
- Model system boundaries and external dependencies.
- Express responsibilities and key interactions clearly.
C4 component view
- Break containers into meaningful components and interfaces.
- Detect risky coupling and unclear ownership.
Communicating decisions with diagrams and short notes
- Link diagrams and short decision notes into one coherent narrative.
- Create a repeatable communication routine inside and outside the team.
Who this is for
- Mid-level to senior developers who want senior, staff, or tech lead trajectories—not another year of only closing Jira issues.
- People who want system fluency: how pieces connect, fail, and evolve—not just framework APIs.
- Anyone who wants interview-relevant clarity: explain architecture and trade-offs in a structured way under time pressure.
- Engineers who are tired of being overruled without a vocabulary to push back constructively.
Who this is not for
- Beginners still learning core programming.
- Anyone who wants a talk-only event with no exercises or peer review.
- People unwilling to sketch, write, and defend a decision in the room.
- Anyone who needs remote—this format doesn't translate without the whiteboard.
Next step
Reserve a spot on the waitlist—and when I follow up with Budapest dates, you can send a short description of a system you work on (or two decisions you still find hard to justify). A few sentences is enough. I use that to tune examples and to make sure the cohort is a fit.
