Giant Robots Smashing Into Other Giant Robots

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

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

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

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

Brendan Schwartz from Wistia discusses the journey of the platform, challenges faced during strategic shifts post-COVID, value of simplicity in product development, authenticity in content creation, embracing challenges in business, and future goals of Wistia in video marketing.

Agnes Malatinszky is the Founder of Senga, which takes care of back-office administrative needs for freelancers, contractors, and solopreneurs. Victoria and Will interview Agnes about the thoughtbot Incubator program and what led Agnes to choose to apply, what the demands on her time were like, how it worked, and how she feels now that she's at the end of the program. Senga Follow Agnes Malatinszky 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: I'm your other host, Victoria Guido. And with me today is Agnes Malatinszky, Founder of Senga, providing back-end support for freelancers. Agnes, thank you for joining me. AGNES: Hey, it's a pleasure to be here. VICTORIA: You are the first graduate of thoughtbot's incubator program, and I'm really excited to dive into that with you today. So, before we get started in talking about the incubator program, let's just start with what fun thing do you have going on this week? AGNES: I'm based in Washington, D.C., and it's a beautiful time of year here. Early summer, late spring is gorgeous. So I'm excited because my family and I are actually headed out to Harpers Ferry this weekend for a little hike. So I'm looking forward to that. WILL: So, what is...when you say a hike, can you explain it to anybody that's outside of the D.C. area? AGNES: It's just a beautiful area in West Virginia. And we're going to take our dog and my daughter out there and get some fresh air and walk around. There's a little historic town there as well that's really interesting to explore. WILL: That sounds fun. VICTORIA: Yeah. I've been to Harpers Ferry to go floating, like, on the river. AGNES: Yes. VICTORIA: Where you float down the river in inner tubes and drink beverages. [laughter] There's also...there's rock climbing in Harpers Ferry too, which is sometimes closed for bird nesting. So it is really beautiful. AGNES: Ooh, I didn't know that. That's really cool. We'll keep an eye out for that. WILL: Yes. For anybody that doesn't know, Victoria is an amazing rock climber. I have a lot of respect for her because I don't know if I could do it. [laughter] VICTORIA: You could definitely do it. The next thoughtbot trip that we're on, we'll go rock climbing, Will. I'm confident in your skills. You could do it. Yes, I'm a big rock climber and rock-climbing advocate, so I'll talk about it forever if you let me. WILL: [laughs] VICTORIA: And I'm actually going to go rock climbing this weekend and get outside myself. And we're going up to Mammoth, California. And we're going to do a half-climbing, half-ski trip. WILL: Ooh. VICTORIA: So that's going to be fun for Memorial Day weekend, so...What about you, Will? What do you have going on fun this week? WILL: Yeah. So you said skiing. VICTORIA: Yes. So Mammoth got the most snow in the country this year. When we were there in February, they'd already had, like, 10 feet of snow. And then they got another foot of snow while we were there, so they're going to have snow through August, at least. WILL: August. Wow. Here in South Florida, the lowest we got was 50. So snow, I don't even know what you're talking about. [laughs] Yeah, so you asked what I'm going to do. Last week was a big week for us because my boys they turned four years old and one year old. And we took them to Disney and had a blast. Anybody who's been to Disney knows it's a trip. It could be a lot, especially it was very hot there too. So I think this weekend we're just going to take it easy. We're just going to relax and just enjoy it. VICTORIA: Trip of a lifetime for them, I'm sure. WILL: Yes, they loved it. VICTORIA: We have Disneyland over here in California. I have been to Disney World in Florida. But I still haven't been to Disneyland since I've been here, [laughs] which I think some people would judge me for. AGNES: You know what? I haven't been to either. I hold it against my parents forever. [laughter] Although my family is not a big fan of crowds, so I think that's why. WILL: Yes, if you're not a fan of crowds, Disney is not the place, especially now. I've heard around September is probably the best time to go. So we're going to try that out during that time too. AGNES: Ooh, protip. You heard it here first. WILL: Yes. [laughs] VICTORIA: September, Disneyland, Florida sounds very warm to me. [laughs] But yeah, we're actually going to go to Mexico with thoughtbot as a team meetup in September, which is also going to be pretty warm, I think. [laughs] But it'll be fun. Well, that's lovely. I love getting to hear a little bit about your lives before we dig into your business. Agnes, I'm super excited to hear about Senga. But maybe start with just a little bit about your background before you started. AGNES: I had been thinking about starting my own business for a while. I am an immigrant, and I come from an entrepreneurial family. Actually, my mom ran her own translation business back in Hungary, and now she's a really successful artist. So, you know, I had support from them and my husband as well to sort of try out something new. But, in my last role, I was actually Chief Operating Officer at an EdTech company that had scaled to serve over 80% of U.S. schools during the pandemic. And I was at that company for about five years and had seen the full arc of, you know, startup to a mature organization. So I was ready to take on a new challenge and to learn something new. WILL: You mentioned that your mom was an entrepreneur. And my dad was an entrepreneur, also. He had his own electric and HVAC business, and I learned so much from him. Is there anything that you can just, like, ooh, I learned this and this from my mom as a kid, looking at your mom being an entrepreneur? AGNES: I mean, she is just a, you know, fix-it person in every sense of the word. So she will fix an electric outlet. She will fix something with her business. WILL: [laughs] AGNES: She's just, like, really good at getting her hands dirty and being really scrappy. And I think that's a really important skill to have, you know, especially in a startup, and especially when you're starting out and still on your own. VICTORIA: So, what did your parents say when you told them you were going to start out on your own and build your own company? AGNES: They were really encouraging. They, you know, they keep up with all my LinkedIn posts, and they read everything I publish. So they're just very supportive and the best cheerleaders I could possibly hope for. [laughs] WILL: Did stepping out and starting your business did anything scare you in that area? AGNES: Oh my gosh, every day, something new. It's all just uncertainty and risk at this point. You know, I'm very, very early in my startup journey, so literally every question about the business I have to test. I have to find answers for. And that ranges everything from, you know, business formation to, you know, the nuts and bolts of getting the business organized and setting up financials, and the legal structure for the company, to figuring out what the product is going to be. So all this uncertainty is definitely a little bit nerve-racking. VICTORIA: And I'm wondering, what about your past experience as a Chief Operations Officer led you to want to build a product like Senga? AGNES: So being a Chief Operating Officer, I think one of the things that I really learned was that in order for a business to be really successful, and for people working at that company to be really successful, they have to have the organization's support to do what they do best. You know, what I used to tell my operations team was that you know, we were really the plumbers of the organization, making sure that everything ran smoothly behind the scenes. So, actually, that was one of the inspirations for Senga, for my current company, this idea that freelancers and independent workers don't have that support. They don't necessarily have somebody helping them with HR, and with financials, and with legal stuff, and with everything else that goes into running a business, whether you're a business of 1 or a business of 100. And that's really where I wanted to come in and, you know, support independent workers. VICTORIA: One follow-up question for Agnes on your experience in the COO role. I believe your team also had a lot of background in the freelancing world. So you had people you could ask questions to and start to understand that market. Is that right? AGNES: Yeah. Like a lot of businesses, I guess we had, you know, freelancers and contract workers that we relied on. And that's increasingly true for most companies now, I would say. There's specialized roles. There is seasonal roles that you don't necessarily hire full-time employees for but that are perfect for somebody, you know, on a temporary basis or somebody with more specialized skills. So you're exactly right; being able to tap into that network and having had experience working with freelancers and contractors was really helpful coming into the incubator and having people to tap for interviews and for input. VICTORIA: Great. And then, what is the thoughtbot incubator, which we've mentioned a few times already? It is for a non-technical founding team with a business idea that involves a web or a mobile app. It's an eight-week program that helps you get the proof points you need in order to move forward with confidence. So I'm curious, Agnes, what led you to choose the thoughtbot incubator Program as something you wanted to apply to? AGNES: I mean, it's exactly what you named. So this incubator program was really a perfect launching pad for me. It's designed for non-technical founders, like myself, to get their own dedicated team of product and dev experts to, you know, like, hone customer discovery practice, create a product strategy, run proof of concept experiments. And, you know, these were exactly the areas where I lacked skills and expertise the most. So I had actually looked at other incubators and even some venture studios before, but those models were not as good of a fit for me. I was really excited to find and to be able to join thoughtbot's incubator program. MID-ROLL AD: Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff. WILL: What was the original idea behind Senga? AGNES: The idea that I came into the incubator with and then the pain points that we honed in on during the incubator, and then the long-term vision for the company are all kind of a little bit different. So I'll zoom out first to the sort of 30,000-foot view of this. So, coming into the incubator, I had been reading and researching a lot about some macro trends that I think are really interesting, and these are trends that many of us are keeping an eye on. So they're nothing revolutionary, but I think they're going to create some really interesting problems to solve in the next couple of years. So the first one is the rise of independent workers, or contractors, or freelancers. I'm kind of going to use these terms interchangeably. In recent years, the number of independent workers has shot up like crazy. There are already over 65 million independent workers in the U.S., and this number is growing by about 25% annually. And then, add to this that economic downturns tend to grow this number even more. You know, this makes up about a third of the workforce in the U.S. already, and it's growing. The second thing is that you know, the fact that early-career folks, especially Gen Z, really like the independence and autonomy that comes with this type of work. Over half of Gen Z already freelance, and the majority want to make independent work their career. In other words, they explicitly do not want to work for a company in the traditional sense. And then, third, there's kind of a mishmash of factors that I'll lump into one bullet that additionally drive up this type of work, which is that, increasingly, jobs are going to be skills-based, not degree-based, and all work, even white-collar work, will become more modular. Both tech advances and even, I think, novel organizational structures are going to make it possible for people to hyper-specialize and to plug into different organizations at different times, and, you know, even simultaneously to perform that specialized work. So take all this together, and what I'm really seeing is that the current market offerings serving freelancers and contractors are not nearly enough to meet all their needs, which is driving huge inefficiency. The types of companies that cater to this segment now or, you know, there's mature marketplaces like Upwork, and Fiverr, and some earlier-stage companies that do, you know, more workflow and back office. But I'm not seeing a comprehensive solution, and that's driving like I said, a lot of inefficiency. So, ultimately, being a freelancer is still really hard. Only about 50% of a freelancer's time is spent on billable work. And so this is what I really want to solve. VICTORIA: And did anything change through the incubator process? AGNES: So the biggest thing I found during the incubator was actually a really good entry point into this market. So startup wisdom says that you have to narrow down your product to a super tight segment that has a very strong, like, yes to your product. So, during the course of the eight weeks that I did the incubator, we did a ton of interviews, and I was really on the lookout for big spikes and pain points that repeated for a specific niche of freelancers. And that's exactly what we ended up finding. There's lots of nuance to this, but generally speaking, people new to freelancing and those that are just looking to get started need help getting started in a more manageable way and then setting up good practices that will serve them in the long run. WILL: You mentioned those practices that helps them set them up in the long run. Are you talking about mostly the operation, so, like, anything that's non-billable for a client? AGNES: Exactly, yeah. So that's kind of how I think about the work is anything that's billable and then anything that's non-billable. So that includes client management, client communication, marketing themselves, finding, you know, new work, so drumming up new business, all the back-office financials, back-office legal and admin stuff. All these other things that traditionally would be, you know, done by, you know, an operations team at a big company, but, for freelancers, they have to do it themselves. WILL: Yeah, I love that idea because my spouse she dipped her toe into the freelance world. And I felt like the operations kind of overcame everything else. And so it almost felt like the operations was taking over the job. But it's one of those things I feel like we didn't really think through of how much work that that 50% is. Like, how much work do you have to do, which are taxes, operations, speaking to clients, even to get to the things that people usually love, like the design, the software development? So I'm excited about this product. AGNES: Yeah, exactly. And that's kind of what I kept hearing again and again in interviews with all sorts of different freelancers because we went out and interviewed folks from, you know, everywhere from graphic design, to UX/UI design, to web developers, to other types of creatives, content creators. And this idea that they all get into freelancing to pursue their passion, the thing that they're uniquely good at. But then end up spending a huge chunk of their time on, you know, things that they're not really specialized in, you know, basically running their business. VICTORIA: What types of experiments did you run while you were in the incubator program with the people you mentioned you're talking to? And what were the demands on your time really like? AGNES: Oh, so the program is between 20 to 40 hours a week. I had a chance to meet with my thoughtbot team daily. We had independent work time, also breakout sessions. Like you said, a lot of that time was spent doing interviews and running all sorts of different experiments, so discovery interviews, interviews showing the prototype once we had it to interviewees. But we also set up Google Ads. We created a landing page with various calls to action. And then based on who was coming through the landing page and what they were doing on the site, we had all sorts of, you know, lessons that we could take away from that. And then another piece of it was I also learned how to basically start building out an organic community around this problem and from, you know, the community of freelancers, which is so important to have, like, for a future user base and also to be able to continue to engage with my target audience. WILL: Was there anything that surprised you about the program, or did you have any interesting findings coming out of the program? AGNES: One thing I learned through the program was that you know, there are concrete steps that you can take and a process that you can follow to build out a strong business that solves real problems for people. And that's really what this program and this incubator is focused on, is to teach you those skills to go through those early steps. You know, everything that I had read before about startups they're kind of clouded in mystery. And, you know, the big ones that end up being really successful tend to be mythologized, and founder stories tend to have these, like, big eureka moments in them, where the founder had their big idea that led to the big company. But really, at the early stage, it's pretty messy. And nevertheless, you have these steps that you can follow and processes that you can follow to build out the company. VICTORIA: And how are you feeling now at the end of the program? AGNES: I feel really excited and, frankly, more confident than I came into the program. So, you know, I'm leaving here with lots of good data, lots of good anecdotal evidence, having had dozens and dozens of conversations with my target market. So, for me, that's a really great feeling to know that my ideas they don't just exist in the abstract in my head but that we've bounced them against the universe and confirmed that folks are having the pain points that we expected and some that we did not expect. And that there is an opportunity around this. WILL: So, what could be done better about the incubator program from your perspective? AGNES: It was a great program, and that's a pretty hard question to answer. But, you know, I would selfishly say make it longer. Eight weeks is, by design, you know, a pretty short time to get started. And that's really what the program is designed to do is to get you started, to set you up with good practices and good tools. But, again, selfishly, I wish it were a little bit longer, so I can stick around and have the thoughtbot team around me. And then I just look forward to building more of a community as more founders join thoughtbot's incubator every quarter. We have a shared Slack channel that I'm going to continue hanging out in and that I've been told the new founders, as well, will be added to. So I'm looking forward to getting to meet them and to, you know, hear about their experience as well. VICTORIA: What's coming up next for you in the next six months? AGNES: So I'm talking to a couple of potential partners in the next couple of weeks, which might kind of change the roadmap slightly. But, basically, this summer and fall, I'm building out a lot of the content and the prototype for Senga. Again, continuing to talk to the freelancers I've been continuing to talk to. I'm also putting together sort of, like, an advisory committee of freelancers I've met along the way who had a strong yes sort of reaction to this product. And then my goal is that by fall or winter, I'll be able to start building out an MVP. WILL: That's exciting. AGNES: Yeah, I'm really excited. [laughs] WILL: Your dream is finally coming true, so, yeah, you have something to be excited about. [laughs] Do you have any advice for any other founders? AGNES: I guess I don't know how qualified I feel to be, you know, handing out advice as a brand-new founder. But, overall, I would encourage others out there who are interested in taking this path to, you know, really take a risk and to bet on themselves. What I've found in the last couple of months is that there are so many supportive communities, and founder groups, and entrepreneur groups. And this is kind of common advice, and everybody says this, but there's really no way you can fully prepare. You just kind of have to start doing. And at least from what I've seen, that's the secret sauce to this early stage is to keep doing and to keep going from one step to the next every day. VICTORIA: If you could travel back in time and give yourself advice from when before this all started, what advice would you give yourself? AGNES: I would just encourage myself to, you know, take the plunge and maybe even go down this path sooner. You know, I feel really confident where I'm at now in terms of my career and my, you know, support networks and everything. But being able to go back and start experimenting earlier and start going down this path earlier might have even set me up better. WILL: One thing when you're starting a startup is funding. Are you looking for any funding? AGNES: Not urgently, but I'm definitely interested in talking to others working and investing in this space. So, you know, if any of your listeners are investors or entrepreneurs in a similar space, I would love to talk to them. WILL: Yeah. So, how could they reach you if they wanted to reach out to you? AGNES: You can reach me by email at hello@senga.app, or you can find us on LinkedIn at Senga. VICTORIA: You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You could find me on Twitter @victori_ousg. WILL: And you can find me on Twitter @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening. See you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Agnes Malatinszky.Sponsored By:thoughtbot: Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoffSupport Giant Robots Smashing Into Other Giant Robots

