LiA - Outcomes Report

AsylumWorks (Arrived) & JustNeighbors

When I wrote my initial LiA proposal, I set out to find an organization working directly with refugees, asylees, and other displaced populations — one with the institutional depth to responsibly engage vulnerable clients, an interest in data-driven evaluation, and enough flexibility to accommodate an independent, non-long-term project. I ultimately built my Leadership in Action experience around two organizations that met those criteria from different angles: AsylumWorks (now rebranded as Arrived), a D.C.-based nonprofit providing wraparound services to asylum seekers and other newcomers, and JustNeighbors, a legal services nonprofit serving low-income immigrants across Northern Virginia. Rather than one placement, I worked concurrently with both as a Data & Communications Consultant and a Data Systems Consultant, respectively — roles that let me apply the same core skill set (data systems, automation, and analytics) to two organizations serving overlapping but distinct populations within the immigration space.

What I Actually Did

At AsylumWorks, I designed a consolidated communications analytics dashboard pulling together roughly two years of engagement data across Instagram, LinkedIn, and email newsletters, and an event-task reminder automation system the development team used during a major fundraising gala. I also built an Asylum Deadline Dashboard & Email Alert tool centralizing asylum filing rules — I-589 deadlines, EOIR filing windows, BIA appeal deadlines, EAD eligibility — into a rules library with a risk-tiered alert system.

At JustNeighbors, I built a Power Query–driven grant reporting system automating compliance reporting across five funders (Fairfax, Arlington, Alexandria, and Loudoun counties, plus VA DOJ), each with different reporting periods, income thresholds, and demographic labeling conventions, and documented it in a how-to-use manual and training deck so staff could maintain it without me.

I want to be honest about the limits of that output, though: I have no way of confirming whether either system is still in active use today. Nonprofit organizations run lean, staff turn over, and priorities shift quickly — I built these tools to be self-sustaining, but sustainability of a system and sustainability of its adoption are two different things, and only the organizations themselves can speak to the latter. What I can speak to with confidence is what building them taught me, which I think is closer to the actual point of a Leadership in Action placement than whether a dashboard is still being clicked on six months later.

Understanding the “Why” Before Proposing the “How”

My instinct coming in was to look for inefficiency and fix it. What I learned instead was to slow down and ask why the inefficiency existed in the first place — often it wasn't a lack of foresight but a real constraint: a case manager juggling triple the caseload a well-resourced organization would carry, a reporting format dictated by a funder's legacy system that nobody at the nonprofit had authority to change, or a process that looked redundant to me but existed because it had been the only reliable way to catch a data error that once caused real harm. At JustNeighbors specifically, the five-county reporting system wasn't fragmented because no one had thought to unify it — it was fragmented because each county funder imposed genuinely different income definitions and fiscal-year conventions, and any “clean” unified system had to preserve those differences rather than paper over them. Designing around that constraint, instead of against it, was the actual skill I built.

Working Within Constraints and Respecting Existing Norms

Both organizations had informal norms I had to learn rather than assume — who needed to sign off before a new process replaced an old one, which staff would actually be the ones re-entering data by hand and therefore had veto power over anything I designed regardless of what leadership wanted, and where documentation lived versus where “how things actually get done” lived. I learned that a technically superior system nobody trusts or understands is worse than a modest one that fits how the team already works. That meant resisting the urge to redesign things I didn't have the standing or context to redesign, and instead building tools that mapped onto existing workflows as closely as possible.

Sensitivity to Vulnerability, Political Volatility, and Staffing Uncertainty

This is where the work felt most different from a typical internship. AsylumWorks navigated a federal grant funding freeze that threatened 60% of its funding portfolio while I was working with them, and a volunteer coordinator I'd been corresponding with left the organization partway through — a reminder that the people I was building institutional knowledge with weren't guaranteed to be there to receive it. I had to design with the assumption that the person maintaining a system in a year might not be the person I trained. That shaped real choices: writing manuals for someone with zero context on my design decisions, avoiding jargon or personal shorthand, and building in guardrails (like flagged fields for manual review rather than silent automation) so a future, less-informed user wouldn't break something by trusting it too much.

More broadly, I came to understand that immigration-serving nonprofits operate inside genuine political volatility — shifting enforcement priorities and funding uncertainty aren't background noise but a constant operational variable — and that clients and staff alike are managing that uncertainty on top of everything else. That context asked for a kind of humility I didn't fully anticipate when I wrote my original proposal: my job wasn't to be the person who fixed things, but to build something durable enough to survive changes I couldn't predict or control, in a sector where nothing about the ground underneath the work stays fixed for long.