top of page
Context
A fun, flawed, and flat incubator structure
E-Board Project Management Lead at OK, USC's creative incubator, managing five concurrent cross-functional teams. OK is a USC creative incubator that allows students to pitch projects, which it then allocates resources towards, for a semester at a time. OK ran on an intentionally flat structure, which had real upside for individual agency and passion-driven work, but by the end of the incubator's first semester most projects barely crossed the finish line or weren't complete by review. My own project had run well and completed on time, because I'd built my own structure for it. The following semester, I was brought onto the e-board to install something similar club-wide.
What was needed
A standard system for wildly different projects
OK did not seek out a certain type of creative, they welcomed any and all types of projects. Because of this, the incubator needed a shared system flexible enough to fit wildly different projects, from card games to furniture pieces, without forcing every team into the same process. It also needed to be a system that would actually get used, since the club had already tried optional versions that didn't stick.
Work I did
Structure that fit the culture instead of fighting it
I started by giving everything a home. I built a unified planning space in Notion, one page per team, familiarizing myself with the tools at my disposal. However, the first real constraint was time: I could build a shared space, but I only had so many days to onboard and tailor it to five teams before their projects got underway. I prioritized the largest and most complex teams first, since they had the most to lose from starting without structure, and worked down from there.
The bigger problem wasn't the tool, it was adoption. Three things were killing it: expectations and tools weren't established before projects got underway, teams were encouraged to operate "headless," without a lead, so no one owned using the system, and a one-size-fits-all version didn't fit projects different enough that teams used it wrong or gave up on it. So, I set aside one-on-one time with each lead to personalize it and set expectations for how it would actually be used.
There was real pushback from leadership, though. OK's culture was built around being flat and deliberately "no-boss," and structured leadership ran against that on principle. So, when I spearheaded instituting a project lead role, the actual work was finding a version of ownership that gave projects someone accountable, without recreating the hierarchy the club had intentionally built itself against.
What Changed
MVP completion up 40%, then adopted club-wide
I measured this by comparing projects in a complete MVP state at the semester check-in, before the framework and after. MVP completion rose 40% the semester it was implemented, and it was later adopted program-wide, beyond the five teams I ran it with directly.
What I Learned
What actually makes a system stick with operators
Three things sit underneath this: set expectations and vision early, before people are already underway. It's also valuable to respect the culture you're operating inside instead of overriding it. Lastly, it's important to build for the specific needs in front of you instead of one version meant to fit everyone, that's usually what breaks adoption.
bottom of page