Chad joins cohosts Victoria and Will to talk about thoughtbot's 20th birthday! 🤖🎉 In this episode, you'll find the 411 on the thoughtbot mascot, "Ralph," taking the company fully remote, and our company values and how we believe products should be designed and built! Follow Chad Pytel on LinkedIn, Twitter, or visit his website. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. JORDYN: Thanks for having us. DAWN: Yeah, glad to be here. VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. JORDYN: Wonderful. VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. VICTORIA: What made you decide to start this incubator program this year with thoughtbot? DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. VICTORIA: Wonderful. That's amazing. Thank you both so much. INTRO MUSIC: 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 host, Will Larry. And with us today is our other host, Chad Pytel, the CEO of thoughtbot. Which, we're celebrating 20 years of business this year. Chad, welcome. CHAD: Oh, it's good to have the tables turned on me. And I'm looking forward to the discussion today. VICTORIA: Great. We have a whole set of questions, some of which come from other employees within thoughtbot. So we're really excited to dig into it today. Why don't we start with thoughtbot's iconic logo, the Ralph bot, and the little red robot that everyone knows thoughtbot for? And we call him Ralph within thoughtbot. So, how did Ralph come to be? Where does his design come from? And how did that become part of the company mascot? CHAD: I'm happy to tell the story. But I have a question for both of you: have you ever heard me call the robot Ralph? WILL: [laughs] No. VICTORIA: I don't think I've ever heard you refer to the robot. WILL: [laughs] VICTORIA: So, if you did call it, I don't know what you would call it. WILL: Oh, who started that? [laughs] CHAD: It was someone who was at the company, Matt Jankowski. WILL: [laughs] VICTORIA: Ah, I see. CHAD: I actually don't like the name. I think it's a terrible name for the robot. [laughs] I don't understand why the robot has to be gendered at all. And so I've never said that that's the robot's name. You know, when you're CEO, you have to pick your battles. WILL: [laughs] Yes. CHAD: Yeah. So that's the unofficial name of the robot, I think. And Matt started calling it that because Matt's a big fan of coming up with names for things. And yeah, so, at some point, he started calling it that. And it sort of stuck as people joined the company and just sort of assumed that that's what the robot's called. We didn't start with this logo. Logo has always been a robot. But the thing we started with was an illustration based off of a tin robot that I think either one of us had or that we saw a picture of. Another Matt, who is one of the founders of the company, sketched it. He was a designer as well as a developer. And we used it for a few years. But what we learned over the course of it as we gained more exposure is that, actually, it's a really common tin toy robot. And you can find a lot of other art and illustration and uses of it in stock photography and everything. Which at first was good because then we could get a bunch of stock photography, and it was our logo. But then we realized, ooh, this is not something that we really own or have control over. So we started to think about creating our own robot logo from scratch. Since we're a design firm, and I think it's notoriously hard to design things for yourself, we actually went to another agency that we were friends with and hired them to work with us to create the logo. And I have to say I was probably the worst client ever. WILL: [laughs] CHAD: Because I was asking...I had a particular vision in mind for this idea of, like, a powerful robot. And we kept on doing sketches, after sketch, after sketch, and it was really hard. We couldn't arrive at something that seemed powerful, that didn't seem aggressive. The logo at the time was a 3D representation of the robot. And it was really hard to also make a new 3D robot that looked powerful but not aggressive. And we just banged our heads against that for a long time. I think it was a couple of months. Until one day, I just said, you know what? We're not going to do it. Let's just stop trying to do this. [chuckles] Let's just do the simplest 2D representation of a robot that we can think of. And just going back to the drawing board starting over, we arrived at the logo we have today. Now we have to deal with the fact that it looks a lot like the Android logo. [laughter] But that's the, I guess, the story of the robot. WILL: So, first off, scratching the name Ralph. [laughs] CHAD: No, no, you can use it. I just think it's funny. WILL: Definitely. Second thing is Chad is not a good client when working with designers. No, I'm just joking. [laughs] CHAD: No, it's totally true. WILL: [laughs] CHAD: You know, when we have strong opinions that are mostly preferences, that leads to people being bad clients. [laughter] Because there was no reasoning behind, you know, the preferences. It was just what I had in my head. And so it wasn't until I let that go that we were able to arrive at something usable. WILL: [laughs] That's awesome. So, was the robot a passion for you, or was it just a toy that one of the founders, employees had, and that's where you went with it, how you got your inspiration? CHAD: The name thoughtbot with the bot on the end comes from...because before we started thoughtbot, we did a lot of Java development as a group, same people I went to school with them. We did projects together. And we would follow the pattern where you sort of have an object and then a manager object or a service object. And it was a common naming pattern. If you have orders or customers, then the service object might be called order manager or customer manager. And, in our code, we tended to not do that and instead do bots. So we would have order bot over orders, customer bot over customers. So, when we were brainstorming names for the company, we naturally tended to put bot on the end because that was our typical naming convention in the projects we were doing together. And so there wasn't anything particular about robots that we cared about at all. [laughter] It was that naming convention, which then extended to, okay, well, it's the thoughtbot. And so it should be a robot with thoughts on it or thought lines or something like that. That's where it came from. VICTORIA: I love to hear that. I'm learning so much myself I didn't know before even as a thoughtbot employee. WILL: [laughs] VICTORIA: It's been 20 years since you started the business. I want to start...or go back in time. So, if you could go back and give yourself, the younger version of you 20 years ago, some advice, what would you say? CHAD: I've gotten similar versions of this question on different shows. My answer for the last several years has been pretty consistent. So I'll give that one, and then I think I have another one too. The thing that I didn't realize at the time that I think I would be better for and the company would be better for I had a big blind spot in terms of I started thoughtbot with friends. We were the same age. We were all five White guys in our 20s, just out of school. That was the people that I was doing projects with; that was the people I was surrounded by in school. And it was a big blind spot. And, if I could go back in time, I would try to open my eyes to the fact that that was the case. And I think that I would be a lot better for it. And I think the company would be a lot better for having started with a more diverse team from the beginning because it makes us worse when you don't start off that way. It's harder and harder to correct it the longer it goes on. And so that would be something that I would go back and try to tell myself. Look at what you're doing. You don't realize now, but it is important. WILL: So, because we started talking about this at Summit a month ago, and it was amazing to hear that you're saying that because, at the same time, we're at this all-staff event, and we're able to see how diverse our team is and stuff like that. How has the journey been increasing the diversity of the team? Like, I look at our team photo, and it's just amazing to see the diversity in every level, especially in leadership, the diversity in leadership. And I know we haven't, quote, unquote, "arrived." So, how has that journey been? And what does it look like in the future? CHAD: Yeah, I mean, we've clearly made a lot of progress on this. It is better and easier now than it was in the early days because nobody wants to be the first. Nobody wants to be the first woman on the team. No one wants to be the first person of color on the team. You don't know when you're coming into an organization like that, whether it's the kind of place for you or whether you're going to run into problems. And so now that we've made some progress, that in and of itself makes it easier to continue on the journey. But when we were just getting started on that, we really needed to do a lot to intentionally fix it without tokenizing people, which is not easy to do. And so we're very fortunate that we have made progress. And I appreciate everyone along the way putting themselves out there, willing to be the first, or the second, or the third. I know that that's not easy, and it's made thoughtbot a better place now that we've progressed. WILL: Yeah, and I want to interrupt and say this: after that conversation, I remember I had to split and run to another event. While at that event, I met one of the first ladies that were on the team. And I started chatting about her experience. And it was amazing to see the transformation from the beginning to where it is now. So it was just really good to have that conversation with you, and then go talk to her and just, I guess, see the complete picture, so that's amazing because she's still on the team to this day. CHAD: Yeah. But we're not done yet. Like you said, we still have [laughs], you know, we can always be better. WILL: Where do you see it going in the future? CHAD: Well, I think that even though the management team, the senior leadership team, we have made progress there, I think that that is an obvious area where we have more progress to go in terms of making sure that people at the company are represented...the demographics of the people at the company are represented at every level of the company, especially when you have a culture like we do where the leaders are the people who have been here the longest. And we don't have so many of those positions opening up over the years. In fact, over the last five years, we've eliminated more of those positions in order to reduce overhead and to stay financially sustainable. So we actually have less of those opportunities than we have in the past, and so that holds us back. And so we have to figure out how to handle that and to do better with that. The other is, you know, one of the biggest changes over the last three years is going fully remote. And that has enabled us to hire the best people, no matter where they live, in the time zones that we operate in. And that has been really great for bringing new people, new energy onto the team. That is going to continue into the future. And we're going to see the demographics of the company continue to shift away from the United States. 60% of the company is now outside of the U.S., and that's going to keep on going. And that doesn't make us any worse off. It makes us better. VICTORIA: Yeah, I wanted to ask you about that. So, thoughtbot, as I understand it before we went fully remote, was known for having an amazing in-person office culture. So, what was that shift like for you? And how do you maintain that company culture after going fully remote? CHAD: Well, here's the honest answer. WILL: [laughs] CHAD: The honest answer was I was already not part of that office company culture. I was traveling one week out of every month to one of the studios. I didn't interact with people in the same way because of my position within the company. I was out of the studio a lot of the time. And even when I wasn't there, I was already working from home a few days a week because of my travel schedule or something like that. So moving to fully remote...and I was already sort of over-commuting to 45 minutes each way to the office. And so moving to fully remote has made things a lot better for me because I'm traveling a lot less. I get to be home with my family a lot more. I don't have that commute time. And my experience now, I think, is more similar to everyone else on that team. And I feel like we're all sharing more equally in what the experience is at thoughtbot. And so when I work to improve that, I'm not only working to improve it for me. I'm working to improve it for everybody. And so there are trade-offs. It is certainly different for the individual designer or developer at thoughtbot than it was before. But I think that the benefits of having the team that we have now, people being able to live where they want to live and to get that commute time back, outweigh the downsides of changing that company culture. VICTORIA: The other part is about just that shift, right? Of it was COVID. [laughs] Obviously, a lot of people were going remote at that time. So I'm just curious how that experience really happened for thoughtbot. I know how it happened for me at the company I was at. [laughs] CHAD: Well, it was certainly abrupt, you know. And, at the time, we thought, okay, we're going to shut down the office for two weeks, and then we'll all be back. And that, very quickly, was proven to be wrong. When it came to our actual work, the biggest shift we had was in the way that we collaborated with clients. But we were already collaborating with each other across studios in a distributed way. And so that was a more natural progression. I think the biggest shift was the way that our projects were working and collaborating with clients. You know, we would have clients in the office with us, too, sitting right next to us. And so figuring out how to do design sprints fully remotely, to ramp up the amount of remote pair programming that we were doing, those were the big changes, I think. And then you had the cultural ones, too, that you really need to work at when two people are getting a snack in the kitchen and having an off-hand chat about something. When you're fully remote, that doesn't happen. You need to put a lot more effort into those sort of what would have been casual conversations previously. WILL: So, and it seems like...just having a conversation with you, I know that it wasn't an easy decision to change over. And my question is, how do you make decisions, especially the hard ones that are not...and you stick with them? For example, I know, like, with hiring, we're talking about the diversity and creating a diverse pool that kind of resembles the area that we're trying to hire for, so, you know, resemble the U.S., or overseas, or wherever it is. And that's a hard thing to do at times, but we stuck with it. And there's been other decisions I've noticed. So, how do you make those decisions, one, and then, how do you stick with them when most companies or most people will say, "Hey, it's just too hard. Let's pivot and change it up"? CHAD: Yeah, we have our values, five core values, and one of them is fulfillment. And I often refer to that as our North Star value, meaning that when we're faced with a decision as a company or as individuals, fulfillment is often the one that we most often look to as the guide for which direction to go in. And I think that that is really powerful for us. It causes us to choose things that other companies might not choose. And it also is really powerful for us because it means that I don't need to be the one to make all of the decisions. You can make decisions based on what is fulfilling to you in your work. And that's very likely the right thing for everybody else at the company. And it may mean that we're a little bit less successful financially. But there are two aspects to success, you know, you need to be financially sustainable, but if you're unhappy in your work, if you're unfulfilled in your work, then that's not truly being successful. And so that's the guiding point of the way that we make a lot of decisions. Take the example of going remote, we weren't really deciding between going back to the way things were or going fully remote. Going back to the way things were was not an option because we had already told everyone if you need to move if you need to be away from the studio you were previously part of, go do that. You don't need to worry about remaining at thoughtbot. And about 20 people moved away from where their studio had been located, which is about 20% of the company. So we were deciding between hybrid or fully remote. Going back to the way things were wasn't an option because we had already removed that from the table, I think, guided by supporting the team, fulfillment, trust, our values. So then the decision-making comes, do we want to figure out how to be hybrid? Which we had done before in our history. And we understood, based on that past experience, that you have to work at that quite a bit to integrate everyone fully, and sort of if you don't, it becomes very tough or even just mediocre. And so it was, are we more excited about working at being the best hybrid organization in the world, or are we more excited at figuring out how to be the best remote company in the world? You know, for me, that was an obvious choice. I was more excited about figuring out how to be the best remote company than I was about being the best hybrid company. So I think that that's an okay... [laughter] I think that's an okay way to make decisions. What are you more excited by? What are you going to be more fulfilled by in your work than that? And so that's, you know, sort of dissecting that decision-making, you know, part of what tipped us over the edge in terms of choosing to be fully remote. VICTORIA: I like that you said that you tried to make it so that you're not the one making all the decisions. [chuckles] And I felt that as a managing director and as an associate director that there is a very purposeful tact of when I'm bringing issues to leadership. The response I get back is very careful not to tell me what to do. [laughs] CHAD: Yeah. I'm sure it's annoying at times, right? [laughter] VICTORIA: I think it's a shift, right? Like, if you're coming from a typical, like, top-down organization, it can be a real mind shift, and it can be frustrating. But then, once you embrace it, it can be very fulfilling, like you said. CHAD: Part of why we do that, too, is because if you're not careful, you know, one of our other values is trust. And we really do trust people more than they're used to. And our other value is self-management. So, people should be left to their own devices. People at thoughtbot take initiative in their work to make decisions, those kinds of things. And so, at the intersection of trust and self-management, what happens in a lot of other cultures is this idea of permission. If you have to ask permission to do things, then you can't truly self-manage. So, when you come to a leader and you're asking for something, it's hard for that not to be articulated as asking for permission for something in a traditional sort of power hierarchy. I encourage people at thoughtbot to think about...in the way that our culture works, it's a lot better to frame things as asking for advice because there are people who have more experience in a certain area than you or whatever. And so a much better way of framing the conversation that you want to have with those people is instead of just asking open-ended questions, which it's very easy to misunderstand as basically just asking for permission to do something, it's better to say, like, "Here's what I know. Here's what I would do based on what I know. Do you have any advice for me based on that?" And then I can say, "Oh, well, here's what I know. [laughs] Can I share that with you?" And then, you can take that information in, and then you can make the decision based on having that additional information. I don't want to make the decision for somebody. That's the way I think about it. If you're not sure what's happening, it can be pretty frustrating in our culture because we are sort of averse to telling other people what to do. We're happy to help people and give people information, but we don't like to tell people what to do. WILL: Yeah, and I've definitely felt this, even as a developer here. But it has been the perfect fit for me because I love the, hey, we trust you. Go and do it. Go make decisions. Hey, even if you fail, let's come back and talk about it and move forward. But also the pushing me out of my comfort zone. There has been numerous times where I'm like, "Yeah, I don't think I can do that." And someone in leadership is like, "I think you can. Let's try it out. Let's do it. If you have any questions, come talk to me. I'll help you in any way I can." So, even as a developer, I feel that same way. And so I guess my question for you, Chad, is there's been a lot of decisions that I've seen you make or even this part right here, the trust. Because sometimes, money can override that when you're a CEO, especially because of jobs and everything. But you said fulfillment, and you had the values. But, Chad, as the CEO, like, why do you personally lead like that and make decisions like that? CHAD: It's a really good question. [laughs] WILL: I always wanted to peel back the layers of Chad. VICTORIA: [laughs] WILL: So that's what it is. [laughs] CHAD: To tie it back to development, just like you just did, I think a lot of our values and the way that we do things come from the way that we believe products should be designed and built. When I'm working on a project, I don't want to be told how to do everything. I don't want every ticket to be specified without me being part of the understanding or decision-making process. I want to be able to collaborate with the people that I'm working with, understand the problems that we're trying to solve, and then pick up the ticket and do the research, figure out the best way to solve it or be part of that. And when it's not clear to me, ask questions, learn from other people about the right way to solve something might be, and then to implement it in the best way that I know how, and collaborate with the people that I'm working with as I do that. And then I pick up that ticket, and I'm responsible for deploying it to staging and asking for acceptance of it. And I'm responsible for deploying it to production. So I'm pushing my work. I have agency over my work at every step of the way. I hope everyone who's listening has had an opportunity to be on a project where you've truly had agency over your own work. It's a really good, fulfilling feeling. And so I think that's where it comes from. I think that's what I try to bring to everything that I do. VICTORIA: And I think that philosophy is what creates such a compelling company culture and makes people want to work here, right? CHAD: I think so. Particularly because the work we do, the majority of us are designers and developers, but I don't think it's just design and develop. Like, it resonates a lot the relation to product work. But I think that's true for fulfillment in your own work generally across the board, no matter what your role is. People would rather have agency over their own work than to be micromanaged, to be told what to do all of the time. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. VICTORIA: In 20 years of hiring people and building products, what has really changed in terms of what you see customers looking for in building products, and what's stayed the same? CHAD: There's a lot that has changed, mostly in terms of platforms and practices. When we were first getting started out, the practice of test-driven development was not generally established as a best practice. It was one that we needed to advocate for and fight for, and really put ourselves out there as this is what we believe about the way good products are built, and if you don't want that, we're not a good fit for each other. So that's what I mean by practices. A lot of those things that used to be controversial we sort of won on as they played out as, yes, general agreement now about certain best practices. And so that has evolved over time. The other is mobile development. You know, when we first started, that wasn't really a thing. We did some mobile development early on for Palm platforms and for Motorola platforms using different versions of Java. It was a very different ecosystem. And mobile development has evolved a lot and become...almost every project we do has some mobile component. And a lot of them are native mobile applications with an API back end that we're building as well. So that has been a big change. The things that stay the same are, I would say, the things that we have sort of been constant about. So in the way that best practices change or evolve, the constant has been that we put ourselves out there, willing to be opinionated about what we believe the current best way of working is. That means that the clients who work with us are coming to us wanting that. And that leads to a culture of work and quality and that kind of thing, which I think has been pretty constant over the years. But it's not because we didn't try. Like, if we were willing to be anything to anybody and to compromise all the time and those kinds of things, it wouldn't be a constant. But we work at it, but I think that feeling of what it's like to do this work has been a constant. WILL: Speaking of changes and constant changes sometimes, what's the story behind the handbook? Everyone at the company can access the handbook through GitHub and how [inaudible 29:35] Whose idea was it? How did that come to be? And explain how it's always changing and what that looks like. CHAD: Yeah. So, like you said, we have our company handbook and the public playbook in a source code repository that everyone at the company collaborates on and has access to change. I don't remember who initially moved it into version control. It started as a document. We worked with an outside payroll or HR company to make as our first company handbook. It had policies and those kinds of things in it. At one point, you know, we were doing some revisions, and maybe me, maybe somebody else said, "Let's move this out of this," whatever it was at the time, Word doc, or whatever, "and move it into Markdown and natural place we want to have version control on it." But even though we moved the document into version control and even though everyone at the company technically had access to it, I think for many years, we still did things like a lot of companies do, which is the version control in and of itself isn't the special thing. It's using GitHub issues to track actual problems that we know about, or potential issues that we know about, defects in our policies, our practices, the company itself, just like we do on our software products. That was the actual fundamental shift that we made because it completely changed the way that we make change at the company and organize the work that we do to improve the company. And the way that that happened was, I think, prior to that, we made changes in a lot of ways that companies make changes. So some people know about some things, some people don't. Typically, senior leaders will get together often in meetings and talk about the issues that they see. And they tend to result in really big changes all at once that attempt to address multiple issues or make big reorganizational changes. And there's a tendency not to work iteratively when you work that way, and we did the same thing. So the sort of final big event that happened that triggered the fundamental change of working was, at the time, we had an unlimited time off policy. We had gone to that a few years prior because it was a trend in general. But also, we were tired of sort of tracking time and the permission that happens around time off and all that kind of stuff. So we had sort of blown it all up and gone to an unlimited time off policy. But it's more well understood now that unlimited time off policies have a few issues. And we were seeing those issues. Time off was very inconsistent among everyone on the team. Particularly, new people would join the company, and they'd be like, okay, yes, but how much time am I supposed to really take? So that was one issue. Another issue was we wanted to increase the amount of parental leave that we offered as a company, like, on paper. Now, technically, we had the unlimited time off policy, but you want to give guidance to people, and you want to be able to say in a job advertisement that you have this much parental leave, you know. And because we're a consulting company and we make our revenue when people are working, the question was asked, how much can we say that we have for parental leave? And it was a very uncomfortable position for us to be in to not be able to work that financially because we could say, okay, we have 12 weeks of parental leave. But, at any point in time, anyone else could take more time off for any other reason because we had unlimited time off policy. And the idea that we couldn't prioritize one kind of time off over another to make it work financially was uncomfortable to us. And then, the state of California passed a sick time law, which was fundamentally incompatible with unlimited time off policies that lump sick time and vacation time together. And so we knew about these things. We got together in a meeting. We talked about them. And we put together a pull request to the handbook that, you know, we said, you know, we could probably fix any one of these problems. But probably all signs are pointing to just switching back to a regular time off policy. And so we put together a pull request. You can probably guess since I'm telling this story that, generally, people were very surprised. It was a big change to take in all at once. And I think even though we have a high level of trust, as a company, it was hard for people who generally viewed an unlimited time off policy as a good thing. You know, they were worried that there was some ulterior motive there, that something was being taken away for some reason, maybe financial. So we worked through it, and the pull request is there for everyone at the company, so you can see. Anna, when she opened the pull request, outlined all of those reasons why, but it was a lot of information to take in. And after we made it through, it sort of caused me to reflect on the process. And there was good criticism from members of the team at the time about the process, and we really took that in. And I think it was the state of California passing that law that the solution that we arrived at to mind for me because they passed the law in, whatever it was, the spring or the summer. And it wasn't going to go into effect until the new year. And that's really no different than, you know, a new version of a library is going to come out, or a new version of an operating system or a browser is going to come out. And we know it's going to break our app. What do we do? We create a ticket in the backlog. We describe what the problem is. We prioritize it among everything else we're working on. And we make sure that the fix is in place in time for that to be released. And yet, we weren't doing that for these very obvious defects or things that we knew were going to break an existing policy against this kind of stuff. So I was like, we could use GitHub issues to log problems that we know about that are out there, and not only would that have led to a lot more transparency along the way. When a change was made, people could have come along that journey with us of identifying the problem, being aware of it, being part of problem-solving, and coming to a resolution, and then getting a pull request. But more fundamentally, I think once you start to work that way, probably would have never made the change that we did in the first place because this way causes you to work more incrementally, to work more iteratively, to take each of the problems to try to identify the root cause and the best way to fix it. And very often, that is a smaller change that you can put into place more quickly. And we know that we don't need to get it perfect. We don't need to change absolutely everything about this all at once in order to fix every problem. We just need to make tomorrow better than today. If we can do that, then we know that, over time, it adds up to significant positive change that is very different a year from now or two years from now than what we're doing today. But we do that by chipping away and making tomorrow better than today. And so working this way with these discrete tickets, with this thing, there are downsides too, don't get me wrong. It's not all sunshine and rainbows. It's hard to work this way. But those are some of the benefits and sort of the story of how we arrived at how we do things. WILL: I love that because I'm familiar with creating PRs, commenting on PRs, just giving feedback through PRs. And also, I've never been in a leadership meeting at thoughtbot, like, just never been in one. But I know that if I comment on a PR, my voice is heard with leadership making the decision. I love that idea. CHAD: Yeah, leadership meetings at thoughtbot are actually very boring. WILL: [laughs] CHAD: Because the only things that we're talking about that aren't represented in GitHub issues are things that aren't proper for GitHub issues, so they're individual personal problems or things like that, or, hey, we're doing a leadership training and, you know, talking about that. Actual change, actual things that happen, are represented in those GitHub issues. And that's why it's super important that we have issues for everything because when we truly work this way, if something's not represented as an issue, it's not getting worked on. There's not a lot happening in leadership meetings other than those things that aren't ideal for GitHub issues, or we're going through, and we're saying, "Hey, this issue has been sitting around for a while," or "What's the update?" And you'll often see someone comment after the fact about an issue. Now, that being said, I think one of the hardest things about this is that when you expose these big issues, it can be a little discouraging over time to have them be around there to be not closed. But the way...I'll bring this back to our product work as well, like, when you identify...at least this is the case for me. A bug could have been there for two years, [chuckles] and I don't know about it, and therefore, it's out of sight, out of mind. I didn't know about it. But the minute I find out about a bug in a product that I'm working on, I can't stop thinking about it, and I want to fix it so badly. It becomes my top priority right away. [laughs] And I have to remind myself that just because I know about something now doesn't mean it's actually the highest priority item, or that I can fix it, or that I should take the time to fix it. I know it's my natural tendency to do that. So shedding light on something that's positive in and of itself, and then we can chip away at that over time. And this way of working allows us to tackle big problems. But sometimes it doesn't feel so great because you're identifying sort of defects in the company itself that make everybody uncomfortable. But I would rather light be shed on those so that we have a chance to improve it than to have it go unidentified, just like bugs in our products. VICTORIA: And just to illustrate, we have 162 open issues on our handbook. [laughter] But, you know, from my perspective, that makes me really excited, like, people are engaging with it. They're putting in issues and creating it. Because I've converted a company handbook to GitHub before, and no one ever looked at it. [laughs] So it was actually kind of nice that -- CHAD: [laughs] VICTORIA: You said that it took some time to build up that interaction with it and make people feel comfortable. And I wanted to ask about actually your Dungeons & Dragons campaigns that you run with the company. And I'm wondering what skills or practices from that comes over into your leadership style or the culture at thoughtbot. CHAD: Ooh, I'm not sure it's as deep as that, Victoria. VICTORIA: [laughs] CHAD: I just really like [laughter] playing Dungeons & Dragons. But I will say the itch that it scratches for me and the reason why I like Dungeons & Dragons, and the reason why I'm really happy to play it with thoughtbot people...my degree is computer science. But all throughout elementary school, high school, I did improv and theater, and I have a degree in theater as well. For a long time, Dungeons & Dragons is essentially doing group improv with other people around a game. And to be able to bring those two things together with a group of people that I like to have fun with it's a really great outlet. And I really enjoy it. But I'm not sure that there's anything deeper than it sort of scratches that performance itch that I have with a group of people that I like to hang out with. VICTORIA: That's fair. And then, just to kind of go back to one of our earlier questions we asked —what would you go back in time and advise your younger self —now, what if your younger person could travel to the future and give you some advice, looking at where you are at now? CHAD: The only way that I've done this for 20 years is day by day. Like, each day, you get up, and you approach each day. This is the way I do it anyway. It's like I approach each day as a fresh day. And now, over thousands of days, it's been 20 years. And I think that that is part of why at least I've been able to do this so long is I don't do a lot of dwelling on what happened yesterday. I think about today and tomorrow much more than I do about what happened yesterday. The upside is I've been able to do this for 20 years. [laughs] The downside to that is you tend to not reflect so much on the good things, just like you don't reflect so much on the bad things. You tend to not celebrate the milestones when they happen or appreciate them as much because you're onto the next thing. You're thinking about tomorrow rather than yesterday. And so I would think that if my younger self came forward and talked to me today, I think the thing that he would say is like, hey, look at where you are, look at what you've done. Take a moment [laughs] to celebrate not only your work but, you know, this is true for the people around me. I tend not to celebrate the accomplishments as much and everything because I'm very much someone who sort of lives in maybe not even the moment but the next moment that's about to happen. And so I think the person would say, relax a little bit, have a little bit more fun. Take a moment to celebrate the people around you a little bit more. I think that's what I would say to myself. WILL: I love learning things that I didn't know about thoughtbot. So this has been perfect. CHAD: Thank you both for the really thoughtful questions. And on the note of what I just [inaudible 44:53], thank you for everything that you both do at thoughtbot. I really appreciate it. We couldn't have accomplished everything that we have without the individuals [inaudible 45:01]. So I'm here sort of representing thoughtbot for our 20th anniversary, but it's not just me who got us to this point. It's been a lot of other people over the many years making it happen. And so I appreciate both of you for helping make it happen. VICTORIA: Well, thank you. And again, thank you so much for joining us. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you could find me @will23larry. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Sponsored By:thoughtbot: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devopsSupport Giant Robots Smashing Into Other Giant Robots

