Giant Robots Smashing Into Other Giant Robots

Kendall Miller is the Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. The first half of the conversation with host Victoria Guido and special guest host, Joe Ferris, CTO of thoughtbot revolves around the use, adoption, and growth of Kubernetes within the technology industry. The discussion explores Kubernetes' history, influence, and its comparison with other platforms like Heroku and WordPress, emphasizing its adaptability and potential. The second half focuses on more practical aspects of Kubernetes, including its adoption and scalability. It centers on the appropriateness of adopting Kubernetes for different projects and how it can future-proof infrastructure. The importance of translating technical language into business speak is emphasized to influence executives and others in the decision-making process and Kendall also discuss communication and empathy in tech, particularly the skill of framing questions and understanding others' emotional states. __ CTO Lunches Follow CTO Lunches on LinkedIn or Twitter. Follow Kendall Miller on LinkedIn. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Kendall Miller, Co-Founder and COO of CTO Lunches, a network of engineering leaders to get trusted advice and connections. Kendall, thank you for joining me. KENDALL: Thanks for having me. I'm excited. VICTORIA: And today, we have a special guest host, Joe Ferris, CTO of thoughtbot. Joe, thank you for joining us. JOE: Hello there. Thank you for having me. KENDALL: Hi, Joe. Thanks for being here. It's exciting. VICTORIA: Yes. It's so exciting. I think this is going to be a great episode. So, Kendall, I met you at a San Diego CTO lunch recently, and I know that's not the only thing that you do. So, you're also an advisor, a board member, and CXO. So, maybe tell us a little bit more about your background. KENDALL: Gosh, my background is complicated. I've been involved in tech for a very long time. In college, I worked for a company that started Twitter about five years too soon, and then worked in the nonprofit space in China for ten years, then came back, got back involved in tech. Today, I'm usually the business guy. So, when technical founders start technical products and want help turning them into successful technical businesses, that's when they call me. So, I have the technical background. I have never been paid to write code, which is probably a good thing. But I can hang in the technical conversations for the most part, but I'm much more interested in the business side and the people leadership side of business. So that tends to be where I play. Every organization hires me to do something different. VICTORIA: Thank you for that. And I'm just curious about the CTO Lunches. Just tell me a little bit more about that. And what's the idea behind it that led you to co-found it? KENDALL: CTO Lunches has actually been around for about eight years. And I didn't start the initial incarnation of it. It was two people that got us started, and I was trying to hire one of them; one thing led to another. Actually, originally, they did not want me to join. I think, at the time, my title was COO at a company that I was working with. About six months later, I took over engineering as VP of engineering, and then they're like, you can join the group now. We're less strict about that [laughs] now. Although it is highly focused on senior engineering leaders, it's not exclusively CTOs. But the group's been in place for a very long time, just intended as a place to network, have conversation with people who are in that senior-most technical position at technical organization. So, the CTO role is a lonely role. CTOs get fired all the time. There's not a technical person at the company that doesn't think they can do the job better than them. So, the CTO is always getting feedback. You're doing this wrong. The trade-offs you're making are wrong. This isn't going where it should be going. We should automate that. Why haven't we automated that? We should switch to this other tool. I've used it before; it's 100 times better. Joe, let me know if I'm getting any of this wrong. But that's the experience that I've had. Having a place where people can get together and, you know, half the time just complain to each other, hey, this is hard, is really why the networking group exists. So, it's a listserv. And there are local lunches that started in Boulder, Colorado. It's gotten pretty global. About a year ago, a little over a year ago, I was talking with one of the people who'd gotten it started. I've been involved in the Denver chapter for most of those eight years. And I was suggesting to him that he change a few things about it, to monetize it so that he could invest in it further. And he came back a few months later and said, "I want to take your advice and do this, but I want you to come do it with me." So, we founded the company officially...I think in December is when paperwork went into place. And we started investing in it a little bit more heavily. I was living in Europe last year, so we went and put on lunches in Paris, and Lisbon, and London, and, gosh, all over the place. I'm sure I'm missing some, Amsterdam. But there's been chapters all over the U.S. and a couple of other parts of the world for a long time. VICTORIA: That reflects my experience attending a CTO lunch. It's just very casual, like, just get together and eat food and talk about what you've worked on recently, issues you're having, just get ideas and make some friends. So, I really appreciated the group, and I'm going to personally plug the San Diego Chapter has picked up again. And we're meeting next Friday down in Del Mar. And we're going to be meeting on the last Friday of every month through October. So, I'm super excited to be a part of the group. And Joe, yeah, I'm curious about your perspective. As a CTO with thoughtbot, just what are your thoughts about that kind of thing? KENDALL: Yeah. How right am I about how lonely you are, Joe? JOE: [laughs] You know, I've been lonelier since we went remote. I used to work in the office, and I was a CTO, but also, I had lunch with people, which was nice. So, I'm lonelier. But yeah, I think everybody needs a group like that, like, senior developer therapy just to talk about your woes together, drown your sorrows. KENDALL: Well, I think years ago, I heard that CTOs are the most fired C-level executive. JOE: You're making me nervous now. KENDALL: [laughs] You've been there a long time, Joe. I know you've been there a long time. If you haven't been fired yet, you probably got a little while longer in you. This will be really awkward if it's published and you've already been fired. VICTORIA: We can always edit that out afterwards. [laughter] KENDALL: Yeah, no, I think it is a particularly lonely position. And, again, I think a lot of it is the average engineer in a technical company doesn't look at the COO or the CFO or even the CEO and think I could do that. But they're all looking at the CTO and thinking, what does that person do that I can't do? It's ridiculous because most of them would make terrible CTOs because it does require some of the business sense. Or, you know, right out of the gate, they might make terrible CTOs. It actually is quite a skill to be the most technical person and speak the business language. I mean, am I right about that, Joe? Like, was that hard for you to learn? JOE: Yeah, I definitely think...so, my background is also technical. I have a background in consulting. So, I always did a lot of metaprogramming, if you will. But making that transition to thinking about organizations that way, thinking about how all the other pieces play into it, was a pretty big step for me, even before I became a CTO as a consultant. KENDALL: Well, because you can't just chase the newest, hottest technology. You have to make business trade-offs. And not everything can be resume-driven development, right? Even if that technology over there is newer or hotter, it doesn't mean you have a business model that supports it. And it doesn't mean that migrating to it can be done, right? JOE: Yeah. I mean, even beyond choosing technologies, just choosing where to invest in your software stack, like, what needs to be reworked, what doesn't, and trying to explain those trade-offs, I think, is a rare skill. Being able to explain why something would be harder than something else when you're working with the leadership to prioritize a backlog it's a puzzle. KENDALL: Well, and I think when I'm in an executive conversation, and the CTO says, "Here's the thing that I think is the best decision technically, and I think it's the wrong decision for the business because of X, Y, or Z," I'm always super impressed, right? Like, this is the right technical solution for what we want. However, we shouldn't pursue that for business reasons right now. Maybe we can in six months, but right now, we need to prioritize this other thing. I don't know, that's always when I feel like, oh, this person knows what they're doing. JOE: There's nothing more dangerous to software than a bored developer. [laughs] One nice thing about being a consultant is that I don't have to invent problems to solve with technology at my company because sooner or later, I'll run across a company that has those problems, and I'll get to use that technology. But I think a lot of people are mostly happy...they might be happy in their role. They might be happy with our team. But they're very interested in whatever is hot right now, like machine learning, AI. And so, suddenly, that surreptitiously makes its way into the tech stack. And then, years later, it's somebody's problem to maintain. KENDALL: [laughs] Well, I have a specific memory of a firm in New York City that was, you know, this is relevant to y'all as thoughtbot is that, you know, at least historically, it was, to me, the premier Ruby on Rails consulting shop. I think that's still largely y'alls focus. Am I right about that? JOE: We still do a ton of Rails, yeah. KENDALL: Okay. Well, so this organization was all Ruby on Rails. It was a big organization. They had a very large customer base. And they hired a new CTO who came in, told everybody in the company they were stupid, laid off 70% of the engineering organization, and told the CEO he was going to completely rewrite the product from scratch in .NET, and he could do it in three weeks. And I'm pretty sure the business went under about three months later [laughs] because that was just so outrageously nuts to me. JOE: It's too bad he laid everybody off beforehand. I've been in that situation where somebody tells me, "I'm going to rewrite this. It'll be ready in three weeks." And I could fight with them and try and convince them they're wrong. But I feel like somebody who's approaching that with that attitude they're missing all of the nuance and context that would make it possible to explain to them why it's not going to work. And so, it's easier to just say, "You know, take the three weeks. I'll talk to you in three weeks." But if you've already laid off your development team, that's hard [laughs] to recover from. KENDALL: That's exactly right. VICTORIA: There's got to be a name for that kind of CTO who just wants to come in and blow everything up [laughs]. Yeah, so you spend a lot of time talking to different CTOs and doing this social networking aspect. I'm wondering if there's, like, patterns that you see. You've mentioned already one about just, like, the most often getting fired. [laughs] But what are the patterns you see, like, in challenges, and then what makes someone successful in that CTO role? KENDALL: Well, oh gosh, I have so many thoughts about this. First of all, I run into a couple of different categories of CTOs. There's a lot of people who come to CTO Lunches who are small company CTOs. I mean, it makes sense that there's a lot more small company CTOs than there are big company CTOs. But the small company CTO who maybe it's their first gig in the role or they're a serial CTO. There's the fractional CTOs that come that are doing it across several different organizations at the same time, and then there's the big company CTO who shows up. And honestly, all of their problems are very different. The thing that they have in common is even at a very large organization, in that position, they can make a decision that causes the company to go under. So, there is a significant amount of volatility in the amount of power that they wield. So, what's interesting about that is not everybody understands that. And so, first of all, there's the kind of CTO that just doesn't get that, and that doesn't matter if they're fractional, or a small company CTO, or a big company CTO. If they don't understand that, they're going to cause significant problems, right? Like the person I just mentioned who said, "I can just re-platform this in three weeks in .NET." There's that. I mean, I think, as with any senior leadership position, the comfort with volatility, the ability to know what to communicate down versus across and versus up, and then the ability to speak the business language. For everybody, the CFO's job is to communicate the financial needs alongside of the business leads, right? If the CFO's sole goal is to cut costs or make sure we're running as lean as possible, they're a bad CFO. But they're not as good of a CFO as the CFO who can say, "Hey, we're underspending right here. And I can look at the numbers and know we should invest more there. How can we invest more there and invest it well?" And it's the same thing for a technology executive to be able to look at the business context and communicate it back. And there are so many CTOs that I've worked with who they're the most technical person in the room, and they know it. And as a result, they're just a jerk to everyone around them, like, everything you did here was wrong. You know, that's where they fail. And so, if they can communicate the business needs, navigate the volatility, and support a team that's going to make decisions that aren't always the same decision they're going to make, they're going to be successful. Honestly, there's very, very few CTOs that I've met like that. People who are excited to meet you at work, excited to see you succeed, excited to see that you went and built a thing is great. I mean, the reason I was VP of engineering is the CTO that I was working with at the time...it's a terrible story. There was an engineer who had seen something that we were doing on repeat all the time and, in his spare time, spent about 40 hours outside of work, not during work hours, automating this task that we were doing regularly. And it was related to standing up a whole bunch of things in our standard infrastructure. He brings it to the CTO and says, "Look what I built." And the CTO, instead of saying, "Hey, this is incredible. Thank you. This is going to save us a bunch of time. Let's iterate on it. Here's some things I'd like to tweak. Can we bring it in this direction? Can we..." you know, whatever, said, "Why is this in Python? It should be in Ansible," something like that. I can't remember. And the engineer literally burst into tears. [laughs] JOE: Oh my God. KENDALL: [laughs] Well, I mean, yeah, it was like; literally, that's why the CTO stopped managing people that day. There's a lot of examples that I have like that. Joe, I appreciate that your response is, "Oh my God." Because I think there's a lot of people who'd be like, wait, what was wrong with that? Shouldn't it have been in Ansible? JOE: [laughs] Yeah, I've seen CTOs come into primarily two groups. One is the CTO who just tells, you know, like, they make the decisions, and they tell everybody what to do. They obviously don't have all of the information because you can't be in every room all the time. And the other is the CTO, who just wants to be one of the team members and doesn't make any decisions and tries to get people to make decisions collectively on their own without any particular guidance or structure. And finding that middle spot of, like, not just saying, "Hey, everything's in Ansible," allowing for the creativity and initiative, but also coalescing the group into a single direction, I think, is what makes a good CTO. KENDALL: Well, yeah, because the CTO does have to say no, sometimes, right? Like, the best product, people say, "No." Good CTOs say, "No." There is some amount of, hey, I need you to come to me with trade-offs about this. Why are you going to make that decision? And I'm sorry, you still didn't convince me, right? Like, I mean, those are appropriate things to say. But yeah, I'm with you on that. You said they fall into two categories. But you really mean the third and that middle ground. Is it easy for you to walk that middle ground, Joe? JOE: I wouldn't say it's easy. [laughs] KENDALL: Yeah. Well, I'm always nervous to say something. I'm doing well because I know there's a report out there that can point at every time I failed at it, right? So... MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneurs. VICTORIA: Yeah, what I'm getting from what you're saying, too, is this communication ability and not just, like, to communicate clearly but with a high level of empathy. So, if you say like, "Well, why is it in Python and not Ansible?" is different than being like, "What makes Python the best solution here?" Like, it's a different way to frame the question that could put someone on the defensive that just really requires, like, a high level of emotional intelligence. And also, if they've just worked, like, an 80-hour week, [laughs] I probably would maybe choose a different time to bring those questions up and notice that they have been burning the candle at both ends and prioritize getting them some rest. So, speaking of, like, communication and getting prioritization for [inaudible 15:34], especially on, like, infrastructure teams, maybe we could talk a little bit about Kubernetes, like, when that comes up as an appropriate solution, and how you talk about it with the business. KENDALL: My background with Kubernetes is long because a company that I still work with, Fairwinds, used to be called ReactiveOps, has been in the Kubernetes space for a very long time. I think we were one of the very first companies working with Kubernetes. It was coming up that people were running into the limits of something like Heroku, right? And I think it's Kelsey Hightower who said every company wants a PaaS. They just want the Paas that they built themselves. And that's really accurate. And I think Kubernetes isn't quite a framework for building your own PaaS or isn't quite a foundation where I think of a foundation for a house. Instead, it's more like rebar and cement and somebody saying, "Good luck, buddy." You know, you still have to know how to put the rebar and cement together to even make the foundation, but it is the building blocks that help get you to a custom-built PaaS. And it's become something that a lot of people have landed on as, you know, the broadly accepted way to build cloud-native infrastructure. The reason I've been in the Kubernetes space and the space that I see Kubernetes still filling is we need to standardize on something. We can choose a cloud provider's PaaS. We can choose a third-party PaaS, or we can standardize on something like Kubernetes. And even though we're not going to migrate from AWS to Azure, the flexibility that Kubernetes gives us as a broadly adopted pattern is going to give us some ability to be future-proofed in our infrastructure in a way that previous stacks were not, you know, it was Puppet, and it was Ansible. And it was SaltStack. And it was all Terraform all the time. I'm not saying those things don't exist anymore. I'm saying Kubernetes kind of has won that battle. Joe, since you're here and I know y'all are doing some Kubernetes work now at thoughtbot, I'm curious if you agree with that characterization. JOE: Yeah, I think that's true. I think it's the center for people to coalesce around. Like, for an effort in the industry to move forward, there needs to be some common language, some common ground. And I think Kubernetes struck the right balance of being abstract. So, you can use it in different environments but still making some decisions, so you don't have to make them all. And so, like, all of the things you had to do with containers like figuring out what your data solution is going to be, what your networking solution is going to be, Kubernetes didn't even really make those decisions. [laughs] They just made a platform where those decisions can be made in a common way. And that allowed the community and the ecosystem to grow. KENDALL: I mean, I think of it a lot like WordPress; you know, WordPress is hated by many. When WordPress came out, it was hot, right? And it was PHP, which everybody was super excited about at the time. Kubernetes is going to reach a point where it's as long in the tooth and terrible as people think WordPress is, but it has become the standard. And the advantage of the standard is you can use the not standard. You can go build a website in Jekyll instead of WordPress, and there's going to be some things that are nicer about Jekyll. But because WordPress is so broadly adopted, there's a plugin for everything. And I think that's where Kubernetes sits is because it's become so widely adopted everybody's building for it. Everybody's adapting for it. If you run into a problem, you're going to find somebody else out there who has that problem. In fact, I think of one organization that I know that was on HashiCorp's Nomad. And they said, "Actually, we think Nomad has better technology through and through. But we think we're the only company at this size and scale using Nomad. And so, when we run into a problem, we can't Google for it. There's no such thing as a plugin that exists to solve this. Nobody has ever run into this before on Nomad. But there's 100 companies dealing with the same problem in Kubernetes, and there's ten solutions." And I think that's the power that it brings. VICTORIA: So, it's not just a trend that CTOs are moving towards, you think. KENDALL: I mean, I think it's already won the battle and the hockey stick of adoption. We're still right at the very bottom of that tick-up because it takes people a long time to adapt new technology like this, especially in their infrastructure. It's a big migration, to move. So, I don't think it's the widely adopted infrastructure technology even yet. I think a lot of the biggest organizations are still running on things that predate Kubernetes. But I think it has won the battle, and it is winning the battle and is going to be the thing going forward, so yeah. JOE: I think it also has a lot of room to grow still. Like, there are other technologies that I used previously, like Docker, and they were a big step up from some of the things I was doing at the time. But you quickly hit the ceiling, or it was, like, I don't know where to go with this next. I don't know what else is going to happen. Whereas with Kubernetes, there are so many directions it can go in. Like, the serverless Kubernetes offerings that are starting to pop up are extremely interesting, where, you know, you don't actually maintain a cluster or anything. You just deploy things to this ethereal cluster that always exists. And so, that sort of combination of platform as a service, function as a service, Kubernetes, as that evolves, I think there are a lot of exciting things that have yet to come in the Kubernetes space. KENDALL: Well, so say more about that, Joe, because I've been going to KubeCon for a very long time, maybe...I don't know if it's 2016 or so when I first went. And it felt for a number of years...maybe those first four-ish years it was always the people at KubeCon were the, like, big dreamers and thinkers and, like, we're here to change the future of cloud infrastructure. And this is going places, and we're excited to be here and be a part of it. And here's what I'm going to do that changes the next thing. And I feel like now if I go to KubeCon, it's a lot of people from, you know, IBM and some big bank that are, like, deep sigh, well, I have to adopt Kubernetes. I need to know what the vendors are. What do you guys do, and how does this work? Can you please teach it to me? Because I'm being told by my boss, I have to do it. I don't see that excitement around Kubernetes anymore. The excitement I see is all around further up the stack, you know, things like Wasm, WebAssembly, or eBPF, the networking things and tracing things that are possible. Maybe that's further down the stack. I guess it depends on how you think about it, but different part of the stack. So, I'm curious, touching on the serverless components of Kubernetes; sure, I get that. And I do think, increasingly, the PaaSs of the future are all going to be Kubernetes-based, whether that's exposed or not. But where are the places that you think it's still going to go? Because I feel like it's already gotten boring, maybe in a positive way. But I don't see the excitement around it like I saw a few years back. And I'm curious what else you think is going to happen. JOE: Yeah, I mean, I don't think I disagree. I think Kubernetes itself, the core concept, is, like, it's still changing. But you're right that the excitement about Kubernetes existing has gone down because it's been there for a while. But I feel like the ecosystem is still growing pretty rapidly. Like, the things you mentioned, like Wasm and Istio, and all the tools in that ecosystem that continue to grow, is where I think the interesting things will happen. Like, it's created this new lower-level layer of abstraction that makes it possible to build concepts and technology that could not have existed before. KENDALL: Yeah, well, and I'm, you know, talking to people who are working really hard at making short-run ephemeral workloads work better on things like GPUs for the sake of AI, right? Like, I mean, there is some really interesting things happening, and people are doing this in Kubernetes. So, I get that. I agree with that. It is interesting that Kubernetes has become sort of the stable thing, and now it's about who can build the interesting add-ons. It's almost like, okay, we've built Half-Life. What is Counter-Strike going to look like? You know. That's a terrible (I'm aging myself.) example. But still. VICTORIA: I think it's interesting, I mean, to look at the size of the market for platform engineering right now. In 2022, was 4.8 billion, and it's estimated to be in 10 years $41 billion. So, there is this emerging trend of different platform engineering products, different abstractions on top of Kubernetes. And I wonder what advice you would have for a technical founder who's looking to build and solve some of these interesting issues in Kubernetes and create a business around it. KENDALL: Well, okay, let me clarify that question. Are you thinking, I'm a startup, and I need to build my infrastructure, and I'm going to choose Kubernetes. What advice do I need? Or are you thinking, I am founder, and I want to go build on the Kubernetes ecosystem. What advice do you have? VICTORIA: Now I want to know the answer to both. But my question was the second one to start. KENDALL: One of the things that is hard about the Kubernetes ecosystem is there's not a ton of companies that have made a whole bunch of money in Kubernetes because, as I said, I still think we're actually really early in the adoption curve. The kinds of companies that have adopted Kubernetes are the kinds of companies that don't spend lots and lots of money on an infrastructure. [laughs] They're the kinds of companies that are fast-moving, early adopters, or, you know, those first followers, and so they're under $100 million companies for the most part. Where the JP Morgans and Chase are running Kubernetes somewhere in their stack, but they haven't adopted it across the stack to need the biggest, best tools about it. So, the first piece of advice that I'd give is, be a little wary. It's still very early to the market. Maybe now is the time to build the thing. When ReactiveOps pivoted to Kubernetes, I think it was six months of having conversations with companies who were just, like, so excited about it, and this is definitely what we want to do. But nobody was doing it yet. You know, it was, we have, like, six solid months of just excitement and nobody actually pulling the trigger. And, you know, we were a little too early to that market. And that was just the people adopting it. So, I think there is some nervousness that cloud-native solutions the only people who are really making money in Kubernetes are named Amazon, Google, and Microsoft because it's the cloud providers that are making a ton off of it. Now, there's Rancher. There is StackPointCloud. There's a few others that have had big exits in this space. But I don't think it's actually as big of a booming economy as a lot of people think, in part because EKS is an incredibly amazing product. Like, eight years ago, the thing people paid us the most to do at ReactiveOps was just stand up Kubernetes because it was so stinking hard to just get it up and working. And now you click some buttons. Anybody can go do that. So, it's changed a lot, right? And I think be wary when you're entering that ecosystem. And then, my advice to the founder that's not building on the ecosystem but just looking to adopt a technology that's going to be a future-proofed infrastructure is just adopt one of the cloud-native platforms. And there are a whole bunch of sort of default best-in-class add-ons out there that you need to throw in. Don't adopt too many because then you have to maintain them forever. That's the easiest way to get started. You can figure out all the rest of it later. But if you go use EKS, or GKE, AKS, you can get started pretty easily and build something that is going to be future-proofed. I don't know, Joe; I'm curious if you disagree with any of that. JOE: Well, I think it's interesting to think about who's making money in Kubernetes. Like, I think there might not be as many companies who are doing only Kubernetes and Kubernetes-focused products that are massively successful. But I think because it has had a good amount of adoption and because it's easier to work with something that's standardized, it has helped companies sell things that they wanted to sell anyway. Like, all the Datadog, all the Scalas, the logging companies, they all have Kubernetes add-ons. And now everybody is paying Datadog [laughs] to have a dashboard for their Kubernetes cluster. I think they're making more money than they would have been without targeting the market. And so, I think that's really...if you want to get into the market, it's not, like, I'm going to build a Kubernetes product. It's if I'm building operations and an infrastructure product, I should definitely have it work with Kubernetes, and people will want to click and install it. KENDALL: So, to be clear, you know, one of the companies that I work with is called Axiom, and they play in the same, you know, monitoring, observability space as Datadog does. And part of what makes Kubernetes interesting in that space is in a microservice environment; there's so much happening. Where are problems being caused? We don't live in a day where I can just run my code, and it tells me that there's an unexpected semicolon on line 23, right? Like, that still happens. You're still doing those things. But this microservice talking to that microservice is where things tend to break down. Did I communicate this correctly? What was sent? What was received? Where did it break down? What was the latency? And if you were doing things in the old way back when you were standing it up with, say, Ansible, or Puppet, or something like that, and you were orchestrating all of these cloud virtual machines, you had to really work hard to instrument the tracing and logging and everything involved in order to track what was going on. Whereas that's one of the magic things about Kubernetes is with a few of the add-ons or some of the things out of the box with Kubernetes, it's a couple of clicks to get so, so much of the data and have insight into where things are going and what's going wrong. And so, I 100% agree with that. Kubernetes is generating a tremendous amount of data. And if you're a data company, it's really nice to have all that come in, and it helps them make money, helps the user of Kubernetes in that situation understand where problems are happening and breaking down. Yeah, there's definitely some network effects of what Kubernetes is doing in that. I completely agree. JOE: I think there are also some interesting companies, like, where they make...Emissary, Ambassador, and they have that sort of dual -- KENDALL: Komodor, is that -- JOE: Yeah, maybe. They have open source, but then they have a product. KENDALL: You're thinking of Ambassador Labs. JOE: Yeah. Ambassador Labs, yeah. I guess I don't really know how much money they're making. But I think that's a really interesting concept as people who make open-source things then make a well-supported product built around it. KENDALL: Sure. What's interesting is, I think in the VC world, at least right now, and it may pick up again, but post-Silicon Valley Bank nearly caving in, I think that the VC tolerance for, yeah, just go get a billion open-source adopters, and we'll figure out how to monetize later I think that the tolerance for that is a lot lower than it was even six months ago. JOE: Yeah, I think you have to have a dual model right from the beginning now. KENDALL: Yeah. Agreed. VICTORIA: You got to figure out how to make money on Kubernetes before you can. [laughs] KENDALL: You know, minor detail. That's why I think services companies in this space still have a lot going for it. Because in order to even be able to sell software to a company using Kubernetes, you half the time have to go stand up Kubernetes for them because it is still that hard for so many people to really adopt it. VICTORIA: Yeah. And maybe, like, talking more about, like, when it is the right decision to start on Kubernetes because I think the question I get sometimes is just, is it overkill? Is it too much for what we're building? Especially, like, if you're building a brand-new product, you're not even sure if it's going to get adopted that widely. KENDALL: I mean, and I'm [laughs] curious your thought on this, Joe, but there's a good argument to be made that Heroku was enough for the vast majority of founders early on. But the thing is, Kubernetes isn't as hard as it used to be. Going and clicking a couple of buttons on GKE and deploying something into Kubernetes with GKE Autopilot running it's not as easy as Heroku, but it's not wildly far off. And it does substantially future-proof you. So, when is it too early? I'm not sure it's ever too early if you have an intention of scaling if you're planning on running some kind of legacy workload, like, things that are going to be stateful. Or maybe WordPress, for example, you don't probably need to deploy your WordPress blog onto Kubernetes. You can do that in your cPanel on Bluehost. I don't actually know if Bluehost even exists anymore, but I assume it's still a thing. I don't know, what would you say, Joe? JOE: I agree with that. I think it's a hard first pill to swallow. But I think the reality is that it's very easy to underestimate the infrastructure needs of even an early product. Like, it doesn't really matter what you're building. You're still going to have things like secrets management. You're still going to have to worry about networking. They just don't go away. There's no way you have a product without them. And so, rather than slowly solving all those problems from scratch on a platform that isn't designed for it, I think it's easier to just bite the bullet and use one of the managed solutions, especially, as you said, I think it's getting easier and easier. The activation energy from going from credit card to Kubernetes cluster is just getting lower. KENDALL: And so, the role of the CTO is just getting easier and easier because they can just adopt the one technology, and it's obviously Kubernetes. And it's obviously Rust, right? [laughter] Yeah, no, I'm with you. And I think if you find somebody who knows Kubernetes inside and out, it's really not going to take them long to get started. VICTORIA: Yeah, once again, change management is the biggest challenge for any new innovation coming into adoption. So, I'm curious to talk more about the influence that you need and how you influence others to come around to these types of ideas, like, in the executive suite and with the leadership of a company, especially on these types of topics, which can feel maybe a little abstract for people. KENDALL: How you influence them specifically to use Kubernetes, or just how you talk with them about technology adoption in general? Or what are you asking? VICTORIA: Yeah, like, how do I get people to not just turn their ears off when I say the word Kubernetes? [laughs] KENDALL: Yeah, I mean, I think...so I think that's where it's the technologist's job and the role of the CTO to translate these things into business speak. And that's why I'm using words like future-proofing your infrastructure is because there are companies that...I know one company that made a conscious decision that they were going to try to re-platform every single year, and that is not a good idea or sustainable for the vast majority [laughs] of companies. In fact, I can't think of a single situation where that makes sense. But if you can say to the CFO, "Hey, it's going to cost us a little bit more right now. It's going to save us substantially in the long term because this is the thing that's winning. And if we go standardize on Heroku right now, every company does eventually have to migrate off of Heroku. They either go out of business, or they get too big for it." That's the kind of thing that needs to be communicated in order to get people to adopt it. They don't care what the word is. They don't care if you're saying Kubernetes; you know, most CFOs understand it about as well as my mom does. My mom tries to bring it up in conversation because she's heard me use it. And she thinks it makes her sound smart, which maybe it does in the right climate. VICTORIA: My partner does the same thing. He says DevOps and Kubernetes all the time. I'm like; you don't know what you're talking about. [laughter] JOE: Those words do not come up in my house. KENDALL: One of my kids asked me to explain Kubernetes. And I do a whole talk, particularly at organizations where understanding Kubernetes is essential to the salespeople's role. And I give a whole talk about the background of how we got here from deploying on some servers in our back room. And, you know, what's different about the cloud, what containerization did, et cetera. And I have this long explanation. And I remember taking a deep breath and saying to my kids, "Do you really want to hear this?" And I had one son say, "Yes, absolutely." And my wife and three of the other kids all stood up and said, "No way," and left the room. So, when somebody asks me, "What do you do?" Actually, one of the key relationships I built with some of the early people at GCP when we were partnering closely with them was a person that I met, and I asked, "What do you do for a living?" And he said, "I can tell you, but it's not going to mean anything to you." And I was like, "That's what I say to people." And it turned out he was in charge of, you know, Kubernetes partnerships for Google. I can explain to you what it means and why it's important. But you're not going to be happy that I spent that time explaining it to you. VICTORIA: [laughs] That sounds awesome, though. It sounds like you built a server rack just to demo to your children what it was. KENDALL: No, no. I just talked back through the history of...that company that I mentioned that built Twitter about five years too early; we had a, you know, we had a server rack in the...literally physically in our closet that was serving up our product at the time. VICTORIA: Probably the best demo I ever saw was at Google headquarters in Herndon, and someone had built...They had 3D-printed a little mini server rack that they had put Raspberry Pis onto, and then they had Kubernetes deployed on it. And they did an automatic failover of a node to just demo how it works and had little lights that went with it. It was pretty fun. So maybe you should get one for yourself. [laughter] It's a fun project. KENDALL: They remember the things that it enables. They don't remember what it does. And so, when I say so, and so is a client that's using this technology, then they get real excited because they're like, "My dad makes that work." And I'm like, well, okay, that's kind of a stretch, but you get the idea. VICTORIA: Yeah, you got to lean into that kind of reputation in your house. KENDALL: That's right. VICTORIA: And you're like, yes, that's correct. KENDALL: That's right. [laughs] VICTORIA: I do make Kubernetes. I make all the clouds work, yeah. KENDALL: Actually, my most common explanation is Kubernetes is the plumbing of the internet. Unless you're a plumber, you don't care about the pipes. You just want your shit to flush when you use the toilet. You want the things to load when you click your buttons. You don't actually care what's going on behind the scenes, but this is what's orchestrating it increasingly across the internet. VICTORIA: So far, we've called Kubernetes WordPress or the toilet. [laughs] KENDALL: The plumbing. [laughter] VICTORIA: You are really good at selling it. [laughter] KENDALL: Hey, if you want to build a nice, clean city, you need good plumbing. You might not care what the pipes are made of, but you need good plumbing. [laughs] VICTORIA: Works for me. On that note -- [laughs] KENDALL: Yeah. Right? Right? VICTORIA: That's [inaudible 36:41] on a high note. Is there anything else that you'd like to promote? KENDALL: With regards to CTO Lunches, we have a free listserv. There are local lunches. If there isn't a local lunch where you are, it's very lightweight to start up a chapter. We often have folks who are willing to sponsor that first lunch to get you going. We do have a paid tier of CTO Lunches. If you want a small back room Slack channel of people to discuss, I think it's $99 a month. Yeah, if you're a CTO and/or a senior engineering leader and you want a community of people to process with, be it our free tier or our paid tier, we've got something for you. We're trying to invest in this to build community around it. And it's something we enjoy doing more than almost anything. Come take part. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Kendall Miller.Sponsored By:thoughtbot: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneursSupport Giant Robots Smashing Into Other Giant Robots

