Resume-driven architecture: when career incentives overwrite system needs

The architecture review is for a contact form.

It receives about fifty submissions a day. A customer fills in a name, an email address, a short message, and maybe a file attachment. The business requirement is unremarkable: validate the input, store the submission, notify the right people, and make sure the team can respond before the lead goes cold.

The diagram on the screen is not unremarkable. There is Kubernetes. There is a service mesh. There are four services where one process would do. There is an event bus, even though no downstream consumer exists yet. There is event sourcing, because 'auditability' came up in a meeting. There is a queue, a dead-letter queue, a replay path, a metrics stack, a deployment pipeline for each service, and a local development environment that needs a page of bootstrapping instructions before anybody can send themselves a test message.

Nobody in the room is stupid. That is the uncomfortable part.

The people proposing the design can explain each component. Kubernetes gives scheduling and scaling. A service mesh gives traffic control. Events make integration easier later. Event sourcing preserves history. A queue smooths bursts. Every choice has a plausible defence when considered alone. The architecture only becomes absurd when the system is considered as a whole: a small workflow has been treated as a career portfolio.

This is resume-driven architecture. It is resume-driven development applied at the system boundary, where the consequences outlive the pull request. The team is not merely using a fashionable framework in one module. It is committing the organisation to a topology, an operations model, a hiring profile, a failure surface, and a maintenance cost because the selected technologies have more labour-market gravity than the problem itself.

The easy version of the argument blames vain engineers. It imagines a developer sneaking Kafka into a billing service because it looks good on LinkedIn. That happens, but it is too small an explanation, and I have stopped finding it useful. Resume-driven architecture is rarely just individual self-interest. It is an incentive system. Hiring rewards recognisable keywords. Promotion rewards visible modernisation. Conferences reward novelty. Vendors reward platform adoption. Managers reward proposals that sound strategic. Teams reward engineers who appear to be keeping the stack current.

The boring choice has fewer allies. Nobody gets invited to a panel for saying the form should be a normal web handler, a relational table, and one queue if the mail provider is unreliable. Nobody adds 'did not introduce a distributed system' to a CV bullet. The simple design saves the future, but the future is not represented in the room, and architecture reviews are decided by the people who showed up.

The incentive is rational

Resume-driven architecture begins with a rational observation: technology choices are career signals.

In 2021, Jonas Fritzsch, Marvin Wyrich, Justus Bogner, and Stefan Wagner published an empirical characterisation of resume-driven development. They surveyed 591 software professionals, including people in hiring and technical roles, and found that 60% of hiring professionals agreed that trends influence job offerings, while 82% of software professionals believed that using trending technologies in daily work makes them more attractive to future employers.¹ A 2023 follow-up framed the pattern as a potentially self-sustaining dynamic between hiring demand and applicant behaviour, then argued for more deliberate hiring and applicant practices to resist hype.²

That matters because it turns a moral complaint into a system problem. If employers advertise for the fashionable tool, candidates try to acquire the fashionable tool. If candidates advertise the fashionable tool, employers infer that serious engineers use it. The labour market teaches teams that architectural novelty is not merely technical. It is professional currency, and currency is hard to argue against in a budget meeting.

The Stack Overflow Developer Survey makes the same environment visible from another angle. Its 2023 survey, fielded in May 2023, included 89,184 qualified responses from developers in 185 countries, and devoted large sections to technologies developers had used, admired, desired, or wanted to work with next year.³ Those surveys are useful. Popularity and developer interest are real signals. But they are not requirements documents. A technology being widely desired by developers says something about the market around the technology. It does not say the technology belongs in a particular system.

Teams confuse those layers constantly. A hiring signal becomes an architecture signal. A technology radar becomes a roadmap. A conference theme becomes an internal migration plan. A senior engineer says the organisation should 'invest in cloud native', and suddenly a product with one backend and a predictable load profile is being prepared for an infrastructure model designed for a different class of constraint.

