Building Programs That Outlast Their Founders

I have seen a lot of library programs that were really people.

Not in a pejorative sense. The person was skilled, committed, and genuinely good at the work. But the program was legible only through them. The workshops happened because they showed up. The relationships held because they maintained them. The documentation existed mostly in their head.

When they left — promotion, retirement, burnout, another offer — the program did not survive them in any meaningful form. Sometimes it limped along. More often it quietly stopped.

This is not a failure of individual people. It is a failure of how we build things.


The dependency problem

Programs built around a person share a structural flaw: their sustainability is bounded by that person’s continued presence and capacity.

This matters more than it might seem. The half-life of a library staff member in a given role is short. People leave for better positions, move to other institutions, or take on responsibilities that pull them away from what they built. A program designed to require a specific individual will, with near certainty, eventually encounter that individual’s departure.

The question is not whether the founder will leave. The question is what survives when they do.


UC Carpentries as a case study

When I started building the UC Carpentries network, I had a choice about what I was building.

One option was to build something efficient: centrally coordinated, with UCLA running the workshops and setting the curriculum, other campuses participating when they wanted to. Fast to stand up. Responsive. Dependent on continued UCLA staff investment.

The other option was harder: build a distributed network with shared governance, cross-campus instructor communities, and decision-making structures that did not route everything through me or my team.

I chose the second.

It took longer. It required negotiating with campus partners who had their own priorities. It required documentation, governance agreements, and investing in instructor training at campuses that could not easily reciprocate immediately.

The payoff is that the network now runs without depending on any single campus. Workshops happen even when UCLA staff are stretched. The 10-campus structure has its own momentum. If I were to leave tomorrow, UC Carpentries would not end.

That resilience is the design.


What building for survival requires

Documentation that actually exists. Not in one person’s email history or their memory of conversations from 2019. Real documentation of how decisions are made, who has authority over what, and how new participants get oriented.

Distributed authority. Programs that survive are programs where multiple people have real decision-making power. This requires founders to give power away, which is often harder than it sounds. Founders usually built the thing because they cared about it. Handing authority to others requires trusting that they will care appropriately, even if they make different choices than you would.

Training the trainers. The IMLS open science curriculum work is explicitly structured around this. We are not just developing lessons — we are developing the instructor community that can sustain, revise, and extend those lessons without our involvement. Fourteen new lessons funded, piloted, and moving toward integration into existing training ecosystems. The goal is a curriculum that keeps running when we stop paying attention to it.

Governance at the right scale. Governance sounds bureaucratic. In practice, it means the program has a way to make decisions, resolve disagreements, and adapt to new circumstances without those processes requiring someone specific to be in the room. The Library Carpentry Curriculum Advisory group I helped lead is an example: formal pathways for lesson adoption and review that operate independently of any individual contributor.


What this requires of founders

It requires a different orientation toward the work.

If the goal is to build something that works while you are there, you can optimize for your own efficiency. Be the hub. Make decisions quickly. Rely on your own judgment. It will work, and it will be fast.

If the goal is to build something that works after you leave, you have to optimize for distributed capacity. Slow down to document. Create decision structures even when you could just decide yourself. Train people even when you could do the thing faster.

This is genuinely harder. It is also the only kind of building that produces durable programs.

The test I use: if I stepped away tomorrow, what would stop working? Every answer to that question is a governance gap. Close the gaps before you leave, not after.


On claiming this as leadership

I want to be direct about something.

Building programs that outlast their founders is leadership. Not management, not coordination — leadership.

It requires a vision of what the program is for that extends beyond your own tenure. It requires the discipline to build structures even when they slow you down. It requires trusting others enough to give them real authority. And it requires accepting that the program’s success will eventually be credited to others.

That last part is not incidental. If the program survives you, it will be improved by your successors. They will get credit for that improvement. You built the thing that made the improvement possible.

That is the right outcome. It is what we should be trying to build.