Alaina Percival is the Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers. Alaina delves into the origin and mission of Women Who Code, highlighting its community building, free technical events, and collaboration with companies to promote diversity in hiring. Victoria adds her personal experience with the organization, emphasizing its positive impact on her career. They discuss the challenges faced while expanding Women Who Code, including the need for systems and processes to manage growth. Alaina recounts stories of discrimination faced by women in tech and stresses the need for continued support and encouragement. The conversation also touches on the financial benefits of diversity and the alignment of Valor Ventures with Women Who Code's values. This discussion offers a detailed look into the women in tech movement, the importance of community, and the drive to create a more equitable industry. It serves as a reflection on both the strides made in fostering diversity and the work still needed to create a truly inclusive technology field. __ Women Who Code Join the Women Who Code Slack! Women Who Code Podcast Follow Women Who Code on Facebook, LinkedIn, Instagram, GitHub, Twitter, or YouTube Follow Alaina Percival on LinkedIn or Twitter. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: WILL: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Will Larry. VICTORIA: And I'm your other host, Victoria Guido. And with me today is Alaina Percival, Venture Partner at Valor Ventures and Co-Founder and CEO of Women Who Code, with a mission to empower diverse women to excel in technology careers. Alaina, thank you for joining us. ALAINA: Thank you so much for having me. I'm thrilled to be here. VICTORIA: I'm thrilled to have you as well. I reached out. As you know, I was previously a Director of Women Who Code D.C. and helped to organize our DevOps and cloud series when I lived there. And it really had a huge impact on my career. So, I'm just super psyched to talk to you today. What's going on in your world, Alaina? ALAINA: So, in addition to my full-time job of working with Women Who Code, I'm also a mom of two young children, and so they're currently three and five. And so, it's summer. We've got summer camp. Every week is a different program with different details and things that you have to read and stay up on. It's a lot of additional project management added on over the summer. I'm looking forward to getting back to the school year, where I can kind of focus on just one role. WILL: That's amazing. And I can totally relate because I have a four, a three, and a one-year-old. Yes, it's a different story when you have to, like you said, project manage around them. So, that's amazing that you're wearing so many hats, and you're doing that. Hats off to you. ALAINA: Same to you. [laughter] WILL: Victoria, what about you? What's going on in your world? VICTORIA: Well, it is summertime at the beach, so all the kids are out. [laughs] It's busy. But that means that you know, the weather is warming up. It's tempting to try to go surfing again, so we'll see if that ends up happening anytime soon. But no, I'm hanging out. I'm local. I'm kind of done traveling for a little bit, so not until I go out to Outer Banks to visit my baby niece and nephew in August. So that's where I'm at right now. I'm kind of hunkered in trying to survive without air conditioning here and get through the summer. [laughs] WILL: You don't have AC? VICTORIA: I do not. Yeah, there's a lot of houses around here just never were built with it. I have heat, but I have no air conditioning. ALAINA: Are you being hit with the heat wave that's happening? VICTORIA: Yes. But it's still very mild. We're spoiled here for sure on weather. WILL: [laughs] VICTORIA: It's like 77, and I'm like, ugh, it's so hot. [laughs] WILL: I'm in Florida, and it amazes me. So, I got up early, around 7:00 o'clock, to go out for a run, and it's, like, 87 degrees. And it feels like almost 100 at 7:00 a.m. And I'm like -- VICTORIA: Oof. WILL: How? [laughs] Like, the sun is barely out, and it's already reaching 100. So yeah. ALAINA: I feel you. I'm in Atlanta. Yesterday, I had an in-person meeting. Typically, we're entirely remote. So, I was wearing real pants [laughs], and it was a hard day. We're not quite as hot as Florida. We are in the low 90s. But yeah, this weather is for real. WILL: Yes. [laughter] VICTORIA: That is the...yeah, working in person again in a hot climate. [laughs] I forgot the challenges of that of, like, trying to navigate life while having to be fully clothed is difficult in that kind of weather. So, I'm glad. I hope you all find some ways to stay cool and to entertain your children [laughs] so that you have some sanity and can get through the summer. I've also been really interested in the European model of just taking five weeks off in the summer. Doesn't that sound nice? WILL: Yes. [laughs] ALAINA: Yeah. I started my career off in Germany. I worked for Puma. Their headquarters is right outside of Nuremberg in a town called Herzogenaurach. And people really do take the whole month off August. And, in fact, you would even separate out the salaries. So, you got something called urlaubsgeld, which was vacation money. So, you would get kind of a little bonus going into August, and then everybody would take off. So, I agree with you. We should be doing that. VICTORIA: Yeah, we should be doing that. And I'm so excited. Maybe we can segue into, like, your background and how you got started. How did you go from there to founding Women Who Code? ALAINA: Yeah, so after working at Puma, I somewhat came back to the United States. I did a dual degree program, an MBA where I was studying between Atlanta, so I could get back in the United States, spend some time with my family, and then also the Sorbonne in Paris. And I did an MBA and a degree in organizational management, Master's in organizational management. Then I went to work for really small ones, performance wear company. And that was more, like, a startup because you really had to think outside of the box. You know, you're a small $10 million a year company, and Nike and Mizuno, you know, these big companies are your competitors. So, I had the opportunity to move out to San Francisco. It was one of the cities that was always on my list of, hey, if you get a chance to do it, go for it. And I did. So, I moved out there, and I kind of hit a bit of a wall with my career, an unexpected wall because up until that point, I had just this really, you know, successful early career. I got out there, and they're, like, Puma. You know, you haven't worked for Microsoft, or Twitter, or Facebook, or Google. Who are you? So, I started learning to code just to transition my skill set to help me understand the culture and the language and just getting more involved in the tech community. And I was still struggling a little bit in figuring out my transition pathway and got more and more involved with Women Who Code and started, you know, spending my nights and weekends. And finally, I was at a small startup that had gotten acquired, so I had my official tech credibility. And I went to work for one of the top technical recruiting firms, executive recruiting firms in the Bay Area, as their head of developer outreach. And I largely chose that role because they were allowing me to run their philanthropic arm, and I focused that around supporting underrepresented communities, you know, get a leg up in the tech community. And then, while I was there, I was working with CTOs, vice presidents of engineering, directors of engineering on a day-to-day basis. And I started learning what they were doing in their career to help develop and cultivate the success that they were having, and I started bringing that knowledge and programming into Women Who Code. And that's where our mission around seeing diverse women excel in technology careers came about is, you know, that piece of retaining and seeing diverse women excelling was an area that wasn't really the focus at the time. And I feel like it sounds funny now because it's such a big piece of conversation. But that was the beginning. VICTORIA: Yeah, it's so interesting that your experience from being in a startup and then how you moved up into being really involved in the hiring and the process of how women...how anyone would actually, like, move up in their career led you to have that background to found Women Who Code. And for people who maybe don't know, [laughs] no, I certainly know what it is. Can you talk a little bit more about what it offers to women and what it offers to companies who are looking to hire diverse women? ALAINA: For individuals, we are the largest and most active community of diverse technologists. We have close to 350,000 members. We're serving members across 147 countries. And we're producing close to 2,000 free technical events every single year, so that's about an average of 5 per day. Once those events take place, if you happen to miss them if you happen to not be in a location where they're having them in person, we're putting a lot of that on our YouTube channel. So, you can go back when you have time, when you're available, still invest in yourself and learn some of these technical and career-related skills. You can also, you know, when you think about, say, the 2,000 talks that are being delivered at Women Who Code, the majority of them are being led by and delivered by diverse technologists. So, we're creating role models and helping people who are on their career path have a sense of belonging, see a pathway to success. People who are thinking about the career path see themselves represented as thought leaders, as leaders in the tech industry. And that sense of belonging, that sense of drive, is just so important to be able to continue on in your career. But we work with companies. So, Women Who Code is dedicated to accessibility. All of our programming is free or scholarship accessible. And so, what we do is we work with companies, and we do this for two reasons: for programmatic reasons. Because we know that if companies develop strong diversity, equity, and inclusion, and belonging practices, that we will reach our mission and vision so much faster than if we work with every individual in the world. But it also creates an opportunity for us to be able to support the community. So, we work with companies to sponsor Women Who Code to donate to support Women Who Code's programming. We have our first-ever walk coming up, so a walk, run, roll called Women Who Code to the Finish Line. And we're going to be having that in September of this year. And that's going to be an opportunity for the stakeholders. You know, often, people who aren't in our community but absolutely support us say, "How can we help?" And so, companies can form teams and go and walk, run, roll to change the face of the tech industry. Right now, we're also in a position where the tech industry has been doing a lot of layoffs, so there's a lot of instability. And so, when that happens, our programming thrives. So, people are coming to our events in high numbers. People are participating in our programming. People are visiting our job board. It's the time when companies are stepping back and pulling back on their funding and things like that. So, I just encourage every single company to...if you have a great technical job open, make sure you're sharing it with the Women Who Code community because we have incredible technologists. They deserve access to companies that are willing to support them and the best roles that are available in the industry today. WILL: Alaina, I just want to honestly and truly say this, what you're doing is amazing. Having a background in nonprofit, over 140 companies, over 300,000 in your membership, and it's an international nonprofit. It's truly amazing what you're doing and helping women find their role and help them become better. I'm truly just blown away by, you know, you started in September 2011, so you're coming up on 12 years this year. And just 12 years as a nonprofit and doing this, share with us how was it received at the very beginning? Because I feel like that was a different time that we're in right now. ALAINA: Yeah, it started off as a meetup, just a community group in San Francisco. And it was incredible. It felt like our little secret. And we were spending time together. We were learning. We were building connections. And just it was this incredible community. And then, the world started talking about, hey, we need to teach girls to code. We need to teach women to code. And we were this community of people in the industry. Our average age at Women Who Code is 30, so 50% of our members are currently in technical roles. So, we had this moment of, hey, we need to elevate the voice of those who are in the industry right now, alongside teaching girls to code and teaching women to code. Because if you miss out on that, it actually becomes a threat to the women in the industry who, every time you hear "Teach women to code," you're saying she doesn't already know how to do it. And we had so many people in our community who already did and already had to kind of prove themselves on a regular basis or constantly underestimated. In the early years, a Women Who Code leader who told me that she was managing a booth at a conference, and everyone was an engineer except for one recruiter, and the recruiter's name was Brian. Someone walked up to her and said, "Are you Brian?" Because it was easier to imagine that her name was Brian than that she was one of the engineers at the table. And so, kind of going through this, we said, hey, we need to elevate our voices. We need to elevate the needs of women in the industry. And it feels being in it day by day, that nothing's happening. But when you look back over 13-15 years, you see that parental leave policies have improved significantly, that we see numbers in leadership going up across the board, that it's part of the conversation that relatively standard and tech companies to have DEI roles within the organization, within the people team. And so, these are not enough. It's just the beginning. But it is a lot that's taken place over the past 10 to 15 years. VICTORIA: I agree. And I can relate as someone who was a project manager working in a technology space. Was it back in, like, 2013 or something? And you'd go to tech meetups, and most likely, I would be the only woman there. [laughs] But then, with Women Who Code, my friend invited me to go to a Ruby event, and it was, you know, all women. [laughs]. There was a woman who was even giving the instruction. And so, that was just a really cool feeling after having been out networking and feeling kind of isolated to really find a lot of people who are similar to you. And I remember part of the narrative at that time when we were talking about increasing inclusion and diversity in technology; there was a narrative that, well, there just aren't as many women in tech. And being a part of Women Who Code, I could be able to, like, answer back to say, "Well, there actually is a lot of women in tech." And it's the bigger problem that women would get started because they're interested in the industry and having good careers, but then they would fall out midway. So, there just wasn't enough progression in their careers. There wasn't enough support on the parental leave side, or there just wasn't enough community to keep people interested, like, when you're the only one. And many of our members they were the only women in their company, and then Women Who Code was where they found people they could really connect with. So, I just think it's interesting that it solves a particular problem where we would have women who are just interested in learning to code who would come to our events. And then, we had women who were actively coding in their jobs and teaching others in these leadership roles within the community to advance their own careers. And that's certainly what I did, and how I broke into executive leadership was, like, I'm a director at Women Who Code and I've got all this other leadership experience. And I'm bringing that network with me. It really increases your value to employers and demonstrates your leadership abilities. ALAINA: Yeah, I couldn't agree more. The program which we kind of fell into, it's our volunteers, is our program that I'm actually most proud of at Women Who Code. And it's probably because I get to know our volunteers because I know so many people's lives and careers are impacted by our programming. But that leadership development, that practice-based leadership that our volunteers are able to obtain, the doors that get open, and just like you said, it opened doors. And I remember it hit me when one of our volunteers told me she was interviewing with SpaceX. And one of the reasons they said they were excited to talk to her was because of her Women Who Code leadership experience. And I just thought to myself, we're doing something right. [laughs] VICTORIA: Yeah, absolutely. And I think maybe part of Will's question before, too, is, like, did it always feel like you were doing something right? Or did it all just come together naturally? Or what kind of bumps did you initially hit when you were getting things off the ground? ALAINA: Yeah. When we first got started and realized, hey, we need to make Women Who Code more accessible, we were doing everything in a very manual way. We needed to adapt to building systems and processes, and that's not the fun part of running a volunteer organization. And when you're moving so fast, it means slowing things down a little bit to be able to make sure that you can do things better, more consistently, more efficiently, but it's so critical. And so, I would say we kind of launched outside of the Bay Area in a couple of cities. And it just snowballed until we expanded into 20 to 40 more cities within probably a year outside of that. And we just really needed to catch up on creating systems and processes, which is not beautiful at all, but it's an important part of running a real business, a real company. WILL: That's amazing. First off, I just want to say I am so sorry that the world we live in looks down upon women or anybody. So, I'm just so sorry that, like, the story you said about Brian, asking the lady that. I feel like that's so disrespectful. I am so sorry if you ever got treated that way or anything like that. And so, I was going to ask this question, and then I kind of answered it. But the question was, do you think women are at a place to where kind of equal in tech? And I kind of answered my own question and said, "No." And so, I want to reframe it. What do you think it will take to continue to help the women get to that level of where it should be? ALAINA: It's going to take a lot of things. But the fastest and easiest way to create more equality for women and girls in the tech industry is by investing and supporting the incredible talent that is in the industry today. We need them to thrive. We need them to stay in their careers. We need them to become leaders with power and influence to create more equity in the industry so that when future generations are coming in, they're coming into an industry that is less broken for them, that is more welcoming, that shows and demonstrates more opportunity. This is one of the most exciting and innovative industries to be a part of. So many things are being shaped and built for the first time that are systems that are going to be the foundations for years or centuries to come. And so, it's more important now than ever for us to be thinking about bringing equity into that so we're not dealing with technical debt, where we're starting from a system that has more equality to it. VICTORIA: I really appreciate that perspective. And I'm curious how that relates to your work at Valor Ventures as well. ALAINA: Valor Ventures is very aligned with the values of Women Who Code, which is why I chose it. I am passionate about creating more equality and opportunity for diverse individuals to thrive and succeed in general but via the tech industry. And so, when I move into focusing on entrepreneurs and focusing on seeing diverse entrepreneurs succeed in building thriving organizations, I see an opportunity to have someone who will be thinking earlier about the policies and the practices that are going to build more equitable teams, products that are really for all of their users. VICTORIA: I think that's a great mindset. And it reminds me that when we talked about, like, the importance of diversity, and equity, and inclusion, that it's not purely a moral thing, even though morally we know we want to support and be inclusive, but that it's also good business strategy [laughs], just by the value of having different perspectives and different types of people, and then being able to have your products be accessible for a diverse group as well, right? ALAINA: Yeah, the data shows teams that are diverse are smarter. Companies that have women represented in leadership they have a stronger ROI. There's business reason behind it. There's certainly a social-moral reason that it just should take place. But, you know, if you need to come back to your shareholders or your investors, there's financial data around it. WILL: Yeah, I totally agree on all that, like, yes, yes, yes, yes, yes. MID-ROLL AD: Now that you have funding, it's time to design, build, and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Liftoff brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we'll help launch your new product and guide you into a future-forward business that takes advantage of today's new technologies and agile best practices. Make the right decisions for tomorrow today. Get in touch at thoughtbot.com/liftoff. WILL: What have you seen hold back women in this space? And the reason I'm asking this question is because there are some biases out there, and, at times, we don't even realize it. For example, I know we have parental leave. And before I had kids, I didn't understand parental leave at all. But then, now that I have kids, I'm like, oh, it is not even close to being enough time during that time, you know, four or five hours of sleep at night, just all those things. So, in your experience, what have you seen? And hopefully, we can use this as a learning opportunity for anybody that just may be blind to it. What have you seen that kind of holds it back? ALAINA: That's holding back, like, implementing specific policies and practices or? WILL: Yes, holding back the policies, or maybe women not being as prevalent in tech roles any of those areas. ALAINA: So, sort of two different approaches with that is I'm optimistic. I think most companies, yes, they care about the bottom line, but they want to be doing the right thing if it's easy. Leaders like me we need to put pressure on companies making better decisions. But also, industry leaders and organizations out there need to be able to make it easier for companies to make the decisions that are going to create more equity inside of their organization. I know that's taking the responsibility off of them a little bit. But companies won't make commitments. They won't do the hard things if they don't know how to do it. And so, the easier that we can make it for them to make the right decision, the more likely they are to make the right decision. VICTORIA: I think that people want to do the right thing if it's easy is a really succinct way to explain a lot of, like, social and moral [laughs] issues right now, right? Most people generally want to do the right thing, but it can be complex. I'm curious about, speaking of complexity, for Women Who Code, going through, you know, being an organization that was built around in-person events, and then having COVID happen, so, like, what were some of the challenges of the last few years and changes that you experienced along the way? ALAINA: Yeah, when COVID hit, that was a big moment for the whole world. It was certainly really hard for organizations that rely on in-person activities. You know, our major conference supplied a third of our operating revenue. Our members were going to, you know, close to 2,000 in-person events. And so, we had to adapt just like everyone else. The organizations and the companies that adapted were the ones that thrived. So, we had to completely retrain all of our volunteers from doing in-person events to be able to create digital events for our community. We had to figure out how to produce major events, and conferences, and hackathons and do it in a remote way. And then, of course, there's the day-to-day that absolutely everyone had, and that was, you know, just your team went from meeting in person to everyone being remote. And some of the great things that came out about that is we were serving members in about 26 countries and about 80 cities, and now we serve members in 147 countries. It just made it accessible that if you don't happen to be in a location where an event is happening and you also don't happen to have childcare, be able to participate, that you are still able to participate in an online setting. And then, what we saw with being able to start moving more of, you know, those talks that were being delivered to our YouTube channel, it then became even more accessible. People spent about five years of life watching our YouTube trainings, and that's time people are investing in themselves. And when I say they did it, and I'm talking about in 2022. So, our YouTube channel, our trainings, they continue to grow, and then our online events continue to happen. But luckily, now we are able to start going back in person. And it's, again, just so amazing to be able to see the people you haven't seen in a long time, feel that feeling that is just a little bit different for an in-person event. WILL: That's amazing. So, from, say, 2019, 2020 to now, it went from 80 countries to over 140, just because of the pivot to go more, like, YouTube and tech. Is that kind of what you're saying about the growth of it? ALAINA: Yeah, so about 80 cities, so about 25 countries to serving members in 147 countries. WILL: That's amazing. ALAINA: Yeah, a tremendous amount of growth and creating accessibility around the globe. Previously, we were really only able to focus on tech hubs that had an ecosystem to support it. But, you know, just because you're from a rural area of your state or from a country in the Global South, you still deserve access to this incredible community and all of the free accessible programming that Women Who Code has to offer. When we have a conference, we have people from 88 countries participating. And when you sign into the networking session, you're going to hop on the phone with someone from Nigeria, someone from Bangladesh, someone from your same city, and it's just such an incredible experience to be able to have that global focus and reach. WILL: Wow, that is so amazing. So, let's talk about right now. What does your next milestone look like, you know, in the next six months or next year? What does that look like for you? ALAINA: As I mentioned before, one of the big challenges we've had this year is our programming is going so, so well, but our funding has pulled back a little bit. And so, we're working to diversify our revenue strategy a little bit and have a traditional nonprofit walk that we've never done before. And it's a remote walk, so anyone all over the world can participate just like you can with our digital events. But this has been something new for us. Because when we went through it during COVID, again, you know, you'd get on the call with all of your partners. You know, the world is going through something, and you kind of say, oh yeah, we're in it together. But you don't see the grace that you saw in 2020 and sort of the camaraderie, and we're in this together, and we're going to give you space and support you, you know, in every way that we can that, you know, is just really missing this time around. You know, we have members who absolutely need support in their careers right now. And so, it's navigating through something different. VICTORIA: Yeah. And I guess talking more about inclusivity, like, we have all this free content, and it is Women Who Code. But I remember when I was an organizer, I had a few people ask me, "Well if I'm a man, can I come to your event?" And I was like, "Yes, it's open to everyone," right? Like, it's promoting women, and it's about women growing in their careers. And certainly, if that's not also your intention with attending the event, you should keep that in mind and make sure you're leaving space for other people. But I also really appreciated that it's open for everyone and that it's open for everyone who is in the women umbrella, and being intentional about that, and that it's inclusive of everyone who relates to being a woman, right? ALAINA: Yeah. Women Who Code welcomes all genders. We, you know, really struggle with our name from a brand perspective because it isn't as inclusive as we'd like it to be. So, actually, after we say our name, we try not to repeat the word women anywhere else. From the beginning, been dedicated to having an open, accessible community. But we definitely require, you know, that you are following our code of conduct, that you're there for the intended purpose of the event. And we want to make sure that we're protecting our community. VICTORIA: Well, I really appreciate that. And I appreciate...it sounds like a value organization that I'm with. I always look for those things that that's what we're really promoting. There's been so many changes that have happened with Women Who Code and in your career. If you could go back in time and give yourself some advice when you were first getting started, what would you tell yourself? ALAINA: If I was going back and thinking about what I would tell myself in the beginning, I'd probably tell myself to focus on data sooner. Coming from the history of being a meetup group to transitioning to being a global nonprofit, we dragged our feet around focusing on data impact, and really, it's because we're constantly doing so much programming. We're always doing so many things, and anything you add on is an extra thing to do. And so, I would say focus on the data much sooner. VICTORIA: I can speak to there being a lot of events. I remember back in the heyday in D.C., it was, like, algorithms on Tuesdays and Ruby on Thursdays, and then next week, it would be DevOps. And there was just always something going on. And I thought that was so cool. And I really appreciate just really everyone who is involved in putting on those programs. I really want to emphasize, too, like, the value for companies working with Women Who Code. And what do they get out of the partnership, and how can they really engage with the community? ALAINA: Yeah. So, companies that work with us, it's a partnership. They are there to support the community, and that's what they have to do to really develop trust. And we're going to make sure that we're guiding them in that process. So, if we see an opportunity for them to engage in a more authentic way, we're going to point that out. But companies are often hiring from our community; that's one of the big reasons, not just through our job board because our members are unicorns. They're diverse technologists, and everyone wants to hire them. And so, you can just say, "Hey, come work for me." But really, they want you to explain who's on the team? What are the exciting projects, and what are the exciting technologies that your company is building? So that they can actually identify that your company is an organization that they would want to work for before just applying for a job. And that's what a lot of our partnership creates space for. So, maybe getting an opportunity to join our podcast and tell the story and get to know some of the diverse leadership team or diverse engineering team, learn about some of your, like, commitment to DEI and things like that. Because when a senior engineer receives multiple job outreaches, they're going to respond to the one that they've heard of, that they already know is a good company, that they know is supporting and investing in building equity into the tech ecosystem. That's going to go a long way in them deciding to reply. WILL: That's awesome. Earlier, you mentioned being inclusive of all the members. I think I know the answer, but I just want to double-check. If I want to volunteer, am I able to volunteer at Women Who Code? ALAINA: Yes, absolutely. If you visit our website...and we just updated our website, so I encourage everyone to go visit womenwhocode.com today. It's looking different than it has over the past five years. There's a sign-up to volunteer. You would be absolutely welcome, Will. WILL: Awesome. And, as a volunteer, what would that look like? What could I get involved in? What areas? ALAINA: You could decide to be a speaker. You could apply to be a network leader. You could become a lead in a particular technology area. We have six technical tracks. Our tracks are cloud, data science, Python, mobile. When [inaudible 32:53] hears about it, we will have emerging technologies track that was expanded from our blockchain community this year. And then, we also have a career track as well. So, you can become a lead focused on one of those particular areas in our digital communities. You can get engaged with the Women Who Code community in many different ways. We also have some really cool programs like mentor me and buddy system, so getting involved in those. Building long-form connections or long-time connections with individuals in the community really helps to create a sense of belonging and start to build trust and an opportunity to exchange knowledge. VICTORIA: I always really appreciated people who were, like, "Do you need a space to host your meetup?" Or "Do you want us to buy you pizza for your meetup?" [laughs] Those are very easy ways to engage. And it's true that the membership does see and pay attention to, like, who is regularly getting involved in committing to this, and it makes a difference in your brand and reputation. ALAINA: Absolutely. The companies that work with us absolutely hire from the Women Who Code community. I'll give two examples. So, one of the most exciting examples was we had an event at a company, and they sort of were connecting in an authentic way, not, like, an interview way, but they essentially were doing an early interview with people who were there. And so I remember that it took place on Tuesday, and they had a job offer on Friday at the company that they were at. So, they were just able to move so quickly and hire someone from our community. And then, ages ago, Snapchat was at our first-ever conference, and they had hired four or six people at that event. And it was just so cool to see that we're not a recruiting agency, so we really just rely on either individuals or companies to tell us when they have these amazing career outcomes. So, every time we hear about it, it's always exciting to me. VICTORIA: That's super cool. And I wonder, what is the thing you're most excited about coming up for Women Who Code this year? ALAINA: We have CONNECT Asia taking place later on this year, and so that's our major technical conference with a focus in the Asia market. It's going to be just really, really exciting. We haven't had one since pre-COVID. It's still going to be a remote event. We had CONNECT LATAM, so our first-ever conference focused on Latin America last year. And this year, it's focused on Asia. So, it's really exciting to get back and provide some support to our regional audiences and really showcase some of the incredible talent and leadership coming out of those regions. WILL: That's amazing. So, the question I have for you, and it's easy to assume this question, but I want to hear from you because I know you talked about, at the beginning, how it was when you started the nonprofit. But what is the wind in your sails? Like, what keeps you motivated and going? It sounds like it's an easy answer, but just from your heart, what motivates you? ALAINA: Oh, it is absolutely the stories that I hear, like I said, especially from our volunteers. So, the Mexico City volunteer who, in under a year, told me her salary increased 200%. The director from Toronto, you know, when she stepped up, was an individual contributor, and under one year, she made it to director level, and today she's a vice president. So, when I think of the career impacts that are taking place for our members, and every single time I hear about it, it drives me to wake up. It drives me to work harder. It drives me to deliver better program and just makes me completely connected to what we do as an organization. VICTORIA: What a great benefit. And for myself, personally, it absolutely has been a factor in the last, like, two jobs I've gotten. [laughs] They're like, "Oh, you are a director at Women Who Code? That's so interesting." So, I really appreciate everything that you've done and happy to be a part of that. And my personal network, I know many women who have been through that and benefited immensely from having that networking community. And really, even just being able to see yourself and know that you belong in the industry, I think, is really, really important. ALAINA: I'm sure I'm going to be telling your story the next time someone asks me. [laughter] VICTORIA: That's great. No, please do. And let's see; we're wrapping up at the end of our time here. Is there anything else that you would like to promote? ALAINA: Yeah, please visit womenwhocode.com. If you have technical jobs available, please post them to the Women Who Code job board. Again, it's just womenwhocode.com/jobs. Join our community. Check out our amazing, new, beautiful website, and follow us on social media @WomenWhoCode. VICTORIA: Love that. Thank you so much for joining us today. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you can find me @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Alaina Percival.Sponsored By:thoughtbot: Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoffSupport Giant Robots Smashing Into Other Giant Robots

Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. Marc Mar-Yohana is the CEO and Founder of OtisHealth, a personal health application and platform for patient-caregiver engagement, population health, and clinical research. The conversation revolves around the origin and working principles of OtisHealth, a healthcare app designed to consolidate health information. Marc was motivated to start the app following the tragic death of his eight-year-old daughter, Constance, from an undiagnosed brain tumor. Despite being under the care of multiple health providers, the fragmentation of her medical data meant they missed the signs of her condition. Marc has dedicated his life to developing better tools for families and caregivers to manage their loved one's health. He aimed to create a unified system where all health data could be gathered, enabling caregivers, patients, and medical providers to see the whole picture. OtisHealth allows patients to integrate data from different sources, including wearable devices, and capture information outside clinical settings. The initial outreach strategy of OtisHealth through consumer channels was slow to get traction. The company switched to recruiting through organizations with health interests, such as health insurers or "payers," leading to a significant increase in users. Although not everyone uses the app daily, it is a crucial health management tool for those with chronic illnesses or emergencies. The trustworthiness of OtisHealth is demonstrated through accreditation from the Electronic Healthcare Network Accreditation Commission, indicating that their practices meet or exceed federal regulatory requirements and industry guidelines. This, along with community outreach and educational content, helped build trust with users. Marc's diverse corporate background gave him the skill set to lead OtisHealth, emphasizing the importance of team development and collaboration with other organizations, even competitors, to move the mission forward. __ OtisHealth Follow OtisHealth on Facebook, LinkedIn, Instagram, or YouTube Follow Marc Mar-Yohana on LinkedIn. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Marc Mar-Yohana, CEO and Founder of OtisHealth, a personal health application and a platform for patient-caregiver engagement, population health, and clinical research. Marc, thank you for joining me. MARC: Victoria, I'm honored to be here. Thank you so much for inviting me to join you on this podcast. VICTORIA: You're welcome. I'm excited to have you. So, why don't you just tell me a little bit about what's going on in your world right now? MARC: Well, OtisHealth is keeping me pretty busy. So, I live in Northern California. My team is mostly in California, a little bit in Illinois. And we're busy every day, both supporting our members and working with clients. And so, it's exciting times, especially on our advocacy front. We work with organizations across the country to advocate for patient access to their health records and also for individuals themselves to improve their access to quality healthcare wherever they reside in the United States. The advocacy, the work with our clients, and the work with our members keeps us super busy. Although I do still try to make time to hike in the beautiful scenery out here. I'm new to California. I'm originally from Illinois, so it's great to just be able to get out every once in a while for a hike in the area. VICTORIA: That's wonderful. Have you made it to any redwood forest out there? MARC: Yeah, Muir Woods, which is just north of us, north of the San Francisco Bay Area. Most of the time, we like to walk the coastline. So just north of Santa Cruz is a great state park known as Wilder State Ranch. And they have amazing views of the coastline, wonderful views of birds, as well as occasionally spotting whales, and dolphins, and sea otters along the coast. VICTORIA: That's so cool. I had a friend, actually, who just went up there and went kayaking with the otters, and I'm very jealous. [laughter] It sounds beautiful. MARC: Yeah, that can be fun. Otters are really cute creatures. And they can be aggressive too. There's a concern right now. There's one female otter that likes to grab people's surfboards. And I saw a video of a sea lion jumping on top of a sea kayak to steal a fish from a fisherman. VICTORIA: I think if a sea otter or a sea lion wanted my vessel, a kayak or surfboard, I mean, you can have it. [laughter] You worked this hard. [laughs] MARC: Yeah, they're pretty aggressive. They're more comfortable in the water than we are, so they [laughs] pretty much are in charge in the environment. VICTORIA: That's right. We're in their house, right? So, I'm, like, okay, [laughs] you can have it. That's great. Oh, wonderful. I'm glad you still have time to get outside and enjoy hiking with your family, even though you're a very busy founder [chuckles] and very active advocate for your community. So, why don't you tell me how everything with OtisHealth got started? MARC: So, it started with a tragedy, a horrible tragedy in my life. My daughter, Constance, who was eight years old at the time and had been previously diagnosed with autism, apraxia of speech, and epilepsy, died from an undiagnosed brain tumor. She had great healthcare. She had a neurologist, a pediatrician. She had therapists that saw her five days a week and, of course, her parents watching over her. Yet, we all missed the symptoms, the major illness that claimed her life. And so, because all of her healthcare providers were on different systems, and as parents, we didn't have a system, there wasn't a place to put our observations together. And everyone attributed their observations of her changing condition to other medical concerns. And so, after she passed, I started to spend a couple of years trying to understand what happened. And I realized a big part of it was the information was in front of us. It was just in different people's hands. And when we put it together, we could have seen the whole picture that would have shown that she had a more serious illness. And so I chose a new mission in my life: to abandon my corporate career and move into this role of developing a better set of tools for families and caregivers to manage their loved one's health. And so, our mission today is to work with families, caregivers, and people with chronic illness to give them better tools to manage their everyday health and the health of their loved ones, and thereby also improving lives in the community. VICTORIA: Well, I love that out of the tragedy, you were able to find direction and purpose to solve this major problem, which I can relate to having moved across the country. Your medical records don't come with you. You have to basically kind of start all over, or they have to go get them from your past patients. It's not unified as a system, as you might think that is. [laughs] MARC: That's absolutely right. Our data is spread out across different clinical sources. Just in the time I moved out here to California from Chicago, I saw five different providers just because I wanted to get some tests done. So, I had to go to a few different locations to do a normal battery of tests. And so, I had at least five different health records created just when I moved out here. And they're all in different systems, and they're not even on the same type of application. So, to bring them together, I had to basically download them and put them in files on my desktop computer. With OtisHealth, I'm able to retrieve that data and put it onto one continuous record and watch it. But that's still just our clinical data, meaning data collected in clinical settings. We have more data to share of things that you and I observe as regular people or our families observe. And so, the part that's missing in the record is all the observations in the time that we're not in the physician, in a physician's office, or in the presence of a clinician. We can; with our tools today, such as wearable watches, or blood pressure cuffs that are Bluetooth-connected, we can get a lot more data and share that back into our records so that we have a true baseline, not the once-a-year that I go to see a physician, and they say my blood pressure is high. And the next time I go, it's low. It's because we only have two data points over two years. Where today, with our technology and our capabilities, we can have a baseline of true data continuously throughout the year that will give the physician or care team more insights into how we're doing in terms of our health. VICTORIA: That's so interesting. And it makes a lot of sense to me why someone would want to use this or why doctors would want to use this. And I'm curious, once you had this idea, how did you get that initial traction to get started with OtisHealth? MARC: Initially, it was a little difficult. And this is kind of part of our lessons learned when we started the company. We started advertising on Facebook. This is after we launched the product. So, we launched in 2021. We had the idea that we were going to make this available to a lot of people. We knew a lot of folks that needed it. It was okay to get the first 100 or so people because there were folks that we knew needed the application or folks that were curious about it and wanted to try it. And we started advertising through consumer channels such as Facebook, and LinkedIn, and other magazines to people that we knew had the need for the app. Yet, it was a very slow uptake. And the part of what we learned and we started applying to our marketing or our membership development or recruitment thesis is that the health records are kind of like an umbrella. We don't think about the umbrella or going out to get an umbrella until it's raining, and for most people, it doesn't rain very often. And so, it's not something that people would use every day. In most cases, they use it only when they have an emergency or when they're managing their chronic illness or the chronic illness of a loved one. And so, we eventually changed the way we were recruiting and started recruiting through other organizations, such as clients where we're able to get thousands of users through the client that has members. And then, slowly, over time, teach them the importance of managing their everyday health, and taking their own vitals, and recording that, and they record for themselves and their family. VICTORIA: Right. So, you were able to offer the app for free for daily users because you found another group that was interested in having access to the data and having this app, right? MARC: Yeah. So, anybody today can go to the Apple Store or the Google Play Store and they could download the app for free. And they can use the web version also. And they could share it with friends and family, which I always encourage people to do. So, if you have an emergency contact, invite them to your medical records; at least they have your basic medications, and allergies, and other key information in case of an emergency. What we did in terms of our change of strategy early on is we started going to organizations that also had an interest in improving the health of their population and, in particular, health insurers or what we call in the industry payers. And so, payer organizations could be Medicaid, Medicare, or it could be employee health plan, one of the big health insurance companies like Blue Cross or UnitedHealthcare. They have an interest in people managing their everyday health. And so, one of our clients right now, everyone that enrolls in one of their plans automatically gets enrolled in a version of OtisHealth specifically for their members. And those members could still invite people to join them on the platform, and those people can get on with OtisHealth. But the nice thing is now this payer has a way to both encourage healthier activity or healthier practices for their population and monitor if there's a problem. So, if somebody is missing medications, or not taking their medications on time, or has vitals that are tracking poorly, this gives the payer an opportunity to reach out and ask them if they need help managing their health. VICTORIA: So, how does that dynamic affect how you measure successful engagement on the platform, like, a successful rate of engagement? MARC: So, for us, most people don't use the app every day. Most of us don't even think about our health [laughs] on a daily basis from a standpoint of our medical health or clinical health. Sometimes those of us that exercise regularly think about it in those terms or eating healthy. But we don't think about keeping a record or using an app to maintain our health. And so, for us, an active user is anybody that's logging in at least once a month to update their information. Our really great users are the ones who are using the reminder features to take supplements or take their medications. And so, I would say of the few thousand users that we have—we're approaching 10,000 right now active users—only a small percentage of those, maybe 10%, are actually using it on a daily basis for themselves or their family. And so, for us, a good engagement and good practice is folks setting reminders on at least a weekly basis to take vitals, weigh themselves—something that would help them track their health over time—and if they're taking medications, to set daily reminders for the medications that they take. And so, we currently have far more people enrolled in OtisHealth and that, you know, 5,000, 6000 I mentioned that are active. But they basically bought the umbrella, and they just put it in their closet. They're waiting for that rainy day that they have to pull it out and start using it. VICTORIA: That makes sense. And I'm already in my head going through the people in my family who would benefit from this where, you know, I have family members who have a learning and a physical disability, and tracking everything that they're supposed to be doing to maintain their health is quite difficult. So, I can definitely see the value in that and why people would want to use it. And I think for, you know, healthcare apps, you have to build this high level of trust. You know, people are giving you all this data about their health information. So, how do you go about building a product that people can trust from the beginning? MARC: One of the things we sort early in the life of OtisHealth is an accreditation. An accreditation is not required by law. It's not required by any institution necessarily. It's a third party that reviews our practices and our systems to see if we're actually following good privacy and security standards and practices. And so we went live in November of 2021, and by the end of December of 2021, we already had our full accreditation in what's called a comprehensive level from a national established organization known as The Electronic Healthcare Network Accreditation Commission. And so, that was the first step of making sure that folks understood that we took their privacy and security seriously. That accreditation means that our practices and our technology meets or exceeds federal regulatory requirements and industry guidelines. And that's just the first step. Then after that, it's really a matter of people gain their trust because an accreditation itself doesn't necessarily mean that we trust that brand. That's just a basic starting point for us. After that, we publish articles about maintaining health. We have launched some videos about different aspects of our advocacy, such as with autism for caregivers. And we participate in community activities at the national level to improve patient access and to talk about how important it is to manage our own health and the health of our loved ones. And so, it's a combination of both basic accreditations that show that we made the investment, and we provided a third party to critique us and to review us. And we actively maintain that accreditation is not a one-time stamp. And then, the second part is continuous outreach, and letting the community know what we're working on, what's important to us, so that, over time, they start to look at what we do and start to trust it and invite other people to trust it as well. VICTORIA: That makes a lot of sense. And I'm curious if there were experiences from your corporate career that informed how you acted as a founder and what you prioritized. MARC: I've had an odd corporate career. [laughs] So, I started my career as an engineer in manufacturing operations and in product development and then went down to as a consultant strategy in ops and market management, and then, later, investment management and private equity, and then, later, for a safety science company where I was managing global capital investments in technology and new operations. And so, I've been fortunate that I've had a breadth of experience, from marketing to sales, to product and technology development, and infrastructure management. So, I had some basic skills that helped me understand what...well, the endeavor before I jumped into it because I spent a couple of years thinking about whether or not I even wanted to do something like this. And then, I would say probably the most important part of my previous experience that I apply every day at OtisHealth is developing teams and developing collaboration with different organizations. You know, aside from the team that I have, our own staff, we also work very closely with other organizations, even competitors, to make sure that we're all successful. And so, that collaboration across organizations that don't even have a necessarily contractual relationship is something that I brought over from my previous work and seeing how working across the industry, we can help each other and serve the mission. So, I think that was probably the most important part of my previous work experience that I apply today is this: building a team and building a coalition of organizations that want to move forward together. VICTORIA: That's great. And I'm wondering if there was anything that surprised you in that early phase of building collaboration with other companies and understanding your users that changed the strategic direction you were going with in the app. MARC: So, one of the things that I was really just in awe of was how willing people in the healthcare industry were to jump in and help out when we started talking. And so, many of the organizations that we work with, the founders or the senior staff within the nonprofits we work with, all have a story of why they're doing what they're doing. Many are brilliant people who could have taken their careers in many different directions, not in healthcare. And they chose to move forward in healthcare because of some personal experience in their life. And so, as I learned about the people I was working with, I was surprised how quickly they just took me under their wing and said, "Hey, let's get you started marketing. Let's move OtisHealth forward." And so, we have organizations like Onyx and Invitae [SP] that are giving us support in data access. There's another organization that I can't mention yet; that's another private entity that has offered their support, and we hope to launch with them in the next couple of weeks. And so, we're forming these data access bridges to help get patients more access to their data, their loved ones' data. And then, there's the nonprofits in the advocacy and standards organizations we work with, such as HL7, which is an international health technology standards organization, and DirectTrust, which is an organization that establishes trust networks in ecosystems, as well as the technology infrastructure behind how those systems communicate. And we work also with EHNAC, the accreditation commission. So, we not only are using the accreditation from EHNAC, we're on committees to advise them on future criteria for accreditation. VICTORIA: That's really cool. I love that there's that collaboration and just openness and willingness to try to make things better and to invest in solutions together. Mid-Roll Ad: VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? RICHARD: Hi, Victoria. VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along. And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken. RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So... [laughter] RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... RICHARD: [chuckles] Absolutely. VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. RICHARD: Yeah, it was a pleasure. Thank you. VICTORIA: You mentioned advocacy. And I'm curious if you could say more about what advocacy are you doing or how does that blend into your business model and what you're doing with OtisHealth? MARC: I'll give you an example. One of the organizations we belong to and I participate in personally is the Health Information Management System Society. And so, this is a professional society of healthcare IT professionals. And in Northern California, there's an advocacy committee that works directly with the state legislature to promote legislation that will improve the quality of healthcare for people in California. We actively talk to members of the legislature to tell them what bills we think are important. The ones we focus on and the ones I personally focus on are the ones that improve access to our data and also improve our privacy. So, there's a legislation in California, as an example, that will prohibit access to people's healthcare data without proper legal warrant. So, it's basically extending HIPAA protections across any health app launched in California. And we, of course, are already HIPAA-compliant, so that's very easy for us. There's also advocacy specific to certain health conditions. So, my daughter had autism. I work with the Autism Society here in California and also Achieve Tahoe, which is an organization that teaches skiing and other skills to people with disabilities in particular. This past season was my first season. I work primarily with children and young adults with autism and other developmental disorders. And then we also partner with organizations when we think that they're aligned with some of our mission. And so we work with the Caregiver Action Network. We also will work with AARP and other organizations regarding caregiver rights and also teaching caregivers how to access the healthcare data of their loved ones and how to take care of themselves personally. VICTORIA: That's wonderful. And I guess it's not really a question, but I saw that autism service dogs are a thing, and I just thought that was really cool. [laughs] MARC: Yeah, OtisHealth is named after Constance's autism service dog, Otis. And so, service dogs are extraordinary animals. They're highly trained. Otis had been trained for two years before we received him. He was trained specifically for Constance's needs, and he kept her safe. And that was the primary interest in Otis is observing things that she...because of her cognitive limitations, wasn't always aware of her surroundings and wasn't always safe. And so, the dog maintained her safety and her boundaries and kept her focused, as well as just basically blocked her if she was going to do something that was unsafe. So, there are many different kinds of service dogs, and I'm talking specifically about ADA, the Americans with Disability Act type service dogs. These aren't, like, companion dogs or therapy dogs. These are truly highly trained animals that are focused on specific tasks to help an individual be safer, more free, or have more abilities than their disabilities may allow. VICTORIA: Well, I love that. And I like that the app is named after her dog as well. That's just very sweet. And I love that that's how that worked. And I'm curious, what's on the horizon? What are you most excited about for OtisHealth in the next year? MARC: Like all startups, we have [laughs] a lot of plans. And we've been invited to speak at some conferences. I spoke at two already this year. And I have another one coming up in Washington, D.C., where we're going to advocate, again, for patient access. And this is primarily talking to the health systems themselves in adopting technology that makes it easier for patients to securely access their health records. And so, we're excited about that movement in the industry to recognize and start to act on that need for patients to be able to access their health records. And we work with our partners to promote that and also with the federal government. We work with the health and human services to promote this access. And we were published in a report earlier this year because of our technology demonstration with health and human services. And it sounds like it's finally getting some real traction in hospital systems. And members of the Federal Congress are also saying that this is something we need to move forward with in a more aggressive manner. On a more direct path, we're excited our membership's growing. We've had tens of thousands of people register to use the app, with thousands actively using it today. We're working on some new programs right now for payers and for providers that will improve health outcomes and within their populations, as well as bring on hundreds of thousands of other people on the app. We're really excited to know that we're getting both recognized for the work that we're doing and that people are starting to understand the importance of managing everyday health, whether it's with OtisHealth or another application. VICTORIA: Well, I love being excited for these opportunities to advocate for your product and for the mission behind the product. I'm not going to recommend being excited about going to D.C. during the summer. [laughs] Last time I was there when I landed at 9:00 p.m., it was 90 degrees outside [chuckles] and humid, like, 90% humidity. But it's great to have access to people who care and are trying to make things better and have that voice. I'm excited to see you grow. And then, it's been two years since you started the app. I wonder, if you could go back in time to when you first were getting started, what advice would you give yourself? MARC: So, this is a really hard thing for anybody to look back and say that they'd like to change a few things. There are things I would change. I have a lot of experience managing large, sophisticated programs. Because in the past I had large budgets, it was really easy to maintain strict discipline around the implementation. And I think I was too loose in the implementation process at the onset of OtisHealth. I would have been more disciplined around my program management and the accountability that I had to developers I was using. As a startup, I didn't have a large development team in-house. I needed to use external parties. And I should have been a little more closely on top of that process. The other things that we experienced were primarily a result of pivots. We were constantly pivoting as we were learning. I think having a team to review our process and pivot more quickly is really critical. You don't want to pivot 20 times a week. You need to stay focused for a while, but also having friends or advisors or members of your team that can help you assess when a pivot is necessary, or a new opportunity presents itself, I think, is critical. And so, we all know, as founders, the team is key. And I think the earlier you engage a team and not be bashful by asking for advice, the better. VICTORIA: I love that. And I'm curious if you have any advice from your program or from your startup career now on choosing the right development teams. And how do you find those right partners to actually build the app and have that accountability? MARC: So, I would say the number one thing that I've learned, that I knew previously, but I really appreciate it more now as a founder of a small company, is you need mission alignment, not just company to company, but person to person. And I took my time picking advisors to join us, and I took my time getting people on board to OtisHealth. We pick folks that we believe understand what we're doing, and we take our time and make sure that they appreciate it and that we're comfortable with them. Our startup is too small to make a bad hire or to have the wrong perspective because somebody has other motives, such as just making money. If I was providing advice in terms of picking teams or picking vendors to work with, I would say take it slow. Don't rush, even though you may be in a rush, or we may be in a rush to get moving, either for financial reasons or personal reasons. It's important just to feel comfortable. Get to know folks. Meet them in person if you can and spend a few hours with them at a time [laughs], just to make sure that they believe in you, and you believe in them, and that you have a common vision. Because when things get rough or tough, financially or otherwise, you need people that are going to be able to stick through it and work with you. VICTORIA: That makes a lot of sense. There's a lot of pivots happening. You want everyone to be on the same page. And you don't want to have to be corralling everyone all the time if they have competing priorities, so that makes a lot of sense. MARC: Absolutely. Just to be clearer on that, we all run into challenges. So, in some cases, we had to make some financial sacrifices, and everyone did it together. You really need people that are that committed that say, "Okay, I understand where we are, and so, I'm willing to take a pay cut for a while or not get paid for a while until we can get this spec started again." Even vendors I work with today that are strategic vendors understand that and have helped us financially when we need some time to get more revenue in. VICTORIA: Great. And so, when you were building a healthcare app, was there people you needed to have on your team who had that exact specialty in either patient care, or medical records, or something like that? MARC: Yes, yeah, you need experts. So, I'm a quick read. I mean, I spent a couple of years learning the industry and understanding the technology. But the person that's our IT director he has over 25 years of experience in healthcare IT systems, so he is the expert in-house. We also have advisors on our team that are experts in payer services and payer systems, launching healthcare apps, managing standards, and managing SaaS services. We have a data and an AI expert, and a clinical research specialist. We also have physicians we refer to. [laughs] So, we have a pretty big entourage of individuals that we go to for very specific advice and work. VICTORIA: That makes a lot of sense. Let's see, what question should I be asking that I haven't asked yet? MARC: You know, I think most of the people listening to this podcast are technical founders. And it was surprising to me, and I had some founders contact me, asked for some free advice, which I'm happy to do, but they didn't seem sincere in their interest in being in healthcare. And one thing I told them, and I would say to anybody that's interested in being a healthcare technology developer, is you have to have a reason to do it besides the money. It will be a really hard battle to move forward with a technology if the only motivation is a financial opportunity. That isn't going to sustain the pivots or the development. You'll run into a lot of walls, primarily because everyone will see it. Everyone in the industry sees those players come in that just have a financial interest, and the consumers see it, and they don't like it. So, my advice to anybody that wants to develop technology in healthcare is you have to be a little sincere about it and have a real reason to do it beyond just making money, and I think you'll find it more rewarding. There's so much need for healthcare technology and better technology out there. So, I welcome folks to join the fight, the battle, or the opportunities. But I would say that just come in with the idea that you're helping people, not just making money. VICTORIA: I think that rings true for any business you're in, right? But especially in healthcare because it is this big target. Even in consulting, if you're doing business development and you're thinking of working on health IT projects, there's just a huge market that you have to narrow down and figure out where you're going to be. So, if you don't have that intrinsic motivation, it can be overwhelming and scattered, and then people won't connect with you, right? Because everybody is going after the same thing. MARC: That's exactly right. One of the conferences I went to earlier this year, a speaker got up and said, "People invest in people, or people make deals with other people." We talk about companies signing a deal with another company, but it's really one person trusting another person. Whether it's in healthcare or another industry, obviously, that trust needs to happen. At some point, if I don't trust the individual I'm talking to, I'm less likely to have a deal with that company. VICTORIA: Right. It's like; I don't know how, you know, it doesn't really matter how impressive your credentials are. If there's not a basic level of trust, you might not move forward with it, so that makes a lot of sense to me. MARC: Yeah, that's absolutely right, Victoria. VICTORIA: Absolutely. Is there anything else that you'd like to promote at the end of this podcast? MARC: I'd love for folks to try OtisHealth. If you have family that have chronic medical needs or need help managing their medical information, please download OtisHealth, help them join. There are videos on YouTube that explain how to use it if you need some guidance, but we believe most of it is self-explanatory. We are continuously adding data access points. We're going to be launching this week new versions of OtisHealth that have access privileges for people in New York and Nevada and parts of California and Colorado. And so that means that with the app, once you're ID-proofed on the app, you can use it to get your medical records from different sources without having to log into all these different patient portals. So please try it. Use it for yourself but especially use it for your family or anybody who you care for. We'd love to get your feedback as you use the app too. VICTORIA: That's great. And I'm actually already thinking about...next week; I'm going to be going to The San Diego Annual Veterans Stand Down, where anyone who is experiencing homelessness can come in and get access to all the services that they might need, whether it's legal, or healthcare, or dentistry, showers, food, all of these things. And I'm curious if that organization might benefit from having a tool like that for their users. So, I'll be talking about it. [laughs] MARC: Oh, thank you so much. That'd be wonderful. Thank you. VICTORIA: That's great. Well, thank you so much, Marc, for joining us. MARC: My pleasure. Thank you, Victoria, for having me on the show. VICTORIA: Excellent. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Marc Mar-Yohana.Support Giant Robots Smashing Into Other Giant Robots

Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. __ Simon Ritchie, the founder and CEO of Blox, discusses his background and journey leading up to starting the company. He began his career in finance but discovered his passion for technology and finance systems. He worked at Anaplan, a successful finance planning and analysis software company, but saw the limitations of rigid systems when COVID-19 hit. He realized there was a need for a more flexible and accessible financial modeling and planning tool, especially for small businesses and charities. Blox aims to fill this gap by providing a powerful yet easy-to-use modeling, calculation, and planning engine that sits between spreadsheets and complex enterprise software. The company is about a year old, has raised venture funding, and launched a free tier of its product. They prioritize building a compelling product, iterating quickly, and engaging with users to understand their needs. Simon acknowledges that building the product has been enjoyable, leveraging his background in product management. However, sales, marketing, and customer traction have proven challenging. Nonetheless, he remains optimistic about Blox's progress and is committed to providing a valuable solution to help businesses make informed decisions and achieve their financial goals. Blox Follow Blox on Twitter, Facebook, LinkedIn, Instagram, or TikTok Follow Simon Ritchie on LinkedIn. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with me today is Simon Ritchie, Founder and CEO of Blox, which provides pre-built planning models to help business leaders escape the tyranny of complex, clunky, and error-prone spreadsheets, giving you visibility into and confidence in the reality of your business. Simon, thank you for joining us. How are you doing today? SIMON: Hey, guys. Yeah, I'm very good today. VICTORIA: So, Simon, where are you joining us from today? SIMON: So, I'm joining from the UK. I live in a city called Brighton on the South Coast of the UK, where it's a lovely day today. It's nice and sunny. VICTORIA: Oh, that's where our thoughtbot summit has been the last two years, in Brighton, actually. SIMON: Fantastic. Yeah, it's a wonderful place. VICTORIA: And a great place to be in the summer right now, right? Do you get out in the water very often? SIMON: Yeah. Yeah, absolutely. Like many others, we have a paddle board. So, I go out with my family. I have four kids, so we go out and have fun at the beach. Brighton's got a stony beach. So we are, as Brightoners, we're very proud of the stones. You know, if you have sand, you get sand everywhere, stones are...it's much cleaner. [laughter] It does hurt your feet, though. There you go. [laughter] WILL: Yeah, that was the first time I've ever seen that, and I was like, that's very interesting. SIMON: Yeah. [laughs] WILL: I probably will like it because I don't like the sand getting everywhere, so... SIMON: Yeah, absolutely. WILL: So, yeah, I probably could trade that in. [laughs] SIMON: Yeah, yeah. You just have to wear shoes if you want to go run around. We're proud. We're proud of it. VICTORIA: I didn't think about that either. It makes a lot more sense. I don't really like the sand [laughter]. Rocks make more sense. But in California here, we're surfing, so having too many rocks on the beach would be a problem [laughs] for those of us who can't control ourselves. [laughter] SIMON: Yes. Yeah, Victoria, I thought you lived in Wales when I first looked at your profile -- VICTORIA: Oh, right. SIMON: On LinkedIn. And I thought, oh -- VICTORIA: That's...yeah. SIMON: A Welsh girl. That's -- VICTORIA: My family is actually Welsh on my mother's side. SIMON: Oh really? VICTORIA: Yeah. SIMON: Okay. VICTORIA: And Cardiff...California is named after Cardiff, Wales. SIMON: Okay, oh. VICTORIA: But yeah, so that's where it came from. So, I thought that was very cute, too. SIMON: [laughs] Very cool. VICTORIA: But, you know, Cardiff-by-the Sea is its own little beach town here. SIMON: It's not Wales. [laughs] VICTORIA: Not Wales. [laughs] Pretty different. But I do hear Wales is beautiful. SIMON: Oh, it is. Yeah, absolutely. VICTORIA: Awesome. Well, let's talk about Blox a little bit. So, why don't you tell us maybe a little bit about your background and how you came around to starting it? SIMON: Yeah, great. So, and just in terms of me and my background, so I started my career in finance, actually. I didn't really know what to go and study, so I thought, you know, studying numbers was probably a good thing. So, I did an accounting finance degree. And I got into the world of work in finance roles very quickly realized that finance wasn't for me. I just didn't really want to be a CFO. I just didn't feel the passion for it. But I was the techie guy always in the finance team. I was the guy people turned to and originally for, you know, Excel and spreadsheet modeling. And behind Excel, you've got VBA. So, you've got this little, you know, it was my first exposure to programming and some, you know, and what coding was. And so, I sort of just realized, actually, I love the technology side. And so, I followed my passion more into the finance systems arena. And my passion has always been...the focus of my career has been helping leaders understand what's going on in the business by getting hold of those numbers, the data that they have, and analyzing it, summarizing it, trying to draw insights from it so they can make decisions. And so, in the early days, it was lots of Excel spreadsheet modeling. And, in some businesses, there's still tons of spreadsheet modeling going on. And then the next phase of my career was actually working in...there are a number of software options that help you with planning, modeling, reporting, et cetera. So, I joined...well, I did some consulting for a while and then joined a company called Anaplan. And was an early employee, the company was still very early in their journey. They were just launching a European office, so I joined as one of the early European employees. And Anaplan went on, over the course of nearly eight years that I was there, to be [inaudible 04:31], absolute rocket ship, grew up to 2,000 people, and we floated on the New York Stock Exchange and then IPO in 2018. It was acquired last year for a very big number. So really fantastic time there. But to just talk about Blox, so I left Anaplan two years ago. The observations that I made that led to Blox ultimately were there were sort of three main aspects. Like, when COVID happened, the world changed radically. And what I saw...I was working in Anaplan. For anyone who doesn't know, Anaplan they focus on selling to large enterprise. So, you may not be familiar with the company if you're not a CFO or a finance person in a very large company. And they sell very expensive product. It's very, very powerful modeling, calculation, FP&A, finance planning, and analysis software. And so, companies...we were working with companies like Procter & Gamble, HP, Cisco, Google, and others. What I observed was when COVID kicked in, the FP&A system was too rigid. So, Anaplan, you know, these models that people had built up, spent a lot of time and energy building up, it was too rigid. The world changed so much that they couldn't really use their typical budgeting systems or these FP&A solutions. They couldn't use Anaplan. So, everybody just jumped back into a spreadsheet to figure out, you know, do I still have a business? How am I going to survive this if I just had to shut all my retail stores or if I had to send everybody home? You know, so everyone was using spreadsheets, basically. And so my observation there was that the tools that are available at that point are still way too hard to use. They're not flexible enough. You can't mold them quickly enough to really handle some of those scenarios that you want to throw at it as a leader. So, when you're trying to make big decisions about new revenue streams, new offices that you would want to launch, restructuring your team, investing in more people, those things they're really hard to model in the tools that are available. You need real specialist experience and expertise. That's very expensive, et cetera. So that was one part. And then the other thing that happened was I've worked most of my career in larger companies. And I'd worked in, yeah, in finance, in businesses. And also, I'm a chartered management accountant. It's all about helping with managing a business with your numbers. And I hadn't really worked with many very small companies. I ended up volunteering. When the lockdowns were happening, there were lots of people that were sheltering in place and they were staying at home. And so, a local charity had organized to put together food parcels, and then they found drivers to drive them around. And so I had volunteered through a friend of a friend, and somewhere my name got put in. So, I ended up driving these food deliveries around for the summer, and I loved it. Every Thursday, I'd take a couple of hours to just drive around and drop some food on people's doorsteps and then maybe have a quick conversation with them from a distance. I got connected with the charity. It is a local charity that runs on the South Coast in England here. And they found out I was an accountant, and I worked in software technology. They were like, [gasps], please, you can be our new best friend. We need some help. So, I ended up helping them a bit in their back office with some of the reporting that they do. And to cut a long story short, they're a charity. They live on grant funding that they get. So, they apply for grants, and then the grant providers want them to report back on the progress that they've made, the services that they've offered, the people they've helped. So, I went and helped them, and they needed these reports and some plans for grants that they were trying to get. What seemed really easy to me, like, they were showing me that they had to download this data from a system. And they needed to filter it and then count how many people they had been helping. And they basically were just, you know, with different needs and in different categories and cohorts. So, they would basically download the data, open it in a spreadsheet, put a filter on, select some filters, and then they would count the number of rows that had that criteria. And then, they would type the number into an email. And I just showed them some very simple things, like, when you do a filter or if you select the cells, you can see a countdown at the bottom-right in Excel, and I showed them that. And they almost fell off their chair because [laughs] they were like, "Oh, you know, why did we not see that sooner?" But I suppose through that, and, you know, through the various times that I helped them...and I just helped them with initially some spreadsheets and just some help with that. But it just showed me that there are a lot of businesses, a lot of charities in this case, but a lot of businesses where the leaders are not finance savvy, and they are not accountants. They're not MBAs, but they still need help running their business. They need to do reporting. They need to do planning, you know, manage their business, control the finances. So, I just thought, you know, just started thinking a lot more about what does a small business need? What does a leader in a business need to make great decisions, run the business? And how could we get them a tool or some software that doesn't cost hundreds of grand every year but is accessible, a nice, low price point, and really easy for them to use? And that's the problem that I thought about for a long time. And ultimately, that's what we're trying to work on with Blox. WILL: That's amazing. I used to work at a nonprofit. And I remember those days of, like, because I wasn't an MBA, like you said, MBA finance and just trying to figure out numbers. I don't even remember the software we used. SIMON: [laughs] WILL: But it was old and very hard to maneuver. [laughter] SIMON: Oh yeah. WILL: It was harder to maneuver than spreadsheets. And I was like, ahh, this is a nightmare. So, this is amazing that you're doing that. Can you tell us more about how Blox solves that issue? Because it sounds like it is a tween of big software that's for enterprise companies and spreadsheets. So, it's kind of in the middle; it sounds like. SIMON: So, spreadsheets are great. They're really easy. They're easy to start with. You'll often find that your spreadsheet will just kind of reach its natural end. It becomes too complex. And that normally happens when you've got, like, you're planning for lots of people, or lots of products, or lots of different projects. And so, you end up sort of having to figure out how to scale the model, you know, across lots of different columns or rows, or you start copying. And how you'll have three identical tabs or ten identical tabs. And, at that point, you've basically outgrown Excel, and trying to keep that spreadsheet running and working it becomes a real nightmare. And so, that's the point where Blox comes in. You could use Blox right from the very beginning. We've started with a focus on making really nice, simple models that you can just pick up and use. So, our earliest customers are startups doing a financial model for a brand-new idea. So, you can use Blox from the beginning, but you could probably use a spreadsheet, too. Where you would want to use Blox is where it becomes more complex, and you've got a lot more going on. You might have lots of different months, and you've got loads of time. You might want to connect it to your actual accounting system or a CRM system. And so, when you want to pull in actual data and do some reporting and maybe have different scenarios, different versions of a plan or of a report, that's where you've basically outgrown a spreadsheet, and it just becomes complex and unwieldy. And that's where you would want to move into a system. That's what we're building with Blox is basically a powerful modeling calculation planning engine that scales really easily. So, you can build up your dimensions, products, countries, time, et cetera, and you can build up those dimensions. You can build up your logic. You can add your own KPIs. You can add your own projection logic, et cetera. You can build out a model. We've got lots of template models that you can start with because you shouldn't have to start from scratch every time. You can get going. You can load up your own data very quickly at the beginning. For a lot of models, it's just assumptions. You're just trying to work out, okay, like, we've got some service businesses that use Blox. To get a basic model together, what you need to know is how many people do you have roughly? How much do you pay them? And then, how many people do you plan to hire at certain times? And how long does it take to ramp a new hire? Because, normally, there's some sort of ramp time. And if it's a service business and you're selling time, then you kind of have an average number of hours billable or often called utilization. So, with a few quick assumptions, you could throw them in. You could build out a multi-year plan for your business. And you could use that to think about, okay, how can I grow this business? I kind of talk about it as a financial roadmap that you could create. So, you know, often in the product world, we talk about product roadmaps. I like to talk about, you know, a business roadmap or financial roadmap. And that's really what we are working on; Blox and Blox will help you with this financial roadmap that you can build out. You know, I'd like to get my business to this point to, you know, 2 million in revenue, or 10 million in revenue, or maybe there are some financial or non-financial goals that you're trying to get to. And, with a model, you can help try and kind of work out what the assumptions and drivers and what those things need to look like. And then, as a manager of the business, you can start working on, okay, how do I increase my headcount? Or how do I decrease this particular cost per unit or various things like that? So yeah, that's a very high level on what we're doing with Blox. VICTORIA: Thank you for that. And I certainly can relate to that, having worked for several different consulting services companies and how difficult it can be to get software [laughs] to project that -- SIMON: [laughs] VICTORIA: Far into the future, like, to think about how you're going to hire, all the things that go into it. So, I'm curious about your own plan for Blox. Like, how would you describe where you are in your plan for the company? SIMON: We are a year old, actually just celebrated our one-year anniversary. In the last year, we've formed, hired an early team. We've fundraised successfully. So, we raised venture finance to fund the business. It's a complex product to build. We're trying to replace a spreadsheet, which has got tons and tons of features. They've been developing that for a long time. So, for someone to come across, it needs to be a relatively mature product. So, we raised venture funds from investors. We're busy investing that to build up the product and take that to market. It's been a fantastic year. And this is my first time as a founder. I've worked in leadership roles in technology businesses, in customer success, and in product as well. Yeah, I definitely would say working as a founder in a brand-new startup is very different to working in product, in a scale-up. You know, some of the lessons that I learned back there have been useful. You know, you learn how to juggle chaos, how to juggle...how to spin lots of plates. But yeah, I'm really delighted with our progress so far. We've fundraised. We ran a beta of our product last year with some early customers. We graduated from that. Our approach has always been to try and get the product out, so really embrace agile. It's kind of you don't see it so often in enterprise software. What you see is companies that like to just put "Book a demo" on the website. And they don't like to show their software until they've already kind of sold the value, and they've pitched, you know, positioned their pricing, and qualified their leads, et cetera. Our approach has always been let's build a fantastic product. Let's build something which is super compelling, super easy to use. Let's get people into the product as quickly as possible so they can experience it, see if it's going to be valuable for them. We launched a free tier of our product, the first sort of MVP, as a free tier, so not paid, not with some of the features that we plan to add to the product. And so, we've got that out there, and it's been fantastic. We've got users from all over the world using it in all sorts of different ways. And that's the other thing that is really great for us. Because it's such a flexible product, it can be used in lots of places. So, we've got all sorts of different applications being used by it. People jump in; they use it. They can try different templates that we've got. And then, if they need something different...every business is slightly different. So, if they need something slightly different, they can just chat to us in the product. We absolutely love chatting to people. And then, you know, we'll often spin up a custom template for them. And when we've done a few of those, then we'll build a standard template for a new industry. That's a little bit about where we're at. We're a small team based between here and India, where most of our developers are. It's good fun. Some of the learning...so I would say maybe it's just because of my background. So, I moved into product, and I was a product manager and then product leader for the last six years. So, for me, I've found building the product has been the easier part, probably because it's my background and that's where my passion is. So, I absolutely love anytime I get to spend in the product and spend with the team. The original founding team is myself as founder and CEO. And I don't get too much time on the product. I have a product manager and a designer. And so, that was the first...the early team, the founding team. And then we've added marketing and some other roles and software development. And so that's the team. I've found building the product has been really fun, and that's been a bit easier. Trying to work out how to do fundraising was a real challenge, so that took a lot of energy. We've been pretty successful so far in that. Still, always more to go, always more fundraising needed definitely. The really hard thing, especially in the market that we're in right now, it's hard, you know, getting early customer traction and selling. And that's really hard trying to get your name out there, build a brand, find early customers. That's really hard. So yeah, that's definitely an observation for me that the product has been really fun and a bit easier than I thought. But yeah, trying to do sales, marketing, figure that out...and probably as well because it's not my background or my kind of natural area of interest, so I've been learning. That's always tough, isn't it? Mid-Roll Ad: VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? RICHARD: Hi, Victoria. VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along. And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken. RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So... [laughter] RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... RICHARD: [chuckles] Absolutely. VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. RICHARD: Yeah, it was a pleasure. Thank you. WILL: You mentioned getting your product out there how challenging it can be. So, what has been some other wins and some challenges that you've had as a first-time founder? SIMON: So, my approach to things as a leader is I basically like to bring silliness and games to help motivate and energize the team. So, as a human, I have quite a lot of energy. I roll around with lots of energy. And I take loads of photos of what I'm doing, and I share those. So, we have a Friday wrap-up with the team, and so I'll often share a lot of the pictures of, you know, what I've been up to this week. So, yeah, there's been some really fantastic moments launching a product. We launched our MVP in three months. So, we basically set off...I actually funded the first season of the business, a couple of software developers, a couple of early employees. I funded the first season. We hadn't raised money. And I just spoke to my wife, and I said, "Look, now's the time. I really want to do this." You know, I've been saving up if you like, I had this, like, one day I'll do a startup fund. Some people would probably call that their long-term savings or like, you know, some...and I kind of called it my one day I'll do a startup fund. So, I'd been building up this fund because I knew that at some point, I'll probably go do this. The timing was way earlier than I thought. I thought I'd still do another four or five years in a career in a corporate role to try and get a few more notches in my belts to make fundraising easier, et cetera. The timing came. The team was perfect. And everything just felt right, so we went for it. But yeah, we basically set out. We didn't know where we were going to get funding from. The market was in a real state, so this was middle of 2022. The Ukraine war had kicked in; valuations had dropped by 90% for a lot of tech companies. The post-COVID bubble had burst. It was hard. So, we sat down, and we were like, okay, we could spend all of our runway trying to fundraise now, or we could crack on and try and build the first MVP. But we'd already done a lot of the market research, the user testing, early prototypes, et cetera. And that's a bit of a long story. But we had done that in the company that the founding team had worked at, and then we were actually a spin-out. So that happened. And we were sitting here thinking, okay, you know, we could spend all of our runway fundraising, or we could just crack on and build a product as quick as we can in the next three months. And so, we had this really hard conversation where we descoped so much stuff. And we just figured out what's the core piece that will really show the value of what we're trying to build, that we'd give to a user, that we could give to an early customer that they could use and get value from? And so, we came up with that scope. And we cracked on, and we built it. Within two and a half months, we had a working version. We played with it. Within three months, we kind of launched into this beta and got early users onto. So that was, you know, fantastic. So, we did that in the first three months, and then off the success of having an MVP, and just being able to show the product, and start getting some early user feedback, initial feedback was, you know, we took into account very quickly and improved. And just having that, you know, you basically start building momentum. Every step is still really hard, but you do build momentum. So, we got this product. We launched it. We went to a couple of events, and we talked about that, and then we did some fundraising. And we landed some funding, so that was fantastic. And then, you know, and then we've just gone sort of step by step from there. So, it's really fantastic what we've been able to achieve so far. The challenges there's been loads of them, especially when you're building a startup. It's really exciting. So, you can get people excited quite easily about the future potential. And you can kind of talk about what this can be. I've got a printed picture of a unicorn on my whiteboard in my office right here as a sort of a statement of, you know, where we're going. It's really hard as a founder or a leader trying to persuade people to leave a stable job, take a pay cut, and come and work with you and give them some equity, which you hope will be worth a ton, and you kind of paint the picture. But also, you don't know how long you can keep them because you're on runway. You're on runway. You haven't got infinite cash if it's not a profitable business. So, you know, there are some real challenges. And, as a founder, you go through ups and downs. Ben Horowitz talks about it in his great book, The Hard Things About Hard Things, as the struggle. I definitely understand that a lot more now because there is an up and down to this. You do build momentum, but you also...you're creating the momentum, you know, one hard push at a time. So that's that early customers come on. You kind of pitch the dream of what the product will do, and then it will fall over as soon as they touch it. But I absolutely love it. What I love is the chance to create and how quickly you can move in the early days of a startup or a new product, where you don't have masses of technical debt. You don't have hundreds of customers. You don't have all this, you know, you don't have a massive team where everyone's got their point of view on what you should do. So, you can move really fast, and that's fantastic [inaudible 30:14] creative season. So yeah, lots of ups and downs, but it's really fun. VICTORIA: That's so interesting and particularly interesting that you're trying to make something that's easier to use than Excel. So, I'm curious how you're testing to make sure that it's actually easy. And what might be...I'm sure there's some interesting feedback you got about that. SIMON: Yeah, so we're making Blox easier than Excel. But it's got to be powerful enough to be able to handle the data and the modeling that you need for a business. If you're doing projections for multiple years if you've got lots of products or teams, then it can be complex, so it needs to be powerful enough to handle that. It needs to be flexible enough because you can take a template, but every business has got its own unique quirks. So, it needs to be flexible enough that it can be tailored easy for a unique business. And then, crucially, and this is also important, it needs to be easy enough to use so that the person who understands the business can change the model to kind of suit their business. That's the bit that most of the other players, you know, the enterprise software that's available today, just that they haven't figured out how to make it easy enough so that a businessperson that, you know, doesn't have database experience, can't write SQL, not going to write Python, you know, doesn't do complex scripting or any of this stuff. It's got to be easy enough that they can, you know, tailor, reflect the way that their business works, the way that they make money, the way that their cost structure works, so they can figure out what drives the business. And so, if they're projecting revenue, they can work out the costs associated. So, one of our founding team is a UX designer, a really, really fantastic designer, very experienced. He's been in the game for 25 years since, way before it was called UX. And started doing graphic design, and then has done lots of branding and branding for some really fantastic, large companies, did lots of consulting. And then got into UX and how, you know, the art of wireframing and helping to make products easily usable. I call him my secret weapon. I've worked with some fantastic designers in the past, so, as a founder, I think I appreciate and understand the value of a really good design and a really good UX designer. So, Mike, our UX designer, has just been fantastic at that. He's very good at wireframing and very good at testing. And he's not a finance planning expert. That's why I call him my secret weapon because, you know, I understand planning really well, but sometimes I understand it too well. When I describe what a user is trying to do or, you know, what I expect a screen will look like, I'm just probably subconsciously replacing or recreating something that I've seen or used before, whereas he's coming at it brand new. He's not worked in planning or data modeling, or many of these things. He's worked in lots of different businesses. So, he comes at it with a mobile-first perspective. Normally, he's thinking about, okay, how could this be used by a busy leader on their phone and they're running around? And so, he's been really fantastic at helping to keep it simple and easy and to rethink and to create a product, which is just so different to what other tools in the space are doing. And that's some of the feedback we get. It looks so different. It works so different. But yeah, the hard thing is that spreadsheets are the most sticky tool, I think. They're just so useful for, you know, for everything where you need to get a list of things. You just start throwing it into a spreadsheet, and then you can, you know, organize it and improve structure over time. But yeah, it's a really sticky tool. And we train people how to use spreadsheets from early days from school. My 12-year-old daughter she already has been taught how to use a spreadsheet in school. So, what we're trying to do is create something which is easier. But there's also, you know, you want there to be some familiarity in there so that people will...to avoid some of the friction of the people who have it. No one really signs up to learn a new tool if they can avoid it. We're lazy. [laughs] VICTORIA: It makes sense that design would be a big priority for your product because that was your intention from the beginning, right? Is to make something that's easy to use, so you prioritize that as an investment. SIMON: That's right. That's absolutely right. Yeah. VICTORIA: What's on the horizon? What are you the most excited about for Blox in the coming months? SIMON: So, yeah, we've got some really exciting elements of our roadmap coming. So, yeah, really excited to see these things come to life. Like anyone working in building products, whether you're designing, doing product, sort of overseeing, or actually developing, it's so great to see these things come to life. You spend a long time thinking and chatting about them, imagining, ideating about how they could look. The thing that I'm just most excited about is—and that's probably why I love product—is, you know, you're building a product, and then you can...then you're talking to somebody about how they would use this. Or before that, you're talking about their day-to-day right now and what their problems are, and how you could help them save time, save money, et cetera. And so, you know, I absolutely love chatting to more and more different types of companies, leaders in different parts of the business. And, you know, especially in our space, it's mostly about, okay, how can I help? You know, how could we improve this planning process that we've got, whether it's, you know, planning for the cost of running a big project or trying to figure out how can I scale my business to reach my objectives? So, I just love chatting to lots of different leaders globally. So, I love going to events, chatting to people, fact-finding about how they run their business, how they think about finances, et cetera. In terms of the product roadmap, we're working on some exciting new scenario capabilities, so you can easily look at different scenarios around a decision. So, you might be trying to decide, you know, should I be aggressive with my investments and hiring, or should I be pessimistic? Or is there a middle ground? So, we're adding, like, scenario capabilities where you can build out different versions of that, and then easily compare and contrast, and then decide which one to do. We're working on some really...really enjoying working on some intelligent capabilities. So, again, in the search of making it really easy to use for a busy leader, for a busy businessperson, or a busy finance person, making it really easy to use. So, we've invested a lot in AI technology and been designing, developing POCs around how AI could help to onboard customers faster, how we could help to personalize models for businesses automagically. So, as soon as we understand the website of a user, what sort of industry they're in, we can automagically personalize the template for them, add their own KPIs, like, industry-specific KPIs, into the model, and throw in benchmark data and all these things. So, we've got some fantastic AI capabilities coming through the pipe and some data integrations. As we get out more and more, we're connecting to different data sources. So, yeah, exciting times ahead for the roadmap. And as we add more features, then we'll add different pricing tiers, you know, so we can try and offer a nice, affordable entry-level offering for Blox, but then we will, you know, as you get more and more different features, you'll pay at the appropriate level. So that's a little bit about what our future looks like. WILL: That's neat some of the things you have coming up. You mentioned AI and how you're kind of embracing that. Can you expound on that? Like, kind of I know you said some data models automagically is going to do it. But, like, where can you see the benefit for a customer to use that? Because I know AI can be scary and stuff like that. But, like, just kind of taking the fear out of it and talking about how beneficial it can be. SIMON: Yeah. So, there's lots of different places where AI can help. So, the typical model today for finance planning is you'd have a leader who's responsible for the business, and they're responsible for an advertising budget. You know, they just intuitively know, you know, where should I spend money, what's good return on my investment, what's, you know, what works. But when it comes to actually trying to model that, so how to put that into a financial model or some other model that you can understand the relationships between these things, put in the KPIs, have the formulas, calculating things in the right way at the right level, what you often find is that the leader is not the system's expert. So, you'll often have, especially in bigger businesses, you've got this expert data analyst or FP&A finance planning person that will do the modeling. So, we really believe that AI can be like a digital business coach to digitize that business advisory piece. So, the leader can be sitting down. They can be looking to try and improve some part of their business or understand some part of their spend and trying to work out, like, what would life look like if I increased my spend on this particular channel by X? And so, you know, we are looking at AI to help with lots of different areas around this. Initially, it's helping a new user to get onboarded with Blox. So, it's taking a template and helping to personalize it for their business. What we basically try and do is fetch as much data about a new user and a new company as possible. So, if their team is on their website, then we'll pull in their team. If their products are listed on their website, we'll pull in a list of their products and try and throw that into the model and take out a lot of the friction that you have. As a user in the new system, you have to type in everything normally. If you're trying to model a business, you used to type it all in or copy and paste it from a spreadsheet. So, we're looking at lots of options to help onboard new users. That has a good value add for us because we can increase the speed of adoption and help get users to value faster, which is great for us. And also, users are, you know, they're busy. They're impatient, and they want to understand what value they're going to get before they spend lots more of their time. So that's going to be useful for us and them. And yeah, helping to interpret the data. So, they'll connect us to their source systems. We'll be able to interpret what's going on, help them to understand different options and scenarios about how things might play out in the future. Basically, AI will help us to draw our insights that we can present to the user, will help explain what the user is looking at when they're looking at the model, so we can summarize some of the key insights so that they can use that. We're expecting to have all sorts of users, but we're really focusing on really busy leaders who may have a good understanding of spreadsheets and data, but they're just too busy, and so they don't have time. So, they want something which is quick and easy. Or leaders who don't have that expertise, so those are the ones that we really cater for. We try and keep it really simple and help guide them through the process, et cetera. So that's where AI is going to be, like, that digital business AI...We kind of kind of talk about this AI business coach concept. And, over time, we'll build up more and more elements to that coach capability. We call him Anton in our team when we talk. We'll add more and more capabilities to him. But we've built a number of different POCs. And we've launched a couple of those with some customers. We've been out to events and showing off these new capabilities to basically test them out, understand what's working, what's not. What more do we need to think about to productionize this proof of concept? So that's, yeah, it's a very exciting time to be working on those things. VICTORIA: I love hearing about that. That's super interesting to see where it's going to go. So, my last question for you today is, is there anything else that you would like to promote? SIMON: I think I would just say, yeah, if you're a leader running a business or maybe it's a service business, and you're trying to think about, you know, when hiring business planning, financial planning, anything like that, then I'd love for you to come over to Blox, and you can jump straight into the product from our website. You can sign up. I absolutely love chatting to people about their businesses and what they're trying to do with their finances. So, if you want to do that, you can sign up. You can chat to us. I actually take a lot of time to respond to people in there, so yeah, if you want to do that. Or, if you can, also find me on LinkedIn. You can search me there. Just strike up a conversation and say, "Hey, Simon, I'd love to chat about financial roadmapping or finance planning." Yeah, I absolutely just love to speak to different leaders that work right across the business in different roles and see how we can help them to build a business that really unlock the potential that they have in their business through a great understanding of finances. So, yeah, if I can be of help, I would love that. VICTORIA: Wonderful. And we'll have all those links in the show notes so our audience can go and take a look. WILL: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @will23larry. VICTORIA: And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Simon Ritchie.Support Giant Robots Smashing Into Other Giant Robots

Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. __ Maggie Bachenberg, CEO, and Trisha Ballakur, CTO, are the co-founders of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities. Victoria talks to Maggie and Trisha about their cycling backgrounds, how they met and became co-founders, and what they feel is the differentiator for their app versus what was/is already on the market for biking-related apps. Pointz Follow Pointz on Instagram, Facebook, LinkedIn, or TikTok Follow Maggie Bachenberg on LinkedIn. Follow Trisha Ballakur on LinkedIn. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. With me today is Maggie Bachenberg, CEO and Co-Founder of Pointz, and Trisha Ballakur, CTO and Co-Founder of Pointz, a mobile mapping app that helps navigate bike and scooter riders through safe routes in cities. Just to get us started here, are you both cyclists? And if so, where do you do that at? What's your city? Where do you bike around? MAGGIE: Yeah, we both bike. So I live in Providence, Rhode Island, along with Trisha, and use my bike primarily as a transportation device. So I'm riding around from my house to work, to get groceries, to my friend's house, kind of all different types of purposes. TRISHA: Yeah, and I grew up biking but kind of stopped after age, like, six or seven. And it was only when I got to college at Brown, where I met Maggie, that I got back into it and felt more confident to get back on the bike. And that was completely actually because of Pointz. VICTORIA: Oh, that's nice. Yeah, speaking of confidence, I am not confident on a bicycle. I actually only learned after college. [laughs] And there's a video out there of my college friends helping me learn how to ride a bike. It's very cute. But still not my expertise. So I'm excited to learn more about it and learn about how Pointz could give you that confidence. So, whoever who'd like to start, why don't you tell me about what caused you to want to create Pointz? MAGGIE: Pointz was originally kind of my idea. And I got into biking in 2017 when I did a long-distance bike trip. I biked from Virginia to California. And it was my first time doing long-distance cycling, and I just kind of fell in love with it. But I realized that when I was riding, it was pretty scary to navigate cities in particular. And so, a lot of locals would redirect me onto different routes that were safer. And I was confused why this wasn't captured in a mapping app already. And so, that's kind of where the idea was seeded. But I didn't start working on it until I got to college and met Trisha. VICTORIA: Great. So you got to college, and you saw that there was a need to have easier access to biking and biking information in an area, right? MAGGIE: Yeah, exactly. VICTORIA: Very cool. What was that initial process like? It was just the two of you, and you started building stuff? How did you really get the traction going early on? MAGGIE: It started with doing some customer discovery interviews with local cyclists. And so we interviewed over 100 initially and just asked kind of what their biggest barrier was to start riding. And we kept hearing this recurring theme of people not feeling safe enough to go on different routes. And so we brainstormed a bunch of different ideas in a class that Trisha and I were in together. But we ended up landing on the one that we're working on today, which is, like, you know, the rating system, and then also putting the rating system of bike friendliness into a routing algorithm where people could actually find routes. VICTORIA: That's very cool. And was there anything that really surprised you in that customer discovery process? MAGGIE: Just maybe the consistency around people's fear and, like, I guess, being nervous on a bike because we were interviewing people of all types of backgrounds and experiences. And even people that were more experienced had this fear of getting hit by a car because of lack of infrastructure and that sort of thing. TRISHA: Doing customer discovery and chatting with so many different types of riders...and we call them riders, bike riders, rather than cyclists for the distinction that, you know, in the bike riding community, there's a lot of very avid fitness-geared cyclists, maybe who want to go on their bikes to burn calories and challenge themselves. A lot of people they would call themselves someone who rides a bike. And it's to those types of people where safety is really critical, especially in allowing new people to go and try to ride a bike for the first time or the first time in many years. And so, that's something else that we noticed from those customer discovery interviews is identifying the different types of riders. VICTORIA: Thank you. That clears it up for me because I never know to call someone a cyclist or a rider, but it makes sense that cyclist is more, like, the athletic pursuit versus riding and, you know, just trying to get about your day. [laughs] And it also makes me feel better that even people who are really experienced riders have fear of being unsafe or getting hit by a car because that's certainly what I'm thinking about when I'm [laughs] venturing out there. So, what was your initial build like for the app solving this problem? TRISHA: Initially, we had a couple of different Brown University interns or students working on it together one summer and myself included. And that evolved to me and this one other student who was working with us figuring out how to transition the app from, like, an iOS Swift native app to React Native so it could be cross-platform. And we had to teach ourselves React Native for that. So our intern at the time he had done an internship during the summer at this one startup where they taught him React Native. So he had done a couple of projects there. And I had a little bit of experience writing in JavaScript but really not as much as him. And so, together, we worked on coding the app from what we had in iOS in Swift, which was pretty limiting. But, at the time, it wasn't very much. But we were able to replicate that in React Native during; I think it was my junior...Maggie in my junior winter break. That became the start of our MVP, which had many, many more iterations to get all the features in and was a little bit slow to build until when we released it out, which was our senior year in about March or so. VICTORIA: So that's really exciting. So, like, how long did it take you to really get to that initial MVP with the team that you have? TRISHA: It took quite a bit longer than expected, as with all sorts of technology when you're building it for the first time. So what was important to us throughout the process was making sure that all the features we put out there were really well tested, and were useful, and were actually solving the problem of providing safer routing. And to get to that stage, at first, we, you know, we had an app in Swift. Then we wanted to make it cross-platformed, and we needed to have the routing algorithm actually take those different weights, the different bike friendliness ratings of the roads into account. And that took a lot of researching and talking to mentors. So there were quite a few really hard challenges to get to the MVP, which is why it spanned about a year to get to that point. But throughout it all, we worked with other students at Brown. Then we pulled in some front-end contractors from online, like contractor sites, who were awesome. And we were just focused on being really scrappy to get it out in March of 2022. VICTORIA: That's great. And maybe it felt like a long time, but I feel like a year for a really solid MVP is pretty good, [laughs] especially when you have those safety concerns, and the quality of your data, and what you're giving out is super important. So now you've got the MVP, and I believe you just raised your round of seed funding last year. What was that process like for you? MAGGIE: Yes, so the round of funding that we did, we raised the first initial amount actually going into our senior year, and that was from a firm called Rogue Venture Partners. And we also got a little bit of it from their Women's Fund. And, yeah, that was the kind of piece of funding that got us started and allowed us to really, you know, add additional resources to the product to get it out there, at least the MVP. And then, after that, we got a little bit more funding from them. And then we raised money from Techstars as well because we got into their accelerator at The Roux Institute. That's kind of in association with Northeastern, and that was out of Portland, Maine. I guess it wasn't really necessarily, like, a cohesive round. It was, like, a couple of different checks that all kind of went into, like, our early funding for Pointz. And I would say it was very much so based on, you know, our relationship that we had with our initial venture firm that were working with Rogue. They actually mentored us for quite a few months before they invested in us. So they started mentoring us our junior year when we were in school. And then we got the deal together September of 2021. VICTORIA: That's awesome. Well, congratulations. And I'm glad you were able to find the right partnerships, and mentors, and funding that you needed. What did you find was really the differentiator for your app versus what was already on the market for biking-related apps? MAGGIE: There are a couple of different types of competitors, so there are the biking-related apps that you just mentioned, and then there are the general kind of use case apps like Google Maps or Apple Maps. And so, for the bike-related apps, the main thing that's different about Pointz is that we're more focused on, like, bike riders in general, so people that are riding around for transportation and recreation, not so much the cyclist type of a person that Trisha described earlier. So, you know, a lot of our features are geared towards people that are getting around the city or maybe are exploring a city or a neighborhood. It doesn't necessarily have to be a city, but that's kind of the focus. Whereas for other cycling-specific apps, like Komoot or Ride with GPS, it's focused a lot on, like, the fitness side of things and the recreation fitness side of riders. And so, at least the Ride with GPS and a few other of, like, the technologies that are available to more hardcore cyclists tend to have a more sharp learning curve. And ours was built more as, like, a general use case in navigating and exploring. VICTORIA: That makes sense. So it's more for people like me who are trying to go the most scenic [laughs] or the flattest and the safest way, not necessarily the fastest or the more fitness-focused aspect of cycling and biking. MAGGIE: Yeah, exactly. And, you know, we actually built this for people like us. Granted, I did do that long-distance bike trip. But, generally, I don't consider myself that hardcore of a rider, I mean, in my daily life. So it's for people who don't really identify as a cyclist and are more just, like, riding their bike around and, honestly, for people who are new to riding in general. Because a lot of our riders have recently gotten into biking or have recently moved to a new area, and so, they're just trying to figure out, you know, where are the good places to ride? Where do I feel safe? And, you know, how can I get more comfortable on my bike? VICTORIA: I'm loving this idea because I have a bike that's been sitting in my patio for over a year. [laughs] I haven't used...my partner is like, "Can we get rid of it? Because you don't use it." But I'm like, "I will. I will use it." I know my neighborhood problem is that there are giant hills if we leave our street here. So getting out is fine. But getting back in [laughs], it's like you need an electric bike. So that's very exciting. So, tell me more about now that you've graduated and you're taking this up full time; what does the future look like? What's on your horizon? MAGGIE: I mean, we've been working a lot with one of our advisors on, you know, getting to the point where people really love the product, and that's been kind of happening over the last year. We met Anuj Adhiya from Lenny's Newsletter. We've been working with him to really hone in on what the thing is that people really love about Pointz and make that experience better. And then also figure out what exactly the persona is so we can target them eventually with marketing, which is kind of the stage that we're at right now. So we were seeing our retention curves really evening out in especially a couple of cities that we're targeting. And so, this summer, we're focusing on getting our user base up in Los Angeles and then trying to figure out how, like, a playbook for scaling up a user base in a specific geography. Right now, a lot of our users are distributed throughout the United States. And there are clusters, but there's not, like, a huge spike in one city. And so, that's what we're working on right now is figuring out how to get a geographic kind of density to happen. VICTORIA: That makes sense. And it sounded like the app also uses a lot of user-generated data for safety ratings and things like that. Am I getting that accurately? TRISHA: Yep, that's correct. And what we do is we have a bunch of different layers of our data that we pull from. We have a base layer of data that comes from OpenStreetMap, and then we build on top of that. We rate all roads on a one through five bike friendliness scale. And building on top of that, we pull from city-specific data sets from cities, and towns, and municipalities. And then, we layer on the crowdsourcing similar to how Waze does at the top. VICTORIA: Got it. So taking advantage of that open data, the open city data, and what other data the city is putting out there. Are you finding that you're using whether or not a city has open data to inform if you're going to expand into that location? MAGGIE: Kind of as a focus point. So, the way it works right now is Pointz is available actually anywhere in the U.S. So; it doesn't matter if you're in a city or a rural area, you can use Pointz. And you can use it for routing and navigation and all the features that are available. However, we only have visualized the ratings in all 350 or so urban areas in the U.S., and so those are all visualized, but not all of them have the supplemental city-data. And so, the way we decide when we pull in city data is based on gaps in, like, the base layer. So, if we're seeing that there are a lot of accuracy issues in a specific city, we'll go, and we'll look and see if there's a more accurate map that the city has put out or that an advocacy group has put out. And so, we've done this recently in Chicago, Minneapolis, Portland, Oregon, just to supplement the base layer of data, and it has helped a lot in terms of accuracy. And users or our riders really like it. VICTORIA: That's great. And what is your current level of usage in the app? How well have you been adopted? MAGGIE: Are you talking in terms of, like, user numbers or just, like, our engagement levels? VICTORIA: Yeah, whatever you're using to measure your level of engagement or number of users on the app. Like, what are your stats looking like? MAGGIE: Yeah, so, we use...we have our overall signups. And then we have a subcategory of, like, active and engaged users. And so, for our overall signups, we're at just over 9,000 total signups since we launched the MVP, and we haven't marketed it at all kind of until right now, where we're trying to push it out in LA a bit more. And then, in terms of our engaged cohort, I'd have to pull up the exact number. But last I checked, it was around 1,800 monthly active users. We kind of look at that cohort, and then we break it down into, you know, who's even more engaged in that? Who's coming back every week, every day? Mid-Roll Ad: VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5K per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. VICTORIA: And with me here, I have Richard Newman, who is the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? RICHARD: Hi, Victoria. VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. And so, a number of things that we pay attention to in maintenance are, we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application that, we're responding to those sorts of changes as we go along. And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so, a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so, those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so, that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where, suddenly, you need to make a very large investment and fixing whatever is broken. RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So, we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. So... [laughter] RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... RICHARD: [chuckles] Absolutely. VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. RICHARD: Yeah, it was a pleasure. Thank you. VICTORIA: I'm wondering if you have any incentives built into the app for users who are, like, contributing data back, or maybe they're writing every single day. Are there any little challenges or achievements that you could unlock within the app right now? MAGGIE: We do have some gamification, yes. And so, the way that people can earn points on the app...we call them points with a Z because of the name. The way that they can earn those points are a couple of ways. So, one is through riding their bike and using Pointz as a navigation tool or as a tool to record their ride. And so, for that, you get one point for every mile. And then the second way is by contributing to the map, so either crowdsourcing an amenity like a bike parking that isn't on the map already or by adding information about a hazard that might be on the map, like, for example, a car parked in the bike lane. And for each of those, you know, you get one point. And so, yeah, we have that gamification system built out and a couple of...like, we have a leaderboard. And then, also, we have, like, a way for you to kind of go up in your avatar on the app. But besides that, we do monthly contests. And so, this past month, we partnered up with a company called Po Campo, which makes stylish bike bags that can be taken off your bike and then worn as, like, a purse or a handbag. And so, they sponsored the prize, which is one of their bags, and whoever kind of gave the highest quality and quantity of crowdsourcing reviews and miles ridden they're the winner of the contest for this month of June. VICTORIA: That's very cool. I love to see that and hear about what strategies people have for engaging with their users within the app. I'm curious to go back to, you know when you two first met, how did you know that you were going to be good partners to work on this project together? TRISHA: One of the ways that we knew that was because we had first been introduced to each other from our mutual friend who is a close friend of both of ours, and she had been telling the other person about each other. And it was one day where we just met up, and we really clicked. But, at that point, Maggie was looking for someone who could work on the mobile development, and I didn't have any experience with that. However, I joined a club, which Maggie was leading, which was called The Women's Entrepreneurship Group. And we got a chance to work together and plan out many events, including a large conference right before COVID hit. Like, we saw how we'd worked together. We really enjoyed it. And we had very similar aspirations and motivations towards entrepreneurship. When I had the chance to basically join what Maggie was already working on with Pointz in the summer of 2020, I knew that that was going to be a great opportunity. And we decided to become co-founders by the end of the summer. VICTORIA: That's very cool. And I know how important it is to have the right team together to work on a project like this and to start something up from scratch. So, were there other big turning points? And you mentioned COVID, so I'm curious how that affected the growth and progress of this effort. MAGGIE: Yeah, to be honest, in the heart of COVID, like 2020, we weren't really built yet. So, it didn't quite affect us a whole lot, just because the product didn't get launched until the spring of 2020 to actually, you know, kind of publicly. But there were a couple of other turning points in our company, one of them was Techstars and kind of the progress we made during Techstars. We joined the accelerator, and we were having a bit of a hard time getting tech kind of pushed out really quickly. It was taking us a long time to build the features. And so, Trisha and I kind of evaluated why that was happening. And we came up with a process that worked a lot better, which we still use today. And speaking of team, we got a couple of really awesome teammates that made a huge difference on how quickly we could turn around features and bug fixes. And so, that was a really big turning point because we were able to iterate much more quickly and get feedback from our riders a lot faster. So that happened November, December of last year, of 2022. The other big turning point, I would say, is the slider that we released in March of this past year of 2023. And so we were having a hard time retaining users and getting them to really like the routing because people who bike tend to be very opinionated. And if the route isn't exactly kind of how they wanted it, they would be upset. And so, we'd fix it for one group of users, and then we would upset another group that didn't want that, you know, added to the routing. What we ended up doing was releasing this safety slider, which has the fastest routes on the left side of the slider and then the safest or the longest routes on the right side of the slider. And that really helped people get a wide variety of routes that fit their use case. And it's helped a ton with retention. And also, the feedback we were getting from users really changed from, like, really honing in on a very specific issue with routes that they were getting to general feedback about how we could enhance the app and keep people coming back more consistently. TRISHA: I just want to emphasize again that, yeah, the team is really critical. And, like, on our team, we have really awesome people who are 10xers and just great. Also, have someone who worked at MapQuest and has...I think our combined mapping experience is around 20-plus years. So it's really awesome to have that sort of a team together. VICTORIA: Yes. And, you know, talking about it now on the podcast, in retrospect, I'm sure it all seems like it came together, and it was kismet, and everything just worked. But was that how it really felt? Or were there moments where you doubted it and thought, maybe this isn't going to come together? MAGGIE: Yeah, definitely. There were moments of that feeling. One thing that gave us a lot of confidence was getting to the point where we felt like we could really iterate quickly and release features at a consistent and predictable cadence. So that gave us confidence that you know, there is a process for this, and there's a process of gathering user feedback and rider feedback, and then translating that into features, or bug fixes, or UI fixes. I think that gave me a lot of confidence that we could solve it. But, of course, it always takes a lot longer than you expect. And our advisor, Anuj, always says that 80% of what you're going to do won't work and 20% of it will. And it's all about how quickly you can iterate and figure out what works. And sometimes you get lucky, and it happens quicker. Or maybe you have unique insight into the problem, and you can guess, and it works out quicker. But I don't know; I definitely think it's been a learning process for everyone on our team. VICTORIA: That's great advice. And now that you've got your velocity up and you have your confidence, what's on the horizon? Are there new features that you all are working on that you're excited about? TRISHA: Yeah, so we're really excited about leaning into the whole generative AI trends that are happening, especially with ChatGPT and others. One thing that we've been hearing from most of our riders, people who use Pointz, is that using the app to create routes, which will allow them to explore new places, go to a new coffee shop that they've been hoping to go to but just don't know how to actually get there is critical. And most of our riders on Pointz are people who are new to a city. Maybe they've only lived there for a max of one year or less. So, exploring the area around them is really important to them, and that's why they use Pointz. And so, leaning into that, we're going to be releasing, in the next couple of weeks, a new explore feature where someone can go and, you know, describe to Pointz what type of route or...not even route, what type of things they want to see in a city, and Pointz will come up with that. It'll learn their preferences and continue to suggest really awesome places to get to, which they can do car-free, basically, through bikes, because they can be safe and, you know, they can rely on this app to get them through the city safely. VICTORIA: That's really exciting. And I'm excited to try it out myself [laughs] once you have that feature launched. Maybe you can tell me how that feature plays into...or what your success really looks like for Pointz in the next six months. MAGGIE: Yeah, so I think that feature is something that will be, I mean, of course, we got to test it, but I think that it will help people kind of use Pointz as an exploration tool more effectively. People are already using it for that, but it's not specifically built for exploration. Right now, it's built more for, I guess, routing to, you know, new places but not specifically, like, oh, let's go on a route that takes me through all these tourist destinations in the city I'm visiting. But this new feature will allow people to use it for that more. And I think, overall, you know, our mission at Pointz is to help people feel comfortable riding bikes so that they can drive less and feel like they can get around in a sustainable fashion, rather than having to rely on their car so often. And this feature is tied to that in the sense of, like, people can use it as a tool to help them, you know, find the safe route or a route they're comfortable with, and then use it to explore an area but maybe a bit more geared towards, like, tourists or, you know, more recreational-type use cases. VICTORIA: That's very cool. Thank you so much for sharing that. And what is your biggest challenge to achieving that success? MAGGIE: I think biking is a first step in that process of helping people feel like they can be more car-light or car-free, you know, use their car less. There are obviously a ton of other factors that go into whether or not you're driving, or you're taking a bike, or you're taking public transportation. And, you know, our next steps after we have really nailed this product are to explore those opportunities and build tools that help people choose alternative transportation more often. That's what we're excited about going into the future. You know, there's a ton happening in cities all across the U.S., not only for biking but also investments in transit, infrastructure, and whatnot. So, you know, young people and people of all ages...I think a lot of people feel comfortable and that they don't want to be sitting in traffic a whole lot [laughs] because that's not fun for anyone. And, you know, traffic and congestion is always frustrating. So, as much as we can reduce that, I think that's the mission of our company. And, of course, it takes a ton of scale. But it's a big goal, but we're going after it. VICTORIA: That's great. You know, I heard about a town in the U.S. that actually had banned cars and was pedestrians only for the whole town. It's like, what a great idea. [laughs] But I love it. I love that you're working on it. And I wonder now, you know, you're a couple of years into it. If you could go back in time and give advice to yourself when you first started this project, what advice would you give yourself? MAGGIE: For me, I would say to get a minimal viable product more minimal, [chuckles] so reduce it to, like, a single feature, get it out quickly, and start getting feedback more quickly from, like, a very practical, you know, piece of advice. And then, like, an overall piece of advice would be just to be more confident earlier on. It took a long time for me to gain the confidence of, like, being a thought leader in the space. And, you know, I felt like I was young, so there were all these people that knew more than me. But I think everyone has a really unique perspective, and if you really lean into that and share that with the world, it can inspire a lot of people. And you just have to be confident enough to do that. TRISHA: Yeah, I definitely second what Maggie just said. I think also from the tech perspective, if you're someone who is maybe more inexperienced, like, I just got out of college and did this, and I have never worked a full-time job before anywhere except this. And so I think there was a lot of doubt that I had of being able to lead the technical side because I didn't have 20 years experience working somewhere. But, actually, at the end of the day, that doesn't matter. It just matters that you're able to be in touch with what it takes to build certain features and talk to the users, or your riders, or whoever because they're the ones who are going to be dictating whether this is a success or not based on what you build. It's really not good if you're building and wasting a lot of resources and time on features which nobody wants or nobody uses. And so, that's been core to why I think I've gotten a lot of confidence in being able to be, like, the tech leader in this app and in this space. VICTORIA: Yeah, I'm curious to hear more about that. You touched on this really being your first full-time job. So, how do you build your personal brand as an executive leader in this company that you're building? TRISHA: For anyone who does startups, they'll know that it's a lot of figuring it out as you go, and things that you're taught in school don't necessarily translate well to the startup world because, like, I did, like, a Bachelor of Science in Computer Science. I did operating systems. I built a whole bunch of random stuff in school, and I studied for hours and hours. Of a lot of that, the most important thing, which actually translates to working in my field, is the perseverance to, like, keep going and working really hard. Otherwise, none of that stuff which I learned honestly translates. I had to learn everything myself with regards to building mobile apps. And I think the foundations were really critical from school but not really much of the hours of studying. I don't think that that's necessary, but I think it's necessary to build that sort of perseverance mindset. VICTORIA: That makes sense sort of to reflect that back a little bit, just having the perseverance to keep pushing, and keep learning, and keep understanding what is it going to take to build the features that you want? And that's really the core of being a CTO, right? TRISHA: Exactly. Exactly. Yeah. VICTORIA: And, Maggie, I wonder about you as well, like, what resources are you drawing on to really perform as a CEO for this company? TRISHA: One thing that I read a lot is...it's more product-focused, actually, but it's product and growth-focused. It's Lenny's Newsletter, which I mentioned earlier. I use that as a resource a lot. I listen to their podcasts, and I read their articles. And then secondly, I interact a lot with other CEOs and founders because I think that's one of the best ways you can learn is from other people who are in it right now, maybe are a couple of steps ahead of you, or who have done it before. And so, I lean into that quite a bit. And just, you know, try to get advice from people, take what makes sense, and apply it to what we're working on. VICTORIA: That sounds great, yeah. I can relate to that; just building your personal network with people who are in similar roles helps you stay in touch and understand what other challenges people are facing and what you might face someday, right? [laughs] That's really cool. I love that you have all that set up. And is there anything else that you all would like to promote today? MAGGIE: I would just say to anybody who's interested in biking or maybe is, like, a beginner rider, we'd love to have you try out the app and then explore your area and give it a try one weekend when you have some time and see if you feel more confident, you know, given the routes that are on more green and protected roads. VICTORIA: I'm really excited to be talking to you because I am that person. I need this app. [laughs] I'm excited to try it out. Thank you, Maggie and Trisha, for joining us today. [laughs] It was a really great conversation, and I'm excited to follow along and see what happens with Pointz in the coming years. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guests: Maggie Bachenberg and Trisha Ballakur.Support Giant Robots Smashing Into Other Giant Robots

Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. -- Brittany Martin is an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers and is the Co-host of The Ruby on Rails Podcast. Victoria and Will talk to Brittany about the multitude of stuff she's interested in, including Roller Derby, and gives the story of how she found herself co-hosting the show. She says knowing what your brand is and what listeners should expect from listening to you is super important, and she gives her opinion on what it means to be in the Ruby on Rails Community. Shogun The Ruby on Rails Podcast Follow Brittany Martin on LinkedIn or Twitter, or visit her website. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with us today is Brittany Martin, an Engineering Manager at Shogun, where she manages a team of Ruby and React engineers. She is the Co-host of The Ruby on Rails Podcast, almost five years running. And she plays roller derby for Steel City Roller Derby under the pseudonym, catch this, Merge Conflict. She is based in Pittsburgh, Pennsylvania. Brittany, thank you for joining us. BRITTANY: I am so thrilled to be on here. I have been listening to Giant Robots for years. So it's an absolute honor to be on the show today. VICTORIA: Yes, thank you so much for joining us. And I met you at RailsConf this year. And, at the time, you had a boot on your foot. So, I have to ask you, are you healed? Are you recovered? Are you walking around again? BRITTANY: This is such a good question. When I was between jobs in March, I was, you know, having these two weeks, I had a whole list of things that I was going to be doing. You know, I was going to train, like, running and whatnot. And I had roller derby practice that first week, and I broke my ankle. And, you know, going into it, I had no idea what a blocker it was going to be. I was like, oh, this is minor. It'll just take a couple of weeks to heal. No, it's been a long process. But I can gleefully tell the listeners that I am out of the boot. I am walking. I am hopefully getting into a sports program next week that will train me up to get back into CrossFit, running, and skating. Though the really funny part is that I currently have another injury which is golfer's elbow. [laughs] WILL: Oh, wow. BRITTANY: Yeah. So I have that from overusing my arms. So I'm a little bit of a mess, but, you know, getting myself back together physically so I can get back on my skates. WILL: So I know it's called golfer's elbow. But did you actually hurt it doing golf, or was it another sport you were playing? BRITTANY: It's so funny that you ask that, Will, because whenever people ask me how I broke my ankle, I can be glamorous and be like, "Oh, it was roller derby." WILL: [laughs] BRITTANY: Like, it's a sexy injury, you know. I have a friend who just broke their ankle because they were dancing down the stairs and broke it, not as glamorous of a story, right? WILL: [laughs] BRITTANY: Golfer's elbow. I literally have no idea how this happened. I've never golfed a day in my life. So [laughter] it's my non-glamorous injury at this point. WILL: Yeah, that's my background, sports medicine. BRITTANY: Oh, great. WILL: So it's interesting. Yeah, golfer's elbow, and I'm like, it's usually not golf that does it. So...[laughs] BRITTANY: Yeah. So I said something to my PT. I was like, "Am I the first person to ever get golfer's elbow from, like, you know, fixing another injury?" And she's like, "Yes. Yes, you are." [laughs] And I was like, oh. [laughter] I really was expecting to get some reassurance that it wasn't me. But hey, what are you going to do? WILL: There you go. BRITTANY: I love the fact that you do love my roller derby name. As you can imagine, it is a beacon for finding the other programmers out on the track because they find it very funny. Nobody else finds it funny whatsoever. And people call me Merge for short, and some people think it's Marge. And I just allow it at this point. [laughter] My number is 200, and its status code okay. When you hit me, I get up okay until, apparently, I break my ankle. So...[laughter] WILL: I love it. Because if you're a programmer, you're like, oh, she means business. BRITTANY: Exactly. WILL: Because merge conflicts...yeah, never fun. BRITTANY: Exactly. VICTORIA: I love that. I love finding other people who work in tech in other random activities. Like, I've recruited people from the climbing gym. [laughs] I'm like, oh, we're climbing together, and, oh, you're an engineer. That's interesting. [laughs] So it's great to, like, be with your community in different settings, so... And you're just so involved in the Ruby on Rails Community. And I'm curious what really got you started into podcasting. BRITTANY: Yeah, that's a really good question. So I'm a former product manager former MBA. So I didn't know how to code. I moved out to San Francisco because I thought that's what everyone did. If you wanted to be in tech, you moved out to San Francisco, and so I did that. And I realized very quickly that it was going to be hard for me to be a product manager without knowing how to code. And so I went to a bootcamp at night, and I became a Ruby on Rails developer. So I wish I had, like, just a really cool story for why I chose Rails. It's literally the framework that was being taught by the bootcamp. WILL: [laughs] BRITTANY: But I'm so glad that it was because I love this community so much. But, you know, when I moved out to San Francisco, I just had my current partner at the time and my dog. I didn't have any friends. And so it was really the perfect time to learn how to code just because I was really able to focus. And I ended up having a lot of long walks at night, like, getting to the train, getting to the bus, and that's really when I got into listening to podcasts. I'm not a huge music person, which is kind of weird. I really...I deeply love podcasts. And so I just kind of glommed on to a bunch of podcasts like Giant Robots, CodeNewbie, Bike Shed. I figured if I listened to all the things that I wanted to be, like, osmosis would just happen, and I would just start learning the things because I was actively learning about how to code. And I thought just listening to those concepts would really help. And really what ended up happening is those people that I was listening to, like, to me, they became celebrities to me. Like, I don't care about regular celebrities. [laughter] I care about people within these communities that I care so much about. And so, you know, a couple of years into that, I was still very much devoted to listening to podcasts. I trained for my first marathon listening to podcasts. And I was listening to The Ruby on Rails Podcast, and, at the time, Kyle Daigle had taken over the show. And he had decided, in order to spice things up on the show, he was going to bring co-hosts on that he was going to rotate through. So, every couple of weeks, you would come on as a co-host, and you would drive the conversation with things that were going on in your life. And, at the time, you know, there wasn't a lot of women, female representation in podcasts. I felt that I was doing interesting things. I was working at a non-profit doing ticketing for the Broadway Symphony and opera, like, in Rails. So I felt like I was always working in Rails, and I thought I could provide some useful insight. So I reached out to Kyle. I must have been very ambitious that day because I reached out and I said, "Hey, how about bringing me on as a co-host?" And he said, "Yeah, absolutely. Like, that would be great." And so I came on as one of the regular co-hosts on The Ruby on Rails Podcast, which I should have been flying high, right? Like, this is exactly what I wanted. I got to become like one of my own celebrities, right? Well, Kyle got really busy. At the time, I believe it's when Microsoft was acquiring GitHub. And Kyle still works at GitHub today. Kyle is amazing. He's their COO now. But the podcast kind of went dormant for a couple of months. It was my big opportunity. I really loved, you know, being on a podcast. I had done a couple of episodes. So I reached out to Kyle and said, "Hey, is there any chance you would give me the podcast?" And he said, "Absolutely." And he signed over everything to me, [laughter] which was really scary because I was taking over a podcast that had been around, at that time, it had been around for at least ten years, hundreds of episodes deep. It was on its own network. It was on the 5by5 Network at the time. So it had sponsors and expectations. And so, really, I had to learn everything from the get-go. Like, I made up my own episode plans. I made up my own questions, like, how to do ad reads, how to edit, how to upload to the hosting platform like; that was entirely on me. And, you know, we can talk more about how the podcast has evolved over those years. But yeah, long story now made short, that is how I got my start in podcasting. WILL: That's actually really amazing that that's how it got started and everything. Let's go back to when you first started. What was your feelings like? You say it was a lot to take on. Can you dig deeper in that and tell us more about that? Because I think I felt the same way. I think we've been doing this for about a year now. It's scary, let's be honest. It's scary jumping on a podcast and sharing who you are and what you're doing. So, can you tell us more about that? BRITTANY: Absolutely. I think one thing is just knowing what is your brand and, you know, what listeners should expect from listening to you because this is a podcast that had been around for ten years. You know, it had changed formats several times. It was an interview-style podcast at one point. At one point, it was a bunch of co-hosts that would just meet every week to talk out what was going on. And so I really needed to take a moment and kind of look over the metrics of the episodes. Like, I have that marketing background. I have that product background. So I wanted to know, like, what's actually working? Like, what do listeners want to listen to? And I also, like, kind of pored through all the reviews of the podcast. I'm like, did people even notice that this podcast went offline? Like, what's the current ecosystem? How many podcasts are out there in the Ruby and Rails space? And so what I started doing is I wanted to create, like, a safe environment in order to start the podcast over again. So what I did is I did interview-style podcasts with my friends, people that would tolerate me, you know, making mistakes, knowing that I was probably...I am a terrible editor. And so bringing those people on to have just genuine conversations with. And then really just tried to pick up the listenership of the podcast because I'm basically waving my arms saying, "Hey, folks. Like, The Ruby on Rails Podcast is back. I'm here as your host. And, like, we are here to stay. Like, I want this to be a mainstay in the community." VICTORIA: That's great. So you started to apply those concepts from your product background. And I'm curious what you found in how the business of the podcast really works. BRITTANY: Yeah, I learned a lot, and we can talk about the transition. So, when I came on to the 5by5 Ruby on Rails Podcast, at the time, this was back in 2018. The podcast was being managed by 5by5, which is, like, a long-standing podcast network. They're still around, but they're much smaller than they used to be. So, like, all of the sponsorship and the episode management was being handled by them. And so I didn't have a lot of insight into that part of the podcast. What I did have insight into is, like, what content is performing well? And what is the audience reaction to what we're putting out there? Like, how is the listenership coming back and whatnot? Now, one thing that did happen over the course of me managing The Ruby on Rails Podcast is we decided to take the podcast independent at one point, you know, 5by5 was starting to wind down. And so, back in 2021, I reached out to 5by5 and said, "Hey, I genuinely really love this podcast. I want to be able to take it to a different platform, you know, have it go independent. But it's really important to me that I'm able to hold on to the current subscribers that I have." I think we all know that, like, if you rebrand something and it's a totally different RSS feed, it's really hard to get people to move over, especially if they're using something that makes podcast listening really easy like Apple Podcasts, you know, you subscribe. You get new episodes, and you just hit play. And so they were extremely willing to work with me. And so, we ended up taking the podcast independent. 5by5 created the hosting platform Fireside. And so we moved the podcast over to Fireside, and that was, like, a very seamless transition. But it was a moment in time where, you know, I was kind of questioning. We're no longer 5by5. It was the 5by5 Ruby on Rails Podcast. What do we call it? And so I genuinely had that moment where I was like, I could be really clever with the name. But then I stepped back, and I was like, no, everyone already refers to it as The Ruby on Rails Podcast. I'm just going to go with it. And so I think that ended up being a good decision. We did change the logo of the show. We kept the same feed. And we had, like, the first episode on the new...we're not even on a network now; we're independent. The first episode of, like, the V2 of The Ruby on Rails Podcast is really what we called it. We just kind of explained the whole move. And I'm just deeply grateful all of our listeners just kind of followed along. And I will say the biggest boon to us moving is that we did get a professional editor. And so, like, the quality of the episodes went up, which is the best money that you can spend. Get yourself a professional editor. I cannot stress that enough. Or you get really good at it yourself. But I know my own skills, and it was never going to be that way. And so we took it independent. And I also decided to do a format change as well because it was a lot to do years of a podcast by myself. It was a lot. So I'm really glad Victoria and Will that you have each other. I think it's really great to have co-hosts. So I ended up moving the podcast. I now have a producing partner, and that's Mirror Placement. They do recruiting for Ruby on Rails, and they are wonderful partners. But I also have three co-hosts that rotate through. I have Brian Mariani, who's a recruiter and founder of Mirror Placement. I have Jemma Issroff, who works on Ruby at Shopify. And I have Nick Schwaderer, who works on Rails infrastructure at Shopify. And that's been great because I rotate through those co-hosts. And I always have fresh content from them. But I also do the interview-style episodes as well, which Victoria was on recently. VICTORIA: Yes. I agree 100%. Having a co-host like Will makes it so much more fun. And I cannot appreciate our editor Mandy Moore enough. And I agree on that advice. And I actually would add when people ask me if they should start a podcast, recommend having at least one other person [laughs] who you want to talk with about that topic for every week. But I wonder, if someone's thinking about starting a podcast, what would you have them consider as to whether or not it's worth it for them? BRITTANY: I recently joined the podcasting subreddit on Reddit just because I was interested to see what kind of questions there were out there. Because when I got into podcasting, I was, like, oh, you just need to have a microphone and a way to record, and you just put it out there, and people are going to listen. It feels very much...like, you remember when, you know, the iPhone came out, and the App Store was empty? And then any app that you made was, like, amazing. Everybody would download it because there was nothing to download. We're now getting to a point with podcasts; there's just a lot out there. My first bit of advice is, something that I said earlier, is make sure that you have an identity around your podcasts. Like, make sure that you are targeting a niche. It's fine if there are other people doing it, but do something that is uniquely you and do something that brings you joy. I really love talking to people in the Ruby on Rails Community. I have a special affinity for people who have never been on a podcast before. It's a lot of work. So it's definitely worth it. I've gotten to meet a lot of my programming heroes because of it. And there are times where I've been very tempted to take a break and be able to step away from it. But, as of right now, it has been a good experience. And what I often say whenever I open up my conference talks is the Ruby on Rails Community is my community contribution because I'm not someone who regularly contributes to open source. And so this is kind of, like, how I give back, and I get to meet a lot of amazing people. Mid-Roll Ad: VICTORIA: Introducing thoughtbot's ongoing maintenance service. Need reliable support and maintenance for your software? Look no further. Our expert team handles upgrades, bug fixes, UI adjustments, and new feature development. And the best part? Our maintenance packages start at just 5k per month for companies of all sizes. From Ruby on Rails to Node, React, and, yes, even PHP, we've got you covered. Trust thoughtbot for top-notch support and optimized performance. To receive a custom quote, contact sales@thoughtbot.com. VICTORIA: And with me here, I have Richard Newman, who's the Development Director on our Boost Team, to talk to me a little bit more about what maintenance actually looks like once you've built your software application, right? RICHARD: Hi, Victoria. VICTORIA: Hi, Richard. You have experience building applications. I wonder if you could describe to a founder who's considering to build an application, like, what should they consider for their long-term maintenance? RICHARD: Well, like you said earlier, part of what you're going for with that long-term maintenance is making sure the health of your project, of your application, is always there. And you don't want to be surprised as you're continuing to work with your users and so forth. And so a number of things that we pay attention to in maintenance are we're paying attention to keeping the application secure, providing security updates. We want to make sure that the ecosystem, basically, all of the tools and third-party services that are tied to your application, we're responding to those sorts of changes as we go along. And then part of it is, occasionally, you're going to find some smaller issues or bugs or so forth as your user group continues to grow or as needs continue to change. You want to be able to respond to those quickly as well. And so a lot of what goes into maintenance is making sure that you're paying attention and you're ahead of those things before they surprise you. VICTORIA: Because what can happen? Like, what are the consequences if you don't do that ongoing maintenance? RICHARD: Well, the security updates those happen across gems and in the platform sort of tools that are there. And so, if you're not keeping those up to date, your exposure, your vulnerability to being hacked, or having a bad actor come into your application start growing on you if you're not doing the maintenance. The other ones that can come up is there's new interfaces that these third-party services...they may be updating their APIs. They may be updating how you're supposed to work with their tool. And so those can occasionally break if you're not paying attention to what's going on or you're suddenly surprised by an upgrade that you have to make. And then, finally, there's this long-term sort of code change that just builds up over time if you're not keeping it refactored for the changes that are upcoming in a language or the gems that you work with. And then, suddenly, after a while, it suddenly gets to the point where you have a lot of work that you might have to do to rehabilitate the application to take on some of the newer features that are being released. And so that makes it that much more difficult, that much more friction about being able to deliver updates for your users or to be able to respond to changes that are happening out there in your application. VICTORIA: Right. So, if you don't have that ongoing maintenance, you could run into a situation where suddenly, you need to make a very large investment and fixing whatever is broken. RICHARD: Absolutely. It's going to be very tough to plan for if you weren't keeping up all the way along and, yes, absolutely ends up being much slower if you have to remediate it. VICTORIA: That makes sense. I wonder if you have any examples of a project you've walked into and said, "Wow, I wish we had been doing a little bit more maintenance." [laughs] And maybe you can share some details. RICHARD: Yeah. We had a fairly large application that involved a number of clinic services. So we had an application that users were going in every day and counting on our fast response. And, over time, we've got surprised by a database upgrade that had to happen. Basically, the database was going to be changed by our third-party hosting service, and that hadn't been tested. There hadn't been procedures in place when we discovered this need. And there was a very hard date that that change had to be done or else the entire application was going to go down. And it came at a very inconvenient time, at the end of the year around Christmas, that we had to respond to all of that. And had we been in front of it and just updated it every quarter and staying current with it, it wouldn't have been nearly the lift that it turned out to be. We were facing a pretty hard deadline [laughs] there to keep things going. It was very, very stressful and disruptive for the team and potentially for the clinics. VICTORIA: Right. And it always happens around a big holiday or something like that, right? When it all comes to a head. [laughter] RICHARD: Absolutely. You want to be in control of the timeframe and not have the timeframe be in control of you. VICTORIA: Right. And if you have a team like thoughtbot supporting you, you can go on your vacation with a little bit more knowledge that if something breaks, there's someone there who can respond and fix things, and you don't have to interrupt your very valuable time off. So... RICHARD: [chuckles] Absolutely. VICTORIA: Yeah. Well, thank you so much, Richard, for joining me today. I appreciate you coming here to talk with us. And we'll talk to you again soon. RICHARD: Yeah, it was a pleasure. Thank you. WILL: I have a question around your listeners. I just want to take a second and just thank everyone who listens to the podcast. We really appreciate you so much, so just thank you, thank you, thank you. Because if you don't have listeners, you don't have a podcast, like you said a second ago. And you went through so many changes. What's been your biggest win, and how do you continue winning with your listeners? And how do you engage with them? BRITTANY: This is a fun answer because, actually, thoughtbot comes into play there. They did not pay me to say this. But one thing that The Bike Shed used to do is they used to go to RailsConf and RubyConf, and they would record episodes during the conference with various Ruby heroes in the community. This is going back to me seeing these people as celebrities. I just thought that was, like, the coolest thing. And, at the time, I couldn't afford to go to conferences like that. So being able to listen to those podcasts and get to hear that kind of content was really important to me. And so, you know, eventually, that stopped being a thing at RubyConf and RailsConf. And two years ago, I reached out and said, "Hey, I really love those kinds of sessions. Is there any way that I could take the lead on bringing those sessions back?" And we did. So it took in the form of a podcast panel at these different conferences where we would bring in different podcasts in the community. And we would have a panel. We would answer listener questions. It was genuinely a lot of fun. So that is a proud moment for me. But it's a proud moment for me because it gave me the opportunity to reach out to podcasts in the community and say, "Hey, we're not competing here. We're friends. I want to record content with you. Like, please be part of my podcast community." And we have never been tighter. So, like, we guest on each other's podcasts. We promote each other's podcasts on like Mastodon and Twitter. And it is just the most lovely thing ever because now we say things like, oh, yeah, like, this podcast, like, that's our, like, sister podcast, or that's our brother podcast. Like, it's so cool that we, you know, rising tide raises all ships. That's exactly what's happening here in the Ruby podcast community. VICTORIA: I like that familial sense within the different Ruby on Rails podcasts, and maybe even Giant Robots is a part of that. Like, are we a cousin or an uncle? [laughter] Who knows? But I was actually there when you recorded the episode live at RailsConf in Atlanta this year. Was that your favorite moment at RailsConf, or was it something else? BRITTANY: Yeah, I would say that was my favorite moment at RailsConf. No matter how many times I meet Aaron Patterson, I am always, like, deeply intimidated by just how funny and intelligent he is. So having that excuse of reaching out to him and saying like, "Hey, will you please be on this podcast panel?" was so fun. I deeply adore Irina Nazarova, and so having her on the panel as well was fun. And then just doing the wildcard of having the audience, like, vote in who was going to be the third panel was truly a risky move, Victoria. [laughs] But it ended up paying off, and it ended up generating some really fun content for us. VICTORIA: That's awesome. And I'm curious, you know, to talk a little bit more about the Ruby on Rails Community. And what do you see is the biggest challenge that it's facing right now? BRITTANY: Oh, I have so many opinions on this. What a great question. [laughs] So I recently put together a talk proposal. It's currently waitlisted at a conference, but it is a talk that I very much want to give. But one project that I would really like to work on is...between, I would say, 2013 and 2015, Ruby on Rails was definitely the number one framework that was being taught in bootcamps. And I'm really curious about what happened to all those people. I'm one of them. I learned Ruby on Rails in 2014. I still believe that I'm in the Ruby on Rails Community, not only for the podcast, but I'm an engineering manager for a company that writes Rails. So I believe I'm very much in the community. I'm so curious. Those people had so much potential of being seniors, principals, staff engineers, founders, engineering managers, architects. What happened to them? And did they stay in our community? And then my second part of that is, what does it mean to be in the Ruby on Rails Community? Like, can you just listen to podcasts and be in the community? Do you need to actively write Ruby? I just find that whole thing very interesting. We're very obsessed with bringing new programmers into the Rails community, which I think is important. But what about the people who we taught Rails and left us? Like, is there an opportunity to bring them back? WILL: It's funny you say that because I wasn't in that year range. I was a little later, like, 2017. And I learned Ruby on Rails, and then I went to JavaScript, you know, React, React Native, but I'm slowly inching back towards Ruby on Rails. My current project, I'm actually able to do some Ruby on Rails. And I'm really excited about it because, like you, that was my first language style that I learned, and I still love it. It is weird, but you always love your first language; I do, at least. So it's interesting that you said that because, yeah, I can say, for me, I'm slowly coming back towards it. BRITTANY: Well, welcome back, Will. We're excited to have you. I know that Node was such a heavy hitter when it came out, and it made a lot of sense. Like, we're going to teach you JavaScript on the front end. Oh, hey, we're going to also teach you JavaScript on the back end. You know, from the business side, I'm so curious whether or not Rails is still, like, one of the top three solutions in order to get an MVP off the ground. I don't have my thumb on that, so I'm very curious whether or not that's true or not. VICTORIA: We certainly still tend to default to it at thoughtbot and to get MVPs off the ground. And we're still building a bunch of products every year with it. [laughs] So, Ruby on Rails and React together, especially if you're trying to iterate very quickly and test your assumptions about what you're building, I think that it's still a really fast and high-performing framework to use. And it's interesting because there's a coding school in San Diego, Codecademy, which is really heavily involved, [chuckles] of course, in the Ruby on Rails Community, and they still teach it in their bootcamp. And one of the reasons they said to me was because it's one of the frameworks that gives you that holistic view of how everything works. [laughs] Like, if you're new to tech, new to programming, in general, it's a very easy entry point to understanding. And I think that, of itself, when you're talking, like, the long-term viability of a framework, being able to hire people who can step in and understand what's going on in your codebase, that framework gives you a higher chance of that. [laughs] You know, that might point to your long-term success, too. BRITTANY: Now, that's a really good point. Going back to the podcast as well, I think one thing that is not very well solved is just being able to make it sustainable as well because there are only so many sponsors out there. And it's really hard to prove ROI from sponsoring a podcast, right? Like, you can put links in the show notes. And you can hope people click on them and they convert. And you can be able to say, "Hey, this podcast is the reason." But I've seen a lot of people start podcasts, and they think, well, if I put a bunch of episodes out and some people listen, then sponsors are going to knock down my door. I'm very lucky that I've had some long-term sponsors that have been able to keep the show sustainable. And I love seeing podcasts that come out of companies, you know, like thoughtbot, where you are being sustained by the company that, you know, is producing it. It's really hard to justify a podcast as a business unless you are already a major celebrity already, right? VICTORIA: Yeah, we certainly don't do it for the money it makes us directly off the podcast. We do not. [laughter] BRITTANY: We do not. VICTORIA: Yeah, I agree with that. And yeah, and even it's interesting as an advertising vehicle or marketing for your company. It can be great because, like, I feel with Giant Robots, we have so many listeners, like, loyal listeners over the years that we have this, like, direct way of communicating with a community that we care about. [laughs] But if you don't have...trying to, like, create that market and create that group of people from the ground up can be really tough. [laughs] And it takes a lot of time, a lot of investment, and a lot of effort, especially if you can't afford a professional editor. [laughs] BRITTANY: Agreed. There's just some cost that I believe, like, the longer I do this, that are just, like, non-negotiable. There are some things that you can definitely have as optional. You know, for me, like, you have to have a good microphone. You have to have a professional editor. I pay for, like, my calendar scheduling software because I want to make that really, like, slick for my guests. Like, I used to...oh, I used to do the emails back and forth of, like, I'm available at Thursday at 2:00 or Friday at 3:00. Like, would one of these work for you? No. [laughs] It's just...that's a rotten experience. For us, we do send, like, a thank you gift after being on the show, which has been, like, a nice add with having a producing partner that will back me on that. And I try to get to as many conferences as possible because I think it's a great vehicle to promote the podcast, but those end up all being optional. And all those things they do cost money. VICTORIA: They do. And it's funny, like, yeah, getting out to the conferences, it's still the number one way to grow things is by meeting people in person [laughs], like, being real and human. BRITTANY: Shocking, right? [laughs] VICTORIA: Yeah. And I'm just kind of curious, like, in terms of how you picture what success means for your podcast. Like, what does that look like in the next six months or even, like, five years of hosting this podcast for you? BRITTANY: Ooh, this is, like, the existential crisis question because I've been doing it for nearly five years. And I think the question is always going to be, you know, like, how long do I want to keep hosting the podcast? I will say the podcast is a positive influence on me in terms of making sure that I stay connected to people, that I keep writing code on the side so that way, I know what I'm talking about. I have this whole imposter thing of, like, what if someone finds out I'm not a Ruby on Rails developer day to day and that I'm, like, actually thinking about business problems; I was, like, an engineering manager? You know, I'm going to get found out, and people are going to unsubscribe. But in all seriousness, I think the success for this podcast is that it can go on without me. It's been around for that long already. And eventually, like, I want to have a succession plan where someones, I will say, like, multiple co-hosts to be able to take it over from there. It'll be rough to watch because, like, I really enjoy, you know, my current era because I feel like the podcast has gone through different eras. I really do enjoy it. But, at some point, it's just not going to make sense in terms of my professional goals. Do you feel the same? VICTORIA: Yes. But we're only a year in. So I feel like I'm still...[laughter] I feel like I'm still new to hosting. And I'm like, oh, I've already recorded, like, 30 episodes or something. [laughs] There's been a lot of change. And we're always thinking about, like, how do we make it better? What do we do? And trying to figure out how do we really get the most out of it for ourselves. But I feel the same way that it's just one of the more fun things that I do at thoughtbot [laughs]. And it gives me that chance to reach out to people and start conversations that I otherwise would not have had. So I really appreciate it. I don't know what you think, Will. WILL: No, I totally agree with you. I love meeting new people. And I love meeting the diverse group of people that we have on the podcast. I love that just, like, how did you get here? Like, what makes you keep at it? Like, you've been at it for five years. What makes you keep at it? Just those questions like that I really love. For me personally, I think that I'm still in the growing phase of podcast hosting. Like, I can get better at this. I can get better at that. What else can I get better at? So I think that's where I'm at in this phase. But, like Victoria said, that's only a year in. It's a different story when you're five years in. BRITTANY: [laughs] It is. And one thing that I will do to make it more sustainable is, you know, like when you're running, you can either be sprinting, or you can be doing, like, a long endurance race. So with the podcast, I will book a bunch of podcasts in one week and say, this is my week to be recording. Like, I'm going to be very heads down on the podcast. I have other things going on in my life, but I'm like, this is a podcast week for me. And so I will record a bunch of episodes. And that essentially gives me a couple of weeks where I can essentially take a break from the podcast. But guess what, listeners? Like, you're still getting new episodes. So you have no idea that I'm secretly taking a break. And I think that has also been a huge help. Odd fact is that the five years that I've been hosting The Ruby on Rails Podcast, I am only missing from one episode. And the reason for that is that when I broke my ankle, [laughs] I called my co-host and was like, "Hey, I'm going into surgery tomorrow. We have this great episode being recorded tomorrow. I need you to take it." [laughs] And so that is the one episode that I am missing from, but I think it was a good lesson for me to know that I can step away and good content can still happen. WILL: That's amazing. That's a pretty good record. [laughs] BRITTANY: Or it might be obsessive, Will. I don't know. [laughter] WILL: Let me ask you this, what does success look like for you personally - roller derby, your full-time job? What does success look like for you in those areas in six months or a couple of years? BRITTANY: Oh, that's a really great question. So I had stepped away from roller derby during the pandemic. And so I absolutely love fitness. I do CrossFit. I have a peloton. I have my own little home gym that I built during the pandemic that I absolutely adore. So, you know, success for me is continuing to invest in that self-care. I want to keep skating just because I'm that person. Everyone came to me, and they're like, "Oh, you broke your ankle. I bet you won't go back to a roller derby." And I was like, oh, you think I won't? You think I won't go back? [laughs] So I'm headed back, but I'm going to be very careful about it. Because I've seen that, you know, your body can break, and you need to give yourself some rest. But to answer, overall, like, I am an engineering manager now, and, you know, my goal is to eventually to get to that director level. And, in some ways, like, I can justify the podcast just because I do get the excuse to talk to people that have the job that I eventually want to have in my career. And so it helps in that regard as well. VICTORIA: I think that's great, and I agree. That's also why I started getting involved in my community a lot, maybe 5 or 10 years ago. I was just like, here's opportunities to show my leadership and see how connected I am with other leaders. [laughs] It helps in that way. And on blading, I actually bought rollerblades recently just to go around the neighborhood. BRITTANY: Yeesssss! VICTORIA: And I got heckled by a woman [laughs] who said...I think she was being sincere, but she was like, "Bend your knees, and it's going to be okay." [laughter] Like, "Wear wrist guards next time." [laughter] I was like, maybe just my face was very try-hard in that moment. Because I have a lot of respect for people who can roller derby and get around on skates that fast. [laughs] BRITTANY: Well, you know what's really funny? (I haven't even talked about this on my own podcast.) is that you know, I'm involved in the Roller Derby League. Obviously, I can't skate right now. And so I needed to find a committee so that I was able to still, you know, provide value to the league. And so, for some reason, I decided that skater resources would be a good idea. So I'm essentially one of the people who is, you know, human resources within the Roller Derby League. And so when there are disputes or questions, or people have hurt feelings, like, they're coming to me, which is, you know, really funny because I do some of that as an engineering manager. So, like, to your point, Victoria, like, you know, I can do growth because they're way more extreme through roller derby, as you can imagine. And, in some ways, it ends up being good practice. VICTORIA: Yes, that does sound like practice for higher-level management decisions, [laughs] so get ready. You're going to have issues and problems, and you're the one to solve it. So... BRITTANY: Yeah. It's not like their problems don't matter. But, in some ways, it's almost like playing with monopoly money because, like, you know, you're not dealing with somebody's, like, livelihood. You're dealing with a sport that they do for fun. Like, trust me, no one is being paid to play roller derby. [laughs] It's a very expensive sport. There's a lot of equipment involved. And, Victoria, yes, you want to wear wristguards. [laughter] VICTORIA: Yes. I learned my lesson. BRITTANY: You write code. You want to wear wrist guards. [laughter] VICTORIA: Right. And yeah, it's funny about things like that. Like, it's still very meaningful to people. Like, when I used to coach kids' climbing competitions, it's, like, the same thing. Like, it's rock climbing, everybody, but some people take it very seriously. [laughs] There's a lot of feelings involved. But, at the end of the day, it's nice to have that practice outside of the pressure of it being someone's livelihood and all of those details. BRITTANY: Agreed. VICTORIA: Well, let me ask you this question. It's one of our favorite ones. But if you could go back in time and give advice to your younger self, what would you say? And maybe it's at the beginning of the podcast or some other inflection point in your career. BRITTANY: That is...oh, what a gift because hindsight is 20/20, isn't it? When I was going through school, I ended up getting a marketing degree because I really enjoyed business. I really liked, you know, the mechanics behind marketing. But, at the time, I had taken a couple of computer classes, and this was back in 2006. And, you know, I thought about double majoring in computer science and marketing. And someone gave me the terrible advice that computer programming was going to go away [laughs], and so it would be a waste of time to get that double degree in computer science. And so, you know, I'm very much a second career developer. Like I noted earlier, you know, I was a PM. I was a non-technical product manager before I learned how to code, and so I learned how to code in my 30s. So I wish I could go back and get into programming way earlier. It would have changed the entire trajectory of my life. But part of me always wants to live out, like, that Black Mirror, like, what it would have been like if I had learned to code so much earlier. Would I have found Ruby? Maybe not. WILL: I totally agree with that because the same story. I remember growing up, and I had a cousin that lived next door. He used to program, and I was just, like, he was a celebrity because I was like, whoa, look what he's doing, and how can you do that? And then I went off to college. Well, I grew up in a small town, so we didn't really have many computer programs. I went to a college, and they said, "Hey, we have this one computer course you can either take it or test out." I was like; I'm not taking it; test out. I want to save that money. And I didn't realize how much I'll love computers and programming until later in life, late 20s, early 30s. And I wish I could have started early, so I totally agree with you about that. VICTORIA: Like, I wish I would have time now to learn how to code. [laughs] Like, I still need to learn it. No, I think that...oh, would I advise? I don't know. You know what's funny? A recent guest said that if that had happened, they still wouldn't have believed themselves [laughs], right? Like, would you really believe someone telling you what to do? Like, you know, you try to make the best decision that you can at the time. BRITTANY: I think it's fun to look back and see all the little things that happened that got you to where you are. So, like, two of, like, crucial things that happened for me. I was in school to become a genetic counselor, and I hated it. And so I had gotten an internship, and, like, that internship changed everything because it was like a day in the life as a genetic counselor, and I really did not like it at all. And so, I ended up dropping all my classes and moving into the business school. And so that was one thing that happened. And then the second thing is, you know, I was working at a cowboy restaurant. [laughs] It was ridiculous. And I was getting ready to graduate school and just absolutely terrified about not having a job. I ended up getting this table of this company that was, like, having a business meeting, and we ended up chatting, and they were so wonderful. And they left me their business card, and, like, that ended up being my first job. It's just the little micro-decisions that you make that, like, change your entire trajectory, which is really so cool. So you end up not really regretting anything, but you always just kind of look back and reflect, and you're like, what if I had given that table away? Or what if I hadn't been ambitious and, like, tried to get that internship? So just everything's an opportunity, right? WILL: Yeah, I totally, totally agree with that. So you do roller derby, CrossFit, marathons, coding, your podcast. So you do a lot of self-care, which I don't think, especially in the tech world, we do enough self-care. I know I don't. I am horrible at it, trying to get better. What's your wind in your sails for that? Like, how do you keep going? Like, how do you stay disciplined with that? BRITTANY: I think, for me, I feel better when I move my body. I make better decisions. I am more patient. I need to work out earlier in the day. Like, I am a morning person, and so it makes me feel good. And so then I go into work in a good mood. And I deal with people day to day, right? Like, I manage ten developers. And so it's also something that I can use to connect with my team as well. A lot of them also like to do physical things, and so that works out nicely. In terms of nutrition, I definitely could be better. But I will say my partner and I take turns meal prepping our lunches. We both work from home. And so being able to, like, in between meetings run over and grab a box of actually good food to be able to eat lunch. We do, like, a meal service at night as well. I don't know, like, you need to look out for you. Because while the belief is that other people are also looking out, nobody's going to look out for you like you are. And so you have to prioritize self-care and just making sure that you're getting those moments. And I agree with you, Will; sometimes, I'm absolutely terrible at setting up those processes so that way you don't fall through. VICTORIA: I think there's a book that makes me think of it called, like, The Subtle Art of Not Giving a F*ck. [laughs] BRITTANY: Yes. VICTORIA: Yeah. BRITTANY: Yes. VICTORIA: Yep. And I think that's part of it, too. Like, there's a lot of pressure to be so high-performing and to do all the things for your family, and for your work and your personal life. But, at the end of the day, it's also okay to just sit around and do nothing [laughs] and, like, relax. BRITTANY: Yeah, I've watched a lot of Drag Race, a lot. [laughs] VICTORIA: Oh, awesome. Yes. What's your favorite season? BRITTANY: Oh, season six, I would say. Season six is just so good. Are you watching All-Stars? VICTORIA: I'm not right now. I'm actually...I usually binge-watch it at random times. So I'm not really caught up. But I have met a few of them at drag shows. I think I've met Milk. Is that [inaudible 44:27] BRITTANY: Oh, wow. What a queen to have met. VICTORIA: I know. BRITTANY: That's amazing. [laughs] VICTORIA: That was actually a very funny story. I'll tell you another time. [laughs] But yes. BRITTANY: But honestly, like, Drag Race actually relates to engineering management for me because, you know, at my last job, I had two developers that I was struggling to connect with. And I realized that after stand-up, they were staying behind to talk about Drag Race, and I wanted to connect with them. And I was like, oh, I'll check out a couple of episodes and became so deeply addicted [laughs] that, like, I surpassed them in how much I loved it. So, like, it is a fun, like, I've always thought about giving a conference talk where, like, each report that I have, like, one crazy thing that they do...well, not crazy but, like, one, you know, passion that they have and, like, trying it just to have something to relate to. Though I will say, I did manage somebody who really liked to jump out of planes, and that is just not in the cards for me. VICTORIA: I love that too. I like when someone is really passionate about something. I'm like, okay, I'll give it a chance, at least once, you know. But I have some friends right now who are into freediving, and I'm not convinced [laughs] that I want to go try to hold my breath underwater. BRITTANY: What in the world is freediving? VICTORIA: It's diving underwater without oxygen. BRITTANY: No. VICTORIA: Yeah. Yeah. BRITTANY: That's a big nope for me. VICTORIA: And, like, hunting fish. So, like, they catch tuna and stuff. They're down there pew-pew and making sushi when they get back. BRITTANY: Well, that actually sounds wonderful. But -- VICTORIA: Yeah, I'm like, I will eat this. I will eat [laughs] whatever you catch. BRITTANY: Yes, that's fair. VICTORIA: Yeah. Like, I'm into the results but not...I might try some of the, like... a lot of it is, like, training your breath and being able to hold your breath and to stay calm because that's really the biggest problem. [laughs] I do rock climbing. I think that's enough. Like, that's -- WILL: [laughs] BRITTANY: That's pretty badass. VICTORIA: Yeah. [laughs] WILL: Yes. BRITTANY: That is a very cool sport. VICTORIA: Yeah. And, actually, you're mentioning how it was, like, you worked at a cowboy restaurant, and that was how you got your first connection to your job. And, like, I would go up to, like, my college climbing wall and be, like, I'm a rock climber; you should hire me. And [laughs] through that connection, I got my first referral to my first job in DC. And so, basically, my whole life revolves around it. [laughs] Nothing would happen without these little connections that you make. I'm curious, Will, if you had a pivot point like that you can tell us about. WILL: It was probably getting to tech because it was more of a hobby, and sometimes it's still a big hobby for me. So I will say either getting into tech or working out. So I try to work out with friends. So I used to play football. Everything was a group workout. So after football, it was very hard for me to work out because it was always a group workout. So after many, many years of finally realizing that, I try to work out in groups, with friends, and stuff like that. So that's probably the biggest thing for me is, like, working out in a group and having someone to hold me accountable. BRITTANY: I love that. That's one reason...so I used to be a fitness instructor. I should reveal that as well. I used to be a BODYPUMP instructor. And the reason for that is just, like, again, I thought people that were fitness instructors were just, like, celebrities and absolute badasses. And so, I used to only go to group fitness class as well because I needed that accountability. And so, yeah, there's definitely days I wake up where I absolutely do not want to do anything. But having that accountability, it's just really awesome, and really, it makes sure that you follow through. VICTORIA: That makes sense how you've practiced your voice and why your podcasting voice is so strong [laughter] because you're a fitness instructor. That's what is starting to add up for me. [laughter] BRITTANY: You know what? The biggest challenge of being a fitness instructor is that they would send me the routines, and I would have to memorize them. And being able to memorize like, oh, I'm going to squat on the fourth count. And I'm going to do a clean and press on the eighth count. Oh my God, is that an algorithm -- WILL: Yes. BRITTANY: You know, for a pro...and I was like, is there any way that I could somehow automate? Like, part of me wanted to game it. I'm like, how do I game this so I don't have to spend so much time trying to memorize it? I mean, it was truly, truly challenging. And it was probably, like, the best brain teaser that I could have been doing because you're essentially putting on a live performance while working out. And everyone needs to be able to follow you and feel encouraged by you. It was just...it was a wild time. WILL: [laughs] VICTORIA: That sounds very demanding. Well, coming up to the end of our time here, is there anything else you would like to promote today? BRITTANY: Ooh, no. We're currently not hiring at my job. Normally, that is something that I would promote. I would say if you are interested in checking out my podcast, it is The Ruby on Rails Podcast. We have plenty of things on there that are not Rails-specific. We've had conversations about, like, what's it like to get stock options at a company? What does the recruiting landscape currently look like? And then we also have, like, deep topics about, like, what's currently being merged into Ruby Core? So, really, we have a wide variety of topics. So, if you find my voice somewhat pleasant, come on over; we'd be happy to have you. And, of course, you can listen to Victoria's episode, that will be linked up in the show notes. But this was such a pleasure. It was great spending time with you both, Will and Victoria. WILL: Yeah, it was great. Loved chatting with you. VICTORIA: Yes, thank you so much for joining. This was super fun. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. WILL: If you have any questions or comments, email us at hosts@giantrobots.fm. And you could find me on Twitter @will23larry. VICTORIA: And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Brittany Martin.Support Giant Robots Smashing Into Other Giant Robots

