Operating Principles

You can't direct the orchestra if you've forgotten how to play the instrument.

I reject the narrative that engineering leadership means "graduating" away from the tools. I operate as a Player-Coach. Whether it's Python automation to eliminate grunt work, architecting event-driven systems with AWS Lambda, or building iOS apps in Swift, I stay sharp. This isn't about ego. It's about credibility and context.

When you understand the friction of building something, you make better architectural decisions. You can tell the difference between a real technical constraint and an excuse. You can review code with empathy because you remember what it's like to be in the trenches.

In practice, this means:

• ▸ I allocate 20% of my time to hands-on technical work. Enough to stay credible without becoming a bottleneck
• ▸ I participate in architecture reviews and POCs, not just approve them from a distance
• ▸ I maintain my own side projects and open-source contributions to keep learning
• ▸ When I ask engineers to adopt a new tool or pattern, I've already used it myself

Why it matters: Engineers respect leaders who understand their reality. When your team knows you can still write production code, they trust your technical judgment. When you speak about cloud infrastructure or deployment friction, it's based on experience, not PowerPoint slides.

Resilience in systems and teams is the result of rigorous standards, not luck.

The Marine Corps taught me that discipline isn't about being rigid. It's about having systems you trust when chaos hits. In software engineering, chaos is the default state. Distributed systems fail. Dependencies break. Requirements change mid-sprint. The teams that thrive aren't the ones with the cleverest engineers; they're the ones with the most disciplined processes.

At SEI, we reduced post-deployment bugs by 73% in 12 months. Not by hiring geniuses. By implementing non-negotiable standards: mandatory code reviews, automated testing gates, infrastructure as code, and deployment checklists. Every. Single. Time. No shortcuts when you're tired. No "just this once" exceptions.

In practice, this means:

• ▸ Pull requests require approval before merge. No exceptions, including for me
• ▸ CI/CD pipelines must pass all tests before deployment. Red builds block everything
• ▸ Infrastructure changes go through Terraform, never manual console clicks
• ▸ Post-mortems are blameless but actionable. We document what broke and how we'll prevent it
• ▸ On-call rotations are sacred. If you're on call, you own the response

Why it matters: Discipline compounds. Every test you write prevents future bugs. Every code review teaches better patterns. Every post-mortem makes the system more resilient. Undisciplined teams create technical debt faster than they ship features. Disciplined teams build systems that scale and sleep well at night.

If we do it twice, we script it. If we do it three times, we build a system for it.

Engineering talent is expensive and scarce. Wasting it on repetitive tasks is criminal. I want my teams solving interesting problems: architecting scalable systems, improving user experience, eliminating bottlenecks. Not clicking through AWS consoles, manually deploying code, or copy-pasting environment configs.

At SEI, I reduced deployment cycles from monthly to multiple times per week by containerizing applications and automating pipelines. At AscellaHealth, I built an AI-powered meeting workflow that ingests transcripts, extracts action items, and updates Asana automatically. The ROI is staggering: 45 minutes saved per deployment, multiplied by dozens of deployments per month, equals hundreds of hours returned to the team for actual engineering work.

In practice, this means:

• ▸ Conduct quarterly "grunt work audits": shadow on-call engineers, review Slack history, identify repetitive pain
• ▸ Apply the 2x/3x rule: document at 2x, automate at 3x occurrences
• ▸ Build self-service tools so engineers don't wait on ops for common tasks
• ▸ Use infrastructure as code (Terraform) so environment setup is reproducible in minutes, not days
• ▸ Invest in developer tooling: better local dev environments, faster CI/CD, smarter linters

Why it matters: Automation isn't just about efficiency. It's about morale. Engineers didn't join your team to babysit servers or manually merge configs. They joined to build. Every hour you automate is an hour they can spend on work that actually moves the business forward. Automation is how small teams compete with large ones. It's the force multiplier that lets you scale without hiring.