Articles#
CTO Field Notes is a collection of practical articles on the decisions behind engineering delivery: how teams use AI without giving up judgment, manage technical risk, keep software changeable, and turn uncertain plans into reliable progress.
Browse by Topic#
All Field Notes#
Code Review Is Risk Management
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
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
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
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
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
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
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
Startups don’t fail because they move slowly. They fail because they lose control of their velocity.
De-Risking Big Bets Without Killing Innovation
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
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
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
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
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
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.