When the System is Susan

Why Operations determines whether readiness depends on systems or on people 

OPTIC² is a framework for understanding why funder-readiness is an organizational challenge and what it takes to fix it. It organizes readiness into six interdependent layers: Operations, Public Presence, Trust, Identity, Credibility, and Communications. This post is part of a series examining each layer in depth. For an introduction to the full model, start with The Real Problem Isn't the Writer. 

The proposal is due on Friday. Susan knows where the outcome numbers are: maybe in a spreadsheet from last quarter or possibly in an email she sent to the executive director in November. She knows the budget needs a signature from the finance committee chair, who is traveling. She knows the logic model is in a folder from two years ago that may or may not reflect the current program design. 

She has been here before. She knows who to call, what to ask for, and roughly how long each piece will take to chase down. 

She will get it done. She always gets it done, but that is the problem. 

When readiness depends on one person’s memory, relationships, and willingness to heroically hold the whole system together, it is not a system. It is a person, and when that person leaves, gets sick, or simply reaches the limit of what one person can absorb, the organization discovers how little of the process was ever actually documented. 

That is an Operations problem. 

What Operations actually is 

In the OPTIC2 model, Operations is the internal infrastructure that makes everything else executable: the workflows, calendars, roles, and systems that allow an organization to pursue funding, manage awards, meet reporting requirements, and maintain funder relationships without depending on any one person to hold it together from memory. 

This is not exciting work. It is also not optional. 

Operations covers the full grant lifecycle — from the moment an opportunity appears to the moment the final report goes out and the relationship is documented for renewal. That includes: 

• A grant calendar so opportunities are not missed 

• A proposal development workflow so everyone knows their role and their deadline 

• A budget-to-general ledger coding plan so award funds are tracked correctly from day one 

• A reporting calendar with named owners and backups 

• A file structure anyone can navigate, not just the person who built it 

It also includes clarity about who has authority to make decisions: who can commit the organization to a funding opportunity, who approves program changes that affect grant compliance, and who escalates when something goes wrong. That kind of clarity is easy to overlook when things are running smoothly. It becomes critical the moment they are not. 

The difference between a system and a person 

Most organizations have someone who functions as the de facto Operations layer. 

They carry the grant calendar in their head. They know which funder wants a site visit before the deadline and which one prefers not to hear from you until the award cycle opens. They know where the files actually are, as opposed to where they are supposed to be. 

That person is often very good at what they do. They are also, without meaning to be, a single point of failure. 

The question Operations asks is not whether the work is getting done. It is whether the work could still get done if the person doing it were suddenly unavailable. Whether a new staff member could step in and find what they needed. Whether the process would hold under pressure, or whether it only holds because someone is holding it. 

A system answers yes. 

A person answers yes, for now. 

Funders are buying outcomes, but they are also buying risk reduction. An organization that runs on institutional memory and personal heroics looks different to a funder than one that can demonstrate consistent process, clear roles, and professional follow-through. The difference is not always visible in a single proposal. It tends to show up over time — in reporting quality, in relationship continuity, and in whether the organization can scale without coming apart. 

What happens when Operations is weak 

When this layer is underdeveloped, the scramble is load-bearing. 

Deadlines are met because someone pushed hard enough. Reports go out because the same person who wrote the proposal also tracked the outcomes and remembered the due date. The funder relationship is maintained because the executive director happens to know the program officer personally and stays in touch informally. 

None of that is wrong. All of it is fragile. 

When Operations is weak, gaps in other layers get worse. A weak Communications layer is manageable if someone knows where the old boilerplate lives and can find it quickly. A weak Credibility layer is survivable if someone remembers which spreadsheet has the current numbers. Operations does not cause those gaps, but it determines whether the organization can compensate for them or gets buried by them. 

When a reporting deadline is missed, a compliance requirement is overlooked, or a funder relationship goes cold because no one was tracking touchpoints, those are not writing failures or program failures. They are Operations failures. 

And they carry real consequences for funding relationships that may take years to rebuild. 

What changes when the systems are in place 

When Operations is built, the work does not get easier. Grants are still complex. Reporting is still detailed. Funder relationships still require attention and care. 

What changes is where the energy goes.Instead of spending the week before a deadline locating budget documents and chasing signatures, the proposal team is working from a process everyone understands. The reporting owner knows the due date because it is on a shared calendar, not because someone texted them. The file structure makes sense to anyone who opens it. The funder touchpoint log means no relationship falls through the cracks when staff changes. 

The organization is no longer dependent on one person to hold it together. The system holds it together. The people run the system. 

That distinction matters more than it might seem — not just for operational efficiency, but for what it signals to funders. An organization with clear internal systems looks like a reliable partner. It looks like an organization that will still be running the program correctly two years from now, when the funder checks in. 

Where Operations connects to everything else 

Operations sits at the foundation of the OPTIC² build sequence because without it, nothing else is sustainable. 

Identity can be documented, but if there is no system for maintaining and distributing it, it goes stale. Credibility can be built, but if there is no data collection process or reporting workflow, the evidence base erodes. Communications can be assembled, but if no one owns the boilerplate or knows where the current versions live, the assets drift out of use. 

Operations is the layer that keeps everything else working — not just at the moment it was built, but through staff transitions, program changes, and the ordinary entropy of organizational life. 

If Identity asks who you are and Credibility asks whether you can prove it, Operations asks whether you can keep proving it — reliably, consistently, year after year — without burning out the person who currently holds it all together. 

That is a question worth asking before the next deadline.