John Tolar
Engineering Decision Lab

I turn technical chaos into systems that scale.

Engineering leadership, architecture strategy, and decision-making under pressure.

Tech Debt Confessional

Honest engineering truths.

The assumptions that were wrong. The fixes that were incomplete. What changed.

Sometimes the first fix is just expensive camouflage.

Scaling feels decisive, but it can simply buy time while the actual issue keeps operating underneath.

Reliability

A reset is not a strategy.

Restarting services may purchase time, but it is not resilience. The same failure mode will return.

Operations
Brain as an API

Query my thinking.

Leadership philosophy, architecture decisions, and reasoning — structured as endpoints.

engineering-decision-lab / brain

Core leadership principles and operating style

{
  "principle": "Clarity under pressure",
  "belief": "A leader should reduce ambiguity, expose tradeoffs, and move teams from reactive to intentional.",
  "style": [
    "direct",
    "structured",
    "accountable"
  ],
  "heuristic": "If the team doesn't know why we're doing this, we're not ready to do it."
}
Impact

25M+

Supported issuances

Product scale across real-world operational environments

Multi-team

Leadership scope

Cross-functional engineering leadership and delivery accountability

Modernization

Technical focus

Architecture, technical debt, and systems strategy

Stabilized

Production stability

Production incidents investigated, root-caused, and resolved

Architecture

Systems thinking, made visible.

View all

Multi-tenant architecture

Future state

A future-state model focused on cost efficiency, testability, and flexibility — moving from isolated single-tenant deployments to shared infrastructure with explicit tenant boundaries.

Reduced infrastructure duplication and cost

Higher design discipline required at every layer

Tenant isolation must remain clear even when infra is shared

Worker modularization

In progress

Extracting responsibilities from an overloaded monolithic worker service into clearer, independently scalable service boundaries.

Higher operational complexity during transition

Improved reliability and targeted scalability after

Clearer ownership boundaries per domain

Technical debt sequencing

Ongoing

A structured approach to paying down debt in the right order — starting with the debt that blocks the highest-value architectural moves.

Slower initial progress compared to opportunistic fixes

Higher long-term velocity as blockers are cleared

Requires communicating debt roadmap to non-technical stakeholders

Cost optimization strategy

Completed

Identifying infrastructure waste — over-provisioned resources, misaligned scaling policies, and redundant services — and eliminating it without sacrificing reliability.

Risk of under-provisioning if optimization is too aggressive

Improved unit economics and infrastructure budget

Better understanding of actual load patterns and bottlenecks

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.