The View from the Studio

I have watched a Big Four partner walk a client through an agile transformation deck in the autumn of 2024, and I have watched the client nod politely through the second hour, and I have watched the invoice land shortly afterwards for the first of five phases. The deck was good. The partner was bright. The client was a mid-sized insurer in Central Europe with roughly eleven hundred people in its IT function, and the phases on the slide were the ones I would have drawn myself in 2016 — squad formation, ceremony cadence, definition of done, product ownership, scaling framework. Nothing on the slide was wrong. Nothing on the slide was new, either. The same deck, with the same five phases, was being sold by the same firm to a different client two floors up in the same building. I know because I had lunch with the other client’s head of engineering the following week and he showed me his copy on his phone.
There is no scandal in this. The big consultancies are selling, in good faith, a methodology that was genuinely hard-won in the 2000s and 2010s, they are selling it to organisations that have still not finished adopting it, and the organisations are still, for the most part, getting real value from the work. The scandal, if there is one, is elsewhere: the methodology on those slides is the one every founder using Lovable on a Saturday morning has already left behind, and nobody in the room on either side of the table seems to have noticed.
I am not going to make fun of this. I ran a studio through the same agile adoption curve between roughly 2012 and 2018, and I remember how long it took to hold. The problem is not the ceremonies or the language; it is that the whole apparatus — sprints, stories, acceptance criteria, scoping phases, discovery workshops — was designed to close a gap that, for a growing class of clients, has already closed. The gap between what a founder has in their head and what a developer can build against has been closing fast, and in some cases it has already gone. When it has gone, the apparatus built to bridge it looks like a customs post on a border that no longer exists.
Before your next discovery workshop or scoping phase, ask one question: does this founder already have a working prototype? If yes, skip the workshop and spend that time inside the repository. The workshop was built to extract what the prototype has already made visible. Reading the code is faster and more honest.
The people who built that customs post are still staffing it. They have to. The organisations still adopting agile are not the ones sending us repositories on a Monday morning; they are the ones running twenty-year-old core systems on mainframes, and they need every bit of the agile apparatus they can get. The consultancies serve them well. But they are not, by and large, the people who are going to write the next methodology down, because the clients they serve are not yet living in it.
Sliday’s first era, from 2009 to 2014, was a scramble. We opened in Auckland, took whatever work walked in the door — brochure sites, a couple of e-commerce jobs, a Rails application for a real-estate syndicate — and shipped in one big push at the end of each project with a midpoint demo for morale and a fortnight of firefighting at the end. We called ourselves agile because the word was in the air. In practice it was waterfall with a guilty conscience. David Kravitz and I had agreed the founding split by handshake in those early months — written nowhere beyond the incorporation documents, fifty-fifty, built on trust rather than contract. A friend warned us that equal partnerships almost always come apart. Ours did not, and has now outlasted most companies that launched alongside it. The conviction that it would hold came, for David, from a moment before the studio even had clients: launching sky lanterns on a beach in Thailand around November 2008, he waded knee-deep into the water pushing one lantern up each time it dipped towards the surface until it finally caught and flew. He came home and went full-time on the studio. The reasoning was uncomplicated: if he would do that for a paper lantern, the company would fly. What carried through from that period was the extraction habit: sitting with a person who could not yet describe the product in their head and working them towards a document a developer could read. The projects from that period taught me the habit that Murray illustrates in the opening chapter. The habit was valuable. The mistake, which I only saw later, was believing the habit was the craft. It was the craft of that era, not the craft of the studio.
The second era, 2014 to 2022, was the cleanest agile practice we ever ran. I started shipping the first version of Karma on the side — a B2B SaaS that went through Y Combinator’s Startup School and eventually reached roughly $750,000 in annual recurring revenue at its 2024 peak — and became, usefully, a client of my own methodology. Sliday settled into a two-week cadence, wrote user stories that were read, and built a practice strong enough to ship 200+ projects across the team between 2014 and 2022, mostly SaaS, mostly Europe and Asia. Agile worked. It earned its keep. The ceremonies were not theatre, because we had enough project volume to see which ones moved a project and which ones slowed it, and we dropped the ones that slowed it without a fight. That is a luxury a consultancy does not have, because a consultancy is selling the ceremony. What carried through was the cadence discipline and the willingness to cut anything that did not earn its place on the invoice. What fell away, slowly, was the belief that the extraction phase was load-bearing. Clients had started arriving with cleaner briefs; by 2021 a handful were sending us Notion pages with working flow diagrams, and we were still, out of habit, billing them for a discovery workshop. We noticed, but we did not act on the noticing, because the workshop was also how we justified the onboarding rate. Across those eight years, David says his biggest personal change was losing the feeling of being a complete impostor — present at the founding, gone by the end of the era, harder to shake than any client deadline.
We are not fighting an incumbency. We are not constrained to a sample of one.
The issue was forced by the third era, which I date roughly to the autumn of 2023, when the first clients began arriving with generated code rather than briefs. I have written about this elsewhere in the book and I will not rehearse it here. What matters for this chapter is that the third era did not feel like a methodology for its first year. It felt like clients behaving oddly. They kept sending repositories and asking us to “make this actually work,” and we kept scoping the repositories the way we had scoped napkins, and it kept not landing. The pattern became clear only because we had the other two eras to compare it against. A founder living through the third era in isolation would see only their project, and miss the change. We saw thirty of them in parallel, then sixty, then more, and the shape asserted itself. David places the shift inside the studio’s own working practice at around mid-2025. The first engagement that felt genuinely different, rather than merely novel, was generating illustrations and historical characters (Italian, Greek, Celtic) for Genomelink’s ancestry reports — not a prototype handed in for hardening, but a production deliverable produced in a way that had no precedent in the two prior eras. Around the same time, a Karma feature that would previously have meant two or three weeks of wireframing and design took about two hours from first sketch to near-finished state.
This is the middle claim of the chapter. The founders doing the new work are doing it brilliantly. Some of them are doing it better than we do, in the sense that they move faster through the early stages than any studio would. But they are working with a sample size of one, which is their own product, and the lessons they can draw from that sample are bounded by it. I know this because I run one of those projects myself, at Sky AI, and I know how tempting it is to generalise from what works for Sky AI to what will work for every B2B document-processing platform, and I know how often that generalisation is wrong. A founder writing a book about the new methodology from inside one project would write a good book about that project. They would not, by the nature of their position, see the pattern across projects.
The third position is the consultancy’s, and I have described it above. They see many projects, but they see them through the lens of a methodology they are still mid-way through selling. The incentive to name the thing that is replacing what they sell is low. The incentive to extend the life of what they sell is high. I do not blame them for this; I would do the same in their position, and I did something like it in mine in the late 2010s, when we held onto the discovery workshop longer than we should have.
The studio sits in the middle. We have shipped across both eras. We have shipped enough projects in the new era to see the pattern and not enough projects to be captured by a legacy offering that depends on the old one being true. We are not fighting an incumbency. We are not constrained to a sample of one. The view from the studio is the view from the intersection, an ordinary vantage point that happens to sit where the three claims of this chapter meet.
Twenty, maybe forty studios around the world have similar histories and similar throughput, and any of them could have written this book. A few, I suspect, are writing something like it now. The studio is the right kind of place from which the description comes, and somebody from inside that kind of place had to sit down and write it, or the two groups closest to the work would carry on missing each other.
The world is changing, and that’s wonderful.