Charity Majors is Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. Victoria and Will talk to Charity about observability, her technical background and decision to start Honeycomb.io, thoughts about the whole ops SRE profession, and things that surprised her along her journey of building a company around observability as a concept. Honeycomb Follow Honeycomb on Facebook, Twitter, Youtube, or LinkedIn. Follow Charity Majors on LinkedIn or Twitter, or visit her website. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. WILL: And I'm your other host, Will Larry. And with us today is Charity Majors, Co-Founder and CTO of Honeycomb, which provides full-stack observability that enables engineers to deeply understand and debug production software together. Charity, thank you for joining us. How are you doing? CHARITY: Thanks for having me. I'm a little bit crunchy from a [laughs] long flight this morning. But I'm very happy to be home in San Francisco and happy to be talking to you. VICTORIA: Wonderful. And, Charity, I looked at your profile and noticed that you're a fan of whiskey. And I thought I might ask you just to get us started here, like, what's your favorite brand? CHARITY: Oh, goodness, that's like asking me to choose my favorite child if I had children. [laughter]. You know, I used to really be into the peaty scotches, the Islays, in particular. But lately, I've been more of a bourbon kick. Of course, everybody loves Pappy Van Winkle, George T. Stagg; impossible to find now, but it's so, so good. You know, if it's high-proof and single barrel, I will probably drink it. VICTORIA: That sounds great. Yeah, I tend to have the same approach. And, like, people ask me if I like it, and I like all of them. [laughter] I don't [inaudible 01:21] that I didn't like. [laughs] CHARITY: [inaudible 01:23] tongue sting? Then I'm in. [laughs] VICTORIA: Yeah, [inaudible 01:26]. WILL: See, I'm the opposite. I want something smooth. I'm a fruity drink type of guy. I'm just going, to be honest. CHARITY: There's no shame in that. WILL: No shame here. [laughs] Give me a margarita, and you have a happy Will for life. [laughs] VICTORIA: We'll have to get you to come out and visit San Diego for some margaritas, Will. That's -- CHARITY: Oh yeah. VICTORIA: Yeah, it's the place to be. Yeah, we do more of a bourbon drink in our house, like bourbon soda. That's usually what we make, like, my own custom simple syrup, and mix it with a little bourbon and soda water. And that's what we do for a cool down at the end of the day sometimes, yeah. Well, awesome. Let's see. So, Charity, why don't you just tell me a little more about Honeycomb? What is it? CHARITY: Well, it's a startup that hasn't failed yet, so... [laughs] to my own shock. [laughs] We're still around seven and a half years in. And I say that just so much joking. Like, you're not really supposed to say this as a founder, but, like, I 100% thought we were going to fail from the beginning. But we haven't yet, and we just got more money. So we'll be around for a while. We kind of pioneered the whole concept of observability, which now doesn't really mean anything at all. Everybody and their mother is like, well, I do observability, too. But back when we started talking about it, it was kind of a little bit revolutionary, I guess in that, you know, we started talking about how important it is to have high cardinality data in your systems. You really can't debug without it. And the fact that our systems are getting just astronomically more complex, and yet, we're still trying to debug it with these tools based on, you know, the metric data type [laughs] defined since the '70s when space was incredibly rare and expensive. And now space is incredibly cheap, but we should be wasteful with it so we can understand our incredibly complex systems. So that's us. We really try to empower software engineers to own their own code in production. For a long time, it was like, all of the tools for you to understand your software were really written for low-level ops people because they speak the language of, like, RAM, and disks, and CPU, which you shouldn't have to understand that in order to be able to understand I just deployed something, what went wrong? WILL: I love the honesty because there are so many founders that I'll talk to, and I'm like, okay, you're very successful. But did you really expect this to be what it is today? Did you really expect to survive? Because, like, just some of their ideas, I'm like, it's brilliant, but if I was with you back in the day, I'd be like, it ain't going to work. It's not going to work. [laughs] CHARITY: Yeah. And I feel like the VC culture really encourages delusion, just, like, self-delusion, like, this delusive thinking. You're supposed to, like, broadcast just, like, rock-solid confidence in yourself and your ideas at all time. And I think that only sociopaths do that. [laughs] I don't want to work for anyone who's that confident in themselves or their idea. Because I'm showing my own stripes, I guess, you know, I'm a reliability engineer. I wake up in the morning; I'm like, what's wrong with the day? That's just how my brain works. But I feel like I would rather work with people who are constantly scanning the horizon and being like, okay, what's likely to kill us today? Instead of people who are just like, I am right. [laughs] You know? VICTORIA: Yeah. And I can relate that back to observability by thinking how, you know, you can have an idea about how your system is supposed to work, and then there's the way that it actually works. [laughs] CHARITY: Oh my God. VICTORIA: Right? CHARITY: Yes. It's so much that. VICTORIA: Maybe you can tell us just a little bit more about, like, what is observability? Or how would you explain that to someone who isn't necessarily in it every day? CHARITY: I would explain it; I mean, it depends on who your audience is, of course. But I would explain it like engineers spend all day in their IDEs. And they come to believe that that's what software is. But software is not lines of code. Software is those lines of code running in production with real users using it. That's when software becomes real. And, for too long, we've treated like that, like, an entirely different...well, it's written. [laughs] You know, for launch, I was like, well, it's ops' problem, as the meme says. But we haven't really gotten to a point yet where...I feel like when you're developing with observability; you should be instrumenting your code as you go with an eye towards your future self. How am I going to know if this is working or not? How am I going to know if this breaks? And when you deploy it, you should then go and look at your code in production and look at it through the lens of the telemetry that you just wrote and ask yourself, is it doing what I expected it to? Does anything else look weird? Because the cost of finding and fixing bugs goes up exponentially from the moment that you write them. It's like you type a bug; you backspace. Cool, good for you. That's the fastest you can fix it. The next fastest is if you find it when you're running tests. But tests are only ever going to find the things you could predict were going to fail or that have already failed. The first real opportunity that you have to see if your code really works or not is right after you've deployed it, but only if you've given yourself the telemetry to do so. Like, the idea of just merging your code, like walking out the door or merging your code and waiting to get paged or to get [laughs] escalated to this is madness. This should be such an artifact of the battle days when dev writes, and ops runs it. That doesn't work, right? Like, in the beginning, we had software engineers who wrote code and ran that code in production, and that's how things should be. You should be writing code and running code in production. And the reason I think we're starting to see that reality emerge again is because our systems have gotten so complicated. We kind of can't not because you can't really run your code as a black box anymore. You can't ignore what's on the inside. You have to be able to look at the code in order to be able to run it effectively. And conversely, I don't think you could develop good code unless you're constantly exposing yourself to the consequences of that code. It lets you know when it breaks, that whole feedback loop that completely severed when we had dev versus ops. And we're slowly kind of knitting it together again. But, like, that's what's at the heart of that incredibly powerful feedback loop. It's the heart of all software engineering is, instrumenting your code and looking at it and asking yourself, is it doing what I expected it to do? WILL: That's really neat. You said you're a reliability engineer. What's your background? Tell me more about it because you're the CTO of Honeycomb. So you have some technical background. What does that look like? CHARITY: Yeah, well, I was a music major and then a serial dropout. I've never graduated from anything, ever. And then, I worked at startups in Silicon Valley. Nothing you'd ever...well, I worked at Linden Lab for a few years and some other places. But honestly, the reason I started Honeycomb was because...so I worked at Parse. I was the infrastructure lead at Parse; rest in peace. It got acquired by Facebook. And when I was leaving Facebook, it was the only time in my life that I'd ever had a pedigree. Well, I've actually been an ops engineer my entire career. When I was leaving Facebook, I had VCs going, "Would you like some money to do something? Because you're coming from Facebook, so you must be smart." On the one hand, that was kind of offensive. And on the other hand, like, I kind of felt the obligation to just take the money and run, like, on behalf of all dropouts, of women, and queers everywhere. Just, you know, how often...am I ever going to get this chance again? No, I'm not. So, good. VICTORIA: Yes, I will accept your money. [laughs] CHARITY: Yeah, right? VICTORIA: I will take it. And I'm not surprised that you were a music major. I've met many, I would say, people who are active in social media about DevOps, and then it turns out they were a theater major, [laughs] or music, or something different. And they kind of naturally found their way. CHARITY: The whole ops SRE profession has historically been a real magnet for weirdo people, weird past, people who took very non-traditional. So it's always been about tinkering, just understanding systems. And there hasn't been this high bar for formal, you know, knowledge that you need just to get your first job. I feel like this is all changing. And it makes me kind of...I understand why it's changing, and it also makes me kind of sad. VICTORIA: So I think you have a quote about, you know, working on infrastructure teams that everything comes back to databases. CHARITY: [laughs] VICTORIA: I wonder if you could expand on that. CHARITY: I've been an accidental DBA my entire career. I just always seemed to be the one left holding the bag. [laughs] We were playing musical chairs. I just feel like, you know, as you're moving up the stack, you can get more and more reckless. As you move down the stack, the closer you get to, like, bits on disk, the more conservative you have to be, the more blast radius your mistakes could have. Like, shit changes all the time in JavaScript land. In database land, we're still doing CRUD operators, like, since Stonebreaker did it in the '70s. We're still doing very fundamental stuff. I love it, though, because, I don't know, it's such a capsule of computers at large, which is just that people have no idea how much shit breaks. [laughs] Stuff breaks all the time. And the beauty of it is that we keep going. It's not that things don't break. You have no idea how much stuff is broken in your stack right now. But we find ways to resolve it after the fact. I just think that data is so fascinating because it has so much gravity. I don't know, I could keep going, but I feel like you get the point. I just think it's really fun. I think danger is fun, I think. It might not surprise you to learn that I, too, was diagnosed with ADHD in the past couple of years. I feel like this is another strand that most DevOps, SRE types have in common, which is just [laughs] highly motivated in a good way by panic. [laughs] WILL: I love that you said you love danger because I feel like that is right in your wheelhouse. Like, you have to love danger to be in that field because it's predictable. You're the one that's coming in and putting out the fires when everyone sometimes they're running for the window. Like you said, like, you got caught holding the bag. So that's really neat. This is a big question for me, especially for being an engineer, a dev, do you find that product and design teams understand and see the value in SRE? CHARITY: Oooh. These types of cultural questions are always so difficult for me to gauge whether or not my sample is representative of the larger population. Because, in my experience, you know, ops teams typically rule the roost, like, they get final say over everything. But I know that that's not typically true. Like, throughout the industry, like, ops teams kind of have a history of being kind of kicked around. I think that they do see the value because everybody can see when it breaks. But I think that they mostly see the value when it breaks. I think that it takes a rare, farsighted product team to be able to consent to giving, like, investments all along in the kinds of improvements that will pay off later on instead of just pouring all of the resources into fast fixes and features and feature, feature, feature. And then, of course, you know, you slowly grind to a halt as a team because you're just amassing surface area. You're not paying down your tech debt. And I think it's not always clear to product and design leaders how to make those investments in a way that actually benefits them instead of it just being a cost center. You know, it's just something that's always a break on them instead of actually enabling them to move faster. WILL: Yeah, yeah. And I can definitely see that being an engineer dev. I'm going to change it a little bit. And I'm going to ask, Victoria, since you're the managing director of that team, how do you feel about that question? Do you feel that's the same thing, or what's your observation of that? VICTORIA: I think Charity is, like, spot on because it does depend on the type of organization that you're working in, the hierarchy, and who gets priority over budget and things like that. And so the interesting thought for me coming from federal IT organizations into more commercial and startup organizations is that there is a little bit of a disconnect. And we started to ask our designers and developers like, "Well, have you thought much about, like, what happens when this fails?" [laughs] And especially -- CHARITY: Great question. VICTORIA: Yeah, like, when you're dealing with, like, healthcare startups or with bank startups and really thinking through all the ways it could go wrong. Is it a new pathway? Which I think is exciting for a lot of people. And I'm curious, too, Charity, like with Honeycomb, was there things that surprised you in your journey of discovery about, you know, building a company about observability and what people wanted out of this space? CHARITY: Oh my goodness. [laughs] Was anything not a surprise? I mean, [laughs] yeah, absolutely. You're a director of what team? VICTORIA: I'm a managing director of our Mission Control team. CHARITY: Oooh. VICTORIA: Which is our platform engineering, and DevOps, and SRE team. CHARITY: Now, does your platform engineering team have product managers? VICTORIA: I think it might be me. [laughs] CHARITY: Aha. VICTORIA: It might be me. And we have a team lead, and our CTO is actually our acting development director. So he's really leading the development of that project platform. CHARITY: When I was in New York the last couple of days, I just gave a talk at KubeCon about the Perils, Pitfalls, and Pratfalls of Platform Engineering, just talking about all of the ways that platform teams accidentally steer themselves into the ditch. One of the biggest mistakes that people make in that situation is not running the platform team like a product team, you know, having a sort of, like, if we build it, they will come sort of a mentality towards the platform that they're building internally for their engineers, and not doing the things like, you know, discovery or finding out like, am I really building, you know, the most important thing, you know, that people need right now? And it's like, I didn't learn those skills as an engineer. Like, in the infrastructure land, we didn't learn how to work with product people. We didn't learn how to work with designers. And I feel like the biggest piece of career advice that I give, you know, people like me now, is learn how to work with product and like a product org. I'm curious, like, what you're observing in your realm when it comes to this stuff. Like, how much like a product org do you work? VICTORIA: Oh, I agree 100%. So I've actually been interested in applying our platform project to the thoughtbot Incubator Program. [laughs] CHARITY: Mmm. VICTORIA: So they have this method for doing market strategy, and user interviews, and all of that...exactly what you're saying, like, run it like a product. So I want them to help me with it. [laughs] CHARITY: Nice. VICTORIA: Yes, because I am also a managing director, and so we're managing a team and building business. And we also have this product or this open-source project, really. It's not...we don't necessarily want to be prescriptive with how we, as thoughtbot, tell people how to build their platforms. So with every client, we do a deep dive to see how is their dev team actually working? What are the pain points? What are the things we can do based on, like, you know, this collection of tools and knowledge that we have on what's worked for past clients that makes the most sense for them? So, in that way, I think it is very customer-focused [laughs], right? And that's the motto we want to keep with. And I have been on other project teams where we just try to reproduce what worked for one client and to make that a product. And it doesn't always work [laughs] because of what you're saying. Like, you have to really...and especially, I think that just the diversity of the systems that we are building and have been built is kind of, like, breathtaking [laughs], you know. CHARITY: Yeah. [chuckles] VICTORIA: I'm sure you have some familiarity with that. CHARITY: [laughs] VICTORIA: But what did you really find in the market that worked for you right away, like, was, like, the problem that you were able to solve and start building within your business? CHARITY: We did everything all wrong. So I had had this experience at Facebook, which, you know, at Parse, you know, we had all these reliability issues because of the architecture. What we were building was just fundamentally...as soon as any customer got big, like, they would take up all the resources in this shared, you know, tenancy thing, and the whole platform would go down. And it was so frustrating. And we were working on a rewrite and everything. Like, it was professionally humiliating for me as a reliability engineer to have a platform this bad at reliability. And part of the issue was that you know, we had a million mobile apps, and it was a different app every time, different application...the iTunes Store, like, top five or something. And so the previous generation of tools and strategies like building dashboards and doing retros and being like, well, I'll make a dashboard so that I can find this problem next time immediately, like, just went out the window. Like, none of them would work because they were always about the last battle. And it was always something new. And at one point, we started getting some datasets into this tool at Facebook called Scuba. It was butt ugly. Like, it was aggressively hostile to users. But it let us do one thing really well, which was slice and dice high cardinality dimensions in near real-time. And having the ability to do that to, like, break down by user ID, which is not possible with, you know, I don't know how familiar -- I'll briefly describe high cardinality. So imagine you have a collection of 100 million users. And the highest possible cardinality would be a unique ID because, you know, social security number, very high cardinality. And something much lower cardinality would be like inches of height. And all of metrics and dashboards are oriented around low cardinality dimensions. If you have more than a couple hundred hosts, you can no longer tag your metrics with a host ID. It just falls apart. So being able to break down by, like, you know, one of a million app IDs. It took...the amount of time it took for us to identify and find these brand-new problems, it dropped like a rock, like, from hours of opening it. We never even solved a lot of the problems that we saw. We just recovered. We moved on [laughs] with our day, dropped from that to, like, seconds or minutes. Like, it wasn't even an engineering problem anymore. It was like a support problem, you know, you just go click, click, click, click, click, oh, there it is. Just follow the trail of breadcrumbs. That made such an impression on me. And when I was leaving, I was just like, I can't go back to not having something like this. I was so much less powerful as an engineer. It's just, like, it's unthinkable. So when we started Honeycomb, we were just, like, we went hands down, and we started building. We didn't want to write a database. We had to write a database because there was nothing out there that could do this. And we spent the first year or two not even really talking to customers. When we did talk to customers, I would tell our engineers to ignore their feedback [laughs] because they were all telling us they wanted better metrics. And we're like, no, we're not doing metrics. The first thing that we found we could kind of connect to real problems that people were looking for was that it was high cardinality. There were a few, not many; there were a few engineers out there Googling for high cardinality metrics. And those engineers found us and became our earliest customers because we were able to do breathtaking...from their perspective, they were like, we've been told this is impossible. We've been told that this can't be done. Things like Intercom was able to start tagging other requests with, like, app ID and customer ID. And immediately started noticing things like, oh, this database that we were just about to have to, like, spend six months sharding and extending, oh, it turns out 80% of the queries in flight to this database are all coming from one customer who is paying us $200 a month, so maybe we shouldn't [laughs] do that engineering labor. Maybe we should just, you know, throttle this guy who is only paying us 200 bucks a month. Or just all these things you can't actually see until you can use this very, very special tool. And then once you can see that... So, like, our first customers became rabid fans and vouched for us to investors, and this still blows people's minds to this day. It's an incredibly difficult thing to explain and describe to people, but once they see it on their own data, it clicks because everybody's run into this problem before, and it's really frustrating. VICTORIA: Yeah, that's super interesting and a great example to illustrate that point of just, like, not really knowing what's going on in your system. And, you know, you mentioned just, like, certainly at scale, that's when you really, really need to have [laughs] data and insight into your systems. CHARITY: Yeah. VICTORIA: But one question I get a lot is, like, at what scale do you actually need to start worrying about SRE? [laughs] Which -- CHARITY: SRE? VICTORIA: Yeah, I'll let you answer that. Yeah, site reliability or even things like...like, everything under that umbrella like observability, like, you know, putting in monitoring and tracing and all this stuff. Sometimes people are just like, well, when do I actually have to care? [laughs] CHARITY: I recognize this is, you know, coming from somebody who does this for a living, so, like, people can write it off all they want. But, like, the idea of developing without observability is just sad to me, like, from day one. This is not a tax. It's not something that slows you down or makes your lives worse. It's something that makes your lives better from day one. It helps you move more quickly, with more confidence. It helps you not make as many mistakes. It helps you... Like, most people are used to interacting with their systems, which are just like flaming hairballs under their bed. Nobody has ever understood these systems. They certainly don't understand them. And every day, they ship more code that they don't understand, create systems that they've never understood. And then an alarm goes off, and everybody just, like, braces for impact because they don't understand them. This is not the inevitable end state of computing. It doesn't have to be like this. You can have systems that are well-understood, that are tractable, that you could...it's just...it's so sad to me that people are like, oh God, when do I have to add telemetry? And I'm just like, how do you write software without telemetry? How do you have any confidence that the work you're doing is what you thought you were doing? You know, I just... And, of course, if you're waiting to tack it on later, of course, it's not going to be as useful because you're trying to add telemetry for stuff you were writing weeks, or months, or years ago. The time to add it is while you're writing it. No one is ever going to understand your software as well as you do the moment that you're writing it. That's when you know your original intent. You know what you're trying to do. You know why you're trying to do it. You know what you tried that didn't work. You know, ultimately, what the most valuable pieces of data are. Why wouldn't you leave little breadcrumbs for yourself so that future you can find them? You know, it's like...I just feel like this entire mental shift it can become just as much of a habit as like commenting your code or adding, you know, commenting in your pull request, you know. It becomes second nature, and reaching for it becomes second nature. You should have in your body a feeling of I'm not done until you've looked at your telemetry in production. That's the first moment that you can tell yourself, ah, yes, it probably does what I think it does, right? So, like, this question it makes me sad. It gets me a little worked up because I feel like it's such a symptom of people who I know what their jobs are like based on that question, and it's not as good as it could be. Their jobs are much sadder and more confusing than it could be if they had a slightly different approach to telemetry. That's the observability bit. But about SRE, very few ops engineers start companies, it seems, when I did, you know, I was one of three founding members. And the first thing I did was, of course, spin up an infrastructure and set up CI/CD and all this stuff. And I'm, like, feeling less useful than the others but, you know, doing my part. But that stuff that I spun up, we didn't have to hire an SRE for years, and when we did, it was pretty optional. And this is a system, you know, things trickle down, right? Doing things right from the beginning and having them be clear and well-understood, and efficient, we were able to do so much with so few people. You know, we were landing, you know, hundreds of thousand-dollar deals with people who thought we had hundreds of employees. We had 12 engineers for the first almost five years, just 12 engineers. But, like, almost all of the energy that they put into the world went into moving the business forward, not fighting with the system, or thrashing the system, or trying to figure out bugs, or trying to track down things that were just, like, impossible to figure out. We waste so much time as engineers by trying to add this stuff in later. So the actual answer to your question is, like, if you aren't lucky enough to have an ops co-founder, is as soon as you have real users. You know, I've made a career out of basically being the first engineer to join from infrastructure when the software engineers are starting to have real customers. Like, at Parse, they brought me in when they were about to do their alpha release. And they're like, whoa, okay, I guess we better have someone who knows how to run things. And I came in, and I spent the next, you know, year or so just cleaning up shit that they had done, which wasn't terrible. But, you know, they just didn't really know what they were doing. So I kind of had to undo everything, redo it. And just the earlier, the better, right? It will pay off. Now, that said, there is a real risk of over-engineering early. Companies they don't fail because they innovated too quickly; let's put it that way. They fail because they couldn't focus. They couldn't connect with their customers. They couldn't do all these things. And so you really do want to do just enough to get you to the next place so that you can put most of your effort into making product for your customers. But yeah, it's so much easier to set yourself up with auto-deployment so that every CI/CD run automatically deploys your code to production and just maintain as you grow. That is so easy compared to trying to take, you know, a long, slow, you know, leaky deploy process and turn it into one that could auto-deploy safely after every commit. So yeah, do it early. And then maintain is the easiest way in the world to do this stuff. Mid-Roll Ad: As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. Take your business online with design‑driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. WILL: Correct me if I'm wrong, I think you said Facebook and mobile. Do you have, not experience with mobile but do you...does Honeycomb do anything in the mobile space? Because I feel like that portion is probably the most complicated for mobile, like, dealing with iOS and Android and everything that they're asking for. So... CHARITY: We don't have mobile stuff at Honeycomb. Parse was a mobile Backend as a Service. So I went straight from doing all mobile all the time to doing no mobile at all. I also went from doing databases all the time to doing, you know...it's good career advice typically to find a niche and then stay in it, and I have not followed that advice. [laughter] I've just jumped from...as soon as I'm good at something, I start doing something else. WILL: Let me ask you this, how come you don't see more mobile SRE or help in that area? CHARITY: I think that you see lots of SREs for mobile apps, but they're on the back-end side. They're on the server side. So it's just not as visible. But even if you've got, like, a stack that's entirely serverless, you still need SRE. But I think that the model is really shifting. You know, it used to be you hired an SRE team or an ops team to carry the pager for you and to take the alerts and to, like, buffer everything, and nowadays, that's not the expectation. That's not what good companies do. You know, they set up systems for their software engineers to own their code in production. But they need help because they're not experts in this, and that's where SRE types come in. Is that your experience? WILL: Yeah, for the most part. Yeah, that is. CHARITY: Yeah, I think that's very healthy. VICTORIA: And I agree with that as well. And I'm going to take that clip of your reaction to that question about when you should start doing [laughter] observability and just play for everybody whenever someone asks [laughs] me that. I'm like, here's the answer. That's great. CHARITY: I think a good metaphor for that is like, if you're buying a house and taking out a loan, the more of a down payment you can put down upfront, the lower that your monthly payments are going to be for the rest of your...you amortize that out over the next 20-30 years. The more you can do that, the better your life is going to be because interest rates are a bitch. VICTORIA: It makes sense. And yeah, like, to your point earlier about when people actually do start to care about it is usually after something has broken in a traumatic way that can be really bad for your clients and, like, your legal [laughter] stance -- CHARITY: That's true. VICTORIA: As a company. CHARITY: Facing stuff, yeah, is where people usually start to think about it. But, like, the less visible part, and I think almost the more important part is what it does to your velocity and your ability to execute internally. When you have a good, clean system that is well-tended that, you know, where the amount of time between when you're writing the code and when the code is in production, and you're looking at...when that is short and tight, like, no more than a couple of hours, like, it's a different job than if it takes you, like, days or weeks to deploy. Your changes get bashed up with other people's. And, you know, like, you enter, like, the software development death spiral where, you know, it takes a while. So your diffs get even bigger, so code review takes even longer, so it takes even longer. And then your changes are all getting bashed up. And, you know, now you need a team to run deploys and releases. And now you need an SRE team to do the firefighting. And, like, your systems are...the bigger it gets, the more complicated it gets, the more you're spending time just waiting on each other or switching contexts. You ever, like, see an app and been like, oh, that's a cool app? I wonder...they have 800 engineers at that company. And you're just like, what the hell are they all doing? Like, seriously, how does it take that many engineers to build this admittedly nice little product? I guarantee you it's because their internal hygiene is just terrible. It takes them too long to deploy things. They've forgotten what they've written by the time it's out, so nobody ever goes and looks at it. So it's just like, it's becoming a hairball under your bed. Nobody's looking at it. It's becoming more and more mysterious to you. Like, I have a rule of thumb which there's no mathematical science behind this, just experience. But it's a rule of thumb that says that if it takes you, you know, on the order of, say, a couple of hours tops to deploy your software, if it takes you that many engineers to build and own that product, well, if your deploys take on the order of days instead of hours, it will take you twice as many people [chuckles] to build and support that product. And if it takes you weeks to deploy that product, it will take you twice as many again; if anything, that is an underestimate because it actually goes up exponentially, not linearly. But, like, we are so wasteful when it comes to people's time. It is so much easier for managers to go, uh, we're overloaded. Let's hire more people. For some reason, you can always get headcount when you can't actually get the discipline to say no to things or the people to work on internal tools to, like, shrink that gap between when you've written it and when it's live. And just the waste, it just spirals out of control, man, and it's not good. And, you know, it should be such a fun, creative, fulfilling job where you spend your day solving puzzles for money and moving the business materially forward every day. And instead, how much of our time do we just sit here, like, twiddling our thumbs and waiting for the build to finish or waiting for code review [laughs] to get turned around? Or, you know, swapping projects and, like, trying to page all that context in your brain? Like, it's absurd, and this is not that hard of a problem to fix. VICTORIA: Engineering should be fun, and it should be dangerous. That's what [laughs] I'm getting out of this -- CHARITY: It should be fun, and it should be dangerous. I love that. VICTORIA: Fun and dangerous. I like it. [laughs] And speaking of danger, I mean, maybe it's not dangerous, but what does success really look like for you at Honeycomb in the next six months or even in the next five years? CHARITY: I find it much more easier to answer what failure would look like. VICTORIA: You can answer that too if you like. [laughs] CHARITY: [laughs] What would success look like? I mean, obviously, I have no desire to ever go through another acquisition, and I don't want to go out of business. So it'd be nice not to do either of those things, which means since we've taken VC money, IPO would be nice eventually. But, like, ultimately, like, what motivates Christine and me and our entire company really is just, you know, we're engineers. We've felt this pain. We have seen that the world can be better. [laughs] We really just want to help, you know, move engineering into the current decade. I feel like there are so many teams out there who hear me talk about this stuff. And they listen wistfully, and they're like, yeah, and they roll their eyes. They're like, yeah, you work in Silicon Valley, or yeah, but you work at a startup, or yeah...they have all these reasons why they don't get nice things. We're just not good enough engineers is the one that breaks my heart the most because it's not true. Like, it has nothing to do...it has almost nothing to do with how good of an engineer you are. You have to be so much better of an engineer to deal with a giant hairball than with software that gets deployed, you know, within the hour that you can just go look at and see if it's working or not. I want this to go mainstream. I want people...I want engineers to just have a better time at work. And I want people to succeed at what they're doing. And just...the more we can bring that kind of change to more and more people, the more successful I will feel. VICTORIA: I really like that. And I think it's great. And it also makes me think I find that people who work in the DevOps space have a certain type of mentality sometimes, [laughs] like, it's about the greater community and, like, just making being at work better. And I also think it maybe makes you more willing to admit your failures [laughs] like you were earlier, right? CHARITY: Probably. VICTORIA: That's part of the culture. It's like, well, we messed up. [laughs] We broke stuff, and we're going to learn from it. CHARITY: It's healthy. I'm trying to institute a rule where at all hands when we're doing different organizations giving an update every two weeks, where we talk two-thirds about our successes and things that worked great and one-third about things that just didn't work. Like, I think we could all stand to talk about our failures a lot more. VICTORIA: Yeah, makes it a lot less scary, I think [laughs], right? CHARITY: Yeah, yeah. It democratizes the feeling, and it genuinely...it makes me happy. It's like, that didn't work, great. Now we know not to do it. Of the infinite number of things that we could try, now we know something for real. I think it's exciting. And, I don't know, I think it's funny when things fail. And I think that if we can just laugh about it together... You know, in every engineering org that I've ever worked at, out of all the teams, the ops types teams have always been the ones that are the most tightly bonded. They have this real, like, Band of Brothers type of sentiment. And I think it's because, you know, we've historically endured most of the pain. [laughs] But, like, that sense of, like, it's us against the system, that there is hilarity in failure. And, at the end of the day, we're all just monkeys, like, poking at electrical sockets is, I think...I think it's healthy. [laughs] WILL: That's really neat. I love it. This is one of my favorite questions. What advice would you give yourself if you could go back in time? CHARITY: I don't know. I think I'd just give myself a thumbs up and go; it's going to be all right. I don't know; I wouldn't... I don't think that I would try to alter the time continuum [laughs] in any way. But I had a lot of anxiety when I was younger about going to hell and all this stuff. And so I think...but anything I said to my future self, I wouldn't have believed anyway. So yeah, I respectfully decline the offer. VICTORIA: That's fair. I mean, I think about that a lot too actually, like, I sometimes think like, well, if I could go back to myself a year ago and just -- CHARITY: Yeah. I would look at me like I was stupid. [laughter] VICTORIA: That makes sense. It reminds me a little bit about what you said, though, like, doing SRE and everything upfront or the observability pieces and building it correctly in a way you can deploy fastly is like a gift to your future self. [laughs] CHARITY: Yes, it is, with a bow. Yes, exactly. VICTORIA: There you go. Well, all right. I think we are about ready to wrap up. Is there anything you would like to promote specifically? CHARITY: We just launched this really cool little thing at Honeycomb. And you won't often hear me say the words cool and AI in proximity to each other, but we just launched this really dope little thing. It's a tool for using natural language to ask questions of your telemetry. So, if you just deployed something and you want to know, like, what's slow or did anything change, you can just ask it using English, and it does a ChatGPT thing and generates the right graphs for you. It's pretty sweet. VICTORIA: That's really cool. So, if you have Honeycomb set up and working in your system and then you can just ask the little chatbot, "Hey, what's going on here?" CHARITY: Yeah. What's the slowest endpoint? And it'll just tell you, which is great because I feel like I do not think graphically at all. My brain just really doesn't. So I have never been the person who's, like, creating dashboards or graphs. My friend Ben Hartshorne works with me, and he'll make the dashboards. And then I get up in the morning, and I bookmark them. And so we're sort of symbiotic. But everyone can tweak a query, right? Once you have something that you know is, like, within spitting distance as the data you want, anyone can tweak it, but composing is really hard. So I feel like this really helps you get over that initial hurdle of, like, er, what do I break down by? What do I group by? What are the field names? You just ask it the question, and then you've got to click, click, click, and, like, get exactly what you want out of it. I think it's, like, a game changer. VICTORIA: That sounds extremely cool. And we will certainly link to it in our show notes today. Thank you so much for being with us and spending the time, Charity. CHARITY: Yeah, this was really fun. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you could find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Charity Majors.Sponsored By:thoughtbot: As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.Support Giant Robots Smashing Into Other Giant Robots

