For most of my career I thought the job was to pick the right technology. Choose the right stack, the right architecture pattern, the right level of abstraction. Get those decisions correct and everything downstream gets easier.
It took a few expensive mistakes to understand what the job actually is: pricing the future correctly.
Every technical decision you make either makes the next decision cheaper or more expensive. A clean abstraction layer keeps your options open. A shortcut that works today — and it will work today, that’s the trap — narrows what’s possible tomorrow. The question that should follow every architecture proposal isn’t “is this technically sound?” It’s “what does this make easier, and what does this make harder?”
Every architecture decision either makes the next one cheaper or more expensive. There is no neutral.
Most engineering leaders know about tech debt. You defer cost now, pay it later, usually with interest. The “temporary” patch from 18 months ago that nobody touched becomes load-bearing. The monolith that made sense at 20 engineers becomes the thing slowing down 80. The cost compounds quietly, and by the time it’s visible it’s also unmovable.
What gets talked about less is the mirror problem: the tech bet.
Alex Ewerlöf describes it precisely — a tech bet is paying the price of a hypothetical future upfront, without the data to back it up. The startup that builds for global scale before they have product-market fit. The platform team abstracting away services that don’t exist yet. The engineer from a prestigious company who arrives convinced your architecture needs a complete redesign — and who isn’t wrong, exactly, just early by about two years.
The symptom is the reverse of tech debt: the product requirements lag behind what the technical solution can do. You’ve bought a future that hasn’t arrived and you’re paying to maintain it in the meantime.
I’ve made both mistakes. The debt version is more common and more forgiving — everyone understands it, the remediation is known, the timeline is usually recoverable. The bet version is harder to catch because it arrives disguised as ambition. It sounds like “we’re building for scale” and “we’re being proactive about architecture.” The team is working hard. The code quality is high. The system is just built for a product that doesn’t exist yet.
The reframe that’s changed how I make decisions: the CTO’s job isn’t to build the best technology. It’s to make the future cheaper. Not free — cheaper. Every decision is a bet on what the product will need next, and the job is to price that bet accurately.
A useful heuristic I’ve borrowed from Ewerlöf: when someone pushes for a technical investment, ask how long it can be postponed and what it costs per month to wait. If they can’t answer, the investment is probably a bet. If the answer is “indefinitely,” it’s definitely a bet. The best technical decisions are the ones where the cost of deferral is real and measurable — where you’re not buying optionality you don’t need yet.
The other side of that question matters equally: what does this decision foreclose? Every abstraction, every infrastructure choice, every “let’s do it the right way now” carries a hidden cost in the options it eliminates. Naming those explicitly before committing is the closest thing to a forcing function I’ve found for catching bad bets early.
The goal isn’t technical purity. It’s staying in the game long enough for good decisions to compound.
If any of this maps to decisions you’re sitting on — a rewrite, a platform bet, a piece of debt you’re not sure whether to pay down — reach out. Happy to think it through.
Alex Ewerlöf — Tech Bet