The C4 Diagram gives QA, Dev, and PO the same map

One of the quietest sources of friction I've seen in software teams isn't technical — it's vocabulary. QA, Dev, and PO use the same word, "architecture," to describe three different things. The PO thinks in features and user flows. The dev thinks in classes and modules. QA thinks in test surfaces and points of failure. Nobody is lying, but they're not talking about the same thing either.

The C4 Diagram solves that with a simple idea: instead of one diagram that tries to hold everything, it gives four zoom levels, each useful for a different conversation.

• Context: the whole system seen from outside, and who it interacts with. It's the level a PO understands without effort.
• Containers: the big pieces — the web app, the database, the external service. Technical vocabulary starts to show up here, but still at a level QA can read to think about what breaks if a container goes down.
• Components: inside a container, how it's organized internally. This level is mostly dev territory already.
• Code: classes, functions, implementation detail. The level almost nobody outside dev needs, and that's fine.

What changes with this isn't that QA learns to code or the PO learns UML. It's that when someone says "the problem is in the architecture," there's now a way to ask "at what level?" and have the answer point to a concrete diagram, not a different idea in each person's head.

For QA in particular, this has an extra benefit: seeing the system at the container level helps design what should be tested end-to-end and what should be tested in isolation — the same question that separates an expensive E2E test from a cheap integration test.

I originally published this on LinkedIn