TopPodcast.com
Menu
  • Home
  • Top Charts
  • Top Networks
  • Top Apps
  • Top Independents
  • Top Podfluencers
  • Top Picks
    • Top Business Podcasts
    • Top True Crime Podcasts
    • Top Finance Podcasts
    • Top Comedy Podcasts
    • Top Music Podcasts
    • Top Womens Podcasts
    • Top Kids Podcasts
    • Top Sports Podcasts
    • Top News Podcasts
    • Top Tech Podcasts
    • Top Crypto Podcasts
    • Top Entrepreneurial Podcasts
    • Top Fantasy Sports Podcasts
    • Top Political Podcasts
    • Top Science Podcasts
    • Top Self Help Podcasts
    • Top Sports Betting Podcasts
    • Top Stocks Podcasts
  • Podcast News
  • About Us
  • Podcast Advertising
  • Contact
Not in our directory?
Add Show Here
Podcast Equipment
Center

toppodcastlogoOur TOPPODCAST Picks

  • Comedy
  • Crypto
  • Sports
  • News
  • Politics
  • True Crime
  • Business
  • Finance

Follow Us

toppodcastlogoStay Connected

    View Top 200 Chart
    Back to Rankings Page
    Software How-To

    Giant Robots Smashing Into Other Giant Robots

    A podcast about the design, development, and business of great software. Each week thoughtbot is joined by the people who build and nurture the products we love.

    Advertise
    • Apple Podcasts
    • Google Play
    • Spotify

    Latest Episodes:
    489: CTO Lunches with Kendall Miller Aug 24, 2023
    Show notes

    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…

    Full show notes at the publisher

    488: Women Who Code with Alaina Percival Aug 17, 2023
    Show notes

    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…

    Full show notes at the publisher

    487: OtisHealth with Marc Mar-Yohana Aug 10, 2023
    Show notes

    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…

    Full show notes at the publisher

    486: Blox with Simon Ritchie Aug 03, 2023
    Show notes

    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…

    Full show notes at the publisher

    485: Pointz with Maggie Bachenberg and Trisha Ballakur Jul 27, 2023
    Show notes

    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…

    Full show notes at the publisher

    484: Ruby On Rails: The Podcast with Brittany Martin Jul 20, 2023
    Show notes

    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-hos…

    Full show notes at the publisher

    483: Honeycomb.io with Charity Majors Jul 13, 2023
    Show notes

    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 q…

    Full show notes at the publisher

    482: Evil Martians with Irina Nazarova Jul 06, 2023
    Show notes

    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…

    Full show notes at the publisher

    481: Oscar Health with Neetu Rajpal Jun 29, 2023
    Show notes

    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,…

    Full show notes at the publisher

    480: klo.dev with Aaron Torres and Ala Shiban Jun 22, 2023
    Show notes

    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 hap…

    Full show notes at the publisher

    Previous 1 14 15 16 17 18 64 Next

    Related Podcasts

    Know How… (Video)

    1

    Know How… (Video) Education
    JavaScript Jabber

    2

    JavaScript Jabber Education
    Programming Throwdown

    3

    Programming Throwdown Software How-To
    Software Engineering Radio – the podcast for professional software developers

    4

    Software Engineering Radio – the podcast for professional software developers Software How-To
    The Changelog: Software Development, Open Source

    5

    The Changelog: Software Development, Open Source How To
    Coding Blocks

    6

    Coding Blocks Software How-To
    footer-logo

    Contact Us

    Toll Free: 844-670-7747

    Links

    • Home
    • Top Charts
    • Networks
    • Apps
    • Independents Podcasts
    • Podcast Advertising
    • Podcast News
    • Contact Us
    • About Us
    • Analytics & Insights

    Stay Connected

      Privacy, Terms of Use & Our Code of Ethics Protecting Content Creators Copyrights