This arctic winter — time to repay your tech debt

We’re in the midst of a hard arctic winter. The tech industry has not experienced a more existential reality since the dot com bust. Companies have pivoted, slashed jobs, and are re-looking at innovative ways to cut costs. Hard cultural questions are being asked on the relevance of employee identities in an organization. It’s a test of our times, and while I'm an eternal optimist, these are important debates on how we’ve fared.

As someone who has lived and breathed tech, the broad outcomes of the industry are undisputed. No other field has added so much value so quickly; and in that endeavor, technology has been radically empowering. Engineers have stepped up to the changing demands of our industry, and innovated in unimaginable ways. But, now is peace-time preparation. And, the bitter truth is, engineers are not prepared for some of the more realistic outcomes of how business teams function in such testing times.

The basics — boring, but resilient

Businesses are cutting down on experiments and outlandish bets. This makes sense given the peace-time scenario companies find themselves in. If engineering teams are not building new products/experimenting, what then? What’s the priority, given budgets are being slashed?

Engineers seldom work in these environments.

In most cases, engineers don’t think about budgets. For example, owning a P&L has never been a cup of tea for engineers.

But organizations have to start caring about this deeply. And the ones who do will be better equipped to stand the test of time. At Gojek, engineers owned business metrics; from daily orders, to retention cohorts and acquisition costs, engineers cared deeply for costs. For organizations that don’t care about costs, please do so now. This has to change.

This is as good a time as any for engineering teams to focus on the costs to the business. That free lunch is dwindling. Fast. Do we really need three project management tools; separate ones for designers internally and another for designers and engineers to sync? How do we purge unused/untouched data? What are the attributable storage data costs that are irrelevant? There are tonnes of these unanswered questions.

My peer Nishant has written about Internal SaaS expenses. He contends that the money spent on internal software tools to support tech infrastructure is bloated. This is true.

Most engineers have had the luxury of experiments and wasted resources to play around with different tooling. Now would be a good time to slash those expenses. However, I also believe this is just the tip of the iceberg.

The next year — What should teams focus on

I want to focus on 4 key aspects that need immediate attention.

Fragile systems

It’s time to repay your tech debt. The next year for engineering should be about re-paying engineering debt. All those shortcuts taken need to be redeemed. Code you wrote without tests, shortcuts you took, ineligible code only the author understands, terrible onboarding of new engineers, etc…. This is when a lot of that engineering debt is paid off.

The best time to do a re-write was yesterday. The second best is now, as you’re reading this.

You’re fragile, yet overcomplicated systems need an overhaul; you know it, your manager knows it, and sadly business teams don’t understand it. But this is as good a time as any to pay that debt; rewrite. Do the boring and hard work no one would dare touch, where there’s no glory. Repay this debt.

Hiring smart engineers

A huge part of your engineering debt is how you approach hiring. A random assignment, no defined filtration process, and a half-baked interview attempt.

This is a vicious cycle; you want good people, but you don’t invest the time to do what it takes to hire good people.

One of the ways you can accelerate that is to look at people for the reasons to hire. We look at people and try to filter them out through a bunch of interviewing rounds. Instead, look at candidates and examine what are the reasons to hire — this is a drastic change in attitude, and makes this process more fun. Repay this debt.

Rethinking Build vs Buy

There are no blanket rules over when to buy vs build. You have to map out your infrastructure cost before these decisions are made. Most engineering orgs struggle to do this. This is probably the BEST time to showcase how engineering can reduce costs with buy vs build decisions.

For example; managing your own Prometheus with 5 engineers is downright foolhardy now. Yet, inexplicably, orgs do this. They don’t factor in engineering overheads while calculating the overall costs of ownership.

Start looking at Total Cost of Ownership (TCO), including engineering salaries. This will give you a more comprehensive picture of your bloated costs. Repay this debt.

Measuring engineering efficacy

Engineering metrics need to be defined to bring about accountability with multiple teams. Uptime should be a strong business metric. My peer Sidu has written eloquently about this — Why MTTR should be a ‘business’ metric. Feature engineering should not impact uptime — repay this debt. By publishing engineering metrics, you bring in a greater understanding of the impact engineering teams bring to the org. Repay this debt.

This is as good a time as any to focus on fundamentals. Because we can be sure of one thing in tech: it’s all-pervading, and once the arctic winter abates, these same problems will persist. You can avert these by nipping them when you have the luxury of time.

Anything I missed out on? Tell me, I would love to learn. You can find me on Twitter here.