<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Topics on CTO Field Notes</title>
    <link>https://avivzaken.com/topics/</link>
    <description>Browse CTO Field Notes by topic: engineering leadership, AI-assisted engineering, software delivery, and technical risk.</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 11 Sep 2026 00:00:00 +0000</lastBuildDate>
    <atom:link href="https://avivzaken.com/topics/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Technical Risk</title>
      <link>https://avivzaken.com/topics/technical-risk/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0000</pubDate>
      <guid isPermaLink="true">https://avivzaken.com/topics/technical-risk/</guid>
      <dc:creator>Aviv Zaken</dc:creator>
      <description>Field notes on technical risk: code review, software quality, technical debt, refactoring, and the cost of being wrong.</description>
      <content:encoded><![CDATA[<p>Technical risk is shaped by the cost of being wrong and the difficulty of recovery. These field notes connect code review, software quality, technical debt, and refactoring to the same operating concern: whether a team can change a system with enough evidence, understanding, and reversibility to trust the outcome.</p>
<p>Not every change deserves the same control. Review depth should follow consequence. Debt is useful when its cost and repayment path are understood. Tests and evals should prove the behavior that matters, not merely produce a green check.</p>
<h2 id="technical-risk-field-notes">Technical Risk Field Notes<a class="anchor" href="#technical-risk-field-notes">#</a></h2>
<div class="latest-articles field-note-list" aria-label="Technical risk field notes">
  <article class="article-row">
    <time class="article-date" datetime="2026-09-09">2026-09-09</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/the-reviewer-still-owns-the-merge/">Code Review Is Risk Management</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/technical-risk/">Code Review</a></li><li><a href="/topics/technical-risk/">Software Risk</a></li>
</ul>

      <p class="article-description">Code review should not treat every pull request equally. Review depth should follow the cost of being wrong, and the reviewer still owns that decision.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-05-24">2026-05-24</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/evals-are-the-new-tests/">Evals Are the New Tests</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/technical-risk/">Software Quality</a></li>
</ul>

      <p class="article-description">In April 2025 OpenAI shipped a model update whose offline evals and A/B tests all looked good. It was sycophantic enough to roll back within days. A practical guide to building the measurement layer that would have caught it - with a working eval spec and grading rubric.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-04-26">2026-04-26</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/code-was-never-the-bottleneck/">Code Was Never the Bottleneck</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/technical-risk/">Code Review</a></li>
</ul>

      <p class="article-description">Your engineers are producing more code and your delivery cadence has barely moved. The waiting did not disappear - it moved downstream to review and absorption, and that is where the constraint always was. Includes a review-capacity audit.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-01-03">2026-01-03</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/technical-debt-is-a-tool/">Technical Debt Is a Tool</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/technical-risk/">Technical Debt</a></li><li><a href="/topics/engineering-leadership/">Engineering Leadership</a></li>
</ul>

      <p class="article-description">Technical debt isn&#39;t the main problem-loss of trust is; continuous, small refactors keep teams confident and fast.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-01-01">2026-01-01</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/refactoring-to-move-fast/">Refactoring Is How You Keep Moving Fast</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/technical-risk/">Technical Debt</a></li><li><a href="/topics/software-delivery/">Software Delivery</a></li>
</ul>

      <p class="article-description">How continuous refactoring prevents engineering slowdowns and keeps the cost of change flat over time. Refactoring isn&#39;t a cleanup phase—it&#39;s the mechanism that preserves feature velocity.</p>
    </div>
  </article>
</div>

<h2 id="explore-related-topics">Explore Related Topics<a class="anchor" href="#explore-related-topics">#</a></h2>
<nav class="topic-hub-links" aria-label="Browse field notes by topic">
  <ul>
    <li>
      <a href="/topics/engineering-leadership/">Engineering Leadership</a> — Team design, technical strategy, metrics, and organizational judgment.
    </li>
    <li>
      <a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a> — Review capacity, evals, useful metrics, and AI-era team design.
    </li>
    <li>
      <a href="/topics/software-delivery/">Software Delivery</a> — Roadmaps, small bets, product engineering, and reliable delivery.
    </li>
    <li>
      <strong aria-current="page">Technical Risk</strong> — Code review, software quality, technical debt, and recovery.
    </li>
  </ul>
</nav>

]]></content:encoded>
    </item>
    <item>
      <title>Software Delivery</title>
      <link>https://avivzaken.com/topics/software-delivery/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0000</pubDate>
      <guid isPermaLink="true">https://avivzaken.com/topics/software-delivery/</guid>
      <dc:creator>Aviv Zaken</dc:creator>
      <description>Practical field notes on software delivery, product strategy, startup engineering, and shipping reliably under uncertainty.</description>
      <content:encoded><![CDATA[<p>Reliable delivery is not raw output. It is the ability to turn uncertain work into small, testable, reversible increments while keeping the team close to real feedback. These field notes cover roadmaps as trade-offs, experiments as learning systems, feature design, refactoring, and the operating practices that let startups keep shipping without losing control of their velocity.</p>
<p>The shared theme is reducing the cost of learning. Smaller bets expose wrong assumptions earlier. Clear measures separate motion from progress. Continuous refactoring keeps future changes affordable.</p>
<h2 id="software-delivery-field-notes">Software Delivery Field Notes<a class="anchor" href="#software-delivery-field-notes">#</a></h2>
<div class="latest-articles field-note-list" aria-label="Software delivery field notes">
  <article class="article-row">
    <time class="article-date" datetime="2026-03-15">2026-03-15</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/roadmap-problem-no-one-admits/">The Roadmap Problem No One Admits</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Product Strategy</a></li><li><a href="/topics/software-delivery/">Software Delivery</a></li>
</ul>

      <p class="article-description">Most teams confuse motion with delivery. The roadmap isn&#39;t a list of things you want to do - it&#39;s a list of trade-offs you&#39;re willing to commit to finishing.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-02-25">2026-02-25</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/predictable-delivery-in-an-unpredictable-world/">Predictable Delivery in an Unpredictable World</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Software Delivery</a></li><li><a href="/topics/engineering-leadership/">Engineering Leadership</a></li>
</ul>

      <p class="article-description">Startups don’t fail because they move slowly. They fail because they lose control of their velocity.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-02-15">2026-02-15</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/derisking-big-bets-without-killing-innovation/">De-Risking Big Bets Without Killing Innovation</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Product Strategy</a></li><li><a href="/topics/software-delivery/">Software Delivery</a></li>
</ul>

      <p class="article-description">De-risking innovation isn&#39;t about avoiding failure - it&#39;s about learning faster through small bets, clear metrics, and structured experiments that keep creativity alive.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-01-25">2026-01-25</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/velocity-is-the-product/">Velocity Is the Product</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Software Delivery</a></li><li><a href="/topics/engineering-leadership/">Engineering Leadership</a></li>
</ul>

      <p class="article-description">Velocity is the product, not the metric. It&#39;s the rate at which you learn and ship features. It&#39;s the rate at which you can make changes to the system without breaking it.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-01-06">2026-01-06</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/shipping-in-uncertainty-sdlc/">Shipping in Uncertainty: Field Notes on Startup SDLC</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Software Delivery</a></li><li><a href="/topics/software-delivery/">Startup Engineering</a></li>
</ul>

      <p class="article-description">A candid take on how startups ship software while everything is still unclear - why process is a bet, feedback is truth, and confidence is built, not assumed.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-01-01">2026-01-01</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/refactoring-to-move-fast/">Refactoring Is How You Keep Moving Fast</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/technical-risk/">Technical Debt</a></li><li><a href="/topics/software-delivery/">Software Delivery</a></li>
</ul>

      <p class="article-description">How continuous refactoring prevents engineering slowdowns and keeps the cost of change flat over time. Refactoring isn&#39;t a cleanup phase—it&#39;s the mechanism that preserves feature velocity.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2025-12-27">2025-12-27</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/4-musts-of-feature-dev/">4 Musts of Building a New Feature</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Software Delivery</a></li><li><a href="/topics/software-delivery/">Product Engineering</a></li>
</ul>

      <p class="article-description">Four critical principles for successful feature development: evaluating effort vs. risk, breaking features into deployable parts, failing fast on purpose, and defining measurable KPIs. A CTO&#39;s guide to reducing waste and shipping what matters.</p>
    </div>
  </article>
</div>

<h2 id="explore-related-topics">Explore Related Topics<a class="anchor" href="#explore-related-topics">#</a></h2>
<nav class="topic-hub-links" aria-label="Browse field notes by topic">
  <ul>
    <li>
      <a href="/topics/engineering-leadership/">Engineering Leadership</a> — Team design, technical strategy, metrics, and organizational judgment.
    </li>
    <li>
      <a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a> — Review capacity, evals, useful metrics, and AI-era team design.
    </li>
    <li>
      <strong aria-current="page">Software Delivery</strong> — Roadmaps, small bets, product engineering, and reliable delivery.
    </li>
    <li>
      <a href="/topics/technical-risk/">Technical Risk</a> — Code review, software quality, technical debt, and recovery.
    </li>
  </ul>
</nav>

]]></content:encoded>
    </item>
    <item>
      <title>Engineering Leadership</title>
      <link>https://avivzaken.com/topics/engineering-leadership/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0000</pubDate>
      <guid isPermaLink="true">https://avivzaken.com/topics/engineering-leadership/</guid>
      <dc:creator>Aviv Zaken</dc:creator>
      <description>Practical field notes on engineering leadership, team design, technical strategy, engineering metrics, and resilient delivery.</description>
      <content:encoded><![CDATA[<p>Engineering leadership is the work of turning uncertainty into decisions a team can execute and own. These field notes examine how leaders design teams, choose useful signals, protect delivery, and decide where human judgment matters as AI changes the economics of producing code.</p>
<p>They address practical questions: How should a CTO measure whether AI improved delivery rather than output volume? How can a senior-dense team keep developing future engineers? Which weak signals deserve action before friction becomes an incident? How should leaders preserve predictability when the roadmap and the system are both changing?</p>
<h2 id="engineering-leadership-field-notes">Engineering Leadership Field Notes<a class="anchor" href="#engineering-leadership-field-notes">#</a></h2>
<div class="latest-articles field-note-list" aria-label="Engineering leadership field notes">
  <article class="article-row">
    <time class="article-date" datetime="2026-07-19">2026-07-19</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/the-team-shape-is-changing/">How AI Is Changing Engineering Team Structure</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/engineering-leadership/">Team Design</a></li>
</ul>

      <p class="article-description">Teams are getting smaller and more senior while the pipeline that produces seniors is being cut. What is actually established, what is forecast, what would prove me wrong - plus an AI-era hiring rubric and the real cost of a junior residency.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-06-21">2026-06-21</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/engineering-metrics-in-the-age-of-ai/">Engineering Metrics in the Age of AI</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/engineering-leadership/">Engineering Metrics</a></li>
</ul>

      <p class="article-description">Your board will ask whether AI made engineering more productive. Most available numbers answer a different question. A taxonomy separating diagnostic signals from performance measures, a paired scorecard, and the sentence to actually say in the meeting.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-04-05">2026-04-05</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/staying-one-step-ahead/">Staying One Step Ahead</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/engineering-leadership/">Engineering Leadership</a></li><li><a href="/topics/engineering-leadership/">Technical Strategy</a></li>
</ul>

      <p class="article-description">The CTO’s job is not to see the future. It is to reduce surprise by building systems that detect weak signals early, convert ambiguity into decisions, and act before friction compounds.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-02-25">2026-02-25</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/predictable-delivery-in-an-unpredictable-world/">Predictable Delivery in an Unpredictable World</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Software Delivery</a></li><li><a href="/topics/engineering-leadership/">Engineering Leadership</a></li>
</ul>

      <p class="article-description">Startups don’t fail because they move slowly. They fail because they lose control of their velocity.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-01-25">2026-01-25</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/velocity-is-the-product/">Velocity Is the Product</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/software-delivery/">Software Delivery</a></li><li><a href="/topics/engineering-leadership/">Engineering Leadership</a></li>
</ul>

      <p class="article-description">Velocity is the product, not the metric. It&#39;s the rate at which you learn and ship features. It&#39;s the rate at which you can make changes to the system without breaking it.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-01-03">2026-01-03</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/technical-debt-is-a-tool/">Technical Debt Is a Tool</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/technical-risk/">Technical Debt</a></li><li><a href="/topics/engineering-leadership/">Engineering Leadership</a></li>
</ul>

      <p class="article-description">Technical debt isn&#39;t the main problem-loss of trust is; continuous, small refactors keep teams confident and fast.</p>
    </div>
  </article>
</div>

<h2 id="explore-related-topics">Explore Related Topics<a class="anchor" href="#explore-related-topics">#</a></h2>
<nav class="topic-hub-links" aria-label="Browse field notes by topic">
  <ul>
    <li>
      <strong aria-current="page">Engineering Leadership</strong> — Team design, technical strategy, metrics, and organizational judgment.
    </li>
    <li>
      <a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a> — Review capacity, evals, useful metrics, and AI-era team design.
    </li>
    <li>
      <a href="/topics/software-delivery/">Software Delivery</a> — Roadmaps, small bets, product engineering, and reliable delivery.
    </li>
    <li>
      <a href="/topics/technical-risk/">Technical Risk</a> — Code review, software quality, technical debt, and recovery.
    </li>
  </ul>
</nav>

]]></content:encoded>
    </item>
    <item>
      <title>AI-Assisted Engineering</title>
      <link>https://avivzaken.com/topics/ai-assisted-engineering/</link>
      <pubDate>Fri, 11 Sep 2026 00:00:00 +0000</pubDate>
      <guid isPermaLink="true">https://avivzaken.com/topics/ai-assisted-engineering/</guid>
      <dc:creator>Aviv Zaken</dc:creator>
      <description>Field notes on AI-assisted software engineering, including review capacity, evals, engineering metrics, and team design.</description>
      <content:encoded><![CDATA[<p>AI-assisted engineering makes code faster to produce, but it does not remove responsibility for what reaches production. These field notes focus on the work that becomes more important when implementation gets cheaper: reviewing generated changes, evaluating probabilistic behavior, measuring outcomes rather than activity, and maintaining enough system knowledge to own the result.</p>
<p>The recurring question is not whether engineers should use AI. It is how an organization can gain speed without moving the bottleneck—and the risk—into review, integration, or production.</p>
<h2 id="ai-assisted-engineering-field-notes">AI-Assisted Engineering Field Notes<a class="anchor" href="#ai-assisted-engineering-field-notes">#</a></h2>
<div class="latest-articles field-note-list" aria-label="AI-assisted engineering field notes">
  <article class="article-row">
    <time class="article-date" datetime="2026-07-19">2026-07-19</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/the-team-shape-is-changing/">How AI Is Changing Engineering Team Structure</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/engineering-leadership/">Team Design</a></li>
</ul>

      <p class="article-description">Teams are getting smaller and more senior while the pipeline that produces seniors is being cut. What is actually established, what is forecast, what would prove me wrong - plus an AI-era hiring rubric and the real cost of a junior residency.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-06-21">2026-06-21</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/engineering-metrics-in-the-age-of-ai/">Engineering Metrics in the Age of AI</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/engineering-leadership/">Engineering Metrics</a></li>
</ul>

      <p class="article-description">Your board will ask whether AI made engineering more productive. Most available numbers answer a different question. A taxonomy separating diagnostic signals from performance measures, a paired scorecard, and the sentence to actually say in the meeting.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-05-24">2026-05-24</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/evals-are-the-new-tests/">Evals Are the New Tests</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/technical-risk/">Software Quality</a></li>
</ul>

      <p class="article-description">In April 2025 OpenAI shipped a model update whose offline evals and A/B tests all looked good. It was sycophantic enough to roll back within days. A practical guide to building the measurement layer that would have caught it - with a working eval spec and grading rubric.</p>
    </div>
  </article>
  <article class="article-row">
    <time class="article-date" datetime="2026-04-26">2026-04-26</time>
    <div class="article-row-content">
      <h3 class="article-title"><a href="/docs/code-was-never-the-bottleneck/">Code Was Never the Bottleneck</a></h3>
      
<ul class="article-topic-labels" aria-label="Topics"><li><a href="/topics/ai-assisted-engineering/">AI-Assisted Engineering</a></li><li><a href="/topics/technical-risk/">Code Review</a></li>
</ul>

      <p class="article-description">Your engineers are producing more code and your delivery cadence has barely moved. The waiting did not disappear - it moved downstream to review and absorption, and that is where the constraint always was. Includes a review-capacity audit.</p>
    </div>
  </article>
</div>

<h2 id="explore-related-topics">Explore Related Topics<a class="anchor" href="#explore-related-topics">#</a></h2>
<nav class="topic-hub-links" aria-label="Browse field notes by topic">
  <ul>
    <li>
      <a href="/topics/engineering-leadership/">Engineering Leadership</a> — Team design, technical strategy, metrics, and organizational judgment.
    </li>
    <li>
      <strong aria-current="page">AI-Assisted Engineering</strong> — Review capacity, evals, useful metrics, and AI-era team design.
    </li>
    <li>
      <a href="/topics/software-delivery/">Software Delivery</a> — Roadmaps, small bets, product engineering, and reliable delivery.
    </li>
    <li>
      <a href="/topics/technical-risk/">Technical Risk</a> — Code review, software quality, technical debt, and recovery.
    </li>
  </ul>
</nav>

]]></content:encoded>
    </item>
  </channel>
</rss>
