What is Resume-driven development?
Engineering culture
Resume-driven development is a pejorative term for choosing technologies, architecture or projects mainly because they look impressive on a resume, rather than because they fit the job well. It is a contested phrase. Sometimes it names a real pattern of fashionable overreach. Sometimes it is used too loosely to dismiss legitimate learning or strategic experimentation. The useful core idea is simple: technology choices should serve the work first, while still leaving room for engineers to grow.
What this means
Software people do not build in a vacuum. They also build careers. That tension is where the phrase comes from. If a team picks a new language, framework or architecture because it genuinely fits the product, great. If the real driver is "this will look brilliant on my CV", eyebrows go up. That is the folk meaning of resume-driven development, often shortened to RDD.
The term became common because many engineers have seen the same pattern. A fairly ordinary system suddenly gets a dramatic rewrite. A modest app acquires microservices, event streams, service mesh, three databases and a bespoke platform. The official story is usually ambitious. The private suspicion is less flattering.
Still, the phrase needs careful handling. Engineers are right to care about employability, and learning new tools is part of the job. So the question is not "Are we using something new?" The better question is "Why this, here, now, with this team, and at this cost?"
Why it matters
This term matters because technology choices echo for years. A flashy bet can change hiring, support, security, onboarding, vendor risk and operational burden. If the choice was made mainly to polish a team's market image, the bill is often paid by the next wave of engineers and by the business teams depending on the software.
The phrase also highlights something wider than one engineer's vanity. More recent discussion treats it as a loop. Hiring managers stuff job adverts with trendy terms because they think applicants expect them. Applicants chase those same terms because they think employers reward them. Both sides then reinforce a market where fashionable technology looks more valuable than it really is in day to day engineering. In that sense, RDD can be systemic rather than purely personal.
For leaders, the term is useful because it gives a name to a familiar smell. You hear a proposal and it sounds oddly disconnected from the actual constraints. The product is small. The support team is thin. The delivery timeline is tight. Yet the plan somehow starts with the most fashionable stack on the conference circuit. Being able to name that pattern, gently and fairly, is better than grumbling about "over engineering" in general.
It also matters for morale. Engineers do need growth. If every practical choice quietly makes them less employable or leaves them stuck on unchanging tools, the business creates its own incentive for RDD. So this is not a sermon about boringness. It is about being deliberate. Good teams create room for learning without letting every learning goal hijack core architecture.
How it works
Where the term came from
The phrase emerged from developer folklore and satirical manifesto style writing. That origin matters because it explains the tone. The term was never meant to sound neutral. It was coined to mock a pattern where technical ambition becomes oddly aligned with personal signalling.
Over time, the phrase broadened. It now covers not just individual decisions but a feedback loop between applicants, hiring teams and technology fashion. That broader view is useful because some questionable choices are encouraged by market pressures, not just ego.
How the loop forms
Start with hiring. A company wants to look current and attractive, so it names the latest frameworks and platforms in a job ad. Candidates read that and conclude they need visible experience in those tools. Once inside a company, they naturally prefer projects that let them collect that experience. Managers notice the preference and adjust future ads again. Fashion travels in a circle.
This does not mean nobody believes in the tools they advocate. Often they do. The problem is weighting. A team may be judging the career signal far more heavily than the maintenance, staffing and operating cost.
How it shows up in real technical choices
RDD often appears in architectural jumps rather than small tool changes. A straightforward app is split into microservices before the organisation has deployment automation, good observability or clear service boundaries. A successful but plain stack gets rewritten into a new language with little product pressure. A platform team introduces a sophisticated workflow that only a handful of enthusiasts can understand.
This is why RDD is frequently mentioned alongside microservice cautionary tales. Distributed systems add real operational weight. If the organisation does not have the prerequisites, the extra moving parts can slow everybody down. A fashionable architecture can look senior and impressive while making the daily job much harder.
What healthy learning looks like instead
Critiquing RDD does not mean freezing the stack forever. Teams need experimentation. They need to modernise, learn and replace dead ends. The healthier pattern is to separate learning from core architecture where possible. Run a time boxed spike. Use an internal tool as a test bed. Introduce one new component at the edge, not a full rewrite at the centre. Create explicit training time instead of smuggling career development into production critical decisions.
Another healthy pattern is "choose boring technology" as a default and make deliberate exceptions. "Boring" here does not mean ancient or joyless. It means well understood enough that the team can operate it confidently. That baseline is especially valuable if your product is still finding its shape. A stable stack leaves more attention for users, delivery and reliability.
Why the accusation can be unfair
Like many bits of software folklore, the phrase can become a cheap insult. Sometimes a legitimate proposal gets dismissed as RDD simply because it is unfamiliar to the reviewer. Sometimes an engineer is asking for needed modernisation, but a risk averse culture calls it vanity. Sometimes leaders underpay, undertrain and underinvest, then act surprised when staff care about marketable skills.
So the term is best used as a diagnostic prompt, not a verdict. Ask what problem is being solved. Ask what capabilities the team already has. Ask what future burden this introduces. Ask what would happen if the shiny bit were removed from the slide. If the proposal still makes sense, it is probably not RDD.
How it links to other culture terms
RDD often has a cousin relationship with the 10x engineer myth. One glorifies the rare hero. The other glorifies the conspicuous stack. Put them together and you get a powerful failure mode, the belief that exceptional people prove their worth through exceptional complexity.
It also overlaps with yak shaving. Teams can start with a small, arguable technology upgrade, then wander into months of adapters, platform work, migration scripts and side quests. The final stack may look impressive, but nobody can remember how the detour got so long.
Examples
A small product with one web app and one database is working adequately, but developers are bored and job ads in the market are full of distributed systems buzzwords. A proposal appears to split the app into a set of services, add asynchronous messaging and introduce a new operations layer. The product does not need that complexity yet, and the team does not have strong deployment or tracing practice. This is classic RDD territory.
A platform group wants to standardise front end work and proposes a new framework. This could be healthy or unhealthy. It is healthy if the current setup is painful, staffing supports the move, migration is staged, and the new choice reduces long term confusion. It is unhealthy if the strongest argument is that the team will look more modern to future employers.
A more subtle case happens in hiring. Managers keep adding trendy terms to job adverts because they fear the company looks dated. Engineers inside the company then feel pressure to push those same technologies into live work just to stay aligned with the market image the company itself created. Nobody intended to start an RDD loop, but the loop is real all the same.
Common misunderstandings
One misunderstanding is that any use of new technology must be RDD. That would make progress impossible. The question is fit, not novelty. Many worthwhile advances were once new.
Another is that only junior engineers do this. In reality, senior staff can drive it just as easily, sometimes with more confidence and more persuasive language.
A third is that the phrase blames only developers. Hiring teams, leaders, conference culture and industry fashion all help create the incentives. RDD is often shared, not solo.
Some people hear "choose boring technology" and assume it means tolerate stagnation. It does not. It means be honest about operating cost and adoption capacity before promoting excitement to architecture.
Finally, some teams think the answer is simply to ban career thinking from technical work. That misses the human problem. People reasonably want to stay employable. Healthy organisations acknowledge that openly instead of pretending it does not exist.
Risks and boundaries
The obvious risk is complexity that nobody asked for. Extra languages, frameworks and moving parts can increase training cost, support work and incident burden. It also makes it harder to hire for depth because every role now expects a shopping list of very specific tools.
A subtler risk is strategic drift. Teams can begin optimising for what looks prestigious rather than what makes the product easier to evolve. That slows real learning because the organisation spends so much energy keeping fashionable machinery alive.
But there is a boundary to the critique. Calling something RDD can become its own lazy move. It can shut down experimentation, reinforce gatekeeping and protect incumbents who prefer familiar tools for comfort rather than merit. A company can be too fashion driven, but it can also be too fearful.
The good version of the idea is a spur to clearer thinking. The bad version is a sneer aimed at anyone proposing change. Useful teams challenge the motive without mocking the person.
What to do next
Create a lightweight technology decision process. It does not need to be grand. A one page template can be enough: what problem are we addressing, why this option, what does it cost to run, what skills do we already have, what would a simpler option look like, and how will we reverse course if needed. That one habit catches a surprising amount of fashion driven drift.
Separate learning from production critical architecture. Give engineers explicit room to build skills through spikes, prototypes, internal tools, rotation or funded training. When career growth has a proper home, it is less likely to hijack customer facing systems.
Clean up hiring signals. Review job adverts and internal ladders. If you praise only trend chasing, do not be shocked when people behave accordingly. Reward maintenance, reliability, teaching and sound judgement as visibly as greenfield novelty.
Finally, use plain language in review meetings. Ask, "Is this for the product, the team, or the CV?" without turning it into a public shaming ritual. Often the honest answer is "some of all three". That is fine. The point is to choose deliberately. Good engineering culture does not deny ambition. It steers ambition so the work remains understandable, supportable and worth inheriting.
FAQs
Is resume-driven development the same as over engineering?
They overlap, but they are not identical. Over engineering can come from caution, perfectionism or misunderstanding. RDD specifically points to career signalling as a likely driver.
Is it wrong for engineers to care about their resumes?
No. That is normal and rational. The problem starts when production choices are driven mainly by signalling rather than fit.
Can a new technology still be the right call?
Yes. If it fits the problem, the team can support it, and the trade is explicit, the decision may be entirely sound.
Why is microservices talk often linked to RDD?
Because microservices carry visible prestige and real complexity. They can be an excellent fit in the right setting, but they are also an easy badge to chase too early.
What is a safer way to try something new?
Use a small, reversible experiment. Try an edge component, an internal tool, or a time boxed prototype before betting the whole product on it.
Who is responsible for RDD?
Usually more than one party. Engineers, managers, recruiters and industry fashion can all contribute.
How does this connect to the 10x engineer myth?
Both terms can reward conspicuous individual signalling over shared, sustainable team performance.
How does this connect to yak shaving?
A fashionable rewrite can trigger a long chain of migrations, adapters and platform chores that consume months before users see much benefit.
Sources
Resume Driven Development, A Definition and Empirical Characterization (arXiv). empirical definition, theory and consequences