Case study
Building systems for genomics at scale
Software infrastructure connecting laboratory activity, genomic processing, quality controls, and data delivery across clinical and research programs.
Genomic testing is not a single computation. Samples move through laboratory processes, software systems, computational pipelines, quality checks, and downstream delivery—often across several teams and programs.
Within the Broad Institute's Genomics Platform, I worked on the software infrastructure connecting these steps. Over five years, my role expanded from implementation and production operations toward technical scoping, architecture decisions, workflow design, and cross-functional problem solving.
01 · The environment
A workflow is only as strong as its connections.
A clinical genomics workflow has to connect laboratory activity and sample data to computational pipelines, quality controls, and downstream delivery. Each program brings its own needs, while clinical and regulated laboratory processes constrain how the system can behave.
- Sample / input
- Laboratory activity
- Workflow orchestration
- Genomic processing
- Quality & failure detection
- Data delivery
- Research / clinical program
02 · The platform problem
Distinct programs, repeated infrastructure.
Different research and clinical programs have distinct workflows and delivery requirements. Building each independently can create duplicate onboarding work, inconsistent validation, repeated delivery implementations, and more operational complexity.
The useful question became: which behavior should be shared?
Reusable platform capabilities offered a way to reduce fragmentation without pretending every program was the same. The goal was not a single rigid workflow; it was a common foundation that could support real differences.
03 · My role
Software Engineer
Built data pipelines and reusable onboarding, validation, and delivery capabilities; supported eMERGE; and helped operate and enhance COVID-19 production systems.
Senior Software Engineer
Led implementation of core platform features, authored technical scopes, evaluated architecture options, helped define requirements and data models, and worked across laboratory, clinical, and engineering constraints. This sustained hands-on work also made me the repository's top code contributor.
04 · Reuse
Building reusable capabilities
Build the capability once where possible.
I worked on shared onboarding, validation, delivery, orchestration, and data-representation capabilities that could replace some program-specific implementations. Reuse mattered because a reliable solution for one launch could become a stronger starting point for the next.
The architectural tradeoff was not “generic versus custom.” It was deciding which concepts were stable enough to share and where program-specific behavior still belonged.
05 · Traceability
Making workflow state understandable
In a long, multi-stage workflow, operational questions often reduce to: Where is this sample? What happened? What should happen next? Which step failed? What is waiting downstream?
I defined PostgreSQL data models connecting sample, laboratory, pipeline, and delivery activity. Together with production quality signals, these models made workflow state easier to reason about and helped surface failures before they disrupted downstream teams.
- SampleIdentity and current state
- Laboratory activityWhat occurred upstream
- Pipeline activityProcessing and failure state
- Delivery stateWhat downstream teams receive
06 · Reliability
Designing for failure
A production workflow is not reliable merely because the happy path works.
Quality signals had to distinguish expected progression from abnormal state. The practical value came from detecting failures early, preserving traceability, and reducing the chance that a hidden upstream issue became a downstream surprise.
07 · Cross-functional decisions
Working across disciplines
Architecture choices were also workflow choices. I partnered with laboratory teams, clinical geneticists, and engineers to define requirements and evaluate what the system should do.
08 · Operations
Controlling operational cost
As retained cloud data grew, manual cleanup became both repetitive and difficult to enforce. I automated retention policies that encoded lifecycle rules in the system, balancing ongoing operational needs against growing storage costs—without attaching an unsupported savings estimate to the work.
09 · Programs supported
Shared capabilities in real programs
Genomic risk information for clinical use
Production systems at public-health scale
I helped operate and enhance a production system moving sample and result data from intake to reporting. The broader operation supported by that system delivered more than 33 million tests over two years and approximately 5% of U.S. tests at peak.
What I learned
The code was only one layer of the system.
The hardest systems problems were rarely isolated coding problems. They sat at the intersection of software behavior, laboratory workflows, operational constraints, failure modes, and people trying to get work done.
As my role grew, more of my work involved shaping how the system should behave—not simply implementing a predefined answer.