We’ve covered profitability in your tech team when it comes to the guiding principles, actual software, and your organization. This article will address a holy grail of highly impactful teams: innovation. How do you handle tech debt profitably? Why aren’t hackathons worth it? And more.

Unprofitable Innovation

I think it will be easier to discuss what you should do once we tackle the things you’re familiar with but that don’t really make sense. We have to realize that there’s always tension between tech “perfection” and business needs. Pragmatism is about knowing how to balance these so that we don’t end up on either extreme, that is, a big ball of spaghetti as our codebase or gilding the lilies as the business is going under.

First, I’m sure you’ve heard in the past how important it is to avoid rewrites because they’re extremely dangerous. Having worked with enough startups, I can attest that many waste crucial time dillydallying and finicking with their tech stack, not focusing on the things that matter. However, I also saw cases when a swift rewrite actually unclogged the business (sometimes resulting in acquisitions or great business leaps within a couple of months).

How can you tell? It boils down to considering the basics: how is this going to pay off for the business? If your team considers this and doesn’t push for certain initiatives just for their coolness factor, you’ll already be better poised to win.

With that in mind, you’re less likely to allocate time to tackle tech debt, even though it doesn’t make sense. Similarly, consider your recent hackathons. I’m sure they were fun, and the pizza was good (I mean, how can pizza not be good). However, in hindsight, how many of those projects still deliver value today? If you’re like most companies, your hackathons usually end with things that are about 70% usable, and then they are never touched again because they weren’t that useful. Let’s fix that.

Cutting Debt Wisely

Having become accustomed to calling most old parts of our code “tech debt” has a harmful effect. That’s because, in general, we know that getting rid of debt is rarely bad and that one should aspire to live debt-free, right?

Nevertheless, this “debt” is not the same when it comes to code. We can very easily invest weeks of effort into lowering tech debt that won’t have any effect on the company for months or even years. Perhaps your team would feel nice about it, but it would still be the wrong decision.

Whenever you decide to invest in anything that’s not trivial—your team should ensure it makes sense. So, simple things, like tidying up files we’re touching anyway, probably make sense. The same goes for adding some unit tests to a part of the code that you’re working on that doesn’t have those for some reason. That’s a basic level of autonomy that I don’t want to even consider with the team.

Contrast that with things like moving all your old microservices to have your latest conventions, even though they aren’t likely to be touched again for months. Any effort that’s not trivial and that couldn’t be done “in passing” should probably be considered from the lens of opportunity cost and value in the grander scheme.

Amassing Capital

Now, let us contrast tech debt with something that’s always useful: capital. When I coined the term ‘tech capital’ as opposed to tech debt, it was about tech capabilities that provide ongoing value. So, we’re not talking about another feature here or there but about things that make your company as a whole more valuable.

For some, these might be different parts of the tech solution that are genuinely important components of your “moat.” That’s usually an easy type of tech capital for engineers to think of. Another example would be investing in internal tooling for engineering velocity. We can often easily tell that making our builds faster or more reliable will pay off quickly.

Tech debt, though, can span beyond that. My favorite examples are those where engineers provide little “superpowers” to others in the organization. Think about the endless possibilities of doing “engineering velocity”-like work but for others in the company. Can you aid sales velocity? Help marketing experiment faster? That’s what tech capital can be all about.

Innovation Platforms

One last point about making innovation work for your organization is ensuring that we make the proper space for it to take place. The major advantage of hackathons is that they happen. It’s better than nothing. To unleash innovation in a way that makes sense business-wise, there are two aspects you should consider as you’re reviewing your team and focus.

First, foster a culture that allows for habitual innovation. That means that creativity is something that’s gladly accepted and appreciated. Create an atmosphere that allows team members to speak up when they have ideas and have the safety to suggest something that might not make sense. Accepting a reasonable amount of risk is part of anything that pertains to innovation. Don’t give people blank checks to do whatever they feel like in the name of novelty; it still has to be a “good bet” when considering the opportunity cost and the potential upside. Nevertheless, having some things that don’t work out shouldn’t harm one’s position in the company.

Second, some things require a more concentrated effort. For example, ideas that require several days or several different people to work together. Precisely for these, we create dedicated time for real innovation work. I call these intermissions in my book, I’ve seen other names like “innovation weeks” or “sabbaticals.” The name matters less than the execution. You need to make time for substantial work regularly. There’s only so much you can achieve in a 24-hour hackathon, and an intermission is closer to an iteration spent on innovation.

These should have backlogs that are aimed at generating impact and value for the company if the bets succeed. That means that when you view the intermission as a whole, its expected value as a whole should be substantial. That’s how we avoid turning intermissions into tech-debt festivals. If you want to read more about innovation in R&D, subscribe below to get the chapter from my book about innovation, intermissions, tech capital, and more.