Image: NDAB Creativity/Shutterstock

Yes, you can try to run like Google (or Amazon, Facebook or one of the other hyperscalers), but odds are that their engineering practices won’t be a great fit for you. And that’s okay. As a mainstream enterprise, you have to be realistic about what’s overkill for your engineering requirements, as Google’s Kelsey Hightower has stressed.

Not everyone agrees. One company, Nobl9, hopes to convince enterprises to do things the FAANG (MAANG?) way. No, not everything, but specifically how they manage software reliability, and particularly the impact of technical debt. The premise is that while most enterprises are hiding from tech debt, hyperscalers face it head on, and you should, too–or at least, to understand where tech debt is hurting reputation and productivity. Today Nobl9 is launching a service called Hydrogen that, among other things, automates Jira creation for team-level early warning of technical debt risks. Let’s see why that matters.

Hidden debt in your Jira backlogs

Accrual of some tech debt is normal and healthy. For example, every software release has bugs. Every software service uses languages and frameworks that need to be upgraded to the newest versions, security patches, performance challenges. The list goes on and on. It’s the cost of doing business in software development. It’s normal.

But not all tech debt is so kind.

SEE: AWS Lambda, a serverless computing framework: A cheat sheet (free PDF) (TechRepublic)

Nasty tech debt can take down your service and anger your customers. Benign tech debt might never get paid back. If you’re like most engineering teams, you document these issues in your Jira backlogs, where they eventually need to be revisited and prioritized.

The question that plagues engineering teams and product managers is how to tell the difference. Wasting energy on safe tech debt means slower feature delivery. And ignoring the ticking time bomb means you could have a major outage. Some teams take the “college loan” strategy, others use “credit cards” or worse “loan sharks” to ship ever faster and delay the inevitable.

The great tech default

A natural consequence of technical debt is repetitive and meaningless tasks for engineers.

Oppressive “on-call” cycles have become the norm, and unfortunately many of the preventable issues are simply not prevented. When services go down in production, tortured engineering teams often lament that the very issues responsible for the outage were in the tech debt backlog all along.

As Nobl9 chief operating officer Kit Merker recently tweeted, “people used to quit managers, now they quit on-call rotations.”

Image: Kit Merker

It’s not hard to imagine that these engineers, given the choice, will pick the place that comes with less debt. Sure, finding that nirvana isn’t easy because while the grass may always seem greener on the other side of the fence, the tech debt is almost certainly just as voluminous. Still, you can make a bigger impact more quickly in software development when you have rational conversations about which tech debt makes sense to pay off, and when.

It’s logical to think you don’t have to be Google to care about engineer productivity and sense of purpose in a tight labor market. Downscaling the YouTube and Gmail approach could make sense for other businesses, if it was feasible.

SEE: Power checklist: Local email server-to-cloud migration (TechRepublic Premium)

Optimizing the tech debt equation

When Nobl9’s founders’ previous cloud marketplace technology company Orbitera was acquired by Google, they were forced to replatform it on Google Cloud. This experience gave their team the visibility into the Google way of site reliability, and they had the epiphany that there was a way to model this out as a more mainstream abstraction for balancing software reliability against features creation.

Today Nobl9 launched Hydrogen, a platform that automates Jira creation for team-level early warnings of technical debt risks. Hydrogen uses the Google building blocks of service level objectives (SLOs) and the APM and logging telemetry data that companies already have—so that engineers can model reliability with additional context, and directly link customer impact to tech debt, to understand which specific issues have risen to the level of severity that they are higher priority than new features.

It’s a cool approach, created by folks who have seen firsthand how a hyperscaler like Google handles tech debt. It’s launching at an opportune time. The last 10 years was a renaissance of developer tooling specifically aimed at speeding up development cycles—from Agile methodology and supporting tooling, to build environments, Git workflow, CI/CD, you name it. Now there is a tool that tells you when to slow down, bringing some sense of release to engineers on call.

Maybe some engineering practices are best left for the Googles of the world. However, an approach like Nobl9’s might be a great way to ensure you get to enjoy more of the holidays, uninterrupted by pager alarms.

Disclosure: I work for MongoDB, but the views expressed herein are mine.