The context

TRAILS was growing fast — from a small regional initiative into a national mental health platform serving over 12,000 schools and 30,000+ professionals. With that growth came a problem that quietly compounded every week: the organization had no formal system for managing the devices its employees used.

Devices were tracked inconsistently, if at all. When someone joined, IT provisioning was improvised. When someone left, device recovery was informal — creating real data security exposure. As a remote-first, distributed workforce, the stakes of getting this wrong were higher than they would be in a traditional office environment.

What we were working with

When I assessed the landscape, the gaps broke down into five distinct problem areas:

• No reliable asset tracking — device ownership was informal and inventory records were fragmented across spreadsheets and memory
• Inconsistent onboarding — new employee device setup varied by who handled it, leading to configuration gaps and security inconsistencies
• Weak offboarding controls — no defined process for data wiping, device recovery, or access revocation at separation
• Manual provisioning — setup took hours per device with no standardized tooling, causing delays and errors
• No visibility into lifecycle status — leadership had no reliable picture of device age, condition, or reissuance readiness

Individually, each gap was manageable. Together, they represented a meaningful operational and security risk for an organization scaling nationally with sensitive student mental health data in scope.

Key decisions and tradeoffs

This wasn't a case of applying a standard playbook. TRAILS was an early-stage non-profit with lean resources, a distributed workforce, and no existing IT infrastructure to build on. Every design decision had to balance security rigor against operational simplicity.

How it came together

Outcomes and impact

The program launched on schedule and delivered measurable improvements across every dimension we tracked.

Beyond the numbers, this program eliminated a category of security risk that was genuinely concerning for an organization handling sensitive student mental health data. It also gave leadership reliable visibility into the device fleet for the first time — which directly informed budgeting and procurement planning going forward.

The context

USADA's in-house testing application, DCO Mobile, was purpose-built for domestic doping control operations — and it worked well within those boundaries. But as anti-doping operations became increasingly international, the platform's limitations became a real operational liability. DCO Mobile wasn't designed for direct data exchange with ADAMS, the centralized anti-doping management system governed by the World Anti-Doping Agency (WADA), meaning every cross-border coordination required manual reconciliation to bridge the gap.

MODOC — a globally adopted testing platform used by anti-doping organizations worldwide — offered a path to standardization. Making the switch meant gaining native ADAMS integration and alignment with international agency workflows, but it also meant migrating mission-critical operations for a program where disruption to live athlete testing wasn't just an inconvenience — it was a compliance risk with real consequences for athletes and governing bodies.

What we were working with

The core challenge wasn't just replacing software — it was replacing software that sat at the center of a tightly coupled ecosystem of internal systems, external agencies, and field operations.

• No native ADAMS integration in DCO Mobile — every cross-border data exchange required manual effort to reformat and reconcile testing records
• Misalignment with international agency workflows — other anti-doping organizations operated in MODOC, creating friction in joint testing programs
• Complex internal dependencies — MODOC needed to integrate with SIMON, PostgreSQL, and SFTP pipelines without disrupting existing workflows
• Distributed field operations — DCOs worked across geographically dispersed locations, making a simultaneous cutover operationally dangerous
• Decommissioning risk — retiring DCO Mobile meant ensuring no historical data was lost and no active testing workflows were left mid-cycle

What I owned on this project

How it came together

Outcomes and impact

The migration completed on schedule across all regions with no disruption to live athlete testing operations.

The context

TRAILS had been running its national training program out of Airtable — a tool that worked at smaller scale but couldn't keep pace with the organization's growth. Records were inconsistent and unreliable, there was no way to link program delivery data, training history, and stakeholder information in one place, and leadership had no clear national view of program reach or outcomes. As TRAILS expanded to thousands of schools across the country, the gap between what the organization needed and what Airtable could provide became impossible to work around.

The decision was made to move to Salesforce Nonprofit Cloud. I was brought in to lead that project — owning requirements, vendor coordination, testing, data migration, and user adoption — in partnership with an external Salesforce implementation vendor who handled the platform architecture, object configuration, flows, and integrations.

The resulting Salesforce environment became far more than a CRM. It houses TRAILS' entire program operation — training management, stakeholder relationships, marketing, and donor tracking — and powers a Zoom integration that automates training delivery. When a training is created in Salesforce with the relevant accounts attached, Zoom meetings are automatically generated and invites sent. When the session ends, Zoom sends attendee data back to Salesforce, and an automated Flow marks participants as trained based on their attendance duration. The TRAILS website then makes API calls to Salesforce to check those training records and serve the content each professional is authorized to access.

What we were working with

Airtable had served as TRAILS' primary system of record, but it was never built for the complexity the organization had grown into. The core problems were:

• Inconsistent and unreliable data — records were maintained differently across teams with no enforced standards, making it impossible to trust what was in the system
• No meaningful linkage between program delivery, training history, and stakeholder relationships — everything lived in disconnected tables
• No national reporting capability — leadership had no reliable view of training reach, completion rates, or program outcomes at scale
• No way to automate training delivery or credential verification — every step required manual coordination across multiple tools
• No scalable access controls — as more staff touched program data, the lack of governance created real security exposure

