Manchester is a dev skills bubble just now, no doubt about that.
In the 7 years I have been here the top level advertised salary for a senior C# dev has risen from about £35-40k to about £60-£70k. Obviously some of those are speculative CV-harvesting operations, but from discussions I have had there are clearly a lot more jobs around, and better paid ones at that.
While that is great news for me as a seller of technical skills, it also presents some challenges as someone who leads other people to deliver the work that I have to. How so? Well, when I was recruiting developers in my Manchester role in 2012 we could be a bit choosy about how often a candidate switched jobs. We could worry that she or he may not stay long enough to get to speed and earn their salary. In fact in my second role we anticipated that, given the complexity of the system, if someone was fully effective in six months that was a good result.
The problem is that in today's hot market good devs can be tempted away after not so long in a role. They can afford to be fickle. Because other employers are so (let's not say "desparate") "keen" to fill vacancies, people can leave after a relatively short time in their current role. If we want to fill empty seats we cannot be as choosy as once we (or at least my then-manager and I) were.
The flip-side is that as a purchaser of skills I cannot afford to let someone take 12 months to earn their salary, as if they leave within two years (which seems about a 20%-33% chance at the moment) then we will not have covered our costs.
The only way to mitigate this is to structure systems more simply.
Sure, we've always wanted to do that haven't we?
Yes, but to add to the message pressing for this: ease of maintenance, ability to rotate staff through, easier debugging, we now need to add the economic reality that if we can't get staff up to speed quickly then we're going to risk losing money on employing them.
So more than ever the classic messages of decoupled architectures and TDD have a key role to play to onboarding team members and getting them productive.
In my first .net role in 2006 it was six weeks before I worked on code that made it into the Production release. This week a new starter (with 2.5 years in the industry) had written code (and unit tests) which was in Prod by the end of his second day. The level of test coverage gives confidence that the change is safe and the new starter can start to earn their salary straight away.
While succession planning helps to mitigate the impact of the departures and compnay culture should help to prevent, structuring the code so that devs are productive from the get-go is crucial.