Why You Need to Make Yourself Redundant with Hrishi Dixit, Principal at Gordian Labs

(Intro Narrator at 00:00:00) Today, we're talking to Hrishi Dixit, Principal at Gordian Labs, about making yourself redundant as a tech leader. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:16) I want to get into this how to make yourself redundant. And I think I saw you did a blog post about this. Is that correct?

(Hrishi Dixit at 00:00:25) Yeah. Well, I had the beginnings of one. So I made note of that in a blog post, and I wanted to expand it out. But I thought this was a lot more interesting and fun way to talk about it. And then maybe I'll do a blog post following that as well.

(Joel Beasley at 00:00:41) So how do you do it? And I know that there's a lot of hesitation. There's definitely some people that are listening that are early in their career, which is completely fine. And they're not entrepreneurs, like solo founder type people. They're just running an engineering team or software project.

(Joel Beasley at 00:01:00) And for those people, I have found they've approached me privately and have given me, essentially, the feedback that they're kind of scared. They're scared. Like, what if I am redundant? What if I'm not useful? I need to always find ways to make myself completely ingrained in things so that I'm valuable and I don't get cut if there's cuts and so that I'm absolutely needed.

(Joel Beasley at 00:01:21) I don't see that problem with the entrepreneurs. My job as an entrepreneur, it's like I'm trying to scale this thing. So the goal is figure out how the process works, operate it successfully, hand it off. Give it to somebody else who can then manage it and be intelligent and change it as needed. And that way, I make myself redundant out of the process.

(Hrishi Dixit at 00:01:40) Yeah. That's something that I sort of learned on the job. Part of it is, so how do you do this? I mean, we can do the four ways to make yourself redundant, and there are actually some very key steps that are involved there. And it sounds simple, like four steps, but they're actually incredibly difficult. At least they were for me. But so the first thing is, before we jump into that, I think the reason to make yourself redundant, we're very clear about why. And if you have a hesitation about that, like, what is the reason you're hesitant to make yourself? I mean, job security is the obvious reason. But is that really the reason you want to continue being at a place? Because you're afraid that what you bring to the table may be difficult to port over. I'm speaking in the context of my own skill set and my own role as a CTO. I totally understand this. There are others that are so bespoke that it is important. But for me, I never felt comfortable being in a place and continuing to be in a place and hanging on to that role through any means possible. And the easiest one to do is just like, I'm the only one who knows a password to this provider, or I'm the only person who's built this particular relationship with this vendor or that provider. And it's kind of self-destructive, and it's also not fair to the business or the company that you've helped grow. And, again, depends on what stage you come in.

(Hrishi Dixit at 00:03:29) There are career roles, and I totally respect that. The kind of work that I like to do, which is get something off the ground, that's what I've done most of my career, both as an engineer and then as a tech leader, to get something off the ground. That's a freaking rush. That's adrenaline. You know?

(Hrishi Dixit at 00:03:51) And when you get to a certain scale, the nature of your role changes, and you're not building anything more. You're doing important things. You're managing a team. You're creating and sustaining the culture. You're evangelizing your business. All of that is important. But, you know, that early stage rush goes away. And to get back, the only way to do that is, okay, we can get so big that you can carve up a little incubate, a little startup within a bigger org and be that for that little unit. Most often, you're just moving on to the next thing. Right? So, like, what are these four things? Some of these may sound obvious, but if I have to just rattle them off, so first start distributing knowledge. Any concentration of how things work or where things are, just build a knowledge base.

(Hrishi Dixit at 00:04:43) Since day one, and this is certainly not limited to a CTO or even engineering. You want this everywhere in your org. And there is a very easy correlation to system design as well, which we'll get to. But start distributing your knowledge and start de-weeding yourself. You know, the more you are in the trenches, and this is a natural evolution of a startup early stage CTO where you are the trench in the beginning. You're literally the person who's not only coding, you're designing, you're fixing the router, you're doing all of it. Right? There is no one else or maybe very few others. The moment you hit some kind of stage, like Series A is kind of a de facto milestone in my head because that's how it's worked for me. Sometimes it may be later, sometimes even sooner because now these days, people are raising $100 million seed rounds. It blows my mind. But when you get to a point where you can see the scale ahead of you, start getting yourself out of the weeds. Now that itself takes multiple shapes. The obvious one is start building your team.

(Hrishi Dixit at 00:05:53) You can't take yourself out of the weeds unless someone else is in the weeds, obviously. So start building your team. But the most important thing, this is the third point, there is a tremendous amount of talent around. You'll build your team no problem. Especially if you have the resources to get top talent, you're going to get it. It's really, really hard to find good engineering leaders. This is my experience. And what you really want to build is the third point. You want to start designing the leadership of your org.

