First things first: Motivated staff are like coffee-fueled superheroes—more productive and less likely to vanish. Good leaders know they need to keep their team motivated, but how? Especially with software engineers, who can be as finicky as a cat with a new toy.

Here's the trick: Different people are motivated by different things. Have one-on-one meetings to figure out what makes your team tick. But one thing many developers share is a love for "the new hotness" over "the old and busted" (thanks, "Men in Black II").

If your team's work on specific parts of your company’s software, consider rotating them. Either move members between teams or switch the projects they're working on. This not only keeps things fresh but also spreads expertise around, so you're not stuck when someone with niche knowledge leaves.

Moving developers can shake up team cohesion a bit, like switching seats at a dinner party. But it also means new perspectives and shared knowledge. Switching projects may slow things down temporarily, but the long-term benefits can be worthwhile. Just make sure to discuss these changes with your team to prevent fear of change from being a buzzkill.

Letting junior engineers lead projects is like handing the keys to the eager new driver—nerve-wracking but exciting. Be there to guide them, like a GPS that actually works, and watch them grow into confident leaders.

Another way to have engineers be motivated by the “new hotness” is one that carries more risk than either of the other approaches. That does not mean it should be avoided, but you and the team need to be aware of the downsides and manage them accordingly. The risky motivation is the introduction of new language, framework, or technology. It can be as risky as trying that weird new fusion restaurant. It’s exciting but can come with some stomach aches.

Software engineers are understandably keen to try new technologies. There are promises that new frameworks or languages will make development faster and more reliable. Learning a new technology can be fun. It never hurts to add skills to a resume.

However, there are costs to the wider team that must be considered. Once a new technology is deployed to production, it will need to be supported, as will the existing ones. When Angular was the new hotness, it was widely adopted, then React arrived and engineers started using it. Every place I have worked in the last eight years has had some applications built in Angular and some in React. The front-end engineers need to support both. There is never the bandwidth to rewrite the older apps in React. I joined a company that had an app developed by an outside firm. When it was written, MongoDB was the cool new kid on the block, and the team had used it rather than an SQL database. The app usage was never going to need the scale that MongoDB provides, and the data had a fixed format. The result was that our DevOps team had to provision a database server for just this app. All of our other apps used Postgres.

I am not saying that engineers should be forbidden from using new technology, or we would still be using COBOL for all our development. However, the decision to use new technology should be made with care. There needs to be a discussion that includes the wider engineering team, DevOps, and security personnel. Consider the long-term support implications of using new technology. If the technology is new, be aware that there will be fewer resources available to help troubleshoot issues.