VP of Engineering Economics

Technical debt is the implied cost of future rework caused by choosing an expedient solution now instead of a better approach that would take longer. First coined by Ward Cunningham in 1992, technical debt has become one of the most important concepts in software engineering economics. Like financial debt, technical debt accrues interest. Every shortcut, every "we'll fix it later," every copy-pasted function adds to the principal. The interest comes in the form of slower development velocity, more bugs, longer onboarding times for new engineers, and increased fragility of the system. Technical debt exists on a spectrum from deliberate ("we know this is a shortcut but ship it anyway") to accidental ("we didn't realize this was a bad pattern until later"). Both types compound over time. Organizations that don't actively measure and manage their technical debt risk reaching what Richard Ewing calls the Technical Insolvency Date — the specific quarter when maintenance costs consume 100% of engineering capacity.

AI COGS (Cost of Goods Sold) refers to the variable costs directly attributable to delivering AI-powered features to customers. Unlike traditional SaaS (near-zero marginal cost per user), AI features have significant per-interaction costs. **Components of AI COGS:** - LLM API fees (OpenAI, Anthropic, Google per-token charges) - Embedding generation and vector database queries - GPU compute for inference or fine-tuning - Data retrieval and processing pipeline costs - Monitoring, logging, and observability infrastructure - Error handling, retry logic, and fallback model costs - Human-in-the-loop review costs **Impact on SaaS economics:** Traditional SaaS enjoys 80%+ gross margins. AI-heavy SaaS products can see margins compress to 40-60%, fundamentally changing valuation multiples and capital requirements.

The Innovation Tax is a framework coined by Richard Ewing that measures the hidden cost of maintenance work that gets reported as innovation investment. It is OpEx masquerading as R&D investment, causing organizations to dramatically overestimate their effective engineering velocity. When a team reports '65% of time on new features' but the actual number is 23%, the 42-point gap is the Innovation Tax. This gap causes CFOs and boards to overestimate R&D productivity and make poor capital allocation decisions. The Innovation Tax is insidious because it's invisible in standard reporting. Engineering teams don't intentionally misreport — the maintenance work is scattered across feature work, making it hard to isolate. Bug fixes get bundled into feature sprints. Infrastructure upgrades get coded as feature dependencies. Benchmark: >40% Innovation Tax is dangerous. >70% is terminal — the organization is approaching the Technical Insolvency Date.

The Technical Insolvency Date (TID) is a framework coined by Richard Ewing that identifies the specific future quarter when an organization's technical debt maintenance will consume 100% of engineering capacity, leaving zero time for new feature development. The TID is calculated by projecting the current maintenance percentage growth against available engineering hours. If a team currently spends 45% of time on maintenance and that percentage grows 3% per quarter, the Technical Insolvency Date can be calculated as the quarter when maintenance reaches 100%. Most organizations track technical debt qualitatively. The TID makes it quantitative and urgent. Telling a board 'we have technical debt' gets ignored. Telling a board 'we are 8 quarters from technical insolvency' gets immediate action. The Product Debt Index (PDI) calculator at richardewing.io/tools/pdi automates this calculation, translating maintenance burden into dollar terms and projecting the Technical Insolvency Date.

APER measures revenue generated per engineer, annualized. It is Richard Ewing's recommended alternative to velocity metrics like story points, which measure effort rather than value. APER = Annual Recurring Revenue ÷ Total Engineering Headcount Benchmarks: early-stage startups typically have APER of $100-200K. Growth-stage companies target $200-400K. Mature SaaS companies achieve $400-800K. The best-in-class (Canva, Zoom at peak) exceed $1M per engineer. APER trends are more important than absolute values. Increasing APER means engineering is becoming more efficient. Declining APER means each new hire produces diminishing returns — a sign of organizational complexity, technical debt, or poor product-market fit. APER should be segmented: product engineering vs. platform engineering vs. infrastructure. Product engineering should have the highest APER because they directly build revenue-generating features.

DORA metrics are four key software delivery performance metrics identified by the DevOps Research and Assessment (DORA) team at Google. They are the industry standard for measuring engineering team effectiveness: 1. **Deployment Frequency**: How often code is deployed to production. Elite teams deploy on-demand, multiple times per day. 2. **Lead Time for Changes**: Time from code commit to production deployment. Elite teams achieve less than one hour. 3. **Change Failure Rate**: Percentage of deployments that cause failures requiring remediation. Elite teams maintain 0-15%. 4. **Mean Time to Recovery (MTTR)**: How quickly a team can restore service after an incident. Elite teams recover in less than one hour. These metrics are backed by years of research across thousands of organizations worldwide and are validated as predictors of both software delivery performance and organizational performance.