(Hrishi Dixit at 00:06:21) We had a very well defined, and it's an evolutionary beast as well. It changes over time, but we very early on took the time to design the entire technology organization at Illustrator and even before that at LearnVest. Like, this is how, and these are just boxes with labels, but not just like, hey, here's a title. Here's a cool sounding title. There was a detailed doc that went behind it. We actually drew inspiration from CircleCI's little chart of, like, get shit done, tech competencies, management skills, blah blah. So we had the management track. We had the IC track. We even had a middle track for a little bit, but that just got too complicated, so we kind of simplified it. But build your leadership layer because that's the beginning of your transition plan. That's the beginning of your succession plan. It's really hard at a certain scale for an external CTO, especially CTO, because, A, that's my experience, and B, engineers are weird, weird people. They are, speaking as one. Like, I'm weird. For me to respect a new leader that's coming in off the call, I'm going to spend a ton of time just being in a grudging benefit of the doubt, overlaid with suspicion. I'm going to set the background, then poke to see their tech competencies. The smoothest track is someone who's entrenched in your org already, who is immersed in the culture, immersed in the technology, immersed in the platform, and has the essential leadership skills to kind of grow into that role.

(Hrishi Dixit at 00:07:54) So building that second layer of leadership and you identify, okay, the classic hit by a bus exercise, like, who's going to take over, and what do they need to know that, so we had that. We started building those, I started building those structures and the people. And some people don't want to do it. Some people, they just love the engineering. They just want to, you know, I totally respect that, absolutely needed. But it's almost like a unicorn type role where someone can simultaneously be a solid engineer because that's who the team is going to trust. You maybe scale to 25 to 30. Anything under 25, you can still adjust. Again, these are empirical numbers, maybe a bit different.

(Hrishi Dixit at 00:08:41) But you get above 20 or 25, you have created a certain ethos, a certain zeitgeist, a certain culture in your org. It's really hard for an external entity to fit into it. It's possible, but it's really hard. Your best bet of minimizing disruption is to internally promote someone who's already immersed in that culture, who's not just immersed, but also has had a hand in shaping it. And that's, I mean, I spent a little time on that third point, but it's a good segue into the fourth point: that culture. Because that's the thing that's going to outlast you and your successor and everyone else. That's the thing that keeps people. It's important for retention.

(Hrishi Dixit at 00:09:21) It's important to screen. If you decide that, okay, I'm going to get Diversar or someone to get the next CTO in, how do you even vet that person? You're going to see their background. You know? Oh, this is like, he or she has been at these great startups, and it's like, that's great. So the tech chops are spoken for. Will they fit in? And you don't know if they will fit in if you know what fitting in looks like.

(Hrishi Dixit at 00:09:48) And the core of that is in the culture that you set. It's the hardest thing to build and sustain. And it takes a day to brick it, and it'll take a year to rebuild it if you brick it. So those are the four things that just to kind of summarize: the basic distribution of knowledge, create this vibrant knowledge base, start getting yourself out of the weeds, which is just scaling your team, but start designing your org leadership. That's your succession plan. And start laying down very early on, like day one. This starts on day one. Start laying the foundation for your culture. What is the culture you want to build? What do you tolerate? What are the guardrails? What will you not stand for? I've fired people in the past who are brilliant engineers who just didn't play well with the team. Like, they didn't fit in. It's just they are—

(Joel Beasley at 00:10:44) Look at the Navy SEAL guys. Right? They select for your ability to put others ahead of yourself, and they select for your ability to make the team successful and not you as an individual. So a lot of really talented individual people get kicked out, and they don't make it through because they don't have that ability to bond and achieve it together.

(Hrishi Dixit at 00:11:04) And it's actually, like, being able to sense that bad hire, like, you'll make, you'll have the bad—

(Joel Beasley at 00:11:13) You're always going to have—

(Hrishi Dixit at 00:11:13) You're always going to have. But knowing that, okay, well, this goes counter to everything, every mode of interaction that we've cultivated over the years. Like, what is the mode of engagement? How do we talk to each other? What words do we deploy? What words do we stay away from? The tricky thing with that sort of bad hire is if you're not able to detect that, which is difficult to if you don't know what, sometimes they just stick out like a sore thumb when you have a well-defined culture. You will lose half your team just in your attempt to either retain this bad hire or not even being able to realize that this is a bad hire. So part of this growing your org leadership, which was, again, the hard part. I mean, I would wish I had a crystal ball, but it's about, if you believe that your leadership style is the kind that will keep this team that you've spent so much time building and culture you're still building together, you need to, this is probably more than half of your time and effort at a certain level of scale where you're just making sure that your leaders, who are your culture ambassadors, like everyone is, you are absolutely in tune with them. You're talking to, you're having those one-on-ones every week, and you're talking not just about, like, okay, hey, do some cost cutting here or do some optimization there.