The 41,354 records being migrated represented both current and historical data — every person and organization TRAILS had a relationship with, going back through the organization's history. Getting that data clean and accurately mapped before migration was essential, because these records would immediately drive live training delivery and website access once Salesforce went live.

Key decisions and my role

This project was delivered in partnership with an external Salesforce implementation vendor who owned the platform architecture — designing the objects, relationships, flows, and integrations. My role was to lead the project on TRAILS' side: owning requirements, keeping the vendor accountable to them, validating what was being built, executing the data migration, and ensuring the organization was ready to adopt the new system.

How it came together

Outcomes and impact

The implementation delivered a system that was meaningfully more complex than a standard CRM rollout — Salesforce now serves as the live operational backbone of TRAILS' national training program.

Beyond the numbers, the most significant outcome is structural: TRAILS now has a single source of truth that simultaneously powers internal operations and controls what tens of thousands of trained professionals can access on the website. Leadership has reliable national reporting on training delivery and program reach for the first time, and the system is architected to scale with the organization's continued growth.

The context

USADA's athlete compliance operations ran on a legacy platform that had aged out of step with the demands placed on it. Whereabouts reporting — the process by which athletes in the Registered Testing Pool must file their daily location availability for no-advance-notice testing — requires precision and consistency. A system that's hard to use produces errors. Errors produce compliance risk. And in anti-doping, compliance risk has real consequences for athletes.

Athlete Connect was USADA's answer: a modern, purpose-built web application designed around how athletes actually work, built by USADA's internal development team. I was embedded in that team as part of the DevOps function throughout my time at USADA — leading sprint planning, owning requirements, and driving UAT from inside the delivery process rather than managing it from the outside.

What we were working with

• Low adoption driven by poor usability — athletes avoided or minimized their use of the platform, increasing the likelihood of missed filings and compliance gaps
• High error rates in Whereabouts reporting — a system that made errors easy was a systemic compliance risk under WADA rules
• Limited operational visibility — staff had insufficient real-time insight into athlete compliance status for proactive outreach
• Fragmented data — athlete testing records, drug reference data, and compliance history lived in separate systems with no unified view

Key decisions and tradeoffs

How it came together

Outcomes and impact

Athlete Connect established a centralized, integrated compliance platform that gave USADA teams real-time visibility into athlete status for the first time — shifting from reactive case management to proactive outreach, which is a fundamentally more effective operating model.

The context

When a Doping Control Officer conducts an athlete test in the field, every step — from notification to sample collection to chain-of-custody documentation — must be recorded with precision. The data is legally significant: it forms the evidentiary basis for anti-doping rule violation proceedings and must be defensible under international arbitration standards.

For years, USADA managed this process on paper. Officers completed forms by hand, scanned them, emailed them to headquarters, and then staff re-entered the data into internal systems. As testing operations scaled, this workflow became an operational liability. USADA partnered with an external software vendor to build DCO Mobile — a custom application purpose-built for doping control field operations. I led the project on USADA's side: owning requirements, coordinating with the vendor, leading all testing, and serving as the field validator who took the application live at actual athlete competitions.

What we were working with

• Manual data entry at two points — in the field on paper, then again at headquarters during transcription — doubled the opportunity for error at every single test
• Transmission delays — physical forms moved through scan-email-entry workflows that added hours between field collection and lab receipt
• Limited traceability — reconstructing chain of custody for a given sample required piecing together paper records, scanned documents, and email threads
• No pre-arrival data to labs — laboratories received samples before having any advance information, increasing processing time and delays

My role in this project

How it came together

Outcomes and impact

The context

The Air Force Satellite Control Network (AFSCN) is the global ground-based infrastructure that commands and controls U.S. military satellites. It operates across geographically distributed sites, with each location dependent on communications infrastructure, command and control systems, and IT support that must be available continuously — but especially during launch windows, when new satellites are being brought into operational status.

Launch events are operationally compressed and unforgiving. The sequence of events runs on a precise timeline. Any gap in IT infrastructure, communications availability, or systems support during that window doesn't produce a minor inconvenience; it produces a mission impact. My role was to ensure that never happened.

What we were working with

• Zero tolerance for downtime — any failure in command and control systems or communications during a launch window had direct mission consequences
• Geographically distributed dependencies — multiple sites across different time zones had to be confirmed ready before a launch could proceed
• Compressed resolution windows — issues that could be addressed over hours in normal operations had to be resolved in minutes during a live event
• High consequence of escalation gaps — unclear escalation paths could delay issue resolution past the point where recovery was possible
• Limited rehearsal opportunity — launches happen on fixed schedules determined by orbital mechanics, not IT readiness

Key decisions and tradeoffs

How it came together

Outcomes and impact

The operational processes developed through these launch events — structured pre-launch validation, explicit escalation paths, and disciplined post-event review — became repeatable standards that improved consistency across subsequent events. The broader IT operations program was recognized as a Best Practice by the Air Force Space Command Inspector General.