Why Blocking Developer Learning Is an Expensive Technical Decision

ℹ️ Rewritten 18 September 2026

I first published this post on 12 September 2025, and I have since rewritten it. The original built its case on a return on investment calculation that I had invented, including a “1,400% ROI” and a six figure annual cost attributed to a single unnamed team. Those figures are gone, along with the sections built on top of them. What remains is the part that was true.

“We can’t spare you for three days. Too much to deliver this sprint.”

That sentence is almost always said in good faith. The lead developer saying it is not being careless with anyone’s career; they are protecting a commitment they have already made, with a team that is already stretched, to a stakeholder who will notice if the sprint slips. Given what is in front of them, it is a reasonable thing to say.

It is also a technical decision, and it gets filed as an administrative one. Nobody records it in an architecture decision record. Nobody revisits it when the consequences show up, because by then the consequences look like something else entirely: a difficult bug, a slow quarter, a resignation. The decision and its results never appear on the same page, which is precisely why the decision keeps getting made.

The bill arrives in a different quarter

A team spends three weeks chasing a failure in a distributed system. Complaints are mounting, leadership is asking for hourly updates, and people are working weekends. When they finally corner it, the cause turns out to be a well documented race condition; the kind of thing that had been the subject of a conference talk six months earlier. Sarah had asked to attend that conference and had been told the sprint could not spare her. (Sarah is an invented example, though a representative one. I have had some version of this conversation more times than I would like.)

Three weeks of developer time were booked against the incident. The training request was closed as declined, some months earlier, in a different system, by a person who was not thinking about race conditions at the time. The two entries have never met.

This is the part that makes the problem so persistent. The cost is real and it is large, but it is incurred in a different quarter, recorded in a different place, and attributed to a different cause. Everyone involved can look at their own numbers and conclude they made the right call.

Standing still is not neutral

There is a comfortable assumption underneath the decision to defer learning: that a team which does not learn this quarter simply stays where it is, and can catch up later when things are calmer. That assumption is wrong, and the platforms your team works on will tell you so in writing.

Microsoft publishes a major version of .NET every November. Long term support releases are supported for three years; standard term support releases get two. At the time of writing, .NET 8 and .NET 9 both leave support on 10 November 2026, which means a team on either one has a date in the calendar whether or not anyone has booked a course. Every major ecosystem works like this. The ground moves on a published schedule, and a team that stands still is not holding position; it is drifting backwards at a rate someone else has already documented.

I have been the person brought in after several years of that drift. I charge £2,000 a day to teach teams things they could have picked up far more cheaply and far earlier, and they pay it, because by the time I am in the room the cheaper options have expired. For comparison, a conference pass at NDC London currently starts at £1,050 plus value added tax, so a little over £1,260; a decent online course is a few hundred pounds. The expensive option is the one you end up with by default.

The part you cannot put on a business case

Years ago I was working at a software development agency when a colleague found what looked like a bug in a closed source library we depended on. There was no public bug tracker, no community forum, and no support channel that reached anybody who could actually change the code. We had a fault in production, in software we could not read, maintained by people we had no way to contact.

I remembered meeting someone at a conference who had given a talk about that exact library. One message on LinkedIn later, they had put me in touch with the library’s lead developer, the person who had written the code.

Within a few hours we had confirmed it was a genuine bug, and one they had not known about. By the end of the day they had sent us a patched build to test. We confirmed the fix the following morning. Within a week it had gone out through their normal update channels to every user of that library, most of whom never knew there had been anything to fix.

Nothing about that was on the conference agenda. There was no talk called “how to reach the maintainer of a closed source library in an emergency”, and if there had been, I would probably have gone to something else. The ticket bought a room; the room bought a conversation over coffee; the conversation bought a name that was still useful years later. The four years I spent in Microsoft’s Most Valuable Professional programme worked much the same way: the award mattered considerably less than the fact that it kept putting me in rooms with people I could ask things.

The hallway track, then, is a slow accumulation of people who will answer a message when you are stuck.

Why the spreadsheet is the wrong instrument

The obvious response to all of this is to build the business case. Ticket, travel, and three days of salary on one side; prevented incidents, avoided rework, and retained staff on the other. I have built that spreadsheet. The version of this post I published in 2025 contained one, and it claimed a return of 1,400%.