(Hrishi Dixit at 00:12:47) But, like, hey, we had these OKRs that I laid out for both for myself and also my team. Like, okay. You need to have, you being, let's say, one of my directs who may be someone that I'm hoping will be able to take over, you need some executive presence. You need to be, you need some face time with the C-suite. We need to be in the leadership team. So I'm going to create these opportunities for you to present what you're, like, I can easily go and present something. Like, they're doing the work. This is part number two is de-weeding. Once you're out of the weeds, you don't know the details. If I look at a stack trace in a log on a Grafana dashboard, in the first few months, I'll know where to go and fix it. Two years in, I have no freaking clue. But I'm not supposed to. It's the right thing that I don't know. But I also take comfort in the fact that the people that are looking at it and that do know what that means and how to address that are people that I've almost handpicked and made sure that are the right kind of leaders that will be able to take over in difficult situations.

(Hrishi Dixit at 00:14:09) And it's weird because beyond a point, your job primarily becomes providing air cover for your team to do the best work. Once you have built your team and made yourself, taken yourself out of the weeds, what you need to do is get out of the way. And—

(Joel Beasley at 00:14:25) But that's hard. But that's hard.

(Hrishi Dixit at 00:14:27) It's really, really hard.

(Joel Beasley at 00:14:28) I've seen so many people, Hrishi, who, like, I want to make sure I say this correctly and anonymize it enough to not call anybody out. But they'll be a CTO. They'll get to that point, 20, 25 people. They'll see that error. They won't know where to solve it. They'll be upset that they don't know where to solve it. They'll think I should. I run this whole thing. I need to know where everything's at. And then they just go down this rabbit hole of trying to be an IC again, and then they're completely neglecting their leadership skills and leading their team. And instead, they end up micromanaging and getting involved in the weeds of something that, and then they think that they're doing a good job. They think I need to know this. I need to solve this. But the way it comes off to the people that are the contributors on that project is that you don't trust them.

(Hrishi Dixit at 00:15:16) Yeah. You're failing at your job if you find yourself doing that. And, again, this is, if that's what you really, really like to do, which, again, is totally respectable, you're in the wrong place at that point, which makes the whole making yourself redundant even more important for you. Because, hey, if you like to chase a bug down the rabbit hole and figure out what's going on, find your next gig. You're asked to do that.

(Joel Beasley at 00:15:43) There's another thing I've seen emerge too after talking to so many people. So the individuals that really, really like the coding and they want the title of CTO, so they'll be like, "I want to do this all day, but I want the title of CTO." And I say you can have both, absolutely.

(Joel Beasley at 00:15:59) You just have to make sure whoever's responsible in the org for that type of role emotionally and structurally exists. Call them a VP of Engineering. Call them a Chief Operations Officer. Doesn't really matter what you call them. You can keep your CTO, go grab three to five people, and then just build edge case stuff or build the future, the next iteration that's completely independent from the current business.

(Joel Beasley at 00:16:19) So some people have figured this out, and I've seen them do it, and they've done it very successfully where they have this Office of the CTO.

(Harishie Diggsen at 00:16:26) Of the CTO, yeah.

(Joel Beasley at 00:16:27) Yeah, and it's fantastic. But other people are really struggling.

(Harishie Diggsen at 00:16:31) Yeah.

(Joel Beasley at 00:16:31) They're like, "I don't want to do this," but they haven't figured out the Office of the CTO thing yet.

(Harishie Diggsen at 00:16:35) Yeah, and also I actually wrote a sort of—I don't want to call it a position paper, if you will—an idea, a proposal for the leadership team back in the day where exactly this. How does my—because we had gotten to a point, I had 30 people on my team. Virtually every single person on that team was a smarter engineer than I ever was, and I have no doubt about it.

(Harishie Diggsen at 00:17:01) That's the whole point. You want people who are actually smarter than you to run this thing. They want the guidance. They need the air cover to do their best work. But if you're not hiring people smarter than you, you're not really doing your job well either, because—but I wrote this thing.

(Harishie Diggsen at 00:17:20) Okay, well, these guys have it covered. They got the platform. I've given them the reference frame, the context. I gave them, "We're planning on this level of scale. We are doing this. We are approaching this channel expansion in this direction, which may take traffic on this portion of the platform, so let's look at ways to make that more horizontally scalable," blah blah. The here's-the-problem-statement.

(Harishie Diggsen at 00:17:46) Now deploy your massive genius brain on it and figure out, and I would love to hear and be a participant in the discussion of the solution of it. But I won't even claim to—I'll ask questions because at the end of the day, I love this stuff. I'm an engineer. And I may make some recommendations here and there, but it's your thing. You own this because I trust you to do a much better job than I would myself solving this problem. That's why I hired you.

(Harishie Diggsen at 00:18:07) So then I wrote this Office of the CTO thing, and if you are able to create that, that's the whole making yourself redundant doesn't necessarily mean a path out of the company. It can be, or to your next gig. Your next gig may well be within the company. Not every company necessarily gets to the point where they have the full luxury—

