--- title: "CTO Field Notes: Engineering Leadership & AI | Aviv Zaken" description: "Practical field notes from Aviv Zaken on engineering leadership, AI-assisted development, software delivery, technical debt, code review, and building resilient teams." url: "https://avivzaken.com/" --- # CTO Field Notes > Practical field notes from Aviv Zaken on engineering leadership, AI-assisted development, software delivery, technical debt, code review, and building resilient teams. ## Author Aviv Zaken is an engineering leader, founder, and CTO. He has learned by making decisions with incomplete information, living with the results, and adjusting. CTO Field Notes turns that experience into practical lessons: what worked for him, what did not, and what he would do differently next time. [About Aviv Zaken](https://avivzaken.com/about/) · [LinkedIn](https://www.linkedin.com/in/avivzaken/) ## Topic guides - [Engineering Leadership](https://avivzaken.com/topics/engineering-leadership/index.md) — Practical field notes on engineering leadership, team design, technical strategy, engineering metrics, and resilient delivery. - [AI-Assisted Engineering](https://avivzaken.com/topics/ai-assisted-engineering/index.md) — Field notes on AI-assisted software engineering, including review capacity, evals, engineering metrics, and team design. - [Software Delivery](https://avivzaken.com/topics/software-delivery/index.md) — Practical field notes on software delivery, product strategy, startup engineering, and shipping reliably under uncertainty. - [Technical Risk](https://avivzaken.com/topics/technical-risk/index.md) — Field notes on technical risk: code review, software quality, technical debt, refactoring, and the cost of being wrong. ## Articles - [Code Review Is Risk Management](https://avivzaken.com/docs/the-reviewer-still-owns-the-merge/index.md) — Code Review, Software Risk. 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. - [How AI Is Changing Engineering Team Structure](https://avivzaken.com/docs/the-team-shape-is-changing/index.md) — AI-Assisted Engineering, Team Design. 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. - [Engineering Metrics in the Age of AI](https://avivzaken.com/docs/engineering-metrics-in-the-age-of-ai/index.md) — AI-Assisted Engineering, Engineering Metrics. 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. - [Evals Are the New Tests](https://avivzaken.com/docs/evals-are-the-new-tests/index.md) — AI-Assisted Engineering, Software Quality. 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. - [Code Was Never the Bottleneck](https://avivzaken.com/docs/code-was-never-the-bottleneck/index.md) — AI-Assisted Engineering, Code Review. 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. - [Staying One Step Ahead](https://avivzaken.com/docs/staying-one-step-ahead/index.md) — Engineering Leadership, Technical Strategy. 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. - [The Roadmap Problem No One Admits](https://avivzaken.com/docs/roadmap-problem-no-one-admits/index.md) — Product Strategy, Software Delivery. Most teams confuse motion with delivery. The roadmap isn't a list of things you want to do - it's a list of trade-offs you're willing to commit to finishing. - [Predictable Delivery in an Unpredictable World](https://avivzaken.com/docs/predictable-delivery-in-an-unpredictable-world/index.md) — Software Delivery, Engineering Leadership. Startups don’t fail because they move slowly. They fail because they lose control of their velocity. - [De-Risking Big Bets Without Killing Innovation](https://avivzaken.com/docs/derisking-big-bets-without-killing-innovation/index.md) — Product Strategy, Software Delivery. De-risking innovation isn't about avoiding failure - it's about learning faster through small bets, clear metrics, and structured experiments that keep creativity alive. - [Velocity Is the Product](https://avivzaken.com/docs/velocity-is-the-product/index.md) — Software Delivery, Engineering Leadership. Velocity is the product, not the metric. It's the rate at which you learn and ship features. It's the rate at which you can make changes to the system without breaking it. - [Shipping in Uncertainty: Field Notes on Startup SDLC](https://avivzaken.com/docs/shipping-in-uncertainty-sdlc/index.md) — Software Delivery, Startup Engineering. 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. - [Technical Debt Is a Tool](https://avivzaken.com/docs/technical-debt-is-a-tool/index.md) — Technical Debt, Engineering Leadership. Technical debt isn't the main problem-loss of trust is; continuous, small refactors keep teams confident and fast. - [Refactoring Is How You Keep Moving Fast](https://avivzaken.com/docs/refactoring-to-move-fast/index.md) — Technical Debt, Software Delivery. How continuous refactoring prevents engineering slowdowns and keeps the cost of change flat over time. Refactoring isn't a cleanup phase—it's the mechanism that preserves feature velocity. - [4 Musts of Building a New Feature](https://avivzaken.com/docs/4-musts-of-feature-dev/index.md) — Software Delivery, Product Engineering. 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's guide to reducing waste and shipping what matters.