Cto Advisor

CTO Advisor is a community skill for providing strategic technology leadership guidance, covering technology stack evaluation, engineering team scaling, technical debt management, architecture decision records, and build-versus-buy analysis for technology executives and engineering leaders.

What Is This?

Overview

CTO Advisor provides frameworks for making strategic technology decisions at the executive level. It covers technology stack evaluation that assesses languages, frameworks, and infrastructure choices against business requirements and team capabilities, engineering team scaling that plans hiring, organizational structure, and role definitions as the team grows, technical debt management that quantifies and prioritizes debt reduction alongside feature development, architecture decision records that document significant technical choices with context and trade-offs for future reference, and build-versus-buy analysis that compares custom development against vendor solutions with total cost of ownership projections. The skill enables technology leaders to make informed decisions that balance engineering excellence with business objectives.

Who Should Use This

This skill serves CTOs evaluating technology strategy for their organizations, VP of Engineering leaders scaling development teams, and technical founders making early architecture decisions that will affect long-term product development.

Why Use It?

Problems It Solves

Technology decisions made without structured evaluation lead to costly rewrites and migrations later. Scaling engineering teams without organizational planning creates communication overhead and delivery slowdowns. Technical debt accumulates silently when there is no framework for tracking and prioritizing its reduction. Build-versus-buy decisions made on incomplete cost analysis result in unexpected long-term expenses. Undocumented architecture decisions cause future teams to repeat past mistakes.

Core Highlights

Stack evaluator scores technology choices against weighted criteria including scalability, hiring pool, and maintenance cost. Team planner models organizational growth with role ratios and reporting structures. Debt tracker assigns business impact scores to technical debt items for prioritization. ADR generator creates structured decision records with context, options, and consequences.

How to Use It?

Basic Usage

from dataclasses\
  import dataclass

@dataclass
class StackCriteria:
  name: str
  weight: float
  score: int  # 1-10

class StackEvaluator:
  def __init__(self):
    self.options = {}

  def add_option(
    self,
    name: str,
    criteria:\
      list[StackCriteria]
  ):
    self.options[name]\
      = criteria

  def evaluate(
    self
  ) -> list[dict]:
    results = []
    for name, criteria\
        in self.options\
          .items():
      total = sum(
        c.weight * c.score
        for c in criteria)
      max_score = sum(
        c.weight * 10
        for c in criteria)
      results.append({
        'option': name,
        'score':
          round(total, 1),
        'percentage':
          round(total
            / max_score
            * 100, 1)})
    results.sort(
      key=lambda r:
        r['score'],
      reverse=True)
    return results

Real-World Examples

class BuildBuyAnalysis:
  def __init__(
    self,
    component: str,
    years: int = 3
  ):
    self.component =\
      component
    self.years = years
    self.build_costs = {}
    self.buy_costs = {}

  def set_build_costs(
    self,
    dev_months: int,
    monthly_rate: float,
    maintenance_pct:\
      float = 0.2
  ):
    initial = (dev_months
      * monthly_rate)
    annual_maint =\
      initial\
        * maintenance_pct
    self.build_costs = {
      'initial': initial,
      'annual_maint':
        annual_maint,
      'total': initial
        + annual_maint
        * self.years}

  def set_buy_costs(
    self,
    annual_license: float,
    integration_cost:\
      float,
    annual_support:\
      float = 0
  ):
    self.buy_costs = {
      'integration':
        integration_cost,
      'annual_total':
        annual_license
        + annual_support,
      'total':
        integration_cost
        + (annual_license
          + annual_support)
        * self.years}

  def recommend(
    self
  ) -> dict:
    build = self\
      .build_costs\
        .get('total', 0)
    buy = self\
      .buy_costs\
        .get('total', 0)
    return {
      'recommendation':
        'build' if
          build < buy
          else 'buy',
      'build_total':
        build,
      'buy_total': buy,
      'savings':
        abs(build - buy)}

Advanced Tips

Include opportunity cost in build-versus-buy analysis by estimating features the team could ship during the build period. Use Architecture Decision Records to capture decision context and consequences for future reference. Track technical debt with a scoring system that weights engineering impact and business risk.

When to Use It?

Use Cases

Evaluate competing technology stacks for a new product using weighted scoring against business criteria. Plan engineering team growth from a startup team to a multi-team organization with clear role definitions. Conduct a build-versus-buy analysis for a critical infrastructure component with total cost projection.

Related Topics

Technology leadership, architecture decisions, technical debt, engineering management, and build versus buy analysis.

Important Notes

Requirements

Understanding of the business domain and market context for technology decisions. Access to financial data for cost modeling in build-versus-buy analyses. Organizational context for team scaling including current headcount and budget constraints.

Usage Recommendations

Do: involve engineering leads in technology evaluation to capture practical implementation concerns. Document architecture decisions as ADRs when they are made rather than retrospectively. Revisit build-versus-buy decisions annually.

Don't: make technology choices based solely on technical merit without considering team expertise and hiring availability. Set technical debt reduction targets without connecting them to measurable business outcomes.

Limitations

Technology evaluation frameworks simplify trade-offs into numeric scores which may not capture qualitative factors like developer experience. Build-versus-buy cost projections rely on estimates that become less accurate over longer time horizons. Team scaling models assume predictable growth which may not hold during rapid market changes or funding shifts.