This does not make the engineer cynical. Curiosity is healthy. Learning new tools is part of the job. An engineer who never studies new technology eventually becomes a local expert in yesterday's constraints, which is a different and quieter form of career risk. The issue is not learning. The issue is using production architecture as the learning vehicle without making the cost explicit.

There is a clean way to learn Kubernetes, event sourcing, stream processing, actor systems, service meshes, or any other powerful technology: build a lab, run a side project, pair with a team that already has the problem, prototype against a real requirement, or introduce the tool in a contained boundary where failure is affordable. The dirty way is to smuggle the learning agenda into a product decision and call it future-proofing.

Future-proofing is the favourite disguise of resume-driven architecture. It sounds prudent. It says the system may need to scale later. It says the business may need many integrations later. It says the team may need independent deployments later. All of those statements can be true. The missing question is whether buying that option now is cheaper than buying it later.

Sometimes it is. A compliance platform with immutable audit requirements may be right to design around an event log early. A high-volume data ingestion system may be right to introduce streaming infrastructure before the pain is visible to customers. A multi-team product with independently evolving domains may be right to separate services before all the organisational seams are frozen into one deployable.

But most systems do not start there. They start smaller, messier, and less certain. They need fast feedback more than theoretical scale. They need clear ownership more than distributed autonomy. They need a path to change, not a museum of every architectural pattern a team hopes to learn.

The rational incentive is the trap. A developer who chooses the plain tool may be serving the system well and underserving their CV. A manager who funds the plain tool may be reducing risk and losing the ability to claim transformation. A recruiter who filters for fashionable keywords may be making sourcing easier and making production systems worse at the same time. Everyone can behave reasonably inside their own incentives and still produce unreasonable architecture. That is the part I find genuinely unsettling.

That is also why the fix cannot be 'hire less vain engineers.' It has to be governance, expectation-setting, and an explicit bias toward fit.

Novelty has a maintenance bill

Dan McKinley's 2015 essay 'Choose Boring Technology' remains useful because it names the scarce resource: attention. His innovation-token model is not a law of physics, but it captures a practical truth. A team can only absorb so much novelty before the novelty becomes the work.⁴

Novelty becomes the work quietly. Teams rarely notice the threshold itself, only the part of the year that vanished into operating new things instead of building them.

Every non-boring choice demands a local knowledge economy. Someone must understand it well enough to operate it, debug it, upgrade it, secure it, and teach it. Someone must know the failure modes. Someone must know what 'normal' looks like in production. Someone must know which vendor documentation is relevant, which defaults are unsafe, which dashboards matter, and which warnings can be ignored.

That cost is not paid once. It compounds.

Add a new database and you add backup semantics, query patterns, migration tooling, access control, monitoring, client libraries, connection behaviour, operational failure modes, and a hiring requirement. Add a message broker and you add delivery semantics, retries, ordering assumptions, poison-message handling, consumer lag, replay procedures, local development friction, and a new class of incident. Add a service mesh and you add certificates, proxies, traffic policy, observability integration, performance overhead, debugging indirection, and one more layer that can be almost right.

These costs can be justified. They often are. The problem is that resume-driven architecture discounts them because the benefits are legible now and the costs arrive later — and 'later' has a habit of arriving on the on-call rotation rather than in the architecture review.

In the proposal, the new tool is a capability. In production, it is an obligation. In the architecture review, the system is a clean diagram. In the on-call rotation, it is a cluster of interacting components with partial failures and stale mental models. In the hiring plan, it is an attractive keyword. In the maintenance plan, it is a smaller candidate pool and more onboarding load.

The bill is paid by people who were not in the original meeting. A future maintainer inherits the unfamiliar abstraction. A support engineer has to explain failure states created by an over-designed workflow. A new hire spends their first month learning internal platform rituals instead of the business domain. An on-call engineer discovers that a queue meant to make the system resilient has become the place where failures disappear until they are expensive.

That does not mean the old tool is always better. Boring technology can be bad. A team can hide behind 'boring' to avoid necessary change, preserve obsolete platforms, and punish engineers who can see a genuine constraint. The argument for boring technology is not nostalgia. It is accounting.

