It really is a tough job running a product engineering organization. It is extremely easy to optimize for short-term results and “getting things done.” That would definitely position you as an effective leader and get you some pats on the back. That is, until one day, you’ll realize someone else whizzed past your team. Let’s talk about balancing short-term goals with long-term innovation.

The Problem with Best Practices

Unsurprisingly, we all want to get work done. As I state in my books, no one cares about a tech team with brilliant people doing creative things, but that doesn’t deliver. Thus, each leader should start by ensuring the team reaches a point of stable execution. However, once you’re there, it is easy to get addicted to “being in the groove” and tuning the system more and more to sustain this pace.

When that happens, many options that might feel like slowing things down get shot down immediately. A creative idea never gets tested. A novel approach gets shelved. Someone hears about a new tool that could save time but is told to wait till the next hackathon. Over time, your team stops questioning the way things are.

Best Practices obviously have merit. After all, they spare us the need to reinvent the wheel and all the parts connected to it. However, no best practice is automatically correct in all situations, and if we would all stick to the same practices, no company would ever have an edge. Consider the many stories in Musk’s biography that describe poking holes in requirements because they’re not set in stone or preferring to fight regulatory standards that no longer make sense instead of investing the time to do what NASA and its contractors were doing before SpaceX.

Enable Innovation

If you want to enable your team to use its fullest potential, you don’t have to start with any drastic moves. There is a clear need to handle the balance between delivery and innovation. Therefore, start with sharing the following ideas with your management team and making them part of your routine discussion points.

• Regularly shake things up: Don’t always assign the person who’s most experienced with an area to perform the task. When engineers are exposed to more things, they grow and better understand the system.
• Welcome fresh eyes: Even in an environment of slow/no growth, things should change. Some people should change roles every 12-24 months so that teams get an injection of fresh blood.
• Embrace failure: Musk’s “algorithm” about tearing down requirements says that if you don’t find that you had to add back 10% of what you cut—you didn’t cut enough. Not all your experiments will succeed; that should be the expectation. Don’t treat that as an indication of fault.
• Bring in inter-disciplinary knowledge: Instead of letting people sit in silos, create cross-functional teams and ongoing collaboration with all roles in the company.
• Have fun: I’ve seen countless examples where people just toying around with an odd idea and eventually realized it could be used for something they work on.
• Don’t sanctify best practices: It’s okay to break them sometimes, especially when you have a good reason and want to leap above the current industry standard.
  

For more about innovation in R&D, go here to get a free chapter from my book all about it.