Alistair’s story
I have spent a career in technology, and a good part of it wrong about where the difficulty sits.
What I got wrong first
For the first half of my career I was sure the problem was engineering practice. I taught teams test-driven development, where the test describing a change gets written before the code that satisfies it, and behaviour-driven development, where that description is written in language the business already uses. I spoke about it at industry conferences nationally and internationally, and published open source in the testing space.
Teams got genuinely better at building software. A good number of them were still building the wrong thing.
The practice was never the bottleneck. Working out what was took a venture studio and 14 attempts.
Why the practice matters more now
That is not a case against the practice, and AI coding tools have made it more of a case for it. A team that writes the test before the code, and describes behaviour in the language the business uses, has a machine-checkable statement of what the software is meant to do. Without it you cannot tell whether a model writing code for you is accelerating the work or producing plausible wrong answers very fast. Google’s 2025 DORA research found the same split between teams: loosely coupled systems with fast feedback gained from AI, tightly coupled ones with slow processes gained little.
Practice is what makes the speed usable. It is still not the reason for the work.
Inside the machinery
I spent those years in one organisation, which grew by merger into a mid-sized services business building e-commerce platforms and running large replatforming programmes. I grew up in it, engineer to tech lead to CTO.
That last seat is the one that matters here. I was not watching the commercial machinery from the delivery floor and guessing at it. I sat in the meetings where the business decided what it could afford to sell, and the answer was shaped by how many salaried people were waiting for work and what the last round of pitching had cost. Everyone in those rooms wanted to do good work. Most of them were doing good work. None of it changed what the numbers allowed into a proposal.
14 attempts
The studio sat inside a large insurer. A core team of five would work up a business model, build enough of it to find out whether it was real, then hire the founding team and stay with the investment through to funding or exit. Over 4 years that ran 14 times.
14 attempts is enough to stop believing your own explanations. Engineering quality did not separate the ones that worked from the ones that did not. What separated them was whether anyone had understood the problem before committing to a shape for the solution. That is an uncomfortable finding after 15 years spent improving how software gets built.
In practice that meant building the shared foundation once, so no company in the portfolio spent its early months rebuilding infrastructure that was not the thing it was testing.
The third seat
What I do now is the third seat. I sit inside the team that has to live with the decision.
The clearest version of it started before there was a company. I worked with the investor to form the technical foundations, built the early prototypes that decided what was worth building at all, hired the first engineer, and then coached that engineer until the company hit its funding milestone. No part of that was a proposal. Each next step was a conversation, because by then I was already in the room.
The seat is narrower than the other two rather than better. I cannot staff a programme, and one person inside a team is a dependency that team has to be willing to carry. What it can do is ask the next question without selling it first, and report an answer nobody wanted to hear.
Start with a conversation
30 minutes, no pitch, and a straight answer on whether Kodehort is the right fit.