Irina Nazarova is CEO of Evil Martians, a product development consultancy that works with startups and established businesses while creating open-source products and services. Victoria talks to Irina about getting a sense of what people are interested in learning about or what kind of problems they have, how consulting and product development complement each other, and of course, the question on everyone's minds: Is Evil Martians really evil? 😈 Evil Martians Follow Evil Martians on GitHub, Twitter, Instagram, or LinkedIn. Follow Irina Nazarova on LinkedIn, or Twitter. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with us today is Irina Nazarova, CEO at Evil Martians, a product development consultancy that works with startups and established businesses while also creating open-source-based products and services. Irina, thanks for joining us. IRINA: Hey, thank you for having me. VICTORIA: You're welcome. Tell me a little bit about what's going on in your world this week. IRINA: So I just returned from Rails SaaS in Athens, which was pretty incredible. It's a smaller conference, but it has amazing vibes, amazing people. And, like, I just loved it there in Athens. VICTORIA: Mmm. IRINA: And, yeah, I wonder how your experience was? Because I know you also went to Japan, right? VICTORIA: Yeah, I went to RubyKaigi in Matsumoto last month. It was a good community, and to get to travel to a cool place was really fun. So I feel really lucky that I was able to get to go. Did you eat a lot of Greek food while you were there? IRINA: Not that much. I was a speaker. So I was a bit nervous, and I skipped some meals. [chuckles] VICTORIA: Oh no. [laughs] IRINA: Just to prepare. But we did have a super nice dinner with Xavier Noria, and, well, we had some Greek wine. All right, we did that. VICTORIA: That sounds fabulous. And, you know, I was going to ask you...one of my questions was about the conferences you've been attending because we met at RailsConf in Atlanta. And I saw you went to Rails SaaS and maybe some other ones recently. So, how has that been for you overall? IRINA: It's amazing. I think, like, all the conferences are suddenly back. And the energy is different than maybe pre-COVID. I didn't really attend many conferences pre-COVID, but I did attend some. Now people are so eager to sort of reconnect. And me, I think, I feel like I'm only starting to make those connections. And it's so emotional to meet people that I only see on Twitter, but meeting them in person is magical for some reason. So this is what's happening. Like, to me, I'm just amazed by all this energy and support coming from the community towards many people, like, towards each other. VICTORIA: I also feel amazed when I meet someone I've followed on Twitter for a long time but in real life [laughs]. I'm like, wow. That was Aaron Patterson for me. I was like, oh, this is someone I followed on Twitter a long time ago because I thought they were funny. And now they're a speaker at this conference I'm at [laughs], which is really nice. And do the conferences help you connect more to potential clients? Or what's, like, the business reason for attending all of these events? IRINA: Good question. So I'm not expecting any, you know, direct sales to happen at the conferences. But, for example, I get to understand the clients, maybe better, the potential clients. And I get to connect with the existing clients, again, on a different level. So, if you have a client at the conference and you have a chance to see them in person, which we never do, and you as well, right? thoughtbot, you guys are not meeting the clients, like, the same thing. But if you get to meet even, like, some people from the client team, it's amazing. You can have a different type of connection. And I met an engineer from our past client at RailsConf, and it was something incredible. I didn't expect him to react like the way he did. You know, the moment he realized that I am from Evil Martians, like, his facial expressions just immediately transformed into a big smile. And he said such warm words about the things we did, something like two or three years ago. I mean, you don't have anything better than that in this industry, right? There's nothing better than this sincere, you know, gratitude from a client. [chuckles] It's just amazing. VICTORIA: I can relate to that, being from thoughtbot and attending Rails and RubyConfs. It is a nice feeling that people know the company or they know some open-source projects or some training materials we put out. And they're so grateful. [laughs] And I've only been at thoughtbot for a year. So, for me, I'm like, you're welcome. [laughs] I haven't done those things, but I will. And I will build on, you know, I think it also helps you kind of get a sense for what people are interested in learning about or what kind of problems they have. So, tell me more about that with Evil Martians. What is it all about? IRINA: I think we share this feeling where we want to give back. You and me we both felt something where people were grateful for something the companies did. But now I feel I need to give back somehow, and maybe I'm sure you feel the same. And you're doing this podcast, which is important for the community and other things. You're open-sourcing the tooling. So both of our companies are actually sharing a lot of, like, philosophies, attitude, where it's great to be in the community that we're in. So we also do something where we have some products like AnyCable. And it's interesting to talk to people using those products because we do have a much larger number of users of our products, you know, compared to our consulting clients, that's for sure. So the chances of meeting the users of AnyCable or, like, other products are pretty high at the conference, at Rails Conference. VICTORIA: Right. So I find it similar that you have the consultancy side and you have the product development side. Take it a little bit further back to just where it all started with Evil Martians. Are you really evil? It's [laughs] [inaudible 05:47] question. IRINA: Absolutely. We are. I mean, and we come from Mars. VICTORIA: [laughs] IRINA: Yeah, that's also true. It's a nice planet. We just make you think that it's a bad planet. VICTORIA: Yeah, to keep you away. You don't want too many tourists. IRINA: Yeah. VICTORIA: Mm-hmm, that makes sense. [laughs] But I understand you all started as a consultancy from back-end engineers. And then, it grew into what it is today and having several side projects. So, how does the consultancy side and the product development side complement each other? IRINA: Yeah, so the way it works, it's like a cycle of things where we work for startups like thoughtbot. And then, we work with 20 to 30 product engineering teams every year. And we notice which tools could be helpful for those teams and maybe would be helpful for us in those teams. So we're trying to enhance, improve our own productivity and the productivity of our clients. And that's how, I think, many of our open-source projects started. Some of the open-source projects, I think, started, you know, for fun, for some other reasons. But many of them actually were useful in the client projects. So then we are passionate about this. So, for example, we have PostCSS. PostCSS was built by our Head of Front End, Andrey Sitnik. And it has something, like, 30,000, you know, GitHub Stars. And Autoprefixer, which is a PostCSS plugin, has, like, 20,000 GitHub Stars. So they are huge. I mean, it's not just about the stars; half of the internet is actually using PostCSS. But PostCSS is popular, but we didn't turn it into a product. We are not commercializing it at all. But some of the other tools, let's call them tools, that we open-sourced, we could then envision how we could commercialize them. And the way it works is there are actually several strategies. For imgproxy, for example, we sell a paid version. But for AnyCable, which is another tool, we also sell a pro version. But we also earn consulting kind of get consulting clients come in for product development related to AnyCable, let's say. This is how AnyCable also helps us get consulting clients in a major way. And then we ended up building a lot of tools for engineers. And then because we work with this type of tools, now we also have many developer tools clients. So we started specializing on developer tools. It's about half of the sort of revenue. And now it's getting even more interesting; I think, because we don't just build tools for engineers, you know, ourselves as side projects, like I said. But also, our consultant work is essentially the same thing. It's often commercial open source like Teleport, or HTTPie, tools for engineers. This is exciting, I think, because now we can use this, you know, sort of connection with a type of audience, with a type of customer base, like the engineers, and we can leverage this experience in our consulting work, which is even better. And then we do open source with the products. They help us get consultant revenue, and then the experience on those projects helps us improve our products, and get product ideas, and get the first users for those products, et cetera. So it's like consulting helps product development, in our case. VICTORIA: So, to play that back a little bit, it's almost like a cycle where they feed into each other where your engineers as they're working are also kind of, like, the customers who would be using the developer tools that you want to build. So you have some market research there. And then, you know, it all feeds back into each other so that the customers who are using your products are also likely to need your consultant services. [laughs] So that's a nice flow. I wonder if there's anything surprising that came out during that kind of discovery process for product, for developer tools when you were first starting out, anything that you thought this is a tool maybe we think people are going to use. But then what was the reality, or [chuckles] what surprising things happened? IRINA: A lot of things. But I think the main one that is sort of important is that there's a difference between open source and product a product. And the differences...okay, the way I'm trying to explain it is, like, between...it's, like, the difference between you and your friend from another industry. Let's say you have a friend who is a microbiologist or something. And they are smart, right? They are smart in their own field. But if you give them your open source and ask them to take a look and you expect them to learn about it, to want to learn about it, they won't do it. They might use your product based on your open source, though, if it is easy if they know how to benefit from the product. So what I'm trying to say is, turning open source into a product is like essentially building a new product, a new thing where the customer base is different because you want it to be wider. But you don't want them to learn about your open source and to be passionate about your technology. You want them to be passionate about the value they want to get, you know, about something they're building. So it's a shift in mentality that you got to make to make it work. And pretty often, the people that collaborate with us in the open source are, you know, super different from the people who become our users. And users are great, but, you know, they don't want to learn too much about the internals and how it's supposed to work. They just want to click a button, and pay some money, and get the result, get the value from this. And, I don't know, it sounds simple. But it's actually a major shift in thinking about your product for you as an author of a tool, of a technology, of something. VICTORIA: That's a really interesting distinction to make. So, when you're building open-source projects, you want to really invite people in and get people excited about how the whole tool works and how they can use it in their projects. And then, on the product side, you're wanting to make it super easy [chuckles] for people and make sure they're focusing on the value of what they're getting out of this product instead of having to, like, understand all the little details. Is that right? IRINA: Yeah, exactly, exactly. VICTORIA: That makes sense. And is there any product in particular that you're really excited about or you see a lot of growth in with Evil Martians? IRINA: Yeah, I will talk about AnyCable. I will say AnyCable because I am personally involved in its development. So we did it with Vladimir Dementyev, the author. And the exciting part about AnyCable is the types of products and the types of functionality that can be built using AnyCable. So these are all kind of collaboration features, collaboration tools. The simplest are just the chats within your Rails application. And we have a lot of medical and healthcare applications that want to keep the data, the chat, you know, data on their own servers without sending them to some SaaSs. That's why they use AnyCable. But also, we have other tools that use AnyCable to build collaboration. And we've helped some clients build this at Evil Martians using AnyCable, leveraging AnyCable. But it's exciting when, like, other companies do it themselves sort of without us just by using the product. So I don't like it when I don't have the collaboration within a tool that you're using with someone else together. So I remember we were using something like a tool to create a service, and me and Vladimir we're using it simultaneously, you know, rewriting our edits all the time. And it was so frustrating because they didn't support collaboration in this tool. So the thing you do when you don't support the collaboration is just that every user, every player, is just rewriting what the other player did without saving. So it's, like, so frustrating, yeah. So I like it that our product is helping people fix this problem. VICTORIA: Right. And to kind of summarize a little bit about what AnyCable does, is that it allows you to build Ruby on Rails apps and use any WebSocket server in any language as a replacement for the Ruby server. Is that accurate? IRINA: Not exactly. So AnyCable is a server that stands next to your Ruby on Rails app and handles all the WebSockets. It's written in Go. It's super fast, super efficient, and scales efficiently. That's the most important part. Because you don't have to scale your entire Ruby on Rails app, your, you know, entire logic just to support the real-time load. So you only scale this small, efficient app, and it handles all the load and super quickly. And it also supports HTML over WebSockets updates, I mean, Hotwire and stuff. So it helps you scale your Hotwire updates as well. So it's much faster than Ruby. It's much more efficient in terms of scaling. And, yeah, it's bidirectional, meaning that the server sends...by the way, it's just a drop-in replacement for ActionCable. So we're using ActionCable protocol. So we have the channels and stuff. So this means that we can send data, you know, from server broadcasts, the data from server, but we can also send the data from any client. And one of the use cases for Any Cable, by the way, is different devices that send their coordinates or some other data in real-time. Like, we have some kind of cars sending us GPS data. It's cute, I think that you keep your business logic in your Ruby and Rails app, which is the place to write your business logic, which is the best place to write it. But the infrastructure and all the sort of delivery guarantees, order guarantees, all this kind of infrastructure layer is serviced, is handled by AnyCable, so you don't have to worry about it. VICTORIA: That makes sense. Thank you for expanding on that. The interesting part for you on that is just to have this be able to be more collaborative, right? So we're working on this whole project together and not siloing into our different groups and building bespoke products to solve this problem. IRINA: Yeah, I mean, I like collaborative UI as a norm, as something that has to be there. So, for any work-related tools...and we do work remotely now over the internet somehow. So I think any tool for any professionals has to have a collaborative regime, right? Support for collaboration because people want to work together. And that's the only way to work, I think. VICTORIA: Yeah, that makes sense to me. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. VICTORIA: Was there anything that's happened in the last few years maybe, or even that's come up in that discovery process as you're building these products that made you shift your strategic direction for Evil Martians? IRINA: Yeah. I was initially looking for the right strategy regarding the products at Evil Martians. And what I mean is we were always passionate about building our own products, building our own products for engineers. We were always passionate about this. But, in order to make it work...and I think it works now, in a way, because we just had our other product, imgproxy, incorporate. And they raised a round of external financing, which is a win, I think. I mean, they have a long, long way to go. And we will try to support them. But, for me, it's important that we had an internal project, you know, graduate us and move beyond Evil Martians. So something that I changed, I think, in the company together with the founders, for sure, is how we structure the incentives related to the internal products. What I'm trying to say is this: many companies that have an internal project will be looking to own those products. That's what I'm trying to say. And we are not looking for that. What we're looking for is to have a founding team for a product and to make sure they have the majority of shares, that they are the owners of this product. Because we know that building a product is such a long way, and it's a difficult journey. And it takes years and decades to build them into something large, or profitable, or sustainable. So we want the people who are actually doing this to be properly motivated. So something that I convinced the founders to do was to keep the share of Evil Martian's [inaudible 20:40] in those new products at a low level, which may sound counterintuitive for some businessmen, you know, for some owners of the business. They will say, "Well, this was something that was built internally in this company. So this is fully owned by this company." And I agree. Like, from the legal standpoint, this is correct. But it doesn't make much sense if you think about it because you don't want to own, you know, 95% or 100% in something that its worth is zero or even, you know, a negative amount when you keep investing, and you're not getting any returns. But rather, you'd have 10%, 15%, 20% in something large and profitable. And that was the change, I think, where we said, look, we'll be investing in products in a certain way to make sure that the founders, you know, the team of authors is properly motivated. So they own this, and Evil Martians is just the first investor. VICTORIA: That makes a lot of sense because I have been a part of companies where they wanted to reproduce and productize what they'd built for a client and make that something they owned. And I think you use an interesting approach to motivate people to contribute to a project like that by sharing the ownership. [laughs] And that makes a lot of sense to me. I'm curious, based on your response to that last question, how would you describe your leadership style as a CEO? IRINA: There's no one way to be the CEO, I guess. So every person approaches this differently. And it's not that easy to be the CEO after the founder, [laughs] so, when, you know, the founder who was the CEO before hands you the job. It's not that easy. But I had trust and support. And I still have it, for sure, the trust and support from the founders and from the team because I've been with the company for four years already when I moved into this role. And I think of my style as, first of all, you know, listen to the team, collect the information first. I imagine that I act like a consultant from a management consulting firm, but I didn't work in a management consulting firm. I didn't know how they actually work. But I imagine this is how they work. They sort of speak with every person on the team, and they try to figure out the blockers, the problems, and the aspirations of the team. And then they try to find how to improve, you know, the collective utility, the utility of the group, how to improve the situation, maybe not for every single person but for the majority of them. And this was my initial approach and fixing some, maybe, problems in the company. But I would also try to come up with my own ideas as well for sure. But I rely on the team a lot. So what I also did is I started relying on my leadership team much more than maybe the founder and CEO. So I'm relying on Andrey Sitnik, Head of Front End, on Roman Shamin, on Vladimir Dementyev, and other people, Victoria, Victoria Melnikova, our Head of New Business. And I'm relying on many people heavily, heavily. And my goal is to make sure they see where we want to go and they each can contribute in a certain way. And I ask them how they can contribute. I'm not telling them how to do this, right? I trust their judgment in their area of expertise. But mostly, I just ask about what they can do. And this is how we work together. VICTORIA: I like that. I like how you're really connecting with your team and finding out their strengths, and their struggles, and what they think should do. And then it's how do you enable them as a CEO to achieve this greater vision that you all want to work towards? So I really like that. What would you say is maybe your biggest challenge that you're facing right now? IRINA: I actually challenged myself to become more publicly, sort of effective. [laughs] That's why I'm here, for example. So I realized we do have amazing engineers, amazing designers who are out there, you know, doing podcasts, doing open-source, building technologies, writing on our blog, doing all of this. And I realized that, well, I should do my part as well. And this was one of the goals for this year. The other goal, the other challenge is so complicated that I'm not sure [laughs] I'm ready to talk about it yet. So some of the things I'm trying to do, to be honest, I'm not sure if I can do them at all, [laughs] and that's the problem. So thoughtbot has the Incubator Program, right? And this means that thoughtbot presumably gets equity in those new businesses that people build with thoughtbot's help and guidance. And we're not doing this, but we're doing something else, also trying to make sure we have shares in the amazing businesses that we help grow and they become successful. And we're doing everything we can to make sure they are successful. And I want this company to have a share in the success of our clients, our products, all of that together. VICTORIA: It would probably contribute to motivation, which is another factor you mentioned previously about. IRINA: Yep. VICTORIA: You know, right? [laughs] IRINA: Absolutely, yeah. VICTORIA: Right. We're all going to work a lot harder and collaborate a lot more together. That makes sense. IRINA: Yeah, it also means, yeah, that it makes sense to have a share at Evil Martians. You know, as a part of the company, as an employee, you're getting a share in the company. But as you know, when you are a consulting company, it's sort of a complicated question, actually. If you're a startup and you are granting equity-like stock options to your team, this makes sense because if the company goes, you know, grows and goes public; those shares become something super valuable, like, super cool. But we are not looking to grow our consulting company into something huge. That's for sure. It won't be possible, right? We are operating at this small niche, that's for sure. And we don't have that many amazing engineers, consultants, and it's so hard to hire them. So, anyways, we're not looking to grow that much, although we are growing. And this means that shares in our company do not mean the same thing as the shares in our clients. But if we participate in the success of our clients, then it sort of changes the whole motivation on our own team. This is what I'm thinking about. VICTORIA: Yeah, that's a great question. And I wonder, to build on that, what success really looks like six months from now, or even, like, five years from now for Evil Martians. IRINA: I want us to be recognized as the best consultancy, consulting company for developer tools, products. I know maybe it sounds ambitious, but this is what we are super passionate about. This is where we are accumulating the expertise. And this means I want people to think Evil Martians when they build a product for engineers. I want them to think about us and reach out to us. But also, I want us to build a number of successful products, commercial products for engineers, which is a huge challenge. Like, doing both it's not easy, that's for sure. But let's see. VICTORIA: Yeah, it's good to be ambitious. And I love that journey for you. I'm excited to follow along. I wonder what advice you would give yourself if you could travel back in time to maybe when you first joined [chuckles] Evil Martians. IRINA: I'd say, first of all, be confident in sharing your opinion because, well, especially for females, we do have a lot of, like, impostor syndrome when joining a tech company, for sure. But it's not just females, right? When you dig deeper, you realize that most people have impostor syndrome, regardless of their gender, background, et cetera. No one is this perfect image of a perfect engineer. It's just no one, really. And everyone has that. And I want everyone who is joining the new company or maybe entering tech as the industry to be confident in sharing their opinions, well, humbly, respectfully but for sure. But don't shy away from asking the questions and from owning your agenda. That's what I want to say. Like, the first year and maybe two years, I didn't own my own agenda. I didn't try to control the sort of to-do lists, the things I'm doing. And later, when I started thinking, you know, critically about my own priorities, I realized that I could bring more value by doing something else, maybe not, you know, not 100% different things but maybe by adding 20% to the mix and removing something that is actually not urgent, not important, you know, just randomly added to...just randomly asked by someone, [chuckles] you know. So I think own your own agenda. Be more confident and look forward. Try to imagine the future that you want. And, for some reason, it works. I don't know how, but it does work. So you start imagining the future. You share it with the team; you discuss it with the team. And this is the magic of the teamwork. Maybe you cannot do it alone, but as a team, so much more is possible. VICTORIA: I love that. And thank you so much for sharing. I'm sure there's maybe a future Irina out there [laughs] who's hearing that advice now and can take it into their work. What if your younger self could travel forward in time, and what advice would they give you now? IRINA: Oh, this is funny. Maybe my younger self would say that I should spend more time with my friends. [laughs] That's what I should do, yeah. VICTORIA: That's never bad advice, I think. I love it. Okay. So, is there anything that you would like to promote? IRINA: This is not tech-related at all. But I want to ask the listeners to donate to the non-profit organizations supporting people in Ukraine because people are suffering in Ukraine. And there was this explosion of the dam, and the floods, everything. And it's never been as important as it is now to support the non-profits. And I can suggest the Nova Ukraine non-profit organization. It's an American organization, but they send all their money to the local initiatives. So it's a great way to support a good cause. VICTORIA: Yes, wonderful, and we can include that into the show notes. Thank you so much for joining me today, Irina. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you could email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Irina Nazarova.Sponsored By:thoughtbot: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devopsSupport Giant Robots Smashing Into Other Giant Robots

