Christian McCarrick: This is simple leadership. Welcome
you here to learn from you new and seasoned technology leaders who all share a passion for improving the craft of technology management. Let’s take a deep dive into management, leadership challenges, and best practices specific to software engineering and technology teams. Do you want more engineering management, leadership, tactics and information.
subscribe@simpleleadership.io to receive the latest updates from this podcast. Hi, I’m your host Christian McCarrick. This is the simple leadership podcast. Welcome back. Good morning, Jon, welcome to the show. Thanks for having me, Christian. Yeah, absolutely. And where are you actually connecting in from this morning, Jon?
Jon Thornton: Actually in upstate New York at my parents’ house. I grew up in Socrates, New York and decided to get out of New York city for the week and get some fresh air. So it’s been a nice week up here,
Christian McCarrick: Right? Yeah. Nice. Now, is that area known for, is it racing or something up there?
Jon Thornton: There is a Speedway in upstate New York.
I don’t know. I’m more into the hiking and camping and things like that.
Christian McCarrick: Absolutely. I remember I grew up in New York and long Island and we took a number of sort of boy scout trips up to the Catskills and the Adirondacks.
Oh cool, I worked
Jon Thornton: at one of the boy scout camps up here.
Christian McCarrick: Oh, did you? Oh, cool. Cool, excellent, excellent. Lots of good memories of kind of camping trips. All the way up to like thousand islands and Lake Placid and all, all sorts of great areas. So, yeah, that’s a great memories of kind of getting to the great outdoors and upstate New York. So I’m glad you got to get away from Manhattan. So awesome. Jon, like I asked most of my guests on the show, just so people can get to know you a little bit better.
If you can give me a little bit of a brief history of your background, pretty much how you got to be where you are today.
Jon Thornton: Yeah, so I got started with programming when I was 12 using the view source option. Gosh, I think it was internet Explorer three at the time. Oh, wow. Maybe dating myself a little bit, but I was a self-taught programmer in high school.
Got some odd jobs, building websites for local businesses. When I went to college, I kind of foolishly thought that I had already learned everything about programming. And so rather than studying computer science, I studied electrical engineering, learned a bit about hardware, and that was a fun experience.
But after having a career in software. I realized that it would have been nice to have a more academic grounding in computer science. After college, I kind of stumbled into co-founding a parking company. I had done a senior thesis project on building little sensors called moats that could detect if there was a car parked in front of a parking meter and the natural extension is built an app that tells you where all the free spots are and ended up working at that startup for eight years, bootstrapped it for awhile, got to do front end backend database administration raised a bunch of VC money.
Burned myself out, took a bunch of time off after that and realized that I had a bunch of like mentorship gaps. Basically. I’d been self-taught my whole career. Yep. And so deliberately decided to go find a company to work for had an engineering organization. I respected a place where I could get mentorship and worked at a couple of smaller companies in New York city, worked with some great managers, learned a ton, and eventually ended up at Squarespace where I got this amazing opportunity to build a new product and a new team at a company that already had an established and successful product.
So I got to build Squarespace’s email marketing, product, email campaigns, launched that. And since then I’ve been supporting some other projects at Squarespace. Y eah. Yeah.
Christian McCarrick: Well, great. And I’m pretty thorough, usually Jon, in my kind of digging into people’s backgrounds and I completely missed that about you probably cause I do this on the side. So my day job tends to turn into my night job sometimes as well, but I’m putting two together now, Jon and I thought I knew why your name sounded so familiar. I actually had started a company called Parking Karma.
Jon Thornton: Oh, Whoa. So small world.
Christian McCarrick: Yeah, completely. So we can have that discussion maybe offline, but certainly again, I normally am pretty thorough, but I didn’t kind of go that far back and your bio at this point. So anyway, I don’t need to kind of borrow from our listeners about this, but totally. I think it’s a very small world as it gets to technology and startups, which I kind of, it’s just a theme that always happens. So. Awesome. Awesome. Great to finally meet you. I’ve heard about you and stuff for years. I didn’t put two and two together, but yeah.
Awesome. That’s a total other thing we can discuss later, right. Okay. So one of the things, and I appreciate the background on that. I think, again, I do this again and again, just to make sure that people understand there is no true path to how you get into technology, how you get into software engineering, and then also how you get into software engineering leadership. If that’s kind of the path that you choose to get into, right? Yeah. Yeah. So we kind of talked into a little bit, you just kind of went over how you got into sort of being the manager, but when you went into being the manager, you had a kind of a roundabout way to, you started to sort of a company and then you were maybe instantly a manager.
And then not that you didn’t kind of go through like, Hey, you an, I guess you were an IC, but what were some of those mistakes you made early on? You said you had gaps in mentorship. Like what might some of those have been?
Jon Thornton: Yeah, yeah, exactly. Like you mentioned, when I started a company. I didn’t really think too consciously about moving into a management role.
I just thought, “Oh, I’m the founder. So therefore I’ll be the CTO. Therefore I’ll be the manager.” And it didn’t really introspect that decision too much. And also didn’t really understand that there was a whole practice of management and a lot to learn there. So right off the bat, one of my first big mistakes.
My first hire, I knew I needed help building more features and supporting the system we were building, but I didn’t really do the work to define the role before I hired somebody. And once that person was onboarded, there was a total mismatch of expectations about what needed to get done. And it was really uncomfortable for me.
It was really uncomfortable for the engineer hired and it ultimately didn’t work out. And that was right away. My first big lesson that when you hire somebody, you need to have a plan. You need to know what that person’s role is.
Christian McCarrick: Yep. Yeah, that’s a pretty good advice. And it’s something I think I didn’t consider right away to hear about writing a job description. And I think that’s the only half of it as well. Right. I mean, there’s the, even my engineers today or my managers today, I need to hire and it’s unclear, like trying to go into a little bit of depth, like, why do you need to hire, like, what is this problem? This person is going to solve. How are they going to fit in with the rest of the team?
How are they going to combine to make something additive versus negative? Cause that’s a strong possibility as well.
Jon Thornton: Yeah, totally.
Christian McCarrick: Now, I think if there’s a path, you know, you’ve gone through this path, anything you would’ve done differently along the way?
Jon Thornton: I certainly would have tried to build a stronger network of mentors while I was running my startup company. Once we had VC funding, we got connected via our investors to some advisors and they were super helpful, but. We were bootstrapped for almost five years before that. And I definitely should’ve put a lot more effort into building my network of not just peers, but people who had walked this path before and could kind of help me understand what was coming down the road.
Christian McCarrick: Sure. Yeah. No, I totally agree with that mentors for every aspect, right? I mean, multiple ones, one for leadership, for business decisions, for raising money, for all sorts of things. I think it’s important to sometimes stop and just raise your hand and seek help, because that can cause you right. If it takes you a day, maybe to sit down and just kind of network with people or send cold emails or try to work through introductions that can save you millions of dollars and tens of hundreds of hours of sort of work or rework later, uh, you know, like teaching yourself can be quite satisfying, but it can also be quite expensive and time-consuming.
Jon Thornton: Correct.
Christian McCarrick: Yes. Yeah, absolutely. As a leader now, Jon, how do you advise any new managers making the transition? Like if you had any that were going to be kind of coming up, what are some of the tips you would give them?
Jon Thornton: Yeah, I think a big one that helped me was realizing that in a management role, it’s not about your individual output. It’s about the output of the team that you’re supporting. And once I realized that for myself, it was helpful in shifting the things that I spent my time on rather than trying to. Plug all of the leaks in the team or a common phrase I hear with managers is being a human shield for the team. And I realized that that wasn’t the kind of manager I wanted to be, kind of wanted to get out of the way and focus on how do I make the people on my team and the team itself as productive as possible and not make it about the things that I’m doing directly.
Christian McCarrick: Yeah, definitely. Definitely a good point there. Now, as I do with all my shows, I kind of want to focus it’s on a specific area. And one of the reasons I reached out to you, Jon, I had seen a talk you had given with the lead dev and some of the other things you’ve written online about the topic of good technical debt.
And I think in some cases that can be somewhat link baity. Right. But I think also there’s some validity to it, so I’m sure all of my listeners possibly should know what technical debt is, but I also have people that listen that aren’t necessarily in technology. So if you could kind of give your definition, Jon, of what does technical debt mean to you?
Jon Thornton: Yeah. So I think that the more commonly accepted definition I’ve heard when talking to other engineers is really. Code that you don’t like, and that you feel like you’ll need to change later, need to fix. And I tend to think of it with a bit of a narrower definition, which is work that I expect to have to do in the future on a particular piece of code.
And that typically means like scaling work or work to better factor something, but not necessarily just code that. I don’t like if it works and it doesn’t have to be changed. That doesn’t mean it’s tucked up.
Christian McCarrick: Yep. Yeah, that’s an awesome, I think sometimes people do want to have perfect code in every nook and cranny of the code base, but that isn’t always is worthwhile from an ROI standpoint, other than some personal satisfaction someone has, but it’s not really going to make any money, any money or provide more value to customers.
Jon Thornton: Right, right.
Christian McCarrick: Now you also mentioned Jon, the difference of financial debt and technical debt. They’re not always seen the same way, right? One tends to have a negative connotation and one can potentially have both. Can you explain that a little bit?
Jon Thornton: Yeah, well, financial debt is a pretty commonly accepted thing. If your friend goes and buys a house and takes out a loan to buy that house, you’re going to congratulate that person. And that’s it very reasonable, responsible use of debt to acquire something now and sort of pay for it over time. And the analogy that I’ve tried to use when thinking about technical debt is you can do the same thing. You can use technical debt to get valued now for your team or for your users. And then you can pay that down over time.
Christian McCarrick: Yeah. That reminds me of a popular book that came out a little while ago. I think it was called Bari way to wealth. Right. And the premise is using that debt to provide leverage that can help you provide value now.
Jon Thornton: And in the future. Right, right, right. It’s a tool, you know, it allows you to reorder when the value and when the payment happens and the trick is to use that tool responsibly.
Christian McCarrick: Exactly. And you also mentioned, and I like this term sort of time is our currency, especially as software engineers. And what do you mean by that? And how does that apply?
Jon Thornton: Well, when you think about starting an engineering, a new engineering project, typically you’ll be doing some estimates. And often the words I hear people use around that is like, how much is this project going to cost us? And that’s typically in terms of man hours or engineering weeks, or how long is the team going to spend building this thing?
That is the cost of the thing. So you can sort of use time to do your accounting. If you’re following this financial debt analogy where you can say, okay, we’re going to take out a tech debt mortgage, and we’re going to kind of borrow some time that we will then pay back later. And ideally you’re doing that in a way that creates more value than if you spent the time on that thing now and got the value later.
Christian McCarrick: Yeah, no, exactly. And I think the interesting thing that sometimes I think us in engineering, especially maybe specific ICS and engineers, that the main reason that we exist is really to provide value. We’re providing value to maybe our shareholders, our company, the users of our product. Right. We wouldn’t exist without that.
And I’ve always find it. Some things I coach and some of the managers I coach too is, but yeah. A common scenario is a manager taking over a team from another company. Right. And immediately being presented with what’s clearly going to be some sort of technical debt or risk, right. That is accumulated over the years, right? And how would you manage, how would you kind of coach one of those managers when they come into a new team to kind of evaluate like, Oh my God, how could this decision have been made? And clearly decisions were made at the point in time. I usually, for a specific reason. Right, right. But how do you recommend kind of new managers coming in and hurting a coal-based base and then looking at what they should do with it?
Jon Thornton: Yeah. Well, ideally you can talk to some people, or you can read some commit history to better understand how you ended up with the system that you have today, because there’s almost always a reason for these things, even if. That reason gets lost the time. Yeah. But I think the next step I would do is to try to assess what kind of technical debt you’re dealing with.
And I typically sort it into two groups. Technical debt is actively accruing interest, meaning you are either actively spending time on that technical debt with bug fixes or other maintenance or it’s technical debt that is growing larger. And you’re not necessarily paying interest on that debt, but it is.
Growing. And an example of that would be an API that, you know, has some design issues with it. And if you continue building things on top of that API, it’s just going to get harder and harder to evolve later, versus other kinds of technical debt where perhaps there is. A scaling issue where your performance is.
Okay now, but you know that six months from now, you’re going to run out of disc space or your database. Won’t be able to support the amount of data you have. And in that case, you have a few more options because your debt isn’t increasing literary leader exponentially with time. You know, you have some more time to maybe not work on that technical debt and do some other things in the meantime.
And maybe three months from now is the right time to address that debt. So I think. Once you have the history sort of establishing the urgency with which you need to address that debt is kind of the next step.
Christian McCarrick: Yeah. You made a couple of good points there, right? Kind of assessing the urgency as well as the time is the time right now, the time to deal with that, because there might be some valid reason that this should be dealt with, but there also should, could be a competing.
If you don’t launch this new product, you’re not going to get your next VC round. And then by, by tech debt, you don’t have to worry about it anymore, but you had to get a new job too. So yeah, certainly I think those are definitely two points, two good points you made there. Now, as we kind of flip on the kind of the technical debt side and some of the negative aspects to it, let’s talk about the good technical debt, right. And you say good technical debt is intentional. So when you talk about being intentional with good technical debt, what are some of the things you mean by that?
Jon Thornton: One example from a project I worked on at Squarespace is that we had this access control list where only certain people were supposed to have access to certain features and the, probably the right way to build this would be to have a database table and maybe a management UI or some end points that would make it really easy to add, remove people from that list.
But we realized that the list didn’t change that frequently and it didn’t need to be updatable. Within the minute. And it would be a lot faster for us to just have a hard-coded list of IDs and our code base. And if we needed to give someone else access, we would just go and make a new commit and deploy that.
And that was fine for the first two years of the project. And it allowed us to take the time that we would have spent setting up that database table, building that UI. We were able to spend it on things so that we’re more immediately valuable to the project we were working on. And then two years later when updating that hard-coded list got to be a bit of a drag, then somebody could go in and make that list a bit more dynamic.
Christian McCarrick: Sure. Circling back to your sort of time is currency comment. You only have a certain amount of that currency Ika time. So let’s spend it on things that matter to them.
Jon Thornton: Yeah. And I have a really strong philosophy about trying to do the riskiest parts of your project. First, a lot of this. Idea of reordering the thing reordering the way in which you build things is to enable you to tackle your riskiest parts of your project first, because with any project there’s usually going to be some problems that you have to solve that are going to make or break the success of that project.
And you want to figure out how those things are going to go as soon as possible so that you have as much time to deal with any of the consequences of those things. So going back to the hard-coded list example, managing that list was not going to make or break our project. And so building it. Didn’t de-risk what we were building in any way.
But the email editor that we were building was going to make or break our project. And so that was the thing that we wanted to spend time on first, get that problem solved before we move on to the more mundane things.
Christian McCarrick: Yeah. I think that’s definitely a great cause then, you know, a lot of the stuff we do is time on task. Like it’s not complicated, it just takes time. Right. And others are. Right. You don’t know if it’s ever going to work. Right. You don’t know how are you going to solve it. Right. Right. And sometimes you might realize you can solve it and that’s okay, too. Right. Because then you’ve learned a valuable lesson instead of spending months doing the work that was just menial.
Jon Thornton: Exactly. Exactly.
Christian McCarrick: Cool. Now, one of the things you kind of talk about. You’ve brought up some of the items and how you’ve used this at Squarespace. You also talked about a framework for utilizing some of that good technical debt, a little more on one of your blog posts. You talked about a couple of things. And then you talked about specifically about kind of building out and overhauling your email campaign product there. You talked about things like scaffolding, hard coding, edge cases. Can you kind of go into some examples of maybe each of those that make. Kind of good use of this good technical debt.
Jon Thornton: Yeah. So all of these techniques, scaffolding, edged cases, hard coding things, or even building things that aren’t necessarily scalable are all based around the idea of accepting that. Sometimes it’s okay to build something twice and using that to help you reorder the way in which you build things and scaffolding sort of inspired by.
Physical buildings, where sometimes when you’re building a structure, you need to build a temporary structure to support parts of it while you’re constructing the rest of the building. Later on, you’ll take down that scaffolding and maybe replace it with something more permanent. And the software version of that idea is pretty similar.
Where with the email campaigns product, we knew that we’re going to have to be able to send billions of emails, but we didn’t need that capability to test out the email editor that we were building. And we really wanted to build the email editor before we built the sending capabilities, because in a way the sending capability has felt a little bit more like plumbing.
It felt like there was less innovation to solve there. And so we built an incredibly un-scalable email delivery pipeline that allowed us to test and internally dog food, our email editor, and get a headstart on that before we built the real scalable delivery pipeline and big part of that was everyone involved, accepting that we were going to build.
This delivery pipeline twice and making that successful meant bringing along the product and design team and the rest of the stakeholders of the project to say, Hey, look, we’re deliberately doing some throwaway work, but here’s why we think it’s valuable. And even though we have this prototype that can send emails, everybody needs to remember that we still have the work to build the real email pipeline on our timeline.
So don’t forget that that work exists. We have this debt that we have to pay down.
Yep. Now, that brings
Christian McCarrick: up a good question. And I’ve run into this before, too, especially when you’re dealing, maybe with CEOs or VPs of sales or sort of companies like that, and they see something working like it’s hard for them to understand that no, that is a prototype. Suddenly the prototype becomes the product, right? What are some strategies to sort of making sure that that’s very clear that it’s not the case and then getting that support to me is able to go back and like build it the right way.?
Yeah. If it’s a
Jon Thornton: user facing feature. One tactic can be to deliberately build it so that it doesn’t look right and make it really obvious when you’re deliberately using tech debt. That’s a bit harder to do on the backend, but kind of one social tactic we used is that we celebrated the tech debt and, you know, the team kind of took pride in how quickly and sort of slapdash, they built this thing.
And just by socializing it a lot and everybody talking about it that helped us create that awareness that we were still going to have to build the real thing later. Yeah, I think that is pretty good. I’ve never thought about that. Kind of usually a strong visual indicator. Cause usually it’s someone who sales, who gets a whiff of something and it’s like, pre-selling the thing you have right before it’s ready.
But if it looks unready, then, then they might be like, well, we can’t ship that. And if that’s right, that’s the point you can’t ship them. All right. Yeah. It’s important to call out that these techniques really only work on a team that is able to be very deliberate about how the team spends their time and how they schedule things. If it’s a team that is struggling to hit their sprint commitments or struggling to complete projects and the expected amount of time that team often won’t have the trust of their stakeholders to make these kinds of decisions. And so you got to start with a solid founder.
Christian McCarrick: Yup. And I think you hit it very close to that trust. That’s such a big thing, getting that trust between not only your team, but the related teams and the rest of the organization as well.
Jon Thornton: Yeah, absolutely.
Christian McCarrick: Another thing too. And this, this comes up, there are some very dogmatic engineers and everything has to be built the exact perfect way, whatever that happens to be in their head versus cutting corners. Quote unquote, you can’t see me doing that in the air. And how do you, you, as a manager, kind of, what are the conversations you have with individual p eople or teams to sort of, kind of explain what the purpose of what you’re doing and why we’re doing it and why this is actually the good thing for right now?
Jon Thornton: In that conversation with engineers, that trust is again, really important and reassuring the engineering team that they really will have the opportunity to build these things, quote unquote, the right way when it is the right time.
And building that trust takes time and it takes an already good approach to the team’s existing tech debt. And some tactics I’ve used for that are having teams devote 10% of their time or one day out of the two week sprint to just work on tech debt that the engineers want to address. And that also sort of sidesteps a prioritization problem of in the sprint.
Do we prioritize product work or tech debt work? Sure. Instead we sort of just carve off some time for it. Another tactic that we’ve used is scheduling whole sprints to deal with tech deck. If we know that we took out a tech debt mortgage to ship some value to our users, we will put on the timeline, a sprint or two to pay down that debt after we’ve shipped those features.
Christian McCarrick: Yeah, no, that’s definitely good. And do you have any framework from a prioritization standpoint about how you kind of tackle that tech debt. Is it every engineer just picks their favorite one or do you have sort of an ongoing backlog? That’s like, here’s our highest interest at the top and you maybe the lowest ones down to the bottom.
Jon Thornton: It tends to be more, every engineer picks their favorite one, but we will frequently meet. As an engineering team kind of separate from the product and the design team to go through the backlog of technical items and just talk about them and socializing the different ideas of what each person thinks is the most important technical thing to work on is a good way to help the team coordinate and calibrate on what the team actually thinks is the most important thing to work on rather than just like a collection of individuals.
Christian McCarrick: Yeah, that’s cool. I think that’s a good way to do that. Jon. I ask all my guests on the show, any recommendations you have for books or podcasts, either something you’ve read recently, or, you know, some books that sort of changed the way you think about things, anything you might recommend?
Jon Thornton: Yeah, well, I wanted to plug two of my coworkers blogs. Tanya Riley is a principal engineer at Squarespace has a really brilliant blog at noidea.dog. Okay. And Dan Na, another coworker of mine blogs at blog.DanielNa.com. They’re both totally worth checking out. But as for books, a couple of years ago, I read a book called Nonviolent Communication by Marshall Rosenberg and it’s not about management, but I found it.
It really did change the way that not only I communicated with other people, but it helped me better understand my own thoughts, my own feelings and reactions to things which has been super helpful in stressful situations that arise at work.
Christian McCarrick: Yeah, that’s excellent. I think there’s always a theme with a lot of the management books or just books in general that people recommend and a lot of them are not necessarily about management, but I would say there’s a huge cluster around communication. And I think that just shows how important communication is as well. Part of a manager’s and a leader’s job.
Jon Thornton: Yeah. I mean, it is the job if you ask me.
Christian McCarrick: Yeah, absolutely. And Jon, if anyone wants to kind of follow up with you about any of the topics we discussed on the show, what’s the best way for people to reach out to you?
Jon Thornton: JonThornton.com. My website is links to my writing and all my contact info.
Christian McCarrick: Okay. And as usual for all my listeners, All of the things we’ve talked about in the show, I will put on the show notes for simple leadership.io. Well, Jon, appreciate your time. I know we’re all super busy and thank you very much for being on the show.
Jon Thornton: Thanks for having me Christian.
Thank you for listening to this episode of the Simple Leadership podcast, hosted by me Christian McCarrick. If you’ve enjoyed the show, please subscribe and don’t forget to leave a review on iTunes, full show notes, and additional information can be found on simple leadership.io.
If you knew someone who would be a great guest for the show, or you want to share your own experiences, please drop me a line. We’ll see you back next week for more technology, leadership tips and advice. As I interview more top software engineering leaders. .