Seeing Ten Steps Ahead Was Never My Problem. Choosing One Was.

Of the three parts of this job I have spent the week on, strategic long-term planning is the one I was worst at for years, and that is the opposite of what anyone who knows me would guess. I have always been ten steps ahead on everything. Seeing far was never the problem.

Choosing was. Early on I could see several paths clearly and I had genuine difficulty selecting which one to hang my hat on, because each of them was defensible and I could argue any of them convincingly, including to myself. What resolved it was not better foresight. It was learning to weigh the choices against each other and to read reversibility: how expensive is it to be wrong about this one, and how far back do I have to go if I am.

The second half took longer. I had to accept that I would simply be wrong sometimes, and what made that bearable was noticing how rarely being wrong meant returning to the beginning. Far more often it was a mid-flight course correction, which is an entirely different thing, and a leader who has never separated those two will avoid the decision rather than make it.

So here is the claim. People who are good at strategic long-term planning do see multiple steps ahead. That is the entry condition, not the differentiator. What separates them is that they can choose among the paths they see, on risk against reward, and that is the skill nobody teaches.

Planning is usually argued between two camps that look opposed and share an assumption. One says plan further out: roadmaps, annual strategy, the offsite that produces a deck nobody opens in March. The other says planning is futile, so stay adaptive and respond to change rather than follow a plan. Both are arguing about horizon and accuracy. Neither one is about selection.

Every technical leader reading this has sat in a planning cycle where the entire discussion was how far ahead to commit, and not once did anyone ask how the options on the page were chosen or who narrowed them before the meeting.

That is where the decision actually happened. The options arrive already narrowed and nobody notices, because narrowing is not an agenda item. Whoever wrote the deck narrowed it, and so did whatever is already funded. What is easy to describe in a slide narrowed it hardest of all, because an option needing three sentences loses to one needing six words, regardless of which is better. So the technical seat argues inside a set it did not shape, and winning that argument is participating in the last five percent of the decision.

Preparing for the next band never appears on the page at all, and not because anyone rejected it. It cannot be justified in the form the meeting requires, since no organization approves budget to prepare for a load that has not arrived. So it is not proposed, so it is not declined. It simply never becomes an option anybody had to say no to.

The bill arrives at the bend in the Load Curve, and the bend comes on the company's schedule rather than yours. Capability that had to be built in advance cannot be built in the quarter it becomes necessary. The gap turns out to be large, everyone expected it to be large, and nobody ever learns it could have been small, because that counterfactual is invisible by construction.

The personal version is the one worth naming. A leader who genuinely sees several paths spends their planning energy arguing about horizon, which is the lever they do not hold, instead of on selection, which is the one they do.

The leaders who are good at this are not better forecasters than you, and they are not more decisive by temperament. They stopped trying to win the argument in the meeting and started shaping what reached it.

You may not hold the decision. You hold the curation, and that is upstream of the decision, which is where most of it has already happened by the time anyone votes. Curate on two filters: whether the thing will see real adoption in the customer base you have or open the one you want, and whether the option as written reflects what it truly costs. Nobody else in the room can apply either filter honestly, which is a large part of why the seat exists.

Curation also has a moment, and it is not the meeting. The deck exists before the meeting. The intervention is in whatever conversation produces the deck, which is usually informal, usually short, and almost never on anyone's calendar. If you resolve to do better next planning cycle, you have already resolved to arrive late.

Then build ahead of the load and expect it to look wrong. Camber Architecture is architecting to the next band's demands, named after the manufactured beam built with a deliberate upward curve, sized to a load that does not exist yet. A cambered beam looks like a mistake before it is loaded. Building for a band your company has not reached looks identical, to you and to the people paying for it, which is why the word is the one that explains why the appearance is correct.

Fund it with Sleeving, which is casting capacity for the next band's load into work the current band is already paying for. It is named after the void cast into a concrete pour so a pipe can pass through later, placed during a pour that was happening anyway, because coring the slab afterward costs many times more and weakens what is already there. This is not concealment. The sanctioned work ships visibly and on schedule; it is simply specified one layer more carefully than its own mandate required, so the capability is waiting the moment a route opens.

There is a boundary on that, and it matters more than the technique. A sleeve lives inside the discretion you already hold over how work you own is specified. If you would have to ask permission for it, it is not a sleeve. It is a project, and it should be proposed as one.

Here is what it looked like for me. I saw that our API needed to be a full product rather than an afterthought, and we ran it as one. While that transition was underway I built our SOC 2 compliance alongside it, specified one layer more carefully than the work in front of me required, aimed squarely at HiTrust, which the company had no route to at the time. I want to be accurate about how that felt, because the honest version is less dramatic than the useful one. It did not feel brave; it felt right and smart.

That is what seeing several steps ahead actually buys you. Not courage, which is what people reach for when they cannot see. The move looked obvious from where I was standing, and it looked like over-engineering from almost everywhere else, and both of those were reasonable readings of the same decision.

An acquisition completed this summer, and the acquiring side is HiTrust certified across a number of its products. A route opened that did not exist when the groundwork was laid. The distance from a well-built SOC 2 to HiTrust turns out to be largely a matter of matching documentation templates, style, and manner rather than redoing the underlying processes, which is only true because of how the SOC 2 work was specified. The gap turned out to be small, and everyone had every reason to expect it to be large. That is the only form this work is ever recognizable in: hindsight, as a gap that was smaller than it should have been.

The objection to all of this is that the next band might never arrive, and you will have spent capacity preparing for a future that did not happen. That is true, and it costs less than it sounds like. We all moved to rapid iteration years ago. Work falls by the wayside routinely and nobody agonizes over it. A sleeve that never carries anything is a spike that did not pan out, and the reason it is cheap is structural rather than optimistic: it was cast into a pour that was happening anyway.

So take your current roadmap and find the moment the options were narrowed to these. Name the conversation, and name who was in it. If you cannot, the selection happened without you and it will happen the same way next quarter. Then take one piece of work already funded this quarter and ask what it would cost to specify it one layer more carefully than its mandate requires. If the answer is that you would need approval, it is a project; if it sits inside the discretion you already hold, that is the whole practice, and you can start this week.

The Structural CTO book is where the Load Curve, Camber Architecture, and Sleeving are worked in full, including how to place a company on the curve rather than guess at it. It ships November 2 and is open for pre-order now: http://TheStructuralCTOBook.com