Why Every Founder Should Learn to Think in Types

You don’t need to learn to code. But you absolutely need to learn to think in types.

What does your company own? What does it produce? What does it consume? What must it never touch?

If you can’t answer those questions crisply for every department, every product, every process — your organization has undefined behavior. In programming, undefined behavior is a bug. In business, it’s the thing that kills you slowly while everyone insists things are “fine.”

What “Thinking in Types” Means

In programming, a type system is the language’s way of making you declare what things are before you use them. An integer isn’t a string. A customer isn’t an order. A read-only reference can’t be used to modify data.

This sounds tedious. It’s actually liberating. When you’re forced to define what something is, you discover what it isn’t. And the “isn’t” is where most organizational confusion lives.

Consider a “Product Manager” role. In most companies, that title is effectively any — the type that means “could be anything.” It owns the roadmap, talks to customers, writes specs, coordinates engineering, reports metrics, manages stakeholders, and somehow also “drives strategy.” That’s not a role. That’s a type error.

A typed version would look different: ProductManager implements RoadmapOwner, CustomerResearcher, SpecWriter. Now you can ask: who implements StakeholderCommunication? Is that the PM too? Should it be? The type system forces the conversation that the job description dodges.

What Rust Taught Me About Ownership

Of all the programming languages I’ve used to think about organization design, Rust taught me the most. Not because of its syntax — because of its ownership model.

In Rust, every piece of data has exactly one owner at any time. You can lend it out temporarily (borrowing), but ownership is always clear. When the owner goes out of scope, the data is cleaned up. There’s no garbage collector making guesses. Ownership is explicit, enforced, and non-negotiable.

Now apply that to a business:

Ownership. Every asset, every decision domain, every piece of institutional knowledge should have exactly one owner. Not “the leadership team” — one specific function. When ownership is shared, it’s actually unowned. Nobody maintains what everybody owns.

Borrowing. Other functions can use what you own, but they don’t get to modify it. Marketing can read the product roadmap. It doesn’t get to change it. Engineering can reference the brand guidelines. It doesn’t get to override them. This is borrowing — access without ownership.

Lifetimes. In Rust, borrowed references can’t outlive the thing they borrow from. In a business, this means: temporary projects, seasonal roles, and ad-hoc committees should have explicit expiration. When the thing they depend on goes away, they go away too. No zombie processes consuming resources forever.

Move semantics. When ownership transfers, the previous owner can no longer access the data. In organizations: when you move a responsibility from engineering to product, engineering doesn’t get to keep making those decisions. The transfer is complete. Dual ownership is a compile error.

The Four Questions

Every function, department, product, and process in your company should be able to answer four questions:

1. What do I own? What am I the single source of truth for? What decisions are mine alone to make?

2. What do I produce? What do other parts of the organization consume from me? What’s my output interface?

3. What do I consume? What do I depend on from others? What breaks if they change?

4. What do I explicitly not own? What’s adjacent to my domain but NOT my responsibility? Where’s the boundary?

That fourth question is the killer. Almost nobody answers it. And that’s where all the confusion, duplication, and territorial conflict lives.

When two departments both think they own customer communication, you get inconsistent messaging. When neither thinks they own it, messages fall through the cracks. The solution isn’t a meeting — it’s a type declaration. Someone owns it. The rest borrow read access.

Why This Matters Now

The AI era makes this urgent. When you’re delegating to AI agents, ambiguous boundaries become immediate failures. An AI session with unclear ownership will confidently modify things it shouldn’t touch, produce outputs that conflict with other sessions, and create messes faster than any human team could.

Clear types — clear ownership, explicit interfaces, defined boundaries — are the prerequisite for effective AI delegation. Not optional. Prerequisite.

I’ve found that organizations that can answer the four questions cleanly can delegate to AI effectively. Organizations that can’t answer them struggle with human teams too — they just struggle more slowly.

You Don’t Need to Write Code

I modeled my company in Java. I thought about ownership through Rust’s lens. But you don’t need to do either of those things.

What you need is the discipline these languages enforce: declare what things are. Define boundaries. Make ownership explicit. Separate interface from implementation — what something promises to do from how it does it.

You can do this on a whiteboard. You can do it in a spreadsheet. The notation doesn’t matter. What matters is answering the questions the type system would force you to answer.

What do you own? What do you produce? What do you consume? What don’t you own?

Start there. The compiler in your head will catch more bugs than you expect.

---

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