Three Laws Your Studio Is Already Breaking
Why predictable delivery keeps slipping, and where to look first
Little’s Law says lead time equals WIP divided by throughput. Studios treat a full pipeline as good news.
Goldratt says every system has one constraint. Optimising everything else is wasted effort.
Conway’s Law says your pipeline looks like your org chart. Reorganising teams without changing communication changes nothing.
The three laws compound. That’s why fixing one thing rarely fixes the problem.
There’s a pattern I’ve seen enough times that it no longer surprises me. A studio with no shortage of work, no shortage of people, and no shortage of slipping dates. Everyone is busy. Nothing is shipping on time. Ask why, and you get a different answer depending on who you ask: scope, resourcing, communication, dependencies, leadership. Everyone is right about a symptom. Nobody is right about the cause.
The cause, in most cases, is that three well-understood laws are being broken simultaneously. The laws aren’t obscure. They predate the game industry by decades. Two come from hard science, one from observation, and none of them care whether you’re aware of them. You don’t need to believe in them for them to operate on your project.
I’m going to describe each one and what it looks like when a studio breaks it. Then I want to explain why they compound, because that’s where the diagnostic value sits. Individual symptoms point to individual laws. When a project is genuinely in trouble, you’re usually dealing with all three at once.
Little’s Law and the full-pipeline trap
Little’s Law comes from queuing theory. The equation is: lead time equals work in progress divided by throughput. If you want things to move faster through your pipeline, you either increase throughput or reduce what’s in the pipeline. There is no third option.
The studios I’ve seen struggle with this treat a full pipeline as a sign of health. A backlog stretching five cycles deep reads as security: work lined up, team occupied, no gaps. What it actually signals is slower delivery per item, because every new thing you start competes with everything already in flight for attention, handoffs, and reviews. You’re not preventing gaps. You’re lengthening the queue.
An empirical study of over 8,000 work items across five software teams confirmed what the equation already predicts: lower WIP correlates directly with shorter lead times. This is not a management theory. It’s arithmetic.
I watched one studio respond to slipping dates by adding people. It’s the intuitive move. More hands, more output, faster delivery. Except their WIP didn’t shrink, it grew. New team members meant new work started, new dependencies created, more items entering the pipeline simultaneously. Lead times continued climbing. They’d addressed capacity without addressing flow. Two different problems, easily confused.
The backlog isn’t a list of priorities. It’s an active liability if it’s too long. Every item sitting in it is lead time waiting to accumulate. The length of your backlog predicts your delivery pace as directly as the WIP equation does, because a bloated backlog is just upstream WIP with better formatting.
The fix feels wrong. Stopping new work from starting, pushing back on scope, enforcing WIP limits all look like slowdowns. The board moves faster when there’s less on it. Studios that accept this take a short-term hit to utilisation and a significant long-term gain in throughput. Most studios accept neither, so they add people and watch the dates slip.
Goldratt’s constraint and the optimisation trap
Eliyahu Goldratt’s observation, which he formalised into the Theory of Constraints, is that every system has exactly one element limiting its throughput at any given time. One constraint. Not several.
The implication is uncomfortable. If you accept it, everything you do to improve a non-constrained resource is theatre. You’re making a part of the system faster that isn’t the limiting factor. The system’s overall output stays the same. You just feel like you’re doing something.
“The constraints will determine the output of the system whether they are acknowledged and managed or not.”
I’ve seen this play out in a way that looked, at the time, like productive management. The studio had an obvious constraint: review and approval. The board made it visible. Work stacked up waiting for sign-off at a rate that had been consistent for months. The response was to hire more artists. The logic seemed sound: output was too low, add capacity. Except output wasn’t the constraint. Reviews were. More artists meant more work completed per cycle, which meant more items entering the review queue, which meant the queue grew faster, which meant lead times kept climbing despite the additional headcount.
The constraint was optimised around, not at. Nobody in a position to fix the review process owned the problem, and nobody who owned the problem had the authority to fix it. The constraint stayed. The payroll grew.
This is common because constraints are politically inconvenient. They tend to sit in approval paths, in senior decision-making, in resource handoffs that cross team boundaries. Fixing them requires authority that producers often don’t have and conversations that organisations often avoid. Hiring more people or switching tools are easier decisions with cleaner paper trails.
Goldratt’s prescription for non-constrained resources is to keep them deliberately underloaded, somewhere around 80-85% of capacity, so they don’t produce faster than the constraint can process. This sounds like waste to a studio that measures utilisation. It isn’t. Full utilisation upstream of a bottleneck is how you build a queue. A queue is stored lead time. You’re not saving time by keeping everyone busy; you’re borrowing against future delivery.
The goal isn’t to find the constraint and then optimise everything around it. The goal is to find it, protect it with buffer, fix it, and then find the next one. The constraint moves. The method doesn’t.
Conway’s Law and the reorganisation trap
Melvin Conway’s observation from 1968 has held up without much amendment: organisations design systems that mirror their own communication structures. In game development, that means your pipeline will look like your org chart. Your dependency map will follow your reporting lines. Your integration problems will appear precisely at the boundaries between your teams.
This isn’t a cultural observation. It’s a structural one. You can’t design a system that communicates differently from the organisation that built it, because the design decisions are made by people talking to each other, and their conversations are bounded by how the organisation allows them to talk. The system is a projection of those conversations.
I’ve seen this in two forms, which are instructive in different ways.
The first: a studio reorganised into cross-functional squads. The intention was faster feature delivery, fewer handoffs, more ownership per squad. In practice, the squads worked like squads in their daily check-ins and like siloed departments in every decision that required sign-off. The reporting lines didn’t change. The approval paths didn’t change. The communication structure didn’t change. At integration, the work looked exactly like work produced by siloed departments, because the squads were siloed departments with a different name on the org chart.
The second is stranger and, once you know the law, completely predictable. A shipped game whose architecture nobody deliberately designed. The rendering pipeline, the content pipeline, the live systems, all cleanly separated in ways that matched the team structure almost exactly. Art, engineering, and LiveOps had operated largely independently throughout production. The game reflected that. The seams in the product were at the same places as the seams in the team.
Conway’s Law doesn’t discriminate between good and bad outcomes. It maps communication structure to system design. If the communication pattern suits what you’re building, the system will suit it too. If the communication is fractured, siloed, or running along the wrong boundaries for the product, the system will be fractured in exactly the same places.
The inverse version of the law is the useful one for producers: if you want a particular system design, build the communication structure that would naturally produce it. Reorganising the boxes on a chart is not the same thing.
Why they compound
The reason fixing one thing rarely fixes the problem is that the three laws interact, and they interact in ways that accelerate each other.
High WIP starves the constraint. When everything is in flight simultaneously, the constraint receives an uneven stream of work: bursts followed by gaps, or more than it can process without the upstream teams noticing. Neither is good. Goldratt’s prescription of a buffer before the constraint only works if WIP is controlled enough for the buffer to be meaningful. If the whole system is overloaded, there’s no clean buffer, only a general backlog that hides where the real pressure is.
A mismanaged constraint accelerates WIP accumulation. Work completes upstream faster than it clears downstream. The queue grows. Lead times extend. Teams interpret the delays as a coordination problem rather than a throughput problem and respond by starting more work to demonstrate progress. Which grows the WIP. Which grows the lead times.
An org structure that fights the work pattern prevents either from being fixed. If the people who can see the constraint don’t own it, and the people who own it can’t see it, the diagnosis doesn’t happen. The squad reorganisation doesn’t help if the communication structure generating the bottleneck is left intact. The constraint is in the approval path. The approval path follows the reporting lines. The reporting lines survived the reorganisation unchanged.
The useful question when a project is in trouble is which law is primary. Is this a WIP problem, a constraint problem, or a communication structure problem? They’re usually all present. One is usually loudest. Identify which one is driving the others and start there. Treating a communication problem with WIP limits, or a constraint problem with team restructuring, is what produces the feeling that you’re doing everything right and nothing is improving.
That’s not a formula. It’s a way of looking. The looking is the skill.
Once you can see through these three lenses, the problems stop looking like bad luck or individual failure. They become predictable consequences of decisions made months earlier: the planning session where everything was marked high priority, the hiring decision that added capacity to the wrong stage, the reorganisation that moved boxes on a chart without touching how decisions actually got made.
Uncomfortable if you made those decisions. Useful if you want to make better ones.