(Joel Beasley at 00:18:33) Say it again. Say it again. I really actually want you to say—you are exactly right. Your next gig can be inside—

(Harishie Diggsen at 00:18:40) Inside the company, yeah. It's just not what it was when you started with this. You moved on to that. You've scaled it. You've done a great job building your team, building your leadership, building the platform, getting the platform to where you were. Hopefully you've done a great job, and now you're looking to do what's next, an R&D wing in your company. That's great, you know?

(Harishie Diggsen at 00:19:03) I have all of these ideas and thoughts that I wish I was able to do at DealStreet, but I decided to move on for family reasons. But there's still a document somewhere in DealStreet's knowledge base about Office of the CTO, and I hope the current CTO is able to get there at some point soon, in fact, because we really have an incredible team that we built over the years, literally crafted over the years.

(Harishie Diggsen at 00:19:35) Let's say you get the funding, right? You get the green light. You get the funding to do this R&D. We have this interesting project where you want to figure out how to use NLP and GenAI to actually do the deal sourcing. I'm using a DealStreet example just because that's more recent.

(Harishie Diggsen at 00:19:53) But that's a moonshot kind of thing, right? It's important to do. It's an innovation thing. It's a whole innovation wing and R&D wing of the company. That's a very common and beautiful, logical place for an early-stage CTO in a company to end up in the same company. If you can get that, then man, you landed in the right place. This is great. All the power to it.

(Harishie Diggsen at 00:20:20) None of the "make yourself redundant" bit is made irrelevant by that because you're still not in the weeds there anymore. You're not going to be in the day-to-day of that. Someone else is going to be. Who is that? How do you keep that running? Because ultimately that's what's keeping the company moving. That's the bread and butter. It's the search of Google.

(Harishie Diggsen at 00:20:34) So if someone wants to go and do Google Glass, something is paying for the Google Glass. It has to be the thing that you built. So you owe it to the team and the company to make sure that's in good hands when you're not around to manage it day-to-day, you know?

(Joel Beasley at 00:20:57) You know, an exercise that I can't remember where I got it from, but I implemented it and it worked, so it stuck with me. But it was defining what "done" looks like. So if I have a system or a marketing process at my business, it's like, okay, here's the system. It's a marketing system. The purpose of it is to generate new leads, and we need to build the system. Here's what "done" looks like. Done looks like the report that shows me A, B, and C, or whatever it might be. But working backwards like that, as you go through distributing your knowledge, de-weeding yourself, designing your leadership org and your culture, asking yourself that question—what does "done" look like for each of those?—I think that would get people 20% of the way there.

(Harishie Diggsen at 00:21:38) Yeah, I think the best way to do that litmus test of "Are you done?" is writing it down, first of all. So you look at your own day at that level of scale. Right? We're a CVC company at this point. We have 70 people in the tech org broadly. I think close to 70 now. Look at your day. I look at my own day, and I kind of maybe average a day over the course of a week or a couple of weeks and say, "Here's all the things that I did that I was called—that people came to me to talk to me about or I was asked to or decided to do, whether it's external relationships, whether it's some other department in the company that needed some institutional knowledge support, because you're still carrying that despite all the—you can't, despite all best attempts to document stuff, you're not going to get every little bit down on paper. You know, it's just not possible. There's too much.

(Harishie Diggsen at 00:22:03) The "Are you done?" will be demonstrated by putting—you proactively putting someone in that role and just waiting. For the next week, and I didn't quite do this in a structured way, but thinking back, that's what I would do, because I did it on sort of a need basis. But, hey, for the next week, I'm going to just redirect anything that comes to me. So let's say you identified who your successor is, right? You know who you think would be the best-positioned leader in your team to take over your role should that need arise at some point, and you just let them do it. See how they do.

(Harishie Diggsen at 00:22:33) So it's a massive amount of delegation and redirection, but it sounds like, "Okay, you're just trying to make things easy for yourself," and maybe there's a little bit of—

(Joel Beasley at 00:23:37) But you are, though. But that's the thing.

(Harishie Diggsen at 00:23:39) That's the whole point.

(Joel Beasley at 00:23:39) Right? That's the point. The point is to make yourself—you want to make your job so easy. I would love to have the conversation with my CEO and my board saying, "Hey, I am so good at my job that you guys don't even need me anymore. The thing that you decided you needed a CTO for, that justified the spend, that thing is autonomously running now. It's been solved. Do you need me to do something else?" If you get to that mindset and you get to that level of value, you will never, ever have trouble getting a job or joining a team. Because what is that CEO going to do, Hrishi, or that board? If they don't have a position or they don't have anything for that person, they're going to tell people to use them. They're like, "Hrishi was great. He came in here and he did this thing. He made himself redundant. It was amazing. You should definitely use him." And you can't hide talent. You can't hide talent like that.

