I was very lucky to work with extremely bright and talented people over the last couple of decades. People who don’t shy away from a challenge. Those who find clever solutions. Who work extremely fast. Then came a point in my career where I realized that it can act as a double-edged sword, harming the team’s efficacy.

Shiny New Projects

Look, we’re all human, and it’s extremely fun to work on cool projects. A lot of good startups see these regularly. For example, as I’m writing this, people are still coming down from their yearly Apple WWDC high: so many new APIs are introduced and lots of changes to the OS, and teams naturally want to work on that. I know startups that, for over a decade, have been blocking the summer on their roadmap to work on whatever flagship feature Apple has released—even if it doesn’t really make sense. They’d toil all summer long to be featured on the App Store come the fall for a couple of days. While it might be cool for PR, too often the focus on novelty for novelty’s sake doesn’t produce features that users appreciate after the novelty wears off.

The same happens when there’s a trendy new API or service out, when we want to claim we also make use of AI, or when we get a cool challenge. One of the formative moments of my career was when I received a technological challenge from a CTO and immediately set out to find a solution. Two months or so later, we were celebrating the successful deployment, only to later see the cofounders surprised: had they known the cost and that it wasn’t necessary, they would have gladly worked around that challenge in the product to save the time.

(BTW, you can get that full story by signing up for Unplugged with Aviv and watching the first session.)

The Danger of Pseudo Productivity

Put clearly, when the team has a high level of tech mastery, and an eager to keep honing their skills, the pitfall of pseudo productivity is very much present and dangerous. Just because you can whip up a POC in a couple of days and not weeks or months, it doesn’t mean you should. When we can do these things relatively fast, we just allow the company to shoot in all directions without aiming at any substantial goal, while participating in tech-bro pseudo productivity.

The funny thing is that many times, no one else would even know. It is up to those doing the heavy lifting of coding the solution to point out that some parts aren’t really necessary, or that it might be possible to do things differently, albeit not as sexy or shiny. That’s part of your responsibility as a senior engineering leader.

Neutralizing Coolness

To be a party pooper, I’m going to suggest you teach your team to spot when they’re getting all hyped up about doing something due to its coolness factor, and count to ten. Ask a few questions to be sure you’re not rushing into this just because it’d be fun. We all know how senior engineers can poke holes in projects that they’re not excited to do, and how expertly they wield the scalpel to scope down a project. The same mindset should be applied regardless of how fun the work itself might be, because impact should come first.

So, a second before rushing off to watch a YouTube guide about that shiny new API, make it routine to ask some coolness-neutralizing questions. For example, would you suggest the same scope if it entailed no interesting tech, but performed with your “boring” stack? Is this likely to still be useful a year from today (to clearly point out whether something is feature work derived from understanding clients’ needs, or just “hype cycle” work that should be done, if at all, as a POC)?

It might not seem as cool, but teams that avoid low-impact work, no matter how attractive, are teams that are more likely to reach actual impact. Coolness is not a strategy. Impact is. Your job isn’t to keep engineers entertained. It’s to keep the company alive and moving forward.

So the next time someone gets stars in their eyes over a shiny new thing, remind them: this is a business, not a hackathon.