The correct question is not 'is this technology modern?' It is 'what problem becomes materially easier, and what new problem becomes ours forever?' A team that can answer both sides may be making an architectural decision. A team that can only answer the first side is shopping.

Resume-driven architecture often wins because it borrows the language of seriousness. It says 'scale' when the risk is not scale. It says 'resilience' when the risk is delivery. It says 'decoupling' when the organisation has not defined ownership. It says 'platform' when the team needs a deployment script. It says 'future-proof' when the future being protected is the engineer's employability rather than the product's option space. I have nodded along in too many of those conversations to feel innocent about them.

The word 'architecture' should make the burden higher, not lower. Architecture is the set of choices that are expensive to change. If a technology choice will be hard to reverse, it should be justified against durable forces: product shape, organisational structure, compliance needs, scale characteristics, failure tolerance, team capacity, and operational maturity. Career value can be a happy side effect. It cannot be the primary requirement.

The microservice premium

Microservices are the canonical example because they can be exactly right and exactly wrong for almost the same reasons.

Martin Fowler described the 'microservice premium' in 2015. His argument was not anti-microservice. It was conditional. Microservices help with certain forms of complexity, but they introduce their own complexity through automated deployment, monitoring, failure handling, eventual consistency, and distributed-system concerns.⁵ His practical guideline was to avoid the style unless the system is too complex to manage as a monolith.

That conditionality is where resume-driven architecture slips. The industry remembers the success cases and forgets the prerequisites. A large company separates services to allow teams to change independently, scale different workloads, and reduce coordination around a huge codebase. A small team copies the shape without the conditions. It gets independent deployables without independent teams, network boundaries without a need for separate scaling, eventual consistency without a product reason, and operational complexity without enough operators. Which, in case the picture is unclear, is the worst of every possible world.

Fowler made the prerequisite point even more directly in 2014: teams considering microservices need baseline capabilities such as rapid provisioning, monitoring, rapid deployment, rollback, and close developer-operations collaboration.⁶ Those are not optional accessories. They are the support beams. Without them, the architecture does not create autonomy. It creates distributed fragility.

Thoughtworks called out 'microservice envy' on its Technology Radar, warning that teams were complicating their architecture with many services because microservices had become fashionable. The Radar's November 2018 entry specifically noted that Kubernetes and vendors made complex microservice deployments easier, while warning that microservices trade development complexity for operational complexity and require automated testing, continuous delivery, and DevOps culture.⁷

That warning has aged well because it describes the failure mode precisely. Tooling lowers the activation energy for a complex architecture. It does not erase the complexity. Managed Kubernetes makes it easier to run a cluster. It does not decide whether the product needed a cluster. A service mesh makes it easier to manage service-to-service traffic. It does not decide whether the organisation needed service-to-service traffic in the first place.

Segment's 2018 reversal is still one of the clearest public case studies, and the kind of post worth sending to anyone proposing a fresh greenfield microservice decomposition. Alexandra Noonan described how Segment consolidated more than 140 services into a single service for a core part of the product after a small team became mired in operational and development complexity. The post says three full-time engineers were spending most of their time keeping the system alive, that small shared-library changes could take days to a week, and that moving to one service improved developer productivity and operational behaviour.⁸

The lesson is not that monoliths are morally superior. Segment's own account is careful about tradeoffs. Fault isolation became harder, and the team still needed strong tests. The lesson is that architectural style is not an identity. A team can move from monolith to microservices when the system's forces demand it, and move back when the forces change or the original decomposition proves mismatched.

Resume-driven architecture has trouble with that humility. It treats the fashionable style as a maturity badge. Microservices become what serious teams do. Kubernetes becomes what serious infrastructure runs. Event sourcing becomes what serious auditability looks like. The architecture becomes a costume for an organisation the team wants to resemble.

