Walking into an organisation on day one and being asked “so, how are we doing” is the single most common moment in fractional CTO work, and it’s also the moment where a wrong first move costs months. There’s no existing context, no institutional memory of past decisions, and a genuine risk of either taking too …
Ask which system is most critical to the business and you’ll get a confident architectural answer. Ask which single person’s absence would hurt the business most, and watch the room go quiet — because everyone knows the answer, and almost nobody has done anything about it, because naming it feels like an accusation rather than …
AI doesn’t make an engineering organisation good or bad. It makes a good one better and a bad one worse, faster than either outcome would have happened without it — and the organisations most excited about AI’s productivity gains are frequently the ones with the least visibility into which of the two they actually currently …
Every individual engineer using AI assistance reports feeling faster. Measured at the system level — release cadence, defect rate, time from idea to production — a meaningful number of organisations adopting AI-assisted development are getting slower, not faster. Both observations are true simultaneously, and the gap between them is one of the more important things …
A bad technology decision costs money. An unmade technology decision costs more, consistently, and almost never shows up as a line item anywhere — because nothing was spent, nothing was approved, and the cost hides entirely in what didn’t happen instead of what did. I’ve written about the governance gap between decision rights and feedback …
Most AI adoption advice assumes a large organisation with a dedicated innovation function, a data science team, and budget for a multi-quarter pilot programme. Almost none of the organisations I actually work with have any of that. This is the playbook for the other case — four strategies, chosen deliberately by situation, not a single …
Build-vs-buy conversations almost always mean software. There’s a parallel, less-discussed version of the same question for capability itself: hire a team, or buy access to one through a contractor, agency, or fractional arrangement. Getting this decision wrong is at least as expensive as the software version, and it gets considerably less deliberate attention. I’ve written …
A technology team that spends its days clearing tickets is, by definition, not spending those days executing a strategy — the two are not the same activity wearing different names, however much a full ticket queue looks like productive work from the outside. Reactive task queues — support tickets, ad hoc requests, urgent fixes — …
Called in to fix a technical problem, I almost always find one. I’ve stopped being surprised that it’s rarely the actual problem — usually a symptom of a decision-rights gap, a misaligned incentive, or a process nobody owns, wearing a technical costume because a technical fix is easier to scope than an organisational one. This …
A fractional CTO arriving at an organisation with an existing development agency relationship faces a genuine choice most guides skip: work with what’s there, or treat it as an obstacle to route around. Treating it as an obstacle is usually the wrong instinct, and it’s also the easier one, which is exactly why it happens …