The trouble is that every figure on the return side is a guess about something that did not happen. You cannot count the outage you did not have, or price the rewrite you avoided, because there is no version of the year in which you can check. So the numbers get invented, and they get invented generously, because the person building the case has already decided what the answer should be.

A business case built that way survives exactly one serious challenge. The first finance director who asks where the half million pound figure came from will get an answer that does not hold, and the argument will not recover; worse, the sound argument underneath it goes down at the same time, because it has been contaminated by association. This is the same failure as the engineering dashboard that reports a number because it is easy to count rather than because it means anything, which I have written about in the context of what boards get shown.

The honest position is narrower and much harder to argue with. Conference attendance produces returns that are real, occasionally very large, and genuinely impossible to forecast. That is an uncomfortable thing to take to a budget meeting. It is also true, and it has the advantage of still being true after somebody checks.

The retention argument, honestly sized

There is a second argument I used to make with more confidence than it deserved: that developers leave when you stop investing in them, and that each departure costs you tens of thousands of pounds. I put a figure on it in the original version of this post. I have taken it out, because when I went looking for evidence, the best available source did not support the claim at the strength I was making it.

Stack Overflow’s 2025 developer survey asked what contributes to job satisfaction. The top three answers were autonomy and trust over their own work, competitive pay and benefits, and solving real world problems. Training and development do not appear in that group at all. If you deny a conference request and your developer resigns a fortnight later, the survey suggests the conference was probably not the whole story.

What the survey does show is that job stability and career growth, working with new technologies, and developing specialised expertise all sit inside the top ten. A learning budget of zero touches all three of those. It is also, unlike pay bands and company strategy, something a lead developer can change within a quarter. That is a more modest claim than the one I used to make, and it is the one I can defend.

The compounding effect is real regardless of retention. When a developer comes back from a conference and shows the rest of the team what they saw, the cost stays fixed while the benefit spreads across everyone in the room. Emma comes back from a container conference, runs a lunchtime session, and eight people stop making a mistake they were all about to make. (Emma, like Sarah, is representative rather than real.) That is the argument for treating learning as something the team does rather than something individuals request.

About those sprint commitments

The objection I hear most often is the one I opened with, and it deserves a straight answer. Sprint commitments are real, the stakeholder waiting on the feature is real, and three days out of a two week sprint is a substantial proportion of the available time. Pretending otherwise helps nobody.

But consider what those commitments are actually costing. A team that is unaware of the framework feature which would replace several hundred lines of their own code will write and then maintain those lines forever. A team that has never seen a particular debugging technique will keep spending days on problems that technique finds in minutes. The sprint is not being protected by the decision to skip learning; it is being paid for out of every subsequent sprint, at a rate nobody is measuring.

The old line about being too busy rowing to stop and fix the holes in the boat is worn out from overuse, but it survives because the situation it describes is extremely common and genuinely difficult to escape from the inside.

Budget it, do not approve it

Stop approving learning and start budgeting it.

An approval happens under pressure, in the middle of a sprint, when the request lands in front of someone who is already behind. In that context the honest answer is nearly always no, and it will be no again next quarter, because the conditions that produced the no are permanent. An allocation happens in advance, in a planning meeting, when nothing is on fire. A learning budget assigns days and money per person at the start of the year, sprint capacity is planned around them, and when the request arrives the decision has already been taken by a calmer version of the same people.

That changes what the conversation with your own manager looks like. You are not asking for an exception to the budget; you are asking for a line in it, and you can be honest about what it buys. Some of it buys specific skills you can name. Some of it buys relationships and awareness whose value you cannot predict in advance and should not pretend to. Most senior people have been in the industry long enough to recognise the second kind when it is described plainly, and they are considerably more likely to trust the request that admits it than the one carrying a suspiciously precise percentage.

The same logic applies inside the team, which is where a regular, low ceremony forum for sharing what people have learned earns its place; I have written separately about communities of practice and why most of them fail.

The ticket is the cheapest part

The next time a developer asks to go to a conference, the question worth asking is not whether this sprint can spare them. It is whether you would rather buy the ticket now or the consultant later, because in my experience those are frequently the same decision separated by about three years.

The ticket costs four figures. The three weeks chasing a documented failure mode cost considerably more than that, and nobody ever files them under training.

If you’d like to build a genuine culture of learning and continuous improvement in your engineering team, that’s a conversation worth having. Let’s talk.