
Three Targets I Set for My Engineering Team
The three targets I set for my engineering team — PR size, open-to-merge time, and change failure rate — and why these are the three that matter.
I'm an Engineering Manager and Technical Architect who ships at slightly-illegal speeds by pairing sharp architecture with AI-powered workflows. I lead engineers across the stack, run crisp sprints, and keep code quality high with friendly-but-firm guardrails (review SLAs, PR size limits, and real tests). I modernize platforms from monolith to TypeScript microservices, design scalable Postgres with RLS, build sane RBAC for multi-tenant apps, and wire the hard bits—auth/MFA, data sync, job queues, CDC—so legacy and modern systems play nice. Releases flow through AWS with feature flags, while Sentry and CloudWatch keep us humble. I partner with Product and Design to turn ambitious ideas into shippable reality, balancing speed with reliability and leading with technical excellence, empathy, and just enough sarcasm to keep retros interesting.

The three targets I set for my engineering team — PR size, open-to-merge time, and change failure rate — and why these are the three that matter.

Most code-review checklists ask "does this work?" The harder question is "what happens when it doesn't?" Five things I check on every PR that the standard checklists miss... plus the comment grammar that makes reviews actually move.

Building software is like traveling between destinations. In our case, it’s traveling from Problem...