Fifteen years in, I keep coming back to the same handful of things. Most of them are obvious in retrospect and almost none of them are obvious in the moment. They're written down here mostly so I stop having the same conversation in slightly different words.
Question the why.
The most expensive line of code is the one nobody needed.
I've watched plenty of teams burn three weeks on a feature that nobody ended up using. The build itself is the cheap part. The expensive part is maintaining it for years, having it sit in the codebase confusing new engineers, and not building the thing that would have actually moved the business.
So I ask why. Sometimes a lot. It can be annoying. It's also cheaper to be annoying once than to ship the wrong thing and live with it forever.
Less software, more outcomes.
Software is the answer to maybe half the problems people think it is.
If a checklist or a Slack ritual already solves the problem, that's the answer. If a manual process is working and nobody's complaining about it, leave it alone. Every line of code is something a future engineer has to read, run, and replace someday.
The architects I trust most are the ones who push back hardest on building things. They've seen what complexity costs three years later, after the original team has moved on and the original justification has been forgotten.
Build for the team that maintains it.
The team that writes something isn't the team that lives with it.
The clever solution that everyone admires in code review is the one that wakes a junior on-call up at 2 AM six months later, trying to figure out why an abstraction is failing in a way nobody anticipated. The boring solution that's two lines longer survives team turnover and framework migrations and the inevitable "wait, what is this doing?" moments.
I optimize for the next person reading the code. Not the smartest person in the room.
Process before tooling.
A new tool can't fix a broken process. It just hides it for six months.
Slow code reviews aren't a Linear-vs-Jira problem. Sprint chaos isn't solved by buying a different project management tool. Flaky deploys aren't really a CI/CD vendor issue. Underneath each of those is a process nobody has actually fixed, and the new tool just papers over it for a quarter before the same problems show up wearing slightly different colors.
Fix the process first. Buy the tool last, if at all. More often than not, the tool you already have was fine. What needed changing was how the team was using it.
Speed comes from clarity, not from working harder.
Slow teams are almost never slow because of their typing speed.
The fastest teams I've worked on weren't the biggest. They didn't work the longest hours. They definitely weren't on the latest stack. They were the ones where everyone could explain what they were building and why without checking notes. Scope fit in one person's head. Decisions happened close to the work.
If a team is working evenings and weekends and still missing dates, more hours aren't going to fix it. The work just isn't clear enough yet to finish it the first time.
Show up.
"Here am I. Send me." — Isaiah 6:8
Most of the work isn't glamorous. It's a Tuesday morning, an inherited codebase, a stakeholder who's been burned before, and a problem nobody wants to own. The willingness to walk into that room is more valuable than the skill you bring once you're there.
My faith is what frames that for me. It's why I take the call, why I read the whole brief, why I stay until the thing actually works. You don't need to share the same foundation to work with me — but you should know it's the one I'm standing on.
If your team needs more of any of this, I'd be glad to talk.