This is not limited to microservices. Event sourcing has the same pattern. Fowler's writing on event-driven architecture distinguishes event sourcing as a specific technique where state changes are stored as events and system state can be rebuilt by reprocessing them. He also notes that event sourcing introduces issues such as interactions with outside systems, event schema changes over time, and added application complexity.⁹ Those are reasonable tradeoffs when the domain needs audit history, temporal reconstruction, or retroactive processing. They are waste when the domain is basically CRUD with anxiety.

The dangerous phrase is 'we might need it later.' Later is real. Later matters. But later must be costed. If the architecture for a contact form is designed around hypothetical future replay, the team is not only preserving an option. It is paying storage, modelling, testing, operational, and cognitive rent on that option from day one.

The more honest question is: what would make this architecture obviously necessary? If nobody can name the traffic pattern, compliance requirement, team structure, integration demand, or domain behaviour that justifies the tool, the tool is not architecture. It is aspiration with a build pipeline.

Kubernetes is not the destination

Kubernetes deserves special treatment because it sits at the intersection of genuine utility and enormous career signalling.

It is powerful infrastructure. It solved real problems for organisations that needed a common substrate for scheduling, deployment, scaling, and operating containerised workloads. It helped standardise patterns that used to be bespoke platform engineering. It is not a toy, and dismissing it as hype is lazy.

It is also very easy to adopt for the wrong reason.

Kelsey Hightower's public Kubernetes commentary is useful here precisely because he was an advocate, not a reflexive critic. Coverage of KubeCon 2017 reported him framing success as getting Kubernetes to a place where people could build on it while keeping the core boring.¹⁰ The Linux Foundation's 2018 write-up of his opening keynote said he warned that Kubernetes should be considered a means to an end, not the end game.¹¹

That distinction is the whole point. Kubernetes is infrastructure for delivering product capability. It is not product capability. A platform is successful when it reduces the amount of infrastructure the application team has to think about. If adopting Kubernetes means every developer now has to understand manifests, cluster networking, ingress configuration, rollout behaviour, resource requests, local cluster tooling, and debugging through layers of platform abstraction, the organisation may have bought a platform and delivered a syllabus.

There are teams for whom that syllabus is worth it. There are also teams for whom it is absurd. A small product with one API, one database, one background worker, and predictable traffic may be better served by a simple managed runtime, a boring deployment pipeline, and a runbook everyone can understand. The fact that Kubernetes expertise is valuable in the labour market does not make Kubernetes valuable in that system.

The same career signal can distort management decisions. Leaders want to hire and retain ambitious engineers. Ambitious engineers want to work with modern infrastructure. Job ads with modern infrastructure attract more applicants. Vendor presentations make the platform feel inevitable. The organisation starts believing it must adopt the tool to be credible, and credibility becomes confused with fitness. It is one of the more elegant traps in our industry; nobody opens the door and yet everybody walks through it.

There is a version of this argument that becomes anti-learning. That is not the point. Engineers should learn Kubernetes. Organisations with platform ambitions should build Kubernetes capability deliberately. But learning should be named as learning. If a team is adopting a tool partly to grow skill, the proposal should say so. It should identify the training cost, the support model, the rollback path, and the boundary where the experiment stops if it fails to serve the product.

Unacknowledged learning is expensive because it hides risk. A proof of concept becomes production. The person who understood the tool leaves. The team discovers that the managed service still requires operational judgement. The platform becomes normal before it becomes understood. Then the organisation cannot tell whether it is using Kubernetes because Kubernetes solves the problem or because every subsequent decision now assumes Kubernetes exists.

That is how architecture becomes a ratchet. Once enough services, pipelines, dashboards, secrets, and deployment rituals are built around a technology, the decision is no longer debated as a choice. It becomes the local weather. New work inherits it. New hires learn it. Product estimates include it. Incidents route through it. The original career-driven impulse disappears into infrastructure, and the organisation calls the result standardisation.

Standardisation is only good when the standard is good for the work.

Boring is not cowardice

The strongest objection to this argument is that boring choices can become a prison. Teams use 'simplicity' to excuse underinvestment. They keep ancient frameworks because nobody wants to own the migration. They reject useful tools because learning them would disturb local comfort. They turn 'we do not need Kubernetes' into 'we do not need deployment discipline.' They turn 'a monolith is fine' into 'module boundaries do not matter.' They turn 'boring technology' into a defence of technical debt.

