• As team captain for a NYC recreational soccer league, identified that managing attendance over WhatsApp, schedules over email, and enrollment through a Google Sheet was unnecessary friction — and built an app to address it
• Built a React Native iOS MVP in TypeScript covering player accounts, schedule viewing, game RSVPs, push notifications, league enrollment, team management, and an admin dashboard
• Currently in alpha — replacing dummy data with real league data and validating the push notification system before pitching to the league and submitting to the App Store

I joined a recreational soccer league in NYC, took on the role of team captain, and decided to build an app after noticing how much friction the league's current setup created. Managing attendance meant chasing RSVPs over WhatsApp, game times arrived via email two days before kickoff, and players enrolled in new seasons through a Google Sheet linked on the league's website. Most leagues in the city already have a dedicated app for this, and it seemed like a natural gap to fill.

I built a React Native iOS MVP in TypeScript, covering the core player-facing and admin workflows: player accounts and authentication, schedule viewing with a calendar grid, game RSVPs, push notification reminders, league enrollment, team management, and an admin dashboard with CSV export. It's currently in alpha; I'm replacing dummy data with real league data and verifying the notification system end-to-end before pitching it to the league and deploying to the App Store.

• Built five modular C++ ROS 2 (Robot Operating System 2) packages from scratch in a 6-hour coding challenge: clock pose issuer, GUI pose issuer, motion controller, and two coordinate frame transformers
• Designed the system so a robot follows pose inputs from multiple sources (clock-based positions or user-selected GUI poses) and reaches each target via a motion controller
• Handled coordinate frame conversion between the normalized world frame and the robot's local body frame to keep each package decoupled from the simulation's internals
• Delivered a full documentation suite, system connectivity diagram, test suite, and shell scripts for building and launching the system

For a 6-hour robotics coding challenge, I designed and implemented a ROS 2 (Robot Operating System 2) stack in C++ where a robot follows pose inputs from multiple sources and reaches each target using a motion controller. I built five packages from scratch, each with a focused responsibility. The clock pose issuer converts clock time into 6D positions on a unit circle. The GUI pose issuer gives the user a manual interface to issue pose commands directly, with a spacebar reset. The motion controller subscribes to both pose sources and converts the target pose into velocity commands. Two transformer packages handle coordinate frame conversion, mapping between the normalized world frame and the robot's local body frame, so each component stays decoupled from the simulation's internal coordinate system.

I also wrote a full documentation suite covering installation, build and run instructions, and testing and formatting procedures, and included a system diagram showing how all five packages connect through their ROS 2 topics. I kept each package's structure consistent and straightforward to extend — adding a new package or controller means following a clear pattern rather than reverse-engineering existing code. The submission included a test suite and shell scripts for rebuilding and launching the system.

• Designed and demonstrated a multi-agent path planning and collision avoidance system on Michigan's physical M-Bot robots, built on the CBS (Conflict-Based Search) algorithm for completeness and optimality guarantees
• Led path-following logic implementation, TCP (Transmission Control Protocol) server-client architecture, and PID (Proportional-Integral-Derivative) controller configuration for robot operation
• Owned the testing effort — designed the QA test plan, test scenarios, simulation field, and testing matrix; ran six successful trials across varying levels of map complexity; produced a video walkthrough of the system

