Technical Decision Translation

My engineering team has given me a technical decision to make. I need help understanding the business implications.

THEIR PROPOSAL:
${technicalProposal}

THE OPTIONS THEY'VE PRESENTED:
${options}

Translate this into terms a non-technical CEO/product leader can evaluate:

1. **PLAIN ENGLISH EXPLANATION**
What is each option actually doing? Explain it like I'm a smart businessperson, not an engineer. Use analogies if they help.

2. **BUSINESS IMPACT COMPARISON**
| Factor | Option A | Option B | ${optionC ? 'Option C' : ''} |
- Upfront cost (time + money)
- Ongoing cost
- Impact on users (will they notice anything?)
- Impact on team velocity (will this slow down feature development?)
- Scale ceiling (when do we outgrow this solution?)
- Risk if it fails

3. **WHAT QUESTIONS SHOULD I ASK?**
5 questions I should ask my engineering lead to make a better decision. These should reveal information that changes the calculus.

4. **HIDDEN ASSUMPTIONS**
What assumptions is each option making about our growth, traffic, team size, or product direction? If those assumptions are wrong, which option breaks worse?

5. **MY RECOMMENDATION IF I WERE YOUR FRACTIONAL CTO**
One paragraph: what I'd recommend and why, with the main risk clearly stated.

My engineering team wants to make this architecture change:

${architectureChange}

Their reasoning: ${reasoning}

Timeline: ${timeline}
Cost: ${cost}

Help me evaluate this as a business decision:

1. **WHAT THIS ACTUALLY MEANS**
Plain English: what changes for us operationally? What changes for our customers?

2. **THE REAL QUESTION**
What's the actual business problem they're solving? Is this the right time to solve it? What triggers would tell us we MUST do this vs SHOULD do this vs COULD do this?

3. **OPPORTUNITY COST**
What are these engineers NOT building during this time? List the features or improvements that get delayed.

4. **INCREMENTAL ALTERNATIVE**
Is there a smaller version of this change that gets 80% of the benefit at 20% of the cost? (Engineers sometimes propose the "right" solution when the "good enough" solution is what the business needs right now.)

5. **RISK ASSESSMENT**
- What happens if we do this and it doesn't work?
- What happens if we don't do this? When does it become urgent?
- Can we reverse this decision if it's wrong?

6. **DECISION FRAMEWORK**
At what scale/revenue/traffic level does this become critical? Are we there now, or are we building for a future that may not arrive?

Engineering recommends we switch from ${currentTool} to ${proposedTool}.

Their reasoning:
${reasoning}

Translate this for a business evaluation:

1. **WHAT DOES THIS CHANGE FOR THE BUSINESS?**
- Will customers notice? (performance, features, reliability)
- Will the team be more productive?
- Does this lock us into a vendor?

2. **TOTAL COST OF OWNERSHIP**
| Cost Category | Current (${currentTool}) | Proposed (${proposedTool}) |
- License/subscription cost
- Migration cost (engineering time)
- Training/ramp-up time
- Ongoing maintenance
- Risk of migration issues

3. **VENDOR LOCK-IN ASSESSMENT**
How hard is it to switch away from ${proposedTool} later? What data or configurations become vendor-specific? Is there an open-source alternative that avoids lock-in?

4. **TIMING**
Is this urgent (current tool is failing) or strategic (better tool for the future)? What's the cost of waiting 6 months?

5. **WHAT I'D ASK**
Questions for the engineering team before approving:
- Have you evaluated alternatives beyond ${proposedTool}?
- Can we run both in parallel during migration?
- What's the rollback plan if ${proposedTool} doesn't work out?
- Is there a smaller proof-of-concept we can run first?

My engineering team wants to dedicate ${allocation} of their time to technical debt for the next ${period}.

Their justification: ${justification}

Current team size: ${teamSize} engineers
Current velocity: ${velocity}

Help me evaluate this:

1. **WHAT IS TECHNICAL DEBT IN BUSINESS TERMS?**
Translate their specific technical debt items into business impact. For each item:
| Debt Item | Business Impact If Ignored | Business Impact If Fixed | Risk of Ignoring |

2. **VELOCITY MATH**
If we allocate ${allocation} to debt, we lose X feature-weeks per quarter. Is the expected velocity improvement after debt reduction worth it?

3. **PRIORITIZATION FRAMEWORK**
Not all technical debt is equal. Help me categorize their items:
- **Fix now** — Actively causing customer-facing issues or slowing the team significantly
- **Fix soon** — Will become urgent within 3-6 months at current growth
- **Fix eventually** — Real debt but not impacting anyone right now
- **Don't fix** — Debt that's tolerable forever or will be replaced before it matters

4. **ALTERNATIVE APPROACHES**
Instead of a blanket allocation, should we:
- Dedicate one sprint to debt every 6 weeks?
- Fix debt in the area we're already working on (boy scout rule)?
- Have one engineer on debt rotation while others ship features?

5. **THE BUSINESS QUESTION**
What would you want to see in 90 days to know this investment was worth it? Define success criteria that aren't just "cleaner code" but actual business outcomes.

Here's my engineering team's weekly update. Translate it for a non-technical audience:

${engineeringUpdate}

Produce:

1. **EXECUTIVE SUMMARY** (3 bullets)
What the team accomplished this week in business terms. "Reduced page load time by 40%" not "Optimized database indexes."

2. **PROGRESS AGAINST GOALS**
Map the work against our quarterly goals:
| Goal | Progress This Week | On Track? |

3. **RISKS OR BLOCKERS** (in business terms)
Any technical issues that could impact timelines, features, or customers. What should I know about?

4. **NEXT WEEK PREVIEW**
What's coming that I should be aware of — especially anything customer-facing or deadline-sensitive.

Keep the total output under 200 words. I don't need to understand the technical details, just the business implications.