CTO Advisor
Build vs Buy Decision Framework
Decision Matrix
## Build vs Buy Analysis: [Feature/System Name]
### Scoring (1-5 each)
| Factor | Build | Buy | Weight |
|--------|-------|-----|--------|
| Core competency alignment | [1-5] | [1-5] | 3x |
| Time to market | [1-5] | [1-5] | 2x |
| Total cost (3 year) | [1-5] | [1-5] | 2x |
| Customization needs | [1-5] | [1-5] | 2x |
| Maintenance burden | [1-5] | [1-5] | 1x |
| Data control | [1-5] | [1-5] | 1x |
| Integration complexity | [1-5] | [1-5] | 1x |
| Vendor risk | [1-5] | [1-5] | 1x |
| **Weighted Total** | [sum] | [sum] | |
### Decision: BUILD / BUY / HYBRID
Decision Rules
| Condition |
Recommendation |
| Core differentiator |
BUILD (competitive advantage) |
| Commodity capability |
BUY (focus on core) |
| Strict compliance / data sovereignty |
BUILD (control) |
| Team has no domain expertise |
BUY (faster, less risk) |
| Vendor lock-in risk > 7/10 |
BUILD or multi-vendor |
| Time to market < 3 months |
BUY (speed) |
| Budget constrained, long-term |
BUILD (lower TCO) |
Build vs Buy Anti-Patterns
| Anti-Pattern |
Neden Yanlis |
Dogru Yol |
| "Not invented here" |
Wasted engineering time |
Evaluate vendors objectively |
| "We'll build it in 2 weeks" |
Always takes 5x longer |
Realistic estimation with buffer |
| Buying everything |
No differentiation |
Build core, buy commodity |
| Ignoring maintenance cost |
Build looks cheaper initially |
Include 3-5 year maintenance TCO |
| No exit strategy from vendor |
Lock-in trap |
Evaluate migration cost upfront |
Tech Debt Quantification & Prioritization
Tech Debt Classification
| Type |
Description |
Impact |
Example |
| Code debt |
Poor code quality |
Developer velocity |
No types, huge functions, no tests |
| Architecture debt |
Wrong architectural decisions |
Scalability |
Monolith that should be microservice |
| Test debt |
Insufficient test coverage |
Reliability |
No integration tests, flaky tests |
| Dependency debt |
Outdated dependencies |
Security |
3 major versions behind, CVEs |
| Documentation debt |
Missing/outdated docs |
Onboarding |
No API docs, stale README |
| Infrastructure debt |
Manual processes, legacy infra |
Reliability |
No CI/CD, manual deployments |
| Design debt |
UX inconsistencies |
User experience |
5 different button styles |
Tech Debt Scorecard
## Tech Debt Assessment: [Project Name]
| Area | Score (1-10) | Trend | Priority |
|------|-------------|-------|----------|
| Code quality | [X] | [up/down/flat] | [H/M/L] |
| Test coverage | [X%] | [up/down/flat] | [H/M/L] |
| Dependency freshness | [X] | [up/down/flat] | [H/M/L] |
| Build/deploy time | [X min] | [up/down/flat] | [H/M/L] |
| Documentation | [X] | [up/down/flat] | [H/M/L] |
| Security posture | [X] | [up/down/flat] | [H/M/L] |
### Cost of Delay
[If we don't address debt area X, what happens in 6 months?]
### Investment Request
| Initiative | Effort | Impact | ROI Period |
|-----------|--------|--------|------------|
| [debt 1] | [weeks] | [description] | [months] |
| [debt 2] | [weeks] | [description] | [months] |
Prioritization Formula
Priority Score = (Impact * Urgency * Spread) / Effort
Impact (1-5): How much does it slow the team?
Urgency (1-5): How quickly will it get worse?
Spread (1-5): How many areas does it affect?
Effort (1-5): How hard is it to fix? (inverse: 1=hard, 5=easy)
Tech Debt Budget Rule
RULE: 20% of sprint capacity reserved for tech debt reduction
Sprint capacity: 10 story points
├── 8 points: Feature work
└── 2 points: Tech debt reduction (ZORUNLU, negotiable degil)
Team Scaling Strategies
Hiring Framework
## Hiring Plan: [Quarter/Year]
### Current State
| Role | Headcount | Capacity | Gap |
|------|-----------|----------|-----|
| Backend | [X] | [Y features/quarter] | [shortfall] |
| Frontend | [X] | [Y features/quarter] | [shortfall] |
| DevOps | [X] | [Y deploys/week] | [shortfall] |
| QA | [X] | [Y tests/sprint] | [shortfall] |
### Ratios
- Engineer : Manager = 6-8 : 1
- Senior : Mid : Junior = 2 : 3 : 1
- Backend : Frontend = project-dependent
- Engineer : QA = 4-6 : 1
### Onboarding Milestones
| Day | Milestone |
|-----|-----------|
| 1 | Dev environment running, first commit |
| 7 | First PR merged |
| 14 | First feature shipped to staging |
| 30 | Independent task completion |
| 60 | Contributing to architecture discussions |
| 90 | Fully productive, mentoring others |
Team Topology Patterns
| Pattern |
When to Use |
Size |
| Stream-aligned |
Product features |
5-8 people |
| Platform |
Internal tooling, infrastructure |
3-5 people |
| Enabling |
Coach other teams, remove blockers |
2-3 people |
| Complicated subsystem |
Deep expertise (ML, security) |
2-4 people |
Architecture Decision Records (ADR)
ADR Template
# ADR-[number]: [decision title]
## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
## Context
[What is the issue? What forces are at play?]
[Include constraints, requirements, team capabilities]
## Decision
[What is the change that we're proposing and/or doing?]
## Alternatives Considered
### Option A: [name]
- Pros: [list]
- Cons: [list]
### Option B: [name]
- Pros: [list]
- Cons: [list]
## Consequences
### Positive
- [benefit 1]
- [benefit 2]
### Negative
- [tradeoff 1]
- [tradeoff 2]
### Risks
- [risk 1]: [mitigation]
- [risk 2]: [mitigation]
## Decision Date
[YYYY-MM-DD]
## Decision Makers
[names/roles]
ADR Index
## Architecture Decision Log
| # | Decision | Status | Date | Impact |
|---|---------|--------|------|--------|
| 001 | Use PostgreSQL over MongoDB | Accepted | 2025-01-15 | High |
| 002 | Adopt microservices for billing | Accepted | 2025-02-01 | High |
| 003 | Use React over Vue | Accepted | 2025-02-15 | Medium |
| 004 | Monolith-first for MVP | Deprecated | 2025-03-01 | High |
Technology Evaluation Framework
RICE Scoring
## Technology Evaluation: [Technology Name]
### RICE Score
| Factor | Score | Weight | Weighted |
|--------|-------|--------|----------|
| **Reach** (how many people/teams affected) | [1-10] | 1x | [X] |
| **Impact** (how much improvement per person) | [1-3: minimal/medium/massive] | 2x | [X] |
| **Confidence** (how sure are we) | [50-100%] | 1x | [X] |
| **Effort** (person-months) | [X] | divisor | [X] |
**RICE Score = (Reach * Impact * Confidence) / Effort = [score]**
Weighted Scoring Matrix
## Vendor/Technology Comparison
| Criteria | Weight | Option A | Option B | Option C |
|----------|--------|----------|----------|----------|
| Performance | 20% | [1-5] | [1-5] | [1-5] |
| Community/support | 15% | [1-5] | [1-5] | [1-5] |
| Learning curve | 15% | [1-5] | [1-5] | [1-5] |
| Cost | 15% | [1-5] | [1-5] | [1-5] |
| Scalability | 10% | [1-5] | [1-5] | [1-5] |
| Security | 10% | [1-5] | [1-5] | [1-5] |
| Integration | 10% | [1-5] | [1-5] | [1-5] |
| Maturity | 5% | [1-5] | [1-5] | [1-5] |
| **Weighted Total** | | [sum] | [sum] | [sum] |
### Recommendation: [Option X]
### Reasoning: [1-2 sentences]
Technology Evaluation Anti-Patterns
| Anti-Pattern |
Risk |
Dogru Yol |
| Resume-driven development |
Wrong tool for the job |
Evaluate against actual needs |
| Hype-driven adoption |
Immature ecosystem |
Wait for version 2.0+ |
| Single vendor evaluation |
No comparison baseline |
Always evaluate 3+ options |
| Ignoring exit cost |
Future lock-in |
Calculate migration cost |
| No POC/prototype |
Unknown unknowns |
Build spike before committing |
Budget Planning & TCO Analysis
TCO Template (3-Year)
## Total Cost of Ownership: [System/Technology]
### Year 1 (Setup + Operations)
| Category | Cost |
|----------|------|
| Licenses/subscriptions | $[X] |
| Infrastructure (cloud/hardware) | $[X] |
| Implementation/migration | $[X] |
| Training | $[X] |
| Integration development | $[X] |
| **Year 1 Total** | **$[X]** |
### Year 2-3 (Ongoing)
| Category | Annual Cost |
|----------|------------|
| Licenses/subscriptions (+ annual increase) | $[X] |
| Infrastructure | $[X] |
| Maintenance engineering (FTE fraction) | $[X] |
| Support contracts | $[X] |
| Upgrades/patches | $[X] |
| **Annual Ongoing** | **$[X]** |
### 3-Year TCO: $[Year 1 + Year 2 + Year 3]
### Hidden Costs (often missed)
- Context switching overhead
- On-call/incident response time
- Documentation maintenance
- Vendor management overhead
- Compliance/audit costs
Vendor Management
Vendor Assessment Checklist
Vendor Risk Matrix
| Risk |
Likelihood |
Impact |
Mitigation |
| Vendor acquired/shutdown |
Low |
Critical |
Data export procedure, backup vendor |
| Price increase > 30% |
Medium |
High |
Multi-year contract, alternative evaluation |
| SLA breach |
Medium |
High |
Credits, contractual remedies |
| Data breach at vendor |
Low |
Critical |
Encryption, contractual liability |
| Feature deprecation |
Medium |
Medium |
API abstraction layer |
Engineering Metrics
DORA Metrics
| Metric |
Elite |
High |
Medium |
Low |
| Deployment Frequency |
On-demand (multiple/day) |
Daily-weekly |
Weekly-monthly |
Monthly-6monthly |
| Lead Time for Changes |
< 1 hour |
1 day - 1 week |
1 week - 1 month |
1 - 6 months |
| Change Failure Rate |
0-15% |
16-30% |
16-30% |
16-30% |
| Mean Time to Recovery |
< 1 hour |
< 1 day |
1 day - 1 week |
> 1 week |
SPACE Framework
| Dimension |
Metrics |
How to Measure |
| Satisfaction |
Developer satisfaction survey |
Quarterly survey (1-5 scale) |
| Performance |
Code review turnaround, incident resolution |
Tooling metrics |
| Activity |
PRs merged, deploys, commits |
Git/CI data (NOT for evaluation) |
| Communication |
Knowledge sharing, documentation |
Survey + doc metrics |
| Efficiency |
Dev environment setup time, build time |
Measure and track |
Engineering Health Dashboard
## Engineering Health: [Quarter]
### DORA Metrics
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Deploy frequency | Daily | [X/week] | [on/off track] |
| Lead time | < 1 day | [X hours] | [on/off track] |
| Change failure rate | < 15% | [X%] | [on/off track] |
| MTTR | < 1 hour | [X min] | [on/off track] |
### Team Health
| Area | Score (1-10) | Trend |
|------|-------------|-------|
| Developer satisfaction | [X] | [up/down/flat] |
| On-call burden | [X] | [up/down/flat] |
| Tech debt sentiment | [X] | [up/down/flat] |
| Tooling satisfaction | [X] | [up/down/flat] |
### Actionable Insights
1. [Insight + recommended action]
2. [Insight + recommended action]
Board/Investor Technical Reporting
Quarterly Tech Report Template
## Technology Report: Q[X] [Year]
### Executive Summary
[2-3 sentences: key wins, risks, requests]
### Key Metrics
| Metric | Q-1 | Q0 | Target | Trend |
|--------|-----|-----|--------|-------|
| Uptime | [X%] | [X%] | 99.9% | [arrow] |
| Page load time | [Xs] | [Xs] | < 2s | [arrow] |
| Active users | [X] | [X] | [target] | [arrow] |
| Deploy frequency | [X/mo] | [X/mo] | Daily | [arrow] |
### Achievements
1. [Milestone/launch/improvement]
2. [Milestone/launch/improvement]
### Risks & Challenges
| Risk | Severity | Mitigation | Status |
|------|----------|-----------|--------|
| [risk] | [H/M/L] | [plan] | [active/mitigated] |
### Budget
| Category | Budget | Actual | Variance |
|----------|--------|--------|----------|
| Infrastructure | $[X] | $[X] | [+/-X%] |
| Licenses | $[X] | $[X] | [+/-X%] |
| Headcount | $[X] | $[X] | [+/-X%] |
### Next Quarter Focus
1. [Priority 1]
2. [Priority 2]
3. [Priority 3]
### Resource Request
[If applicable: what do we need and why]
Board Communication Anti-Patterns
| Anti-Pattern |
Neden Yanlis |
Dogru Yol |
| Too much jargon |
Board members aren't engineers |
Translate to business impact |
| Only good news |
Erodes trust |
Honest + solution-oriented |
| No metrics |
Unverifiable |
Data-driven with trends |
| Feature list only |
No business context |
Connect features to revenue/growth |
| Asking for budget without ROI |
Unlikely approval |
Show expected return |