The CTO's Guide to Shipping Fast

Every org I’ve joined thinks it has a speed problem. Almost none of them have a speed problem. They have a decisions problem — too many open loops, waiting on someone else to commit. Here’s what I’ve learned helps.

1. Make decisions the day you see them

A decision sitting on a desk for a week costs more than a decision made wrong and reversed on day two. Set yourself a one-day clock: if a question has been open longer than that, either you decide, or you assign who does.

2. Write decisions down — lightly

Not an ADR process. Not a template that takes an hour. A three-bullet note: what we chose, what we rejected, what we’ll reconsider if X changes. The reconsideration trigger is the part that matters; without it, every decision gets relitigated.

3. Choose boring technology (again)

Yes, I said this in the last post. It’s worth repeating because no one listens the first time. The reason boring tech ships faster is not that it’s faster — it’s that nobody has to learn it mid-sprint. Your innovation budget is finite. Spend it on the product, not the toolchain.

4. Kill projects early, not late

The hardest engineering lesson is when to stop. Every killed project feels like failure; every late killed project feels like fraud. Check-in every sprint: “Would we start this project today, knowing what we know now?” If no, don’t finish it out of politeness.

The compounding effect

None of these are about working harder. They’re about removing the delays that compound silently: a decision you didn’t make, a document you didn’t write, a project you didn’t kill. Remove those, and speed follows.