Conway’s Law: What Your Cloud Team Can Learn from Stressed Out Kitchen Staff

Shannon
Nov 12, 2025
5 min read

I was reminded of Conway’s Law the day I watched an episode of The Bear where Carmy tried to redesign the entire kitchen workflow in the middle of lunch service. Onions were flying. Pans were screaming. Richie yelled “cousin” every twelve seconds. Sydney was five seconds away from either fixing everything or throwing a stainless steel pan into the alley. Half the staff looked like one more missed step would send them into a new career that involved silence and scented candles.

The restaurant wasn't broken because the food is bad. It was broken because the communication looked like a Slack or Teams channel during a production outage. Every plate coming out of that kitchen is a perfect reflection of whatever chaos is happening behind the counter.

Just so you know, this is how a lot of my customers still build their teams and corresponding cloud architecture. I've started saying "your cloud platform always looks like your people under pressure."

What do I really mean? Sometimes the environment feels less like a modern engineering organization and other times, it's more like Carmy’s kitchen on a Saturday rush with vendors waiting, customers yelling, and someone screaming “behind” at the wrong moment.

Note, this is Conway’s Law in its purest form.

The Restaurant Example That Explains Everything

Let's take where this blog originated and expand on a theme. Imagine a restaurant that wants to produce high quality meals at scale. Great ingredients. Great recipes. Great menu. High hopes.

Now picture a kitchen where the teams are split into isolated functions:

One group chops vegetables
One group cooks meat
One group makes sauces
One group plates
One group handles desserts

These groups barely talk. Each team works in its own mental silo. Timing suffers. Visibility collapses. Dishes finish at random times.

Suddenly:

The veggie team finishes early and everything sits too long
The sauces team makes things nobody else is ready for
The cooks finish entrees long before the plating team notices
Desserts arrive at odd times because dessert staff cannot see the dining room

Every plate looks like the communication pattern behind the scenes. Disjointed, uneven, chaotic. The kitchen did not choose to fail. It simply built a system that reflected how its people interacted.

This is Conway’s Law. Systems mirror the structure and communication of the teams that create them (pocket this for later or for always - it's still ridiculously relevant).

How the Kitchen Fixes It

A better restaurant restructures the kitchen around the work that actually needs to happen.

Instead of five isolated groups, they form small cross functional squads (hold onto this idea for later in my blog):

A prep cook
A line cook
A plater
A runner

Each squad is responsible for entire dishes from start to finish. Communication becomes natural. Timing lines up. Quality skyrockets. Suddenly the entire restaurant feels calm, even during heavy service.

The kitchen layout changed because the communication structure changed. This is the Reverse Conway Maneuver in action.

Now Bring This Into the Cloud

Your cloud teams are not any different from Carmy’s kitchen. It is the same story, except with more YAML and fewer burnt onions.

Most cloud organizations have some combination of:

Platform engineers
Developers
Data scientists
SRE
Security engineers
FinOps analysts

On paper, this looks great. In practice, if they work like the dysfunctional kitchen...which means your cloud architecture will show it and consumers of your services will notice.

When Cloud Teams Move Like a Kitchen in Crisis

You know the story:

Developers build in isolation until deployment day.
Data scientists push pipelines with no FinOps oversight.
Platform engineers design landing zones without input from SRE or security.
Security arrives when everything is already built and immediately says no.
SRE only finds out about an application’s design when it is already falling over in production.

Your cloud platform starts to look like:

Three ways to deploy
Three ways to tag resources
Three ways to secure databases
Three different logging patterns
Three incomplete IaC libraries
Three versions of confusion

The power of THREE (note, I could've used something like eight, but three works better)!

Ultimately, this is exactly like watching Carmy try to design a new menu mid service while Richie yells in the background. No one plans for chaos, but chaos appears anyway because the system reflects the communication patterns inside the team.

That is Conway’s Law.

How Cloud Teams Fix It With the Reverse Conway Maneuver

A high functioning cloud organization reorganizes collaboration, not just code.

You build cloud squads (told you it'd show up later) that align with desired platform outcomes:

A developer experience team that handles pipelines, internal tooling, templates, and golden paths
A platform governance team that owns landing zones, identity, guardrails, and policy
A FinOps and observability team that defines budgets, dashboards, metrics, and cost controls
A reliability team that blends SRE with platform engineers to design for resilience
An embedded security partnership that participates from the first line of code

To use my kitchen analogy...now everyone cooks together...everyone plates together...everyone serves together. It's almost sort of magical!

The cloud architecture then becomes:

Scalable
Predictable
Cost controlled
Secure
Consistent
Friendly for developers

No more plates coming out at random times. No more half finished dishes. No more snowflake infrastructure hidden under a prep table in the back (WOO!).

This is how you shift your cloud platform from The Bear in season one into something closer to Sydney’s dream restaurant, where the entire team operates like a single organism.

Why Conway’s Law Matters for Cloud Leadership

Conway’s Law explains the root cause of so many cloud problems:

Drift happens when teams drift
Security breaks when communication breaks
FinOps fails when tagging fails
Reliability suffers when collaboration suffers
Architecture becomes inconsistent when reviews are inconsistent

Your cloud environment is not just shaped by technology. It is shaped by human behavior and the way your teams relate to one another.

Your cloud architecture is a mirror. What you see in the system is exactly what exists behind the scenes.

The Real Takeaway

If you want a cloud environment that feels unified, smooth, secure, cost aware, reliable, and scalable, then your team structure must support those goals. Tools cannot fix cultural silos. Pipelines cannot fix communication gaps. Dashboards cannot fix disjointed workflows.

You design the architecture by designing the people who build it.

This is why Conway’s Law is so powerful. It reminds us that every cloud platform tells the truth about the team behind it. Make the communication intentional, and the architecture becomes intentional too.

CLOUDY MUSINGS

If I can do it, you can, too!