Lessons from Personal Finance Applied to Tech Debt

Lessons from Personal Finance Applied to Tech DebtBrendan ConeBlockedUnblockFollowFollowingApr 4Three years ago, my wife and I bought our first house together.

It was nerve-wracking, especially in the insanity of the Toronto housing market boom.

We are both, at our core, totally averse to debt, primarily due to the fact that we both come from modest means.

When seeing our mortgage realized in our online bank portal for the first time, reality set in: we now owed the bank a whole lot of money, and initially our thinking was that we had to pay it off about as fast as we possibly could.

Within the short time that we’ve owned our house, it is now worth 50 percent more than what we bought it for based on our estimates.

I say this not to brag, as I also realize that many of these financial gains are often fleeting and three years from now, it could similarly be worth 50 percent less.

Rather, I bring this up to introduce a parallel between buying a house (and personal finance in general) and the transition from engineering development work into engineering management.

Debt as a Developer vs.

Debt as a ManagerI’ve found anecdotally that most engineers are risk averse, and for good reason.

Engineering is a discipline built upon the principles of safety and responsibility, and software engineering is no different.

Many of us in tech are perfectionists by our nature and we try our best to honour this responsibility.

We want to know when our systems are broken in any way, so we prioritize monitoring and alerting before a launch.

Many of us are uncompromising when it comes to propriety of system architecture and cutting too many corners.

The problem that many of us encounter as we move into engineering management positions (if that’s our career path of choice) is that our job is to directly challenge and contradict those core sensibilities at times.

We are responsible for finding inefficiencies, removing roadblocks for our teams, and sometimes launching based on timelines that are driven by a market opportunity.

This is our reality, and it is a tough job convincing people to go against the things that are so core to their identity.

I remember often as a developer or team lead being outright frustrated that we were making technical sacrifices before a release in order to hit a specific deadline.

But I also remember all of the good times that came after the release when we could see a successful product flourish and gain adoption, and ultimately we enjoyed the fact that we had created something where before there was nothing.

Being first-to-market helped drive our success, even if we weren’t so happy with how we’d gotten there at the time.

There’s a reason that every successful small- and mid-sized tech company has a legacy monolithic codebase written in a language and framework from 5 or 10 years ago.

It’s the same reason that, as a young person, you should be investing in stocks over bonds to realize better long-term growth, sometimes borrowing to do so.

When a company is starting out, they need to take risks, and they need to take on debt in order to grow.

Most companies that start out trying to build things “the right way” and don’t take on enough tech debt don’t make it past the start-up phase.

Often, you need to earn the privilege to get to refactor your disgusting code, by writing disgusting code.

With this comes risk — the more disgusting code you write, the higher your risk exposure.

This helps explain why many successful companies end up spending time rearchitecting or fixing things, being forced to slow their growth.

When most of your monthly salary is going to the bank as interest, it tends to change your spending priorities.

Mortgages, Credit Cards & Monthly PaymentsA dev manager, seen here, after 5 years sprinting on product features.

thisisfine.

jpgAnother important concept is that not all debt is the same.

In the real world, the interest rate is often a known quantity, but in software there are many different signals that a particular solution may incur ongoing tech debt that could be unbearable for a team.

Teams need the ability to recognize what the actual rate of interest is on the debt that you’re taking on, and need to be able to classify solutions on a danger spectrum.

I always try to factor this into our team’s decision-making process: are we taking on credit card debt that’s going to come back every month and derail the team, or a low-rate mortgage that will only become an infrequent annoyance?.And, in times of struggle, is it worthwhile to take on that credit card debt anyway and live with the consequences for a short while?To apply principles from personal finance, I’ve learned that you should treat tech debt as something that you will, for most of the lifespan of your company, organization or department, have to deal with near-constantly.

You should pay off credit card debt quickly, but you’re probably going to have a mortgage for most of your life.

If you have no debt, you’re moving too slowly, and not realizing nearly enough of your potential gains.

If you have a ton of high-interest debt, you’re probably taking on too much risk and not getting much done.

I’ve also painstakingly learned that if you really want to maximize your potential, you should get into the habit of paying your tech debt off at regular intervals.

I’ve started to think of things in terms of monthly payments, and what we can afford.

The bank won’t let you take on a mortgage that is far beyond your means (and they base this decision on your monthly expenses, not the total sum of the mortgage), so why would you take on so much tech debt that you can barely afford to keep the lights on every month?.Analyzing and quantifying how much of a team’s every-day time is spent dealing with tech debt is a worthwhile exercise, and helps you build a business case to deal with it.

The Psychology of DebtReflecting back on our mortgage situation, after we had bought our house, my wife and I asked ourselves: should we invest our savings, or pay down our mortgage?.The common advice is based on simple math: compare the average interest rate that your investments can earn against the interest you pay on your mortgage and your long-term finances will benefit if you prioritize putting your money against the larger.

The decision is not so simple in practice, though.

Would your decision change if your income was unstable?.What if you expected an inheritance or some other windfall this year?.What if you had inside information that bitcoin was going to skyrocket by 2200% next year and then tank?.These factors show that the system is dynamic and psychological, varying with peoples’ risk profiles — it isn’t an exact science.

The same is true when managing tech debt.

Sometimes it can be easy to develop the business case to address a piece of debt: our team can move faster, or they can be more focused on a specific problem that is valuable to the company.

But sometimes — and it’s important as a manager to recognize when these times are needed, and to use them judiciously to maintain trust with those who depend on our teams — we need to make the decision to address tech debt even when there is a stronger business case to work on something else, simply for the quality of life and psychological satisfaction of the team.

People can only live in filth for so long, and we need to make sure our codebases spark joy with their developers.

The Bull Market and the Bear MarketDRAM, seen here making the decision to accrue tech debt in a bull marketTo stretch the analogy even further, what if you knew every single year that if you took on debt to put down an investment in July and cashed out in January, you’d get ten times as much compared to the reverse?This scenario exists in a lot of industries.

For example, in retail, there are heavy shopping seasons around Black Friday and Christmas, and a lull in the earlier months of the year.

If our customer is the average shopper, this helps inform how we should be managing our debt, as well.

It makes sense to invest with a bull market/bear market mentality accordingly: coming into the high season, we should make technical trade-offs and take on debt regularly, because the potential gains that can be realized in the high season are much greater.

Afterwards, as high season transitions into low season, we pay down the debt that we accrued (or try to pay off as much as makes business sense).

It’s obvious that there is also risk to this strategy as well — if you take on the wrong debt, you could do serious damage in high season because the stakes are higher in general.

Your industry may also dictate how much risk you can and should be taking, as well.

Health tech, and other industries that require certainty in the way that they do things are limited in the amount of debt that they can take on because of the inherent risks, which also helps inform why those types of tech companies typically grow more slowly aside from all the regulatory hurdles.

ConclusionNo engineer likes tech debt, and they especially hate writing code that they know contributes to it — to be sure, one of my favourite activities is refactoring terrible code, especially if I wrote it.

But over time, I’ve grown to understand and even appreciate tech debt as a tool.

In what other industry do we have the privilege of saying “this could take either 2 months, 4 months, or 6 months, with varying degrees of risk” for a given project?.How fortunate we are to be in a position to control our own destiny to that degree.

Just make sure to always pay your debts in a timely manner else you’ll end up paying it all in one lump sum soon.

*Extra special credit and thanks to Jeff Francis, Principal Engineer at Flipp, for seeding and helping to expand upon many of these ideas.

.

. More details

Leave a Reply