Decisions shaped by experience, grounded in real-world systems.
Software Engineering Manager / Director focused on scaling high-performing teams and resilient architectures.
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.
Leading through complexity.
Why I Don't Do Technical Interviews for Senior Engineers
A senior engineer's resume already tells me what they know. What it can't tell me is whether they're curious, passionate, and hungry to build great things. That's what the interview is for.
A senior resume already proves technical competence — the interview should go deeper
Behavior, curiosity, and passion reveal more than syntax recall under pressure
The best engineers want to build great things, not just write correct code
Artificial context produces artificial signals — interview for the actual job
Accountable Autonomy: The Leadership Philosophy That Actually Works
The best engineering teams don’t need to be micromanaged — they need to be trusted. But trust without accountability is just abdication. Here’s how to build a culture where capable people own their outcomes.
Autonomy without accountability produces complacency
High expectations and real ownership bring out the best in people
Underperformance addressed early prevents team-wide damage
Trusting your team is not the same as ignoring your team
Scaling Decision-Making: How to Stay Collaborative Without Losing Authority
The best decisions in engineering aren’t made by the loudest voice or the highest title — they’re made through genuine collaboration with clear final authority. Here’s how to build a culture where people are heard, trade-offs are understood, and decisions actually stick.
Collaboration means everyone has a voice — not everyone has a vote
The manager owns the final call, especially on resource and priority trade-offs
Leads resolve what they can; escalate what they can’t
Transparent reasoning builds trust even when people disagree with the outcome
People Are Your Most Valuable Asset — And Most Leaders Don't Actually Believe That
Every leader says it. Few leaders live it. Here's what it actually looks like to treat your people as your most important investment — and why retention is one of the most strategic things a leader can focus on.
Your best people have options — invest in them or lose them
Recognition is just as important as criticism
Growth conversations don't require open headcount to be valuable
Your bad people stay; your good people leave — unless you act
The things I'd tell you on day one.
Beliefs shaped by real systems, real failures, and real wins.
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.
You can delegate a task. You can't delegate the outcome.
Engineers can own a ticket. Leads can own a sprint. But the outcome of what ships — the quality, the reliability, the user experience — that stays with the manager. Delegation is a tool, not a transfer of accountability.
Not all technical debt should be paid at once.
Some debt creates blast radius. Some just creates drag. Fixing drag debt first feels productive — and it is, until you realize the blast radius debt has now accrued interest into a migration. Debt sequencing matters as much as debt reduction.
Clean code that ships never is still just a draft.
Perfect architecture that never gets deployed solves nothing. Iteration beats perfection.
Systems thinking, made visible.
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.
Speed over completeness. Acknowledge first, process later
Isolation over simplicity.
Serverless cost for predictable scale.
Standardization over flexibility.
Independent deploys, coordinated schemas.
From Busy Flag to Service Boundaries
A monolithic worker processing six event-driven workloads behind a single in-memory busy flag couldn't scale horizontally, couldn't deploy independently, and was hiding a race condition on its most critical data collection. Using a phased Strangler Fig migration, we decomposed it into five independent modern .NET Worker Services — sequenced by risk, validated by shadow runs, and delivered without a single outage.
Operational complexity for independent failure domains.
Redis dependency for safe horizontal scaling.
Shadow run duration for cutover confidence.
Strangler Fig pace for rollback safety.
Shared NuGet contracts for consistency.
Security Vulnerabilities Were Accumulating in Our GraphQL Stack
Active CVEs in a production compliance platform. Audit scheduled. Limited team capacity. Every new feature built on a deprecated foundation.
- Active CVEs in a production compliance system handling sensitive data
- Compliance audit in 6 weeks — auditors will check dependency versions
- Every new feature is built on a deprecated, vulnerable foundation
Situation
You're the lead engineer at a compliance SaaS platform. Your GraphQL stack is 2+ years outdated. A security scan just flagged two active CVEs: a DoS vulnerability via malicious file uploads and a SQL injection vector in the type system. A compliance audit is scheduled in 6 weeks. Your team is 3 engineers — one is mid-sprint on a customer feature.
Two active CVEs in production. Audit in 6 weeks. Team of 3. What's your approach?
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.
Want someone who can see both the code and the consequences?
Engineering leadership that connects technical decisions to business outcomes — and can explain both clearly.