That objection is valid, and I have made some of those mistakes myself. Boring is not an aesthetic. It is not a personality. It is not the cheapest thing that already exists. A boring technology is one whose behaviour, tradeoffs, and failure modes are sufficiently understood by the team for the problem at hand. Sometimes the boring choice is a migration away from the old stack because the old stack has become locally exotic. A ten-year-old framework nobody understands is not boring. It is archaeology.

The resume-driven and nostalgia-driven failures are mirror images. One says 'newer is more serious.' The other says 'existing is safer.' Both avoid the harder question: what does this system actually need?

A useful architecture process should make both sides show their work. If someone proposes a new tool, they should explain the force that makes the current stack inadequate. If someone proposes staying put, they should explain why the current stack still supports the product, team, and risk profile. The default can favour simplicity without giving old choices immunity.

There is also a human point that blunt critiques of resume-driven development often miss. Engineers need careers. They need to remain employable. They need to learn the tools the market values. A company that traps engineers in a dead stack while demanding loyalty is creating its own retention problem. People will try to learn somewhere, and if the organisation gives them no legitimate path, they will either leave or smuggle the learning into product work. I have seen both. I would rather pay for the training.

The answer is to separate career development from architectural gambling. Give engineers training budgets. Create internal labs. Fund rotations onto platform teams. Let people prototype new tools against bounded internal needs. Run brown-bag sessions. Support conference attendance. Build small, reversible experiments. Make learning visible enough that it does not need to masquerade as a production requirement.

Then make production architecture boringly accountable.

That accountability starts with a decision record that states the problem, alternatives, reasons, costs, and reversal path. Not a ceremonial document written after the decision, but a thinking tool before the organisation commits. The record should explain why the simple option is insufficient. It should name the operational owner. It should describe how the team will know the choice is failing. It should include the migration or exit plan if the bet is wrong.

It should also say what will not be adopted. Architecture is partly a discipline of refusal. A small system does not need every pattern that could someday be useful. A platform team does not need every CNCF project whose logo appears in a conference hallway. A product team does not need a separate service for every noun in the domain model. A company does not need to become a distributed-systems company just because its engineers are good enough to build one.

The most valuable senior engineers I have worked with are often the ones who can make the less glamorous choice without sounding incurious. They do not say no because they are afraid of modern systems. They say no because they understand what the modern system costs. They can recognise the day when a boring monolith should become a modular monolith, when a modular monolith should split a service, when a service should be independently deployed, and when a platform should absorb repeated operational work. They can also recognise the day when the best architecture is a table, a transaction, and a clear owner.

That judgement is harder to market than a tool list. It is also, in my experience, the actual point of the job.

Put the system ahead of the signal

The cure for resume-driven architecture is not a blacklist of technologies. Kubernetes, microservices, event sourcing, stream processing, CQRS, serverless functions, service meshes, graph databases, and actor systems all solve real problems. The cure is refusing to let marketability substitute for fit.

A practical review can start with a few plain questions.

What is the current pain, and who experiences it? If the pain is hypothetical, how expensive would it be to wait? What simpler option was considered? What would make the proposed technology unnecessary? Who will operate it? Who will debug it at 03:00? What new failure modes does it introduce? What skills must the team acquire? How will new hires learn it? How will the organisation know the decision worked? How will it reverse the decision if it did not?

Those questions sound basic because they are. Resume-driven architecture thrives when basic questions are skipped in favour of identity questions: are we modern, are we scalable, are we cloud native, are we a serious engineering organisation? The better question is whether the design makes the system easier to change, operate, understand, and trust.

Architecture should be evaluated at the level where its costs land. A developer may enjoy the new tool. A manager may enjoy the transformation story. A recruiter may enjoy the keyword. But the cost lands in incidents, onboarding, delivery time, support complexity, platform work, vendor spend, and the next migration. If those costs do not appear in the decision, the decision is incomplete.