(Harishie Diggsen at 00:24:29) This is the thing that gets me excited. If you're staying in there because you're like, "I'm not going to get a gig anywhere else," then you're proactively starting to underperform as a CXO, really, but again, CTO for sure, because of—and CTOs, we techies talk about this in a non-human context all the time. It's an essential tenet of system design for scale, right? We talk about system redundancy. We talk about transparent failover. We talk about single point of failure, resiliency. These are equally applicable to human capital as they are to systems, because systems and humans are part of the entire enterprise value of an org.

(Harishie Diggsen at 00:24:59) So if you have redundancy, we've had experiences—and I've had experience in the past in both Get Illustrated and elsewhere in other departments—where someone moved on for very, for their own reasons, other opportunities. I was the only person who was doing that job. There was no part—I tried to, I hope that's still—I'm pretty sure that's still happening—but I tried to do everything to make sure that there's no portion of the user platform that at least two people, ideally three, know how it works down to the semicolon and the indentation. This is how it works.

(Harishie Diggsen at 00:25:36) And then there is this expanding circle of, "Okay, well, there's this core set of three people who know deeply how that service works, and then there are some that have a high-level knowledge," and there's no part of the platform that is complete—what's the word for it?—left-field territory for anyone. Like—

(Joel Beasley at 00:26:19) Well, that happens, though. It does come about. People will say, "We don't want to touch it. No one knows how it works here," so—

(Harishie Diggsen at 00:26:26) We just don't touch it. Yeah, I don't know what's going to break. Yeah.

(Joel Beasley at 00:26:30) I mean, there are pieces of tech debt which—that happens, though. I did a conversation with somebody six or seven years ago, and they were telling me confidentially, so they abstracted the name of the power plant, but there was a power plant in Northeast United States where nobody knew how to modify or understand or read the code that ran the plant. And when it went down, there was this huge issue, right? Calling people out of the retirement homes and stuff, trying to find somebody that understood. Luckily now we have GPTs and LLMs, right, that can help us with this. But yeah, there's definitely the scenario that happens where things just die off.

(Joel Beasley at 00:27:18) How do you prevent—let's get a little weird here. At your company, do you care enough to monitor it, and if so, how do you monitor that every—there's at least a couple people that understand—is it—

(Harishie Diggsen at 00:27:32) Yeah. That's actually something that I recently posted about on my blog, and it ties into the ever-present beast of tech debt, right? Every piece of software—this is what I wrote on the blog. Every piece—people say you have to manage tech debt, and it's slowing our shipping velocity. This is all true. Tech debt's real. Stuff happens. The thing is, absolutely any piece of software that you write that goes into production and has to be maintained from the day it goes into production starts its life as tech debt.

(Joel Beasley at 00:28:05) Correct.

(Harishie Diggsen at 00:28:05) It's only a matter of time. Think of this horrifying thing: there's entire banking systems that are still freaking running on mainframes with COBOL. Do you know how many COBOL developers there are in the world? Actually, I don't know. There's probably double figures in the entire world. What happens when that generation dies out? There is no one who understands this stuff. I'm sure we can pick it up, we can get some out-of-print COBOL programming book.

(Harishie Diggsen at 00:28:33) So what do you do? You basically—and this is also hard to do, and we tried it. We managed to do a decently good job of it at DealStreet. I can't say I've been very successful with it over my career. I had fun writing that blog post.

(Harishie Diggsen at 00:28:54) But here's the thing: just like libraries are end-of-life, right? Versions are end-of-life. Every bit of software you write, part of the maintenance is end-of-life in it. Now that can take two shapes. One is just, no one's using this stuff. We built it three years ago. It's this little algorithm that I wrote up over an afternoon, and that feature has long since been decommissioned, but that piece of code is just sitting there. Just nuke it. Just get rid of it.

(Harishie Diggsen at 00:29:15) And the other thing is basically aging your software, even heavily used software. There are always—there's always a compelling case that you can make for rewriting something that, even if it's working, it's the natural evolution of software. Let's say your basic system, right? I wrote a login module in 2015, but it's still used to log in to your—my little ragtag, "Okay, here's how you do session management."

(Harishie Diggsen at 00:29:57) But one of the conversations that we started having last year was—and again, it's not complicated. It's freaking log-in. Anyone can write it, and you can read the code and you understand how it works. But as an example, is this—it's ten-year-old code. That's way too old. It should not be there anymore. What do you do? Okay, well, it's time to upgrade this. Let's use Auth0. Let's use some other provider. Let's upgrade that piece of software.

(Harishie Diggsen at 00:30:34) Particularly true for—and this is something that is also a part of your whole redundancy documentation thing. What are the absolutely mission-critical paths in your platform? You cannot make those stop working ever. No matter what, they always have to work. They have to work impeccably.

(Hrishi Dixit at 00:30:53)
You're an investment platform. You gotta be able to invest. You gotta be able to move money around. If you can't, that's a problem. So monitor those.

