Thoughts

The quickest way I’ve found to learn a technology is to need it to do something.

I’ve done courses. I’ve been to conferences. I’ve read books and documentation. All of them have their place.

But give me something I actually want to make and I’ll learn considerably faster.

The application creates the questions.

How does this store data?

Where should this logic live?

How does authentication work?

How do I deploy it?

What happens when I want to do something the framework’s authors hadn’t anticipated?

You can spend hours learning how something is supposed to work.

Build something and you’ll discover how it actually works before lunch.

Professional development is hard in an agency

I’ve spent a lot of my career in agencies, and professional development is one of those things everyone agrees is important and nobody quite knows where to put.

The obvious answer is to allocate time for it.

I’ve tried variations of the 20% model. Give developers a proportion of their week for learning, experimentation or internal projects.

I’ve never really managed to make it work.

The problem is fairly obvious.

If an agency is busy, there’s always something else to do.

There’s a deadline. Something needs testing. A developer needs help. A client has come back. There’s a pitch. There’s support work. The project that was supposed to finish on Wednesday hasn’t finished.

The protected Friday afternoon gradually becomes:

You can have 20% of your time, provided you’ve done 100% of your work.

Which isn’t really 20% time.

And there’s another slightly uncomfortable point.

If you’ve always got 20% spare capacity for professional development, there’s a reasonable chance you haven’t got enough work.

Professional development time doesn’t magically appear.

You have to make it.

Training should cost something

If the business needs a capability, learning it is work.

If we’ve won a project requiring Drupal and somebody needs to learn Drupal, that’s work.

If accessibility is becoming a bigger part of the offer and the team needs deeper expertise, that’s work.

If agentic development is changing how we build software and developers need to understand it, that’s work too.

An employer can’t consume somebody’s entire working week and then make maintaining their professional skills an evening activity.

If the company needs the capability, the company needs to provide the time to develop it.

Real training has an opportunity cost.

If I take a developer off billable work for two days to learn something, I’ve made an investment.

That’s fine.

That’s what investment means.

If professional development only happens when there’s literally nothing else for somebody to do, it isn’t much of an investment.

Curiosity isn’t a training strategy

There’s an uncomfortable truth about software development.

Some of the developers I’ve seen progress fastest are naturally curious about technology outside work.

They make things.

They try things.

They install something because they want to know how it works.

They’ll spend an evening making something completely unnecessary because the idea amuses them.

I’m like this myself.

Making things is something I do to relax. If I’ve got three ideas I could work on, I’ll often choose the one adjacent to something I think might become professionally useful.

Inevitably, some of that learning comes back into work.

But an employer cannot build a professional-development strategy around that.

The moment keeping up becomes an expectation outside working hours, something has failed.

People have children. They have caring responsibilities. They have hobbies that have absolutely nothing to do with computers. Some excellent developers close the laptop at the end of the working day and don’t think about code until the following morning.

They shouldn’t be professionally disadvantaged because somebody else happens to enjoy doing the same thing for fun.

Personal curiosity is a bonus.

It isn’t free training.

Not everyone learns the same way

Some developers are excellent structured learners.

Give them a course, a conference, a workshop, a certification or a good book and they’ll systematically work through it.

Others are more exploratory.

They encounter a new technology and immediately think:

I could make something with that.

I’m definitely in the second camp.

For me, the idea creates the curriculum.

I don’t particularly want to learn a framework and then decide what I could do with it.

I want to make something, discover that the framework might help me do it, and learn whatever I need along the way.

There’s a useful capability hidden in that too.

Some developers are particularly good at inventing reasons to learn things.

A new browser API appears and they think of something that could use it.

A new framework appears and they invent a little application that will push against it.

A new AI capability arrives and they immediately wonder what happens if they connect it to something else.

The project doesn’t have to be useful.

It gives the learning somewhere to happen.

But that isn’t the only way to learn, and management needs to recognise the difference.

Sending somebody who learns by making things on another generic three-day course might not be the best use of their development budget.

Sometimes the better offer is:

Here’s two days. Build something with it.

Agencies are a product of their work

There’s another problem with professional development in agencies.

We become good at the work we win, and we win the work we’re already good at.

An agency wins a load of WordPress work.

It hires WordPress developers.

Those developers get very good at WordPress.

