Operating Principles

Shipping features is not the goal. Moving business outcomes is the goal.

Most engineering teams measure success by what they ship. Story points completed, PRs merged, features deployed. But shipping a feature that doesn't move a metric is waste. The real question is always: did the work produce the outcome we needed?

I connect OKRs to product roadmaps so teams can trace every sprint's work back to a strategic objective. When engineers understand why they're building something, they make better decisions about how to build it. They push back on low-impact work. They suggest simpler paths to the same outcome.

In practice, this means:

• ▸ Every initiative maps to a measurable OKR. No orphan projects
• ▸ Quarterly planning ties short-term sprints to mid-term objectives to long-term strategy
• ▸ Build feedback loops between delivery and impact. Track what happened after the feature shipped
• ▸ Executive-facing materials tell outcome stories, not activity stories. Data-backed narratives over status updates

Why it matters: Organizations that measure outputs will always overdeliver features and underdeliver results. Outcome-focused teams are more aligned, more motivated, and more effective. They build less and achieve more.

Sustainable excellence comes from well-designed operational systems, not individual effort.

When chaos hits, the teams that thrive aren't the ones with the cleverest engineers. They're the ones with the strongest systems. Distributed systems fail. Dependencies break. Requirements change mid-sprint. Operational systems determine whether those moments are crises or routine responses.

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 prevent it
• ▸ Monitor organizational health with data. Identify bottlenecks and risks before they become fires

Why it matters: Systems compound. Every test you write prevents future bugs. Every code review teaches better patterns. Every post-mortem makes the organization more resilient. Teams that depend on heroics create debt faster than they ship features. Teams with strong systems 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 using Claude Code that ingests transcripts, extracts action items, and updates Asana automatically via MCP integration. 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:

• ▸ Design AI-assisted development setups. Use Claude Code, n8n, and workflow automation to reduce manual coordination
• ▸ Conduct quarterly "friction audits": shadow 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
• ▸ Invest in developer tooling: better local dev environments, faster CI/CD, AI-enabled decision support

Why it matters: Automation isn't just about efficiency. It's about morale. Engineers joined your team to build, not to babysit servers. Every hour you automate is an hour spent on work that moves the business forward. Automation is the force multiplier that lets small teams compete with large ones and scale without hiring.