Most delivery problems are operating-model problems.
Slow teams usually have too much WIP, unclear ownership, brittle deployments, or no real on-call discipline. Those are fixable. Motivation is rarely the bottleneck.
About
I grew into engineering leadership from inside the work.
I am a senior engineering manager based in the Burlington/Raleigh area of North Carolina, currently leading platform modernization and AI tooling for an insurance claims platform. Before this role, most of my career was in public safety software - 911 computer-aided dispatch, criminal justice records, and the mobile terminals police officers use in their cars.
How I got here
I started out in cellular hardware at Sony Ericsson in the late 2000s, writing the Windows software that talked to Sony Ericsson's PC cards: PC300, MD300, EC400, and F3507g. After short stints consulting at GlaxoSmithKline and Cigna, I joined CentralSquare Technologies as a senior developer in 2009.
I stayed there eleven years. Long enough to be part of major product rewrites, acquisition and merger transitions, and one significant platform shift. That is where I learned most of what I know about regulated systems. We rewrote major parts of the suite - CAD, RMS, and the mobile terminal - from FoxPro to .NET while public safety agencies depended on the existing products in production.
We partnered with AWS ProServ on the planning and early execution of moving that suite to AWS GovCloud - a program I helped kick off and led teams on before transitioning to my next role. We also containerized the application stack with Docker across Dev, QA, and IT. I was selected for the company's FAB50 leadership group during that period, a CEO-level recognition program for the top 50 leaders across a 2,000+ person organization.
After CentralSquare I moved to Mark43 as a senior engineering manager - remote-first public safety SaaS - and then to my current role in insurance claims, where the systems are different but the operating constraints are similar: regulated, audited, mission-critical, and unforgiving of careless changes.
Senior developer to team lead to assistant manager to engineering manager, while still owning architecture, database performance, deployments, customer integrations, and production support along the way. That is why I am still close to the technical decisions.
How I think about the work
Modernization is a sequencing problem, not a technology problem.
The interesting decisions are about which systems to leave alone and for how long. Anyone can draw the target architecture; the work is in the path between here and there.
On-call shapes the rest of engineering.
Teams that own their own pagers build different software than teams that do not. I would rather fix the on-call model than write more incident postmortems.
AI tooling is an operating-model change.
The teams I see getting real value treat it as workflow redesign, not a tool rollout. The teams I see getting nothing are the ones measuring adoption.
A few things outside the resume
I read widely - Julie Zhuo, Lencioni, and Michael Lopp on management; Marcus Aurelius and Rumi for clarity under pressure; Kahneman for the things you cannot trust about your own thinking. And I have traveled to 60+ countries over the years, which has done more to shape how I think about leading across cultures and time zones than any management book.
I also care about growing engineers. A lot of the work I am proudest of from the public safety years was hiring college graduates and watching them become the senior engineers the rewrite depended on.
What this site is
A place for sanitized case studies from past roles, build notes from current work, and writing on the topics above. It is not a comprehensive portfolio - just the parts of the work I would want a hiring manager or peer to read.
Credentials
- AWS Certified Solutions Architect
- Certified Scrum Master
- Microsoft Certified: MCTS and MCPD
Education
- Master of Computer Applications, Nirma University
- Bachelor's in Information Science, SP University