I chose EECS 467: Autonomous Robotics as my capstone (Michigan's Major Design Experience, or MDE) because I had a strong interest and academic background in robotics by senior year. Our team of four designed and demonstrated a multi-agent path planning and collision avoidance system on Michigan's physical M-Bot robots. We built on the CBS (Conflict-Based Search) algorithm for its completeness and optimality guarantees, implementing path-following logic that translated a 2D path array into linear and angular velocities over a TCP (Transmission Control Protocol) server-client architecture, and configured a PID (Proportional-Integral-Derivative) controller for each robot to ensure smooth operation.

My primary contributions were leading the path-following logic implementation, TCP communications, and PID controller configuration, as well as owning the testing effort. I designed the QA test plan to verify the system worked end-to-end in the real world — creating test scenarios, designing the simulation field, and building the testing matrix. We ran six trials across varying levels of map complexity, and the system performed successfully. I also led the team's technical documentation, including producing a video walkthrough of the system.

• Implemented occupancy grid mapping, particle filter localization, and path planning on a LiDAR-equipped M-Bot
• Built forward and inverse kinematics models to translate between joint space and physical robot motion
• Fused odometry and LiDAR data for accurate real-time localization
• Tuned PID controllers for reliable low-level motor control on physical hardware
• Demonstrated end-to-end autonomous maze navigation on a physical robot

EECS 467 was a lab-based robotics course built around the M-Bot, a four-wheel-drive robot equipped with a LiDAR (Light Detection and Ranging) sensor. Working with one partner, I implemented the core stack for SLAM (Simultaneous Localization and Mapping) based autonomous navigation across a series of labs that each built on the last.

We started with low-level control: odometry and PID (Proportional-Integral-Derivative) tuning to get the robot moving accurately, then moved up to occupancy grid mapping, where the robot used LiDAR readings to build a 2D map of its environment. From there we added localization using a particle filter, so the robot could track its position within that map in real time. Path planning came last, tying everything together so the robot could navigate autonomously — finding its way through a maze it had never seen before. The robot navigated the maze end-to-end at the final demo.

• Designed and implemented a reactive autonomous Rocket League algorithm using real-time computer vision input
• Wrote the computer vision Python script detecting AprilTags and field colors for real-time robot state estimation
• Led C implementation of embedded components: magnetometer, gameplay timers, PS2 controller SPI communication, and USB-to-Serial adapter
• Scoped and demoed a goaltending robot under time pressure after a last-minute team setback
• Produced systems engineering diagrams, a milestone report, and the project poster

EECS 373 was an embedded systems design course concluding with a month-long team project. Our team of four chose to build a real-life version of Rocket League, the car-soccer video game, where a human-controlled robot competed against an autonomous one on a physical field. My primary ownership was the autonomy algorithm: a reactive system that used a computer vision Python script to detect the ball and field state in real time and feed that directly into the robot's decisions.

On the embedded side, I led the C implementation for several components: a magnetometer for orientation, gameplay timers, PlayStation 2 controller SPI (Serial Peripheral Interface) communication for the human-controlled robot, and a USB-to-Serial adapter for system communication. The computer vision side was Python — I wrote the script that detected AprilTags (QR-code-style markers used for position tracking) and colors on the field to feed real-time state into the robot's decisions. I also designed and implemented the full autonomous Rocket League algorithm, though the demo circumstances meant it never got validated and tested in time. My documentation contributions included systems engineering diagrams, a milestone report, and the project poster.

Two days before the demo, it was clear a critical piece of a teammate's work wasn't going to be ready. The rest of the team pulled an all-nighter to stabilize what we could, which left no time to validate the full autonomy algorithm. I made the call to scope it down to a goaltending robot that used the CV (computer vision) system to track the ball and move to intercept it. It worked, though latency in the pipeline meant it struggled with fast shots. The lesson I took from it was practical: trust teammates but verify progress early, and test in small integrated chunks throughout a project rather than waiting for full system tests at the end.

• Replicated Zhang et al.'s "Colorful Image Colorization" CNN architecture, training on a 90,000-image subset of the MIT Mini Places dataset
• Investigated the impact of loss function choice by substituting the authors' Cross Entropy loss with MSE (Mean Squared Error)
• Tuned ADAM (Adaptive Moment Estimation) optimizer parameters to compensate for reduced computational resources and training data
• Demonstrated that MSE produces visibly duller, more monochromatic outputs than Cross Entropy on a pixel classification task

EECS 442 covered the core theory and methods of computer vision, including convolutional neural networks, image processing, and deep learning approaches to visual understanding. The course culminated in an independent research report, for which I chose to replicate a published deep learning colorization model and use it to investigate how loss function choice affects output quality.

The model, originally from Zhang et al.'s "Colorful Image Colorization" (ECCV 2016), uses a CNN (Convolutional Neural Network) architecture (a class of neural network that applies learned filters across an image to detect patterns) with downsampling and upsampling layers to compress and reconstruct spatial information, batch normalization to stabilize training, and Leaky ReLU (Rectified Linear Unit) activation functions that introduce non-linearity so the network can learn complex mappings. My replication trained on a 90,000-image subset of the MIT Mini Places dataset using a tuned ADAM (Adaptive Moment Estimation) optimizer, an adaptive gradient descent algorithm that adjusts learning rates per parameter during training, and deliberately omitted the authors' class-rebalancing method to isolate the variable I was testing: replacing their Cross Entropy loss function with MSE (Mean Squared Error).

The results were clear. MSE produced consistently duller, more monochromatic outputs — only blues retained any vibrancy across test images. My explanation was that MSE, designed for regression problems where outputs can range across any value, converges much more slowly on a classification task like colorization than Cross Entropy, which is purpose-built to penalize confident wrong predictions. The experiment confirmed that loss function choice is not just a technical detail: it has a direct, visible impact on what a model actually learns to produce.

• Built the original site in summer 2022 using HTML, CSS, and JavaScript, customizing an HTML5 UP template as a foundation
• Identified a gap between the site and my personal brand, then redesigned the entire UI from scratch
• Introduced a two-layer content model (modal and longform toggle) so the reader actively chooses how deep to go, keeping the main view skimmable by default
• Rebuilt the visual design to reflect a clear personal brand: an engineer who thinks logically and communicates clearly

I built the first version of this site in summer 2022 using HTML, CSS, and JavaScript, customizing an HTML5 UP template as a foundation. It did the job of displaying my work, but returning to it later, I realized the layout was harder to read than it should have been — even I struggled to skim it, and I wrote the material. The visual design didn't reflect how I think about my own work, and nothing about it communicated a clear point of view.

In spring 2026, I decided to redesign it from scratch, starting by defining my personal brand: an engineer who approaches problems logically and communicates clearly. I used that as the design brief and built the entire UI myself. The most important structural change was introducing a two-layer content model: all detailed content is now hidden behind both a modal and a longform toggle, so the reader actively chooses how deep to go rather than being confronted with everything at once. The main view stays clean and skimmable by default. The visual design I built from scratch to match that brand — the site now feels like it belongs to someone with a specific point of view rather than a generic portfolio template.

• Built an ACC (Adaptive Cruise Control) system in Simulink with three autonomous operating modes: manual, fixed-velocity, and lead-car position-following
• Deployed the system onto an S32K144 microcontroller via Simulink's automatic C code generation, running on a physical driving simulator
• Developed a haptic interface embedded controller across earlier assignments using C, SPI protocol, and NXP software
• Designed PID controllers and vehicle dynamics models in Simulink to represent systems of differential equations
• Debugged subsystem behavior by analyzing oscilloscope waveform responses from sensor inputs

EECS 461 was an embedded control systems course built around progressively complex assignments, each adding a layer toward the final project. Throughout the semester, my partner and I developed a haptic interface embedded controller using an S32K144 microcontroller, C, and SPI (Serial Peripheral Interface) protocol in an NXP software workspace, writing C code to read from and write to hardware registers directly. We designed flow logic, PID controllers, and vehicle dynamics models in Simulink to represent complex systems of differential equations, and used an oscilloscope to analyze subsystem waveform responses for debugging.

The final project brought all of it together: an ACC (Adaptive Cruise Control) system with three operating modes and auto-steering active throughout. In Manual mode, the user controls speed and path through a potentiometer and haptic wheel. Velocity mode sets a fixed traveling speed via dip switches on the microcontroller. Position mode activates automatically when a lead car enters a preset distance and is traveling slower, matching its speed. We built the entire system in Simulink using scaffolding provided by the course instructors, then used Simulink's automatic C code generation to deploy it onto the S32K144 microcontroller running on a physical driving simulator.

The system performed successfully at the demo — all three modes triggered and transitioned correctly, and the position-following behavior worked as intended.

• Benchmarked five character classifiers in Python using scikit-learn against the EMNIST (Extended Modified National Institute of Standards and Technology) dataset (60,000 training samples): KNN (K-Nearest Neighbors), SVM (Support Vector Machine), Naïve Bayes, Decision Trees, and a LeNet CNN (Convolutional Neural Network)
• Selected the LeNet CNN for the full-scale model based on accuracy, speed, and MATLAB interface compatibility
• Implemented the LaTeX (a document typesetting language used widely in technical and academic writing) document formatting subsystem in MATLAB to convert classifier output into a structured, formatted document
• Led the project plan, defining subsystem ownership and deadlines across a five-person team
• Wrote the majority of project documentation across GitHub and the team website

EECS 351 was a digital signal processing course with a team project component. Our five-person team chose to build a pipeline to convert whiteboard lecture screenshots into formatted LaTeX (a document typesetting language used widely in technical and academic writing) documents, motivated by a real problem we had during COVID: students who miss class and rely on lecture recordings often can't read what's written on the board. The system ran in four sequential stages: image processing and filtering, character isolation, character classification, and LaTeX document generation.

I led the character classification subsystem, where I benchmarked five classifiers in Python using the scikit-learn library against the EMNIST dataset (a standard handwritten character dataset with 60,000 training samples): K-Nearest Neighbors, SVM (Support Vector Machine), Multinomial Naïve Bayes, Decision Trees, and a LeNet CNN (Convolutional Neural Network), each implemented in their own Jupyter Notebook. SVM achieved the highest accuracy at 90.87%, but I selected the LeNet CNN for the full-scale model because SVM's training and testing time was prohibitively slow and the CNN had a cleaner interface with the broader MATLAB codebase. I also owned the LaTeX document formatting subsystem, which I implemented in MATLAB to take the classifier output and generate a structured document with metadata fields and LaTeX syntax support like superscripts. I led the project plan as well, defining subsystem ownership and deadlines, and wrote the majority of the documentation across GitHub and the team website.

The full pipeline worked end-to-end on block handwriting under good lighting conditions. The main failure modes were light-colored markers, slanted writing, and ambiguous character pairs like O vs. 0 and l vs. 1, limitations we documented and attributed primarily to training data constraints rather than architectural issues.

• Co-authored a research paper with a partner analyzing an autonomous bicycle robot model in Simulink, covering the Pure Pursuit control system, vehicle dynamics, and PRM (Probabilistic Roadmap) path planning algorithm
• Tested PRM robustness across three maps of increasing obstacle coverage (20%, 50%, 73%), varying node count and connection distance across 10,000 trials per configuration
• Found that higher node counts consistently outperformed longer connection distances for path-finding success, with success rates ranging from 100% to 0% depending on map complexity and node count
• Identified diminishing returns beyond 100 nodes, suggesting an optimal node count exists for any given map
• Implemented a custom bicycle plant model in Simulink using continuous time integration, producing smoother paths than the original discrete time implementation

MATH 462 was a mathematical modeling course in which my partner and I chose our own research topic for the final paper. We decided to investigate an autonomous bicycle robot model in Simulink, focusing on three areas: the existing control system, the vehicle dynamics, and the robustness of the PRM (Probabilistic Roadmap) path planning algorithm.

The PRM algorithm distributes randomly placed nodes across a map, connects any two nodes within a specified Euclidean distance, and uses Dijkstra's algorithm to find the shortest path from start to goal. To test its robustness, we varied node count and connection distance across three maps of increasing complexity: 20%, 50%, and 73% obstacle coverage. The results were concrete: on the simplest map with 100 nodes and a long connection distance, the algorithm found a valid path in 100% of trials. As map complexity increased and node count dropped, success rates fell sharply — to 0% on the most complex map with only 5 nodes. We also found that increasing node count from 100 to 300 produced diminishing returns on path quality, suggesting an optimal node count exists for any given map beyond which additional nodes only increase computational cost without meaningfully improving the path.

On the vehicle dynamics side, we implemented our own plant model in Simulink using continuous time integration to solve the bicycle's kinematic equations — the system of differential equations governing its x/y position and heading angle. Compared to the original model's discrete time integration, our version produced a smoother path, which we attributed to continuous integration better capturing the underlying dynamics of a physical bicycle.

• Built the back end of a functioning superheterodyne AM radio from discrete components: bandpass filter to isolate a target frequency range, envelope detector to demodulate the AM (Amplitude Modulation) signal, and output amplifier to boost audio — all wired in series to a speaker

EECS 216 was an introduction to continuous-time linear systems, covering convolution, Fourier series and transforms, frequency response and filtering, the sampling theorem, and Laplace transforms with poles and zeros. The course tied theory directly to application — lectures covered analog communications and feedback control alongside the mathematical foundations, and five labs put those concepts on physical hardware.

The final lab was the one that brought the most of it together: building the back end of a functioning superheterodyne AM radio from discrete components. Starting from the antenna input, I wired a bandpass filter built from resistors and capacitors to isolate a specific frequency range, an envelope detector using a diode and capacitor to demodulate the AM (Amplitude Modulation) signal by extracting the audio from the carrier wave, and an output amplifier using op-amps to boost the recovered audio signal before sending it to a speaker — all connected in series. To tune to a station, I adjusted the local oscillator frequency to shift a target broadcast into the bandpass filter's range.

• Implemented SillyQL, a simplified SQL (Structured Query Language) query engine in C++, supporting table creation, row insertion, and queries on large datasets
• Made data structure design decisions based on space and time tradeoff analysis to meet performance constraints at scale

EECS 281 is Michigan's core data structures and algorithms course, centered on understanding and navigating the space and time tradeoffs in algorithmic design. The curriculum covered hash tables, binary search trees, graph algorithms, sorting algorithms, priority queues and heaps, and dynamic programming.

The final project was SillyQL, a simplified version of SQL (Structured Query Language, the standard language for querying relational databases). The core challenge was parsing large datasets efficiently — the project required designing a system that could create tables, insert rows, and execute queries, all while choosing the right underlying data structures to meet performance constraints. I used hash tables for fast lookups and binary search trees for ordered queries, selecting between them based on the access pattern the query required.

• Took an unpaid internship before college to get firsthand exposure to engineering research; supported PhD students studying hydrophobic aluminum treatment methods for arctic-bound container ship hulls
• Designed and built an experiment at the end of the summer to test how different phase change materials retained heat under varying ambient conditions, using lab facilities and materials from the PhD team's own research

The summer before starting college I took an unpaid internship at a mechanical engineering research lab at George Washington University — mostly to get a firsthand sense of what research actually looks like before deciding how much to pursue it in college. The day-to-day was unglamorous: compiling notes from research papers, washing labware, preparing samples, and taking observations during experiments run by PhD students studying hydrophobic aluminum treatment methods to prevent hull cracking in container ships bound for arctic regions.

At the end of the summer the team gave me free rein to pick a topic related to the research and use the lab facilities to explore it. I designed and built a metal block with a grid of drilled cavities to test how different phase change materials (materials the PhD students were evaluating) retained heat under varying ambient conditions. The experiment involved heating the block for a set duration, then measuring how long each material held its temperature once removed from the heat source.

• Compiled and synthesized hundreds of testing documents into executive summaries conveying key Lessons Learned to Navy leadership in the Unmanned Maritime Systems Program Office (PMS 406)
• Collaborated with senior engineers to organize a multi-day leadership conference for Unmanned Undersea Vehicle (UUV) Homeport program managers
• Recognized for exceptional communication and documentation skills by the Strategic Capabilities Office (SCO); PMS 406 extended a part-time continuation offer into sophomore year, which I accepted

I joined the Navy's Unmanned Maritime Systems Program Office (PMS 406) after my freshman year of college. My primary work was independently synthesizing hundreds of testing documents into executive summaries conveying key lessons learned, which went directly to Navy leadership within PMS 406. I also collaborated with senior engineers to organize a multi-day leadership conference for UUV (Unmanned Undersea Vehicle) Homeport program managers. The Strategic Capabilities Office recognized my communication and documentation work at the end of the summer, and PMS 406 liked my work enough to offer a part-time continuation into my sophomore year, which I accepted.

• Identified ODRI's original electronics architecture as the primary driver of cost and capability constraints; proposed and led a full electrical redesign replacing it with the MicroDriver v2 and Master Board system — quadrupling communication capabilities and motor control bandwidth while reducing costs by over 91%
• Built out the technical documentation foundation for external collaborators: cost analysis, wiring schematics, circuit tutorials, and a bill of materials on GitHub
• Co-authored a research paper documenting the redesign and presented findings at Michigan's SURE symposium

The Open Dynamic Robot Initiative (ODRI) is an open-source research effort to develop a low-cost quadruped robot as a platform for researchers worldwide to build and test control systems on — the goal being to lower the financial and educational barriers that have historically made robotics research inaccessible. I was one of two undergraduates selected to join the interdisciplinary research team through Michigan's SURE (Summer Undergraduate Research in Engineering) program.

My first contribution was improving the technical foundation for other collaborators: conducting a statistical cost analysis, creating wiring schematics, assembling circuit tutorials, and compiling a bill of materials on GitHub to track research progress. From there I identified that ODRI's original electronics architecture, built around TI evaluation boards requiring separate hardware per motor pair connected to the host PC via CAN, was the primary driver of both cost and capability constraints, and proposed replacing it with the MicroDriver v2 and Master Board system. I led the electrical redesign, reworking the robot's circuitry, computing, communication, and motor control systems: the Master Board manages all motor drivers simultaneously over a high-speed SPI bus and adds WiFi and Ethernet communication to the host PC in place of CAN, quadrupling communication capabilities and motor control bandwidth while reducing costs by over 91%. We documented the mechanical and electrical redesigns in a research paper and presented our findings at Michigan's SURE symposium.

• Completed the primary internship assignment within the first month — built LabVIEW GUIs to automate RF characterization data collection across multiple ADI technologies, including a two-tone intermodulation distortion measurement GUI; authored a ZCG (Zero Code GUI) tutorial guide adopted by other ADI RF testing teams
• Independently identified and automated the senior engineering team's manual test results analysis process while manager was on vacation — built MATLAB parsers that generated radiation performance reports, compiled thousands of raw data files into spreadsheets, and produced hundreds of plots for the design team, saving days of engineering effort per input analyzed

I joined ADI's Aerospace and Defense team as an RF (Radio Frequency) test engineering intern, with a primary assignment to standardize RF characterization data collection for new chips onto a single platform — Zero Code GUI (ZCG) by Soliton Technologies. After completing LabVIEW Core 1 and 2 training, I built GUIs (graphical user interfaces) in National Instruments LabVIEW to automate data collection across multiple ADI technologies, including a GUI to measure 2nd and 3rd order two-tone intermodulation distortion using two signal generators. I also authored a ZCG tutorial guide to help other ADI RF testing teams adopt the platform and contributed weekly UI improvement suggestions to the ZCG development team. I finished the entire assignment within my first month.

With my manager on vacation for much of the summer, I spent the remaining time on a problem I had identified while going through the test results analysis process myself — it was slow and largely manual for the senior engineering team. I built several MATLAB programs to automate it: one parsed large datasets to generate radiation performance reports with tables of key statistics, and another sifted through thousands of raw data files to compile spreadsheets and hundreds of plots for the design team. My manager returned to find the work completed with a few days left in my internship. The automation saved the team days of engineering effort per input analyzed, and the accompanying MATLAB documentation left them equipped to tackle similar projects going forward.

• Promoted from Associate to Autonomy Engineer in eight months — a track that typically takes two or more years

• Identified that the existing Python/Dash stack couldn't support internal deployment and independently rebuilt the application from scratch as a React TypeScript + Python FastAPI + PostgreSQL full-stack web application, designing the database schema and migrating 2GB of data
• Built a Mapbox route network visualization to communicate the optimizer's output — rendering which combinations of airport upgrades enabled which route networks across a target market for a given technology scenario, making the geographic and connectivity implications of each upgrade sequence legible at a glance
• Owned all coding changes to extend the CP-SAT decision model with time-dependent logic, co-developing the math with the senior engineer who originally built the framework, allowing optimal technology selections to persist across multi-year planning horizons
• Drove the case study effort end-to-end — identifying insights to surface, collecting the data, and presenting to 25 Boeing engineers at a sustainability workshop in Seattle
• Produced the program's first comprehensive documentation suite for an 8,000+ line CP-SAT optimization codebase — enabling future developer onboarding on a mathematical framework too complex to approach without it; received an Aurora immediate recognition award

• Won first place in a two-week engineering hackathon by diagnosing and restructuring the Non-CO2 module: eliminating redundant queries and recomputations, cutting runtime from 17m 50s to 4.3s (99.6% improvement), and unblocking the module for customer deployment; received an Aurora immediate recognition award

• Selected among five Aurora engineers in a competitive downselect to continue the program, and placed on the highest-priority workstream: delivering the ICD (Interface Control Document) — coordinating across six companies, architecting the documentation format, and driving on-time content merging for a hundreds-of-pages primary deliverable
• {"Built two automated verification tools to validate the ICD"=>"a Groovy Cameo macro cross-validating thousands of message schema references against the reference architecture, and a Python Word parser flagging prose inconsistencies — recommendations from the latter were adopted into the program's syntax guidelines; received an Aurora immediate recognition award"}
• Designed Level 1 compliance requirements and a C2 (Command and Control) authority model for autonomous distributed systems; both passed Change Review Board across all participating companies

Aurora Flight Sciences is structured as an R&D company, meaning engineers rotate across programs rather than owning a single product long-term. In my time there I worked across six programs, and was promoted from Associate to Autonomy Engineer in eight months — a track that typically takes two or more years.

• Assumed full technical ownership of the reconciliations product area within two months — the previous lead departed mid-project, and I drove it forward as the only engineer on one of the most critical parts of an accounting automation product
• Designed and shipped Custom-Month Reconciliations from scratch, owning the full lifecycle from product scoping and stakeholder alignment through QA and production rollout for thousands of customers — reworking backend data structures and calculation logic to support any monthly close cadence in place of hardcoded calendar-month logic
• Diagnosed and resolved blocking issues in the Reconciliation Editor (a replacement UX built by a contractor who left before finishing it), designed the QA test plan, and drove it to production
• Designed and shipped 12-Month Planning Visibility from scratch, owning the full lifecycle from product scoping and alignment with PM and tech lead through production rollout for thousands of customers — extending the platform's planning horizon for accountants and introducing product controls such as disabling auto-sign-off on tasks in future months
• Resolved 30 customer bugs using test-driven debugging practices — writing tests to reproduce failures before fixing, then expanding the test suite to prevent regressions; was frequently the primary escalation contact for on-call incidents
• Diagnosed and fixed 4 system-level performance issues including line item matching timeouts, database query bottlenecks in orchestration services, and chronic background job failures

I shipped 3 features to production for thousands of customers and owned the entire reconciliations product area — picking up accounting as a new domain from scratch in the process. Within two months of joining, the engineer leading reconciliations departed mid-project, and I assumed full technical ownership as the only engineer actively working on one of the most critical parts of the product.

The flagship initiative I took on was Custom-Month Reconciliations, which I designed and shipped from scratch. The original codebase was hardcoded to perform reconciliations only from the first to the last day of a calendar month. I extended this across the backend, reworking data structures and calculation logic throughout, to support any combination of months over a year, enabling close cadences like quarterly (March, June, September, December) or annual. I started with product scoping (user flow diagrams, product descriptions, and internal FAQs) then validated proposed business logic with accounting stakeholders before moving into technical scoping, breaking my work into milestones with effort estimates and verification criteria. I led a full round of QA testing to verify the feature end-to-end, set up a feature flag for the rollout, authored a finalized product description distributed to non-technical stakeholders, and delivered an internal presentation to the customer-facing support team before driving it to production.

In parallel, I took over the Reconciliation Editor — a replacement UX for the live editor, originally built by a contractor who left before finishing it. The code had been sitting dormant: core UI interactions were broken, including file linking that failed to resolve the correct month and category folder, and any change required mirroring updates across both editors simultaneously. I diagnosed and resolved the blocking issues across frontend and backend logic, designed the QA test plan to verify the feature end-to-end before rollout, and drove it to production.

Beyond reconciliations, I designed, scoped, and shipped a 12-Month Planning Visibility feature from scratch — extending the platform's planning horizon for accountants and including product-level permissions. I authored the product scoping document and got alignment from the program manager, then moved into technical scoping and alignment with the engineering pod's tech lead before owning the full lifecycle through implementation, QA, and production rollout for thousands of customers.

On the production stability side, I resolved 30 customer bugs (including production hotfixes and database migrations to clean up duplicate records and session context errors) using test-driven debugging practices: writing tests to reproduce each failure before implementing a fix, then expanding the test suite to prevent regressions. I was frequently the engineer that on-call escalations landed on, and wrote detailed root cause analyses after each incident. I also diagnosed and fixed four system-level performance issues: line item matching timeouts, database query bottlenecks in orchestration services, and chronic background job failures, unblocking jobs that had been failing entirely. I worked fully AI-native, using AI agents as the primary tool across every stage of the work: coding, debugging, product scoping, technical architecture, and documentation. After four months I decided to leave — the reconciliations product area was in a stable state and I handed it off completely before my last day.

• Tutored guitar to Detroit students through a University of Michigan nonprofit providing free music education in underserved communities, freshman through senior year
• As Director of Music, coordinated tutor and student attendance across multiple locations, managed financial expenditures, and planned end-of-term public showcases giving students a real performance experience

I started tutoring guitar at Seven Mile during my freshman year of college because I resonated with their mission of providing equal access to arts education in underserved communities. A few hours a week watching students grow, as musicians and as people, was one of the most rewarding parts of my time in college.

In my senior year, I stepped into the Director of Music role to get more involved. That meant coordinating tutor and student attendance across multiple locations, managing financial expenditures, and planning public musical showcases at the end of each term where students could perform for their communities. The showcases were the highlight of each term, bringing together tutors, students, and venues to give students a real performance experience and a chance to celebrate their progress.