(Hrishi Dixit at 00:31:04)
Monitor the usage. Monitor their aging. See where they're — the software moves fast. There's a very good chance that something you spent a ton of time writing that's cranky, that's all convoluted code, someone has probably built an embedded version of that by now.

(Hrishi Dixit at 00:31:18)
You know? Take account linking. We spent a lot of time in LearnVest writing against Yodlee APIs to aggregate financial accounts. Right?

(Hrishi Dixit at 00:31:27)
You don't — it's all embedded software now. You don't have to do it.

(Joel Beasley at 00:31:30)
There's just — yeah. It's so easy now.

(Hrishi Dixit at 00:31:33)
So imagine the sense of liberation. The footprint of your maintained software base should not be monotonically increasing. It's a part of just regular — you should make it a habit-forming thing where you just make it a habit to actively look at old cranky pieces of code even if they're working and just end of life them.

(Joel Beasley at 00:32:02)
You know who does this a lot? Salesforce. So when I interviewed Parker, one of the co-founders, he had made some comment and I stopped him in the interview. I was like, you rewrite your systems? Like, Salesforce, you rewrite it every year?

(Joel Beasley at 00:32:15)
He's like, yeah. He's like, we constantly are just rewriting it.

(Hrishi Dixit at 00:32:19)
Wow.

(Joel Beasley at 00:32:19)
And I was — I asked him twice. I was like, are you sure you rewrite it? He's like, yeah. He's like, we are constantly rewriting the systems. We never stop redoing them. And it makes sense too, especially if you have something that's like a contact database and, you know, by the time you get another year around, there's some efficiency that's been gained in some new technology. And if you can implement it at the Salesforce scale, it's almost — it's financially worth it. Right? Because you get a small percentage efficiency across all your servers, and that cuts the cost. Right?

(Hrishi Dixit at 00:32:52)
It actually is — you said it exactly right. This is not just a, you know, protect yourself against obsolescence thing. It's actually a cost-saving measure. You know? Because you can divert a lot — it's just crazy how much time, over time, is spent in just maintaining things that are built. Even things like, I look at tickets sometimes. I used to, until recently. And I used to — why are we even fixing this? Who's using this? You know? Is anyone even — is this a corner use case that once was a thing? I'll give you an example. This is a bit of — and it's not IP or anything. So when we launched Yieldstreet 10 years ago, it was, like many platforms, invite only during just early days of launch. So when we launched it, you had to send in a request to be part of it that was vetted and then —

(Joel Beasley at 00:33:58)
They would call you. I remember. I remember.

(Hrishi Dixit at 00:34:00)
Yeah. So there's this whole access request module that I wrote. You know? Again, simple piece of software. It's still there. We've been not an invite-only platform for close on a decade now. It's not used. It's not hurting anything, but it's still bloating the code base. And it's just this, you know, piece of software. And we talked about this office of the CTO thing. Sure, part of that could be just doing moonshot projects, but it doesn't all have to be that. There is actually a lot of interesting software. If you're spending time making your team's job of maintaining the platform that you built increasingly easier, it's freeing them up to do new things. Because one of the very common debates and arguments that I've been a part of and I dare say other CTOs as well with your CEO or with your business leaders is —

(Intro Narrator at 00:35:03)
They just —

(Hrishi Dixit at 00:35:05)
We built the first version in three weeks. Why is it — it was two people, and we were able to do it in three weeks. Now you have 40 people. Why is it taking so long to do the simple thing? Because it was small, it was easy to do. When you have 40 people and you have 40 microservices as opposed to one app, the whole reason it's slower is because it's bigger and the team is bigger. It's like the whole Mythical Man-Month. Then it goes into that rabbit hole, which is not where I'm going. But the point is, if you can proactively create space in your development work, in your sprints, in your whatever, to say, I'm gonna — maintenance is not just about fixing bugs. Maintenance is about actually maintaining. And an essential part of maintaining, I'm just talking as if I did a good job of it, which I didn't do nearly enough —

(Joel Beasley at 00:35:56)
You did.