Brian Douglas is the CEO of OpenSauced which helps enterprises discover the best engineers in Open Source. Victoria and Will talk to Brian about meeting as many developers as possible, setting goals, and keeping himself accountable, and what makes a successful open source project. OpenSauced Follow OpenSauced on Twitter, GitHub, Instagram, YouTube, Discord, and Dev.to. Follow Brian Douglas on LinkedIn, Twitter, or visit his website. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. JORDYN: Thanks for having us. DAWN: Yeah, glad to be here. VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. JORDYN: Wonderful. VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. VICTORIA: What made you decide to start this incubator program this year with thoughtbot? DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. VICTORIA: Wonderful. That's amazing. Thank you both so much. INTRO MUSIC: 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 host, Will WILL. And with us today is Brian Douglas, CEO of OpenSauced, helping enterprises discover best engineers in open source. Brian, thank you for joining us today. BRIAN: My pleasure. Thanks for inviting me on the podcast. VICTORIA: Just tell us a little bit more about OpenSauced. BRIAN: Yeah, it's opensauced.pizza is the URL. So I always point that out because it's easy to found. WILL: I love it. BRIAN: And OpenSauced is a platform for engineers to find their next contributions and enterprises to discover the best engineers doing open-source, so... VICTORIA: Right. So maybe tell me what led you to start this company? BRIAN: Yeah, that's a great question. Actually, if you don't mind, I'll start further back. I graduated college in 2008 during the financial crisis with a finance degree. And what I learned pretty quickly is, like, if you don't know anybody in finance, it's a little hard to get a job in a bad market. So I took a sales role instead, mainly because I just wanted to learn. I was very much introverted. I wanted to learn how to talk to people, and have conversation, and communicate. So I did that four years and then got my MBA. And then started learning how to code while building an app, which is...I mentioned before we hit record I learned about this podcast around that time, which is, like, very serendipitous to be on this podcast years later. But, fast forward, OpenSauced, like, because of the whole networking aspect of how I got my job in sales and how I was able to do sales when I learned how to engineer, I knew the connection to open source, or how I learned how to code was, like, a wealth of information. So I made it my career goal to meet as many developers as possible. And then, I was working at this company called Netlify. I was employee number three there. And my role was to basically be a front-end engineer, but where I was actually getting more adoption to the product by doing open source. Like, every time I'd do an open-source contribution, I'd add a Netlify deploy preview manually in my PR. And that would give the maintainer enough juice to review the PR sooner. And I was doing a lot of open-source contribution at the time. So I wanted to build a tool to maintain, like, all the PRs I had opened in-flight that I needed to respond back to or...because back in, like, 2016, notifications on GitHub they weren't the greatest. WILL: [laughs] BRIAN: So I built a tool just to keep up to date on what I had opened and how I can communicate back with the maintainer. And saw a need...actually, I didn't see the need. I used this thing myself, and then in 2020, I started live streaming myself, building more features on top of this, like, CRM tool, and had a few people ask, "Hey, can you add a login to this? I'd love to use this, too, with my own database and stuff like that." So I did that. I added login. And I say database, like, we actually originally started with no database. We used GitHub Issues as a tracking mechanism for tracking repos and conversations. We've since moved away from that because, now, obviously, GitHub's got way more advanced in how notifications work. But the sort of ethos of the project still lives today, and what we have in the open-source platform. So that's, like, the long tale of how we got to where we are today. And then, I spoke at GitHub Universe on OpenSauced back in 2017. And from that talk, I had GitHub employees reach out to me and ask me to work at GitHub. So I accepted, and I worked at GitHub for almost five years, sort of putting OpenSauced to the side up until last year, decided to go ahead and pursue it again. And at that point, decided to make it a company. VICTORIA: What a cool story. There are so many things in there that I want to follow up on. I'm sure, Will, you also are like -- [laughs] WILL: [laughs] Yes. VICTORIA: I have so many questions. [laughs] WILL: Wow, that's amazing just hearing the story from you [laughs] got a four-year degree in finance, 2008 happened, no job, very hard to get a job because of who you know. And then you go and changed directions to start learning to code. And I love how it's kind of guided your path to where you are here right now. Like, who knows? But would you have been the CEO of OpenSauced if 2008 would have never happened? So it's amazing to see it. So, I guess, because I love the idea of OpenSauced...because I am that developer that wants to get into open source, but it is hard. It is hard to find the issues that you can work on. It's hard to get into the community to do that. So, if you can just explain to me a little bit more as from there, and we can do it from the enterprise portion later. But, as far as a user: a developer, what does it look like for me to use OpenSauced as a developer? BRIAN: Yeah, yeah. And that's a great question, too, as well. It's funny how serendipitous the story is today, but when I was living it, it was like, oh, man, I'm never going to get a job. [laughter] Or I'm never going to learn how to code. And I think anybody listening who might be where I was ten years ago, I just want to preface, like, your story is like a guided path through experiences. And every experience is like an opportunity for that sort of one piece of, like, the sort of stepping stone to move on to, like, CEO of whatever your next startup is or senior engineer, or staff engineer, whatever it is. But, to answer your question, Will, we built a Discord, and the Discord itself is how we sort of discovered this sort of onboard ramp into open source. So today, if you sign up to OpenSauced, again, opensauced.pizza, you connect to your GitHub account, and you get on-boarded into a flow to ask a couple questions. So, like, what languages are you interested in? And then, what time zone are you in? And the reason for those two things is, one because we're going to do recommendations for projects pretty soon. Everything is open source, so you can literally see the issues that are open about recommendations; happy to take contributions and feedback on it. And then time zone is because communication is pretty key. So, like, if someone is not awake when I see their PR, I have an expectation of, like, cool, I'll write a response, and I'll wait for them to wake up and respond back to that. So the goal there is there's a lot of projects on GitHub, like, 372 million repos is the number off the top of my head. They literally announce this stuff, and they share the data. But of those repos, only 225,000 have more than five contributors. Understanding what you're looking to accomplish first out of doing open source to either share knowledge, or gain knowledge, to get exposure, to get a job, or just to enhance your current job by go try something that's not in the roadmap of what you're working on. Eventually, we'll start asking those questions around, like, what type of contributor that you want to be, so we can start recommending those types of projects. But I mentioned that 225,000 repo number because there are a lot of projects that don't have five contributors that could use their second contributor, or third, fourth. And my recommendation is always find up-and-coming, like, growth-stage projects. A lot of people want to contribute to React. You had mentioned you did React, Will. That's a really big lift to go contribute upstream to a project maintained and supported by millions of enterprises around the world. But there are tons of projects that go trending every week that have no documentation, that have no README, that have no structure and are just getting off the ground. Like, those are the best projects that we try to showcase. So, like, that's hot.opensauced.pizza is our sort of up-and-coming project list. And the way that works is like projects that are trending based on our open-source community; we surface those there. There's a lot of work we have to do on that project. That was, like, a Hack Week project we did a couple of years ago as a community. But the basis of that is they're looking to build our recommendation engine off that. So, step one is find a project that is welcoming, that needs some work done, and then find the path in. So the path usually is going to be your CONTRIBUTING.md, which is like established projects will have this. But if you don't find a CONTRIBUTING.md, but you find a project you want to use, chances are you could build that CONTRIBUTING.md and ask the question, so, like, hey, how would I contribute? Like, how can I be supportive? Actually, I did this talk a couple of years ago at Juneteenth Conf. It was a remote conference on Juneteenth, which a bunch of Black Engineers we all gave our technical expertise sponsored by Microsoft. And I was talking about the idea of open-source hospitality. The best thing you could do is be that sort of hospitable person, either you're a maintainer or a first-time contributor. Like, be that person to set it up for the next person behind you. And the idea of hospitality, you go to a hotel. Like, you know where the towels are. Like, you know where the soaps are. Like, you know exactly where everything is all the time. And, in open source, like, if we could set up our projects in a very similar fashion, like, not franchise them in a way like the Hilton or Marriott, but set the expectation that there is a way to source information and to interact and operate, so... VICTORIA: Yeah, I mean, I love, [laughs] like, hot.opensauced.pizza. That's hilarious. And I love how you have used humor to...even though it's a very serious product, we're making it more friendly and more hospitable like you're saying. And I like how you said, you know, the journey is cool looking back on it, but it was really hard to go through it. And now you're this wonderful speaker and a CEO. But you said that you weren't actually good at talking to people at first. And you specifically sought to get better at that skill. So I wonder if you would share more about that, how that's impacted your career, and why that's important as a developer to have those communication skills. BRIAN: Yeah, it's like...I have a twin brother since birth, basically. And my twin brother is very extroverted. Like, he actually used to wait tables in college. It was like he was the person that would make you feel very special as a server. Like, he's the type of person that kind of lights up the room when you walk in. His name is Brock. My entire life growing up, I was always Brock's brother. And it's like, oh, you're Brock's brother. And it's like, yeah, I'm Brock's brother. And I'm more of a person, like, if you meet me in person, like, I'm very much reserved. I'm sort of reading the room, waiting for my point to jump in. And I made it a point for me to, like, have enough comfort to speak on a podcast or speak at a conference because I knew that skill set would be valuable. Because I definitely had, in my sales career, definitely got overlooked for a lot of opportunity because folks thought, oh, I don't think Brian could do it. So coming into tech and seeing that when every time I went to a meet up...because meetups also are places where I cut my teeth and got to learn about the industry and the community. They always needed someone to speak. So I was, like, oh, there's an opportunity. I can leverage this opportunity of them always looking for speakers and me always wanting to share knowledge and learn something new to do talks. So my first-ever conference talk was in San Francisco. And I had learned React Native, but prior to React Native, I had learned Objective-C. And then, in between Objective-C and React Native, I learned Swift because React Native and Swift came out the same year. Well, React Native went public, open source, the same year as Swift. So it was like a really interesting year back in; I think it was 2017 where...actually, it might have been 2016. But, anyway, everything came out at the same time. And I was learning iOS development. So I made it a point for me to give a talk. But my pet peeve for giving talks is, a lot of times, people just go directly into the code, and there's, like, no connection to a story, or why do I care about this? So I always bring storytelling into my conversations and talks. So, like, that talk about Swift, and Objective-C, and React Native, I made the comparison of, like...it was the same year that Kanye West took the mic from Taylor Swift at the VMAs or whatever the award show was. And the correlation was React Native took the mic away from Swift because it built similar interactions for JavaScript developers to understand and build iOS applications that was not like Ionic or RubyMine or...I forgot the Ruby one. But, anyway, what I'm getting at is, I just wanted to bring story to this because usually what happens is like, you see cool things, but you never remember what the name is. You try to find that REPL again, or you try to figure out who that speaker is. And it's usually hard to find it after the fact. So, like, my goal was always to make it memorable, which is why I go by Bdougie because Bdougie is easier to Google than Brian Douglas. Shout out to Brian Douglas, who's based in Ireland who does system engineering, and has a great YouTube channel. Like, I want to be memorable. And I want to make it easy for folks to find me after. So, while at GitHub, when I was developing all this sort of like Kanye West-type speaking and stuff like that, well, literally, I would use Kanye West years ago as the example to understand storytelling. I no longer use Kanye West. I'm now a Beyoncé advocate. [laughter] So I use Beyoncé instead. But I guess what I'm getting at is, like, I just had a goal. And I knew if I could teach myself to code...and it was about 17 weeks it took me from zero to ship a Ruby on Rails app. And I felt confident enough to talk about it. I knew basically anything I could just accomplish just by putting some effort and consistency behind it. So that's the...sorry, that was a little more long-winded than expected. But I just keep accountable and set goals for myself and try to achieve enough to feel proud about at the end of the year. WILL: Yeah. It's so funny because I recently had a similar situation. At thoughtbot, we try to engage with the community, and one of the ways was writing a blog post. I've never been a writer. It just hasn't been my thing. But I was telling my boss, I was like, I'm going to do that to get outside my comfort zone and to really stretch myself. And at the same time, I was like, why a blog post? Like, I don't know, it doesn't really make sense why a blog post. Well, when I started writing the blog post, I was like, oh, you have to really know, one, what you're talking about in order to write about it. And so I had to really do some research, really had to study it. And I finished it last week. And then, now, looking back over the last couple of months it took me to write that blog post, I'm like, wow, I feel stretched. But I feel really good, and I feel really good about the topic that I did. So that's interesting that you went through that process to stretch yourself and to grow and even learning to code and get to that point. So talking about...you were at Netlify, and then you worked at GitHub. And then you're at your current one OpenSauced. How have Netlify and GitHub, the work that you did there, how has it prepared you for your position right now? BRIAN: You know, actually, that's a great question. I don't know how much thought I put into that. Like, Netlify prepared me because it gave me an opportunity. So I was employee number three, but I had a sales background. And so I got to be an engineer, but they kept always trying to ask me like, you know, business questions and strategy. And, like, I pitched them a 30-60-90 in my interview of, like, what's the growth strategy of Netlify, like day zero when I start? And I go into way more detail in other content. But that prepared me because I got to see how startups work, being so early. I got to see that startup go from seed-funded, just closed their seed round to get their series B is when I left. At GitHub, I got to see what it looked like at a bigger company, which, like, it doesn't matter how big or small you are, like, there's always chaos. Like, GitHub was, like, so much chaos, and there was a lot of good that was happening but a lot of uncertainty at the time I joined in 2018. And then, nine months later, Microsoft acquired GitHub. So then I got to learn stability and what it looks like to...for personal reasons, I always had a budget but never had extra money, even years into my engineering career. And that taught me what it looks like when success meets career. With that being said, like, the problem that I'm solving, I got to learn firsthand while being at Netlify and getting adoption and traction through open source. And then going to GitHub and seeing every single other company that looked at GitHub as a solution to their open-source collaborations and interactions. And then also seeing that there was a hole in just understanding, like, how do you survive? How do you sustain yourself as your career but also your open-source project? Like, a lot of folks want to know, like, what success looks like for open source. Like, how do you get on the trending algorithm? Like, how do you get noticed? It's more than just pushing to GitHub and hoping for the best. There are, like, other things that happen for projects to be successful. And for us to choose the next in the future technologies, it really comes down to community, marketing, and then resources. And those three things end up making projects successful. With OpenSauced, we're working to help inflate some storytelling and add some of those resources to open-source projects. VICTORIA: Great. So you were able to really get, like, the full vision of what it could be if you had a product that became successful and stable, and you knew you wanted to build it on open source. So I love that you really just...you had this problem, and that's what you built the product around. And that ended up becoming the business. What was surprising for you in those early discovery phases with OpenSauced when you were first thinking of building it? BRIAN: I guess what's really surprising is we're not, like, crazy traction today. But we've done a pretty good job of getting, like, 2,000 developers to sign up to it since December. And then the conversations with enterprises so far just by the sheer...like, basically, what was surprising is if you use proper sales technique and you're early stage as a startup, so, like, not necessarily hire salespeople, but as a founder or as a stakeholder, just go talk to your future customers and your users. Everyone says it, but that's actually super valuable. And I think in the same vein of open source, folks they see projects die on the vine, but then you see projects succeed. And I think it also comes down to how often the maintainer of the project is talking to the contributors and the users and also that distinction as well. There are folks who want to contribute code to the codebase, but then there are folks who want to use the codebase. And, like, how do you interact between the two? And how do you cross the chasm for those folks as well? And, a lot of times, it's just fascinating just, like, just by trying, and just by showing up, that's half. It's all cliché stuff, like, I could say, but it's all true. Like, showing up is, like, it's, like, step one. Just show up, do the thing, do the work. And then talk to people is, like, step two. And it's hard to say, like, okay, yeah, because we are not a multibillion-dollar company, like, we're just getting started. So I can't say, like, yeah, we're super successful. But we've survived the year. And we've survived the year based on those two steps, the showing up and then talking to people. Because a lot of times, we could get lost in the sauce, per se, of just shipping code and never talking to anybody and never coming up for air. And I think what I learned, going back to what I learned from GitHub and Netlify, is talking to people and getting that feedback loop going is the best thing you could do for any product. Any early project, any feature you're working on, talk to people about it and see if it's actually valuable for somebody that after you ship it, something will happen. WILL: You're talking about communication is a big thing for a successful project. Have you noticed any other trends that make a successful open-source project? BRIAN: Yeah, that's...Any other trends? Yeah. I mean, AI, [laughs] just kidding. WILL: [laughs] BRIAN: No, I mean, but it also it is true, like, having a trend not sort of following the herd, but catching the herd earlier is extremely valuable. Like, at Netlify, we caught the trend of React. So, basically, Netlify built essentially GitHub Pages but a product and a company. And that was, like, the original project of Netlify. It's expanded so much further from that. But at that time, when I joined, I joined three months before Create React App was developed. So, like, it was a CLI tool to build React apps easy. And, prior to that, React was, like, super complicated to get up and running. Like, you had to know Webpack. You had to know, Babel. You had to make all that glue happen together. And then there wasn't an easy process to go host it somewhere. So the prevalence of build tools like Grunt, and Gulp, and Browserify, they all made it easier to build a static output from React. And that trend is what took Netlify to where it is today. It's like, people needed a place to deploy these static applications. GitHub Pages was like the solution for a lot of folks. Because Heroku, like, why pay $7 for something you could host on S3 for free? But the challenge was S3 it requires way more thought in how you host and take it down and deploy, and then it becomes like a Kubernetes nightmare. So the trend there was, like, people just wanted to have a better developer experience. When it comes to, like, open source, the developer experience in JavaScript has improved so much more. But folks are now looking at the next thing like a Zig, or a Rust, or all these other new languages and server renderings and stuff like that. So I guess when I take a step back, when I look at how I chose things I wanted to work on, and communities I wanted to hang out in...before committing to React...I'm based out here in Oakland, so San Francisco, basically. By seeing the sheer number of RSVPs to the React meetup, it made me confident that React would be something I should pay attention to. When you look at the RSVPs of now all these AI meetups that are happening in San Francisco, like, every single weekend is a hackathon. Highly confident that if you're engineering today, you probably want to know what embeddings are and know how OpenAI works. Not that you necessarily have to build AI stuff, but it is going to be the thing that people are going to be using. So just like we had to learn build tools, and servers, and CDNs prior, now it's all trivial stuff that you can sort of use Cloudflare for free. Like, AI is going to be very similar, and it's probably going to happen much quicker. But, in the time being, the trend right now is, like, you should probably understand whatever the players are in that space so that way you're able to talk confidently about it. WILL: That's really good advice, yep. VICTORIA: Absolutely. And, you know, in my role as Managing Director of Mission Control, or, like, DevOps, SRE platform, I spend a lot of time looking at trends, more on the engineering side. So I think my question is, [laughs] as someone who hires people to work on open-source projects, and who actively maintains and contributes to open-source projects, what should I be thinking about how to use OpenSauced as in my role? BRIAN: For hiring and sourcing skilled folks, we're actually working on a tool right now to make it more discoverable. So, today, when you onboard as an individual developer, you can check a box in your settings to say, like, if you want to collaborate with other folks, you have to opt into it. So if you want to be discovered on OpenSauced, it's in the settings. We'll probably expose that and share more about that in the future, like, in the next month or so. But for, in particular, our user flow today for folks looking to find other people to contribute alongside their project is, you add your project to what we call an Insight Page. You click on the tab on the top and create a page with your project. And then, you can see contributions in your project in the last 30 days. And then you can also add other projects like your project, so you can see who else is contributing. So, that way, you can start discovering folks who are making contributions consistently and start to get some stories of, like, if they're interested in collaborating, they'll check that box; if they're not, the box won't be checked. But at least you know the sort of scope of the ecosystem. As an individual developer, we have the onboarding flow, but then we also have highlights. So, eventually, we'll do recommendations to get you to make contributions. But, for now, if you're already making contributions, you can highlight the contributions you've made so that way, you're more discoverable on the platform. And the highlights are very much like a LinkedIn post or a tweet. You just drop in a PR, and then we'll either generate that description for you, or you write a description: I did a thing. This is what it was. This was the experience. And then, now you're attached to the project through not just a code contribution but also a discovery mechanism, which is a highlight. And then, eventually, we'll start doing blog posts, and guides, and stuff like that, as they're written. Like, if you want to attribute your career, and your journey to your participation to, like, documentation updates and stuff like that, those will also be highlights coming soon. WILL: I love, love, love that. MID-ROLL AD: Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoff WILL: I hear you saying that you have some things that's coming soon. In a high, high level, what are some of the things that you have coming? And what does success look like, six months, a year? What does that look like? Because it sounds like you have some really good ideas that you're working on. BRIAN: Yeah, yeah. So, like, six months to the end of the year, what we want to do is actually start getting more deeper insights to what's happening in open source. What we're doing right now is building the individual developer profile and experience so that way, they're able to be discovered, find projects to work on. And then what's next is there are tons of enterprises and companies that are maintaining open-source projects, SDKs. And what we're seeing right now is we're seeing massive layoffs happening currently in the industry. So like, as of today, I think Facebook laid off 4,000 people, ESPN laid off, like, 7,000 Disney employees as well. And some of those employees are around the Disney+ place. It's a lot of technical engineering stuff. So I guess what I'm getting at is there...we want to be able to see the trends of places that activity is happening and start recommending people to that. But also, we want to give an opportunity for folks who...companies...sorry, I'm avoiding trying to name specific companies because nothing is in contract yet. But certain companies, like, you, don't think of as an open-source powerhouse. So, like, a company we're now talking to right now is walgreens.com. And Walgreens they have tech. They've got open source that they participated. But they're not thought of as a place like, oh, I want to go work at Walgreens and go work on some cloud infrastructure stuff. So, how does Walgreens get exposure? And, like, hey, we're involved in the kubectl, and the Kubernetes platform and stuff like that, like, be aware that there's opportunity here. So we're going to start driving that connection to folks. So, as you develop your career doing open source, you can also be noticed, and folks can reach out to you. And also, I want to stand on the notion of open source is not for everybody. But I also want to point out, like, my entire career in open source has not been nights and weekends. It's always been finding a company that supports my interest to do open-source at work. Part of my story is, like, I was getting an MBA. My first kid, who's nine years old now he, was born 11 weeks early. And he's the reason why I built an app because I wanted to build an app to solve a pain point that I had, and ended up building that in 17 weeks. And that turned into opportunity. So I guess what I'm getting at is, like, folks being laid off right now, you might have some extra free time. You might be submitting like 100 applications a day. Consider taking that down to 50 applications a day, and then try to contribute to a couple of open-source projects a month. So that way, there's some more story to be shared as you're in the job market. VICTORIA: I love that you created that app when you had your son and you had that need. And for developers wanting to get noticed and wanting to get their next leg up or maybe even negotiate for higher salaries, what's the traditional way people do that now to kind of highlight themselves? BRIAN: The traditional way what people are doing is they're tweeting. They're speaking at conferences. They're sharing their stories. It's like zero to I'm an influencer in the open-source space. There's no real clear guide and steps to get to that point, which is why we have highlights today. Like, we want to make it low effort for folks to write 200 characters about something they contributed to. We're actually working on something to generate pull request descriptions because I think that's another missed opportunity. Like, when you open a PR in an open-source project, and it says no description added, like, that's a missed opportunity. Like, there's an opportunity for you to share what you've learned, what Stack Overflow questions you looked at, like, how you got to the problem, and why this is the right solution. All should be in the pull request description. And then that pull request should be in your cover letter for your resume so that people can go back and say, "Oh, wow, you did some real work." I can go see the history of your contributions because perhaps the job you got let go from you only worked in private repos. You couldn't really showcase your skills. That now gives you a competitive edge. And I guess when I look into this, like, going back to my original onboard ramp into engineering, I graduated with a finance degree with no network. I had one internship at an insurance company, but that wasn't enough. Like, everyone who I interned with, like, the guy who got a job at the internship, like, his dad was a client, was a big client at that firm. And another guy he worked at a golf course, and he'd be the caddy for all these big finance folks where I went to school. So, once I learned that there's an opportunity to get a job by just knowing people, that changed my entire path. Like, when I got to sales, like, oh, or when I got to engineering, I just knew go and meet people. Go have conversations. Go to meetups. What I'm trying to do with OpenSauced is make that step closer for folks, so they could look up and be like, you know, I've made all these contributions, or I don't know where to start. Let me just look at people who I know and follow in the industry and see where they're contributing, and make that connection. So, like, we've kind of closed that gap without the need of, again, you don't need 100,000 Twitter followers to get noticed. Just make some contributions or show up and ask questions. And, hopefully, that's the first step to establishing your career. VICTORIA: Well, that sounds great for both people who are looking to get hired, but also, as someone who hires people, [laughter] I know that there's a lot of amazing developers who are never going to do a conference talk, or they're not going to post on Twitter. So I love that that's available, and that's something you're working on. BRIAN: Yeah, it's just coming out of my own pain of, like, I was saying, like, looking at the story now, it sounds great. [laughs] But part of that story was like, hey, I was getting severely underpaid as an engineer in San Francisco, living in a one-bedroom apartment with two kids. Like, all that part of the story is like nothing I dwell on. But it's like, all that opportunity and knowledge-sharing that I ended up benefiting from, it's like what I constantly try to give. I pay it forward with folks. And I'm more than happy to talk with folks on Twitter and in OpenSauced Discord and other places because I think there's a lot of opportunity in open source. And if anybody's willing to listen, I'm willing to show them the path. WILL: I'm so glad you brought that up because this is one of my favorite questions I ask on the podcast: So, knowing where you're at right now and your story, you've gone the ups, the downs, all of it. If you can go back in time and know what you know now, what advice would you give yourself at the beginning? BRIAN: Honestly, I would say write it down. Like, one thing that I did is I did a blog post, and that's part of the reason why I was able to find my first job in engineering is I started a blog, which was really for myself to learn what I did yesterday. I tell everyone who I mentor it takes two hours every time you want to sit and learn something new because one hour is to remember what you did yesterday, and then one hour is to do something new. And so, I usually write it down and then make it a blog post just to solve that problem. I wish I did more with that, like, you know, wrote a book, or created a YouTube channel, or something because all that knowledge and that sort of sharing is actually what got me to level up faster. I was asked by one of my close friends, like, "Hey, how do you do it? How do you accomplish everything you've done in the last, like, 9-10 years?" And I didn't know what the answer was then. But the answer today for my friend, and I'll share this with them, is it's because I wrote it down. I was able to go back and see what I did. And then, at the end of six months, I was able to go back six months and see what I did. It's like the idea of relativity with, like, Einstein. Relativity is the idea of motion and the perception. Like, if you're in a train, it feels like you're just going slow. But you might be going 100 miles per hour, but you don't feel that. And when you're going on your journey, you could be going 100 miles per hour, but you're thinking, oh, man, I failed yesterday. I could have solved a problem. But yeah, you solved six problems while trying to solve for one. It's that situation. So advice for myself, in the beginning, write it down and then share it way more than I did when I started. Because a lot of the stuff I'm like, even in this conversation, I'm thinking, oh yeah, this, this, and this. And I never shared that before, and I wish I did. So yeah. WILL: I love that. Because yeah, I feel like that's development, like, you have some weeks that you're shipping out multiple features. And then other weeks, you're like, I barely got one out, or I barely fixed this one bug that I've been trying to...struggling with the last couple of weeks. So yeah, I like that advice. Write it down. And remember where you've been, remember. I just love the example you used, too, because it does seem like I haven't made any movement. But when you look back, you're like, no, you actually made a lot of movement. And you were very successful with what you did. So that's great advice. VICTORIA: I sometimes write things, and then I go back maybe six months later and read them. And I'm like, who wrote this? [laughter] I don't remember learning this stuff. Oh yeah, I guess I did, right, yeah. [laughs] No, that's so cool. What questions do you have for us, Brian? BRIAN: I'm curious in, like, how do thoughtbot folks stay up to date? Like, what does your involvement in open source look like today? VICTORIA: Yeah, so we are known for being active maintainers of a lot of very popular Ruby on Rails gems. So we're a consulting agency. So we're able to structure our time with our clients so that we can build in what we call investment days, which is typically Fridays, so that people can contribute to open-source projects. They can write blog posts. They can do trainings. And so that gives us the structure to be able to actually allow our employees to contribute to open source, and it's a huge part of our business as well. So if you have a Ruby on Rails project, you're probably using one of our gems. [laughs] And so, when there's other crises or other things happening in an organization, and they want to bring in an expert, they know that that's who thoughtbot is. Of course, we've expanded, and we do React, and now we're doing platform engineering. And we have some open-source TerraForm modules that we use to migrate people onto AWS and operate at that enterprise level with a mix of managed products from AWS as well. And that continues to be, like, how we talk to people [laughs] and get that buzzword out there is, like, okay, there's this cool open-source project. Like, one I'm excited about now is OpenTelemetry. And so we're digging into that and figuring out how we can contribute. And can we make a big impact here? And that just opens the door to conversations in a way that is less salesy, right? [laughs] And people know us as the contributors and maintainers, and that creates a level of trust that goes a long way. And also, it really speaks to how we operate as a company as well, where the code is open and when we give it back to the customers, it's not. Some organizations will build stuff and then never give it to you. [laughs] BRIAN: Yeah. So it sounds like folks at thoughtbot could probably benefit from things like OpenSauced for discoverability. And I get a lot of conversation around in OpenSauced as like, how do I get connected to maintainer of X or maintainer of Y? And the first step is like, how do I even know who the maintainer is? Because when you go to GitHub, you could sort this by last commit date, which not a lot of people know. You can sort the contributors by most frequently and stuff like that. But it's challenging to find out who to reach out to when it comes to packages, especially when people move on. Like, someone created a thing. They have tons of commits. And then they look like they're the number one committer for the past ten years, but they left five years ago. Those are things that we're trying to make more discoverable to solve that problem. But then, going into that thoughtbot thing, is like being able to reach out to thoughtbot and be like, oh, who can I reach out to about this gem? And, say, I have an idea, or we have an issue; how can we get unblocked because we're using this in our product? And I imagine with consulting, there's an opportunity to say, hey thoughtbot...which, honestly, at Netlify, we used thoughtbot to solve some harder problems for us. We were just like, yeah, we don't have the bandwidth to go down this path. Let's go to consulting to unblock us in this arena. VICTORIA: Right. And that was really important to me in making the decision to join thoughtbot last year is that it was built around open source. And that ethos really spoke to me as, like, this is a place where I want to work. [laughs] And you can think of, like, if you're looking for vendors, like, oh, I want to work with people who have that same ethos. So yeah, OpenSauced seems like a really cool product. I'd be curious about how we can leverage it more at thoughtbot. BRIAN: We just shipped a feature called Teams, which it's self-explanatory. But, basically, when you build an insight page, you're able to build a team to help the discover process of what's happening in contributions. You get details and reporting on OpenSauced. The goal is basically to unblock teams who are involved in open source together and make it more discoverable for folks who want to find maintainers and collaborate with them. VICTORIA: Will, I know we're running close on time. But I had one more question about what you said around making open source more hospitable. And, you know, you mentioned going to Juneteenth Conf. And I'm curious if you have a perspective on if open source is equitably accessible to everyone or if there are things we can be doing as a community to be more inclusive. BRIAN: Yeah, it's a great question. So the first answer is quick, it's no. The reason why it's no is because we have to admit [laughs] where there are inequitable situations. And as much as we want to set this up of, like, I want to say that there's opportunity for everyone to contribute based on no matter where their background, but just by your time zone, makes it inequitable of, like, whether you can contribute to open source. Because if you look at the data and zoom out, most open source happens in the West Coast U.S., so from San Francisco to Seattle. Like, majority of contributions are there. There are reasons for that. Like, California has a very, very expressive clause of like where you can contribute. And, technically, your employer can block you on doing open-source contributions. Unless you sign...like, at Apple, you sign away your rights to be able to do that in your employee offer letter. Sorry, [laughs] not to be a dig against Apple. Apple buy lots of open source. But what I'm getting at is that the opportunity is there, but it's the awareness thing. I'm part of an organization called DevColor. It's an organization of Black engineers in tech. We have squads and monthly meetings where we just talk about our career, and growth, and stuff like that. And I attribute a lot of that interactions to my success is, like, talking to other folks who are years ahead of me and have a lot more experience. But I say this because the majority of the folks that I interact with at DevColor they don't do open source because they all...to be a Black engineer at a level of like senior engineer at Netlify, or a staff engineer, or a manager...sorry, I meant, like, Netflix but Netlify too. You basically had a career path of, like, you probably went to school at a decent engineering school, or you figured out how to get a job at Facebook or Google. And, like, that's pretty much it. And, like, this is a blanket statement. I totally understand there are outliers. But the majority of the folks I interact with at DevColor they have a job. They have a great job. And they're doing the thing, and they're being very successful. But there's less community interaction. And that's what DevColor exists for is to encourage that community interaction and participation. So, at the end of the day, like, there's opportunity to make it more equitable. So things like, every time there's a release cut for a major open-source project, why not go to Black Girls CODE and have them build something with it? And, again, very specific, like, React 19 that's currently being tested, why not go to all these other underrepresented organizations and partner with them to show them how to use this project? Because the assumption is everyone in open source, you got to be senior enough to participate, or if it's too hot, get out of the kitchen. But if we set up a place for people to interact and level up, in three or four years from now, you'll see the open-source ecosystem of that project be completely different as far as diversity. But it takes that investment to have that onboard ramp to even have that connection or conversation about testing early releases with underrepresented groups in engineering. That's where we have to start, and that's what we're trying to do at OpenSauced. We want to make that connection. I have a whole plan for it. I'll share in a blog post. I also mentioned that a lot of these thoughts are on our blog as well. I've been writing blog posts around these conversations. So opensauced.pizza/blog if you're interested. VICTORIA: Very cool. Thank you for that. WILL: I'm just processing on the whole conversation. It has just been great. VICTORIA: Yes. Thank you so much for sharing with us. And I wonder, do you have any final takeaways for our listeners today, Brian? BRIAN: Yeah, final takeaways. Like, if anything at all resonated in this conversation, please reach out, bdougie on GitHub. I'm pretty active with my notifications. So if you @ mention me in a random project, I'll probably jump back in and respond to you. But also Twitter @bdougieYO. And then, I mentioned our blog. We also have a newsletter. So, if you're interested in any of this OpenSauced journey, please join us there, and keep in touch. VICTORIA: Wonderful. Thank you so much for joining us today and sharing your story. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. WILL: And you could find me @will23larry This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thank you. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Brian Douglas.Sponsored By:thoughtbot: Now that you have funding, it’s time to design, build and ship the most impactful MVP that wows customers now and can scale in the future. thoughtbot Lift Off brings you the most reliable cross-functional team of product experts to mitigate risk and set you up for long-term success. As your trusted, experienced technical partner, we’ll help launch your new product and guide you into a future-forward business that takes advantage of today’s new technologies and agile best practices. Make the right decisions for tomorrow, today. Get in touch at: thoughtbot.com/liftoffSupport Giant Robots Smashing Into Other Giant Robots

