You Never Needed a Fad to Invest in Your People

13 min read

Permission Granted by Slide Deck

The pattern is always the same. A consulting firm publishes a report. A competitor announces something. A board member attends a conference and returns alarmed. Suddenly a budget appears. Suddenly change is urgent. Suddenly people deserve support.

Nobody asked for it before that moment. Not because it was unnecessary. Because the organization spent years training entrepreneurship out of its own people. Initiative gets punished, ignored, or quietly absorbed into someone else’s credit. After enough repetitions, even strong developers stop proposing anything. They do the ticket. They go home. The culture wants wage compliance and gets it — then wonders why nothing improves without external intervention.

The vocabulary is usually already in the room. Developers have heard of TDD. They know continuous integration exists. They know pair programming is a thing. They never practiced any of it because nobody created the conditions, set the expectation, or signaled that ownership was welcome. Whether the company employs five thousand developers or five, the pattern is identical. The senior developer who might say “we should be doing X” learned long ago that saying it changes nothing except their own reputation for being difficult.

Then someone external arrives — a coach, a consultant, a framework evangelist — and within weeks the same people are writing tests, running pipelines, and delivering with flow. The knowledge did not come from outside. The permission did.

That is what makes the fad dependency so revealing. The people were always capable. Leadership never made the space. Then a brand name gives political cover and everyone pretends the need is new.

The Fad Dependency Cycle

It works like this. An industry movement gains traction. Vendors and consultancies spot the wave. They produce certifications, maturity models, and benchmark reports. Those reports create enough fear to move budget committees. Suddenly the organization can invest in things like mentoring, tooling, developer experience, or collaboration practices — but only under the banner of the new framework.

The moment the fad fades, the support evaporates. Nothing about the underlying need changed. The developers still need learning time, better tools, reasonable team sizes, and technical authority. But the political cover is gone, so the investment dies.

This is not accidental. It reveals how many organizations relate to their own technical workforce. They do not invest because it is obviously needed. They invest because an external authority made it socially safe to invest. That is a governance failure dressed as strategic patience.

And between fads, leadership does not actively search for help either. They do not open LinkedIn and read what practitioners write about modern development. They do not attend meetups where actual developers talk about what works. They do not research how other organizations solved similar problems. They do not call experienced specialists and ask questions. They do none of the homework a responsible owner would do before making a significant operational decision.

What they do instead is delegate. They tell HR to hire someone for X. They issue an RFP. They ask Gartner what the Magic Quadrant says. They wait for a vendor to pitch them. They attend an executive conference and hope a keynote tells them what to do next. The pattern is always passive reception of packaged answers rather than active investigation of their own situation.

That passivity is how the hiring filter does its damage. Leadership does not understand what good looks like, so they cannot describe it. HR receives a vague brief full of keywords, builds a filter that rewards keyword symmetry, and screens out exactly the people who could have helped. The talent shortage that follows is really a filter failure — but leadership never sees it because they never participated in the search with enough understanding to notice what went missing.

Governance means owning the conditions that allow good work Publishes on July 6, 2026. Come back then. — not waiting for a consultancy to explain what good work looks like.

The Drivers Are Political, Not Rational

The fad dependency is not caused by ignorance alone. It is sustained by organizational politics.

In most companies, the people who build software sit in a box labeled IT. That label is not neutral. It means support function. It means cost center. It means the people in that box do not set direction — they receive tickets. Their judgment is not consulted when strategy gets formed. Their objections are not recorded when a vendor promise contradicts reality. Their warnings do not reach the room where the budget decision happens.

That arrangement is political. Someone decided, probably decades ago, that software is infrastructure rather than product. That it is maintenance rather than creation. That the people doing it are interchangeable service providers rather than specialists whose knowledge shapes what the company can even attempt.

Once that political classification is in place, everything follows. Developers cannot get budget without a framework because their domain is not recognized as strategic. They cannot push back on unrealistic deadlines because support functions do not get to challenge the business. They cannot refuse harmful architecture decisions because cost centers do not have authority. They can only receive instructions and be blamed when the result is poor.

The fad changes that temporarily — not because it fixes the political structure, but because it briefly elevates the conversation to a level where budget committees pay attention. Then the fad passes. The political classification reasserts itself. Developers go back to being IT.

The Primadonna Myth and What It Hides

There is a word that comes up reliably when senior leadership discusses software developers who push back, ask questions, or refuse to pretend a bad plan will work. Primadonnas. Difficult. Not team players.

This label performs useful political work. It reframes legitimate professional objection as personal deficiency. The developer who says this deadline is unrealistic becomes someone with an attitude problem. The architect who says this vendor product cannot do what sales promised becomes difficult to work with. The senior specialist who says the team needs three months of focused refactoring before any new feature will ship safely becomes someone who does not understand the business.

None of these objections are primadonna behavior. They are the normal output of competent professionals who understand the material they work with. A structural engineer who says the foundation cannot support another floor is not a primadonna. A surgeon who says the patient needs a different procedure is not being difficult. But software developers who exercise the same professional judgment get a different label — because the organization has already decided their domain is a support function and support functions do not get to say no.

The deeper irony is that experienced developers typically know more about the business domain than the decision-makers allow themselves to believe. They see how the rules actually execute. They see where the data contradicts the narrative. They see which customer workflows actually happen versus which ones the product manager imagined. They see where the organization’s own processes break down every single day because they are the ones whose code has to handle the exceptions.

That knowledge rarely travels upward. Not because developers cannot communicate it. Because nobody in a position of authority asks. The political structure says: you are IT. You implement. You do not analyze, advise, or challenge.

Strangers Cannot Create Your Breakthrough

There is a recurring fantasy in organizations that struggle with software delivery. It goes like this: we will assemble a new team from external specialists, give them the requirements, and they will build something extraordinary.

