Most engineers start their career after college. I started mine in high school, when NASA came calling.
I was seventeen. I didn't fully understand what I was walking into at Langley, only that these people were building things that mattered and they were letting me help. That feeling, the quiet thrill of working on something bigger than yourself, never left. It became the filter I've run every career decision through since.
But if I'm honest, the deeper filter didn't come from NASA. It came from how I was raised. I grew up watching people in my family and my community give without talking about it. Show up for others without making it a story. Do the right thing not because anyone was watching, but because that's just what you do. That shaped me more than any job title ever has. The work ethic, the listening, the belief that how you treat people matters more than what you accomplish. I carried all of that into engineering, and it's never left.
Two decades later, across aerospace, public health, fintech, and AI, I keep coming back to the same question: does this work leave someone better off? Not in the abstract. Not on a slide. In their actual life.
What the CDC taught me about building for people
For years I built the data systems behind an international tuberculosis clinical trial. Drug inventory management, clinical monitoring, FDA-compliant data pipelines. The kind of systems that don't make headlines but quietly determine whether a study succeeds or fails.
There was a moment early on when the weight of it hit me. We were debugging an issue in the drug management system, and I realized that the data flowing through my code wasn't metrics. It was people. Patients in multiple countries enrolled in a trial that could change the standard of care for TB treatment worldwide. Every field I validated, every edge case I caught, every decision I made about how data moved through the system was connected to a person waiting for better medicine.
"Ship it" carries a different weight when you understand that. A bug isn't a bad sprint. It's a risk to a study that families are depending on. You write code differently when the users aren't customers. They're patients.
That experience changed how I think about engineering. Not what tools I use or how I architect systems. Those are skills. What changed was my understanding of why those skills matter. Engineering is at its best when it's in service of people. Not in service of the demo, the funding round, or the logo wall. In service of the person on the other end who may never know your name but whose life is a little better because you got the details right.
The quiet work
I've never been the loudest person in the room. That's by choice.
I've spent a career listening more than talking. Showing up for people before they ask. Mentoring engineers who remind me of who I was at twenty-two, unsure whether they belonged in rooms that felt too big for them. Volunteering for the work that doesn't come with a title or a press release. Sitting on diversity councils not because it looks good on a résumé, but because I've seen firsthand what happens when capable people get locked out of rooms they've earned a seat in.
None of that is on my LinkedIn. Most of it never will be. That's fine. The work matters more than the credit.
What I've learned from the quiet work is the same thing I've learned from engineering: the most important things you build are often invisible to everyone except the people they help. A system that keeps clinical trial data safe. A conversation that keeps a junior engineer from quitting. A door held open for someone who didn't know it was there.
The people I admire most in this industry operate the same way. They're not the ones giving keynotes about their impact. They're the ones whose former teammates, years later, still say "she's the reason I stayed in engineering." That's the kind of legacy I care about.
Empathy as engineering
I know that sounds soft. It's not.
Empathy in engineering starts before you write a line of code. It means sitting with a client or a user long enough to understand the problem they're actually trying to solve, not just the feature they're asking for. A founder says "we need a dashboard." What they actually need is to stop feeling blind about their own business. An operations lead says "the system is too slow." What they really mean is "I'm spending two hours a day on something that should take ten minutes." If you build what people ask for without understanding why they're asking, you'll deliver something that technically works and functionally misses.
The best products I've built started with listening. Not a requirements document. A conversation. What does your day look like? What have you given up trying to fix? The real requirements live in the workarounds people have stopped complaining about. In the manual processes they've accepted as normal because nobody ever asked if it could be better.
Empathy also means designing for the person who's tired, distracted, under pressure, and just needs the thing to work. That's not edge-case thinking. That's the actual use case, most of the time.
And it extends to the people building the product. The best teams I've led shipped well not because they were pressured to, but because they felt safe enough to be honest. Safe to say "I don't know how to do this yet." Safe to flag a problem early instead of hiding it until it became a crisis. You build that safety the same way you build good software: deliberately, one interaction at a time. Sometimes an engineer needs a pairing session. Sometimes they need someone to say "you belong here." Those two situations look identical from the outside. Knowing the difference is the job.
The measure of whether any of it worked isn't sprint velocity. It's what happens after I leave. Did the team get stronger? Did someone grow into a role they didn't think they were ready for? The best engineering leaders I've known didn't build great products. They built great teams that built great products.
Choosing what to build
Having twenty years in this industry gives you options. It also gives you a responsibility to choose well.
I've built defense systems that protect people. Data infrastructure that helped bring a TB treatment to market. Fintech tools that gave people access to financial services they'd been excluded from. And now, with ELITE, I'm building a system that lets people prove what they can actually do, so opportunity flows toward capability instead of pedigree.
The industries change. The through-line doesn't. Every project I've taken on shares the same quality: if it works, someone's life gets a little more fair, a little more dignified, a little more possible.
I don't hand teams a strategy deck and disappear. I embed. I write the code. I stay until it works. Not because I need to prove something. Because that's how I was taught to show up. You do the work. You do it right. You do it for the person who's counting on it, whether they know your name or not.
The bar
Early in my career I thought the job was to build great technology. I still believe that. But "great" has a different meaning to me now than it did at seventeen.
Great technology isn't the most elegant code or the most sophisticated system. It's the system that works so well for the people who need it that they never have to think about it. It's the data pipeline that a researcher trusts without questioning. The credential that a hiring manager believes without second-guessing. The tool that gives someone their time back so they can spend it on something that matters to them.
The best work I've done has been the quietest. The systems nobody sees. The people nobody thanks. The small choices that add up over twenty years into something you can look back on and say: that mattered. Not because I said so. Because the people it served are better off.
Technology is only worth it when it leaves people better off. That's the bar. It has been for twenty years. Everything else is just implementation.