Lauren Maffeo is the author of Designing Data Governance from the Ground Up. Victoria talks to Lauren about human-centered design work, data stewardship and governance, and writing a book anybody can use regardless of industry or team size. Designing Data Governance from the Ground Up Follow Lauren Maffeo on LinkedIn or Twitter. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. JORDYN: Thanks for having us. DAWN: Yeah, glad to be here. VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. JORDYN: Wonderful. VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. VICTORIA: What made you decide to start this incubator program this year with thoughtbot? DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. VICTORIA: Wonderful. That's amazing. Thank you both so much. INTRO MUSIC: 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 Lauren Maffeo, Author of Designing Data Governance from the Ground Up. Lauren, thank you for joining us. LAUREN: Thanks so much for having me, Victoria. I'm excited to be here. VICTORIA: Wonderful. I'm excited to dive right into this topic. But first, maybe just tell me what led you to start writing this book? LAUREN: I was first inspired to write this book by my clients, actually. I was working as a service designer at Steampunk, which is a human-centered design firm serving the federal government. I still do work for Steampunk. And a few years ago, I was working with a client who had a very large database containing millions of unique data points going back several centuries. And I realized throughout the course of my discovery process, which is a big part of human-centered design work, that most of their processes for managing the data in this database were purely manual. There was no DevSecOps integrated into their workflows. These workflows often included several people and took up to a week to complete. And this was an organization that had many data points, as mentioned, in its purview. They also had a large team to manage the data in various ways. But they still really struggled with an overall lack of processes. And really, more importantly, they lacked quality standards for data, which they could then automate throughout their production processes. I realized that even when organizations exist to have data in their purview and to share it with their users, that doesn't necessarily mean that they actually have governance principles that they abide by. And so that led me to really consider, more broadly, the bigger challenges that we see with technology like AI, machine learning, large language models. We know now that there is a big risk of bias within these technologies themselves due to the data. And when I dug deeper, first as a research analyst at Gartner and then as a service designer at Steampunk, I realized that the big challenge that makes this a reality is lack of governance. It's not having the quality standards for deciding how data is fit for use. It's not categorizing your data according to the top domains in your organization that produce data. It's lack of clear ownership regarding who owns which data sets and who is able to make decisions about data. It's not having things like a data destruction policy, which shows people how long you hold on to data for. So that knowledge and seeing firsthand how many organizations struggle with that lack of governance that's what inspired me to write the book itself. And I wanted to write it from the lens of a service designer. I have my own bias towards that, given that I am a practicing service designer. But I do believe that data governance when approached through a design thinking lens, can yield stronger results than if it is that top-down IT approach that many organizations use today unsuccessfully. VICTORIA: So let me play that back a little bit. So, in your experience, organizations that struggle to make the most out of their data have an issue with defining the authority and who has that authority to make decisions, and you refer to that as governance. So that when it comes down to it, if you're building things and you want to say, is this ethical? Is this right? Is this secure? Is it private enough? Someone needs to be responsible [laughs] for answering that. And I love that you're bringing this human-centered design approach into it. LAUREN: Yeah, that's exactly right. And I would say that ownership is a big part of data governance. It is one of the most crucial parts. I have a chapter in my book on data stewards, what they are, the roles they play, and how to select them and get them on board with your data governance vision. The main thing I want to emphasize about data stewardship is that it is not just the technical members of your team. Data scientists, data architects, and engineers can all be exceptional data stewards, especially because they work with the data day in and day out. The challenge I see is that these people typically are not very close to the data, and so they don't have that context for what different data points mean. They might not know offhand what the definitions per data piece are. They might not know the format that the data originates in. That's information that people in non-technical roles tend to possess. And so, data stewardship and governance is not about turning your sales director into a data engineer or having them build ETL pipelines. But it is about having the people who know that data best be in positions where they're able to make decisions about it, to define it, to decide which pieces of metadata are attached to each piece of data. And then those standards are what get automated throughout the DevSecOps process to make better life cycles that produce better-quality data faster, at speed with fewer resources. VICTORIA: So, when we talk about authority, what we really mean is, like, who has enough context to make smart decisions? LAUREN: Who has enough context and also enough expertise? I think a big mistake that we as an industry have made with data management is that we have given the responsibility for all data in an organization to one team, sometimes one person. So, typically, what we've done in the past is we've seen all data in an organization managed by IT. They, as a department, make top-down decisions about who has access to which data, what data definitions exist, where the data catalog lives, if it exists in an organization at all. And that creates a lot of blockers for people if you always have to go through one team or person to get permission to use data. And then, on top of that, the IT team doesn't have the context that your subject matter experts do about the data in their respective divisions. And so it really is about expanding the idea of who owns data and who is in a position of authority to make decisions about it by collaborating across silos. This is very challenging work to do. But I would actually say that for smaller organizations, they might lack the resources in, time, and money, and people to do data governance at scale. But what they can do is start embedding data governance as a core principle into the fabric of their organizations. And ultimately, I think that will power them for success in a way that larger organizations were not able to because there is a lot of technical debt out there when it comes to bad data. And one way to avoid that in the future or to at least mitigate it is to establish data governance standards early on. VICTORIA: Talk me through what your approach would be if you were working with an organization who wants to build-in this into the fabric of how they work. What would be your first steps in engaging with them and identifying where they have needs in part of that discovery process? LAUREN: In human-centered design, the discovery process occurs very early in a project. This is where you are working hand in hand with your client to figure out what their core needs are and how you can help them solve those core needs. And this is important to do because it's not always obvious what those needs are. You might get a contract to work on something very specific, whether it's designing the user interface of a database or it's migrating a website. Those are technical challenges to solve. And those are typically the reason why you get contracted to work with your client. But you still have to do quite a bit of work to figure out what the real ask is there and what is causing the need for them to have hired you in the first place. And so, the first thing I would do if I was walking a client through this is I would start by asking who the most technical senior lead in the organization is. And I would ask how they are managing data today. I think it's really important, to be honest about the state of data in your organization today. The work that we do designing data governance is very forward-thinking in a lot of ways, but you need a foundation to build upon. And I think people need to be honest about the state of that foundation in their organization. So the first thing I would do is find that most-senior data leader who is responsible for making decisions about data and owns the data strategy because that person is tasked with figuring out how to use data in a way that is going to benefit the business writ large. And so, data governance is a big part of what they are tasked to do. And so, in the first instance, what I would do is I would host a workshop with the client where I would ask them to do a few things. They would start by answering two questions: What is my company's mission statement, and how do we use data to fulfill that mission statement? These are very baseline questions. And the first one is so obvious and simple that it might be a little bit off-putting because you're tempted to think, as a senior leader, I already know what my company does. Why do I need to answer it like this? And you need to answer it like this because just like we often get contracts to work on particular technical problems, you'd be surprised by how many senior leaders cannot articulate their company's mission statements. They'll talk to you about their jobs, the tools they use to do their jobs, who they work with on a daily basis. But they still aren't ultimately answering the question of how their job, how the technology they use fulfills a bigger organizational need. And so, without understanding what that organizational need is, you won't be able to articulate how data fulfills that mission. And if you're not able to explain how data fulfills your company's mission, I doubt you can explain which servers your data lives on, which file format it needs to be converted to, who owns which data sets, where they originate, what your DevSecOps processes are. So answering those two questions about the company mission and how data is used to fulfill that mission is the first step. The second thing I would do is ask this senior leader, let's say the chief data officer, to define the data domains within their organization. And when we talk about data domains, we are talking about the areas of the business that are the key areas of interest. This can also be the problem spaces that your organization addresses. It also can have a hand in how your organization is designed as is; in other words, who reports to whom? Do you have sales and marketing within one part of the organization, or are they separate? Do you have customer success as its own wing of the organization separate from product? However your organization is architected, you can draw lines between those different teams, departments, and the domains that your organization works in. And then, most importantly, you want to be looking at who leads each domain and has oversight over the data in that domain. This is a really important aspect of the work because, as mentioned, stewards play a really key role in upholding and executing data governance. You need data stewards across non-technical and technical roles. So defining not just what the data domains are but who leads each domain in a senior role is really important to mapping out who your data stewards will be and to architect your first data governance council. And then, finally, the last thing I would have them do in the first instance is map out a business capability map showing not only what their data domains are but then the sub-domains underneath. So, for example, you have sales, and that can be a business capability. But then, within the sales data domain, you're going to have very different types of sales data. You're going to have quarterly sales, bi-annual sales, inbound leads versus outbound leads. You're going to have very different types of data within that sales data domain. And you want to build those out as much as you possibly can across all of your data domains. If you are a small organization, it's common to have about four to six data domains with subdomains underneath, each of those four to six. But it varies according to each startup and organization and how they are structured. Regardless of how your organization is structured, there's always value in doing those three things. So you start by identifying what your organization does and how data fulfills that goal. You define the core data domains in your organization, including who owns each domain. And then, you take that information about data domains, and you create a capability map showing not just your core data domains but the subdomains underneath because you're going to use all of that information to architect a future data governance program based on what you currently have today. VICTORIA: I think that's a great approach, and it makes a lot of sense. Is that kind of, like, the minimum that people should be doing for a data governance program? Like, what's the essentials to do, like, maybe even your due diligence, say, as a health tech startup company? LAUREN: This is the bare minimum of what I think every organization should do. The specifics of that are different depending on industry, depending on company size, organizational structure. But I wrote this book to be a compass that any organization can use. There's a lot of nuance, especially when we get into the production environment an organization has. There's a lot of nuance there depending on tools, all of that. And so I wanted to write a book that anybody could use regardless of industry size, team size, all of that information. I would say that those are the essential first steps. And I do think that is part of the discovery process is figuring out where you stand today, and no matter how ugly it might be. Because, like we've mentioned, there is more data produced on a daily basis than ever before. And you are not going into this data governance work with a clean slate. You already have work in your organization that you do to manage data. And you really need to know where there are gaps so that you can address those gaps. And so, when we go into the production environment and thinking about what you need to do to be managing data for quality on a regular basis, there are a couple of key things. The first is that you need a plan for how you're going to govern data throughout each lifecycle. So you are very likely not using a piece of data once and never again. You are likely using it through several projects. So you always want to have a plan for governance in production that includes policies on data usage, data archiving, and data destruction. Because you want to make sure that you are fulfilling those principles, whatever they are, throughout each lifecycle because you are managing data as a product. And that brings me to the next thing that I would encourage people working in data governance to consider, which is taking the data mesh principle of managing data as a product. And this is a fundamental mind shift from how big data has been managed in the past, where it was more of a service. There are many detriments to that, given the volume of data that exists today and given how much data environments have changed. So, when we think about data mesh, we're really thinking about four key principles. The first is that you want to manage your data according to specific domains. So you want to be creating a cloud environment that really accounts for the nuance of each data domain. That's why it's so important to define what those data domains are. You're going to not just document what those domains are. You're going to be managing and owning data in a domain-specific way. The second thing is managing data as a product. And so, rather than taking the data as a service approach, you have data stewards who manage their respective data as products within the cloud environment. And so then, for instance, rather than using data about customer interactions in a single business context, you can instead use that data in a range of ways across the organization, and other colleagues can use that data as well. You also want to have data available as a self-service infrastructure. This is really important in data mesh. Because it emphasizes keeping all data on a centralized platform that manages your storage, streaming, pipelines, and anything else, and this is crucial because it prevents data from leaving in disparate systems on various servers. And it also erases or eases the need to build integrations between those different systems and databases. And it also gives each data steward a way to manage their domain data from the same source. And then the last principle for data mesh is ecosystem governance. And really, what we're talking about here is reinforcing the data framework and mission statement that you are using to guide all of your work. It's very common in tech for tech startups to operate according to a bigger vision and according to principles that really establish the rationale for why that startup deserves to exist in the world. And likewise, you want to be doing all of your production work with data according to a bigger framework and mission that you've already shared. And you want to make sure that all of your data is formatted, standardized, and discoverable against equal standards that govern the quality of your data. VICTORIA: That sounds like data is your biggest value as a company and your greatest source of liability [laughs] and in many ways. And, I'm curious, you mentioned just data as a product, if you can talk more about how that fits into how company owners and founders should be thinking about data and the company they're building. LAUREN: So that's a very astute comment about data as a liability. That is absolutely true. And that is one of the reasons why governance is not just nice to have. It's really essential, especially in this day and age. The U.S. has been quite lax when it comes to data privacy and protection standards for U.S. citizens. But I do think that that will change over the next several years. I think U.S. citizens will get more data protections. And that means that organizations are going to have to be more astute about tracking their data and making sure that they are using it in appropriate ways. So, when we're talking to founders who want to consider how to govern data as a product, you're thinking about data stewards taking on the role of product managers and using data in ways that benefits not just them and their respective domains but also giving it context and making it available to the wider business in a way that it was not available before. So if you are architecting your data mesh environment in the cloud, what you might be able to do is create various domains that exist on their own little microservice environments. And so you have all of these different domains that exist in one environment, but then they all connect to this bigger data mesh catalog. And from the catalog, that is where your colleagues across the business can access the data in your domain. Now, you don't want to necessarily give free rein for anybody in your organization to get any data at any time. You might want to establish guardrails for who is able to access which data and what those parameters are. And the data as a product mindset allows you to do that because it gives you, as the data steward/pseudo pm, the autonomy to define how and when your data is used, rather than giving that responsibility to a third-party colleague who does not have that context about the data in your domain. VICTORIA: I like that about really giving the people who have the right context the ability to manage their product and their data within their product. That makes a lot of sense to me. Mid-Roll Ad: As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. Take your business online with design-driven digital acceleration. Find out more at tbot.io/acceleration or click the link in the show notes for this episode. VICTORIA: What is it like to really bring in this culture of design-thinking into an organization that's built a product around data? LAUREN: It can be incredibly hard. I have found that folks really vary in their approach to this type of work. I think many people that I talk to have tried doing data governance to some degree in the past, and, for various reasons, it was not successful. So as a result, they're very hesitant to try again. I think also for many technical leaders, if they're in CIO, CDO, CTO roles, they are not used to design thinking or to doing human-centered design work. That's not the ethos that was part of the tech space for a very long time. It was all about the technology, building what you could, experimenting and tinkering, and then figuring out the user part later. And so this is a real fundamental mindset shift to insist on having a vision for how data benefits your business before you start investing money and people into building different data pipelines and resources. It's also a fundamental shift for everyone in an organization because we, in society writ large, are taught to believe that data is the responsibility of one person or one team. And we just can't afford to think like that anymore. There is too much data produced and ingested on a daily basis for it to fall to one person or one team. And even if you do have a technical team who is most adept at managing the cloud environment, the data architecture, building the new models for things like fraud detection, that's all the purview of maybe one team that is more technical. But that does not mean that the rest of the organization doesn't have a part to play in defining the standards for data that govern everything about the technical environment. And I think a big comparison we can make is to security. Many of us… most of us, even if we work in tech, are not cybersecurity experts. But we also know that employees are the number one cause of breaches at organizations. There's no malintent behind that, but people are most likely to expose company data and cause a breach from within the company itself. And so organizations know that they are responsible for creating not just secure technical environments but educating their employees and their workforce on how to be stewards of security. And so, even at my company, we run constant tests to see who is going to be vulnerable to phishing? Who is going to click on malicious links? They run quarterly tests to assess how healthy we are from a cybersecurity perspective. And if you click on a phishing attempt and you fall for it, you are directed to a self-service education video that you have to complete, going over the aspects of this phishing test, what made it malicious. And then you're taught to educate yourself on what to look for in the future. We really need to be doing something very similar with data. And it doesn't mean that you host a two-hour training and then never talk about data again. You really need to look at ways to weave data governance into the fabric of your organization so that it is not disruptive to anybody's day. It's a natural part of their day, and it is part of working at your organization. Part of your organizational goals include having people serve as data stewards. And you emphasize that stewardship is for everyone, not just the people in the technology side of the business. VICTORIA: I love that. And I think there's something to be said for having more people involved in the data process and how that will impact just the quality of your data and the inclusivity of what you're building to bring those perspectives together. LAUREN: I agree. And that's the real goal. And I think this is, again, something that's actually easier for startups to do because startups are naturally more nimble. They find out what works, what doesn't work. They're willing to try things. They have to be willing to try things. Because, to use a really clichéd phrase, if they're not innovating, then they're going to get stale and go out of business. But the other benefit that I think startups have when they're doing this work is the small size. Yes, you don't have the budget or team size of a company like JP Morgan, that is enormous, or a big bank. But you still have an opportunity to really design a culture, an organizational culture that puts data first, regardless of role. And then you can architect the structure of every role according to that vision. And I think that's a really exciting opportunity for companies, especially if they are selling data or already giving data as a product in some way. If they're selling, you know, data as a product services, this is a really great approach and a unique approach to solving data governance and making it everyone's opportunity to grow their own roles and work smarter. VICTORIA: Right. And when it's really the core of your business, it makes sense to pay more attention to that area [laughs]. It's what makes it worthwhile. It's what makes potential investors know that you're a real company who takes things seriously. [laughs] LAUREN: That's true. That's very true. VICTORIA: I'm thinking, what questions...do you have any questions for me? LAUREN: I'm curious to know, when you talk to thoughtbot clients, what are the main aspects of data that they struggle with? I hear a variety of reasons for data struggles when I talk to clients, when I talk to people on the tech side, either as engineers or architects. I'm curious to hear what the thoughtbot community struggles with the most when it comes to managing big data. VICTORIA: I think, in my experience, in the last less than a year that I've been with thoughtbot, one challenge which is sort of related to data...but I think for many small companies or startups they don't really have an IT department per se. So, like, what you mentioned early on in the discovery process as, like, who is the most senior technical person on your team? And that person may have little to no experience managing an IT operations group. I think it's really bringing consulting from the ground up for an organization on IT operations, data management, user and access management. Those types of policies might just be something they hadn't considered before because it's not in their background and experience. But maybe once they've gotten set up, I think the other interesting part that happens is sometimes there's just data that's just not being managed at all. And there are processes and bits and pieces of code in app that no one really knows what they are, who they're used for, [laughs] where the data goes. And then, you know, the connections between data. So everything that you're mentioning that could happen when you don't do data governance, where it can slow down deployment processes. It can mean that you're giving access to people who maybe shouldn't have access to production data. It can mean that you have vulnerabilities in your infrastructure. That means someone could have compromised your data already, and you just don't know about it. Just some of the issues that we see related to data across the spectrum of people in their lifecycle of their startups. LAUREN: That makes total sense, I think, especially when you are in a startup. If you're going by the typical startup model, you have that business-minded founder, and then you likely have a more technical co-founder. But we, I think, make the assumption that if you are, quote, unquote, "technical," you, therefore, know how to do anything and everything about every system, every framework, every type of cloud environment. And we all know that that's just not the case. And so it's easy to try to find the Chief Technology Officer or the Chief Information Officer if one exists and to think, oh, this is the right person for the job. And they might be the most qualified person given the context, but that still doesn't mean that they have experience doing this work. The reality is that very few people today have deep hands-on experience making decisions about data with the volume that we see today. And so it's a new frontier for many people. And then, on top of that, like you said as well, it's really difficult to know where your data lives and to track it. And the amount of work that goes into answering those very basic questions is enormous. And that's why documentation is so important. That's why data lineage in your architecture is so important. It really gives you a snapshot of which data lives where, how it's used. And that is invaluable in terms of reducing technical debt. VICTORIA: I agree. And I wonder if you have any tips for people facilitating conversations in their organization about data governance. What would you tell them to make it less scary and more fun, more appealing to work on? LAUREN: I both love and hate the term data governance. Because it's a word that you say, and whether you are technical or not, many people tune out as soon as they hear it because it is, in a way, a scary word. It makes people think purely of compliance, of being told what they can't do. And that can be a real challenge for folks. So I would say that if you are tasked with making a data governance program across your organization, you have to invest in making it real for people. You have to sell them on stewardship by articulating what folks will gain from serving as stewards. I think that's really critical because we are going to be asking folks to join a cause that they're not going to understand why it affects them or why it benefits them at first. And so it's really your job to articulate not only the benefits to them of helping to set up this data stewardship work but also articulating how data governance will help them get better at their jobs. I also think you have to create a culture where you are not only encouraging people to work across party lines, so to speak, to work across silos but to reward them for doing so. You are, especially in the early months, asking a lot of people who join your data stewardship initiatives and your data governance council you're asking them to build something from the ground up, and that's not easy work. So I think any opportunity you can come up with to reward stewards in the form of bonuses or in terms of giving them more leeway to do their jobs more of a title bump than they might have had otherwise. Giving them formal recognition for their contributions to data governance is really essential as well. Because then they see that they are rewarded for contributing to the thought leadership that helps the data governance move forward. VICTORIA: I'm curious, what is your favorite way to be rewarded at work, Lauren? LAUREN: So I am a words person. When we talk about love languages, one of them is words of affirmation. And I would say that is the best way to quote, unquote, "reward me." I save emails and screenshots of text messages and emails that have really meant a lot to me. If someone sends me a handwritten card that really strikes a chord, I will save that card for years. My refrigerator is filled with holiday cards and birthday cards, even from years past. And so any way to recognize people for the job they're doing and to let someone know that they're seen, and their work is seen and valued really resonates with me. I think this is especially important in remote environments because I love working from home, and I am at home alone all day. And so, especially if you are the only person of your kind, of your role on your team, it's very easy to feel insular and to wonder if you're hitting the mark, if you're doing a good job. I think recognition, whether verbally or on Slack, of a job well done it really resonates with me. And that's a great way to feel rewarded. VICTORIA: I love that. And being fully remote with thoughtbot, I can feel that as well. We have a big culture of recognizing people. At least weekly, we do 15Five as a tool to kind of give people high-fives across the company. LAUREN: Yep, Steampunk does...we use Lattice. And people can submit praise and recognition for their colleagues in Lattice. And it's hooked up to Slack. And so then, when someone submits positive feedback or a kudos to a colleague in Lattice, then everyone sees it in Slack. And I think that's a great way to boost morale and give people a little visibility that they might not have gotten otherwise, especially because we also do consulting work. So we are knee-deep in our projects on a daily basis, and we don't always see or know what our colleagues are working on. So little things like that go a long way towards making people feel recognized and valued as part of a bigger company. But I'm also curious, Victoria, what's your favorite way to get rewarded and recognized at work? VICTORIA: I think I also like the verbal. I feel like I like giving high-fives more than I like receiving them. But sometimes also, like, working at thoughtbot, there are just so many amazing people who help me all throughout the day. I start writing them, and then I'm like, well, I have to also thank this person, and then this person. And then I just get overwhelmed. [laughs] So I'm trying to do more often so I don't have a backlog of them throughout the week and then get overwhelmed on Friday. LAUREN: I think that's a great way to do it, and I think it's especially important when you're in a leadership role. Something that I'm realizing more and more as I progress in my career is that the more senior you are, the more your morale and attitude sets the tone for the rest of the team. And that's why I think if you are in a position to lead data governance, your approach to it is so crucial to success. Because you really have to get people on board with something that they might not understand at first, that they might resent it first. This is work that seems simple on the surface, but it's actually very difficult. The technology is easy. The people are what's hard. And you really have to come in, I think, emphasizing to your data stewards and your broader organization, not just what governance is, because, frankly, a lot of people don't care. But you really have to make it tangible for them. And you have to help them see that governance affects everyone, and everyone can have a hand in co-creating it through shared standards. I think there's a lot to be learned from the open-source community in this regard. The open-source community, more than any other I can think of, is the model of self-governance. It does not mean that it's perfect. But it does mean that people from all roles, backgrounds have a shared mission to build something from nothing and to make it an initiative that other people will benefit from. And I think that attitude is really well-positioned for success with data governance. VICTORIA: I love that. And great points all around on how data governance can really impact an organization. Are there any final takeaways for our listeners? LAUREN: The biggest takeaway I would say is to be thoughtful about how you roll out data governance in your organization. But don't be scared if your organization is small. Again, it's very common for people to think my business is too small to really implement governance. We don't have the budget for, you know, the AWS environment we might need. Or we don't have the right number of people to serve as stewards. We don't actually have many data domains yet because we're so new. And I would say start with what you have. If you are a business in today's day and age, I guarantee that you have enough data in your possession to start building out a data governance program that is thoughtful and mission-oriented. And I would really encourage everyone to do that, regardless of how big your organization is. And then the other takeaway I would say is, if you remember nothing else about data governance, I would say to remember that you automate your standards. Your standards for data quality, data destruction, data usage are not divorced from your technical team's production environments; it's the exact opposite. Your standards should govern your environment, and they should be a lighthouse when you are doing that work. And so you always want to try to integrate your standards into your production environment, into your ETL pipelines, into your DevSecOps. That is where the magic happens. Keeping them siloed won't work. And so I'd love for people, if you really enjoyed this episode and the conversation resonated with you, too, get a copy of the book. It is my first book. And I was really excited to work with the Pragmatic Programmers on it. So if readers go to pragprog.com, they can get a copy of the book directly through the publisher. But the book is also available at Target, Barnes & Noble, Amazon, and local bookstores. So I am very grateful as a first-time author for any and all support. And I would really also love to hear from thoughtbot clients and podcast listeners what you thought of the book because version two is not out of the question. VICTORIA: Well, looking forward to it. Thank you again so much, Lauren, for joining us today. You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Lauren Maffeo.Sponsored By:thoughtbot: As life moves online, bricks-and-mortar businesses are having to adapt to survive. With over 18 years of experience building reliable web products and services, thoughtbot is the technology partner you can trust. We provide the technical expertise to enable your business to adapt and thrive in a changing environment. We start by understanding what’s important to your customers to help you transition to intuitive digital services your customers will trust. We take the time to understand what makes your business great and work fast yet thoroughly to build, test, and validate ideas, helping you discover new customers. Take your business online with design‑driven digital acceleration. Find out more at: url tbot.io/acceleration or click the link in the show notes for this episode.Support Giant Robots Smashing Into Other Giant Robots

