Engineering Decision Lab
Decisions shaped by experience, grounded in real-world systems.
Software Engineering Manager / Director focused on scaling high-performing teams and resilient architectures.
Start here: If you're evaluating me for engineering leadership, start with a Lab — they're real decisions I've navigated, not hypotheticals. Then check the architecture and leadership sections to see how I think about systems, teams, and trade-offs.
AI-powered search
Find what matches your situation.
Describe an engineering challenge in plain text — a migration, a team issue, a reliability problem — and get pointed to the most relevant articles and case studies on this site.
Leadership
Leading through complexity.
Philosophy
The things I'd tell you on day one.
Beliefs shaped by real systems, real failures, and real wins.
Three documents describe your system. Only one of them is true.
The functional spec says what the system is supposed to do. The code comments say what the developer thought it did. The source code says what it actually does. All three start drifting apart the moment they're written — the spec ages, the comments rot, the code keeps running regardless.
Architecture
Don't Tell Me You Can't Do It Unless You Can Tell Me Why
If you can explain why something can't be done, you usually understand it well enough to find a path through. The inability to articulate the blocker is often the actual blocker. It leads to understanding and collaboration.
Mindset
Series
Multi-part deep dives.
Leadership4 parts
AI Adoption in Engineering Teams
AI adoption fails when leaders treat it as a tool problem instead of a judgment problem — you can't mandate trust, you can't speed your way past context, and you can't automate away the need for thinking. These four pieces show you how to build adoption that actually improves your system instead of just making output faster. The real work isn't getting engineers to use AI. It's building the conditions where they use it right.
View seriesArchitecture
Systems thinking, made visible.
ArchitectureIncident ResponseFeatured
Production Pods Were Restarting Randomly
A production incident involving intermittent connection failures and pod restarts under normal traffic patterns.
What's at stake
- Users are seeing failures in real time
- Logs are noisy and hard to read
- Leadership is asking for answers
Situation
About
John Tolar (JT)
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.
Recent
Latest articles
Architecture
Taming 50 Million Callbacks with Event-Driven Architecture
A legacy .NET HttpHandler buried inside the customer portal was processing webhook callbacks synchronously — and at 20M+ messages a month, vendor retry storms inflated that to 75 million callbacks with 90-second processing latency. We replaced it with an Azure Function that acknowledges in milliseconds and routes to channel-isolated processors via Service Bus, dropping latency to sub-second and eliminating the retry cascade entirely.
Read article
Architecture
When Compliance Makes the Architectural Decision for You
The cleanest architectural decisions aren't the ones where you evaluate all the options and pick the best one. They're the ones where a constraint eliminates the bad options and forces you to build something more durable than unconstrained choice would have produced. Compliance requirements did that here — and the result was a better design than I would have chosen on my own.
Read article