About
Most engineers start with "Hello World." Mine starts with a $2 million pricing problem.
Before engineering, I worked in finance, pricing, sales, and field roles at Ford. That matters because I still see software through the business process it's supposed to fix: who touches it, where it stalls, and what the delay costs.
Origin
Four Excel files, Raptor, and a 30-day delay.
In 2019, I was working in finance and pricing at Ford. Interest rate spreads moved through four Excel files (one for each market area), brand approvals, and then a legacy system called Raptor. Brand managers negotiated spreads, someone keyed the changes in manually, and everybody waited.
That was annoying on a quiet week. During the end of ZIRP, with Fed meetings moving rates, it got expensive. A 30-day lag between decision and system update could cost roughly $2 million a year.
I proposed an automated fix. The answer was: "We don't have the technical resources or skills to do that." Fair enough. So I built what I could with the skills I had, then spent nights and weekends filling in the rest: Java, Python, React, Terraform, cloud systems, design patterns. The first version cut the delay down to about a week.
That was the point where software stopped feeling like another department and started feeling like another tool I needed to be useful.
The through line
I have been the field rep and the engineer with the ticket.
I spent the first half of my career in sales and business development, moving through 7 states and 13 territories for Ford. I have been the person asking engineering for help, and now I have been the person receiving the Jira ticket. That ruins you in a useful way.
People rarely hand you the real problem neatly packaged. They hand you the workaround. A dashboard request might be a broken handoff. An AI request might be a team without a shared way of writing things down. A "simple automation" might be covering for a system nobody trusts.
So I ask annoying questions early. Who touches this? What breaks silently? Where does the money leak? What happens after version one ships? That's the operator part of me. The engineer part still has to make the APIs, queues, schemas, tests, and logs behave.
Working standards
Business math first
Before the architecture diagram, I want the boring numbers. Where is the money leaking? Where is the time going? What breaks if the system is slow, wrong, or quietly stuck?
Production tells the truth
A green job with an empty database isn't success. Ask me how I learned that one. The work has to tell you what happened, not just that something ran.
Context has to live somewhere
If the important part only exists in Slack, a console click, or someone's memory, it's already drifting. Write down the traps before they become folklore.
Production scars
The database was empty, but the job said success.
Early in my automation career, a workflow reported success while the target database stayed empty. It took about 24 hours to find the real issue: DevOps had failed us over to us-west-2, while part of the application still pointed at us-east-1.
Nobody was trying to be careless. The system just had enough hidden assumptions to lie convincingly. That one stuck.
Now I care a lot about boring things: logs that show the actual outcome, alerts on the result instead of the attempt, config that lives in code, and docs that tell the next person where the trap doors are. Glamorous? No. Useful? Very.
Selected background
The formal record, minus the resume wall.
Now
Lead Software Engineer
Morningstar
Regulated workflows, queues, compliance systems, observability, and the kind of cloud work where missing a record isn't a cute little edge case.
2021-2024
Connected Vehicle Engineering
Ford Motor Company
IoT telemetry, Kafka, Pub/Sub, identity work, inventory audit automation, and vehicle event systems across hundreds of thousands of connected vehicles.
2017-2021
Finance, pricing, sales, business development
Ford Credit / Ford Motor Company
The business-side apprenticeship: dealer ops, pricing systems, field trust, manual process pain, and what long delays actually cost.
A little more human
The page behind the portfolio.
I taught myself engineering from the business side inward. Java made me slow down. Python made me dangerous enough to automate things. React made me respect state more than I wanted to.
Recursion was the first CS concept that made my brain need a new gear. It clicked when I stopped treating it like syntax and started seeing trees, sorts, and repeated structures.
I have lived in Dallas, Atlanta, Denver, Boston, and Detroit. Moving that much gives you a useful read on incentives, communication styles, and how quickly headquarters assumptions get weird in the field.
Outside work: gym 3-5 times a week for years, nutrition tracking, country music, and 2000s rock. Creed and Nickelback are OK by me. I said what I said.
Working together
If your team needs help.
I take on a small amount of independent work each week: AI coding tool adoption, convention files, automation architecture, and the system decisions that keep getting deferred because every option has consequences.
If that sounds like your team, the services page has the details on how I work and how to start a conversation.
View services