Neetu Rajpal is the CTO of Oscar Health. Oscar aims to make a healthier life accessible and affordable for all by refactoring healthcare to make great care cost less. Chad talks to Neetu about working for a relatively new insurance company, reorganizing its structure by getting people into the right positions, and how incorporating large language models and generative AI is an inflection point that will help move things forward. Oscar Health Follow Oscar Health on Facebook, YouTube, Twitter, Instagram, or LinkedIn. Follow Neetu Rajpal on LinkedIn, or Twitter. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: CHAD: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Chad Pytel. And with me today is Neetu Rajpal, the CTO of Oscar Health. Neetu, thank you so much for joining me. NEETU: It's great to be here. Thank you very much for having me. CHAD: I want to talk about your role at Oscar Health, and your history, and everything that you've done. But everyone listening might not be familiar with Oscar Health. So let's start there; what is Oscar Health? NEETU: Yes. Oscar Health is a health insurance company. We sell health insurance, primarily on the ACA marketplace across 20 different states in the U.S. We have just over a million members. So we basically sell health insurance to people. One of the big, unique things about Oscar Health has been it's a very relatively new insurance company. So it's only been around for about ten years. And it was founded as a pretty standard tech startup. We've built all of the infrastructure for acquiring supporting members and providers, and brokers in-house. So we're fully cloud-native, distributed systems hosted on AWS and GCP with a giant data lake that supports all of our workflows. And this is a pretty unique integrated solution in terms of health insurance companies. So we're very much a tech-focused health insurance company. I've been at Oscar for about three and a half years. I came to Oscar not from a healthcare background but just really mission-oriented and motivated to go help something in the healthcare space. I've spent most of my career building software, first at Microsoft and then at Conductor and WeWork. And I'm really excited to be here. It's really, really rewarding to be at a company that's serving primarily an underserved market in the ACA space. CHAD: Well, I suppose full disclosure is in order. Oscar and thoughtbot have been working together for a long time now, actually, with Oscar as a client of ours. So I appreciate you joining us on the show, and I appreciate you working with us over the years. I think we worked...we started working with Oscar maybe when you were just in one or two states. And so, how have you handled that growth? And I think that's one of the complexities of the insurance space, right? Is every location is different in important ways. NEETU: Yeah. Actually, it seems like Oscar and thoughtbot have worked longer than Oscar and myself. CHAD: [laughs] NEETU: So I think that's a pretty exciting, interesting statistic. And even during my time, it's been a great experience working with thoughtbot. One of the big premise Oscar had was to build software that was segregated enough and isolated enough but composable enough that you could, in fact, bundle the full healthcare tech stack and then bundle it back together as you needed with configuration and scale it as you needed with, like, smart built-in scalability. And I think our ability to grow into multiple states and multiple counties has been, like, a good proof point of the fact that you can, in fact, do that. In most cases, adding a new state is sometimes, at least from the tech perspective, from the software perspective is a combination of identifying the right configuration settings, mapping it to the features, and then just configuring the software to be able to support that new service area that we've just added. And that, I think, has been, like, a huge value add in terms of being able to add new locations to serve our members, add new providers, add new contracts. And our premise of building stuff or to unbundle and then bundle it back together as needed has really proven out a lot. CHAD: I assume there have been some challenges along the way. What do you think have been among the biggest? NEETU: I think the challenges have been an interesting combination of just learning the insurance business landscape then building software that aligns with it. So each county you might go into, each state you might go into, have its own set of regulatory requirements, have its own set of, like, reimbursement requirements, have its own set of, like, plan requirements, and these are...as a new insurance company, I think along the way, we really did have to learn a lot of these things and sometimes by trial and error and that, you know, it's a pretty sometimes a long cycle with insurance. So that has been interesting and challenging. CHAD: So not necessarily a technical problem but more, like, even just figuring out what it should...how it should work. NEETU: Yeah. I think definitely the business problem has been interesting on the technical side. So I started at Oscar about three and a half years ago. And my first questions as I was going through the interview process were, "Like, I don't understand why you built all of this stuff in-house, like, why aren't you just [inaudible 05:18]?" And those were rather naive questions to be asking a tech-focused insurance company. Many years ago, when Oscar chose to use Elasticsearch, it wasn't a BAA-compliant solution. So you couldn't actually use a managed version of Elasticsearch. So we ended up hosting our own Elasticsearch cluster. We were one of the first or the first few people to actually sign a BAA with AWS a long time ago. So, technically speaking, I think the challenges have been around you don't always have the same set of tools available to you; at least, that used to be the case. This is rapidly declining rapidly. The availability of tools is almost the same now. And two, the ecosystem that you live in. We still definitely have a service that has easy availability to a fax machine, and I think there are a few companies that are able to say that. But it's also the ecosystem that you live in, that you're trying to bring along with yourself, and also ecosystem you're using to support and build the tech stack. Both of those things have been rather interesting. In terms of actually building the software, that's, like, pretty standard regular set of software challenges. CHAD: How big is the Oscar engineering team at this point? NEETU: Oscar engineering team has fluctuated between 300 and 400 people over the past few years. I think we're about 350 or so right now. CHAD: Generally speaking, how is the team organized to perform at that scale? NEETU: I am actually a pretty big believer in first building a tech strategy that is tied to the business strategy before building the org structure. So, even at the Oscar engineering and tech team org structure, it has probably fluctuated quite a bit based on what the business needed. As of right now, we have dedicated folks that are aligned along individual set of audiences that we are supporting. So we have a group of people who focuses primarily on the members and the member applications. We have a group of folks who focuses primarily on the provider and all the needs of the providers. And then we have a group of people maybe focused on just growth in general. And that could be growth through enrollments with brokers, enrollments without brokers, direct exchanges, or even some of our +Oscar business work. So we've tried to, at this moment, align ourselves with the audience that we're serving. And, of course, like, no engineering team is purely vertical or purely horizontal. So we also have an infrastructure platform team that supports all of the areas. CHAD: Do people sort of opt in, or are their roles advertised in each of those places? Or, as you reorganize into those structures, have you seen ways that work successfully in terms of getting people into the right position? NEETU: Like, at the larger level in terms of the audience space, there tends to be pretty standard set of roles. As you might imagine, when the companies are smaller, there's a lot of investment or need for really, truly full-stack developers and full-stack engineers. As we've grown larger, there is a bit of specialization towards either the front-end portion of the house or the back-end portion of the house. And we do have roles posted, and the roles some of them concentrate more towards the front-end tech. Some of them concentrate more towards distributed computing, and back end, and data engineering roles. And some concentrate more towards infrastructure engineering. And, as the teams always get bigger, there tend to also be, like, the supporting functions around technical product management and technical program management that are also part of the equation at the moment. We do post all of these roles in those terms, with clarity around what the expectations are. As we re-org, we always prioritize internal candidates. We have a big enough team. People like to work on different set of problems and happy to align passions with our business needs because that tends to work out really, really well. CHAD: Well, there's a reason why I'm asking about this particularly for you because one of the things that stood out to me about your background was the length of time that you were at Microsoft and the movement that you did between a variety of different roles across the organization. So that's an experience that you bring to the table. Was that something that you did intentionally? NEETU: Yeah. I was at Microsoft for 18 years. And I think every couple of years, I did a new thing. And while I would like to very much say, yeah, I totally figured out that I wanted to be an engineer... CHAD: [laughs] NEETU: And then a product manager, and then, you know, an engineer again, or then a product manager again, or a leadership role again, or even the stack as in work on small APIs or work on full enterprise-grade products or cloud...I would like to very much say those were very thought through, you know, clearly pre-planned career moves; they were not. And particularly, in my case, they were very much I chased problems. And I would get very obsessed or interested in a particular problem. And then, I would go dive deep into that problem and aim to go solve it. And by the time I had figured it out and solved it, there was always a new problem. And this was the wonderful promise of Microsoft where, you know, it is so large, and there are so many different ways to think about different problems, or different ways you can bring software to market, or problems in the world you can solve with it, that I particularly took full advantage of it. And that hasn't really changed in terms of how the rest of my career post-Microsoft has gone, either. Every couple of years, I find myself in a space that is completely scary, completely new, completely different. For me, that tends to be my happy place, to be working on super difficult things that are very scary. Mid-Roll Ad: When starting a new project, we understand that you want to make the right choices in technology, features, and investment but that you don’t have all year to do extended research. In just a few weeks, thoughtbot's Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprint. CHAD: It does sound like even though you might not have some grand plan, [chuckles] you are driven to seek out challenges. NEETU: Yeah. I heard something really, really long time ago that kind of has stuck with me always, which is don't let your curiosity die. So, if you are curious, don't just let it shy away; just indulge in it. That's how you're always moving forward. For me, that's been a big theme as in, I really, really enjoy always learning. Always finding myself not to be the smartest person in the room is really, really great. And always moving forward and pushing hard, and solving bigger and bigger problems. CHAD: So, when you were deciding to join Oscar Health, how concerned were you with the particulars of the individual position that you were applying for? Or was it more, like, I've identified this space and this problem that I want to be a part of? NEETU: Yeah, that's a really, really great question. And I think it's one of the ones that when I mentor people, I tell them about as well, which is, I had a role with Conductor that was this head of R&D, CTO, and CPO, and a very traditional ladder style path to the next step or something along those lines or bigger. But I personally am not motivated by titles as much as I am about potential impact I can have. My walk into healthcare out of MarTech or out of just, like, platform was very personal in terms of I have a healthcare story. Everybody really has a healthcare story. And I wanted to go do something in this space, utilize all of the skills that I already have, and then try to push the space forward. And so, when I joined Oscar, I was not really that motivated by what the title was going to be. I was really looking for is, is there going to be an opportunity to have an impact? And is there going to be space for me to have impact? Am I going to be surrounded by a group of people who I can have impact with? That was the primary concern. And I did join Oscar as a VP of engineering. And that didn't last very long. Within the next year and a half, I was already promoted to CTO in that role. And each one of those steps was very much motivated by will I actually be able to have impact? Will I be empowered to have impact? Was I equipped to have an impact? And was I going to learn a lot in that role? Those were my primary motivators. And that's always been the case. It's also a hard-won lesson. Like, when I had my first kid, it was a really difficult time, personally. I had really bad postpartum depression. I had really hard time dealing with what is going to happen with my career, and I had to take a step back. And as somebody who was, like, super ambitious and wanted to go straight up, that was a really challenging thing to do. And that was a long time ago, and I've been able to rebuild, quote, unquote, "rebuild" my career back multiple times over. So it's actually been, like, a hard-won lesson where it doesn't kind of matter what part of the rocket ship you have a seat on, as long as you have the seat on the rocket ship. And by rocket ship, I wish I was only talking about stock price; I'm not. I'm just talking about the ability to have impact. If I can be in this right group and I can have a voice, then it didn't matter what my title was. CHAD: Yeah, thank you for sharing. And I think it feels like the pace of change accelerates. But in growing organizations, so much changes all of the time. So what you are doing...or the roles that exist will change as well. And the other thing...I often get asked by clients, "Should we be hiring a VP of engineering or a CTO?" I'm like, the definition of those roles varies so much between company, and team size, and everything. It's like; it really is difficult to answer that question because it is so different. It all depends on the needs of the organization. NEETU: Yeah. I've done both of those roles, at least twice each time, twice now. And I've personally discovered that A, those roles don't really have a defined, like, there is no clear definition for either one of those roles. The other thing that I think is more important is I don't think the organizations know what they want out of those roles most of the times, either. In my experience so far, VP of engineering is a little bit easier to define because it has a very heavy management component to it. And so I've ended up just defining those roles for myself every time, and so far, so good. And the way I define those roles is very much, like, a CTO role is a half-business half-technical role. It's the role where you understand the business strategy and turn it into a tech strategy that supports the business strategy and pushes the business forward, and acts as the competitive advantage for the business. And your role is, in fact, to be the person who takes tech and applies it to pushing the business forward. That's one direction. And the other direction, it is the role to take the business strategy and translate into technical terms so that you can bring and coalesce your whole team's motivation around it and bring the whole team around it. And I definitely find this very much at Oscar, where most people who join Oscar engineering and Oscar tech they all come motivated outside of Oscar already to help push the industry forward in one way or another. So actually keeping that motivation in the right place all the time with authenticity and truth about what it is, how we're pushing the business forward. And helping the business move forward is an extremely valuable skill. So, from my perspective, the tech role is definitely half-business, half-tech with some variable sprinkling of management attached to it, and I think that's the CTO role. And the VP of engineering was very heavily bent towards management, I think, yeah. CHAD: Well, so in that CTO role, we'll often be faced with understanding how industry changes, or new technology, or whatever can help the business. Obviously, we have a big one happening right now with artificial intelligence or large language models and machine learning. I have a couple of questions around this area. But, like, is there something in particular with that that you're either thinking about now in terms of Oscar or have already incorporated? NEETU: Yeah. I think large language models and generative AI, in general, is definitely an inflection point. And I think it's an inflection point that is going to help push so many things forward. And I think healthcare is very interestingly poised towards pushing in that direction. There is everything from, like, shortage of providers or shortage of mental health providers to just a large availability of data in the healthcare space that can help discover things that may not be the easiest to discover through humans looking at it. So I think there's a huge opportunity. I also think it needs, like, a bit of cautious evaluation. We are dealing with something that you can't break, so you can't move fast and break things when you're dealing with people. But there are interesting use cases where you could use generative AI and have it maybe not make a decision for a person but assist the provider to make a decision. Or you can use it in areas, at least in healthcare space, where there is a lot of inefficiency because of too much to do. And you can actually optimize a whole bunch of that. So examples could be, you know, there's the standard examples of chatbots as in, is this doctor part of my network? Can I have an appointment with this doctor? Can I have an appointment and a prior auth with this doctor immediately? Like, those are, I think, a little bit more accessible use cases. And Oscar, also, we're exploring and figuring out which one of those makes most sense for us in our business. And there's tons of excitement and tons of, like, thought being put behind it. As of right now, I probably can't say all the things that we're working on at the moment. But yes, absolutely, this is a very big deal. CHAD: So, speaking more generally around exploring new ideas, you mentioned at Conductor, you were in an R&D role combined...like, is there strategies that you've seen that work particularly well for doing research and development within an organization, exploring new ideas, figuring things out? NEETU: Yeah. It definitely depends on which portion or which portion of the maturity stack you're on. If you're building software that is going to be sold to enterprises, you have to have some version of a promise of a date, and then you have to keep your promise. So, if you're selling enterprise software, you have to be predictable because your partners on the other side are relying on you. And you can't actually get predictability without having enough stability in your team, and enough stability in your roadmaps, and enough stability in your tech environment [inaudible 22:30] So that you can figure out what you're going to build, you can figure out where you're going to build, and how you're going to build it. You can figure out what teams and resources you're going to allocate to it. And you can also have some confidence that when you're ready to send code out to production, there is some automated CI/CD system that is, like, going to help you make sure that the number of errors that you are sending out into the world is as few as possible. And that superpower of being able to, like, churn out code and features and products like a machine on a pretty regular basis has the potential downside of not being able to disrupt yourself. And I think there are definitely a couple of strategies to do that. One of them is to allocate enough space by filling it with P2s as opposed to everything being a P0, that if you were to, like, displace the P2s with something that is new and available now, then you're going to be okay because you can live without the P2s. We had to have enough of those. There is also the whole skunk works model, which I think works pretty well. I think it does need to be set up carefully so that you're not, like, destroying the motivation of everybody in the team. You do have the opportunity to do the skunkworks model. And, like, the generating ideas portion, we do this at Oscar, and I think this is also done elsewhere. We have pretty regular hackathons that are dedicated amounts of time, and we put them on the schedule. And, during that time, we just go explore and dream and go build other things. And we build it collaboratively with the rest of the business. And there are definitely still, like, stories of things that were developed in a hackathon that served us really well for years on end. And I don't think that's ever going to change. But anything that is, like, a real solid enterprise production stuff probably needs a dedicated skunkworks something or the other so you can...I don't think it's a bad thing to have solid schedules. I think it's a really huge superpower to have solid schedules. I do think you have to have the discipline to be able to disrupt yourself; otherwise, somebody else will. CHAD: Right. And so figuring out a structure, you can do that. And, like you said, you know, you don't want to ruin the morale or the excitement of the entire organization where people say, like, "Well, it's not my job," you know, or, "I wish I could work on this, but it's this team's." And you're not set up to capture that individual person's excitement over generative AI, for example, who is the one who's actually going to make it happen. And you're squashing that because they're not, quote, unquote, "supposed to work on it." I think that's a really difficult balance to strike. NEETU: Yeah, I think it is. But I don't know; there are very few things in the healthcare space that anybody does that is easy. CHAD: Yeah, that's a good point. Now that you've been in the role, well, at Oscar for a few years, what's next? What are the things that, like, you feel like are sort of motivating you each day you come to work? NEETU: Oscar is in the ACA space, which serves primarily underserved communities. There have been, like, some recent examples of where people had to shutter doors in the ACA space. So the fact that we're still around and the fact that we're successful, like, we don't take that for granted. It's a really valuable thing to be able to survive in this market and to be able to grow. We launched a mission-driven tech-focused company ten years ago based on the belief that you could build your own tech stack and be successful in a very tightly controlled market. And I think this is the year that we actually had to just, like, really prove out the use case. So, this year, Oscar is 100% focused on being insure co profitable. And once we finish proving that out, next year, we're going to prove out that it is... Holdco can be profitable, which is all of our tech stack, in addition to all of our insurance business. And I'm very, very much looking forward to Oscar being successful this year in the mission, where I think it's just proving out that you can build a successful business and ACA-powered by your own tech stack. And not compromising on the outcomes for our members is really valuable and keeps me very motivated. And then, looking at the future, looking at being able to be 100% full company profitable and potentially selling our software for others so they could also bring this efficiency to their businesses is extremely motivating for me. And, as of right now, this is what the whole company is focused on. And we're all super excited about it. CHAD: Yeah, oftentimes, having a clear goal that everyone knows about and is working on can be really empowering for an organization, even if it's hard. NEETU: Yeah. Like I said before, I think almost everybody I've interacted with at Oscar didn't come to Oscar, assuming it was going to be easy. They came to Oscar with full knowledge that it was going to be hard, but they were going to try anyway. So we are so close. CHAD: Yeah. And, you know, that's one of the things that, at thoughtbot, we skew to working with clients that do positive things for the world, that deserve to exist for precisely this reason, is when you have a positive purpose in your organization, it makes working hard easier, [laughs] or solving big problems easier because you know that you're going to have a positive impact when you do. NEETU: Yeah. The personal healthcare story was a motivating factor towards going to go do something that was, like, going to be, like, positive for the world. I wish I could say, yes, I'm going to solve all of healthcare's problems and [inaudible 29:02] not that way. CHAD: Yeah. Well, that was actually what I was going to ask you about next is that's the thing about healthcare. And I've seen people almost get demoralized for it because you actually can't solve every problem. It's really difficult to solve all of healthcare. So, how do you sort of exist within that environment and not get demotivated? NEETU: I think the more you dig into the problem, the more you realize how interconnected the way in, like, society, politics, money, power, and tech it really is. And it seems like if you try to solve the whole thing, it almost feels like you're going to boil the whole ocean. And it is definitely a blocker from even trying. And, for me, it was just like, does that mean I stop? Do I apply the boy scout rule of, like, just trying to leave it better off, a whole lot better off, as much possible better off than I found it? I could do that. Or I could just go do something completely different. But there is no guarantee it's going to be as motivating or potentially as impacting. So, for me, it's very much about, like, if I could make even small changes, I know they'll be part of a greater whole. So I will just try to make those small changes because, alternatively, I may be neutral for the world at most. CHAD: Well, Neetu, thank you so much for stopping by and sharing with us. I really appreciate it. NEETU: Thank you very much for having me. It's been a great conversation. CHAD: If folks want to get in touch with you or follow along, where are the best places for them to do that? NEETU: I am easy to find on LinkedIn. I do have a Twitter account, but I'm not very active. It's @Nee2D2, and I look forward to hearing from people. CHAD: Awesome. You can subscribe to the show and find notes for this episode, along with a complete transcript, at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you could find me on Mastodon @cpytel@thoughtbot.social. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening, and see you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Neetu Rajpal.Sponsored By:thoughtbot: When starting a new project, we understand that you want to make the right choices in technology, features, and investment, but that you don’t have all year to do extended research. In just a few weeks, thoughtbot’s Discovery Sprints deliver a user-centered product journey, a clickable prototype or Proof of Concept, and key market insights from focused user research. We’ll help you to identify the primary user flow, decide which framework should be used to bring it to life, and set a firm estimate on future development efforts. Maximize impact and minimize risk with a validated roadmap for your new product. Get started at: tbot.io/sprintSupport Giant Robots Smashing Into Other Giant Robots

