Rebuilt Every Two Years

In the first week of January 2026 we held a meeting at Sliday that, had it been proposed two years earlier, I would have cancelled on the grounds that it sounded like the kind of ritual we had spent a decade trying to stop having. It is a forty-five-minute slot on a Monday morning. It has one agenda item, which is a spreadsheet, and the spreadsheet has three columns. The first column is a tool somebody on the team started using in the previous week. The second column is a tool somebody on the team stopped using in the previous week. The third column is what we intend to do about either. We call it, without any irony the team could find at short notice, the Triage.

It is the single most useful meeting we run, and it is the one we most nearly did not start.

For most of Sliday’s history the company’s internal training method was the method every studio of our size used, which is that we hired people who already knew the things we needed, we paired them with the next hire, and we called that knowledge transfer. It worked when the things we needed were stable over a three-to-five-year window. A senior Rails developer in 2014 was a senior Rails developer in 2017 with a few framework updates in between, and the shape of the work was recognisable to anyone who had been doing it for a decade. You could promote on accumulated judgement and interview on a CV, because what a person had been good at last year was still what we needed this year.

That arrangement has stopped holding. When I started writing this chapter I went back through our internal tools register and counted how many of the tools our delivery team was using in production in January 2024 are still in production in January 2026. The answer is roughly a third. The other two-thirds have been retired, replaced by a tool that did not exist when we adopted the one it replaced, or folded into a platform that absorbed three or four predecessors into one interface. This is not a function of our taste; other studios report similar numbers. The World Economic Forum’s 2025 Future of Jobs report projects that around three in five of the global workforce will need reskilling or upskilling before the end of the decade, and that one in nine of the whole workforce needs it and is unlikely to receive it.¹ Almost everybody is in that bracket, us included.

The fifty-nine per cent headline matters less to Sliday than the ratio between two half-lives. A specific tool, at the moment I am writing, lasts roughly eighteen months before the team’s usage pattern has meaningfully moved on from it. IBM’s skills research reaches a similar conclusion from the other direction: a learned skill lasts about five years and a technical one about two and a half; BCG puts the average under five and roughly half that in technical fields, and the range matters less than the direction.²³ The skill of adopting a new tool well lasts, as far as I can tell, for a career. The first half-life is shorter than a single performance review cycle. The second is the asset that actually compounds. If your studio rewards the first and neglects the second, you are training the team for a world they will stop living in before their next review arrives. Dmytro, a backend engineer we work with, puts the practical version of this plainly: your problem-solving is your value, not knowing every tool on the market; dig deeper into your core stack, adopt one tool at a time, master it for real use, discard it if it fails, then repeat.

Peter Senge called the capacity for continuous collective learning a discipline in The Fifth Discipline in 1990, and the framing survives because it was never about what the technology was; it was about whether the organisation could notice what it had stopped knowing.⁴ The vocabulary has aged. The observation has not.

I want to describe the practice we actually run, including the parts we got wrong in the first year.

The Triage meeting was the second thing we tried. The first thing we tried, in the first half of 2024, was a quarterly “AI upskilling sprint” — a week of structured training, external speakers, a shared reading list, a Slack channel with hopeful emoji. It produced exactly one useful outcome: a list of tools half the team had independently decided to abandon by the end of the sprint. The problem was the cadence. A quarter is too long: the tool we taught in week one was being deprecated by its own maker in week seven. We were teaching a snapshot of a moving picture, at the speed a snapshot moves, which is to say not at all.

Weekly, by contrast, is the cadence the tools themselves move at. The Triage does not teach anybody anything on its own. It exposes what is in use, what has been abandoned and what the next person to try it should know. The training happens afterwards, in pairs, in the quiet hour, on a live paid project, under a small explicit budget for the risk that the experiment fails. That last clause is the one that changed the meeting from a ritual into a practice. For the first six months we told the team we supported experimentation, and for the first six months nobody experimented, because the economic signal in the room was still that billable hours were the currency. In July 2024 we stopped talking about support and started writing a line on the project plan called experiment budget, usually between five and ten per cent of the engagement, explicitly labelled as money we expected to spend and did not expect to recoup. The experimentation rate went up within a month. The signal people responded to was not permission, which is cheap. It was a budget line, which is not.

Alongside the Triage and the experiment budget, we retired the job titles. This was the hardest of the four changes and the one I am still the least sure about. In 2024 the studio had the titles it had always had — senior developer, junior developer, designer, project manager, tech lead. By late 2025 several of those titles had stopped describing what the people underneath them were actually doing. Our most useful “senior developer” was spending half her time writing prompts and reviewing agent output, and the remaining half of her time acting as the verification layer on work the agents had produced faster than she could have produced it. Calling her a senior developer was not wrong, exactly, but it was undershooting the job. We replaced the title ladder with a flatter scheme — maker, editor, operator — with people rotating across the three as the work demanded. Some people on the team hated it. Some clients found it confusing and continued to ask who the developer was, by which they meant who was typing, which was increasingly the wrong question. The scheme is, a year in, partly back-tracked: we kept editor and operator as meaningful internal labels and quietly restored developer to external-facing documents because the friction on the client side was not worth the fight. The lesson, which I am passing along rather than dressing up, is that language changes slower than practice, and the studio that tries to lead on both simultaneously will exhaust itself.

