Resume-Driven Development
Why Tech Choices Must Serve the Business, Not the Developer
Over my 28 years in technology, I’ve watched countless teams kick off a new project by picking a tech stack for all the wrong reasons.
Often, it happens because the team wants to learn a shiny new framework or try out an emerging trend. They jump in headfirst without considering the long-term trade-offs. Fast-forward a year or two, and the team either deeply regrets their choices, or worse — the original authors leave, and the developers who inherited the pieces want to throw the whole thing away and start over.
I’ve seen this exact scenario play out time and time again. I once worked alongside a team that was adamant about avoiding traditional relational databases and object-relational mapping frameworks because they were desperate to use MongoDB. Despite warnings that their data model was highly structured and relational, they pushed forward anyway.
The result? They spent years writing custom boilerplate code to work around MongoDB’s limitations for their specific use case. They lost immense time and momentum — and years later, the organization is still burdened with maintaining those workarounds.
Design for the Problem, Not Your Curiosity
As software engineers, we love new tools. When a project lands on our desk, our first instinct is often to reach for whatever language, database, or tool is trending or whatever we’ve been eager to pad our resumes with.
But choosing a technology stack based on developer curiosity or individual familiarity — rather than the problem at hand and the goals of the organization — is a quiet, insidious form of technical debt.
Consider this: if your engineering organization is 90% Java, introducing a single Go or Rust microservice might feel like a win for that specific project. But at the organizational level, you’ve just created an isolated island of technical debt. You’ve fragmented your CI/CD pipelines, bypassed shared security harnesses, and ensured that only one or two people in the entire building know how to fix a bug in that service.
Get Stephen Paulin’s stories in your inbox
Join Medium for free to get updates from this writer.
Local optimizations often lead to global friction.
Aligning Tech Choices with Business Goals
Of course, this doesn’t mean an organization should stay frozen in time. There are entirely valid reasons to migrate to a new language or database paradigm, but those choices must be intentional and driven by broader business strategy:
- Ecosystem and Talent Pool Realities: If your core stack relies on a legacy language where hiring qualified talent is becoming impossible, shifting to a modern alternative (e.g., migrating legacy C components to Rust) is a smart, strategic business decision.
- Top-Down and Bottom-Up Synergy: Sometimes corporate leadership is out of touch with modern industry trends. In those cases, engineering teams should advocate for modernizing the stack — provided they do so transparently, with a clear view of the organizational impact, rather than in a silo.
- Team Mobility: When most of your engineering organization uses a unified set of languages and tools, developers can seamlessly jump between teams to help during crunches. Fragmented tech stacks destroy team mobility.
When you work for an organization, technology choices aren’t about personal preference. They must serve the overarching goals of the business.
Driving Change with Context
Picking a technology stack requires looking far beyond the immediate requirements of a single project. It demands a clear understanding of where the business is heading, how the broader engineering team operates, and where the industry is moving as a whole.
There is rarely a single “perfect” technology choice for any problem, but there are plenty of demonstrably wrong ones. Siloed decisions made in isolation almost always lead to operational headaches down the road.
Before you introduce a new language, database, or framework into your ecosystem, ask yourself a simple question: Am I choosing this because it is genuinely the best long-term solution for the business, or just because I want to build it?
Engineering maturity isn’t about how many cutting-edge technologies you can cram into a production architecture. It’s about exercising the restraint to build simple, maintainable systems that outlive your tenure at the company.
