Jon Thornton worked at some small companies in NYC before he ended up at Squarespace. He’s been able to build a new product and new team—their email marketing product. He launched that and has since been supporting other products. Throughout his career, he’s learned how to manage technical debt. What is the difference between technical debt and good technical debt? What is a framework for using technical debt? Listen to this episode of Simple Leadership for Jon’s advice on managing technical debt.

Jon has been solving problems with software for over 20 years and leading engineering teams for 10. Along the way, he’s parked millions of cars, improved textbooks with AI, reduced the price of prescription medication, and sent billions of emails. Currently, he’s an engineering director at Squarespace in New York City. Though Jon’s day job is mostly meetings and documents, he still gets his coding kicks in by maintaining a mildly popular jQuery plugin in his free time.

Outline of This Episode

• [1:26 ] Jon’s history in programming


• [4:43 ] Mistakes Jon made early on


• [6:22 ] What would he have done differently?


• [7:32 ] Teamwork isn’t about individual output


• [8:25 ] Financial debt and technical debt


• [10:53 ] Why time is currency


• [14:32 ] Good technical debt is intentional


• [17:14 ] A framework for using technical debt


• [21:24 ] Why building trust with your team is important


• [22:37 ] Jon’s book + podcast recommendations


• [24:54 ] How to connect with Jon

How technical debt compares to financial debt

The common definition of technical debt is that it’s code that you don’t like and you’ll need to fix or change later. But Jon applies a more narrow definition: It’s work that he expects to have to do in the future. It’s not necessarily code that he doesn’t like.

Jon points out that financial debt is a commonly accepted occurrence. Someone that takes out a mortgage to buy a house and is congratulated. It’s a “responsible” use of debt. You can use technical debt to get value now and then you can pay it down over time. It’s a tool. It allows you to reorder when they value and the payment happens—you just have to use it responsibly.

People want to have perfect code from the moment of conception, but it isn’t always worthwhile from an ROI standpoint. If it doesn’t make more money or provide more value, it can be shelved for later.

How to manage technical debt

When you think about starting a new engineering project, it starts with estimates: “How much is this project going to cost us?” It typically refers to man-hours or engineering week. The cost of the project is how long the team will spend building it. If you’re following the financial debt analogy, you are taking out a tech debt mortgage. You’re borrowing time that will be paid back later. You’re doing it in a way that creates more value now.

The main reason engineers exist is to provide value—to shareholders, your company, and the users of your product. If a manager takes over a team from another company, they’re immediately taking on technical debt or risk that has accumulated. How do you walk through that? How do you evaluate that?

According to Jon, you can talk to people or read commit history to understand how you ended up with the system you have. The next step is to assess the kind of technical debt you’re dealing with. What technical debt is actively accruing interest? Are you spending time on it with bug fixes? Is it growing larger?

There may be an API with design issues. If you keep building on top of it, it will be harder to evolve later. Other kinds of debt may be a scaling issue where performance is okay now, but your database can’t support it later. You have more time to put that technical debt aside and address it later. Assess and establish urgency.

Good technical debt is intentional

During his initial Squarespace project, Jon used an access control list where only certain people had access to certain features. The right way to build it is to have a database table and management UI that makes it easy to add people. But the list didn’t change frequently. It would be easier to have a hard-coded list of IDs in their code-base. To give someone access, they’d make a new commit and deploy it. It was fine for the first two years of the project. They’d instead spend their time on things that immediately impacted the project they were working on. They could go in and make the list more dynamic down the road.

Jon recommends that you do the riskiest parts of your project first. Reordering the way you build things enables you to tackle risk first. With any project, there’s usually going to be some problems that you have