(Hrishi Dixit at 00:35:57)
Well, I tried to, let's say, you know, and we were reasonably successful because we rewrote large swaths of the old PHP monolith that we had written around 2019. They don't compete over all of the platform, which is great. You know, it's all broken down. And we've been chipping away at that old code base. So we did it reactively. You know? Not all of it, but a lot of it was done reactively because there are certain critical paths that we needed to scale. There are certain portions of the platform that were just — that needed to be more flexible than they were because the requirements around them changed. So external catalysts drove that maintenance effort, but it doesn't have to be. You can actually have a team, a platform team, an R&D team, call it what you will, create a unit, rotate people in and out of that so they get exposed to that. But keep looking at the footprint and keep looking actively at bits of code that you've written, and you have GitHub to help you. I know the last commit was two years ago. Is anyone using this shit? Get rid of it. You know? Or let's rewrite this. I just found this new provider that just does this as a service, and people use this maybe once or twice a month to update their phone number or whatever. We don't need to maintain this at all. Outsource that. It's a habit-forming challenge because the obvious and understandable impulse with every new piece of development, every new sprint, is to build new things, to grow new things, and make sure that stuff doesn't break. Build new things and — there's this whole gray space in the middle which hardly gets any attention until something breaks, and then it goes into that, okay, it's breaking, let's fix it. You can get ahead of that. And we kind of started from the knowledge redundancy part. But this is — the whole distributing knowledge, it's really valuable for this, the number one thing, to make it so redundant. When you rotate people in and out of the, quote unquote, platform team that's responsible for just health of the platform, just pure health. And part of that health is making sure it's fresh, it's new. Things that are not used are churned out. Things that are heavily used or things that are old are actively looked at and saying, okay. Is there a better way to do this? Go out and find out. And we have people who read a lot. There are amazing things. One of the best things I've subscribed to over the years from a, hey, what's going on out there thing is Changelog. And there's a lot of them — hack and use them — but Changelog is brilliant because it actually has, like, here are the active repos. Here are some of the things. And I can literally do a search on something that I'm trying to do a refactor on and — someone else has. Like, yeah, here's a library that does it. I understand you take on a little bit of risk there by externalizing something. Now you're relying on the maintenance of that library, but you make judgment calls around that. But in general, you age your software. You have to do an aging analysis of your software all the time to kind of keep it fresh. And that actually has a fringe benefit of helping distribute the knowledge of your platform. Because nothing gets you deep into the weeds of any part of the platform as rewriting it. You know?

(Joel Beasley at 00:39:32)
One of the things I would do when — so, I mean, I wrote software for 17 years, and it's probably been about five years I haven't been actively writing software. But when I would build a class or whatever it would be, I would — and I didn't do this all the time. I picked this up probably halfway through my career because I saw someone do it at a conference, like, live coding conference. And they determined how long they were — they determined at the beginning how long this code would live for. They'd say, okay. I'm writing this code for — it's gonna be three months. This code's gonna be useful for three months or two years, and then we're gonna rewrite the platform. So they set this expectation even in the comments on the model of, like, hey. This is just to get us to funding. We just need a quick and dirty MVP to get some buttons on the screen to get some basic stuff. So that's what we're writing this chunk of code for. And I thought that was really interesting. So I did my version of that going forward with the systems. And it was really helpful, but it's to your point of, like, it's determining the age before you even go about the project.

(Hrishi Dixit at 00:40:38)
Yeah. And that actually goes beyond just age. You can — if you're building a prototype to get funding, and this is the classic, and I wish I could claim that I did a good job for everybody. I bombed twice on this. Definitely not gonna do it for a third time. The little thing that you build to get funding, the little thing that you build, your prototype, your MVP, whatever. Not MVPs always, but your prototype to — you know? It's so tempting to just keep building on top of it and launch. And you end up launching something on Heroku that was written in, I don't know, Ruby on Rails. You get the funding, use it to build it for real. Build it for real. Right? And it doesn't mean play the whole thing, and not all prototypes suck as well. So just to be clear. But often the directive, and more often than not, it's a development partner. Right? You know, unless one of the founders is technical and she's doing it herself. The number of times prototype becoming product has been the source of original organic tech debt, not just in my own experience, but in my friends' experiences as well, friends who are similar, you know, early-stage CTOs. People write about it, how bad it is, what a terrible idea it is. But it's so — when you're in that kind of velocity of, okay, we got funding and we gotta launch and TechCrunch and — it takes an extraordinary amount of convincing the founders or whoever that hey, let's just take a little step back and do it right. Build it for the actual future and not — trust me, no production system should ever run on Heroku. What you said about aging the piece of software, it actually also helps around sizing it. So if it's not a prototype for funding, but actual a feature that you're launching, and this is the other thing that is the source of a lot of contention between business and tech is, why — here's, hey, we need to build this. How long will it take? You know, the whole estimation, which —

(Joel Beasley at 00:43:09)
Oh, that's always fun. Yeah.

(Hrishi Dixit at 00:43:11)
Yeah. At some point, someone will realize that it is absolutely impossible to estimate software accurately. It just doesn't —

(Joel Beasley at 00:43:19)
I know. Because they've tried — they've tried points. I've tried every software. It's just like, I don't know. You spend all this time figuring it out. It's like, I just spent a third of my time. I could have been doing it.

(Hrishi Dixit at 00:43:29)
Exactly. When you change that around and say, okay. Well, we don't know where this is gonna go. So I'm gonna build something that's so small that I know I could do it in three. So it's not — you're changing the question. You're not saying how long will it take to build this. You say, this is what you're trying to solve for. How long — what can you build in pick your window, three weeks?

