The Titanic Effect with Michael Cloran (Series Part 3 of 3)

titanic.jpg

Today we have part 3 in our 3 part series on the Titanic Effect ( https://www.titaniceffect.com/competitors), a book by Todd Saxton, Kim Saxton, Michael Cloran. In this episode, we talk with Michael Cloran, who created the technical ocean of the Titanic Effect. This ocean covers a lot of concepts that in general describes the process of building up technical debt as you begin a technical project, such as a code base that is difficult to edit and modify, architectural decisions that were made early on, or it could be processes where your developers aren’t following up on best practices. He also shares some of the technical debt that he can now recognize he created in some of his earlier projects.

When it comes to technology, as a founder, stop thinking that you can abdicate. You’re going to have to read and understand a little bit about design, and this is a great place to start.
— Michael Cloran

Topics in the episode

  • The three seas of the technical ocean: validation, design, and development

  • Biggest sources of technical debt within each ocean

  • The importance of running a quick test to validate a concept

  • False hope drift of icebergs

  • Value of building a vision in the early stages

  • Exercises in building a vision

  • Divergence tax

Contact Info

https://www.titaniceffect.com/competitors

Email: mec@developertown.com

Twitter: https://twitter.com/TitanicEffect

Facebook: https://www.facebook.com/TitanicEffect/


Transcript

Mike Kelly:                          Welcome to the Startup Competitors podcast. Today, we have part three in our series covering The Titanic Effect, a new book that has been launched by Michael Cloran, Todd Saxton, Kim Saxton. Today, we have Michael Cloran on the podcast. Mike, welcome.

Michael Cloran:                 Glad to be here.

Mike Kelly:                          You're our first repeat guest ever.

Michael Cloran:                 You've had a lot of people come back twice for second sessions, which you've never asked me to, so we'll call this my second session.

Mike Kelly:                          Wait. Have I had people come back twice? Who came back twice?

Michael Cloran:                 Did part one and part two.

Mike Kelly:                          Oh right. Yeah, that's true. But they were recorded in the session. Yeah. Talking to The Titanic Effect, you have the technical ocean, correct?

Michael Cloran:                 That's correct.

Mike Kelly:                          Why don't you tell us about the technical ocean? What is in the technical ocean?

Michael Cloran:                 Sure. I think the concept of technical debt is something that's much more widely understood than maybe 10 years ago when we were really plowing into it hard with interactions and then at the beginning of DeveloperTown. I think Todd and Kim really deserve a ton of the credit for looking at that and saying, "That's a great mechanism to describe a lot of the other types of debts that startups get there." So, we built a presentation around it, and they, of course, did the ones you've already heard in parts one and two, marketing and strategy and the human ocean. Then, I did the technical ocean, which is a lot of concepts that are pretty familiar to people in the technical debt world.

Michael Cloran:                 But in general, it describes the fact that, as you begin a technical project, particularly software, because that's where I've spent my 10,000 hours, what happens is that it builds up this debt over time, and this can be debt from code base that is difficult to edit and modify, it can be architectural decisions that were made early on or it could be process, where your developers aren't following best practices, and as the snowball of code gets bigger and bigger, it gets harder and harder to push it up the hill.

Michael Cloran:                 I discovered this pretty hard when I raised $32 million for interactions and was spending many of those millions on development and not getting very far. As you know, that's when I basically asked you to come in and help us try to fix this thing called technical debt, which I didn't know. I wasn't smart enough to call it that at the time. Basically, we've learned a lot over the last 250 projects we've done at DeveloperTown over the last 10 years. We've learned a lot more about technical debt.

Michael Cloran:                 Now, I would've before said it really was centered in the development, which is the development sea, and of course, there's three seas in each ocean, and here, it's really now a validation sea, then the design sea and then the development sea. We've realized, I think, over time that so much technical debt that people maybe wouldn't call technical debt occurs during those early phases of validation and design. Then, you get into the actual, "How do I build this thing to make sure that I have the right code base to scale with me over the 18 or 36 or 48 month hunt to find product market fit?"

Mike Kelly:                          So, maybe we could start with the validation sea. Why don't you walk through maybe ... You don't have to recap the entire book. Pick anywhere from one to three of your favorite hidden debts in the validation sea and maybe provide some examples.

Michael Cloran:                 Yeah. I mean, I think one of my all time favorites on the validation sea is just people missing the chance to test the concept with an MVP or ... Not an MVP. Sorry ... with something that can just be tested immediately, ad hoc, something that could be done before you write a single line of code. So, the story that I always tell there is that we once had someone come in who had already spent money developing weather algorithms to detect severe weather, they'd already spent money, and they found us because of our voice expertise from doing interactive voice and hey wanted us to build an interactive voice system. This was an entire system to track down severe weather across the country, call people with an automated system in that area after the storm went through and see if you could help them out with an immediate need and create leads for roofing companies.

Michael Cloran:                 After about an hour of talking through the process, we asked how the tests go, the entrepreneur looked at us and said, "What are you talking about?" We said, "Well, how could you just call a hundred people after you just, with your own eyeballs, looked at and saw the red line go through an area and just call them up?" He got redder and redder in his face and he's like, "Well, what would I do if they answer the phone?" We're like, " You would talk to them. You're going to be better than an automated voice system." Then, if they asked for something ... He's like, "What if they ask for a roofer?" "You hit Google, look for a roofer in town, call them up, ask them if they want a free lead and you just see if it's a service that people want." He leaned back, got just visibly red in the face and said, "Where the hell were you a year plus ago?" before he quit his job, gone full-time, spent his friends and family money building algorithms to try to build the tool instead of just jumping to a quick validation test.

Michael Cloran:                 We've seen that with people trying to test RFID chips inside ice skates to test ice rink access when you could test it with a teenager for $10 an hour for two weeks and you could test the entire business model for $3,000 rather than spending $100,000 on a prototype. So, that, by far, is the biggest one is finding the quick way to test and validate.

Michael Cloran:                 One of the other gigantic favorites is sort of ... We call it the false hope drift of icebergs, and that is an entrepreneur today is the new American hero. They're the ones that are going to save the economy and create all the new jobs, and so when you tell somebody for an idea, everybody's going to tell you, "That's great. You should do that. That's awesome." No one wants to be the one that's going to rain on someone's parade until they come here and then we're a bunch of jerks and we say, "Hey, let's rain on your parade," but we hit because we love.

Michael Cloran:                 So, basically, getting entrepreneurs to recognize that false hope that they're sailing straight towards. We give a couple of tools of the book that lets them ask questions in a way that suddenly unlocks that conversation when people go, "Oh no. I meant it would be good for other people, not for me." Somebody on Twitter start getting the real story then.

Mike Kelly:                          Yeah. Let's switch over to the design ocean. So, in the ... Or the design sea. Sorry. In the design sea, pick one or two hidden depths there.

Michael Cloran:                 Oh, this one, I'm just going to pick an argument with you.

Mike Kelly:                          All right. Let's do it.

Michael Cloran:                 Let's do it.

Mike Kelly:                          This is where I would say 80% of our philosophy differences live.

Michael Cloran:                 Yes, absolutely.

Mike Kelly:                          First, are you sure you want me to embarrass you on your own podcast on your own book?

Michael Cloran:                 Well, I don't think that we disagree as much as we once did because I think I have moved a hundred feet and you've moved at least six or seven inches my direction. But I would say that one of my favorite things in the design sea is that it can be cheap, you can overdo this, but to take the moment to project where you think you're going to get to, and, of course, the further you go out in the future, the more wrong you're going to be, but getting a vision out there is important a couple of ways, right? It helps you test the market with an eventual vision. So, instead of testing just a concept with folks, you can test, "Hey, this is where it could go in the next five years." It can get you a lot of feedback from investors and potential employees and customers about that future vision. Then, tear that thing back down to a minimum viable product.

Mike Kelly:                          That thing that you're talking about, is that ... What is that?

Michael Cloran:                 So, painting a vision of saying, "In five years, we're hoping to build an entire system that's going to have artificial intelligence applied to a canned video interview set of questions that automatically spits out the best candidates for a job," but painting that vision to see is that a real pain point and would it really work in the real world. Maybe that's some wireframes, maybe that's some concepts and some value props, something that would take ... might take you 40 or 80 hours of work to do, but it's worth doing that five-year vision.

Michael Cloran:                 When a lot of people start and say, "I'm just going to build an MVP," and they spend five hours of planning and then start building, and if you're going to spend 100 or 200 or 500 hours building, spending 40 or 80 hours up front, I think, to paint that longterm vision and then spend the 5 or 10 hours to tear it back down. The biggest thing that that helps avoid in my mind is this thing that I would call the divergence tax, which is when you start an MVP and you start and if your destination that you're trying to get to is up and to the right over here and you start going down to the right over there as a different destination, the more you build your MVP down that path that is not really going to your eventual investigation, the more you get feedback on that path, the more you get pulled that way by customers pulling you down that path.

Michael Cloran:                 Then, if you ever do want to try to get back on vision, that divergence between those two lines is the tax you pay to get back, and that tax can be incredibly hard to pay when you're in the trenches fighting for product market fit, trying to figure it out and you're still ... and you're trying to figure out how to get back onto this vision and not get stuck in a local maxim of value that you can create.

Michael Cloran:                 Anyway, that, to me, is one that I think is an exercise. Somewhat controversial. Some folks would say, "Don't spend the 48 hours thinking through the longterm vision, just build an MVP and go test the minimum viable thing you can test," and I think that works for some products, and, of course, I always go to my friend Mike Kelly, who's the master at building an MVP instead of building the grand vision.

Mike Kelly:                          Some days. Can I do two quick riffs on that I think are-

Michael Cloran:                 Sure. Go.

Mike Kelly:                          ... topical. So, there are ... It is totally the same intent, totally that same idea of, one, can you test the market with that bigger picture vision without actually building it, then two, I think the second key point there is keeping that anchoring device. As you make decisions in the short-term, you're doing that in light of, "This is where we're going long term," right? So, maybe I can ignore ... I don't need artificial intelligence today, but as I'm thinking about building in data schemas and stuff like that, just doing it in a way that's not going to limit me from doing that and-

Michael Cloran:                 Design structure.

Mike Kelly:                          Yeah. So, two other cheap, easy ways to do that ... Well, maybe they're not easy, but they're cheaper. One is, when we were working on Waterly back in the day and thinking about launching that, we worked with a firm called Do Tank, came out of Business Models Inc., and so they did a bunch of the different types of canvases. One of their canvases that they use all the time is this magazine cover visioning exercise where you basically ... you draw out a magazine cover ... the cover of a magazine. So, you can pick, like, Forbes, you could pick Engineering Weekly, whatever makes the most sense for your product, could be Inc, and you design the magazine cover for that that is announcing your ... whatever your big win is seven years from now, right? It's like, so what are you on the cover of Inc for?

Michael Cloran:                 The vision board-

Mike Kelly:                          Yeah. Yeah. Just classic vision board. There's tons of ways to do this, right, but that was one that I've done a couple of times now because I stole their process because it's awesome, they're super smart guys, and it's one of the things that I try to do a lot now, is just try to think of, like ... There's a couple of things there, right? Where would you want that recognition from? So, with Waterly, it was interesting because it's water treatment, wastewater treatment. Clearly, that's not Inc, right?

Michael Cloran:                 National association of water managers.

Mike Kelly:                          Right. Yeah. Exactly.

Michael Cloran:                 ... water managers.

Mike Kelly:                          So, one is, like, who's your real audience, right, and then two, what are you actually being recognized for? Is it great software or is it economic impact on the water system overall, is it-

Michael Cloran:                 Or you fix Flint.

Mike Kelly:                          Yeah, exactly. So, that's one that I think is super interesting to do. Then, the other one, I was just ... I've been reading Ryan Holiday's new book, Perennial Seller, and in there, he talks about ... He shares the example of Amazon's press release, right? So, Amazon ... I don't know if this is real today, but they used to have this process where before every new initiative you have to write the press release before the project would get funded to go forward. So, if we were successful with this endeavor, what does it look like when we announce it to the market three years from now, five years from now, seven years from now? You'd have to pre-write the press release as part of your pitch to the executive team for why this project should get funded. If you can't encapsulate what you're trying to do that crisply, if you can't talk about it as if it's a thing that's already done, you don't know what you're doing. It's was just instant feedback of like, "You can't possibly know where you're going."

Michael Cloran:                 It's Richard Feynman, right? If you can't explain it to a reasonably educated freshman in college, then you don't really understand the problem.

Mike Kelly:                          Nice. Yeah, yeah. Both of those, to me, feel like riffs on that same idea of design out intangible assets, that five-year vision, because it helps paint that picture.

Michael Cloran:                 Yeah. I think maybe where we differ a little bit is I love making them tangible because it's super valuable for me to have a tangible asset, like beautiful wireframes that look like software. It really helps get people's feedback without counting on them to be able to visualize something, right, have done it for them.

Mike Kelly:                          Yeah. No, it's great.

Michael Cloran:                 It's a great point. Thanks for pitching another book during the pitch for this book, but that works out great.

Mike Kelly:                          Yeah.

Michael Cloran:                 Awkward. So, I think it's ... In terms of the rest of the design pieces, I think there's a lot in there that's just really some of the technical pieces around design, which is making sure that you get the scoping correct, make sure that you are consistently iterating wireframes with real feedback, that you're bringing in somebody, an impartial moderator, for instance, to run a user test with paper wireframes and actually seeing how someone reacts to it as you're doing the iterative design. So, those are all some of the technical depth process things that you can do to make sure that you keep a low design debt as you go forward.

Mike Kelly:                          What does design debt look like? So, the one that you shared is very focused on upfront, right, like are you painting that picture for the future? What does design debt look like in a project that's been in production for four to five years? Can you talk about that a little bit? How would I recognize if I had design debt down the road? You can talk generically, you can pick a specific product if you want, whatever makes sense for you.

Michael Cloran:                 Yeah. I'm trying to think of a ... What it often looks like is a, what I'd call, a local maxima. So, you've got something that ... The oyster has been smoothed over in a design and you're there, but you're looking at it saying, "Man, I don't know why we didn't design in advance for this entire use case, like a custom or a set of things for general managers in the field as opposed to corporate office folks," but you've got an interface that's being used by both and being blurred across and you invested a ton in it and you're like, "Man, I have to get mediocre outcomes for each of them, when, if I'd had the design thinking upfront, I would have realized I could afford this interface and I could have a dramatically better outcome on both sides by forking the interface and going."

Michael Cloran:                 You can see that stuff coming in advance, and you get to this place where it's like, "Yeah, but can we afford the million dollars? Can we afford the million dollars to go tear this big function back out and rebuild these pieces?" Right? So, that's what design debt looks like is you often get stuck where it's just going to cost so much to go back and fix some major structural piece that design upfront could have fixed it. For me, it's the whole job... Qualities job one and four, right? You find it at the design phase, it can cost one tenth or one hundredths of the cost of fixing it when you're already out there in production.

Mike Kelly:                          In the design sea, any other favorites there?

Michael Cloran:                 Not without kicking off more arguments with you-

Mike Kelly:                          No. Well, I mean, you hit the big ones.

Michael Cloran:                 ... other books and things that we can talk about. No. I think, for me, that leads directly into the development side, right, because I think you and I had the most experienced there, which is, as you go to develop, we've made developers now change their game, right? So, developers have to write a ton of tests, you have to actually run a process where maybe you have automated code-grading in place and you also are doing peer reviews, which does all sorts of wonders, prevents moral hazard, actually educates people, gets across project familiarity across things. There's a lot of things that you can do that, along the way, the way you actually build the code means that you can continue making changes at pace in the code.

Michael Cloran:                 That sounds like, "Oh, what's the big deal there?" The big deal there is that when I think about the word scalability, I always laugh when we're the startup and scalability comes into conversations about, "Well, we're going to have to have clusters and able to quickly scale our capacity for our millions of users that we don't have yet and are miles away for that startup." The core form of scalability for most software technology ventures during their first five years of existence is the scalability of the development team to continue making changes at pace on that code base without, "Let's throw it all away and rewrite it," or, "Let's start over," and doing those things.

Michael Cloran:                 Anybody can make rapid progress in the first nine months of a project. You can rip things out and it looks good. Then, when you wake up and suddenly the slope of your development curve up and to the right is gone from 1.0 to 0.7 to 0.5 to 0.1. all of a sudden, it's barely sloping upward. If there's a competitor out there who might've never been as fast as you, might have always had a 0.7 on that slope, just going up and to the right slowly, but if they keep that pace, pretty soon, they're doing 5 and 10 times your pace of development for new features, and that's going to win in the marketplace today.

Michael Cloran:                 If you're setting out down the path and saying, "I'm going to take on technical debt knowingly," maybe you're smart and know all this stuff, and you're like, "I'm going to do this anyway because in six months or nine months, I'm going to have proof and traction and I'll be able to raise the money and I'll be able to do a rewrite," good luck. As a guy who's failed at that a couple of times and told myself that story and failed at it a couple of times, it's incredibly difficult to pull that off, and you're six or nine months is probably more like 24 or 18 or 36.

Michael Cloran:                 I saw the other day, the average time to product market fit ... Someone did a study of SaaS companies. The average time for when the companies said they found product market fit, 47 months for a software as a service startup company, right? Think of that, 47 months. Most people, when they set out and think about fundraising and the pain and the road they're going to go on, does not think about 47 months before they really feel like they find product market fit. That means half had ... That was median. Half had longer than 47 months and half had less than 47 months.

Mike Kelly:                          Right. That's awesome. Well, and terrifying.

Michael Cloran:                 And terrifying.

Mike Kelly:                          Certainly fits some of our experiences with products that we've helped with.

Michael Cloran:                 I think an interesting comment about that number, that 47 months, is there's another side to this book, which Todd and Kim have really strapped this book on their back and carried me along to get it done and helped me with writing and editing and done a lot of great stuff. There's a piece here that we want to build that is really interesting and exciting, which is we want to take this thing we call the titanic index. There's a MVP of it in the book, and it's a little detailed and long.

Michael Cloran:                 But we want to go put up a site and start asking people, some people that are in real time answering it in their startup as they go, answering these questions, sort of a credit score for how much human debt do you currently have in your start up, how much marketing debt, how much technical debt do you have or strategy debt, and basically go through a little rubric or evite, which is go through and mark, "Okay. We're doing great with our founders and we've got reverse fasting in place and we've got good diverse skills and we've got the right advisors." You go through and check those things off. We'd love to do this as a way to gather insight on what I think is a sort of under-visualized part of the startup experience.

Michael Cloran:                 You think about due diligence that we get from investors and people were looking at numbers and analytics and they're looking at employees, maybe they're looking at code or doing a code review if it's a big enough round, but there's an entirely different level of diligence, which is to ask some of these other hidden debt questions. We're going to try to build a tool set just so we can really benchmark this.

Michael Cloran:                 So, the book launches June 11th, and sometime after that, this summer, I've got a couple of summer interns slated to also work on this tool, we'd like to start seeing if we can create an experience that people would come in and say, "Oh, yeah. I did a startup," and then retrospectively go back and answer some of those questions about how things were going in each of those areas. The benefit for someone to come do that would be, one, you're contributing back to the startup knowledge and community, but two, you're getting the sort of benchmarking. So, if you come in and answer just three or four quick questions in the human ocean, you get to see right away, "Okay. Well, hopefully a thousand other startups answered it this way," so you can see, "Was I above average, below average? How did I do it?"

Michael Cloran:                 So, that's sort of the index that's coming, and we'd like to make that a bit of a community effort. So, as you answer the questions, you can comment and tell little short stories so that we can gather, as a community, these types of stories. I think it's a corpus of both data and sort of anecdotal that would be incredibly helpful for future entrepreneurs. Maybe someday ... It's probably not gathered the right way for pure academic research, but someone with a research and could really research into it and find some interesting trends and insights out of it.

Mike Kelly:                          Nice.

Michael Cloran:                 Grand vision on that would be that someday, investors use that as just like a, "I want to see a business model canvas," or, "I want to see ..." I guess the new is the investor memo, but that it would become, "Yeah. I want to actually do a titanic index report. I want to see the titanic score on this startup and let VC firms, just like they can get a startup competitors' report and see what all the competitors are like, I feel like they could also get this hidden debt report of what are the hidden debts at each of these areas for the startup and actually find a way to build that. So, that would be the grand dream for five years. We're trying to build the MVP on short-term -

Mike Kelly:                          Nice.

Michael Cloran:                 ... pull that off.

Mike Kelly:                          I like that. What's the investor memo? I don't know the ... I don't know. I'm not down with my new hotness.

Michael Cloran:                 So, the guy, Conrad Parker, his new startup, Rippling, which is, by all accounts, on fire, 45 engineers, two years of coding to really build something hot, and he raised $45 million in a week. He did not do a pitch deck. He did an investor memo. It was an 11-page memo. His whole point is that it's a very powerful way to raise money because, first of all, it's incredibly well written. It clearly was written by a guy who, A, had the money and seed funding to get two years and 45 engineers in before he had to raise 45 million dollars, but he ...

Michael Cloran:                 Basically, he says, "Look, if you give a pitch deck, your partner to VC firm is going to have to go write a memo anyways," so you're handing them this already written memo. You can pre-address a lot of the concerns, a lot of the ... At VC pitch meetings, a lot of them are going to read the memo anyway during the first 10 minutes of your presentation, so just give them the damn memo and say, "Here's my memo," and write it for them. Then, the investment partner can write notes on it. You should just go to Rippling. Rippling has a post up on how they raised $45 million a week with it. You should just read his memo. You're like, "Wow. It is a hot piece of writing."

Mike Kelly:                          The skeptic in me is now going ask you the question "What is the difference between a memo and a short business plan?"

Michael Cloran:                 Yes, exactly. I think the difference, I would say, in this one that I saw would be where this is more of a series A, series B kind of level whereas a business plan is mapping out all the things we're going to do and how we're going to do. This memo is more written from a "This is why this is a great investment and how we're going to ..." ... It has some of the metrics of, "Here's what we've been doing each month and here's how we're going to use the funds that we're going to do and here's how we're going to ..." You know what I'm saying? A business plan's more like, "We're going to be the premier-"

Mike Kelly:                          Yeah, that's fair.

Michael Cloran:                 "... provider of bananas to whatever," right? It's instead going to be ... I don't know. Sorry. Popped my eye ... to the underserved monkey market with an AI-driven banana delivery.

Mike Kelly:                          Correct. Yeah. All right. Back to the technical ocean real quick. When you think back on your career, what are the hidden icebergs that, for you, were most painful that you wish, had you had something like this in your hand early on, right ... Not everything can be avoided by by knowledge, right? But certainly, maybe could have been curved, less painful, whatever the case may be, right? So, any stories there you would be willing to share?

Michael Cloran:                 Well, yeah. I think ... What would I have done differently if I had this book or this knowledge? So, certainly, at the place where we met, Interactions, I started with a guy who's a brilliant guy, youngest kid at 12, all of them salutatorians or valedictorians of their class and super bright, and he started writing code that really, in hindsight, I realized was a prototype proof of concept. we took that code, rolled it into just enough to get into production, got just enough there to raise money from that first customer and an interest from a couple of others, and then we just rolled forward with it.

Michael Cloran:                 If I would've recognized the technical debt in that code, certainly, at the time we raised money, we had enough to split resources off. It seems like a crisis to just get the next little bit done, next little bit done, to get the next client, hit the growth plan, but I would have recognized the amount of technical debt in that code was compounding interest at a rate that was going to literally absorb a 3 and $4 million a year tech team that I was putting on, a dev team, and I could have instead peeled off a team that would have built the code with the right foundation, gotten rid of some of the, certainly, the pure code debt, some of the architectural debt, and we probably could have crossed over in a, within a ...

Michael Cloran:                 Somewhere between 6 and 12 months after doing that kickoff, we would have crossed over and then we would have had payback of 10x on that side investment to build the code base the right way. But that was also 2002 to 2006 and then 2006 to 2009. They've had nine years now to recover from all the mistakes I made. So, Interactions, great company. Hopefully gets the S1 out sometime here in the next couple of years.

Michael Cloran:                 But I think today, because of this softwares and service revolution, those concepts are much better understood, still not understood by a significant number of entrepreneurs who are building code bases for the first time. I still have conversations with people when I just talk to them about how to properly buy services, whether that's from a external firm or even buying "from an employee that you've hired to build code for you." How can you, as a senior leadership team, be a savvy buyer of that technology? When I explain to them just the basics of, "Look, just start from the very beginning and make sure that you grade your code and make sure that someone looks at it and keeps looking at it, not just the one time, 'Oh, that's curious,' but makes it part of your process."

Michael Cloran:                 Then, that includes test coverage and some ... not overdoing test coverage, but not under-doing. Then, lastly, is making sure that, even if you have a solo developer or just two developers, just recognizing that, very early on, implementing this peer review process, which is now supported by a ton of tools, it's easy to ... not easy to do, it's easily tool-supported, that you just have to do that stuff. It makes just an absolute world of difference along the way from from that ability. So, I definitely learned those lessons a lot, and yet still suffering from them.

Michael Cloran:                 We've had some startups that we've invested in that have had the classic in development team that is old school and knows better and is better than all the other folks that have built these tools and these processes and they're going to do it their way and, sure enough, I have one right now I'm dealing with that's a two-year-old code base that we're paying down technical debt for probably two or three months just trying to fix the technical debt from that arrogance, go to loan and skip all the processes process that was run.

Mike Kelly:                          When you think about this ... This may be a poorly worded question, so bear with me, but in my mind, there's two types of software products, right? There's the deep, technical challenge, something that's never been done before ... Interactions was clearly that, right? It was hard. It's hard. I think it's -

Michael Cloran:                 Trying to do human-assisted AI in 2002. Yeah, that'd be fun.

Mike Kelly:                          ExecOnline way back in the day before streaming video was easy, was a thing that you could just plug in, right? That was hard when we first jumped into that. I think some of the companies in the portfolio now, like that ... There's a big difference between where you're, like, the first person ever to do a thing versus, "We're building a CRM system for getting bananas to monkeys," right? Which is not technically hard, it's kind of well-understood, it's kind of you leverage most frameworks off the shelf and it's really just about figuring out user experience, product market fit. It's not about the technology necessarily, right? If that makes sense.

Michael Cloran:                 Yes.

Mike Kelly:                          So, when I think about ... Certainly, that's a continuum, right? So, you've got very clear examples on one end, maybe you're doing Space X, right? Then, you've got very clear examples on the other end. You're doing just online forms, right? When you think about technical debt, because, to me, there's this ... It's really easy to think, if I'm doing Space X-level stuff, it's very easy for me to say, "Oh, no. We gotta be super aware of technical debt every step of the way. We don't want to accrue this stuff because it's really hard," and everybody acknowledges that it's hard, which almost makes it easier to say, "We should put these practices in place. We should have more people spend more time thinking about architecture," or whatever the case may be.

Mike Kelly:                          I often feel that, on business software, software-solving general business problems, which is kind of that general other end of the spectrum, it's very easy to just be like, "Well, yeah. What are you talking about?" To build that user experience is a one-week sprint from one developer. I don't even know that you need a designer. It just seems super straightforward, super simple. How do you balance that? How do you find the right balance between, "I want to move quick. This is not a key user experience. This is not hard stuff. I trust my developer to go forward and get stuff done?" and balance out with kind of what you're saying around, like, "No, no. I'll try to do to the common. You need all these practices," which is super easy to see at this other extreme. Where's the balance in there?

Michael Cloran:                 Some of it is the insurance problem. You don't know which of those problems is going to jump up and rear its ugly head, so having processes in place around all of them make sure that you don't get burned by that. So, an example would be, "Oh, yeah, we threw together this integration to third-party service, Stripe or something, and it was easy, straightforward, basic integration, business process done a million times." Then, "Oh. Uh-oh. We didn't wrap it with monitoring and we didn't do the systems, thinking through, 'Well, what happens if somebody comes in and changes an account from their side instead of our side?' and, 'Does the API still work?" and, 'Do we have all the ... We handle all the conditions. Are we basically, functionally complete? '"

Michael Cloran:                 Next thing you know, it's 2:00 AM and stuff's going down and the $100,000 bill runs not going through and then it's like, "What's going on?" Suddenly, you've got your forums lighting up with your customers saying you have a crappy product because the payment interface is always down because what you ended up doing was fixing one of those problems and then you fixed the next one and the next one and the next one, and what was missing was the technical debt around saying, "Hey, we're doing this integration. What are all the ways this could actually break us?" A lot of those business things are classic. I think RPA's driving this, is the ability to do business process decompensation. Who is driving-

Mike Kelly:                          Robotic process automation, right?

Michael Cloran:                 Oh, got it. The skills today of going back to business process decomposition and then systems thinking and then being able to see all the holes, our age hold skills, right? Those have been around for a long time. I think what's different is that today ... The expectations in the past were you had time to design those things in waterfall, build them in and do all those things. Today, you're in a world where the expectations and the tools to build software are so much faster that you really need the ability to wrap all of those pieces that you're going to rapidly build that are relatively, simple business, fill out a form, send a message here, integrate with that, pull this data back.

Michael Cloran:                 All those things sound simple, but in a systems world, you don't know which one is going to sneak up and cause a huge problem and break it. It doesn't ... It sounds like it can be overblown, and when we started, I was always like, "Oh, that seems overblown. It seems like a lot of expense." As the guy writing the checks for software development teams at startups, I'm always like, "Man, do we really have to spend that money?" But once your house is burned down a few times, you're like, "Maybe I should buy fire insurance."

Mike Kelly:                          Nice.

Michael Cloran:                 Yeah.

Mike Kelly:                          If I'm a founder ... Well, yeah, let's start here. There's probably a couple of ways to go. If I'm a founder and I'm the business founder, I'm not the coder founder, right? So, I'm looking for my technical cofounder or I'm hiring a firm or my brother-in-law's coding away in his basement, how do I ... I don't know how to recognize technical debt. I can't look at code ... So, I read this book. It's maybe helping me ask some smart questions like, "Hey, should we get somebody to do a code review or something like that?" but how do I have that conversation in a way that ... My fear could be that I'm going to be insulting, right, like I'm questioning your competency as a developer or ... If I have a third-party firm doing the development, do I need to go hire a second third-party firm to audit them? I can't afford that. I'm in startup mode. Just any guidance if you're that first-time founder, not technical. How do you even have these conversations?

Michael Cloran:                 So, first is, if you're a founder and you're building a technology company or a tech-enabled company, which many startups now are really ... It's not Space X, it's not a new technology, it's wrapping technology around a service, so a tech-enabled company. The first thing I would tell you is you can't advocate, just like you need to understand as an entrepreneur the reality of the tax code and how it affects your business or how the different corporate structures could work.

Michael Cloran:                 You could say, "I'm just going to hire a lawyer to help me build corporate structures. I'm going to hire a tax company to do my taxes," but you know as well as I do, the best entrepreneurs understand the moving blocks and understand how to move the pieces around on the chessboard in order to try to make a better outcome in those arenas, even though, yes, they're hiring technical expertise for those detailed processes of writing the actual contract and doing that, coming up with, "Well, how can I address that in a contract?" Well, we just did a few minutes ago. How would we move that account receivables around and which entity would we move it to? You have to understand how the levers work to even play that game.

Michael Cloran:                 When it comes to technology, as a founder, stop thinking that you can advocate. You're going to have to read and understand a little bit about design, and this is a great place to start because, hopefully, we're not going super deep and technical. This is written for founders in this area to understand what you can do in design, and when it comes to being a savvy buyer, there are some directives in here. A ton of it is just knowing to ask the questions and knowing what it looks like. A lot of people were like, "Oh, yeah. Well, they told me it was going to cost $32,000 and it's going to be done in three months," and then they're shocked when it's taking six months and it's going to cost double that or it does get done, but it is like that house you moved in where they just did the punch list of everything you actually asked for, and then when you actually get there, you realize, "Oh, there's, like, 17 other things I need fixed," and then you're stuck fixing those on your own.

Michael Cloran:                 A lot of people end up in that situation. They didn't recognize early enough in the process what they were actually buying, what they were trying to get done, and you really have to spend some time and understand how to be a savvy buyer and then how to wrap a process around it where you actually do look at the code grade. You can understand code grade. Look at it. Look at it every week and use it as one of your KPIs if you want. If it's a small team with three people, just have the conversation about it, but then don't let it fade and disappear in the background. Keep it at one of the checklist items you have to be top of mind on. So, I think that's number one, you can't add abdicate.

Michael Cloran:                 Number two, when you go to hire an external firm, ask these specific questions. If you're interviewing firms, ask three or four of those firms, "Okay. What's your process? Do you actually do these things? What's the evidence of that that I can see that you're actually doing peer review process and that you're actually doing some quality code checking?" et cetera. You can just ... Just asking those questions immediately makes you the, "Oh, this is the buyer that actually asked if the real estate commission had to be six or seven percent," and suddenly found out, "Oh, no. I can get it for five or four and a half if I just ask. You can be the savvy buyer that can just ask those questions and do that.

Michael Cloran:                 So, it's not that hard, but it's going to take a couple of brain cycles, and if you're doing a business where technology is going to be a big part of your spend or your strategic advantage, you owe it to yourself to do it as a founder to not do it. You can log into these tools, you can log into Rollbar and look at errors. You can understand well enough, "Oh, that's red and it's flashing at me. That's probably an error. I should ask about why we have 22 errors that haven't been fixed for the last week. Are those okay? Are we going to fix them or not?" right? You can do that. Just log into the tools, figure it out.

Mike Kelly:                          Awesome. I've probably kept you too long.

Michael Cloran:                 It's been great.

Mike Kelly:                          Next steps for the book, you talked about the iceberg index ... No, titanic index.

Michael Cloran:                 Yes, exactly. I think ... Now, you got me messed up. I think it's called the iceberg index.

Mike Kelly:                          Oh, it is the iceberg?

Michael Cloran:                 It's called iceberg index. Yeah. Sorry. But it'll be on thetitaniceffect.com when we launch it, and it'll basically ... We're trying to figure out how to let people come here and I'm trying to do ... Here's my theory ... I'll tell you ... is we're trying to do a thing where you can answer just a few top-level questions first and immediately get some payback and then drill down into each area so that we can at least get a complete dataset skimmed across the top.

Mike Kelly:                          Yeah.

Michael Cloran:                 So, it's an interesting form design challenge, to try to get people to come in and answer the top and then entice them enough with those results to say, "Hey, here's three more things or five more things."

Mike Kelly:                          Here's where you really messed up. You want to go deeper.

Michael Cloran:                 Yeah. You want to go a little deeper and do that. So, we're just trying to figure out how to make it fun and exciting for people that contribute the data and then make it be exciting for the community to actually have these conversations and bring them out in front. I just cannot believe that it's 2019 and we still have founders running around saying, "Let's go thirdsies," right? I promise you, someday I'd write a book called Thirdsies is Evil, and it's in this book,-

Mike Kelly:                          Don't worry.

Michael Cloran:                 ... didn't get to be the title.

Mike Kelly:                          Todd's got you covered. He covered it in the human ocean.

Michael Cloran:                 But that's still happening, and that's such a well-known problem, and it's so easy to solve, and it's not there yet. There's another 20 problems like that. I think if we had a community actually get active and get the Kaufman Foundation to promote this to startups or entrepreneur or VC firms use it, I think we could start a real conversation about some of these hidden debts that are making founders' lives more miserable than they have to be in years in months 12 to 48. There's a whole lot of things here that can make your life better there if we learn them.

Mike Kelly:                          If people want to get ahold of you to ask questions, how do they do that?

Michael Cloran:                 Just email me at MEC, that's Michael Eric Cloran, my initials, at developertown.com and I'll answer you there.

Mike Kelly:                          Thanks so much.

Michael Cloran:                 Thank you.