"The master craftsman does not simply fix the blade. He redesigns the forge."— Adapted from Zhuangzi
The Challenge
In the early 2000s, Himanshu inherited what might generously be called a failing operation. The Office 365-D Exchange team — managing email infrastructure for tens of millions of dedicated and federal-government seats across thousands of servers — had an automation backlog drowning in its own complexity. Every server generated alerts. Each alert needed a fix. Each fix required a developer to manually translate a PowerShell script into C# workflow code. The turnaround: four weeks per fix.
Meanwhile, the alert backlog was growing faster than the team could write code. With 3,500+ alert types and a customer base expanding rapidly, the math was brutal: a 24×7 incident-management team of human engineers was absorbing costs that scaled linearly with infrastructure — the most dangerous cost curve in software operations. The offshore team of 18 developers, despite their effort, was perpetually behind. The model was broken not because of the people but because of the architecture of the process itself.
The Portfolio Analog
This story maps precisely onto a category of OneX portfolio companies: SaaS businesses, infrastructure platforms, or marketplace products that have grown their customer base but not their operational automation. Their support-to-engineering ratio is wrong. Their on-call engineers are human alert-parsers, not product builders. Their ops spend scales with revenue instead of declining — the inverse of what a healthy software business looks like. The Greek concept of ἀρετή (arete) — excellence through the right application of one's nature — is instructive: these engineers are not poorly skilled, they are misapplied. Automation returns them to their highest use.
The Baseline: The Hidden Cost of Human-Mediated Operations
For a typical OneX portfolio company — a SaaS platform with 15 engineers, $80K MRR, and an ops-heavy incident model — here is the pre-automation baseline:
| Cost category | Monthly cost | Driver |
|---|---|---|
| Offshore/contract ops team (alert triage) | $45,000 | Manual resolution of known-fix alerts |
| Senior eng hours on incident escalations | $21,000 | ~25% of 3 senior eng @ $28K/mo each |
| Developer time translating fixes (backlog) | $18,000 | 4-week cycle per fix type, queue growing |
| Customer churn from SLA breaches (est.) | $16,000 | Delayed alert response → downtime → churn |
| Total pre-automation operational drag | $100,000/mo | 46% of total eng spend |
The Intervention: Two S+3 Automation Levers
Lever 1 — The scriptable automation engine
The insight was deceptively simple: stop translating scripts into code. Build an engine that executes scripts directly. The PowerShell script becomes the fix; the C# developer becomes unnecessary for known issues. Turnaround collapsed from four weeks to same-day, and the 24×7 team gained the ability to add and update fixes themselves through a self-service UI. For a portfolio company, this pattern applies to any repetitive, rule-based operational task: customer-data imports, provisioning workflows, billing reconciliation, environment resets, scheduled maintenance. The S+3 Scale pillar identifies and systematically automates these workflows as a first-order priority, not a nice-to-have.
Lever 2 — Horizontal Planning as a future-proofing tool
The monthly SME meetings scheduled to review recent fixes — initially seen as routine — became the origin of what S+3 calls Horizontal Planning: looking three sprints ahead and understanding the dependencies and co-implications of future work before the sprint begins. In the Office 365 case, this prevented new automated fixes from breaking old ones. In S+3 language it is the 4D Framework in action — Deliver, Design, Deliberate, Direction — a structured gate system that ensures no ambiguous work enters execution. Every hour of ambiguity eliminated in planning saves roughly 4–8 hours of rework in execution.
| Ambiguity detection stage | Cost to fix | S+3 gate |
|---|---|---|
| Direction (S+3): business alignment | $1 | Backlog locked, approved thrash prevented |
| Deliberation (S+2): architecture review | $4–8 | No major ambiguity passes this gate |
| Design (S+1): UX/product readiness | $16–32 | No ambiguity in next sprint |
| Delivery (S): sprint execution | $64–128 | Zero incomplete items |
| Post-deployment (production bug) | $256–512+ | The cost of NOT having gates |
Adapted from the classic cost-of-quality model used in Six Sigma, this is why Horizontal Planning is not process overhead — it is the highest-ROI investment an engineering organization can make.
The Results: 12-Month Recovery Model
Applying the automation engine and the Horizontal Planning gate to a 15-engineer SaaS portfolio company:
| Recovery stream | Monthly (steady state) | Annual |
|---|---|---|
| Offshore ops team elimination (post-automation) | $35,000 | $420,000 |
| Senior-eng incident-escalation reduction (70%) | $14,700 | $176,400 |
| Developer backlog-translation elimination | $18,000 | $216,000 |
| SLA improvement → churn reduction (est.) | $10,000 | $120,000 |
| Planning rework reduction via H-Planning gates | $8,500 | $102,000 |
| Total annual savings | $86,200/mo | $1,034,400 |
Key Performance Indicators: Before vs. After
| Metric | Before S+3 | After S+3 (12 mo) | Δ change |
|---|---|---|---|
| Alert-to-automation coverage | <20% | 90%+ | +350% |
| Fix turnaround (new alert type) | 4 weeks | Same day (self-service) | −93% |
| High-impact incidents per server (YoY) | Baseline | ↓ dramatically | Structural |
| Ops team headcount needed | 18 offshore + senior eng | Self-service + 2 oversight | −85% |
| Customer SLA-breach frequency | Baseline | Near-zero (known types) | −90%+ |
| Developer time on ops vs. product | ~30% on ops | <8% on ops | +280% product time |
| Cost per additional server (marginal) | Linear (human-dependent) | Near-zero (automated) | Non-linear |
Automate the toil engineers should never be doing in the first place, and four cents saved per seat, times millions of seats, stops being arithmetic — it becomes a business model.