The failure mode of a technical strategy is almost never that it was wrong. It is that it was never funded, because nobody translated it into the language the budget is written in.
That translation is most of this role. Directing the cloud architecture for a logistics platform running 300,000+ shipments was an architecture job on paper; in practice it was equally about sequencing the roadmap so each phase paid for the next. At Amazon, a proof of concept that made an infrastructure bottleneck undeniable is what secured VP-level funding for a phased cross-org rollout — the architecture had been correct for months before that.
What this covers
Technical strategy that a board can act on. A roadmap tied to commercial milestones, with the cost of not doing each item stated plainly. Executives do not reject technical work because they undervalue it; they reject it because nobody showed them the alternative’s price.
Due diligence with a real opinion. Whether you are buying, raising, or inheriting a system, the useful output is not an inventory. It is a ranked, priced list separating what is genuinely structural from what merely looks alarming in a scan.
The engineering organisation. Team topology, hiring, standards, and the review culture that makes them stick. Building a development centre from zero — twelve engineers, a defined culture, 30% organisational revenue growth in six months — is the reference for this work.
How it works in practice
One to two days a week, with real decision authority in the technical domain. Available to the board, to the engineering team, and to whoever is uncomfortable, which is usually where the actual constraint is.
The measure of the engagement is that it ends: a permanent CTO hired well, or an engineering leadership team that no longer needs the seat filled.