The work that actually gets programs
done is rarely technical.

I lead technical programs, but what moves them forward is usually the human part.

• Noticing when someone’s stuck and hasn’t said so yet.
• Asking a hard question in a way that doesn’t make anyone feel cornered.
• Earning enough trust that people tell you what’s actually going on, not just the status-update version.

I bring a mechanical engineering background (MS, plus hands-on experience at Los Alamos National Laboratory and Parker Meggitt) and enough software experience to have shipped my own application. That technical depth means I can follow the real conversation in a design review or a sprint retro, not just the summary.

The way I work isn’t tied to one domain. Whether it’s a flight-critical redesign or a software build, I map the dependencies, pressure-test the assumptions, and trace a problem back to its root. That’s why the range across hardware and software holds up. It’s real, not cosmetic.