Ideas & Writing Michael Orlando

If you want the venture index page, start here: Interdisciplinary Design Collaborative.

IDC matters in my story for one reason: it’s where I first built a real operating system for turning a messy list of ideas into shipped work with other people.

Before there was Lumate. Before there were mobile apps. Before there was an adtech platform or a data business.

There was a student-run LLC at Missouri S&T that existed to do something very specific:

Give students real project experience they can use to get their first job by shipping real work, winning real grants, and learning how to operate as a team.

What IDC was (in plain language)

Interdisciplinary Design Collaborative LLC (IDC) was a student-run incubator and execution studio at Missouri S&T in the 2007–2012 era.

I formed IDC as a Missouri LLC in 2008 while I was still an undergraduate. It was not a student club. It was a legal entity with the ability to sign agreements, pay people, and hold work.

The reason the “LLC” part matters is simple: it forced the work to be real. When you’re accountable to program officers, grant reviewers, clients, and contracts — not just a classroom rubric — you learn what the world actually rewards.

The problem IDC was trying to solve

In university, most students graduate with a transcript and a few class projects.

The gap is that employers don’t just hire for knowledge. They hire for demonstrated ability to:

  • take an ambiguous problem
  • build something concrete
  • work across disciplines
  • communicate progress and constraints
  • and ship outcomes under real expectations

IDC existed to close that gap for students by giving them a place to do real work while they were still in school.

How IDC actually operated

IDC was not one project. It was a portfolio.

The core pattern looked like this:

  1. Maintain a big idea list (not everything gets built).
  2. Form matrixed project teams around the most promising opportunities.
  3. Use “functional groups” to share specialized capability across multiple projects.
  4. Write proposals, win funding, execute, and publish results.
  5. Capture the learning so the next project starts with better structure than the last.

Two design choices made IDC different from a normal student organization:

1) The matrix was intentional

Students weren’t boxed into a single club role. Teams were built across disciplines as needed (hardware, software, energy systems, business, documentation).

The goal wasn’t “be interdisciplinary” as an identity. The goal was to match the shape of the team to the shape of the work.

2) Execution had to be legible

IDC used real operating patterns: agreements, tracking, role clarity, and the kinds of documentation that let someone new join without everything depending on tribal knowledge.

That bias toward legibility still drives how I build today.

The kinds of work we did (non-mobile era)

In the pre-mobile era, IDC’s project portfolio was wide:

  • SBIR proposal work (EPA / DoD style efforts)
  • a funded residential energy optimization project
  • hybrid PV-thermal and sensor-network R&D
  • data systems work tied to defense/intelligence contexts
  • product prototypes and small consulting engagements
  • early human-computation experiments that later shaped PulaCloud

If you’re reading this and thinking “that’s an odd mix,” that’s the point: IDC was a forcing function for synthesis. We had to learn how to move between domains while still operating with real accountability.

What it produced (why it wasn’t just “experience”)

IDC had three categories of output that matter:

1) Student outcomes

The most durable result was student trajectory change.

People could walk into an interview with shipped work, proposal wins, and real project leadership experience — not just “I took a class.”

2) Proof that students can operate at a higher bar

We submitted millions of dollars worth of proposals, won meaningful funding, and built work that had external stakeholders.

That mattered because it proved a claim I still believe: the limiting factor for most talented people isn’t intelligence. It’s structure, opportunity, and a place to ship.

3) The operating system that everything else re-used

IDC is the root system for later ventures because the patterns were portable:

  • portfolio thinking instead of single-project thinking
  • matrix teams and shared services
  • proposal/pitch discipline
  • documentation and system-of-record habits
  • explicit upside sharing instead of vague “we’ll figure it out”

Those patterns show up later in IDC Projects, Lumate, PulaCloud, Great Data Lake, and eventually AspirationalX — even when the domain changes completely.

How this affects how I work with people now

IDC trained a few instincts that are hard-coded into how I collaborate:

  • I don’t trust “alignment” that isn’t written down.
  • I assume most execution failure is structural before it’s personal.
  • I prefer small teams with clear roles over large groups with vague enthusiasm.
  • I’d rather ship one real thing than talk about ten impressive possibilities.

If you want to work with me and you want it to go well, the best pattern is:

  • bring a real problem with real constraints
  • agree on what “done” means
  • build a structure we can both point at
  • ship something, then iterate

If you want to go deeper: