Let’s start with a story that may sound familiar. Your team is about to take on a new tech initiative – building out a new, bespoke software platform that’s critical to your company’s future. Your team is under pressure to make a slew of important technical decisions: deciding on a cloud platform, designing the infrastructure, picking the right frameworks and languages, and choosing appropriate solution architectures and design patterns. Luckily, you have a great team of knowledgeable, cross-disciplined engineers that are hungry to learn, grow, and share their expertise. 

But as the conversations and planning move further along, you notice a pattern.  

Well-established platforms, architectures, or languages that seem to be a good fit for the solution are quickly shot down, while those that are hotter in the industry are pushed disproportionately by the team. 

This is what is known as “resume-driven development,” when the technology decisions are driven by the need to add buzzwords on a resume rather than by the actual needs of the project. And let’s get this out of the way up front. I’m guilty of it. You’re guilty of it. As technology professionals, we’re all guilty of it. At some point in our careers, we’ve chosen a cloud provider, an architectural pattern, a programming language, or a data platform not because it was the best choice for the project, but because we wanted it on our resume. 

So, let’s ask two tough questions: 

• Are the technical decisions we’re making focused on the project’s success or our personal success?  

and  

• Do we have to sacrifice one to accomplish the other?  

Understanding the Trend

To answer those questions, we need to start by understanding why this happens. In my 20+ years in the world of software development and tech consulting, the one thing that’s remained constant is how incredibly fast our industry evolves. Mastering the latest cloud offerings, learning new frameworks, or picking up new programming languages aren’t just optional activities – they’re required just to stand still in your career.  

High performers, the folks that truly drive success and make your entire team better, tend to be voracious learners. They will find a way to learn the tech and get the experience they need to advance their career, and you should encourage that.  

When that desire to grow is focused appropriately, it results in a happier, smarter, and more productive team.  

The problem arises when individual ambitions start to bias our technical decisions, leading us to choose the new, shiny, and exciting without properly considering the more established alternatives. Yes, Rust is an awesome programming language that you should absolutely get some experience with, and it does look great on a resume, but does that make it the right choice for a simple data-entry web app your team is tasked with building? Probably not. 

The Impact on Projects

When decisions are made based on career aspirations rather than project requirements, the results can be very painful and costly. The foundational choices of a technical solution are often difficult to change without significant time and expense, and they often have a significant impact on the team’s ability to successfully deliver results on time and within budget. 

Let’s look at a few examples where a poor choice could come back to haunt you in multiple ways.

Choosing the Wrong Cloud Platform

• Limited Scalability: If the cloud platform or the selected cloud services used in the solution don’t align with a project’s growth needs, scaling could become complex and costly, leaving you with performance bottlenecks and a large bill.  

• Vendor Lock-in: Relying on a cloud platform’s proprietary services makes it difficult to migrate to another provider in the future, resulting in high switching costs and limited flexibility.  

• Compliance Issues: A platform that doesn’t meet your regulatory requirements could lead to legal challenges, fines, or the need for costly redesigns to achieve compliance.  

Choosing the Wrong Programming Language

• Productivity Issues: The breadth of functionality available via built-in, commercial, or open-source libraries can vary drastically between languages, making a short, easy task in one language a long, complex task in others.  

• Maintenance Challenges: A language that isn’t well-suited for the project’s needs can lead to hacky workarounds, complex implementations, and difficult-to-maintain codebases.  

• Talent Scarcity: If the chosen language is niche or declining in popularity, finding skilled developers for future maintenance and development can become a significant challenge.  

• Performance Issues: Some languages may not be optimized for the type of work your application requires, resulting in slower performance and a need for later refactoring.  

Choosing the Wrong Architecture(s)

• Complexity Overhead: An architecture that is too complex for the project’s needs can lead to unnecessarily complicated development and deployment processes, organizational conflict, higher development costs, and slower time-to-market.  

• Scalability Problems: Inadequate or poorly designed architecture can restrict the ability to scale efficiently, leading to costly refactoring or re-architecting efforts down the line.  

• Security Vulnerabilities: An architecture that isn’t designed with security in mind can introduce vulnerabilities, making the application more susceptible to attacks and breaches. 

Let me give one more example from my own career. I once joined an ongoing project where the team had chosen a trendy document database largely because of industry buzz and the previous software architect’s desire to get some experience with it. The reality, however, was that a relational database was much better suited for the project requirements. This left them with essentially two choices – live with a backend that didn’t perform well for the intended use case, or redesign much of the backend data access code, at significant time and expense. If the project’s needs had been properly prioritized over the architect’s preference for learning something new, the development efforts would have been simpler, faster, cheaper, and more maintainable.  

Leadership teams need to be aware of how these choices are being made and consider the long-term impact on the project. There’s nothing wrong with choosing an innovative, cutting-edge tech stack – as long as it’s chosen for legitimate, well-thought-out reasons that support the project’s goals. 

Common Offenders

Even with the best intentions, some technologies or architectural patterns are especially prone to being chosen for the wrong reasons. Below are some common examples where resume-driven development often rears its head. For each, I’ll give a brief explanation of why it might be chosen inappropriately and some light guidance on when it really is the right choice. 

Microservices

Why it gets chosen – Microservices are often selected because they’re seen as modern and scalable, and many developers want the experience of working with them. However, microservices can introduce unnecessary complexity, especially in projects that don’t require fine-grained scaling or where teams lack experience with distributed systems.  

When it’s appropriate – Microservices are well-suited for large, complex applications that need to scale individual components independently or where different services might require different technology stacks. If your project is small or the team is new to microservices, a monolithic architecture might be simpler, faster, and more maintainable.  

Rust

Why it gets chosen – Rust is a powerful and trendy language, praised for its memory safety and performance. It’s attractive to developers who want to work with a language that is both modern and technically impressive. However, the complexity of Rust and its steep learning curve can be overkill for many projects, especially those that don’t require systems-level control or aren’t performance-critical. 

When it’s appropriate – Rust is an excellent choice for systems programming, high-performance applications, or when memory safety is paramount. If your project doesn’t have these specific needs, more established languages like C#, Java, Python, or Go might be more productive and easier to maintain. 

Generative AI

Why it gets chosen – With all the buzz around AI, particularly generative AI, it’s tempting to incorporate it into projects to appear cutting-edge. However, not every problem requires AI, and using it without a clear purpose can lead to unnecessary complexity, inflated costs, and disappointing results. 

When it’s appropriate – Generative AI is a great fit for projects where creativity or large-scale content generation is needed, such as personalized marketing, design automation, or language processing tasks. If your project doesn’t have a well-defined use case for AI, simpler automation or traditional algorithms might be more effective. 

Blockchain

Why it gets chosen – Blockchain technology is often chosen due to its association with security, transparency, and decentralization. Many developers are eager to work with it because of its perceived innovation and potential to disrupt traditional systems. However, blockchain can introduce significant complexity, slow transaction speeds, and high energy costs, particularly when simpler database solutions suffice. 

When it’s appropriate – Blockchain is best suited for scenarios where trustless, decentralized transactions are critical, such as in financial services, supply chain management, or when creating immutable records. If your project doesn’t require these features, a traditional relational or distributed database is likely a more efficient and cost-effective choice. 

GraphQL

Why it gets chosen – GraphQL is often selected for its flexibility in allowing clients to specify exactly what data they need, which can be appealing for developers who want to avoid over-fetching or under-fetching data. However, implementing GraphQL can complicate backend development and lead to performance issues if not carefully managed. 

When it’s appropriate – GraphQL is ideal for projects with complex data requirements and multiple client types that consume the same API in different ways. If your application has relatively simple data needs or you’re already well-served by a RESTful API, sticking with REST is a more straightforward option. 

Balancing Career Growth and Project Success

So, where does that leave us? I’ve been telling you repeatedly that your choices must align with project goals, but I’ve also said you must support the career growth of your developers if you want a happy, talented, and loyal team. How do you pull that off? Here are a few strategies: 

Foster a Learning Culture

Encourage your team to explore new technologies in a controlled, low-risk environment. Side projects, hackathons, or internal tools development can be a great way to experiment with cutting-edge tech without jeopardizing critical initiatives. This approach allows team members to build skills and gain experience with new technologies, giving them a more informed opinion of their fit for use in future projects. 

• One of the easiest ways to set up low-risk environments like this is via the free offerings provided by the major cloud providers: Azure (Microsoft), AWS (Amazon), and GCP (Google). Microsoft also offers $150 in Azure credits per month if you have a Visual Studio Enterprise subscription. 

• Several training platforms like A Cloud Guru or Whizlabs allow for quickly spinning up sandbox cloud environments alongside courses for hands on learning. 

Pilot Projects and Proof of Concepts

Before fully committing to a new technology for a major project, start with a pilot or proof of concept. This smaller-scale initiative can help you assess whether the technology truly meets the project’s needs without the risk of major setbacks. If the pilot is successful, you can confidently scale up; if it isn’t, you’ve learned valuable lessons without significant investment. 

Align Tech Choices with Long-Term Value

When selecting technologies, consider their long-term value for both the project and the organization. This involves evaluating not just the immediate benefits but also the maintainability, scalability, and potential integration with other systems. Choosing a stable, well-supported technology may not seem as exciting, but it often leads to more sustainable and successful outcomes. There’s a fine line to walk here, as speed-to-market can be critical in some scenarios, and the right long-term tech stack could be different from what’s needed for your initial release. When that’s the case, it’s still critical to identify those shifting needs up front so that you can properly plan for any transitions. 

Encourage Mentorship and Knowledge Sharing

Encourage senior developers or architects to mentor less experienced team members, allowing them to share their technical knowledge and decision-making criteria with junior team members on a regular basis. AND encourage the reverse! Younger members may have fewer biases or stay closer to what’s trending in tech, meaning they often have valuable insights to contribute to the team’s collective knowledge. 

Be Transparent in Decision-Making

When possible, involve the entire team in major technology decisions. When everyone understands the rationale behind a choice—whether it’s stability, scalability, or innovation—they’re more likely to buy into the decision and work towards its success. No one enjoys being handed decisions from an Architect in an ivory tower, especially when the reasoning isn’t clear. Transparency helps to ensure that decisions are made for the right reasons, not just to add a new buzzword to someone’s resume. 

Seek Outside Help

The breadth of options in platforms, languages, services, architectures, or tools in technology is absolutely massive, and trying to know everything is a fool’s errand. It’s just not possible for any one individual, or even team, to always be aware of the available options and more importantly, which is the right choice. So instead, get comfortable asking for help. Talk to other teams in your organization, start a conversation with a trusted friend, or reach out to an expert from a 3rd party group. 

Ultimately, the best tech decisions are those that meet the goals of the project while also providing opportunities for the team to grow and learn. Sometimes the gods smile upon us, and those goals overlap. But when they don’t, it’s the job of leadership to intentionally bridge that gap and provide alternative career development opportunities. It’s a balancing act, but one that is crucial for the success of both the project and the team.