Avoiding Resume-Driven Development

Resume-driven development is choosing technology because it will look good on a CV or conference talk rather than because it solves the problem best. It is rarely cynical. Engineers want to learn, markets reward fashionable skills, and every new tool arrives with a convincing blog post. The result is systems that are more complex than their problems justify.

What it looks like

Typical symptoms:

• A team of eight runs a microservice architecture with forty services for an application with two thousand users.
• A relational workload with simple queries moves to a graph or document database because it is interesting.
• Kubernetes, a service mesh, and an event-sourcing framework are adopted before the first customer.
• Proposals justify themselves with what other companies use rather than with the team's requirements.

Contrast two proposals for the same problem:

| Proposal A | Proposal B | |-----------|------------| | "Netflix uses this, so should we." | "We need 200 requests per second with 99.9 percent availability." | | Learns tool while building product | Chooses tool matching team skills and load | | Operations cost unknown | On-call and upgrade cost estimated |

Why it is costly

New technology carries hidden costs: operational learning, immature tooling, hiring difficulty, and bus factor. When the champion leaves for a better job, the team inherits a system nobody understands. Complexity is paid for on every feature, every incident, and every onboarding, long after the excitement fades.

Be fair to novelty

The opposite failure exists too. Refusing all new technology leaves teams with unmaintained stacks and a dwindling hiring pool. Engineers need growth, and some new tools are genuinely better. The aim is not to ban novelty but to make it deliberate, bounded, and justified.

Tests to apply to a proposal

Ask these questions in design reviews:

1. What specific requirement does this meet that our current stack cannot?
2. What is the simplest option that works, and why is it insufficient?
3. Who on the team has run this in production?
4. What is the operational cost: monitoring, upgrades, security patching, on-call?
5. What happens if we must remove it in two years?
6. Would we choose it if nobody outside the company knew?

If the answers are vague, the proposal is probably driven by interest rather than need.

Adopt boring technology on purpose

Dan McKinley's "innovation tokens" idea is useful: assume a team can afford only a few unfamiliar technologies at a time. Spend them where they create real advantage, and use proven tools everywhere else.

Innovation budget: 2 tokens
Spent: 1 on a new vector search engine (core to product differentiation)
Reserved: 1 for next year
Everything else: Postgres, a mainstream language, managed cloud services

This turns an emotional debate into a resource allocation question.

Give curiosity a safe outlet

People pursue exciting technology partly because their job offers no other route to learn. Provide that route:

• Time-boxed spikes and hack weeks that do not touch production.
• Internal talks and reading groups.
• Rotations onto genuinely hard problems.
• Career ladders that reward impact and simplicity, not tool breadth.

When engineers can grow without compromising the product, the pressure behind resume-driven choices eases.

Model the behavior as an architect

Say aloud when you choose the simple option and why. Celebrate deleting a component. Ask for the problem statement before discussing tools. Share your own past regrets with over-engineering. Teams copy what leaders reward.

Key takeaways

• Technology choices should trace to a stated requirement, not trends or career value.
• Hidden costs of novelty appear in operations, hiring, and bus factor.
• Use a checklist in reviews, including whether the simple option works.
• Budget a small number of innovation tokens and spend them where they matter.
• Provide safe outlets for learning so production is not the experiment.