My company held a leadership summit this month. I went in expecting the usual — slide decks about strategy, breakout sessions with forced participation, a keynote that everyone claps at and nobody remembers by Monday. I was wrong. Our CEO, Sarah Chavarria — she's brilliant, genuinely, and almost certainly doesn't know I exist — gave a talk about inspiring what's next. About not staying in your lane. About being bold enough to think bigger than your job description and audacious enough to act on it. And something about the way she said it broke something open in me. I'd been writing musings for a year, scattered across the internet under a pseudonym. Hiding behind the words without putting my name on them. She told the leadership gang to stop playing small, and I realized I was doing exactly that. I walked out, built this website, called it Inspire What's Next — her words, repurposed as my mandate — and put my real name on everything. Sarah doesn't know I exist. But she gave me a permission I didn't know I was waiting for. Permission to come out and be who I am. And who I am is an engineer who can't stop optimizing — and who is starting to wrestle with what that actually costs.
There's a thing that lives inside every engineer, and it never shuts up. It looks at a process that takes ten steps and whispers: this could be three. It sees friction and it cannot rest until the friction is gone. I've had it my whole career. I've built systems that replaced manual processes, automated pipelines that used to require entire teams, designed architectures that turned weeks of work into minutes of compute. And every single time, it felt right. Like progress. Like I was doing what engineers are supposed to do: making things better, faster, smoother, more frictionless. And then one day you look up and realize that "frictionless" has a body count. Not literally. Nobody died because I automated a report. But someone's job changed. Someone's role got smaller. Someone went from being the person who knows how to run this process to being the person whose process doesn't need running anymore. The claims processor whose workflow I streamlined. The data analyst whose report I automated. The QA team that got halved because my test pipeline caught more bugs with fewer people. These aren't abstractions. These are the people on the other side of my efficiency obsession. And I've spent most of my career not thinking about them, because the engineer's brain doesn't think in people. It thinks in systems. And systems don't have families.
I don't have a resolution. I still automate things. I still optimize. I still feel that itch when I see friction, and I still scratch it. But I've started asking a question I never used to ask: who is on the other side of this? Not what system. Not what workflow. Who. What person's day am I about to change? What job am I about to reshape? And if the answer is "someone," I don't stop — because stopping isn't an option in this industry — but I slow down. I think about whether there's a way to make the person more capable instead of more replaceable. I think about whether the efficiency I'm chasing is worth the human cost of catching it.
Engineers like satisfying answers. Clean solutions, elegant architectures, systems that resolve to zero friction. This problem doesn't have one of those. But I refuse to accept that the only two options are "optimize everything and damn the consequences" or "slow down and let the competition eat you." If you think deep enough, there's a way to bring everyone along for the ride. Retrain the claims processor to manage the AI that replaced her workflow. Promote the data analyst into the architect role because she understands the domain better than any model ever will. Build the automation and then build the bridge that helps the person cross to the other side of it. It's harder. It's slower. It's more expensive in the short term. But it's the only version of progress that doesn't leave a trail of people behind. Sarah told me to be bold. So here's bold: I will never stop building toward frictionless systems. But I will also never be ignorant about what that costs. The engineer who optimizes without thinking about the people isn't an engineer. He's just a machine that writes code. And we already have enough of those.