The agency develops deployment processes, hosting knowledge, plugins, integrations and reusable approaches.

The case studies demonstrate WordPress expertise.

The sales team can confidently sell WordPress.

So the agency wins more WordPress work.

That’s not bad strategy.

It’s completely rational.

But it is circular.

The work determines the capability.

And the capability determines the work.

Tech stacks are sticky

This is one reason technologies like WordPress and Drupal have remained so persistent.

I’ve delivered sites across a lot of CMS platforms over the years. For a long time, choosing one often felt like choosing the best of a bad bunch.

Then I started working with Craft CMS.

I’ve delivered numerous sites with Craft now, and it’s the first CMS I’ve used where I haven’t felt that way. I genuinely like it. It gives developers a sensible way to model and build things without making the editing experience somebody else’s problem.

So why doesn’t every agency doing WordPress or Drupal immediately move to Craft?

Because an agency choosing a CMS isn’t just comparing CMSs.

Imagine an established Drupal agency.

It already has experienced developers.

It understands hosting.

It has deployment pipelines.

It knows the security model.

It has modules, boilerplate and migration tooling.

Its project managers understand roughly how long things take.

Its account managers understand the terminology.

Its sales team has case studies.

Then somebody says:

Craft is better.

Even if everybody in the room agrees, changing stack means potentially walking away from years of accumulated organisational knowledge.

The stack isn’t just the software. It’s the capability surrounding the software.

Diversification has a cost too.

Now you’ve got another set of dependencies, another deployment model, another security process and another technology the team needs to remain capable of supporting.

It’s not difficult to understand why agencies stick with what they know.

The capability trap

That creates a difficult problem.

How do you become capable of delivering something you’ve never delivered?

You need the work to develop the capability.

But you need the capability to win the work.

Eventually somebody has to go first.

That’s where small practical projects become useful.

Don’t wait until a client is paying you to discover whether a technology is appropriate.

Don’t necessarily send somebody on a week-long course either.

Give them a problem.

Build something.

It doesn’t have to work

A learning project isn’t a client project.

It doesn’t need a roadmap.

It doesn’t need a product owner.

It doesn’t need a launch strategy.

It doesn’t even need to get finished.

The objective isn’t the thing.

The objective is the journey towards making the thing.

You might spend two days building something and discover the technology is completely inappropriate for the kind of work your agency does.

Excellent.

You’ve discovered that before putting it into a client project.

You might get 60% of the way through and hit exactly the architectural problem you needed to understand.

Stop.

The project has done its job.

You might make something absolutely useless but learn three things that turn up in client work six months later.

That’s useful too.

A learning project doesn’t necessarily need a definition of done.

It needs a question worth answering.

Agentic development changes the economics

This is where things have changed considerably.

Historically, building unfamiliar things was expensive.

You’d lose half a day setting up an environment.

Then you’d work through documentation.

Then you’d discover the tutorial was written for the previous version.

Then you’d spend two hours trying to understand an error.

Eventually you might reach the interesting problem you actually wanted to investigate.

Agentic development removes a lot of that friction.

An agent can scaffold an unfamiliar project.

It can explain conventions.

It can translate concepts from a technology you already understand.

It can navigate documentation.

It can get you through the boring bits much faster.

That makes learning by building much more practical inside an agency.

Agentic development makes disposable software cheaper.

That’s important because the point of a learning project was never necessarily to keep the software.

Want to know whether a different CMS might suit a particular kind of project?

Build something.

Want to understand what an unfamiliar AI integration is actually like to work with?

Build something.

Want to know whether a framework solves a problem better than the one you already use?

Build something.

It can go in the bin afterwards.

What does learning mean now?

There’s an obvious question here.

If I ask an agent:

Build me a small application using this framework that does this.

And shortly afterwards I’ve got something working, have I actually learnt the technology?

A few years ago, I’d have been much more concerned about that question.

I’m less sure it matters in quite the same way in 2026.

I don’t necessarily need to learn how to reproduce every line the agent wrote.

I don’t need to memorise another templating syntax just to prove I can.

I need to understand what it built well enough to question it, change it and ultimately take responsibility for it.

In fact, getting the boring implementation out of the way might get me to the useful learning faster.

How does this technology structure things?

Where does the complexity live?

What does it make easy?

What does it make difficult?