The fourth practice is the one I nearly did not write down because it sounds, on the page, like a slogan. The job of every person at the agency, in 2026, is to automate their own work as much as possible, the interesting parts included: to hand the model, piece by piece, every repeating motion in the week, and to use the time that returns to build the next thing the model cannot yet do. The phrase the team landed on for this, which I dislike and have not replaced, is that everyone at the agency is now, in part, an AI trainer. The designer trains the prompt repository, the engineer trains the agent on the codebase, the QA lead trains the gates on the corpus of bugs we have already seen, the content manager trains the voice document. A lot of the studio’s compounding value, in the end, sits in those trained artefacts rather than in any individual head. You can think of it the way a Pokémon trainer thinks about a team: you train the small team that does the fighting, and you know which one to send into which fight.

The reason this is a practice rather than a principle is that without a deliberate slot for it, nobody does it. Automating one’s own work, at the level that matters, is slow and uncertain and does not produce billable hours in the week it is done. We carve out, on Friday afternoons, a two-hour block that is labelled training on the calendar — not training in the human-education sense, but in the literal sense of teaching the studio’s agents to do more of the studio’s work. The block is protected. It is not billable, and clients are not told about it individually because it does not belong on any single invoice. Over a year it compounds. The first six months produced very little we could point to. The last six produced most of the tooling I now consider central to how the studio ships.

Seniority can make adaptation harder when you have more expertise to retire. A junior engineer may have fewer established habits to reconsider; a senior engineer may need to examine years of instincts. This is a learning problem, not a ranking of colleagues. Łukasz describes what this looks like from the outside as a kind of donkey paralysis: offered too many options at once, the person freezes between them, works less and less, and loses motivation with each new tool that appears before the previous one is mastered. Training alone cannot settle that tension. Agree that reconsidering established expertise belongs to the job and give the person time to practise.

There is a list I keep, not on paper, of signals that a person should consider leaving a role. I have never shown it to anyone at Sliday and I will not name the people in whom I have seen these signals, but the list itself is worth setting down.

The first signal is that the studio you work for is selling, in 2026, roughly the same deliverables it was selling in 2021. Competence should survive. The sameness I mean is in the deliverables, the line items and the quotable scopes. If the thing on the proposal has not moved in five years, the thing on the proposal is not what the market is actually buying any more; it is what the studio remembers the market buying.

The second signal is that your manager dismisses the new tooling rather than critiques it. Critique is fine. I would rather work with someone who has three reasoned objections to agent-assisted development than someone who accepts it uncritically. Dismissal is different. Dismissal is the posture of a person who has decided that the change is a fashion and will pass, and a person who has decided that is no longer a person you can learn from in this field, because the thing they have decided is not true. The same gap, viewed from the other side: Łukasz noted that his university felt like a museum, training students as curators of material two decades old, and the distance between that curriculum and what the market now asks for is wider than any single manager’s dismissal.

The third signal is the one I find hardest to say to people I like, which is that your last quarter’s output looks identical to the output of two years ago. Identical shape, identical volume, identical kind. If the work has not changed and the field has, you are already somewhere the field is not, and it is cheaper to notice that now than in eighteen months, when the market has noticed it first.

None of these signals is decisive on its own. All three together are diagnostic.

If I were writing this chapter only for employees I would stop there. I am not, because the contract runs both ways, and a studio that demands constant reorientation from its staff without carrying its own half of the weight will find, soon enough, that the staff worth keeping have noticed.

What the studio owes, in our experience, is three specific things. Training time that is real — paid, calendared, not the fiction of learning-during-gaps. Tool budgets that are funded, not lists of approved tools that nobody has permission to spend on. And permission to experiment on paid work, under the explicit budget line I described earlier, rather than only on side projects in nobody’s evenings. Training without budget is a slogan. Budget without permission is an accounting entry. Permission without time is a cruelty. All three together are the minimum, and they are expensive, and we pay the expense because the alternative — a team whose skills ossified on the last tool-set — is more expensive still, just further down the road.

What the employee owes is harder to write because it sounds, however carefully phrased, like a lecture. It is three things also. Honesty about what is changing, including the parts of your own job you suspect have stopped mattering. Willingness to retire your own expertise when the evidence arrives, rather than defending it because it is yours. And a refusal to hide behind the old role title, particularly when the old title is more impressive than the new work inside it. The title protects no one any more. The practice is the thing.

The mutual contract holds or it does not. Most of the time it breaks quietly, on one side first, and by the time the other notices, it is months too late to repair.

We are in the second full year of this. The Triage works; the experiment budget works; the retired titles half-work; the Friday training block is the one I would defend most aggressively, because it is the one every other practice compounds into. I do not expect any of these specifics to survive the decade. The point was always the habit of rebuilding them, which is the only piece of this any of us actually get to keep.

The career that lasts is the one that agrees to be rebuilt every two years, on purpose, by its owner.