Managing 200+ Initiatives Across 70+ Employees
Girl Scouts of Northern Illinois | National Nonprofit | 2013–2018
What this is
Girl Scouts of Northern Illinois is a regional council of one of the largest youth development organizations in the country — serving thousands of girls across a wide geographic area with programming, volunteer management, and community engagement at scale.
The work is complex in the way that mission-driven organizations often are: high stakes, limited resources, multiple stakeholder groups with competing needs, and a constant tension between the strategic vision leadership is trying to execute and the operational reality of the people responsible for delivering it.
I spent five and a half years here across progressively senior roles — moving from Multimedia Manager through Digital Marketing and Project Manager to Director of Girl Experience. The scope expanded because the underlying problem kept revealing itself at the next level. You solve the visibility problem and then you can see the alignment problem. You solve the alignment problem and then you can see the experience consistency problem. Each role was a response to what became visible once the previous layer was functional.
Why this approach — and not another one
Two hundred marketing initiatives across seventy-plus employees is not a project management problem. It's an infrastructure problem. I want to be specific about that distinction because it changes what you build.
A project management response adds oversight — more status meetings, more check-ins, tighter reporting. That approach treats the symptom (things aren't getting done on time) without addressing the cause (nobody has a shared view of what's happening, so priorities can't be negotiated and work gets duplicated without anyone noticing). More meetings in a system without shared visibility just creates more opportunities to discuss the confusion.
The infrastructure response builds the shared view first. Before you can hold people accountable for priorities, they have to be able to see the priorities. Before you can coordinate across teams, everyone has to be working from the same picture of what exists. The system I built wasn't project tracking in the traditional sense — it was a visibility layer that made organizational reality legible to the people responsible for operating inside it.
The KPI framework came from a specific diagnosis: people knew what they were doing but not why it mattered in the context of the larger strategy. That disconnect isn't a motivation problem — it's a structural one. When the link between daily work and strategic goals is implicit, two things happen: progress becomes hard to measure and accountability becomes hard to maintain without it feeling punitive. Making the connection explicit, building a framework that showed how individual work contributed to organizational outcomes, changed the nature of the conversations leadership could have with teams. It moved accountability from "why didn't this get done" to "here's what we're trying to move and here's where we are."
The Salesforce transition work is where I learned the most about what adoption actually requires. The instinct in technology implementations is to train people on the tool and trust that usage will follow. It doesn't. What I did instead was design adoption systems around the training — workflows and structures that made using the platform the path of least resistance for the work people were already trying to do. The training itself is almost the easy part. The hard part is making sure the system people are being trained on actually fits how they work, and building the reinforcement structures that prevent reversion to old habits after the training ends.
The cross-functional collaboration work came last because it required everything else to be in place first. You can't build meaningful collaboration across departments that don't have internal coherence. Once teams had visibility into their own work and clarity about how it connected to strategy, they had something real to bring to cross-functional conversations. Before that, collaboration would have been coordination theater — scheduled time without shared purpose.
What would have broken
The KPI framework carried a real risk I thought about carefully: in mission-driven organizations, measurement frameworks can metastasize into surveillance mechanisms. When people feel like metrics are being used to catch them failing rather than help them succeed, they optimize for the metric instead of the mission. That's a worse outcome than no framework at all. Building in transparency about how the framework would be used — and making sure it was genuinely legible to the people whose work it was measuring, not just legible to leadership — was not optional. A KPI framework that leadership understands and frontline staff can't navigate is a control system, not an alignment tool.
The Salesforce adoption work had a specific failure mode I saw at other councils: surface-level adoption. People learn to use the system well enough to pass the training, then revert to whatever they were doing before because the system wasn't actually built into their workflow. Measuring adoption by training completion is measuring the wrong thing. I measured adoption by whether people were actually using the platform for the work it was supposed to support, which required staying in the process longer than a traditional training engagement and building feedback loops that surfaced where the friction was.
The silos were the most politically delicate piece. Cross-functional collaboration fails in predictable ways when one department has more organizational power or resources than others — the collaboration becomes one department doing the other a favor, which isn't sustainable. It also fails when the structural incentives keep departments competing rather than coordinating. I could build the workflows, but the workflows only held if leadership was genuinely aligned on the value of cross-functional coordination versus departmental autonomy. Where that alignment existed, the models worked. Where it was ambiguous, the old patterns reasserted themselves.
The scope of 200+ initiatives in a single system also created its own maintenance problem. A shared visibility system is only as useful as the discipline to keep it current. If the system becomes the place where things are entered when they're created and never updated, it degrades quickly into a record of past intentions rather than a picture of current reality. Building the habits of maintenance alongside the system itself was part of the work — and the part that required the most sustained attention.
What I learned
The progression across five and a half years taught me something I try to bring into every engagement: organizational problems tend to be nested. The visible problem is usually protecting a less visible one. You solve the project management chaos and discover the real problem was that nobody agreed on what the priorities were. You clarify the priorities and discover the real problem was that teams didn't trust each other enough to share information honestly. Working through the layers without getting impatient with how long it takes is most of the work.
I also learned that infrastructure without adoption is just documentation. The systems I'm most proud of from this period weren't the ones that were most elegantly designed — they were the ones that people actually used, that became part of how the organization operated rather than artifacts that lived in a shared drive. That distinction, between a system that exists and a system that runs, is where most organizational improvement work fails. Getting to the second one requires staying in the work past the point where most consultants or project managers consider the engagement complete.
What I'd do differently: I'd move faster to make the cross-functional work explicit rather than emergent. I believed for too long that if the individual team infrastructures were strong enough, collaboration would naturally follow. It doesn't. Coordination at the organizational level requires its own explicit design, its own ownership, its own accountability structures. Waiting for it to emerge from good team-level infrastructure costs time the organization doesn't have.
Outcomes: The organization gained the infrastructure to manage complexity at scale without losing the quality of the mission-driven work at the center of everything it did. Teams that had been operating in isolation began operating in alignment. Strategic goals that had lived in leadership documents started showing up in the daily work of the people responsible for delivering them.
