The Beautiful Absurdity of Modeling Your Company in Java

Last week I did something that would make most business people question my sanity. I opened my IDE, created a new Java project, and started modeling my company as code.

Not the software my company builds. The company itself. Departments as packages. Roles as interfaces. Products as composite classes. Business rules as type constraints.

The compiler had opinions. And it was right about every single one of them.

Why Would Anyone Do This

Here’s the thing about org charts: they’re lies. Nice, clean, hierarchical lies. They show reporting lines, but they don’t show how work actually flows, who actually owns what, or where responsibilities overlap in messy, undefined ways.

Programming languages don’t let you get away with that. A type system forces you to declare: What does this thing own? What does it produce? What does it consume? What can it access? You either define these boundaries or the code doesn’t compile.

So I thought — what if I applied the same rigor to organizational design?

What the Compiler Found

Within an hour, Java’s type system caught three things I’d been ignoring.

The God Class. In software, a God Class is a class that does too much — it knows about everything, touches everything, and becomes a bottleneck for every change. When I modeled my executive functions as classes, one of them implemented seven different interfaces. Seven. That’s not a role — that’s a single point of failure wearing a trench coat.

The fix in code is simple: extract interfaces, split responsibilities. The fix in an organization is the same. You just need the type system to make the problem visible.

Missing interfaces. Some functions were calling each other directly — tightly coupled, no abstraction layer. In code, this means you can’t change one without breaking the other. In an organization, it means knowledge silos and fragile handoffs.

When I introduced explicit interfaces between departments, the compiler forced me to define: what does marketing actually need from product? Not “everything” — a specific, typed contract. That clarity is worth more than a hundred strategy meetings.

Circular dependencies. Two parts of the system depended on each other in a way that made neither truly independent. The compiler caught this instantly. In a real organization, circular dependencies hide for months, surfacing as “why does this simple change require five people to approve?”

A Taste of What This Looks Like

Here’s a simplified example — not my actual model, but the concept:

interface BusinessUnit {
    Set<String> owns();
    Set<String> produces();
    Set<String> consumes();
    Set<String> doesNotOwn();
}

interface KnowledgeStore {
    void record(Decision decision);
    List<Pattern> retrievePatterns(String domain);
}

class ProductTeam implements BusinessUnit, KnowledgeStore {
    // The compiler now enforces that ProductTeam
    // must explicitly define what it owns, produces,
    // consumes, and explicitly does NOT own.
    // Try being vague about boundaries here.
}

That doesNotOwn() method? That’s the most valuable thing in the whole model. Most business planning focuses on what you will do. Almost nobody explicitly defines what they won’t do, what they don’t own, what they have no authority over. The type system forces that conversation.

Design Patterns Are Already in Your Organization

Here’s what surprised me most: I wasn’t inventing patterns. I was discovering them.

The Facade Pattern was already there — a single entry point that simplifies access to complex subsystems. Every company has one, whether they’ve named it or not. The question is whether it’s intentional or accidental.

The Repository Pattern — encapsulating access to domain objects through a clean query interface — maps perfectly to how knowledge should flow in an organization. Not “ask Bob, he knows,” but a structured protocol for storing and retrieving institutional knowledge.

The Observer Pattern — one component publishes events, others subscribe and react — is exactly how content flows from creation to distribution. Create once, publish everywhere, with each channel subscribing to the content it cares about.

These patterns exist in every organization. Most people just can’t see them because they’ve never had a notation system that makes them visible. Code is that notation system.

The Real Insight

I’m not suggesting everyone go model their company in Java. That would be absurd. (Though I clearly did it, so who am I to judge.)

The real insight is simpler: the questions that type systems force you to answer are the questions every organization should answer. What do you own? What don’t you own? What do you depend on? What depends on you? What’s your interface — the contract you expose to the world?

Most organizational problems aren’t strategy problems. They’re boundary problems. They’re the result of undefined interfaces, implicit dependencies, and roles that do too much.

The compiler catches these bugs. The question is: what catches them in your organization?

---

Huy Dang is the founder of AccelMars, building tools for the AI era. Follow the journey on X and LinkedIn.