My Methodology
Much of my work has involved building capabilities that did not already exist, whether that was a structural analysis process, a dynamic model, a surrogate modeling workflow, or software around engineering data. That has made me deliberate about what actually matters, how much modeling a problem really needs, and how I build confidence in the results. As I have taken on more technical leadership, I have tried to bring the same approach to the team by making the objective and tradeoffs clear, giving people room to own their work, and focusing effort where it will have the most impact.
Model what matters
I start by reducing a system to the physics, constraints, and failure modes that drive the engineering decision. I use hand calculations or lower-order models to establish scale and expected behavior, then add FEA, CFD, or other high-fidelity simulation where the additional detail provides useful information.
I also consider computational cost and project timelines. When a detailed model is too expensive to run at the scale needed for design exploration, optimization, or uncertainty studies, I build machine learning surrogate models, to make those analyses practical. The goal is to produce useful, trustworthy results with no more complexity or computational effort than the problem requires.
Validate against reality
I validate models throughout the development process rather than treating validation as a final step. Depending on the problem, that may mean comparing a lower-order model against FEA, checking a surrogate against simulation cases it has not seen, or comparing the full model against test data.
I care less about a single error metric than understanding where the model is accurate, where it begins to break down, and whether that behavior makes sense physically. When something does not line up, I use that discrepancy to decide what needs more work, whether that is the physics, the data, or the model itself.
Lead with clarity
I try to make the objective, constraints, and definition of success clear before getting too far into the technical work. I also make the reasoning behind the approach visible, especially the assumptions, checks, and tradeoffs that will drive the result. That gives everyone enough context to make good decisions without needing every step prescribed for them.
When there is a technical disagreement, I try to get back to the underlying assumptions and evidence, and when possible, turn the disagreement into something we can calculate, simulate, or test. I try to maintain a high technical standard while still giving people room to solve problems their own way.
Prioritize for impact
I often have short-term analysis needs competing with longer-term modeling and software work, so I try to prioritize based on what will create the most leverage. That usually means looking at what is blocking a decision or another engineer, where the biggest technical uncertainty or risk is, and what becomes harder to address if it waits.
For larger efforts, I try to get to a useful intermediate result early rather than waiting for the full solution to be finished. I also look for repeated work that is worth turning into a better method or automated tool. As new results come in, I’m comfortable changing priorities when the value of the work changes, rather than continuing down a path just because it was the original plan.