This is where organisations have to own their role. They cannot complain about resume-driven architecture while filtering candidates by tool keywords, promoting migrations over maintenance, celebrating novelty over judgement, and treating platform complexity as a badge of seriousness. The architecture reflects the incentive system. If the incentive system rewards visible modernity more than sustained fitness, the system will get visibly modern and quietly expensive.

The healthier culture is not anti-ambition. It is ambitious about the product instead of the stack. It asks engineers to learn, but not to make every customer workflow carry the weight of that learning. It values boring systems when boring systems let the team move quickly. It values modern systems when modern systems remove real constraints. It treats technology selection as stewardship, not self-expression.

That stewardship has a useful phrase: prove the need.

Prove the need for the new database. Prove the need for the separate service. Prove the need for the queue. Prove the need for the event log. Prove the need for Kubernetes. Prove the need for the service mesh. Not with fear, not with fashion, and not with the phrase 'we might need it later', but with forces the system is actually under.

If the need is real, the proof will make the decision stronger. If the need is not real, the proof will save the team from a maintenance bill it was about to mail to its future self.

There is dignity in the plain solution. A form handler that handles the form is not embarrassing. A modular monolith that matches the size of the team is not immature. A relational database used well is not a failure of imagination. A queue introduced when asynchronous work becomes necessary is not late. A deployment path that everyone can understand is not primitive.

The embarrassing architecture is the one that makes a small problem large so the builders can feel large beside it.

The contact form does not care what looks good on a CV. The customer does not care whether the message travelled through a fashionable topology. The on-call engineer cares at 03:00. The next hire cares on their first day. The business cares when a simple change becomes a week of infrastructure negotiation.

Put the system ahead of the signal. Let engineers learn, but make architecture answer to the product. Spend novelty where it buys real leverage. Keep the rest boring enough that the team can still see the work it is actually there to do.

---

Footnotes

1. Fritzsch, J., Wyrich, M., Bogner, J., & Wagner, S. (2021). 'Resume-Driven Development: A Definition and Empirical Characterization.' arXiv. https://arxiv.org/abs/2101.12703 ↩

2. Fritzsch, J., Wyrich, M., Bogner, J., & Wagner, S. (2023). 'Resist the Hype! Practical Recommendations to Cope With Resume-Driven Development.' arXiv. https://arxiv.org/abs/2307.02850 ↩

3. Stack Overflow. (2023). 'Stack Overflow Developer Survey 2023.' Stack Overflow. https://survey.stackoverflow.co/2023/ ↩

4. McKinley, D. (2015). 'Choose Boring Technology.' Dan McKinley. https://mcfunley.com/choose-boring-technology ↩

5. Fowler, M. (2015). 'Microservice Premium.' Martin Fowler. https://martinfowler.com/bliki/MicroservicePremium.html ↩

6. Fowler, M. (2014). 'Microservice Prerequisites.' Martin Fowler. https://martinfowler.com/bliki/MicroservicePrerequisites.html ↩

7. Thoughtworks. (2018). 'Microservice envy.' Technology Radar. https://www.thoughtworks.com/radar/techniques/microservice-envy ↩

8. Noonan, A. (2018). 'Goodbye Microservices: From 100s of problem children to 1 superstar.' Twilio Segment. https://www.twilio.com/en-us/blog/developers/best-practices/goodbye-microservices ↩

9. Fowler, M. (2017). 'What do you mean by "Event-Driven"?' Martin Fowler. https://martinfowler.com/articles/201701-event-driven.html ↩

10. Krazit, T. (2017). 'Kubernetes in 2018: When the going gets good, the good get boring.' GeekWire. https://www.geekwire.com/2017/kubernetes-2018-going-gets-good-good-get-boring/ ↩

11. The Linux Foundation. (2018). 'KubeCon Opening Keynote - Kelsey Hightower, Google.' Linux.com. https://www.linux.com/training-tutorials/kubecon-opening-keynote-kelsey-hightower-google/ ↩