What happens when I push against its conventions?

How does it fail?

Would I recommend it to a client?

Would I want another developer to inherit it?

Those are the interesting questions.

The objective isn’t to prove I can work without the agent. It’s to make sure the agent hasn’t worked without me.

The threshold has moved

I think this changes what it means to “know” a technology.

I’ve been doing this long enough to have learnt and forgotten an enormous amount of syntax.

That used to matter much more than it does now.

An agent can retrieve syntax instantly.

It can remind me how an API works.

It can find the configuration option.

It can explain an unfamiliar convention in terms of one I already understand.

The valuable knowledge moves upwards.

Why would I choose this?

Where should I use it?

What are the trade-offs?

Where does it become difficult?

How does it fit with the rest of the stack?

Can I recognise when the agent has done something stupid?

Can I take responsibility for what’s been built?

The threshold has moved from:

Can you write it?

to:

Can you own it?

That’s a much more useful definition of capability now.

Agents might make stacks less sticky

And this brings us back to the agency’s technology stack.

Historically, adding another technology meant acquiring another substantial body of knowledge.

Agentic development reduces some of that switching cost.

A good Drupal developer doesn’t become an experienced Craft developer because they’ve opened a coding agent.

There are still things you only learn by operating software.

But an experienced developer already understands many of the underlying problems.

Content modelling.

Templating.

Caching.

Permissions.

Migrations.

Deployment.

Security.

Architecture.

Give that developer a new CMS and an agent that can explain its conventions in terms they already understand, and the journey to being productive becomes considerably shorter.

The question starts moving from:

Do we have a developer who knows Craft?

towards:

Do we have a developer who understands CMSs well enough to become productive in Craft?

That’s a significant difference.

And perhaps it gives agencies a way out of the capability trap.

We don’t need to put an unfamiliar technology straight into production.

We don’t need to retrain an entire development team because somebody saw an interesting conference talk.

But the cost of exploring the thing next door has fallen dramatically.

We can afford to find out.

Professional development doesn’t have to mean promotion

There’s another reason this matters in agencies.

It’s crowded at the top.

You might have eight developers, three seniors, a lead and one Head of Development.

There aren’t enough progressively grander job titles for everybody.

And not every good developer should become a manager anyway.

Professional development needs another dimension.

Capability.

A developer can become more valuable without acquiring direct reports.

They can become the person who understands accessibility.

Or performance.

Or AI-assisted development.

Or a new CMS.

Or analytics.

Or integrations.

Or something the agency doesn’t even sell yet.

Career progression doesn’t always have to be:

Developer → Senior → Lead → Head

Sometimes it’s:

Developer → Developer who can now take us somewhere we couldn’t go before.

That’s valuable too.

Don’t call it innovation time

I don’t think agencies need another innovation programme.

I don’t think everyone needs 20% of their week permanently protected.

And I definitely don’t think developers should be expected to spend their evenings keeping the agency technically relevant.

Be more deliberate.

If there’s a technology you think might matter, make some time.

If someone learns through courses, send them on the course.

If they learn by making things, give them something to make.

If there’s spare capacity, use it.

If there isn’t, and the capability matters enough, accept the opportunity cost and create some.

Let the agent help.

Then let the experiment fail.

Let it be ugly.

Let it get halfway through.

Let the developer discover that the exciting new technology is actually horrible.

Let them abandon it.

The repository can go in the bin.

The capability doesn’t.

Build something

Professional development in agencies will always be difficult.

We’re busy.

The work we’re doing today naturally makes us better at the work we’re already doing.

Our technology choices accumulate years of experience around them and become difficult to move away from.

And there are only so many promotions available.

Agentic development doesn’t remove those problems.

But it changes the economics.

It makes experimentation cheaper.

It makes unfamiliar technologies more approachable.

It lets experienced developers transfer what they already understand into new environments much faster.

And it means we can potentially spend less time memorising how to do things and more time understanding why we’d do them in the first place.

Courses can help.

Conferences can help.

Documentation can help.

Agents can help enormously.

But software development is still an applied discipline.

Eventually there’s a very simple way to find out whether something is useful.

Try to use it.

Don’t wait for the perfect client.

Don’t make it homework.

Don’t worry too much about finishing it.

Find a question worth answering.

Make some time.

Build something.