Aaron Torres and Ala Shiban are from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. Victoria talks to Aaron and Ala about the Klotho engine, Klotho the CLI tool, and InfraCopilot and how they work together to help enable developer teams to iterate on applications and features quickly. Klotho Infrastructure Copilot Follow Klotho on Github, Discord, Twitter, or LinkedIn. Follow Aaron Torres on LinkedIn, or Twitter. Follow Ala Shiban on LinkedIn or Twitter. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido. And with me today is Aaron Torres and Ala Shiban from Klotho, which powers Infrastructure Copilot, the most advanced infrastructure design tool that understands how to define, connect, and scale your infrastructure-as-code. Aaron and Ala, thank you for joining me. ALA: Thank you for having us. AARON: Yeah, thank you very much. VICTORIA: Well, great. I wanted to just start with a little bit of a icebreaker; maybe tell me a little bit more about what the weather is like where you're currently at. AARON: So I'm in St. Louis, Missouri. Right now, it is definitely...it feels like summer finally. So we're getting some nice, warm days and clear skies. ALA: And I'm in LA. And it's gloomier than I would like compared to what it's been in the last few years. But I'll take it if this means we're getting closer to summer. VICTORIA: Right. And I'm not too far from you, Ala, in San Diego, and it's a little chillier than I would prefer as well. But that's what we get for living close to the beach. So there's always trade-offs. Well, wonderful. I'm so excited to talk to you about your product here today. Let me start with a question about, let's say, I'm a non-technical founder, and I've just heard about your product. What's your pitch to someone in that position on the value of your tool? ALA: For somebody who isn't technical, I would say you can enable your team, your developer team, to quickly iterate on their applications or features and let InfraCopilot and Klotho take care of taking that application or features and deploy them and getting them running on the cloud. VICTORIA: Okay. So maybe I've been thinking about having to hire an AWS engineer or someone who's an infrastructure engineer. I could consider getting a tool like Klotho and Infrastructure Copilot to allow my developers to take on more of that responsibility themselves. ALA: Absolutely. VICTORIA: Gotcha. Okay, well, great. So let me ask about how did it all get started? What was the impetus that set you on this journey ALA: Both Aaron and I used to work at Riot Games, and I used to lead the cloud services org at Riot. I had about 50 people, 40 engineers, as part of a larger 120-person org, infrastructure platform org, which was tasked with building the platform that runs League of Legends, VALORANT, for 200 million people all around the world, in China. Full DevOps mode for Riot developers and full ops mode for running in China. It took us three years, a lot of effort. And by the time we were done, it was already legacy, and that seemed broken to me. We were already getting started to do another round of upgrades and iterations. At that point, I decided to leave. But I couldn't let go of this feeling that we shouldn't have had to spend so many years solving a problem only for it not to be solved. And based on research and conversations, it was clear that this was an industry-wide phenomena. And so I went about trying to figure out why that happens and then how we can solve it, and that's how Klotho came about. VICTORIA: That's so interesting. And I've certainly been a part of similar situations where you spend so much time solving a big problem and infrastructure only to get to the end of it and realize now you have a whole nother set of problems. [laughs] And you get upgrade. And they've also invented new ways of doing things in the cloud that you want to be able to take advantage of. So you had that time with Riot Games and League of Legends and building this globally responsive infrastructure. What lessons learned did you take from that into building Klotho and building your product, Infrastructure Copilot? AARON: We learned a bunch of things. One of the more difficult problems to solve isn't technical at all; it's organizational and understanding how the organization flows and how the different teams interact with each other. So we really endeavor to solve that problem. I mean, our product is a technical product, but it is meant to help bridge that gulf and make that problem a little bit easier as well. Otherwise, yeah, exactly to your point, part of the problem with these migrations is that new technology comes along. And there's definitely a feeling of when you hire new developers, they are excited about the new thing, and there's other reasons as well. But you get this kind of natural, eternal migration going to the newer technology. VICTORIA: That makes sense. And you bring up a great point on some of the issues, not being technical but organizational. And when I look at a lot of infrastructure-as-code tools, when we get to security, I wonder how it fits in with the organizational requirements for security, right? Like, you have to have defined groups who have defined access to different levels and have the tools in place to be able to manage identities in your organization. So I'm curious how that fits into what you built with Klotho and the Infrastructure Copilot. ALA: The way we think about infrastructure is as a set of intents or things that developers, and operators, cloud engineers, infrastructure engineers are trying to satisfy or to do. So you have tasks. You're trying to build a solution. You're trying to build an architecture or add something to it. And organizations have constraints, whether it's their own Terraform, or their own ruleset, or security expectations, or compliance expectations. And the way we look at this dynamic is those rules are encoded in a way that Klotho, which is a cloud compiler, it has the ability to reason about both the application and the infrastructure-as-code and enforce or at least warn about mismatches between the constraints that the organization sets, and what the developer or operator are trying to do, or the intent that is being described high level or low level within the tools. And then that is reflected both visually and in code and in the infrastructure-as-code, one or more. And so it's very much rooted in how the entire set of technologies and product and tools are designed. VICTORIA: Got it. So do you see the tool will be more fit for the market of larger development shops who maybe have existing infrastructure but want to experiment with a different way of managing it for their developers? ALA: It depends. So because we went about solving the problem rather than just building a specific vertical or a specific stack piece, we try to only play in this space of intelligent editing and intelligent understanding of the alignment between infrastructure and code. And so you could, as a developer, effectively with Klotho, write a plain application and have it be running in the cloud without knowing anything in the underlying cloud systems. It will set up storage, and persistence, and security, and secrets. All those elements are easily accessible within the code itself. It can also work in the context of a company where the infrastructure or platform team have set those rules and guidance within the tools. And then, developers can continue working the way they expect to work, either in code or in the infrastructure-as-code layer. And it would still allow them to do the same intents that they want only within that sandbox. Or if they can't be satisfied because they're trying to do something that isn't allowed, they have a mechanism of, one, knowing that but also asking, in our case, InfraCopilot to help it reshape what it's doing, what they're doing into the sandbox and the trade-offs that that brings in. VICTORIA: Got it. So you can both start from scratch and start a brand new application using it, or you can integrate it with your existing rules and systems and everything that already exists. ALA: Exactly. VICTORIA: Gotcha. Yeah, I think one interesting thing we've found with very new founders who are building their application for the first time is that there are some essential things, like, they don't even have an identity store like a Google [laughs] or Microsoft Azure Directory. So starting to work in the cloud, there are some basic elements you have to set up first that's a little bit of a barrier. So it sounds like what you're saying with Klotho is that you wouldn't necessarily have those same issues. Or how would you get that initial, like, cloud accounts set up? AARON: Yeah. So, for the situation where you're bootstrapping everything from scratch, you've done nothing; we haven't invested much in setting up the initial accounts. But assuming you get to the point where you have AWS credentials, and you're able to hit the AWS API using the CLI, that's sort of where we can take over. So, yeah, like, I would say right now, as a business, it's definitely where the value is coming is going to be these mid-sized companies. But for that scenario specifically, bootstrapping and starting something from scratch, if you have that initial setup in place, it's one of the fastest ways to go from a concept to something running in the cloud. ALA: And if you think about the two tools that we're building, there's Klotho, which InfraCopilot...or the Klotho engine, which Klotho the CLI tool uses and InfraCopilot uses. The Klotho engine is responsible for the intelligence. It knows how to translate things like I want a web API that talks to DynamoDB. And it will literally create everything or modify everything that is needed to give you that and plug in your code. You can also say things in a much higher level degree, which things like I want a lambda which handles 10,000 users. And I want it to be lowest latency talking to an RDS Instance or to a Postgres database. And what that would do is, in our side, in the Klotho engine, we understand that there needs to be a VPC and subnets, and spin up RDS, and connect an RDS proxy. Because for connection pooling with lambda specifically, you need one to scale to that degree of scale. And so that is the intelligence that is built into the Klotho engine if you want to start from the infrastructure. If you want to start from code, all you have to do is bring in the Redis instance, the Redis SDK, and, let's say, your favorite web framework, and just add the annotations or the metadata that says, I want this web framework to be exposed to the internet, and I want this Redis to be persisted in the cloud. And you run Klotho. And what comes out the other end is the cloud version that does that for you. And it's one command away from getting it to run. VICTORIA: So that's interesting how the two tools work together and how a developer might be able to get things spun up quickly on the cloud without having to know the details of each particular AWS service. And reading through your docs, it sounds like once you have something working in the cloud, then you'll also get automated recommendations on how to improve it for cost and reliability. Is that right? ALA: That's where we're headed. VICTORIA: Gotcha. I'm curious; for Aaron, it sounds like there is more in that organizational challenges that you alluded to earlier. So you want to be able to deliver this capability to developers. But what barriers have you found organizationally to getting this done? AARON: So I'm going to speak specifically on infrastructure here because I think this is one of the biggest ones we've seen. But typically, when you get to a larger-sized company, we'll call it a mid-sized company with, you know, a couple hundred engineers or more, you get to the point where it doesn't make sense for every team to own their entire vertical. And so you want to really put the cloud knowledge into a central team. And so you tend to build either a platform team, or an infrastructure team, or a cloud team who sort of owns how cloud resources are provisioned, which ones they support, et cetera. And so, really, some of the friction I'm talking about is the friction between that team and developer teams who really just want to write their application and get going quickly. But you don't have to fall within the boundaries set by that central team. To give, like, a real concrete example of that, if you wanted to prototype a new technology, like, let's say that some new database technology came out and you wanted to use it, it's a very coordinated effort between both teams in terms of the roadmap. Like, the infrastructure team needs to get on that roadmap, that they need to make a sandbox and how that's going to work. The code team needs to make an application to test it. And the whole thing requires a lot more communication than just tech. VICTORIA: Yeah, no, I've been part of kind of one of those classic DevOps problems. It's where now you've built the ops team and the dev team, [laughs] and now you're back to those coordination issues that you had before. So, if I were a dev using Klotho or the infrastructure-as-code copilot, I would theoretically have access to any AWS sandbox account. And I could just spin up whatever I wanted [laughs] within the limits that could be defined by your security team or by your, you know, I'm sure there's someone who's setting a limit on the size of databases you could spin up for fun. Does that sound right? AARON: Yeah, that's totally right. And in addition to just limits, it's also policies. So a good example is maybe in production for databases, you have a data retention policy. And you have something like we need to keep three months of backups for this amount of time. We want to make sure that if someone spins up a production database from any of those app teams, that they will follow their company policy there and not accidentally, like, lose data where it has to be maintained for some reason. ALA: That's an important distinction where we have our own set of, you know, best practice or rules that are followed roughly in the industry. But also, the key here is that the infrastructure central teams in every company can describe the different rulesets and guidelines, guardrails within the company on what developers can do, not only in low-level descriptions like instance sizes or how much something is, whether it's Spot Instances always or not in production versus dev. But also be able to teach the system when a developer says, "I want a database," spin up a Postgres database with this configuration that is wired to the larger application that they have. Or, if I want to run a service, then it spins up the correct elements and configures them to work, let's say, Kubernetes pods, or lambdas, or a combination based on what the company has described as the right way for that company to do things. And so it gives flexibility to not know the specific details but still get the company's specific way of doing them. And the key here is that we're trying to codify the communication patterns that do happen, and they need to happen if there's no tools to facilitate it between the infrastructure platform team and the feature teams. Only in this case, we try and capture that in a way that the central teams can define it. And the developers on feature teams can consume it without having as much friction. VICTORIA: So that will be different than, like, an infrastructure team that's putting out everything in Terraform and doing pull requests based off GitHub repository to that. It makes it a little more easier to read, and understand, and share the updates and changes. AARON: Right. And also, I mean, so, like, the thing you're describing of, like, the central team, having Terraform tends to be, like, these golden templates. Like they say, "If you want to make a database, here's your database template." And then you get a lot of interesting issues like drift, where maybe some teams are using the old versions of the templates, and they're not picking up the new changes. And how do you kind of reconcile all that? So it is meant to help with all of those things. VICTORIA: That makes a lot of sense. And I'm curious, what questions came up in the customer discovery process for this product that surprised you? ALA: I think there's one...I don't know that it was a question, but I think there was...So, when we started with Klotho, Klotho has the ability to enable a code-first approach, which means that you give the tool to developers as the infrastructure or platform team, or if you're a smaller shop, then you can just use Klotho directly. You set the rules on what's allowed or what's not allowed, and then developers can work very freely. They can describe very succinctly how to turn a plain object, SDK, et cetera, how to build larger architectures very quickly with a few annotations that we describe and that give cloud powers. We had always thought that some teams will feel that this encroaches on their jobs. We've heard from people on infra, you know, platform teams, "This is amazing. But this is my job." And so, one of our hypotheses was that we are encroaching into what they see as their responsibility. And we built more and more mechanisms that would clean up that interface and give them the ability to control more so they can free themselves up, just like most automations that happen in the world, to do more things. What happened later surprised us. And by having a few or several more discoveries, we found out that the feeling isn't a fear of the tool replacing their job. The fear or worry is that the tool will make their jobs boring, what is left of the job be boring, and nobody wants to go to work and not have cool and fun things to do. And because I think we all, on a certain degree, believe that, you know, if we take away some of the work that we're doing, we'll find something higher level and harder to solve, but until that exists in people's minds, there's nothing there. And therefore, they're left with whatever they don't want to do or didn't want to do. And so that's where we tried to take a step back from all the intelligence the Klotho engine provides through that code-first Klotho. And we built out focusing on one of the pillars in the tech to create InfraCopilot, which helps with keeping or making the things that we already do much simpler but also in a way that maintains and does it in a fun way. VICTORIA: That makes sense because my understanding of where to use AI and where to use machine learning for best purposes is to automate those, like, repetitive, boring tasks and allow people to focus on the creative and more interesting work, right? ALA: Yes and no. The interesting bit about our approach to ML is that we don't actually use machine learning or ChatGPT for any of the intelligence layers, meaning we don't ask ChatGPT to generate Terraform or any kind of GPT model to analyze a certain aspect of the infrastructure. That is all deterministic and happens in the Klotho engine. That is the uniqueness of why this always works rather than if GPT happened to get it right. What we use ML for is the ability to parse the intent. So we actually use it as a language model to parse the intent from what the user is trying to convey, meaning I want a lambda with an API gateway. What we get back from our use of ML is the user has asked for a lambda, an AWS lambda, and API gateway and that they be connected. That is the only thing we get back. And that is fed into the Klotho engine. And then, we do the intelligence to translate that to an actual architecture. VICTORIA: That's a really cool way to use natural language processing to build cloud infrastructure. MID-ROLL AD: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneurs. VICTORIA: I'm curious; you said you're already working on some issues about being able to suggest improvements for cost reduction and efficiencies. What else is on your roadmap for what's coming up next? AARON: So there's a bunch of things in the long-term roadmap. And I'll say that, like, in the short term, it's much more about just expanding the breadth of what we support. If you think about just generating all the different permutations and types of infrastructure, it's, like, a huge matrix problem. Like, there's many, many dimensions that you could go in. And if you add an extra cloud or you add an extra capability, it expands everything. So you can imagine, like, testing it to make sure things work, and everything becomes very complicated. So, really, a lot of what we're doing is still foundational and trying to just increase the breadth, make the intent processing more intelligent, make the other bits work. And then one of the areas right now is for our initial release of the product; we chose to use Discord as our interface for the chatbot. And the reason for that is because it gives us a lot of benefits of having sort of the community built in and the engagement built in where we can actually talk with users and try and understand what they're doing. However, we really have a lot of UI changes and expansions that we'd like to do. And even from some of our early demo material, we have things like being able to right-click and being able to configure your lambda directly from the UI. So there's a lot of areas there that we can expand into an intent, too, once we get sort of the foundational stuff done, as an example. The intelligence bit is a much bigger process, like, there's a lot of things to unpack there. So I won't talk about it too much. But if we were to just talk about the most simple things, it'd be setting up alerts somehow and then feeding into our system that, like, we're hitting those alerts, and we have to make modifications. A good example of that would be, like, configuring auto scaling on an instance for [inaudible 22:17]. So we can get some of those benefits now. The bigger vision of what we want to do with optimization requires a lot more exploration and also the ability to look at what's happening to your application while it's running in the cloud. ALA: Let me maybe shed a bit more light on the problems we're trying to solve and where we're headed. When it comes to optimization, to truly optimize a cloud application, you have to reason about it on the application level rather than on the one service level. To do that, we have to be able to look at the application as an application. And today, there's a multi-repo approach to building cloud applications. So one of the future work that we're going to do is be able to reason about existing infrastructure-as-code from different portions of the teams or organization or even multiple services that the same team works and link them together. So, when we look at reasoning about an architecture, it is within the entire context of the application rather than just the smaller bits and pieces. That's one layer. Another layer is being able to ingest the real runtime application metrics and infrastructure metrics, let's say, from AWS or Azure into the optimizer system to be able to not only say, oh well, I want low latency. Then this is hard-coded to use a Fargate instance instead of a lambda. But more realistically, being able to see what that means in lambda world and maybe increase the concurrency count. Because we know that within the confines of cost limitations or constraints that the company wants to have, it is more feasible and cost-effective to raise the minimum concurrency rate of that lambda instead of using Fargate. You can only do that by having real-time data, or aggregated data come from the performance characteristics of the applications. And so that's another layer that we're going to be focusing on. The third one is, just like Aaron said, being able to approach that editing experience and operational experience, not just through one system like InfraCopilot but also through a web UI, or an app, or even as an extension to other systems that want to integrate with Klotho's engine. The last thing that I think is key is that we're still holding on to the vision that infrastructure should be invisible to most developers. Infrastructure definition is similar to how we approach assembly code. It's the bits and pieces. It's the underlying components, the CPUs, the storage. And as long as we're building microservices in that level of fidelity, of like, thinking about the wiring and how things interconnect, then we're not going to get the gains of 10x productivity building cloud applications. We have to enable developers and operators to work on a higher abstraction. And so our end game, where we're headed, is still what we want to build with Klotho, which is the ability to write code and have it be translated into what's allowed in the infrastructure within the constraints of the underlying platforms that infrastructure or platform teams set for the rest of the organization. It can be one set or multiple sets, but it's still that type of developers develop, and the infrastructure teams set them up to be able to develop, and there's separation. VICTORIA: Those are all really interesting problems to be solving. I also saw on your roadmap that you have published on Klotho that you're thinking of open-sourcing Klotho on GitHub. AARON: So, at this point, we already have the core engine of Klotho open-sourced, so the same engine that's powering InfraCopilot and Klotho, the tool itself is open source today. So, if anyone wants to take a look, it is on github.com/klothoplatform/klotho. VICTORIA: Super interesting. And it sounds like you mentioned you have a Discord. So that's where you're also getting feedback from developers on how to do this. And I think that challenge you mentioned about creating abstractions so that developers don't have to worry as much about the infrastructure and platform teams can just enable them to get their work done; I'm curious what you think is the biggest challenge with that. It seems like a problem that a lot of companies are trying to solve. So, what's the biggest challenge? And I think what do you think is unique about Klotho and solving that challenge? AARON: I guess what I would say the biggest challenge today is that every company is different enough that they all saw this in a slightly different way. So it's like, right now, the tools that are available are the building blocks to make the solution but not the solution itself. So, like, every cloud team approaches it on, let's build our own platform. We're building our own platform that every one of our developers is going to use. In some cases, we're building, like, frameworks and SDKs that everyone's going to use. But then the problem is that you're effectively saying my company is entering the platform management business. And there's no way the economies of scale will make sense forever in that world. So I think that's the biggest issue. And I think the reason it hasn't been solved is it's just a very hard problem. There's many approaches, but there's not a clear solution that kind of brings it all together. And I think our product is positioned better than most to solve some of the higher-level abstractions. It still doesn't solve the whole problem. There's still some things that are going to be tricky. But the idea is, if you can get to the point where you're using some of our abstractions, then you've guaranteed yourself portability into the future, like, your architecture will be able to evolve, even in technologies that don't exist yet once they become available. ALA: To tack on to what Aaron said, a key difference, and to our knowledge, this doesn't exist in any other tool or technology, is a fundamentally new architecture we call adaptive architecture. It is not microservices. It is not monoliths. It's a superset that combines all the benefits from monoliths, microservices, and serverless if you consider it a different platform or paradigm. What that means is that you get the benefits without the drawbacks. And the reason we can do it is because of the compiler approach that we're taking, where everything in the architecture that we produce is interchangeable. The team has decided to use Kubernetes, a specific version of Kubernetes with Istio. That works great. And, a year later, it turns out that that choice no longer scales well for the use. And we need to use Linkerd. The problem in today's world and what companies have to do is retrofit everything and not only the technology itself, but it's the ripple effects of changing it into everything else that all the other choices that were made that depended on it. In the Klotho world, because of the compilation step or the compilation approach and its extensibility, you could say, I want to take out Istio and replace it with Linkerd. And it would percolate all the changes that need to happen everywhere for that to maintain its semantic behavior. To our knowledge, that doesn't exist anywhere today. VICTORIA: So it would do, maybe not, like, would do migrations for you as well? ALA: I think migrations are a special case. When it comes to stateless things, yes. When it comes to data, we are much more conservative. Again, bringing what we've learned in different companies in, a lot of solutions try to solve all the things versus we're trying to play in a very specific niche, which is the adaptive architecture of it all. But if you want to move data, there's fantastic tools for it, and we will guide you through getting the access to the actual underlying services and, say, great, write a migration system, or we can generate for you. But you will run it to move the data from, let's say, Postgres to MySQL or from being able to drain a unit on Kubernetes to a lambda. Some of those things are much more automatic. And the transition happened through the underlying technologies like Terraform or Pulumi. Others will require you to take a step, not because we can't do it for you but we want to be conservative with the choices. AARON: I would also add that another aspect of this is that we don't position ourselves as being the center of the universe for these teams. Like a lot of products, you kind of have to adopt the platform, and everything has to plug into it, and if you don't adhere, it doesn't work. We're trying very, very hard with our design to make it so that existing apps will continue to function like they've always functioned. If app developers want to continue using direct SDKs and managing config themselves, they can absolutely do that. And then they'll interact well with Klotho apps that are also in that same company. So we're trying to make it so that you can adopt incrementally without having to go all in. VICTORIA: So that makes a lot of sense. So it's really helpful if you're trying to swap out those stateless parts of your infrastructure and you want to make some changes there. And then, if you were going to do a data migration, it would help you and guide you to where additional tools might be needed to do that. And at your market segment, you're really focusing on having it be an additional tool, as opposed to, like, an all-encompassing platform. Did I get it all right? [crosstalk 31:07] ALA: Exactly. VICTORIA: [laughs] Cool. All right. Well, that's exciting. That's a lot of cool things that you all are working on. I'm curious how overall the workload is for you two. How big of a team do you have so far? How are you balancing out this work of creating something new and exciting that has such a broad potential scope? AARON: Yeah. So, right now, the team is currently six people. So it's Ala and I, plus four additional engineers is the current team. And in terms of, like, where we're focusing, the real answer is that it's somewhat reactive, and it's very fast. So, like, it could be, like...in fact, Copilot went from ideation to us acting on it extremely quickly. And it wasn't even in the pipeline before that. So I'd actually say the biggest challenge has been where do we sort of focus our energy to get the best results? And a lot of where we spend our time is sort of meta-process of, like, making sure we're investing in the right things. ALA: And I think that comes from both Aaron and I have been in the industry for over 15 years. We don't, you know, drop everything and now switch to something new. We're very both tactical and strategic with the pace and when we pivot. But the idea is when we decide to change and focus on something that we think will be higher value, and it's almost always rooted in the signals and hypotheses that we set out to kind of learn from, from every iteration that we go after. We are not the type that would say, "Oh, we saw this. Let's drop everything, and let's go do it." I think we've seen enough in the industry that there's a measure of knowing when to switch, and when to refocus, and what to do when these higher tidbits come, and then being able to execute aggressively when that choice or decision happens. VICTORIA: Are there any trends that you're watching right now that the outcome would influence a change in direction for you? ALA: Not technically. I think what we're seeing in the industry is there's no real approaches to solving the problem. I would say most of the solutions and trends that we're seeing are...I call them streamlined complexity. We choose a set of technologies, and we make that easy. We make the SaaS version, and it can do these workloads, and it makes that easy. But the minute you step out of the comfort zone of those tools, you're back into the nightmare that building distributed systems brings with it, and then you're back to, you know, square one. What we're trying to do is fundamentally solve the problem. And we haven't seen many at least make a lot of headway there. We are seeing a few of the startups that are starting to think in the same vein, which is the zeitgeist. And that's fantastic. We actually work with them closely to try and broaden the category. VICTORIA: Right. Do you feel that other companies who are working in a similar problem space that there is...is it competitive between each other? Or do you think it's actually more collaborative? ALA: It depends on the companies and what they're trying to achieve. Every set of companies have different incentives. So Google, Amazon, and Microsoft have, you know, are incentivized to keep you on their clouds. They may care less about what they have in there as long as you are happy to stay. So you'll see more open source being adopted. You will see Amazon trying to copy or operationalize a lot of open-source tools. Microsoft will give their...because they are working with larger companies to have more vertical solutions. Google is trying to catch up. If you look at startups, you will see some focus more on developers. You'll see others focus on infra team. So it really depends on the intersection of the companies, and then they either collaborate or they compete, depending on how it affects their strategy. In our case, we recognize that our competition is the incumbents and the current way of doing things. And so we are happy to collaborate with all the startups that are doing something in the vicinity of what we're doing, startups like Ampt, and Encore, and Winglang. And there's several others. We have our own Slack channel where we talk about, like, where we're headed or at least what we can do to support one another. VICTORIA: Great. And I wonder if that's part of your business decision to open source your product as well or if there are other factors involved. ALA: I think the biggest factor that we've seen, realistically, is the expectation in the developer community to have a core that is open source, not even the source available model but to have an open-source core that they can rely on always existing and referencing when, you know if the company disappears or Oracle buys them. And so I would say that that was the biggest determining factor in the end to open-sourcing the Klotho engine. It's a very pragmatic view. VICTORIA: That makes sense. Well, I wanted to make sure we had time to ask one of my favorite questions that I ask on the podcast, and you can both answer. But if you could go back in time to when you first started this project, what advice would you give yourself? ALA: I guess the advice that I would give is keep selling and start selling as early as you can, even before the vision is realized. Or let's say you're making kind of headway towards what you'll wind up sharing and giving companies, the lead time to creating the opportunities and the belief and the faith that you can solve problems for companies, and the entire machinery of doing that is a lot more complex than most founders, I think, or at least first-time founders or, honestly, myself have found it to be. AARON: Yeah. If I try and answer that same question, it's very challenging. I guess my perspective now is there's nothing I could tell myself that would make me go any faster because a lot of it really is the journey. Like, the amount of stuff that we've learned in the last year of working on this and exploring and talking with people and everything else has been so vast that there's nothing I can communicate to past me that would prepare me any better. So [laughs] I think I would try just my best to be encouraging to just stick with it. VICTORIA: Well, that's good. And who knows what you're going to learn in the next year that [laughs] probably might not help you in the past either? That's wonderful. Do you have any final takeaways for our listeners today or anything you'd like to promote? ALA: So, from my lens, I've always wanted to do a startup but felt that the life setting wasn't quite ready. And a lot of the startup culture is talking about younger, earlier founders. I think having had the industry experience and understanding both the organizational and technical challenges, knowing more people, and engineers, and founders, potential founders, has been vastly more helpful than what I would have been able to pull off ten years ago. So, if you are thinking maybe it's too late, it is not. It's probably easier in some regards now. And yeah, check out InfraCopilot. It's on infracopilot.io. We would love to have you try it out and go on this journey with us. AARON: Yeah, I would definitely echo that. I mean, sort of the same thing on the journey. Like, it's never too late to start. And yeah, like, I would say being in the industry and actually seeing these problems first-hand makes it so much more fulfilling to actually try and solve them. VICTORIA: That's [inaudible 38:15]. I'm excited to see what you all accomplish. And I appreciate you coming on the show. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, you can email us at hosts@giantrobots.fm. And you could find me on Twitter @victori_ousg or on Mastodon @vguido@thoughtbot.social. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guests: Aaron Torres and Ala Shiban.Sponsored By:thoughtbot: Are you an entrepreneur or start-up founder looking to gain confidence in the way forward for your idea? At thoughtbot, we know you’re tight on time and investment, which is why we’ve created targeted 1-hour remote workshops to help you develop a concrete plan for your product’s next steps. Over four interactive sessions, we work with you on research, product design sprint, critical path, and presentation prep so that you and your team are better equipped with the skills and knowledge for success. Find out how we can help you move the needle at: tbot.io/entrepreneursSupport Giant Robots Smashing Into Other Giant Robots