Jasper (William) Cartwright is a Freelance Producer, Podcaster, Actor, and Motion Capture & Performance Capture Performer. Chad talks to Jasper about his podcast Three Black Halflings, which is committed to discussing diversity and inclusion within fantasy, sci-fi, and nerdy culture from the perspective of three people of color, what it's like to be in the space, and why representation is super important. Follow Jasper (William) Cartwright on LinkedIn or Twitter. Check out his website at jasperwcartwright.com. Follow thoughtbot on Twitter or LinkedIn. Become a Sponsor of Giant Robots! Transcript: VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program. We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP. Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today. JORDYN: Thanks for having us. DAWN: Yeah, glad to be here. VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right? JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again. VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon. JORDYN: Wonderful. VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round? JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product. VICTORIA: What made you decide to start this incubator program this year with thoughtbot? DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time. And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage. It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well. VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right? DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business? It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process. VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP. JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward. You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia. He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing. You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it? VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today? DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders. So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you. VICTORIA: Wonderful. That's amazing. Thank you both so much. INTRO MUSIC: 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 Jasper William-Cartwright, Game Master for hire, Actor, Creative Consultant, Podcaster, Co-Host of The Performance Capture Podcast, and Co-Host of one of my favorite podcasts, Three Black Halflings. Jasper, thank you so much for joining me. JASPER: Hey, no, thank you so much for having me. And, man, with that intro, I almost feel... CHAD: [laughs] JASPER: I almost felt...I was like, oh, I feel cool. Those are some fun things. [laughs] CHAD: I almost started with a Heeello robots. JASPER: [laughs] CHAD: But it doesn't really have the alliteration that hello Halflings does, so... JASPER: Sure. I don't even know how the hello Halfling started. Like, I'm going to have to go back and listen to some of the earlier episodes again because I genuinely have no idea how it happened. And now it's gotten to a point where it's unyieldy. Every episode, I feel like I have to get a little bit further and a little bit higher. And I'm like, this can't be good for people's ears, so, [laughs] yeah. CHAD: So I know what the show is, but in your own words, what is the Three Black Halflings Podcast? JASPER: The Three Black Halflings Podcast is a show which is committed to talking about diversity and inclusion within fantasy and sci-fi, and sort of anything that nerdy culture touches, we try to cover it from the perspective of three people of color, what it's like to be in the space, and why representation is super important. CHAD: I want to talk about the origin of the show and how you got started. But I was introducing someone to the show previously because I try to tell everybody I can about the show. [laughter] I've noticed in the beginning when you started, there was a lot of low-hanging fruit, like, we can dive into this stuff and educate people. And over time, you've introduced actual play where you're playing Dungeons & Dragons on the show. And I think it's changed a little bit, and it's still great. But I always also recommend people go back to the beginning. And I think a lot of the episodes are sort of timeless. They're not about the news of the day. They're diving into particular topics and discussing either the impact or the problems that they have or how to play them better. JASPER: Yeah, definitely. I think you're absolutely right. It's been a weird thing where because we've become more popular and we're kind of more in tune with the TTRPG space; I think that typically what has happened for us is that we've spent less time really digging around for, you know, what's some stuff... all the things that we can explore. And we're a lot more kind of like, what's the beat of the moment? If that makes sense. And I think that's why we haven't done as many episodes like that. And also, just because we...I just think that the audience is changing. And the way that people consume our content is changing. It tends to go in cycles for us where we'll do a batch of very topical episodes then we'll do more really nitty gritty kind of game design episodes. And so I think a lot of it does depend on the sort of moment, what's going on. There are still a bunch of episodes that we have planned. And obviously, we have the Halfling University series which is coming out currently, which is a more retrospective look back on poignant things throughout the history of nerd [inaudible 3:11] and nerd culture. So I like to think there's a good variety on there. CHAD: Obviously the show, especially I think when it started, had a very heavy focus on Dungeons & Dragons, which I love. People who know me [laughs] know that I love Dungeons & Dragons. JASPER: [laughs] CHAD: And I've been playing it for a long time. And as someone playing it since I was a teenager, I didn't realize until I got older and learned a lot more...and certainly, the show went a long way to sort of educating me about how not only the origins of some of the tropes of fantasy and Dungeons & Dragons but just in general how to have inclusive play. When you're playing with a group of people, and to bring it back to a non-Dungeons & Dragons specific thing, this is true, I think, in any group of people. When you're surrounded by a group of people who look the same as you, are from the same area, have the same experiences, you don't realize what's missing from that table, and that's true in our companies, and it's true around a TTRPG table too. JASPER: Yeah, I completely agree. And I think that's the same for a lot of us. I remember doing a big post after I'd been doing the show for about six months, and it was just like, I was very open when I started the show that a lot of what I wanted to talk about I wanted it to be a safe space for me to explore some of these things. Because I grew up in a very White middle-class area, and therefore I had a lot of the blind spots that I would see my friends of color call out my White friends for or whatever it may be. And so I was like, okay, it's time for me to educate myself. And I wanted to do it in a safe space, in a place where I could learn from great people. Obviously, we had other co-hosts of the show who are fantastic people, but we had things like sensitivity consultants and people like that come on. I always like to shout out James Mendez Hodes, who, if you ever want to do a bit of a deep dive into fantasy...and you said, Chad, the historical basis for some of the stuff that we use, and he wrote some really incredible stuff. And so a lot of it was about me trying to educate myself as well and kind of put in that work. I thought there was a value there in doing it in an open forum in sort of saying, hey, I'm a person of color, and I'm also trying to figure this out, you know what I mean? CHAD: Mm-hmm. JASPER: Because I think that a lot of the time, the barrier for anyone who doesn't belong to a minority group is like, oh, man, I don't want to burden someone else with my own understanding of this thing, and I don't want to ask the wrong questions. Or maybe I don't even know where to begin in educating myself. And so there was something about the three of us and me particularly kind of being very open about the fact that we were learning about this too and that there might be things that...mistakes or things might slightly be out of place but that we have that openness and willingness to learn. And I think that in today's internet culture where everyone is so kind of reaction-based, it just felt important to me that we had a space where we could sit in and talk about stuff and really be open with each other in a way that we knew we'd all be able to shake hands and be like, cool, that was a good session or whatever [laughs] it was today, and not be like, I hate you, you know what I mean? Because someone had made a mistake, or misspoke, or something like that. And I think you're absolutely right. It's something I've started to do a bit more of recently, which is doing diversity and inclusion talks and coaching for companies because I think a lot of the lessons that I've learned through doing this show, especially around things like language and how you set up a work environment to suit people of color and more generally, minorities, it's a slightly continuous pursuit in the sense that you always have to be kind of open and learning. And I think also it provides a...what I think is best about it is that it provides such richness to your work environment. We always say on Three Black Halflings that we want you to take these things and use them to enhance your game. Like you're saying, if you have the same people with the same experiences all the time and that's all you ever hear, then, of course, you're going to get a pretty one-sided experience. And then, if you expand that out to include people from halfway across the world who have a very different experience, they're going to see things differently. And I can almost guarantee there'll be a problem that you and your team have been stuck on for like months, and someone from a different perspective will come in and be like, boom, there's the problem, or that's how we get around it because they have a different frame of reference to you. And so I always try to...it sounds really awful to say sell it, [laughs] you know, not trying to sell diversity and inclusion, but I always want to try and go further by saying it's not just about getting different faces in the door. It's about enriching the work that you do and allowing your team to do the best work that they can. Just the quantity of difference between the kinds of things like games that I used to run, you know, to link it back to Dungeons & Dragons, versus the games that I run now, just having had this wealth of influence from other people and different experiences is incredible. And I think it holds true for every element of my work. So I work as a producer a lot in lots of creative fields as opposed to just podcasting. And it's improved tenfold just by having a diverse group of people that I draw from their experiences in my pursuits. So I think it makes a big difference. CHAD: I think it's the idea that you wanted a safe space, and so you created a public podcast on the internet. [laughter] JASPER: Yeah, I can see how that sounds now. [laughter] CHAD: I assume that you've had to navigate being in public spaces talking about diversity, inclusion. I'm sure that that has been difficult at times. JASPER: Yeah, for sure. I think just to clarify that as well, [laughs] because I am definitely aware of how it sounds, I've always been a very, like, I don't care attitude, you know what I mean? CHAD: Yeah. JASPER: In the sense that I felt like I needed what I was going to make, if that makes sense. What, I guess, I meant by a safe space is I wanted people to have the safe space of listening to it. I was getting the safe space as far as I was concerned because podcasts aren't a reactionary medium, which is lovely. So thank God your audience isn't sat here just saying everything that you said wrong and correcting you. People are probably shouting at me for stuff that I've said already on this episode. [chuckles] So it's definitely a fine line, like you said, to put something out on the internet. It's a very, very public thing to do. But it definitely just felt like, for me, creating somewhere where people could just disappear a little bit and encounter these things in a way where they're not going to be called out, or they're not going to be kind of threatened. There's no risk of cancellation or whatever if you say the wrong thing or whatever it is. It felt important. And yeah, we've had to deal with...I will say this; it's kind of tricky to sum up the things that we've dealt with because I think a lot of stuff is still so systemic in the sense that just even down to the opportunities that you get and things like that where you kind of go like, huh, they started in this space like two months ago, and they have twice the followers we do. And they're getting loads of money for doing these streams. [laughs] And you're going to go, like, hold on, what's going on here? CHAD: Yeah, there are three people on this show. They have ten times the Patreons that we do. [laughter] JASPER: Yeah, exactly. CHAD: Why might that be? [laughter] JASPER: Yeah, exactly. Exactly that. And that's one side of it. And then, to be honest, the most it's happened...and this is quite a recent thing, which I don't even think we've really spoken about on the show was the reaction to the...so for anyone who doesn't know Dungeons & Dragons, there was a recent controversy where Hasbro and Wizards of the Coast threatened to repeal part of the license, which allowed creators to freely kind of use elements, not all of them, but some elements of the Dungeons & Dragons game and the Dungeons & Dragons IP for content basically. And they wanted to repeal it, and they wanted to start bringing in more checks and balances in terms of what you could and couldn't do. And they wanted to start taking cuts of the profits and all this kind of thing. And anyway, the reaction was, as you can probably imagine, not great. Us content creators are ostensibly the lifeblood of this game, especially in terms of its online presence. So we ended up getting the opportunity to interview one of the executive producers at Wizards of the Coast, and we put it on our YouTube. And it's hilariously one of the most viewed pieces of content that the Three Black Halflings has, full stop. And the reaction is so strange because you have people that get super angry at this guy for being corporate, and this and that, and the other. And we were like, okay, that's fine. So that was the first wave of reaction. Then it was like, he's a racist against White people. And we were like, whoa, okay. And then it turned into you're racist because you didn't call him out for being racist against White people. And then, eventually, I think it just found its way to the trolls who are now just being openly racist about it. So it's a very strange dynamic of seeing that play out in terms of it literally depending on the amount of people that listened to it, do you know what I mean? It didn't hit troll numbers yet, like; it needed to be more popular to hit troll numbers. So part of me does wonder if we just haven't quite got to peak troll numbers [laughter] with the main podcast. I'm sort of readying myself with a spear and a shield, so I'm like, okay, trolls are coming. CHAD: It's like a double-edged sword. You want to be more popular but at the same time, hmm. Part of what I'm getting at is I think the work you do, even if you take sort of systemic racism out of it, the reaction to diversity and inclusion topics out of it, it's not easy to be an independent content creator, then you add that on to it. So how do you keep going? You've been doing it for three years now. What's your day-to-day like? How do you keep going at it? JASPER: I mean, the rewards are just huge. I got to go to the Dungeons & Dragons premiere the other day. I went to a party in the Tower of London and had people coming up to me. Everyone knew who I was at the Tower of London at a party in the Tower of London. And when I say Tower of London, I want to clarify that it wasn't a function room attached to the Tower of London. CHAD: [laughs] JASPER: We were in the Tower of London. I was having champagne, sipping it next to Henry VIII's armor. CHAD: [laughs] Amazing. JASPER: It was absolutely wild and being there and people coming up to me and being like, "We love what Three Black Halflings does. We think it's a really important voice in the community. And you guys absolutely like..." you know, because I was sort of like, oh God, I can't believe we're here or whatever. And people would be like, "No, no, you absolutely deserve to be here. It's so important that you guys are here." So I think that has a huge impact. People in the community, the way that we've been embraced there's so many shows and so many people who are creating content that are working so hard who don't have nearly the platform that we have. And I think that is, A, a testament to us and the hard work that we put in. But it's also a testament to just how important what we're doing within the community is. And I still don't really think there is a facsimile for Three Black Halflings in the industry in the sense that we're a talk show. We talk about heavy topics a lot of the time, but we do it with a smile on our face. And we try to laugh as much as humanly possible, you know what I mean? Because the whole premise of this show was that Black joy can be a form of protest. So we wanted to be like, hey, we can talk about serious stuff without having to cry and feel crushingly horrible about it, you know. [laughs] And I think I guess that's how I feel whenever I feel like I want to cry or feel crushingly horrible about my workload or how hard it is to make the show is that I go, this is kind of the point, you know what I mean? This is why we got into it because I think that this is going to make it easier for someone else to do the same thing or someone else do something even better, and that, for me, is incredibly rewarding. But I will caveat all of that by saying we've started to generate some money through ad revenue and Patreon, everything like that. And it's actually...this show has given me the opportunity to leave my full-time day job, which was still kind of creative. I was working in animation before this. And I loved that job, but now I get to be my own boss. And it's been a really steep learning curve learning how to do work-life balance when you're your own boss because you're like, I could really disrespect my time here, you know what I mean? [laughter] I can get a lot done today. And I go, no, I have to spend time with my fiancée. I have to eat food. I have to sleep. I have to drink water. I think a lot of the process has been about that. And I think, especially recently, I've gotten much better at kind of giving myself that work-life balance, and that makes it a lot easier for me to carry on. Because I feel like we've gotten to a point where I can be honest with the community as well and say, "Hey, we're having a late episode this week because there are some kinks with the edit," or something. [laughs] And people are just like, "Yeah, it's fine." So I was actually having a consultancy session for someone yesterday. And one of the big things I kept saying to them was, as a content creator, you have to realize the world is not going to crash and burn if you don't hold the standards that you've set for yourself. Because the chances are your audience has much, much lower expectations, and that's not because they don't think you can do it. It's just because they understand that you're human, and they want you to do well, you know what I mean? So if ever I feel like, oh no, Three Black Halflings has really messed up, I'm like, this episode sounds terrible. And we put it out and, ugh, and I'm there twisting myself into knots and making myself feel horrible. And then I go to the Discord, and everyone's like, "Oh, that sounded a bit janky. Oh, well, I'm sure they'll sort it out." [laughs] It's just like, it's absolutely fine. So taking pressure off of yourself, I think, is something that I think is really important if you're trying to pursue, especially if you're trying to start out in pursuit of something like this because, yeah, it's super easy to drown yourself [laughs] in all of the kind of stress and anxiety about putting content out. CHAD: You mentioned ads, and you mentioned Patreon. I think it was...was it last year that you joined a podcast network? JASPER: Ooh, it would have been a year before. CHAD: A year. JASPER: So I've been with Headgum, I think, for nearly two years now. CHAD: Wow. What sort of prompted that, and what does being part of a network give you as a podcast? JASPER: Hell yeah. Joining a network ostensibly is just like joining a kind of family of other shows. I guess the closest equivalent really is sort of having your show picked up by Netflix or a broadcaster or something like that. It's sort of like you're bringing your show to that family. And then the most common thing...every network is obviously slightly different and will have different kinds of support structures that they offer certain shows depending on the money they generate, all that kind of thing. But the most common one is effectively; you are now in a group that can all support each other and can all benefit each other by doing ad swaps because ad swaps typically is the absolute best way to improve podcast performance, mostly just because the user journey is super simple. It's like, hey, do you like the sound of this podcast? Well, the link to it is in your description. You have to click twice. You have to go into the description, click on that link, and then hit subscribe, and you're done. That's all you have to do, and it will be there. And you know it'll automatically tee up in your feed and all that kind of stuff. So things like pod swaps and everything like that are by far the most effective for spreading the word about your show. And it also just helps you really hit specific target audiences where you go; we have great metrics that we can see of like, the average age of our listeners, how they identify gender-wise, music they listen to typically, what the average Three Black Halflings listens to. I think when you roll all of that information together as a part of a network, you have a huge bank of data, which they can then use to kind of market you in the best way and push you out in the best way. And then, on top of that, most networks will have some sort of ad revenue like sort of system or tech, I guess, is probably the best way of putting it. And certainly, for some networks, they almost run like tech companies, how I imagine tech companies run. You're probably about to tell me, "A lot better." [laughs] CHAD: Don't worry about it. [laughs]. JASPER: But, for instance, Headgum has Gumball. So Gumball is their ad sales sort of site, which has software which allows you to basically...everyone can go, and you can book ads just by looking at the podcast, seeing how many downloads it has; again, it has a breakdown of demographics and things like that that you can look at to see if that will marry up with whatever product you're pushing out. And then that will automatically set up a prompt for me to then read the script, upload it, and then that will put a dynamic ad in the middle of an episode, however many episodes until a certain amount of impressions are delivered. So, again, that will be very unique and different depending on which network you join. But ostensibly, I'd say those are the two main things is pooling of resources amongst a family of different podcasts and then some sort of promise of ad revenue or ad sales. Most of them also have an ad sales team where they'll go and hunt out more specific spots for your show. So, for instance, we just got sponsored by, I think it was Penguin or maybe Random House. Actually, maybe it's Random House who are publishing three little additional books to go in and around the Dungeons & Dragons movie. So we just did a little ad for them. And that was, again, the sales team kind of going out and being like, oh, we can see that you're looking for advertising places. Why don't you come and advertise on this Dungeons & Dragons podcast? [laughs] So yeah, stuff like that, I think. Those were, I'd say, the main areas, and then it'll kind of depend...some podcast networks will help with editing. They'll have almost like a house style. So they'll sort of...they'll say, oh, we'll do the editing for you because we want to marry up all the shows so that they have a similar sound CHAD: Is Headgum doing some editing for you and not on other episodes, or…? JASPER: No. Headgum pretty much does...one of the best things [laughs] about it is we have an incredible sound designer; shout out to Daniel. He's actually one of the sound designers of God of War, if you can believe that. CHAD: [laughs] JASPER: He's won several awards for sound design. He basically has almost like a little side hustle, which is him and a group of his friends who do podcast editing for Headgum. He does our main shows and our actual play shows. They were like, "Oh yeah, they can help you out with your actual play shows." And then me, as the incredibly stressed-out producer that was also having to listen to multiple hours of my own voice a week, went, "What about the main show as well?" CHAD: [laughs] JASPER: And they were like, "Yeah, fine." [laughter] I was like, "Thank you," [laughs] because I can't bear listening to myself. I don't mind editing, and I'm not bad at it. But listening to my own voice is not on my list of to-dos. [laughs] CHAD: It sounds like, overall, that being part of a network has been positive for you. JASPER: Yeah, hugely. CHAD: That's awesome. MID-ROLL AD: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops. CHAD: Let's talk about...I'm making the assumption...I didn't dwell too much at the beginning of the episode that people understand what Dungeons & Dragons is, but maybe that's too big of an assumption. But it just seems so much more popular now [laughs] than it ever had before. So I feel like I can at least say Dungeons & Dragons to people, and people are like, even if I don't actually know what it's like to play, I know what it is, at least now. [laughs] JASPER: Yeah, yeah, you got an idea of what it is. Yeah, for sure. [laughs] CHAD: But let's maybe, at this point, take a little bit of a step back. And Dungeons & Dragons is more popular than it has ever been before. I think that that's really exciting for creators like you because it must feel like there's more opportunity than ever. JASPER: Yes, yeah, absolutely. And I think that...so this actually, I think really ties into something that I've been doing a little bit of research on, which is...I can't say too much at this point, but I'm putting together a convention. Part of the idea behind this convention was that I've noticed there's a really big trend towards experience-based entertainment. We love movies. We love going out to bowling, all that kind of stuff. But real full immersion-based experiences, I think, are...post-lockdown, everyone's like, yes, give me all of that. I've been cooped up in a house. I want to be whisked away as far away as possible. And so I do think that is part of the reason why Dungeons & Dragons has started to become even organically more and more popular. Because I just think the idea that instead of, I don't know, just sitting around on a Friday with some friends talking, or just watching a movie, or whatever it may be, that you can kind of with your friends go off and take part in something that feels epic and larger than life and really allows you to abandon for just a couple of hours some of the strains and pressures on your life. I think, again, post-lockdown, that just feels like such an appetizing thing [laughs] to be able to do. And I just think with then the general acceptance of nerdiness as mainstream culture; people are just a lot more willing to be like, well, if I'm going to watch a movie with a dude who has a suit made entirely of iron and says really corny lines and shoots laser beams out of his chest, I probably could be okay with pretending to be a goblin for half an hour. CHAD: [laughs] JASPER: Whereas I think before, people would have been really like, no, no, no, we don't do that. I only watch, I don't know, Kubrick movies or something. Do you know what I mean? CHAD: Yeah. JASPER: Like, that's their form of entertainment. CHAD: Yeah, that trend really resonates with me. Even before the pandemic, escape rooms and that kind of thing were becoming really popular. JASPER: Yes. CHAD: I mean, there are escape rooms everywhere now. [laughs] JASPER: One of the things that I found out as I was coming up with the idea for this convention...I was talking to a buddy of mine, and he basically owns an event space, which has a cinema in it, and it also has a little theater. And he ran over; I think it was last summer, a "Guardians of the Galaxy" themed kind of experience where you walked around, and you got to meet some of the characters and stuff like that. And then next door in that building, they were showing the "Thor: Love and Thunder" movie. And despite the fact that the experience was three times as expensive as the "Thor: Love and Thunder" movie at the cinema, that experience sold out almost instantly. And the "Thor: Love and Thunder" movie was struggling to get people on the seats; you know what I mean? But I was like, but "Thor: Love and Thunder" is a Guardians film, you know what I mean? All of them are there. It's ostensibly a "Guardians of the Galaxy" movie, and yet people are going to see a "Guardians of the Galaxy" experience, which I don't even know if it was like an official thing...rather than seeing the movie of it. So I just think, yeah, like you said, this trend for escape rooms and all that kind of stuff just really resonated with me that I was like, yeah, that's...like, if I had to choose, if I was in a privileged position and could afford to go to that thing, I'd be like, pssh, yeah, I'd probably go to the "Guardians of the Galaxy" experience rather than just, eh, I don't have to watch the film. I could probably get it on Disney Plus in like two weeks, so...[laughs] CHAD: Yeah. Have you ever been to a secret cinema in London? JASPER: Yes. I did "Top Gun: Maverick" Up here in Manchester. CHAD: [laughs] I went to the "Star Wars" one a few years ago. JASPER: Nice. How was that? CHAD: I guess, actually, it would have been five years ago. It was amazing. So for people who don't know, secret cinema is you're ostensibly going to see a movie, [laughs] but they build up an entire experience with improv actors themed to the movie that you're seeing, and you don't know where it is. It's technically a secret. They send you the location of it. You go there, and you're whisked away into the world of the movie. JASPER: Yeah, I did a "28 Days Later" one. [laughter] Yeah, that was one... CHAD: Horrifying. JASPER: Yeah, that one was a little much, honestly. [laughs] I was like, I love this movie, but I don't feel safe sat in this cinema [laughs] because I've just walked through three fields filled with zombies and I ran for half of it. [laughs] So, I don't know, I was like, my heart was still racing as I sat down to watch the movie, which I think in many ways, did enhance the experience because I was sort of looking over my shoulder for half of it. [laughs] CHAD: And when people who haven't ever actually seen Dungeons & Dragons played before, I often describe it as we're just telling a story together. Or maybe if they're a little less intimidated by improv because some people are into it, it's like an improv show where you can basically do anything you want or say what you want to do. And then you roll the dice to see whether it actually happens or not. And that's really at the base level all it is. JASPER: Yeah, yeah, absolutely. [laughs] CHAD: And I think you're right; people are more open to that idea of an experience or a game like that than they ever have been before. JASPER: Yeah, for sure. There are so many things that you can kind of fall back on if you're not someone who is super comfortable with improvising or whatever. And I think that's what the game provides is it provides enough structure for you to then just kind of, honestly, because, you know, you do just kind of forget that you're doing it really after about 10 minutes of slight awkwardness when you start with a new group because the game provides you with almost like the fuel. You'll be like, oh, I don't know if I can do this or whatever. And it's like, okay, just go ahead and roll me a d20. And then you roll in that 20, and everyone loses their minds around the table. CHAD: [chuckles] JASPER: And suddenly you're like, okay, I'm in this. I'm the barbarian, and I'm getting angry. And I run in there, and I kick the door down, you know what I mean? And suddenly, you're sat there watching this person who was super nervous five seconds ago stood up on their feet screaming at me as the DM telling me how they eviscerate all these bad guys. So yeah, definitely, the game provides a very good structure for that. CHAD: With this...you mentioned building this experience for a convention. Do you want to talk more about that? JASPER: Yes, I can talk about it in very broad terms. I just can't go into the specifics of when, and the whos, and stuff like that. But ostensibly, the idea was to do a...I got really interested by this idea of reclaiming fantasy. It was kind of like this thing that kept going around in my head. And I was like; I wonder if there's a way that we could see our...again, specifically geared towards minority groups. It's what I know well and a community that I want to continue to serve. And I was like; I wonder if we can create a space where it's specifically for them, explicitly for them in the sense that I think there are a lot of spaces that are explicitly for non-minority groups, you know what I mean? I think a lot of the traditional conventions typically are those things. But I think we get very afraid of creating something where we...people with the purse strings usually go, oh no, you can't exclude people, and I'm like, we're not excluding people. We're just making it very specifically for someone else. And a lot of it was...it then came from the idea of seeing "The Rings of Power" trailer get released. And then the thing that's trending on Twitter is like; there were no black elves, not yes, we've got a black elf, you know what I mean? And I suddenly was like, I really want us to have a space where we can be celebrated in fantasy, et cetera, without having to have that caveated as like seeing it as some sort of diversity hire or whatever. Anyway, this snowballed through going to things like D&D in a Castle and combining it with this idea of reclaiming fantasy of, like, what if we did it inside of like a stately home or a castle? What if we made this event and we really made it that you as a minority can be there and celebrated in the space where you've got, like, Baron, what's his name, on the wall? CHAD: [laughs] JASPER: And it's this White dude from 500 years ago, do you know what I mean? And it's like, I just really loved the idea of a room full of minorities really feeling welcomed and like they were a part of this space, and just realizing minorities we've been around forever, you know what I mean? [laughs] There's never been a point in human history where people with Brown skin haven't been here. We've always been here. So I guess it was just about really realizing that when we sat there watching, I don't know, Pirates of the Caribbean, and there's like two Black people in the swamp. It's like, no, no, no, no, we would have been everywhere, [laughs] do you know what I mean? We would have been everywhere. And we can be celebrated in these spaces too. These don't have to just be White spaces, and they don't just have to be for a very specific group that they have been traditionally for in the past. [laughs] And yeah, the reaction to this sort of pitch, if you will, was overwhelmingly positive. CHAD: That's good. JASPER: And it really took me by surprise, actually, because I was sort of thinking, yeah, I'm really sticking it to them with this pitch. CHAD: [laughs] JASPER: And then everyone was like, "Yeah, we love it." And I was like, oh, right. CHAD: [laughs] JASPER: Okay, yeah. [laughs] I was sort of doing that, and I had to climb down a little bit and be like, okay, awesome. Let's talk about it. What I think is really exciting about that it's just that I really think that conventions and everything can do more in terms of delivering experience. Like myself and my fiancée went to Comic-Con a couple of years ago. And I remember her feeling like, oh, it was just a little bit flat. And it was just sort of...I thought that there'd be more kind of grandeur to it, almost like there'd be more...it was just other than people cosplaying; there wasn't a lot of theater to the whole thing. It was just like in these massive warehouses, and add a little bit of that theater in, have some of those actors, have some of the music and the sound and everything, really give people a place to go and explore and enjoy exploring. And I kind of keep thinking in my head it's like LARP lite, you know what I mean? CHAD: Yeah. JASPER: It's like LARP still with the kind of commercial interaction that you can still go and meet your favorite people. You can still get signings. You can still get previews of things. You can still buy things that you've been wanting to buy all year and that you can only get when you go to a certain convention, and all of the kind of normal convention tropes but really just explicitly labeling it on the bottle: this is for minority groups. Because I honestly think if we explicitly label it like that as well, we'll start to get away from a lot of the things that have plagued conventions for far too long when it comes to making people feel comfortable in those spaces. And quite often, my biggest tip when it comes to diversity and inclusion with companies as well it's just like, put it on the bowl. Like, if you really believe it, have it front and center. Don't tuck it away in like a D&I bit on your website. Have it there so that everyone can see it. Everyone knows when they come to work with you; this is what you stand for. This is what you believe in, things like that, so... CHAD: That sounds awesome. And it's a really good illustration of the idea which we've talked about on the show in previous episodes is that when you are used to being in the majority all the time, and that is the default, when something is being done that's different than that, it feels like you're losing something. It feels like you're under attack. That's a total natural feeling. JASPER: Yes, yes. CHAD: So it's like, that sounds like a great experience. I would love to experience that, and I'm being excluded because I'm White; that's not fair. But that's coming from a position of you've been in those safe spaces for yourself in a world that's been entirely tailored for you. So you haven't realized that you've had that all along. JASPER: Yeah, absolutely. And the beauty of it is..., and this is where it's even better for people in the majority, which is that we have zero intention of making an unsafe space for anyone because that would be wild. So even the spaces that we create for minorities explicitly will still be safe for you as well, you know what I mean? But I think, like you said, it's that reaction, which, again, I get it completely because, as I mentioned earlier, I was there. I've been there. I've been in a space where I suddenly go, oh, I'm part of the problem, and it feels horrible. Like, it's not nice, and it's a really challenging thing, which you have to be comfortable with, and I think everyone should be comfortable with it. Whether you're a minority or not, everyone has blind spots. Everyone has biases. It's a huge part of human interaction. And honestly, in a modern world with the way that social media is, I don't think you can live without biases and without assumptions because you see new people, thousands of new people every day if you want to just by scrolling on your Twitter feed. So to be in this zen place of just like, I will accept everyone only on their merits, and I will not judge anyone would be impossible and maddening, I think. So it's a perfectly normal thing to exist with those biases. The thing that we have to get better at is going, cool; I've got those biases. Now it's time to let them slide, like, to move them over there and to not get defensive if someone calls them out. Like, that's the trick. That's the magic trick. That's pulling the rabbit out of the hat. That's what you got to get comfortable with. CHAD: Yeah, awesome. Well, I really appreciate the conversation, and I really appreciate you taking the time. I know that you get married in less than a week from now. JASPER: I do. I do get married -- CHAD: So congratulations in advance. JASPER: Thank you so much. Thank you. CHAD: If we could just take a few more minutes at the end to maybe nerd out about the Dungeons & Dragons movie, which I know you went to the premiere for, and I just saw this weekend... JASPER: Oh please, let's do. Absolutely. CHAD: It was funny because I think you've said exactly how I left the movie feeling, which was they captured the spirit of what it's actually...like, it was just fun. And Dungeons & Dragons is fun in a way that is not like "Lord of the Rings" [laughs] or just super serious fantasy, right? JASPER: Yeah, yeah. I can't even think of the last time we had a fantasy movie that was like, you know, other than, I don't know, "Your Highness" or something that was just like, I don't know, yeah, whatever that was, you know what I mean? Something that was like an actual movie and didn't take itself too seriously, yeah. CHAD: Yeah, I'm so happy because you could have easily have seen it, like, no, we need to do something super serious and to compete against "Game of Thrones" and "Lord of the Rings" and all that stuff. And to feel like, you know, this was made by people who get it and represented what I love was really exciting. JASPER: Yeah. And I think that what it did for me is I think it lays the groundwork for them to explore more serious places because now they will have that trust that they understand what it's like to be at the table and how to do that. And then I think this is where the real skill is going to come in for them to curate more of these which is like...that, I think, is the art of a really good DM. They can have you absolutely roaring with laughter one minute and then sobbing in like, you know, and it's like an hour's difference, [laughs] you know what I mean? Between the two places. And that's then the next step for these. But I think this was absolutely the tone they needed to strike for this, especially for this first kind of outing. I think they really needed to say, hey, we get it. We understand what it's like, just displaying purely unhinged actions and things, which I think that's the bit that feels D&D for me is when a character...and I think I won't go into any spoilers, but I think you'll probably know the moment I'm describing when a very clear solution is laid out in front of you in big, green letters, for instance, and you choose to do something truly, truly unhinged and wild. Because that was what you decided you were going to do ahead of time. It's such a D&D thing to do. [laughs] And I loved that. It was one of my favorite moments in the movie. And I just thought that perfectly encapsulates the nature of it and the thing that you don't get to see in "Game of Thrones" or whatever because you don't get the Nat 1s or the Nat 20s, I think in the "Game of Thrones." Everything's like 7 to 12; you know what I mean? CHAD: [laughs] Right. Right. JASPER: Everyone is relatively skilled, so they can't just, like, you know what I mean? You can't have the mountain versus the Viper, and the mountain just trips over a rock and brains himself on the floor. CHAD: [laughs] Right. JASPER: You know what I mean? Because that would be a Nat 1, but that would be ridiculous because the mountain is an incredibly skilled fighter, and therefore, it wouldn't work like that. CHAD: Yeah, yeah. I found myself grinning throughout, aside from the moments where I was laughing, just like, oh, that's...yes. JASPER: [laughs] CHAD: Just the whole thing about planning and how he's a planner. JASPER: Yes. [laughs] CHAD: Oh, that is so D&D. And just at the end, the way that that battle lays out, I just feel like it just captures everyone's act in the six-second increments in a D&D battle. And everything's happening all at once, and that's what that battle was like at the end. JASPER: Yeah. And it also just props for like a really good magic fight. CHAD: [laughs] Right. JASPER: Like, I don't even know what the word is, but we have been convinced for years that Harry Potter had good magic, but no, he doesn't. CHAD: [laughs] JASPER: Harry Potter has wand-fu, and it's terrible. It's like; it's not particularly pleasing. It's basically the same as "Star Wars." It's just like a little laser pistol type, piu-piu-piu. CHAD: [laughs] JASPER: That's effectively what Harry Potter becomes. And then to see Bigby's Hand and spells like this be used in the ways, like, it was just so fun. And also, it really teaches the importance of flavoring your attacks and how much life you can bring to a game, to anything, by just adding that little bit more, like, that little bit of extra sauce on top. I think Holger the Barbarian does a perfect job of this in the movie where she's always using improvised weapons, and the way that she fights it's, oh, it's very, very pleasing to watch. And you're sat there going, yeah man, barbarians are so cool. But half the time when you're in a game, you'll just be like, yeah, I run up, and I attack with my axe. It's like, no, give me more, give me more. Tell me how and why and stuff like that. So I agree; I think they did a great job. And I was also just grinning from ear to ear [laughs] during most of it. CHAD: I feel like I could talk to you all day. JASPER: [laughs] CHAD: But I really appreciate it. If folks want to either get in touch with you, we mentioned at the top of the show you are a Game Master for hire, and you do games remotely, right? JASPER: Yes, I do. I do. I do. CHAD: So where are all the places that people can find you, get in touch with you, book you, all that stuff? JASPER: Heck yeah. If anyone knows about my GMing for hire, it's you. [laughter] You had me DM for you for, in total, like, 29 hours in the space of a week. [laughs] CHAD: Yeah. So we brought Jasper and we had the thoughtbot summit where we got the company together in person and so Jasper came and he DMed two sessions with two different groups for us, which was awesome. And then I went to D&D in a Castle, which you mentioned earlier in the show. It's where you go to a castle in the UK and play D&D for three and a half days straight basically. It was an amazing experience and Jasper was an incredible DM. JASPER: Thank you. And if anyone is interested in hiring me as a DM, like I said, I do consultancy, whether it be D&I consultancy or podcast to help you grow podcasts and things like that, or even just get started. Most of that information is on my website which is jasperwcartwright.com. You can find me on all social medias. I'm usually pretty good at responding to people in there, and that is just @JW_Cartwright on all of my social media. So yeah, go follow me, and I've got a bunch of really exciting stuff coming up, so it's a good time to follow me. [laughs] CHAD: Awesome. You can subscribe to the show and find notes for this episode along with a complete transcript at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Mastodon @cpytel@thoughtbot.social. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks so much for listening and see you next time. ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.Special Guest: Jasper (William) Cartwright.Sponsored By:thoughtbot: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devopsSupport Giant Robots Smashing Into Other Giant Robots