Notes From My First Cohort: System Design Is Trade-offs, Not Answers

Tonight I taught the first live session of my From Senior to Staff cohort, and I am still buzzing from it.

I have taught online courses for years, and run hundreds of one-to-one mentorship sessions. But there is something different about a live cohort: a room full of strong engineers, all in the same place at the same time, all there because they have hit the same ceiling and decided to do something about it. You can feel it. The questions are sharper. The pushback is real. Nobody is there to be entertained.

I want to write down what the night was actually like while it is fresh, because the thing I tried to teach is also the thing I most believe about this work.

Meeting people where they are

The first job of a session like this is not to teach. It is to find out where everyone actually is.

These are senior engineers. They ship reliable code, they debug fast, their PRs get approved. They know the words: consistency, availability, sharding, caching. What they often do not have is a structured way to reason out loud under pressure. So I spent the early part of the session pulling that out, asking how they would start a problem, where they would push, what they would defer. Not to test them, but to calibrate. You cannot take someone to the next level until you know precisely which level they are standing on.

That is the part of teaching I love most, and it is the same instinct I wrote about years ago when I first started teaching programming. The lesson plan is a hypothesis. The room is the data. Tonight the room told me they did not need more concepts. They needed a way to hold the concepts they already had.

System design is trade-offs, not answers

So that became the spine of the session: system design is not about arriving at the right answer. It is about naming the trade-off and owning it.

This is the shift that separates a strong implementer from a staff-level engineer. A senior engineer asks "what is the correct database here?" A staff engineer asks "what are we optimising for, what are we giving up, and under what conditions would this choice become wrong?" There is rarely a correct answer in architecture. There is a defensible decision, made against real constraints, that you can explain to people who were not in the room.

We worked through this live. Every time someone reached for a clean answer, I asked them what it cost. Choose strong consistency, and you have spent some availability. Choose to scale reads with replicas, and you have bought yourself replication lag. Add a cache, and you have signed up for invalidation. Nothing is free. The skill is not memorising the patterns, it is seeing the bill that comes attached to each one.

The six axes I had them reason along

To make that concrete, I anchored the whole discussion on a small set of axes. Almost every system design decision moves you along these, and you can never max all of them at once:

• Availability — does the system answer when you ask it to?
• Consistency — does everyone see the same truth at the same time?
• Latency — how fast does a single request come back?
• Throughput and scalability — how much load can it carry, and how gracefully does it grow?
• Durability and reliability — once you accept data, does it survive failure?
• Cost — engineering time and money, the axis people pretend is not part of the design.

The point of the axes is not to recite them. It is that every meaningful choice is a movement along them, almost always trading one for another. The canonical example is the one we spent real time on: the CAP theorem, where a network partition forces you to choose between consistency and availability and there is no way to keep both. Once engineers internalise that the dials are connected, they stop looking for the perfect design and start asking the far better question, which dial does this system actually need turned up. These are exactly the non-functional requirements that decide whether an architecture survives contact with reality, and they map directly onto how you reason about SLOs, SLAs, and SLIs once the thing is in production.

By the end, the framing had clicked for the room. We were not debating which answer was right. We were debating where on each axis the system needed to sit, and why. That is the move.

Why this lands for senior engineers

The reason this matters so much at the senior-to-staff boundary is that the job changes shape. Below staff, you are measured on what you build. At staff and beyond, you are measured on the decisions you influence and the judgement you show. Trade-off reasoning is the visible artefact of that judgement. It is the thing that makes you legible to a promotion committee, to a design review, to an interviewer who wants to see how you think rather than what you have memorised.

It is also, frankly, the thing most senior engineers were never explicitly taught. You are expected to absorb it on the job. Most do not, not because they lack the ability, but because nobody ever sat with them and made them say the trade-off out loud until it became a habit. That is the gap this cohort exists to close, and it is the same gap I keep pointing people to in the Staff Engineer book and in how I structure a system design problem in the first ten minutes.

I loved it, and I am doing it again

I will be honest, I enjoyed tonight more than almost anything I have done in a while. Watching an engineer go from hedging to confidently naming a trade-off, in real time, in front of their peers, is a genuinely good feeling. The cohort is sold out, the energy was exactly what I hoped for, and I am already thinking about how to make the next session sharper.

So yes, I am going to keep doing this.

Come to the next free session

If this is the kind of thinking you want more of, my next free lightning lesson is the perfect way in, and it points the same trade-off lens at the most current problem in our field.

System Design for AI Agents, for Engineers (2026) — a free 30-minute session on Thursday, June 18, 2026, 7:00 PM GMT+1, on Zoom. It is the engineer's mental model for putting an LLM in production: what is ordinary distributed-systems work, what genuinely breaks your assumptions, and the few decisions that decide whether an agent system survives real traffic, cost, and non-determinism. Sign up for free here.

If you want the full version of this thinking applied to the hardest current problem in our field, my live cohort Production-Ready Systems with LLMs and Agents runs July 13 to August 23, 2026: a hands-on intensive on shipping LLM and agent systems to production. You can see everything I teach, including future cohorts of From Senior to Staff, on my Maven profile.

I write about system design and the senior-to-staff transition every week in Monday BY Gazar on Substack, and I break down architecture and working with AI agents on Gazar Breakpoint on YouTube.