Open to Engineering Manager / Director roles
About
John Tolar (JT)
Software Engineering Manager / Director focused on scaling high-performing teams and resilient architectures.
25+
Years in Engineering and mentoring
90%+
Alert Noise Reduced
Open to Engineering Manager / Director roles
Software Engineering Manager / Director focused on scaling high-performing teams and resilient architectures.
25+
Years in Engineering and mentoring
90%+
Alert Noise Reduced
4s → 500ms
API Response Improvement
4+
Years Leading Engineering
Multi-team engineering organizations in regulated SaaS and compliance environments
Architecture modernization: monolith decomposition, cloud migrations, dependency pipeline overhauls
Incident response and stabilization — turning 4-hour outages into systemic process improvements
Technical debt sequencing across platform, infrastructure, and team boundaries
I've spent most of my career in systems that don't behave the way we expect them to. Under load, across teams, and in environments where the impact of a decision is real.
The hardest problems I've worked on sit at the intersection of people, systems, and decisions. A 47-minute database outage that triggered SLA penalties. A monolithic worker hitting its scaling ceiling with compliance-critical data flowing through it. A lead developer resisting a platform migration they'd need to own. None of these had clean technical answers — they required understanding the full picture.
What I've shipped: reduced alert noise from 400+ weekly alerts to under 20, dropping incident acknowledgment time from 47 minutes to under 5. Delivered a zero-downtime Strangler Fig decomposition of a monolithic worker into independently scalable services. Identified a 23% hidden tax on sprint velocity from poor ticket quality and recovered 175+ developer hours annually. Took a 4-second API endpoint to 500ms by moving aggregation logic out of JavaScript and into the database — no caching infrastructure required.
I lead by making decisions visible. Trade-offs should be explicit, ownership should be designed not declared, and teams should trust the system enough to move fast. Not every decision is perfect, but it should be intentional.
This site demonstrates how I think through ambiguous, high-impact decisions.
Decision visibility — if the team can't explain why we chose this path, we haven't finished deciding
Sustainable velocity over heroic output — I'd rather ship consistently than sprint and crash
Blast radius awareness — every change should have a known failure boundary before it ships
Team autonomy backed by clear ownership boundaries — not "move fast and break things," move fast because the boundaries are right
Fixing the system, not the symptom — whether that's a pod restarting or a developer disengaging, the answer isn't a restart or a PIP, it's understanding what's actually broken