It almost never works that way.

Building a product that matters requires accumulated context. It requires understanding what has been tried before. It requires knowing where the political landmines are, which customer segments actually pay, which technical decisions were made under pressure and should be revisited, and which ones were made carefully and should be preserved.

A group of strangers does not have that context. They cannot develop it in a two-week onboarding. And the organization typically does not even know how to transfer that context because it lives in the heads of the people who have been there — the same people whose opinions were never elevated to strategy conversations.

Here is what makes the fantasy especially expensive. The people already inside the company — the developers dismissed as IT, the ones who maintained the existing systems — often hold more operational domain knowledge than anyone else in the building. They know which business rules are real and which ones are folklore. They know which integrations actually work and which ones fail silently. They know which customer segments generate edge cases that no specification ever captured. But the organization treated them as implementers, so it never occurred to anyone to include them in product strategy. Instead, leadership hires strangers and wonders why the breakthrough never arrives.

What you actually need is an environment where skilled people who understand the domain can do sustained, focused work with real authority over technical decisions. That has nothing to do with a framework. It has everything to do with treating developers with respect and giving them room to exercise judgment.

The Diploma Illusion

There is a persistent confusion between education and capability in software. Someone finishes a computer science degree and the organization assumes they can build products. They cannot. Not yet. Not without years of mentored practice, painful failures, production incidents, deployment nightmares, and the slow accumulation of systems sense.

A degree teaches theory. Some of that theory is genuinely useful. Much of it has little relationship to the daily work of building, operating, and evolving production systems that actual humans rely on.

The gap between graduation and competence is enormous. And yet many organizations structure their hiring as if the degree were the qualifying credential rather than the starting line. They hire fresh graduates, give them no mentoring worth the name, surround them with other people who also have no production experience, and then act surprised when the resulting software is fragile, expensive, and perpetually late.

The people who could mentor them — developers with fifteen, twenty, thirty years of experience building real systems — are often nowhere nearby. Not because they do not exist. Because the hiring filter screened them out before any human conversation happened.

The Hiring Filter Screens Out Mastery

This is the part that should alarm executives most. Companies complain about a talent shortage while actively filtering out the strongest available candidates.

A developer with twenty-five years of building production systems across multiple industries, multiple technology stacks, and multiple organizational contexts does not look like the clean keyword match your Applicant Tracking System wants. They have not spent five consecutive years in your exact framework because they were busy solving harder problems in different environments. Their resume shows movement because experts get called when something is broken, not when everything is comfortable.

Your filter reads that as instability. The market reads it as a track record.

Staff augmentation misses the same people for the same structural reason. The procurement model rewards sameness, keyword overlap, and frictionless insertion. It punishes depth, range, and the kind of judgment that only develops through varied practice.

Meanwhile the organization hires someone who passes the ATS filter, ticks every framework checkbox, and has never once had to fix a system they did not build, recover from a deployment gone wrong, or tell a product owner that the requirement contradicts reality. That person passes procurement. They do not pass production.

AI Is Not the Problem. It Is the Amplifier.

The current reflex is to blame AI for making developers unnecessary. That narrative is comfortable for executives who already wanted development to be cheaper. It is also wrong.

AI makes great developers dangerous — in the best sense. A developer with deep systems understanding, decades of pattern recognition, and genuine craft mastery can now move at a speed that used to require a small team. AI handles the boilerplate, the syntax lookup, the scaffolding, the first-draft refactoring. What remains is the judgment work. And that is exactly where experienced developers excel.

For someone without that depth, AI is equally accelerating — straight toward a more sophisticated mess. The tool does not distinguish between a good architectural decision and a terrible one. It will happily generate thousands of lines of confidently wrong code if nobody with real understanding is steering.

This means the gap between a strong developer with AI and a weak developer with AI is not shrinking. It is growing. Explosively. The master of the craft who your filter rejected three months ago would now deliver more value than the entire team of ATS-approved keyword matches you hired instead.

And the tragedy is visible from the outside. Companies in desperate need of exactly that kind of experienced judgment are looking the other way because the management conversation has been captured by two false narratives simultaneously: the talent shortage story that excuses the broken filter, and the AI-replaces-developers story that excuses not investing in human expertise at all.

The Real Question for Leadership

If your organization can only invest in developer experience when a framework makes it fashionable, you have already answered the question about whether you value your people. You do not. You value compliance with whatever the current industry narrative demands.

Real investment looks different. It looks like:

• Funding learning time without requiring a branded program to justify it.
• Letting experienced developers mentor juniors without pretending that is waste.
• Hiring for judgment and range instead of keyword symmetry.
• Giving technical people authority over technical decisions without requiring a transformation initiative to grant it.
• Keeping teams stable long enough to build context instead of rotating through contractors every six months.
• Recognizing that the AI conversation is not about replacing developers but about giving your strongest ones more leverage.
• Dropping the primadonna label and listening when technical people explain why something will not work.
• Stopping the pretense that software is a support function when it is the thing your company actually sells, runs on, or competes through.

None of that requires a framework. None of it requires a certification. None of it requires a maturity model, a consultancy engagement, or a conference keynote to legitimize.

It requires leadership that believes its own people deserve investment as a default condition of employment — not as a reward for surviving the latest organizational fashion cycle. It requires admitting that the political classification of software as IT support was always a convenient fiction that let decision-makers avoid learning what the company actually depends on.

The masters of the craft are out there. Some of them are inside your organization already, underutilized, unheard, and quietly described as difficult because they keep telling you things you do not want to know. Some of them applied last month and your ATS rejected them. Some of them stopped applying to companies like yours because the filter made clear they were not wanted.

AI did not create this problem. It made it more expensive to ignore.