When someone first mentioned the term CV-driven development to me, I remember finding it both extremely apt and equally funny. The concept describes the propensity of software professionals to select a tool not only by its ability to do the job but by its effect on the engineer’s career prospects. Indeed, some risky bets on emerging technologies observed in the field do suggest that featuring a technology on someone’s CV can be part of the motivation.
Now, years since I first heard the term I am starting to think that there’s more to this concept than I first thought.

The job market of today is quite different from the market a couple of decades ago. Gone are the days in which you spend a 40 years career with the same employer. In technology, the average annual turnover is around 13% which translates to an expected tenure of about seven and a half years.
This makes it obvious, why an engineer would consider their CV when making technology decisions: They know that sooner or later they will be back on the market. Having up-to-date skills is an engineer’s most valuable asset and having a nice-looking CV is an insurance policy against any storm which can shuffle around an organization at any moment.
Furthermore, even if the technology decision is risky and may cause problems down the road, chances are that the engineers originally responsible for the decision will no longer be around when problems start to emerge. To be clear, I don’t know anyone cynical enough to explicitly make decisions based on this calculus. I do, however, think that the constant rotation which is part of our modern work culture can have a subconscious effect.
What was less clear to me, however, is why companies would support this practice. A cynical mind might say that usually the management layers that could stop this from happening are too far out of touch with the technical realities of their projects and simply cannot tell when it occurs. You could also argue that they should not intervene as that would be micromanagement, raising the question, who at an organization really represents the technical long-term interest.
While these points might play a role, I think that there is something else going on: I think that organizations are at least partly aware of this dynamic and they accept it. This is because modern organizations know and expect that employees will move on sooner or later and the CV-value of your relationship can be considered as a part of the overall compensation package.
This seems consistent with the observation that small startup companies that may not yet have the cash to compete with the big players in terms of salary also turn out to allow riskier technology bets than large, established companies. It becomes part of their value proposition to attract talent: “While you are passing through, why not make an educational stop at our shop to pick up some new skills?”
If we take this line of thinking to its logical conclusion, maybe “the best tool for the job” was an insufficient metric all along. The honest approach might just be to explicitly include the educational value of a technology choice in the list of criteria and to make the career concerns of the engineers involved in the project part of the discussion.
Interesting finding. Curious how a company should then find the balance (between too much new/cutting edge vs. proper learning paths for collaborators). Seems like an architects job to add “discovering/evaluating new tech” as part of the trade-off. Maybe things like a tech radars can help guide what is acceptable risk there and what is too far out …
Good question, Peter! That would indeed be the logical follow-up. There is also a risk management aspect involved, I guess.
At least if the discussion is out in the open rather than happening implicitly, such a trade-off can be arrived at through an open conversation.