The Hidden Physics of Work
Most advice about work describes how work should behave, not how it does.
Set clear goals. Build the right process. Execute the plan. The advice isn't wrong. It's incomplete. It assumes rational actors, aligned incentives, and frictionless communication. Real organizations have none of these.
There's a gap between the org chart and the outcome. Between the project plan and what ships. Between the meeting agenda and what gets decided. That gap isn't noise. It follows patterns—predictable ones, once you know where to look.
Three laws capture most of it:
- Say the wrong thing, get the right answer. (Cunningham's Law)
- You ship your org chart. (Conway's Law)
- The work takes the amount of time you give it. (Parkinson's Law)
These aren't productivity hacks. They're closer to physics. Forces that operate whether you acknowledge them or not. The question is whether you design with them or get designed by them.
Cunningham's Law: Expertise is contextual and reactive
Ask a room full of smart people to explain how something works, and you'll get silence. State confidently how you thinkit works—even if you're wrong—and suddenly everyone has opinions.
This is Cunningham's Law. People are far more motivated to correct than to educate. A blank page is intimidating. A wrong answer is an invitation.
The surface explanation is psychological: correction feels low-cost. You're not asking someone to build something from scratch. You're asking them to react. The cognitive load is lower. The social risk is lower.
But there's something deeper happening. Most expertise in organizations isn't propositional knowledge you can write down. It's pattern recognition accumulated through experience. People often don't know what they know until they see something wrong. The knowledge is real, but it's reactive—triggered by context, not accessible on demand.
This is why documentation initiatives fail. You ask someone to write down "how we do things here," and they stare at a blank page. Not because they don't know, but because their knowledge doesn't exist as a transferable artifact. It exists as a set of reactions: "No, not like that. Like this." The expertise is encoded in corrections, not explanations.
This matters for how you extract knowledge from organizations.
If you're building a product, don't present blank canvases to stakeholders. Present a version—flawed, early, wrong in places—and let them tell you what's missing. You'll learn more in one round of correction than three rounds of open-ended feedback. The strawman becomes a diagnostic tool: it reveals what people actually care about by showing what triggers their corrections.
If you're navigating an organization, state your understanding out loud when you need to learn how something works. Don't ask "Can someone explain this?" Ask "Here's what I think happens—where am I wrong?" The corrections will teach you faster than any onboarding deck because they'll surface the tacit rules that never get written down.
The productive version of this isn't trolling. It's sacrifice. You trade personal correctness for group learning. You make yourself the strawman, explicitly inviting correction. The embarrassment is the price of speed.
Conway's Law: Communication structure is product constraint
Whatever you build will end up shaped like your communication structure. Not metaphorically. Literally.
Conway's Law says systems mirror the organizations that create them. Three teams each own "their" slice of a workflow? The product will have three slightly different flows for the same task. Four senior leaders need to approve a decision? The architecture will have four approval gates. Data is siloed by business unit? The product will duplicate data along those same seams.
You don't just ship features. You ship who talks to whom, how often, and about what.
This matters because most organizations treat product design and org design as separate conversations. They're not. Your org chart is a constraint on your product in ways that no amount of clever engineering can overcome. The structure will reassert itself in every release.
The practical implications cut two directions.
If you want cleaner systems, you often need cleaner team boundaries. Not better processes—different ownership. The question isn't "how do we coordinate better across these five teams?" It's "why do five teams need to coordinate on this at all?"
If you can't change the org (and usually you can't), you design with reality in mind. You acknowledge the seams and reduce dependency across them. You clarify who owns the end-to-end outcome, not just who owns each piece. You let technical architecture push conversations about structure, instead of pretending the two are separate.
When you see a fragmented product, you're looking at a fossil record of fragmented communication. The product is the artifact. The org structure is the explanation.
The trap is treating Conway's Law as fatalism—accepting that dysfunctional structures produce dysfunctional products and leaving it there. But the opposite trap is just as common: constantly reorganizing teams to "fix" product problems, creating churn that's as damaging as ignoring the law entirely.
The productive middle ground is diagnostic. Use the law to read your organization backward. When something is hard to ship, ask: is this technically hard, or are we trying to ship something our communication structure can't produce? Sometimes the answer is "build better coordination." Often it's "build something different—something our structure canproduce well."
Parkinson's Law: Ambiguity expands to fill available time
Give a team three weeks for something that could be done in five days, and you'll get three weeks of work. Not three weeks of a five-day task. Three weeks of a task that grew to fill three weeks.
Parkinson's Law captures how elastic most work is. But the real insight isn't that work expands. It's that ambiguity expands.
When the deadline is far and the scope is fuzzy, time becomes a proxy for seriousness. "We have three weeks, therefore this must be a three-week problem." Effort expands to match:
- More meetings to align.
- More documentation to cover bases.
- More "nice-to-haves" creeping into "must-haves."
- More polish on things that don't need polish.
Sometimes this improves quality. Often it just adds complexity without adding value. The calendar becomes a silent driver of scope, and everyone optimizes for "looking busy until the deadline" rather than "finishing when the value is delivered."
This is insidious because it's invisible. Full schedules and thick artifacts look like progress. Leaders mistake activity for output. Teams mistake thoroughness for rigor. Nobody questions whether the work required the time. The time was allocated, therefore the work expanded to use it.
The counterweight isn't heroic rushing. It's forcing the scope question earlier.
Shorter cycles with crisp definitions of done. A habit of asking "what's the smallest version that delivers real value?" not as a theoretical exercise but as an operational constraint. An explicit trade-off conversation: "Is this extra polish worth the delay, or are we just filling time?"
The discipline here is refusing to let time be the default scoping mechanism. Time is a resource, not a target. The question isn't "how do we fill this timeline?" It's "what's actually required to ship something valuable, and how fast can we learn whether we're right?"
When scope is clear, time compresses. When scope is fuzzy, time expands. The law doesn't care which you choose. But you should.
Designing with defaults, not against them
These three laws share a deeper pattern: they describe how defaults shape reality in organizations.
Cunningham's Law: the default is to ask politely for knowledge. But expertise lives in reactions, not explanations. If you default to blank pages and open questions, knowledge stays locked in people's heads. The alternative default is deliberate wrongness—forcing corrections instead of requesting education.
Conway's Law: the default is to treat org structure and product design as separate. But structure is constraint. If you default to ignoring how your teams communicate, you'll ship that communication pattern as a product. The alternative default is acknowledging the structure and either changing it or designing for what it can actually produce.
Parkinson's Law: the default is to let available time determine scope. But time is a resource, not a requirement. If you default to filling timelines, ambiguity will expand to match. The alternative default is defining scope first, then seeing how fast you can deliver it.
The common failure mode across all three: letting defaults operate invisibly. Assuming that good intentions, smart people, and clear documentation are enough to overcome structural forces. They're not.
The common solution: make defaults explicit. Acknowledge the forces at play. Design intentionally around them instead of pretending they don't exist.
You don't escape these laws. But you can choose which version of them you get. The version where knowledge stays trapped, products mirror dysfunction, and timelines drive bloat. Or the version where you extract knowledge faster, design for the org you have, and constrain work to deliver value instead of filling calendars.
Once you see these dynamics clearly, a lot of otherwise confusing behavior at work makes sense. Not as individual failure. As predictable side effects of how humans and structures interact.
And once you can see it, you're in a much better position to do something intentional about it.