Skip to content

How to stand up a program from zero

I have built programs from a blank page more than once — intake, tracking, the whole apparatus.

I have built programs from a blank page more than once, the whole apparatus: intake, tracking, the rules, the roles. It is exhilarating and it is where good intentions most often calcify into bad bureaucracy, depending on one early choice.

The common mistake is to start with the org chart and the process map. It feels responsible, like real planning. But designing the structure before you understand the person you are serving produces a program optimized for its own tidiness, with the actual human need bolted on awkwardly afterward.

Start at the other end. Begin with the person you exist to serve and the specific thing they need, then work backward to the smallest system that reliably gets it to them. Everything you build should trace back to that need. If a process cannot explain how it serves the person, it is serving the program instead.

Then add structure only where the absence of it is actively causing pain. Premature process is a tax you pay forever. You can always formalize a workflow once you understand it through repetition; it is far harder to un-bureaucratize something you over-engineered before you knew what you were doing.

The programs I am proudest of felt almost too simple at launch, and grew their structure in response to real friction rather than imagined risk. Starting small is not a lack of ambition. It is the discipline of letting the work, and the people it serves, tell you what the program actually needs to become.