(Joel Beasley at 00:43:46)
What's the least amount that you can build to achieve the outcome?

(Hrishi Dixit at 00:43:50)
Yeah. Now if — and you do that, you make sure that the experience is impeccable. You don't compromise on that ever. You're compromising — you're just trimming the feature set. And it's like, this is all. We don't need to do all of the —

(Joel Beasley at 00:44:05)
You're compromising with your inner nerd —

(Hrishi Dixit at 00:44:07)
Yeah.

(Joel Beasley at 00:44:07)
— that wants to build up and scale up. I mean — and we're so good at making things more complicated, aren't we? It's actually the hardest thing to do is to keep it simple.

(Hrishi Dixit at 00:44:18)
Simple. Yes.

(Joel Beasley at 00:44:19)
It is so hard to do that because when you — we're adders. We're creators. And so what's the answer to every problem? To create more.

(Hrishi Dixit at 00:44:27)
More. Exactly.

(Joel Beasley at 00:44:28)
You just create more.

(Hrishi Dixit at 00:44:29)
And this is something that I just recently wrote about. It's just — the one entity that starts getting almost marginalized in that journey is the actual user of your software. Because the more you complicate your system, the more you start impacting the end user's experience using it. And I wrote a post about eventual consistency, which, again, as a concept I truly respect, and it has its places and it has its virtues and values. But in a very tech-driven effort to make everything infinitely scalable, you stop to think about, first, does it really need to be? Are you really gonna be taking a thousand hits a second on this particular endpoint? But more importantly, what's it gonna look like when this update is gonna happen in a few milliseconds and not right away? When — what am I as a user when I click that button expecting to see something on the other screen and not seeing that on the other screen, on the next screen?

(Joel Beasley at 00:45:41)
Broken. So you just hit refresh a bunch.

(Hrishi Dixit at 00:45:43)
Yeah. Exactly.

(Joel Beasley at 00:45:44)
You know that.

(Hrishi Dixit at 00:45:46)
What I've realized after these two back-to-back, three back-to-back, I guess, CTO experiences, and I'm sure there'll be more, is that no matter what you're building or who you're building it for, the core challenges, the core points of contention, whether it's between your engineering org and the business, whether it's within the engineering org, between product and tech, et cetera, they're all almost the same. They're so completely portable. I advise a bunch of startups as well, and the things that they come and ask me — hey, can you help us with X? — it's the same script.

(Harishie Diggsen at 00:46:29) It's like, you know, it's there. So I think that gives me hope in the sense that if the problems are common, then the solutions, once when solutions are at least there, is no solutions. There is just like mitigation approaches. That's all. That's the best we can do in this world, I think. And that's still a win.

(Harishie Diggsen at 00:46:55) They tend to be portable, so you can carry that to the next thing and the next thing and the next thing, especially from a, you know, and this is something that now we're kind of talking about things that has to be ingrained in, again, your own leadership team. Because you can't be the one and only spokesperson that's kind of disseminating this to the whole org or to your own team. Like, you want your leaders and you want this thought process, this culture, this philosophy to percolate down so that it just becomes a part of the day-to-day, how you do things. And people come into teams from different experiences. At Deal Three, it was particularly interesting and actually had a blast scaling the team there because it is a truly diverse, culturally diverse, geographically diverse team. They were in like four different countries, and they all bring their own set of experiences and competencies to the table.

(Harishie Diggsen at 00:48:06) But then you see, I know we are coming up on time. We, you see that, okay, well, once you've kind of established a framework and an environment, a zeitgeist, if you will, for your org to do their best work, people get it. Like, it, because it's ultimately they get to do their best work, and they know what the guardrails are. And then the environment you're creating is actually to help them do their best work, which is what else would you want, right, as any professional, but certainly as an engineer because we're people.

(Harishie Diggsen at 00:48:42) Like, we need, we need to, we don't like to be told what to do. Like, you know, don't tell me just to drop this pixel on the home page. Like, you know, tell me the problem you're trying to solve, and I will suggest some pixels. Look at the one that you're looking at, us.

(Harishie Diggsen at 00:48:56) Like it's just, like, don't ask. Like, you know? You just—

(Joel Beasley at 00:48:59) I just need one checkbox right there. Yeah. Just on the page, can you just put the checkbox there? Harish, dude, thank you so much for doing this. I apologize.

(Joel Beasley at 00:49:06) I have another call.

(Harishie Diggsen at 00:49:07) Yeah.

(Joel Beasley at 00:49:08) That backs up to this that I have to go to. But we were gonna have our next conversation. We'll do another episode in a couple months, maybe in person, but I wanna do it on the culture of Yield Street.

(Harishie Diggsen at 00:49:16) I would love to do that. And this time, I will happily come down to Nashville.

(Joel Beasley at 00:49:19) Let's do it. Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn, or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.