Giant Robots Smashing Into Other Giant Robots

Alexandra Holien is the Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. She talks with Chad about working for a nonprofit that prioritizes teaching Black, Brown, Latinx, Indigenous, Hawaiian, Pacific Islander, and low-income folks software development for free. Ada Developers Academy Follow Alexandra on Twitter or LinkedIn. 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 Alexandra Holien, Vice President of Revenue and Strategy and Deputy Director of Ada Developers Academy. Alexandra, thank you for joining me. ALEXANDRA: Thank you for having me. I'm excited. CHAD: Let's start right off the bat with giving folks a brief overview of what Ada actually is. ALEXANDRA: Yeah, I'd love to. Ada Developers Academy we are a super unique non-profit, and I think, well-functioning business. We're a tuition-free 11-month software developing bootcamp academy for women and gender-expansive people. That may sound like some of the other bootcamps you've seen out there, but we're completely different. We have this really cool intersection of education, social justice, equity, bringing money to the people that need money sort of drive about us. We prioritize serving Black, Latine, Indigenous, Hawaiian, and Pacific Islander folks, and low-income folks. And we prioritize them because they've been left out of this capitalistic system the most. And we think if we can really put money in the hands of these gorgeous, resilient communities through the career of software development and one of the hugest wealth engines of our time, then we're going to change the world. We're crazy because it's like we're free for our students. CHAD: [chuckles] ALEXANDRA: There are wraparound services, ridiculous, not even ridiculous, just like, natural. And it seems unique, and it seems crazy. But these things that we're doing to support our students are actually just human and basic needs, providing comprehensive support for our students financially, childcare, mental health care, free laptops, just making sure that they're set up for success, unlike I think other more traditional education systems. So they can go and be really amazing software developers. And it's proven time and time again if you just set people up, open the door, give them the opportunity, make sure that you're creating equity, then 92% of those folks what we're seeing is our numbers are going to go out there and get full-time software development jobs. So that's Ada in the smallest nutshell and believe me, I'm going to tell you way more. CHAD: Well, we're going to dig into each of those things and more. I interview a lot of people who graduate from bootcamps. We have a pretty wide-reaching apprentice program. And I'm pretty familiar with what it looks like when people are graduating from those programs. And you can graduate from a three-month program and be successful, and I don't mean to imply that you can't be. But I do see folks who go to slightly longer programs, up to 11 months, a year like at Ada, and those people are often much more well-rounded developers not only with the technical skills but with all of the other skills that are important to development. How intentional was the length of the curriculum? And was there pressure early on to get people into the market faster? ALEXANDRA: Yeah, great question. I think that so many...let me answer your first question, which is how intentional was it? It had to be at the forefront of what we wanted to do. And the reason why it had to be is that we were taking a group of people that had already been left out of the system. And we already knew that there were going to be steps that they had to take to get into...like, once they got into the tech industry, getting in and staying in was going to be harder than their counterparts, harder than the white dude who took apart a computer or a Nintendo when they were in the 80s and growing up because their dads were software engineers. And then went on to college and knew they were going to be software engineers. So our founders, Scott Case and Elise Worthy, were so intentional in making sure that the technical bar and the technical merit of our students going into the industry was not what they were going to have to worry about. That was not going to be the thing that kept them up at night thinking like, oh, man, I don't know if I can do this because I don't understand it. That was not going to be it because we knew there were going to be other things. We knew there were going to be people mistaking you for the secretary. And these are examples that are all true. It's mistaking you for the secretary or the person that's the assistant or the executive assistant when they walk into the room or that person that constantly misgenders you. We knew there were going to be other really big obstacles that they're going to have to overcome when walking into a very homogenous industry like the software development industry of the United States. We knew that that was going to be the big thing. So being intentional about the programming that we were going to offer our students that five and a half months of nine-to-five intense programming that also concentrates on what I don't think a lot of bootcamps really concentrate on, that CS fundamentals part of it, showing people that that is a part of the world. It's not the part of the world of the most entry-level software engineers, but it is there, so showing them that that's there. And then giving them that internship, giving them that on-the-job training that Ada does that no other bootcamp does like we do. That sort of on-the-job training where you go in, and you see what does that practice of what you learned in code look like in real-time when you put it next to one of our sponsoring companies' tech stack? So it had to be really intentional. I don't know if it was like, yes, this has to be perfectly like this. I think we definitely iterated and made it better over the years. But making sure that the technical bar of our students was at the technical bar of everyone else was something that we really wanted to make sure that we hit on. So they didn't have to worry about...so retention was not that they couldn't quote, "hack it" like everyone else like the people say, or they didn't have the aptitude. The retention was all about is the company creating a good enough environment for these folks to want to stay at that point? CHAD: What is the tech stack that you're teaching now? ALEXANDRA: Yeah, we just switched. We talked about this for a little bit. We just switched from our beloved Ruby on Rails. We were Ruby on Rails for a very long time. But we just switched to Python, React, JavaScript. HTML and CSS is part of our curriculum. And yeah, that's it, Python, React, JavaScript. CHAD: I don't take the switch away from Rails personally. [laughs] ALEXANDRA: People did. We had companies being like, "What are you doing? We love Ruby." And we were like, "Yes, we do too, but we had to move forward and on." [laughs] Ada started at the same time Ruby was in the spotlight, too, eight years ago. CHAD: So is that what you're seeing in the industry now, is Python, React are in more development, in more demand? ALEXANDRA: Yeah, we're seeing that definitely come up. We put together a steering committee for our curriculum when we made this switch. We basically just brought in our partners to help us like, okay, what is the thing because, you know, our partners range...every cohort, we have a company that sponsors the education of one of our students, and then they take that student on as an intern. So we can't please everyone. We knew we couldn't please everyone here. But we wanted to find a good middle, and Python seemed like a really good middle. Python, React was a good middle for us to go towards for just the future. Eight years from now, again, we'll probably be in the same place we are right now. But we say it's like teaching Spanish. We're not teaching you building out a bunch of Python engineers. We're building out people that know how to be agile, know how to learn different curriculums, know how to be flexible and all that, and know that the industry is changing, and you have to be a lifelong learner, right? CHAD: Yeah. ALEXANDRA: You know this to be a part of this industry. CHAD: Well, beyond the tech, what are some of the other things that students in Ada learn or focus on over the course of the program? ALEXANDRA: I would say our curriculum is broken out into three distinctive pieces that are all a part of our everyday classroom. So that first part being that technical part that our students really are just getting the chops of what it means to be a software engineer, understanding a full tech stack, understanding the frontend, backend, the APIs that all connect the stuff, just making someone that sort of bare bones of what I think is a good software engineer. The next step is that social justice piece, which is held up by our equity and policy team. They're really teaching students once you get in the door, it's not just about getting in the door; it's about staying in the room. And it's about not just diversity; it's about inclusion. And we're seeing that we cannot just expect just because someone's decided to sponsor an Ada student, we can't expect someone knowing how to support someone that is outside of what they've supported in the past, and we know what that looks like. So we have to really create students who know what allyship looks like, know what advocacy for themselves looks like. So they can really manage up in this process, bring people in. We do not want to say someone did something or said something to me, so we're just going to push these people away because we found that when you push those people away, especially in the tech software engineering space, you're really just left out of it. You're just out of the system. So we have to figure out how to change the system from within. So really teaching students how they can talk about gender expression, how they can talk about racial expression, how they can advocate for themselves while they're on the job. And the goal of all of this is actually to keep people on tech. We don't want our students having to talk about these things all the time. We want them to be talking about the tech that they're doing just like they want. And so we want to just keep things as much on tech as possible. The third part is our professional development part. How do you manager up, take yourself in that first block to that SE2 SE3? And that's just helping folks with career development. CHAD: When it comes to the inclusion piece, I imagine it's a little bit of a fine line to walk because you don't necessarily want to put all of the work of creating an inclusive environment on the people who have been historically marginalized. But at the same time, you want to set those people up for success coming out of your program. How directly do you provide training to the companies that are sponsoring? ALEXANDRA: Completely directly. [laughter] We know that if we can get a whole...I would say I sign people at the CTO level and the senior manager level. They have the budget. They're the ones pulling the purse strings. But once we figure out, once you sign on as a company, your manager and mentor are going through our corporate accountability training. While our students are learning the technical part of it, our managers and mentors are going through a monthly training with our team to make sure they are ready to receive these interns. So when that intern comes on-site, they're speaking the same language. We're not only teaching the students how to be allies and advocates. We're teaching the managers how to be. So many times, they're like, "Someone on my team keeps misgendering someone, and I don't know what to do." We had enough of those calls, so we decided to teach them what to do. And not only do we teach them, but we also put them in peer learning groups together so they can teach each other what to do because that's where they really start listening to each other. When two folks coming from the same background are having a conversation on how to be a better manager, we love that. CHAD: Yeah, that's great. And I think that's really likely a very important component to overall success. Well, let's talk economics a little bit because I've gotten up on my soapbox before around how companies have traditionally been way too comfortable saying, "Well, we have this position open, and we're using recruiters." And the position has been vacant for months. And in the meantime, they're willing to pay recruiters tens of thousands of dollars trying to fill the position. And I've always made the case like, tech and the way the economics work it would be better to invest that money that you're willing to give a recruiter into training people. When I learned about Ada, it really resonated with me. So what is the complete picture of how students afford to attend Ada, where the funding comes from, and how that all works out for them? ALEXANDRA: Oh, you're speaking to the choir. [laughs] When I talk about this with companies, I am oftentimes like, "How much did you spend on recruiting last year?" And then they tell me the number, and I'm like, wow, okay. We work with companies we call them our company partners because they are partnering with us to complete this mission of Ada that we have, which is to educate more women and gender-expansive people to be software engineers. Our business model is simple, but it works. We wanted to remove all barriers for entry for people that wanted to become software engineers within that group. So we wanted the program to be free. We knew that was always the case. We knew that there was this hole with bootcamps that was out there. This was seven, eight years ago where it was like people were going through these bootcamps and then not getting full-time jobs. And so we knew we didn't want to fall victim to that. So what we did was put an internship on the backend and really got companies to not just put their money where their mouth is but put their time and resources where their mouth is. That's more money. So they pay $55,000, and that $55,000 educates the student while they're in class with us, keeps the program completely free for our students. And then the other part of their buy into this whole shebang is you have to now make this person a hireable junior engineer because they're going to do an internship with you. And then everyone's always like, okay, the return on investment. To me, the return on investment is you did good, company. CHAD: [laughs] ALEXANDRA: But also, the return on investment for a lot of our company partners, I call it the icing on the cake because it is not a part of our model. It is 70% of them convert their students to full-time jobs, full-time FTE offers from these internships. We had a company give...they sponsored six interns, gave six offers, and then went on to do a hiring loop with our graduating cohort and gave another 23 offers. CHAD: Wow. ALEXANDRA: And this happens every six months. So these companies that are out there saying it's a pipeline problem or I'm just going to spend money on this recruiter to go find talent, I'm like, are you kidding me? We're either in your backyard, or we're a phone call, phone call, excuse me, an email away. CHAD: [laughs] A fax away. ALEXANDRA: I age myself. I said Rolodex to our students, and people didn't know what it was, and I was so embarrassed. I was like, wow, I guess a LinkedIn I'm sorry. CHAD: [laughs] ALEXANDRA: But we're like, you know, the resource is there, the talent is there. We have 120 students in our cohorts, and that's only growing. We're expanding to Atlanta. We're expanding to the DC area. It's there. So when companies are like, "I don't know." I've seen us move the needle at mid-sized companies. There are companies like Amazon, and there are over 100 graduated Adies there. We've moved the needle. So it's like, you just got to call or email at this point. There are other ways to do it. And if you keep going to the same well, you keep going to the colleges; you keep going to that recruit, yeah, you're going to fill up the same thing over and over again. And we know 70% of jobs are received by...you’re networking with your friends, and you’re networking with your peers. And if something like 75% of the industry is white dudes or just dudes in general, then we're just going to keep bringing in the same person. And it's not just diversity is the right thing to do. It is the right thing to do, but it’s also like you build a better product, period. That's just a better product. CHAD: Yeah, the different perspectives that people have, the different blind spots that people have. When you get rid of those, you build a better product. ALEXANDRA: And we're talking about building the future here. We have to include the other 50% of the population. So it's imperative. It's not necessary; it is imperative we get up to that. You're at 40% in your company. We got to get up to 50%. We got to get a little bit more. And we got to make sure that 50% is diverse on all intersections of what diversity can mean. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So you mentioned the companies pay to sponsor individual students. You also have mentioned earlier in the conversation that you provide things like child care. So are the pooled resources of all of those sponsorships also going to pay for those additional benefits while in the program, or do you have another source of funds? ALEXANDRA: We are still very much so a non-profit. [laughs] We have a good amount of philanthropic dollars coming our way, and it's individual donors. I would say one of our biggest clumps of donors, our biggest group of people that donate to Ada, are our alumni. They come out with 160% salary change, and they are the first people to see the value in giving back to Ada. We also have some major donors out there. We just got a pretty large expansion grant from the Pivotal folks, which is Melinda French Gates, MacKenzie Bezos, and the Schusterman Foundation. They invested $10 million in helping us expand. That expansion has served more students. Wraparound services mostly come from philanthropic dollars. So donating to what we do, donating to keep our program equitable, is always very much needed because about 10% of our budget is all philanthropic dollars, and that's covering those wraparound services barriers to entry. CHAD: Is healthcare one of the wraparound services that you provide? ALEXANDRA: No. I wish. I mean, geez. CHAD: I know. ALEXANDRA: If the U.S. government gets it right, after they get it right, we'll follow soon. [laughter] But we're trying. We are trying to do it differently. We're trying to meet people where they are and see the reality of people's situations. And the reality is that if you're a woman or gender-expansive person and you want to take this chance, we offer a zero-interest either loan or a zero-interest grant that comes directly from Ada, or from our partner, Community Credit lab. And that's a zero-interest loan. We don't even check your credit. If you're in it with us, then we're going to get it in it with you. And that zero-interest loan just gets recycled back to serve more people. So that zero-interest loan is while you're in class for that five and a half months, you're going to need still some money coming in. So we make sure you still have money coming in. The stipend hits when you get to internships, so from that 55,000, about 17 goes directly to the student for their stipend while they're interning. Also, we give a childcare stipend. We're looking for a childcare partner out there because we really want to be able to make this more of a national program. But we're looking for that out there. But we give that stipend out to folks so they can pay for daycare or whatever they may need so they can actually come to the program. We have a laptop program. You need a Mac to come to Ada. Everyone can't afford a Mac. We take donated Macs from companies that...companies sometimes give them a two-year life cycle for their Macs. So we can use it for another couple of years. So we take donations for Macs. And we also have a fund that we fund every year so people can buy a Mac. And my favorite and I think one of the most needed things is we partner with BetterHelp and offer our students free therapy while they're in the classroom and while they're in their internship and a little bit after that as well. The free therapy was just...we're in a pandemic, and it's hit women hard. It's hit gender-expansive folks, parents, Brown folks, it's hit people hard. And so we're like, hey, why don't we, while you're in a pandemic, send you through the most rigorous part of your life? [laughs] And so, making sure we were supporting people all around was really important to us. And it did nothing but create success for us. This did not make a deficit in our bottom line. This actually created more success for us. We saw when we did this; we got more people graduating. We get more people donating back. We get more people paying back their loans faster. So it just does nothing for the community but make it better and stronger. So we're going to continue to do it. It's going to continue to always be a part of who we are at Ada. But the wraparound services are key to the success. CHAD: That's fantastic. So you mentioned you're expanding. Where is the original location? ALEXANDRA: Seattle. We are a Seattle-based school. CHAD: And you're expanding to Atlanta and DC you mentioned. ALEXANDRA: Yeah. We first went digital because you know -- CHAD: That is what I was going to ask. ALEXANDRA: [laughs] CHAD: How have you dealt with the pandemic with a primarily in-person model previously? And then how has that affected your expansion plans? ALEXANDRA: The pandemic was shitty and just horrible in so many ways. And out of a lot of shitty and horrible times, it creates a lot of innovation, and that's what it did. Our leadership team is a group of Brown parents. And they went to work immediately. We switched from being an in-person classroom where there's a lunch club, and a push-up club, and there are hugs everywhere and to being 100% online program in three days with systems. And companies were coming to us saying, "How are you creating community in this time?" So we did it very quickly. It taught us that we can educate people digitally. So the first thing we decided to do is like we've got our digital cohort up and running. So still, I would say in quotes, "our Seattle cohort and digital cohort," but digital cohort basically means you're partnering with a company that is fully digital, and they are not attached to anything geographically. And that helped us expand to Atlanta because it helped us jump over the hurdle of like, oh, we have to go get a brick and mortar. We have to set up this brick and mortar. Instead, we just decided to educate people still digitally. If you're in the Atlanta cohort, you're still having your education 100% online, and your internship is going to be in person with an Atlanta-based tech company. So you might be but and see [inaudible 24:11] in Atlanta later on, but we can educate you digitally. So we didn't have to slow this down. We saw the need just like the amount of women that lost their jobs in the pandemic. We were completely energized by the fact that we can do this. We have people that believe in us. They're giving us money. They're funding this. We can do it. So we went for it. And Atlanta is the first campus. We already have staff there. We already have a campus director on point there. And then, the next expansion will be to the DC area. And we're excited to do the same thing. It's educate them digitally because that's what we've been doing for the last few years, and we're good at it. And find but and see partnerships in DC because that's how we can really make sure we have good programming that we know they can do and then give them to the sponsoring companies to complete their programming with the internship. CHAD: So where are the current limits of growth for you then? ALEXANDRA: Current limits for growth, I mean, we've been such a Seattle-based place, and COVID pushed us into that national arena, so not a lot of people outside of our geography know who we are. Pacific Northwest was our sweet spot because people used to have to move to Seattle to be a part of Ada. So we got a lot of Californians. We got a lot of Oregons, Montana, Idaho, some Floridians because Florida knows about...we have a very huge population of Floridians. I don't know how they know, but they know. CHAD: [laughs] ALEXANDRA: Our thing is, how do we get the Ada Developers Academy name and model out to the rest of the country? So they know that we are here, and we're an option for them if they want to become a software engineer. CHAD: And right now, it sounds like you have your sights just set on the United States, not internationally. ALEXANDRA: Not Internationally. I always joke about Ada at sea, but we'll see. CHAD: [laughs] ALEXANDRA: Give me 10, 20 years to get that spun up. But I would just love to...[laughs] but yeah, over the next five years, there'll be five markets in Ada. By 2025, we're hoping to educate 10,000 women and gender-expansive people. We just graduated a class of 72 last Thursday. And we just admitted another class of 120 that starts in March. So we're chugging. But right now, it's Seattle, digital, Atlanta, DC. I imagine there'll be a Southern region, and then probably a Midwest region coming after that. CHAD: So, and then you have the purely digital cohort too? ALEXANDRA: Yep. And that's that sort of the sixth market, purely digital, which means there are so many companies that went fully remote and have no plan on coming back. And so that's just a market that we want to make sure that we're...we want people to opt into that. That's for some people who want to be fully remote forever. Some people are seeing that they need some sort of community while doing this work. And so they want to have a but and see internship. And there's every which way in between. So we'll figure it out as we move through this pandemic like the rest of the folks. CHAD: You've shared some numbers there. And I think sometimes it's good to put that in context because people don't realize that 10,000, on one hand, sounds like a small number in the grand scheme of the United States. But actually, it's a very large number. ALEXANDRA: It's huge. CHAD: The U.S. only graduates around 65,000 CS graduates a year in the whole United States, so just to put that in context for people. ALEXANDRA: Yeah, it's huge. I looked at the numbers for...I'm in Seattle, and I'll just say there's a college here, a large college here in Seattle, and they graduated 300 CS folks last year, and 20% of them were women. And we graduated in six months, 72 women and gender-expansive, and our focus is Brown folks, low socioeconomic folks. So you could just imagine underneath that umbrella of women, even under that, the diversity that you see. We're getting up there with some of our colleges, and we're doing this every six months. And so it's a powerful model. It's the reason why I've been here for six years. It's the reason why I get really excited talking about this program. [laughs] I don't know if you can tell, but I get really excited talking about it. Because once people get in, they love being a part of our program, and they love being a partner with us. And it's a cool place to be. It just feels like a transformative place right now. And I think that we can really make a difference. CHAD: Yeah, your excitement, and I'm a big believer in the opportunity. Your excitement is clear [laughs] when you're talking about it. How did you get into this work? ALEXANDRA: I was in recruiting before. I did technical recruiting, contractor for a few different places. And I just saw the amount...and I came from a working-class. My family is from the Deep South in Louisiana. And the average income from the town I'm from is $26,000, and that was my reality. And then, when I started technical recruiting, it was insane. The amount of wealth that was a part of this churn, the going to these colleges, early recruiting, paying people $6,000 a month, paying them a living stipend, making sure they had a plane ticket home, hot air balloons, tours of people's, you know, these millionaires houses. I was like, holy crap, this has to be more readily available. And again, having two working-class black parents, they didn't even know what software development was. We didn't even know that was a possibility. My dad was like, "We're getting a computer," because he wanted to be on the forefront. And we got to that clear Mac that was like a purple color. We had that purple one. CHAD: [laughs] ALEXANDRA: And my dad was like, "We've one." But still, there were kids in my school and in my college that had been around computers their whole lives; their schools had programming and things. So they just had that extra step. My opportunity to see in was recruiting. And after that, I was like, okay, where do I find the intersection of this and what I want to do, which is making sure that black folks have money? To be crude about it. [laughs] If we’re going to work and live in a capitalist society, then I want us to have some coins to play, and that is where I found Ada. And I love having this place. I just get to be a part of this place where I just get to open doors or show people a door. They can open it themselves and go through, and just that's the amazing part of me, a part of this is watching people change their lives, buy their grandparents' homes, pay off their student debt, get a divorce, anything they want to do. [laughs] But to have the agency to do it in this world we live in, in the society we live in, and that's all I care about is that agency. CHAD: Yeah, I was very privileged to be exposed to computers really early on and get to experience that spark of I love this. This is what I want to do. And I talk to so many people who just never had that opportunity to discover that that was even a thing that they could do, let alone love. It's just incredible when I meet someone who's like a plumber, and then they somehow get that exposure to computers or technology, and you see that spark go off for them. And it's amazing. ALEXANDRA: It's so cool. It's one of my favorite...like; our admissions process is pretty rigorous. I think the average is like 15% or 20%, depending on the cohort admissions process. And to hear how obsessed these airline stewardesses or hairdressers or mothers are obsessed with coding, I'm like, yes, yes. Or these folks who are like...Oh, we had this woman who she was an immigrant from...she fled Israel, and she came to the U.S. And she's like, the only thing she knew about coding before she started was she had one time saw someone with two screens in a movie. CHAD: [laughs] ALEXANDRA: And she saw them on the computer, and she saw two screens. And then she started going through finding free stuff online. She found Ada. And this person's sitting in front of me talking about how geek they are about arrays and loops, and I'm like, yes, this is amazing. And to watch that person graduate less than a year later with just the salary that she got from Microsoft, and just the feeling that she felt when she got to call home and say, "Hey, I'm a software engineer now," I was like, all day, all day. That's like the gravy for this. CHAD: It has nothing to do with aptitude. It has everything to do with opportunity. ALEXANDRA: Oh my gosh. Yeah, opportunities. Yeah, it's everything here. CHAD: Well, that's great. And Ada is providing folks with that opportunity. And I am so excited to hear about it and share it with our audience. Hopefully, students are listening and want to sign up but also those sponsoring companies too, right? ALEXANDRA: Yeah, for sure. Sponsoring companies too. We love you too. You keep the wheels on this bus. So definitely give us a call. CHAD: So if folks want to get in touch, where's the best place for them to do that? ALEXANDRA: Our website that's the best place to start, adadevelopersacademy.org. And there there is stuff on corporate partnership. If you sign up on the partners' email list, it leads you right to my email. And then, for students, we have full admissions. Our admissions opens in March for the next Atlanta cohort. There are going to be 48 seats in Atlanta, 60 seats digitally, and 60 seats in Seattle. I would say get ready for that via our website. CHAD: Awesome. You can subscribe to the show and find notes for this episode at giantrobots.fm along with all those links that Alexandra just mentioned and a transcript of the entire episode. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guest: Alexandra Holien.Support Giant Robots Smashing Into Other Giant Robots

Dagna Bieda is an engineer, career coach, and founder of theMindfulDev.com. She talks with Chad about being a software engineer first and then becoming a career coach who has helped a big range of clients with communication and marketing themselves successfully. theMindfulDev Follow Dagna on Twitter or LinkedIn. 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 Dagna Bieda, engineer, career coach, and founder of theMindfulDev.com. Dagna, thanks for joining me. DAGNA: Absolutely. It's a blast being here. So thanks for having me over, Chad. CHAD: So what you do is a little bit unique in that you provide career coaching to engineers. But you yourself are an engineer and have a background in engineering. So how did you arrive at what you're doing today? DAGNA: Yeah, you're exactly on point there. I was a software engineer and then turned into career coaching. So essentially, I've been coding for over ten years and coaching for the past 3. And I'm the tough love, “I've been in your shoes” kind of coach because I have that engineering experience. And a little bit about what it is that I did as a software engineer is I essentially moved from programming in microcontrollers in C through cell phone towers, providing LTE networks in C++. I also did behaviors of social robots in C++. I wrote a distributed web app in Ruby on Rails. And I also wrote some mobile apps for parking and transit in Swift and Java. Having that range of experience, I really get to help a big range of clients. My former clients have worked for LinkedIn, Amazon, Google, Disney, as well as much smaller businesses. And their own experience was ranging anywhere from 2 to 20 years of experience. And I had clients who are self-taught, who are career-changing bootcamp grads, who are college grads. And my goal as a coach is to really help them reach for their potential. CHAD: Now, did you arrive at this because you yourself struggled with some of these things? Or did you have it easy and you said, "Oh, I don't understand why these other people..." [laughs] DAGNA: So both of these questions are exactly on point. I feel like I had it very easy at the very beginning of my career. I essentially got promoted to a senior engineer very quickly. It took about two years or something, so like superfast. But then, as a senior engineer, there was a moment where I felt that I've just plateaued in my career, and I was stuck, and I was frustrated. And I wanted to learn all the technologies out there. And what was missing was some people skills. So once I finally was able to figure out okay, this is what I'm missing...and in hindsight, it was so obvious. I decided to move into career coaching because I realized that we're kind of brainwashed, so to speak, to put the technology on a pedestal and ignore everything else, right? CHAD: Yeah. DAGNA: But if you don't work on your soft skills and don't realize that at the end, it's all humans because you're working with humans...you're creating products for humans. So it's not something you can really escape from. That was like a huge aha moment. I was like, people don't even know this is important. Like, I got to change that. [laughs] That was a mission for me to change that, to help discover what are those roadblocks? What are those limiting beliefs that software engineers often have that keep them stuck in their career and frustrated and stopping them from really fulfilling their potential? CHAD: I often say that almost all problems are actually communication problems at their heart. DAGNA: Ooh, yes. CHAD: And in consulting, we have clients who come to us with what they think is a technical problem. And we have to sometimes tell them like, "We can fix this problem. But if you don't address the underlying communication problem that caused it in the first place, it's just going to happen again." DAGNA: Absolutely, yeah. CHAD: So I think that's a problem engineers have is that they try to apply technical problems or think code is the solution to every problem. DAGNA: Well, it's not just that. Let's think about how software engineers are trained into their careers. If you have a class and you need to deliver a piece of code that compiles and does whatever it was meant to do for your assignment, even if you had incredible communications with your teammate and partner, even if you negotiated changes in the scope of features, it's all not going to matter for you passing your class if the code doesn't compile and if it doesn't do what it's supposed to do. So early on, whenever we're creating software, we're taught how to create software. We're being taught to put technology on a pedestal. And I've worked with multiple senior engineers that feel really frustrated because they're so knowledgeable but aren't able to communicate all this knowledge that they have in their own mind. They might be having brilliant ideas that might be helping their businesses grow and get past helping the businesses they work for grow. And they're not able to pitch those ideas and not able to really be heard and seen for the value that they bring to the table. And this is where I come in, and this is what I help with, getting past that frustration and that feeling of being stuck. CHAD: And just to clarify if I'm following right, and what I'm advocating is this isn't just if you're a developer and want to move into management. This is for just moving up in your career as a developer, right? DAGNA: Absolutely. Here's the thing, even if you're going to become the principal architect in the company, what are the skills that you need to have? It's not just technical expertise. If you have technical expertise and you're not able to talk about it with the business stakeholders that don't have the same amount of knowledge that you do, then you're not going to get to that point. Principal engineers create direction in the company, make decisions, have to be mindful about the business value that they're creating, not just the underlying tech stack. So as we grow in our careers as software engineers, it is really critical to, once you have, I'd say, five years of experience as a software engineer, to start working on the soft skills. And to be honest, someone who has gone through a coding bootcamp because they had less of that brainwashing about putting the technology on the pedestal often tend to advance in their careers much faster because they bring that previous experience with them to the table, so they can communicate better. They have different types of ideas, different perceptions. They don't have those limiting beliefs that a lot of developers have. The number one limiting belief that I see my clients have is believing that the work they do speaks for itself, and it doesn't unless someone literally dives into the code that you wrote. So for you to be able to advocate for your career, you need to be able to say, "Hey, I wrote this feature," and not expect people to dive into the code and look through the feature and all the lines of code you wrote. It’s to be able to emphasize the business impact that the feature you wrote had on the business, and how it helped, how you contributed to the business side. And that's something that I work with developers on. Now, you did mention, Chad, that you work with a lot of developers, right? CHAD: Mm-hmm. Yeah. DAGNA: Would you say that marketing what developers do is a huge thing holding people back in their career? CHAD: Yes, not only because of what I said earlier about a lot of the root causes of problems are around actual communication. But you're right; when it comes to who you can rely on in your company, who you can communicate with, who gets their ideas across more, it comes down to being able to communicate those ideas and that value. Even little things like when the code you've been working on is ready on staging, don't just say, "It's on staging. Check it out," and moving the ticket forward. DAGNA: [laughs] CHAD: But actually being able to communicate what you've done either through words or screenshots. I think we've all been in scenarios where you're working on a complicated ticket, and you are making decisions along the way about how to do that. And you make all those decisions, and they're the best decisions in the world. But if you just put that ticket up for a review and say, "It's on staging," it's either not going to be accepted, or you're going to get tons of questions around why you did this. What did you consider when you were doing this? It's like a lack of trust and understanding there. But if instead, you say, "Here are all the things I'm considering along the way." And you say, "I've balanced all of these priorities, and here's the decision I've made, and it's on staging, and it works like this. And here's where you go to view it. And click on this. And here's a movie that shows how it works". People are going to be like, "Oh, sounds great. Accepted." DAGNA: Yeah, absolutely. But here's the thing. As developers, we're not taught to do all these things that you just described. We're taught to write code that compiles, boom, done. [laughs] CHAD: So when working with people who have this sort of mindset o the skill gap, what are some things that you have people do to level up? DAGNA: Yeah, there are certain things that we specifically work on, and that is negotiation, setting expectations and boundaries, being able to respectfully either decline a change in scope of work or try to negotiate the change of a deadline whenever there's an impossible feature request. Or things like being able to set expectations that if you're working on your focus time, that you shouldn't be disrupted. And it's something that's very hard because developers usually really want to be helpful. So when a product manager comes to them and says, "Hey, I really need this. It's for a critical client," what happens is most often than not, they're going to drop everything they were doing just to finish that one thing and be helpful. And so being able to create a boundary saying, "Hey, I'll get back to you after I'm done working on what it is that I'm working," is a skill. Being able to market what you did and being able to show the business value, how your work contributed to the business side is also a skill. And even having communication with your manager telling them, "Hey, I realize that I need to work on XYZ. Would you be willing to give me feedback? Because we go to the meetings together, you see how I communicate; you see how I think, you see how I act. Give me more feedback. What can I do to grow in my career?" So asking for that feedback is a skill. So there are a lot of moving elements, and these are the skills that I work with on my clients. But there's a big thing that I want to address here too is that with technology changing and being at such a fast pace, it is very important to give yourself grace, especially when you're starting out. Be patient with yourself to give yourself that time to actually master the tech part. And it's really important to see and understand how you think about your career growth. Do you beat yourself up in your mind, or do you actually see the opportunities for growth? With developers, since we're not being taught how to communicate effectively with other people, oftentimes, when someone wants to give us feedback that might help us in our career, we get defensive because it feels like an attack on our character. And I see it with juniors all the time. "Why did you say I was messy?" "No, no, I said your code was messy." Taking that kind of feedback on the code very personal and getting agitated instead of seeing opportunity for growth in the career. CHAD: Would you say that most of the people that work with you are doing it while they're going through a transition or in between looking for their next thing? Or are they doing it while they're in a position hoping to improve within that existing company? DAGNA: So all three paths that you mentioned are very valid. It depends on what people are doing, what their goals are. When I work with my clients, we work one on one. So it's very tailored to their specific and unique situation and their needs. But I can tell you that from last year, my absolute best example was one client who came to me because he felt that he was being an undervalued senior engineer. And he wanted to promote himself and maybe move on from the job that he was in at the time that he didn't see much opportunity for growth. And he was just stagnant. "Help me market myself. I need to get out of this current situation. I know I have the potential. And I want to find something more exciting to work on." As we worked together, within three and a half months, he became a startup CTO, which was a dream come true for him. But he didn't believe at the time before we worked together that he could actually make that happen for himself. Then I had another client who, within two months of us working together, was preparing to land a team lead position. But he actually was able to jump two levels up, and he became a VP of innovation at his own company. CHAD: Cool. DAGNA: It so happened that as we worked together, his company was going through a massive spurt of growth. And because he was the right person working on the right skills at the right time, he became the VP which is incredible. And I had another client just recently who felt that he was overworking himself. He was coming also from a military background. So he had certain beliefs that they served him in the military, but they were not really helpful for progressing in the tech industry. And as we worked together, he was able to not only stop overworking himself and have a better relationship with his wife; he also landed a new job where he doubled his salary. He went from 109,000 a year to 220,000. That actually made even my jaw drop a little. [laughter] But it shows you how powerful the process is that I follow with my clients. It's really about the engineering mindset. It's about how to think about career growth and how to prioritize certain things depending on which stage of your career you're in. CHAD: Are there other common pitfalls or mistakes that developers make that hold them back? DAGNA: So absolutely the limiting belief that I mentioned earlier, believing that your work speaks for itself. I feel like 80% of people that I work with have that limiting belief, and we work to get past that. Another thing that is pretty common is not understanding how you come across. That's a problem that I had in my career. When I mentioned that I was a senior engineer for a few years and I felt stuck, I wanted to advance, but it wasn't happening for me. It wasn't clear why it wasn't happening until I started working with someone who was open enough to provide me some tough love type of feedback. One time he told me, "Dagna, why are you calling these people idiots?" And I'm like, "I never said that." CHAD: [chuckles] DAGNA: My intention was really pure, good, coming from my heart and my soul, from really good intentions. But my intentions were completely different from the message that got across, right? CHAD: Was it your tone, what you were saying? What was it that made that come across? DAGNA: Part of it is not being assertive enough. And I should probably mention here that I am an immigrant to the United States. I originally grew up and got educated back in Poland, my home country. And the way we communicate in Poland is completely different than how we communicate here in the United States. And at the very beginning, I didn't really understand how my communication impacts my career. So essentially, as a senior engineer, I was way too direct. And I was using words that were triggering for some people. So I had to learn how to be more assertive, how to communicate to people that I get where they're coming from, what is their perspective, what it is that they're trying to accomplish in the conversation. Once I started doing that, I actually got the offer to get promoted to the engineering manager that I was working towards. But the funny thing is that was the day that I actually came into the office and put my notice in because I was so sad of being a coach by then. I was like; I figured this communication thing out. I need to spread the word. CHAD: [laughs] DAGNA: It's way too important for me to now be a manager, nah, nah, nah. I have more lives to impact here than just the team that I might be working with. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: That's great. And it segues really nicely into the next question I was going to ask you, which is your experience with the cultural differences. There's a general trend in the market that we're seeing now in more companies hiring remotely, opening up the candidate pool to people who live all over the place. And not only does that expose more people to be hired by different companies, but it broadens the candidate pool. So you're competing against even more people. So is that something that you're seeing as well? And how do people position themselves within the global market now, particularly if they're not in the U.S.? DAGNA: Well, if we're talking about global market, we got to be mindful that for a company that's located in the United States or any other country for that matter, there are tax implications. So it really depends on the company and how they are set up to be able to pay out salaries offshore or hire contractors offshore. Because the reality is that a lot of clients of mine that are from the European Union, for example, a lot of clients of mine that are in the EU, if they wanted to apply for companies in the United States, they wouldn't really be considered because of those tax implications. So even though a lot of companies open up and want to hire people from abroad, not every company does that. And even if companies say that they are open for remote workers, it really depends on how they're paying their taxes and how all that is set up. So the way I see it is there is a movement towards opening up for remote work. But it's definitely not about competing across the globe, not yet at least. CHAD: I think maybe my perspective is a little bit skewed on it just because of where we're at. So are you saying that developers should do their due diligence about what companies they actually want to work for? DAGNA: Absolutely, yeah. I mean, applying for a company that is not set up in a way that can support paying salaries outside or even having those international agreements in place, you're just wasting your time applying there and setting yourself up for frustration because they're not going to reach back to you. CHAD: Yeah, that's good advice. DAGNA: Now, in terms of your work with remote positions, who do you usually work with, Chad? CHAD: Are you asking from developers that we typically work with or who do we -- DAGNA: Yes. I was curious, like, what's the amount of people that you work with that are actually remote and worldwide? What is your experience there? CHAD: So last year at thoughtbot, we got rid of all of our offices, and we went fully remote. And when we did that, it took us a little while to get everything organized. But when we did, our goal was to open it up based on time zone, not based on country that you live in. And so we organized into two teams, all of the Americas and Europe, Middle East and Africa is the second team. DAGNA: So I'm curious, what are the tax implications of you guys paying out those salaries? CHAD: So we use a company called remote.com along with a few other partners that provide employer record in the country that you live in. So there's an actual entity. You're fully paid according to local rules with actual salary benefits, paid time off, all that stuff. And you are a real employee of that entity in that country. And then what they do is they invoice us for that total amount. DAGNA: Ah, that's awesome. CHAD: And they handle all the local employment, which is great because up until that point, we previously had to have entities of our own in every country in order to do it right because we really want to do it right. We're not that big, and so it's a lot of overhead for us to be able to do that. So working with partner companies, companies that provide that local entity is the direction we've gone in, and it's worked really well overall. DAGNA: Awesome. Glad to hear that. CHAD: And I think in general, I'm trying to spread the word about that because I do think it is important. There are a lot of companies out there. This is building on what you said before. There are a lot of companies out there that are, on one hand, doing things incorrectly or, on the other, they might not have good intentions; they're sort of purposely taking advantage by having people work as contractors when they probably really shouldn't be. DAGNA: Oh yeah, I hear you. CHAD: I'm curious, in your role now, do you still code at all? DAGNA: So I gave up coding for now. I essentially left my last engineering job in March of last year, and I've been fully focused on coaching. Coaching as it is is a skill as well. And I realized that if I really want to make an impact, I have to have my attention fully devoted to that business. And part of it too is business growth. A skill that I'm learning right now is writing, writing a newsletter, writing posts on social media, and just sharing what I think is very important and what is not really being talked about enough like the communication, like the human side of software, like career growth, and the fact that we are set up to overvalue the technical skillset in terms of career growth. And all this really takes up my time and my effort. CHAD: One of the things that resonated with me when I looked at your website was this idea of being clear on your personal definition of fulfillment. Fulfillment is one of the things we talk a lot about at thoughtbot. It's one of our core values. And so, how has it been for you to transition away from coding? And do you think you're going to be fulfilled by that over the long term? DAGNA: Oh, absolutely, yeah. It's been a blast. Here's the thing, as I help my clients achieve spectacular results, that's what really puts me on fire. And I wake up every day thinking, damn, I can help people in very critical moments in their life. I had a client who, as we were coaching together, unfortunately, his father passed away. And he told me that thanks to the coaching that we did together and the mindset training that we did, he was able to cope with this difficult situation in his life so much better, not to mention how that impacted his career. So I get to really help, really have a huge impact on people's lives, and that's something that really is incredible for me. That is my personal definition of fulfillment. And I like to say that I used to be programming, and now I'm re-programming human minds. CHAD: So this idea of personal definition of fulfillment, first, why is it important to be clear on that? DAGNA: It affects your energy levels, your motivation. If you're working in a place that might be giving you an incredible benefits package, but every day you wake up, and you just don't want to go to work, that is something that I like to call golden handcuffs because you're essentially in hell, in prison. And it feels horrible to be in a situation like that. And I have experienced it myself where I felt like I have so much potential within me. Why am I wasting my time here? Even though the money was great, the benefits were good, but I knew I had so much more within me. And figuring out the personal definition of fulfillment is really what helped me open my eyes that; hey, my job was great, but it wasn't something that I really wanted to do. It's kind of like being in a relationship that just doesn't work, but you're in it just because. [laughs] Isn't it so much better to work in a place that is meaningful to you, that supports your values, that fits your desired lifestyle, someplace that every day that you wake up, you're really excited about going to work? Isn't that a much better way to live? CHAD: Yeah. What if someone finds themselves understanding that these are the skills that they should have to be a really great developer and advance in their career and maybe even making progress on that? Are there other things...you used the term earlier about marketing yourself. Does that mean having a great personal website? What does it mean when you say that? DAGNA: Well, I really mean being able to talk about your accomplishments, depending on which stakeholders you're talking to. So if you're trying to pitch an idea to your product manager, then talking at the product manager level, being able to show how what you do or the idea that you have contributes to the business. If you're in an interview setting, how to discuss what you have accomplished with the people that might want to potentially hire you. It also is related to having your LinkedIn in a way that attracts attention and brings people in that you actually wanted to work with. I've had some people come to me and say, "You know what? I get seven; eight offers every single day on LinkedIn." And I'm like, that's great. But are these the offers that you actually want to work on? Is it something that you actually want to pursue, or you just want to keep getting those notifications?" And oftentimes, whenever we have our LinkedIn profiles set up, what happens is we put the keywords there. I know this tech stack; I know this framework. I've worked with this language, blah, blah, blah. And what's missing is who you are as a person, what you value. What do you expect from a workplace? What kind of change do you want to make in the world? What is really important to you? What are your expectations? And I think that the pandemic, in a way, showed that, that as we got to work from home, we got to re-evaluate what is really important in our lives. Back when you used to go to the office, you would have that disconnect between the work and the life. And you could strive for some work-life balance but keep them kind of separate. Now, with everything being super entangled, it kind of forces you to reevaluate okay, what is really important for me? Is it important for me to eat breakfast with my kids and drop them off at school, and pushing that meeting to a little bit later during the day? Or is it important to me to clock out after 6:00 so I can be with my kids after they get back from school? Or do I really care about maybe doing all my work after 6:00 p.m. because that's when my brain lights on fire? Have you found yourself going back to re-thinking what is important in life after the remote work started? CHAD: [laughs] Well, yes, and no. Yes, but I also have made a habit of doing that. DAGNA: Oh, perfect. CHAD: As a result, I often dramatically either change my schedule or my focus or something about every two years. And that has been critical to me to be able to do this for so long. I haven't really worked...I've been doing this for more than 18 years now, but I haven't really worked in the same job more than two or three years. Even though it might be the same title, the job has dramatically changed. And that's through my own personal initiative of realizing what I need to do to be fulfilled now. And I'm fortunately in a position where I can make those changes happen. DAGNA: That's great. But I kind of want to share that I believe everybody's in a position to actually do that. CHAD: Yeah, I agree. DAGNA: Especially in engineering. There are so many opportunities for growth. It's kind of ridiculous. You can be an embedded engineer and become a front-end engineer. You can go into the backend, and then you can do DevOps, and then you can become an engineering manager. And then you can go back to being an individual contributor if you wanted to. I mean, you could just move up, down, left, right, check things out, see what's fun, what's not, change industries. So there's just so much opportunity for growth. And I think it's also very human wanting to grow, wanting to learn more, trying to kind of push the boundaries and check what's out there outside of your comfort zone. I think that's very human. CHAD: Yeah. Well, if people want to get in touch with you or find out more, where are the best places for them to do that? DAGNA: The absolute best place is going to my website, theMindfulDev.com/podcast. And that link will actually redirect you to a case study of a client of mine that explains how I work with clients. So if you're interested for us to get to work together, you can just go there and watch the case study video, and let's go from there. CHAD: Awesome. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guest: Dagna Bieda.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots

Chad talks to Benjie De Groot, co-founder, and CEO of Shipyard. Shipyard manages, creates, builds, and deploys ephemeral environments. Benjie talks about how Shipyard became a funded company, discovering who their ideal customers are, and building out the core team so Shipyard can accelerate and figure out their next steps in how to bring it to the masses. Ephemeral Environments Shipyard Follow Benjie on LinkedIn. Follow Shipyard on Twitter, LinkedIn, or GitHub. 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 Benjie De Groot, co-founder, and CEO of Shipyard. Benjie, thanks for joining me. BENJIE: Thanks for having me. CHAD: Why don't we start by if you don't mind sharing a little bit about what Shipyard is and does? BENJIE: Sure. At the core of what Shipyard is working on is ephemeral environments; not everybody knows what that means. That is changing a bit. But essentially, what we're focused on is on every pull request or commit for a feature; Shipyard manages, and creates, and builds, and deploys ephemeral environments. So that's a disposable one-off on-demand environment that any stakeholder in your internal company can use. And we focus on the tooling around that, on build pipeline, and then security around that. And then all kinds of other cool features that are necessary that pop up. CHAD: Cool. So as a developer, I'm familiar with the concept of developing locally, putting up my pull requests. And also, we deploy a lot of stuff to Heroku. So I'm familiar with some of the infrastructure that Heroku might give. How did you arrive at saying like, this is a thing that I want to work on and believe should exist? BENJIE: That's a great question. I actually am also a developer; that’s my background. And throughout the course of my career, I've always been on the technical side of the company. And what that's translated to, because of passion, to be honest, is always taking on a DevOps type role, so throughout the course of my career, a lot of responsibility. I mean, I started off writing Bash scripts, went to Puppet, did Chef for a while, did Ansible. Somehow I went back to Bash scripts for a lot of this stuff. Then this company called DoCloud popped up, which obviously became Docker, and I kind of got obsessed with that. And then I had a bunch of friends at Google, and they were telling me about this creepy thing called Borg, and that became Kubernetes. And so, my career has kind of happened throughout that entire process. And throughout, DevOps has kind of been my passion. Along with my co-founder, Peter, I was a high-priced Kubernetes consultant in the New York ecosystem just a few years ago. And a lot of companies were trying to make the transition to Kubernetes. And Peter and myself came in and helped people that were struggling to find DevOps resources. And what that always kind of looked like was there was some bespoke version of a deployment system that was perfect for the person that wrote it. But obviously, it wasn't good enough for me and Peter, for Peter and myself. CHAD: [laughs] BENJIE: And so we would rewrite it, and it would be great. But then, eventually, we'd move on, and someone else would rewrite it. And there were a few instances where we ended up going back to companies and just reimplementing what we had already done. And throughout that process of being this consultant, we kept running into this ephemeral environment thing and building the same tooling over and over and over again. So Peter and I, on a weekend, kind of got, "Oh, let's make a tool for ourselves." So we did that. And we made this exoskeleton to help our consulting business. And as things progressed, we kept just adding features, and it was really fun, and it was great. And then some of our customers or clients saw that. And they were like, "Hey, can we click that button?" And we were like, "I guess." And so slowly, it turned into a product that was very duct tape-y and glued together, but it worked great. And to be frank, I had been through the VC process on the technical side in the past and didn't want to go through that again, the hamster wheel of need to raise more and more money and so very, very averse. And was very set on a really nice lifestyle consulting business, and hell was going to have to freeze over for us to take any VC dollars. And then I don't know if you heard, but in March of 2020, hell froze over, and [laughter] there was a little pandemic. And at the same time, we got some pre-emptive term sheets, yadda, yadda, yadda. Next thing you know, we're a funded company building out a really cool product. So that's the origin story of where Shipyard came from. CHAD: Really cool. I definitely want to come back to what building the product for you has been like, and the funding, and where you go from here. But let's come back to the product itself. As a developer, my normal workflow is I'm working locally. I'm able to run the application that I'm working on locally here on my computer. I put up a pull request on GitHub. I ask my team to review it. Once it gets reviewed from a code perspective or a design perspective and gets a thumbs up, I merge it back into the main branch. And I deploy it to a staging server, at which point I would ask my stakeholder, my client, whatever, "Hey, this thing you're expecting it's on the staging server for you to check out." And everyone else on the team is doing the same thing. So where does Shipyard come in, and why is it better than that? BENJIE: So where Shipyard comes in, it's after the local development but before you get to staging or really before you get to production because, in practicality, a lot of people turn Shipyard into their staging servers. But what happens is through webhooks, we hook into your GitHub. And we see that there's a new commit that comes in. And we automatically build and deploy a fully ephemeral environment for that feature. And what that gets you is a few things. One paradigm that we're seeing a lot of is when you make that PR, a lot of end-to-end test suites are being run automatically using Shipyard ephemeral environments. And what that gives you is, in some instances, before you even have a code review, you're passing the suite of tests. And what that gives you is you save a lot of time. If there's just a dumb migration error or some typo or something like that, you're not wasting human capital or human energy on those environments. And the other instance there that gets really interesting is by bringing up these environments earlier on, product stakeholders and QA stakeholders can do their jobs earlier on in the process. And so you can avoid a lot of merge conflicts. So like, you merge something, and maybe there's an edge case that you hadn't tested for, and the code review didn't pick up. Well, all of a sudden, staging is broken. And some other team member that's using the same process you were now they're blocked. Or the client can't see that environment, and there's some other type of problem. But really, we didn't invent this paradigm. This is what FAANG does. There's a reason why I can't remember the last time that Gmail itself a button broke, or there was bad CSS, or bad HTML, same thing with Facebook, same thing with Netflix. Obviously, we all know about –- CHAD: There's the obvious DNS outages. BENJIE: [laughs] Right. I was going to say we all know about AWS, especially in December of 2021. That was a tough month. But yeah, from a UI/UX and controllable release perspective, this greatly increases your internal stakeholders’ ability to get their hands on features earlier, find problems, and then get those back to developers. And the other thing, and maybe this is a question for you. But have you ever been in a situation where you built something, and it doesn't actually get reviewed for a few weeks? And then there is a bug, and you have to go back, and context switch off of what you're working on and go back and put a whole other mental model in place to go back and remember why did I use a switch statement here? That's a bad example but something to that effect. CHAD: [laughs] Yeah. Well, I really try to avoid that scenario by having tight feedback loops, but sometimes it's unavoidable. It might be you finish something right before a holiday or going away or something like that; that can happen. So it's happened to me before, yeah. BENJIE: Right. And how do you get your product people or your UAT teams...when do they get to touch the feature that you're working on? CHAD: It's usually not until after a code review when it's been merged into main and deployed to staging. BENJIE: So that's kind of how we make that feedback loop tighter. And what we've seen in practice actually is a lot faster, more reliable releases. And there's a significant increase in the cadence of releases that can happen and a higher quality of those releases. CHAD: You mentioned that some customers end up even getting rid of staging. And so that's really exciting and interesting to me. When they do that, what does the overall picture look like? Is the code merge manual? Or do you have customers that are doing continuous deployment off of a thumbs up from the person reviewing it in the ephemeral environment and getting that automatically merged, and then maybe canary deploy or something to production? BENJIE: Yeah, that's a great question. The thing to keep in mind here is that the majority of our customers are larger, and they have bigger teams because obviously, this is a collaboration platform ultimately. And so there's more value for the more complex teams and more stakeholders. So we don't have anybody at this moment that I know of; there could be, doing LGTM is good enough. So there's always a manual component. But what it looks like from a staging perspective is that your main branch is actually ostensibly your staging environment, and so all the ephemeral environments are sort of dev environments that are shareable. And then when you merge because a code review passes, and QA checks, and UAT, then it gets automatically built into the main branch and the main environment. And then some people do QA. They'll final pass a QA or a final end-to-end test there. And then there's also a manual promotion to production as well. That's the typical pattern we've seen. CHAD: Cool. One of the things that when I've used...sometimes a problem even with staging. But when I've used or been on projects with some ephemeral environments, getting good data in those environments can sometimes be a challenge. Is that something that Shipyard helps with? Or what's your recommended approach to that problem? BENJIE: So that was one of the biggest problems we had early on. We put a lot of work into that. We apply the same git branch model to data. So the way that we do that is basically if you...oh, by the way, I forgot to mention something. We use Docker Compose as our application definition. So we extrapolate from Docker Compose and transpile into best practice Kubernetes YAMLs. So there is a little bit of inferring and magic we do in certain places. And one of the places we do that is if you have a named volume...sorry, am I getting too technical, or is this --? CHAD: Not for me. And in fact, I have follow-up questions about [laughs] why you have that approach of converting. BENJIE: We will dive into that in a second. And I have a whole bunch of redhead friends that make fun of me about Compose all the time, but I stick to my guns on that one. But I'm happy to talk about that. At high level, if you indicate to Shipyard this is a persistent volume that we want to make sure that child environments get, then we will do an instant snapshot. And we will actually provide that to the generated child ephemeral environment. And ostensibly, what that does is it allows you to test data migrations as well on these ephemeral environments. Now, to go back to your initial question, we encourage...and we're working on some partnerships actually with some interesting companies. But we encourage people to specifically have their main data set on main be ostensibly a copy of whatever the good data set is. But obviously, you're responsible for pulling out your own PII and all the confidential stuff there. But the key thing here is you're maintaining one environment with the right data on it. And then all of the subsequent generated ephemeral environments inherit that and can then change that. CHAD: Yeah, that's cool. That solves a real pain point that I've had in the past when trying to work this way. BENJIE: One company that I think is really interesting around this space is Tonic.ai. And we're actually working on some stuff with them, I think. But we share an investor, so that's why I know them, for disclaimer purposes. But they're great. And they have some really cool tooling around mapping your database to PII and automatic detection of certain types of information that you don't want pushed into your staging servers and to your developers' hands. So that's one to check out, too, if you're looking for data help. CHAD: Cool. So do you want to get back to this Docker question? Why that approach of converting the Docker Compose into YAML for Kubernetes? BENJIE: So this is quite a controversial topic. CHAD: [laughs] BENJIE: But I will tell you where it came from. Hearkening back to our origin story, what we saw was we saw a pattern of a lot of companies going a little bit too all-in in Kubernetes; let’s just put it that way, where every single one of the developers is running minikube or even K3s or K3d or whatever. And all of a sudden, the DevOps people and the SRE people in the organization are spending most of their time supporting developers in local development environments. So early on in that consulting game, we realized we don't want to do that. So if you want to work with us, we think you can use Docker Compose for most things. Now, that's obviously not always the case. There are some companies and applications that have hundreds of microservices. So obviously, Docker Compose is not a very realistic fit for those people. But the majority of people can pretty much encapsulate their application in Docker Compose. So that's one thing. The other thing is I mentioned to you that I'm a DevOps engineer for years. I'm sick of new YAML formats or specifications. So I have a saying, "Not another YAML, I say nay." My co-founder, Peter, hates when I say that, but whatever, I like it. CHAD: [laughs] BENJIE: So that's another piece of this. And then the biggest thing here is that we look at Docker Compose as rabbit ears on a television set. So you know, like a 98-year-old grandmother can somehow stand on one foot and hold the antenna the right way, and it's static. The picture is perfect, and they can watch...I don't know why I'm saying Jay Leno. I don't think it's on the air anymore. CHAD: [laughs] BENJIE: Sticking with the grandma reference, humans are really good at figuring out stuff like that. [laughs] And that's kind of what Docker compose is. It's kind of like if you can make it work locally, Shipyard is going to take care of the rest and clean up a bunch of stuff for you. So that's how we look at it. Admittedly, we do have some Helm stuff we're working on and some Kustomize (with a K) stuff. And there are a whole lot of other interesting things out there. But frankly, we haven't run into problems with our current approach. And when we have tried to ingest raw manifests and stuff like that, other issues tend to arise. So we use Compose as a funnel to be very opinionated about our Kubernetes deployments. CHAD: Well, I'm a big believer in, especially in early days having opinions about things. And it sounds like, with this particular opinion, you not only can help people at different stages and say that "This is good enough," but you're also casting a wide net for what people can do. You're not cutting people off because they already use Kustomize or something like that. BENJIE: Yeah. And a lot of it is about accessibility. And so it's proven to be a pretty interesting thing. We didn't think that we were going to go this far with it. [laughs] We really thought that we were going to get in trouble soon. But it's pretty cool how it's going. And also, I will do a shout-out to the Docker Compose community. They're picking up some steam here. I think a lot of people are realizing that it's a pretty good spec for most use cases. So I know that Docker released somewhat recently you don't have to do Docker-Compose anymore. It's just Docker Compose. And there are all kinds of Compose specifications stuff that I think is worth checking out. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So to get a little bit meta for a minute, how do you use Shipyard on Shipyard? BENJIE: The ultimate dog food. That is one of the biggest selling points to our own engineering team when recruiting. We've got a pretty spectacular team that comes from some pretty awesome companies. And people sometimes ask me, "Hey, how did you get these engineers?" And honestly, I think the answer is dogfooding. Because what we're building is what every DevOps engineer sets out to build every time they start their job, in my opinion. You always want this ephemeral type of elastic environments are only on when you need them to be on. I didn't discuss this, but we also have functionality that we call SLV or Since Last Visit. So we know the last time someone went to one of these environments, and we'll turn it off for you. And then, obviously, it's very quick to turn it back on when needed. So there are cost savings. There are all kinds of stuff there. But ultimately, we're building the ultimate DevOps tool. And so we use Shipyard to run Shipyard. We use it in our QA process. We use it in our end-to-end testing process. And we also use it in our production process as well. We have some of our...we do have a production offering, and we use that ourselves for our stuff. So it's a very recursive conversation around that. And sometimes, when I'm actually doing a demo for various people, the only way to show or the only good demo I have of certain functionality is to actually show the Shipyard organization itself in Shipyard. And I get very recursively tied up, and people get confused. And it's always a bad idea. CHAD: [laughs] Yeah, you have to queue the Inception music. BENJIE: Yeah, exactly. We're at the third level. We're at the ice palace or whatever, ice hideout at this point. That's from the movie Inception for those that don't know what we're talking about. CHAD: [laughs] Yeah, that's really cool. I imagine that...sometimes when I'm working on a project, and you get down to the instrumentation level, to those levels, it can be difficult to run the system on the system. Have there been particular challenges? It's not just a normal web app; I guess is the way of saying that. What Shipyard is isn't just a normal web app. BENJIE: Yeah, one of the things that we do is that we have a pretty robust security posture, so every single one of our customers gets their own cluster. And so our security model is using the hypervisor basically, which, by the way, for anyone looking at Kubernetes, forget Shipyard for a second. Please understand that if you're in a shared namespace anything, our back is great, but don't do it. There's a CVE around on the corner, I promise you. Don't do it. Anyway. CHAD: [laughs] That's a good PSA for people. BENJIE: Yeah, right? [laughs] Yeah. So some of the cool challenges we've had is we early on, we definitely had some stuff where if we did a bad release, we would break our own ability to fix our own releases. So that was that way early on. We figured that one out very early. I think that was even before we were a product even. That was just a few sleepless nights of Peter and myself being like, oh God; we got to fix this so that we don't screw up this client's website. So that's been interesting. I mean, that was really it. And my co-founder, Peter, is listening to this, and he's like, there are 4,000 different things I've fixed over the last few years that were a problem around this, and I can't bring them up. But there's a lot, and I don't know what they are. And Peter is very good at fixing them. So that speaks to my co-founder and the rest of the team. CHAD: So you mentioned that March of 2020 happened, hell froze over. And you found yourself thinking you're going to take a different path and fundraise and become a funded company. How difficult did you find fundraising in that environment, or was it easy? BENJIE: It was real tough at the beginning there. For one, I have no idea what I'm doing. [laughter] That's just the truth. Maybe I should say that in the past tense. I had no idea what I was doing. I still feel like I have no idea what I'm doing. But like I said, I come from a technical side, and I'm a bit of an engineer. So if a VC asked me a question and the answer is yes, but I have to qualify it with some weird edge case that I came up with. That's not a great look for these types of pitch meetings. So I would suggest people not overengineer answers to questions, yes or no works very often. So it was challenging. But also, at the time, I'll say that there was definitely some predatory term sheets going around because this was really early, and we had no idea. And I was a fool...I wasn't a fool, but I had no idea. We're running this consulting company, and I'm like, oh my God, all my customers are funded. They're all going to go away. We had some pretty large customers. It was very irrational looking back. But it was a crazy time. Also, I should mention that we're in New York. So things were heightened a lot more also in March of 2020. It was very intense, and so I had to learn a lot. And basically, the realization like, oh, if the world becomes remote, software is just going to go crazy had not seeped into my brain quite yet in March or April. So did a lot of learning that way. We were very fortunate to have some really helpful people along that path and eventually figured it out. I will say, funny story, I literally didn't have a pitch for three months. I would just do a demo and talk about stuff. And then a friend of mine was like, "Oh, what's your pitch?" And I was like, "I do a demo, and I talk about it." So he's like, "Dude, you got to have a pitch." So that helped a lot once I figured out [laughs] that I needed a pitch. CHAD: It did help. So you recommend people have a pitch. BENJIE: I would say that that is a positive, yes. Having a pitch is helpful. I know that that's a ridiculous statement here, but I literally didn't have...I just didn't think about what's my pitch? CHAD: Well, I think it's simultaneously a ridiculous thing but also there exist in the world things that people do just because that's the way that they're done. And so it's valid, I think to say, "Do we really need that? Can we get by without it?" And if the lesson learned there is actually there's a reason why people do it and it is valuable, that's a valuable lesson. It's too bad you had to go through it to discover it. BENJIE: Well, yeah. I look back fondly at that. And I wouldn't say I was being contrarian. I was just kind of being a jackass, frankly. But I learned a lot. And honestly, in the end, I couldn't be happier. I'm pretty anti-VC. Everyone knows that about me. I like to make fun of them and all these things. But I couldn't be happier with our investors, and they've been unbelievably supportive. And so that's been a super positive. The one thing I would say to anyone listening to this podcast that has to go out and raise money is you got to get really good at letting things roll off your shoulder. As an engineer, it's really hard for me to deal with any level of rejection because I'm like, oh, it works, or it doesn't work. Oh, you found this edge case that I didn't think about? Oh, you got me, but I'll fix it now, and now it's fine. That's not the way that fundraising works. You have certain conversations, and you feel super positive. And then, all of a sudden, you don't hear back from this person for weeks at a time. You have other conversations where you think that it was the worst thing that you've ever done. And the next day, you get a term sheet. I had one pitch...this is when I knew how to do a pitch. This was a few months in. I had this one pitch, and it was all virtual, and it was very early days in our remote world. And there were four partners on this call and a few associates or whatever. And I do the pitch, but everyone is muted on Zoom for 45 minutes. Now, it's pretty clear from our conversation that I talk a lot. So it's not the end of the world. But I had no idea what was going on. And I just thought that I had bombed it. It was horrible, all these things. And the next day, I got an email, and it was three introductions to amazing opportunities. And two of them actually panned out. We didn't end up going with that fund. But I just thought it was hilarious that I was convinced that I shouldn't be doing this, and it was the opposite. So you never know. That's the other thing I learned is you literally can never know what's going to come of any particular meeting in the VC fundraising world. CHAD: So how long did it take you from the point that you decided you were going to do this and you were going to start trying to fundraise to actually getting the investment in the bank? BENJIE: Probably four to six months. We obviously had some opportunities, but as we went through this process, realizing that having the right partner for the next 7 to 10 years was really important. And we ended up with our lead. I can't believe I'm talking positively about a VC on a podcast but whatever. CHAD: [laughs] BENJIE: Our lead, Owen Davis from Contour Venture...Contour is like this New York fund that they do everything, but no one knows their name. Oh, he's going to love that I said that but whatever. CHAD: [laughs] BENJIE: They're great. He's great. And he's the dream investor for us to lead. And then we have other...and I'll mention Shruti over at Array and the folks at Heavybit and Work-Bench as well. They're all in this round, and it all came together. And I was a little picky. So we kind of took our time. And I suggest that if you have that luxury, which we did because we already had a successful consulting business, make sure you know who you're getting into business with for sure. And we got very lucky with that. CHAD: So how much time while you were fundraising did you personally work on that as opposed to other things for the product or the business? BENJIE: I should have probably put a little bit more time to the fundraising. To be honest with you, I would say I probably put 50% to 60% of my energy into the fundraise, and then the 40% was all building product. As an engineer, you have a really frustrating call, or you think you're doing well, and then you're not, or vice versa. So for me, I would retreat into building. And so I probably retreated into building a little more than I should have to be frank, [laughs] but it worked out in the end. CHAD: While you were doing that, you supported yourselves from the consulting revenue. BENJIE: Yeah, for the most part. We still had active clients. So we converted most of those...actually all of those into Shipyard customers. And they were very supportive in that process, by the way, doing due diligence calls for us. They were all very helpful. CHAD: And how did you decide how much money you should be seeking to raise? BENJIE: Ultimately, that was something I struggle with just because I really want to know what I'm going to do and what the plan is. And one of the lessons that I've learned as a CEO now is your job is basically to make unbelievably important, critical decisions with little to no data and just hope you're making the right one and then adjust quickly if you're not. So understanding when you've made the wrong decision. But ultimately, to answer your question, I built out a spreadsheet. I had a wish list of engineers that I knew or positions that we needed to fill, probably underestimated some of the product marketing needs that we would need to do. But built out a model and then figured, hey, how can we get there in 18 to 24 months to get to the next round? Because you really do have to be making sure that you can...I mentioned the hamster wheel early on; maybe that's too negative of an analogy there. But you have to be thinking about your next round. And so you have to get to what metrics you want to hit. And you just work backwards from there. CHAD: At what point along the way...you mentioned earlier that your customers tend to be larger companies. At what point along the way did you discover who your ideal customers were? BENJIE: I think we're still discovering that. We're still figuring that out. But for me, this tool Shipyard, and I've seen it, if you start using a tool like Shipyard from day one, the gains and the benefits are just insane. We had one company that started off from scratch with us. And within two months, they had extremely robust software development lifecycle, production deploys, all kinds of stuff. And they've been going now for years...not years but a year a half or so with us and super successful. So I always wanted to be like, oh, startup X with two engineers you should use us. And the more we talk to them, the more conversations we had. We're just like, this is not a DevOps priority. DevOps is not the priority. CHAD: Especially in those early days, I feel like there's such a tendency, especially from engineers, to say, "Oh, that's not that complicated. I can do that," or "We don't really need that. Let's piece together this." BENJIE: Yeah, that's exactly right. So then, as we started to talk more and more and understand what people were doing, we just fell into this ICP or Initial Customer Profile of more complex teams that are really facing these problems. I mean, specifically, when you get to a certain size, a bad release costs you a lot of money, customer success, customers that are leaving you, frustrated sales execs, frustrated product people, frustrated QA people. So it's when you get to these more complex levels is when you need this type of tooling. Now, one thing Shipyard released actually very, very quietly, but you know, it's released. We released a 30-day free trial. It's kind of like our light tier, so people can start doing it. And we're starting to see some people at the earlier stage companies starting to do this, which is exciting to us. But our goal as a company is absolutely to figure out how to get this to the masses because ephemeral environments is the paradigm of the future. I mean, it's the paradigm of the present with the big tech companies. And it's now coming down to the rest of us. And so instead of having to hire five DevOps people to build the system out for you for six months, you hire one DevOps person, and that DevOps person shifts into an SRE role, not entirely, but their concerns are more about reliability of the actual site rather than reliability for developer environments or QA environments or staging environments. So we think that's really powerful. One thing that I probably should have mentioned way sooner is we have a community site that we've donated, and we're more than happy to have some pull requests come in. We've had a few. ephemeralenvironments.io, yeah, I don't know how to spell ephemeral either, but you can Google it. It will come up. CHAD: [laughs] BENJIE: ephemeralenvironments.io, and it goes through the different use cases of ephemeral environments and where there's value there. So that's kind of the goal with all this. CHAD: So what are you working on now? And what is the next stage for the company, I guess also from a product perspective? But also, you mentioned that hamster wheel. [laughter] You're coming up on 18 months of being on that wheel, right? BENJIE: We are. One thing is we've had some success, so our revenue is pretty solid, but no rest for the weary. But we're probably going to go out and bring in some more capital pretty soon. And the reason for that, because that's always the important thing to me, is that we have some pretty spectacular design partners, some pretty big logos, all these things. The product is there. The product is killing it. I couldn't be more proud of the product and the team. We've also started to build out the core team and couldn't be more proud of that. And so now we need to accelerate and figure out our next steps and how to bring this to the masses. And ultimately, the vision of Shipyard is to make all this stuff move a lot faster, bring velocity to teams, and all that stuff. And we believe that ephemeral environments are a huge component of that. So we're probably in the next few months going to probably go out and look at our financing options. I will say that the market has been a little insane. So I feel like all the education that I got in 2022 is probably out the window because some of these valuations and other stuff seems like it's a frothy market, as they say, but we'll be doing that. And we're really going to probably double down on figuring out what the community needs and where the value is for the community, so both with ephemeralenvironments.io. But also, there are some really cool internal tools that we've built that solve some of the issues within the Kubernetes ecosystem. Okay, that's a strong word. They help a lot. I'm never going to say I've solved anything in Kubernetes. CHAD: [laughs] BENJIE: But they help a lot with understanding why the state of your application is maybe not where you want it to be. And so, we'd like to probably contribute a bit more back to CNCF, in particular, but open source in general. So continue to build the team to work on that. And then, obviously, pushing forward with product and some pretty cool stuff we have on the roadmap that we're really excited about. CHAD: Awesome. Well, I wish you all the best with that. If folks want to find out more about Shipyard, follow along with you, get in touch; where are the best places for them to do that? BENJIE: Really, shipyard.build is our website. And that is probably the best place to try it and also to contact us. Our Twitter is @shipyardbuild twitter.com/shipyardbuild. Personally, I'm not a fan of Twitter. So I personally don't use Twitter, but we do as a company. And I think that our Twitter and our website are probably the best things to reach out to, and obviously, sales@shipyard.build you can send an email there. But I think you'll probably find the information you're looking for on the website. And if not, please let us know what's missing. CHAD: And you mentioned the free trial. So I feel like that's a great thing for people who want to get more into the product; they can give it a try, right? BENJIE: Yeah. And one thing to note about the free trial the reason that it's kind of cool is it's your own cluster. You get your own cluster. It's completely single tenant. It's pretty dope. It's pretty cool. And you can really take it for a spin. I would suggest, I mean, we've had a lot of success with companies that are using Docker Compose already to just dive in there and get their application running. But I would say that we have some pretty cool starter apps as well. They're linked in our docs and our GitHub. Just seeing the power of this through our starter applications has also been a great experience for a lot of people. So I'd suggest taking a look at that. Oh, and I should plug a podcast that I'm a co-host of, Kubelist. I do that with Marc Campbell from Replicated, where we interview CNCF open-source projects all the time. That's why I got to be careful pretending like I'm solving anything. There are a lot of options in the Kubernetes landscape. CHAD: Wonderful. You can subscribe to the show and find notes and a full transcript of this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. ANNOUNCER: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guest: Benjie De Groot.Support Giant Robots Smashing Into Other Giant Robots

Chad talks to Tiffany Shubert, Senior Product Manager at Relias Healthcare. Relias is an online healthcare education company. They develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides in multiple healthcare settings. They span the entire range from acute care hospital settings to in-home care to hospice. Tiffany talks about how her clinical skills apply really well to product management, defining who you're solving the problem for, being all about your end-user, and making sure they have an amazing experience with your product. Relias Healthcare Follow Tiffany on LinkedIn. Follow Relias on Twitter or LinkedIn. 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 Tiffany Shubert, Senior Product Manager at Relias. Tiffany, thanks for joining me. TIFFANY: Hey. Thanks so much, Chad. I'm really excited to be here. CHAD: So, Tiffany, folks may not be familiar with what Relias is, although if you're in certain spaces, it's certainly a big name that you may have heard of. So why don't you start off by telling people a little bit about Relias? TIFFANY: Sure. So Relias is an online healthcare education company. Relias is in many, many different settings. But the majority of what we do is we develop and create education and clinical content for anything from physicians to nurses, physical therapists, to in-home care aides. And we are in multiple healthcare settings. So we span the entire range from acute care hospital settings to in-home care to hospice. CHAD: We do a lot of work with different clients in the healthcare space. And so many of them, without even me prompting, mention, "Oh, we use Relias." [chuckles] And it's remarkable to see. Is Relias the biggest provider of learning management software for the space? TIFFANY: So, we are the biggest provider of compliance training in the skilled nursing space. And we are a big provider in all of the other spaces. And really, where Relias started was in this notion of compliance training which, for those who are not familiar, really could benefit from a lot of design. That is the kind of training that every single healthcare provider has to take in order to see a patient. So that's where you take your patient privacy training, your bloodborne pathogen training, all of those types of trainings. And that's where Relias really started and has grown from there. CHAD: So, how long have you been at Relias? TIFFANY: So I started, interesting, in the end of March 2020. [chuckles] So yeah, it has been my pandemic experience, so almost two years now. CHAD: What brought you to Relias? TIFFANY: So I was at an interesting juncture in my career. I'm a physical therapist by training, and I was in clinical practice for about 15 years. And I transitioned over actually through a very interesting pathway but working for some different startups that were creating different technologies around healthcare. And one of the startups I had been with had run the course. And I was looking for something more around education, which is my original passion. And when Relias actually found me, I didn't realize it was actually in my backyard. CHAD: [laughs] TIFFANY: What drew me to it was this ability at this space where we could be looking at education, especially for clinicians, not as what I would call a penance which is how it's looked at. Like, ugh, I have to take my online education, or I have to take my training. But more of a hey, how can we make education interesting and dynamic? And how can we really apply many of the concepts we know about design and about really developing excellent products to clinical education? Which was incredibly exciting to me. CHAD: As you moved from someone practicing to product management in this space, did you do any formal learning or training in that, or did you just learn along the way? TIFFANY: A combination. Really my original experience in product was working for a startup company that was developing a really innovative concept around creating a soft, light exoskeleton, and they needed a clinician on staff to really understand how bodies move and what kind of problems could be solved. That position really evolved into being a director of user experience. And so that really entailed bringing our end users, who happened to be older adults, into the lab and having them really work side by side with the engineers who are creating the product. So I developed that whole program, validated it, expanded it. And from there, I really realized, oh, my clinical skills actually apply really well to product management. But now I do need to get some more formal training. So I went through some of the different...I actually went through the CSPO certification program, and then I have also just continued doing some more formal training at Relias. CHAD: I imagine that the industry itself experience being almost on the user side helps. But is it ever a hurdle that you need to overcome? TIFFANY: I think when clinicians first get into industry, they make a lot of mistakes because they want to solve every single problem. Or they want to give their users every single opportunity or every single feature. So, for example, if you sit down with a group of physical therapists, and if you say, "I'm going to build you an app for helping your patients with their home exercise program," every single physical therapist is going to give you a laundry list of 30 things that they want. And typically, where clinicians go in my role is they're like, "Okay, we're going to fix all 30 things." And really, it's that ability to narrow it down, narrow it down. And to be honest, if you're a good clinician, it's the same thing. Patients usually come with multiple complaints, and you've got to figure out what that number one complaint is and what you can do to address it. So that's where I think it becomes a barrier is wanting to fix every single problem as opposed to being able to really winnow it down. But when you can winnow it down, it's very powerful. CHAD: An extension of that that I've seen, which I think is one of the challenges in healthcare, is that there are a lot of edge cases. And in normal SaaS products like an e-commerce product or whatever, it's easier to say, "We're not going to solve that right now." But in healthcare, every edge case is an actual person that you could be helping. And so it's a little bit harder to really get in the mindset of not solving every problem. Because especially if the space of healthcare that you're in is literally life and death, it can be difficult from a product perspective to say, "We're not going to solve that case." TIFFANY: I completely agree. Those are just conversations that you have to have because you also have to look at if we spend all of this time solving all of these use cases or all of these edge cases, we're never going to have a product. So then you got to pull back, and you got to go, what is going to have the biggest impact? Or what are the components across every single patient that we can address? Because there's always going to be some commonalities, not necessarily disease space, but in how we actually address that patient and manage that disease or manage that impairment. It is a big trap that we fall into because you're right; healthcare provider training is you have to address everything. But the fact of the matter is that's not realistic. CHAD: What are some other challenges that you encounter while creating products in the healthcare space? TIFFANY: I think the biggest challenge is really defining who you're solving the problem for, and we run into this all the time. And this has become very clear to me lately that if you're working for a Facebook or a Google, you are all about your end-user. And it's all about making sure that that end-user has an amazing experience. But in healthcare, you've got patients, you've got clinicians, you've got hospitals, you've got healthcare systems. You've got private insurance payers, and you've got Medicare. And all of those groups may be interacting with your product. And all of those groups have totally different use cases and totally different problems to solve. So first of all, figuring out, like, who am I building this for? Who is going to pay for it? And where do those two things intersect? And that has been the biggest problem I have seen in innovation in this space over the last ten years has been, well, we're going to build this for the patient, and it's going to be amazing, and the insurance companies will just pay for it. That hasn't really panned out because nobody sat down and actually talked to the insurance companies and asked them what problems do they see happening that a product could solve? And then the flip has happened too where they've gone to the insurance companies, and insurance companies have said, "Well, here are the problems," but then they've never talked to the patients. So it's getting that multifaceted perspective and then boiling it down to what truly is the problem we're going to solve? CHAD: And the way I see it is that this problem is amped up in the healthcare space because there are so many stakeholders or people you're potentially building the product for. But it's a general problem too in enterprise software where basically the people making the buying decision are not the users necessarily or the people you're trying to help. And any time where that's the case, you also run the risk of very difficult to build a good product because the people making the buying decisions aren't actually the ones who are going to be using it or don't have the same needs as the people that you're trying to help with the software. TIFFANY: Exactly, exactly. So it takes a lot of time to sort all that out, and we rarely have that amount of time. I'd say one of the things that was so fascinating on the product that Relias and thoughtbot worked on was we had the time to go a little deeper and to really figure out...so the problem we were trying to solve is okay, we need a better tool. Physical therapists need a better tool to engage patients, specifically older adult patients. And again, so we had the conversation with the clinicians, and they're like, "Oh, well, we want all of these exercises." But then we paused, and we said, "But really, what is your biggest clinical challenge?" And they all said, "Time. We don't have enough time." So then we were able to pull back and not go, oh, this is not about making the best exercise program ever. This is about creating a product that actually solves the problem of time. If we can enhance efficiency, then clinicians will use it. They'll be happy with it, and we can take it from there. Solving the problem of time is a totally different problem than we have to create a product that offers you 30,000 different exercises. It was just a really important lesson because then once we said time, then all of a sudden, we had clinician buy-in. And then we also had an organization buy-in because the organization is going, "Absolutely. If you can save my clinicians 10 minutes, that's going to increase their productivity. That's going to give them more time with the patient. Or maybe we could even get so efficient that there are more opportunities to see more patients." So it's tricky to figure all that out. CHAD: So how did we figure that out? What tools did we use to have those conversations with people? TIFFANY: Yeah, there was a lot of really excellent discovery and meeting with a good variety of clinicians but all practicing in the same space. And that's one of the things I want to call out. When you look at healthcare, healthcare spans so many different settings. And there are not a lot of consistency or universal truths between settings. And what I mean is someone who is seeing a patient in a home health setting is going to have a very different skill set than someone who is working with a professional sports team, same training, same title, totally different set of problems. So we were really, really clear that we had to really refine this problem and get a very specific type of therapist. And we also wanted to get a specific...I'm going to just use home health just for an example. But okay, so let's make sure we get therapists who are working in rural settings, in-home health, and therapists who are working in urban settings in-home health because we wanted to make sure that we had a better understanding of the problems they were facing in these multiple settings. From there, from that discovery, got really, really, really very strict on what consistencies we were seeing around the problems that the therapists were running into. And from there, we just really focused on what was going to give us the most bang for our buck. And the problem of time was super consistent. The questions really were not like, well, would an app save you time? The questions were really what are your biggest challenges right now? CHAD: And did you do that in one on one interviews with them? TIFFANY: Yeah, those were one on one interviews. Yes. Yeah. CHAD: How do you, when you're doing it, collect the data from those interviews in a way that is conducive to analysis later on? TIFFANY: So I've used a whole variety of tools. And we were very analog in this particular one. We were interviewing one person, but there were about four of us on the call, and everyone was taking notes. And then everybody was highlighting common themes. And I've used focus group analysis software as well, which is always really, really helpful. But in this particular, we were really just going analog, and it worked pretty well. CHAD: And you were doing this without a prototype or anything like that yet, right? TIFFANY: Correct, for the initial without a prototype. Yep. CHAD: And so once you had that potential job to be done or value proposition, how did you go from that job to be done to a potential product? TIFFANY: So from there, we did go ahead, and we prototyped, and we prototyped a workflow that seemed to make sense given what we had heard from our users and then also just with my clinical background. And then that prototype really was the trick because a lot of times in healthcare, when you are working with clinicians, some are tech-savvy, but there's a significant amount (And this isn't age-dependent, but this is younger and older.) that are not. And so they really need a little bit of context to ground what their thoughts are and how they think you can solve them. So by getting that prototype in place and by letting the therapist really bounce around in there and see what was intuitive and what wasn't, that was the game-changer. And we could really see okay, here's our understanding of this. And whoops! Missed that one. [laughter] Oh, this all makes sense. But you could see as therapists went through what they appreciated was that the user interface was super simple, super clean. They could easily find things. And even those who didn't have a lot of self-efficacy around technology really felt at the end of a 20-minute session I know how to use this, and I could see how this will save me time. All of that data really helped us understand we were going down the right path. It was a little unsettling because when we looked at other products in the market, they would basically say, "We literally have 6,000 exercises that therapists can use." Well, we were really saying, "We're going to give you about 400. But the reason why is because it's a lot quicker to review 400 exercises and identify what you want as opposed to 6,000." And by and large, what we were hearing was that "Oh, well, when I use those apps that have 6,000 exercises, I just get overwhelmed, and it takes too long." CHAD: But that can be a little scary, too, because if you're in that situation where you know that the person making the buying decision is just going to look and say, "Oh, this one has more exercises." [laughs] TIFFANY: Yep, yep, yep. Yeah. CHAD: Actually, at this point, let's take a little bit of a tangent because you're doing this within an existing company, Relias. Relias isn't necessarily a small company. So what kind of reporting out or management of other stakeholders or the business did you need to do along the way? TIFFANY: That's a great question. And Relias is a big company, but also, this was a very new space for Relias. So they had never looked outward at a patient engagement tool. The focus had always been education for clinicians. So this was a very new space for them. And actually, the most important and early conversations really were with our legal team and our cybersecurity team. And that was because we were going to be creating a database for patients. Again, new space, and we really needed to de-risk as early as possible, make sure that we could actually build this thing, keep it safe, that the budget was going to align. Also, that information really restricted the kind of information that we can actually keep about patients. So having that on the front end saved us so much time later on. That was number one. And I would say anybody who's looking in the healthcare space absolutely has to start there because, again, the rules are changing constantly. And as clinicians, we are trained on how to take care of patients. We are trained to maintain patient privacy. We typically don't have a whole bunch of experience on cybersecurity and how you actually keep an online system secure. So you need to make sure you're talking to the right stakeholders to get the right information. So that was critical. CHAD: Some organizations have an executive sponsor on the team or embedded in the team so that there are direct status updates and awareness of new product development. Is that the track that Relias took, or was it something else? TIFFANY: That was absolutely the track that we took, so we did have an executive sponsor who we reported out to each week gave updates to. And he was able to communicate out to leadership as well. And we also had lots of opportunities internally to give updates and to do demos. So people could understand what we were doing; why we were making the decisions we were making to make sure everything aligned appropriately. CHAD: I'm a big believer in demos and that kind of thing to communicate. I think we all have been in situations where when you're working on a complex problem, even if you do all your research and answer every question in the most perfect way and all that stuff, if at the end of that process it’s the first time anyone's hearing about all the results of that, there's going to be so many questions about did you consider this? Did you consider that? And I think we all know that if instead we communicate things along the way and keep people up to speed, there's much more understanding but also trust in the process. TIFFANY: Yeah, absolutely. And I have also experienced what you're describing. And what I have found is it's really like the weekly demo can be really quick, super helpful, and then documentation, documentation, documentation. We've created FAQ pages because of exactly what you're saying. Because a lot of times, something isn't intuitive to a stakeholder, and maybe you've answered that question three or four times. So you've got to have it written down somewhere so that everybody's on the same page and understands. And even if they've missed seven meetings, if they come and have that question, hey, just so you know, we made that decision three weeks ago. This is why. This is the justification. This is why we're moving forward. CHAD: Yeah. Is there any other sort of techniques that you employ to try to keep people up to date or strike that balance there? TIFFANY: The main one, I think, is the weekly report out. And it is a challenge, and especially with things being virtual, of course, it's even more of a challenge because I think it's really easy to get insular but being consistent and being timely. So if everybody knows okay, I'm going to go to this meeting on Monday morning at 10:00 o'clock, it's going to be 15 minutes, and I'm going to know exactly what's happening, all of a sudden, that organization piece is so key. Keeping it short is really key, and then everybody's on the same page. And you don't end up with that; hey, wait a minute, I didn't hear about that. Or why is that happening? Because that takes so much time to manage. CHAD: We worked with one team several years ago, actually, but I realize that it might even be more relevant now. And I don't necessarily recommend this for every team. I think each team needs to find their own techniques that work well for their culture. But this team, rather than having meetings actually had...they had occasional meetings, but they actually had a team blog, internal, completely internal. And they essentially wrote a blog together that everyone who wanted to follow along was able to follow along with. TIFFANY: I think that's a great idea. I think in bigger companies, sometimes that gets lost. [laughs] CHAD: Yeah, it definitely worked for this organization's culture and who was following along, but it wouldn't work for everybody. TIFFANY: Absolutely. One other thing that I need to call out that I didn't was with some of the formative user interviews, we had to push on this, but we did try to get at least one member of engineering coming to some of those or at least getting some highlights. And this may seem like, of course, you would do that. But when you're working in a fairly large company that's entering into new space, there are new ways to be engaging your engineering team that are different and may not seem valuable at the time. So we rallied pretty hard to get some folks in there so that they could really understand the problem that they were going to be contributing to solving. And that was critical because the assumptions about if you're building an app for an older adult versus the realities are so radically different that you can only really understand it if you visually see it or hearing from your user. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: Okay, so let's pop the stack now and go back to where we were before we took that tangent into that side of internal communication and management. So you had the prototype and were starting to show it to potential users and were getting positive feedback. What were the next steps after that? TIFFANY: So the next steps for us were running through...and to be clear, we actually were creating two apps, which I never actually said, one for the clinician, [laughter] which the problem was to solve time, and one was for the older adult. And I've had a ton of experience actually designing for older adults. So some people may think that that might have been the harder app. But there are some really straightforward design tenets that work when you're designing for somebody who's 60,70, 80, 90, 100-plus. So starting out on the clinician side, got our prototype, went through, validated it with about seven clinicians, identified some areas of confusion, identified some areas that we thought were totally intuitive and were completely not. So my favorite was we wanted a way for clinicians to identify the patients that they were going to see that day, and so we just thought that if they favorited the patients, if they just clicked a star, and they'll show up. And we had seven out of seven clinicians say, "Does that mean that they're actually my favorite patient? [laughter] Like, no. Okay, missed the boat on that one; regroup. We went through about three prototype revisions before we got to the point where we were really happy with the workflow and felt like it was intuitive. So that was the first thing. And then the second thing was on the patient-facing side. And for that one, it's a totally different workflow because it's just one human who's being given exercises. So it really was, okay, how do they access the exercises? How did they experience the exercises? And what makes sense? And so we had a lot of questions because we were trying to figure out, do we want written text? Do we want animations? Do we want animations with audio? So we had a really robust user group that we were able...we had about ten that we were able to actually demo, and they could give us direct feedback on. And then we had a user group of about 30 people that we actually just started sending prototypes and surveys to get some better feedback. And what we found is when we did more of the email, we would send them an audio clip of an animation. And we did some really lovely A/B testing that way. And we got much better results. Because generally speaking, when you interview an older adult about something you are creating for them, they're super positive, even about the stuff they don't like. So it was a lot easier to get more robust, more real feedback by removing the human element and saying, "Hey, tell us how you really feel." We got some amazing feedback that way. CHAD: That's interesting. And just in terms of timeline, was this happening pre-pandemic or post-pandemic? TIFFANY: This was post-pandemic. Well, we really started doing this design work in the summer of 2020, so right in the middle of the pandemic, yes. CHAD: Right. And so when you talk about these interviews and all that kind of stuff, everything was remote. TIFFANY: Yeah, everything was remote, worked fantastic. That has been one of the cool things about being in this space, especially in design space, technology design, and aging, is that the acceleration of the technology adoption that happened in 2020 was mind-blowing. I started working with design with older adults in 2014, building them different types of applications. And it just was incredible the level of comfort that I saw in 2020 amongst a much broader audience compared to 2014, 2015. CHAD: Yeah, we've definitely seen that as well across different products. And the underlying reason is bad, but it certainly makes what we're doing a lot easier to have more people comfortable, even with little things like being on a Zoom call and knowing how to share their screen. Little things like that would sometimes be a big hang-up for getting good interviews and good feedback with people. TIFFANY: Absolutely, absolutely, and doing some relatively complex things. Like, we were trying to validate doing a two-factor authentication, and we were able to do it virtually. So it's really giving us some really neat tools to reach a broad audience. CHAD: A little while ago, you called out that there are patterns for building applications for certain ages. Can you tell me more about that? TIFFANY: Sure. There's actually been a lot of research done in this area. I've contributed a little bit to it. [laughter] So what we really found especially early on...and I was involved with a project to take the connect technology and the Microsoft Connect technology and modify it to deliver a fall prevention program to older adults. So in my previous life as a physical therapist, I have a Ph.D. in human movement and did a lot of research in healthy aging and injury prevention. And older adult falls is a fairly significant public health issue. And there are a lot of cool things you can do to address it around exercise. But the problem is scale. So how do you actually bring some of these exercises to older adults at scale as opposed to one on one? So that's the context behind this. And so we started working with Microsoft SDK, building this out. And what we quickly realized is that the things that tend to make, let's say, a video game really cool and engaging are actually the worst things you can put into design if you're introducing an older adult or someone who's not comfortable with technology into a game. So you need a very simple interface, to begin with. And you need very straightforward commands. And so it's funny because, in 2013, 2014 the people that were in this space all came from the gaming world. So they'd make these really beautiful backgrounds and things jumping and popping out. And you would lose your user within two minutes because it was just so visually overwhelming. And one of the things that's interesting is as we get older, our brains are just not as flexible. They're super smart, but they get easily distracted. So what we learned is if you keep your user interface super simple, and then you make your early experiences very positive, so you keep the tasks very straightforward, you show success, what happens is your user gets a ton of self-efficacy. And they start to really realize that they know exactly what they're doing because they do. And then you can start doing some more interesting things. So what we found is with our technology, as we got our users, okay, they're using it three times, they're using it four times. They're being super consistent doing this exercise program. Let's make it more visually engaging then they could actually handle it because they weren't so worried about what do I do next to go forward in the exercise program? So yeah, so when you think about design, that was a really long-winded answer, sorry. CHAD: [laughs] It's okay. TIFFANY: But you want to keep things super simple and straightforward. You do need to infuse it with compassion and empathy, and if you can do small successes, really, really helpful. The other thing that is incredibly helpful, and this is going to sound a little hokey, is that any kind of avatar or chatbot who's super positive really, really can have a big impact. Because a lot of times, older adults are by themselves trying to navigate this thing, and they have no idea what's going on. And if a chatbot pops up and says, "Hey, you're at this stage, do you need any help?" Or "Hey, you pushed the red button, good job." There's this very interesting relationship that gets built with older adults and chatbots and avatars. They engage with them much more. And I think ultimately what I saw because we were using an avatar to lead through exercises is that self-efficacy increased because even though the avatar was leading them through the exercises, they ultimately knew it was them. Compared to if I was leading them through the exercises, there's always that yeah, I did it, but Tiffany taught me how. Whereas this is well, I did it, and the avatar taught me how, which really means that I actually did it. So I can actually do it. It's a really cool space. CHAD: In validating the exercise format through those surveys and that kind of thing, what did you learn in terms of the format? Was animated ones winning out? TIFFANY: Absolutely. What we learned was animation, hands down 100%. We also learned that animation plus narration really was the winning ticket. What we had tested we did some A/B testing where we did animation plus narration, and we had the exercise instructions written with the assumption that, well, some people are visual, and some people are auditory, and some people want to read the exercises. And we compared that to just animation plus narration and no written instructions. And the feedback we got was that it was too much. Like, you're reading the instructions, you're watching, and you're listening, and it just was confusing and overwhelming. And sometimes it wasn't an exact match because when you're narrating an exercise versus reading about it, the words aren't always exactly the same because sometimes it just doesn't make sense to make them the same. But when you just had the narration with the exercise, people were really happy. They could see it, they could hear it, they could replay it. And the other thing that was really nice about that particular format is it also gave a little bit of space. And this is on a mobile device, so when I say little space, I do mean little space where if the therapist had any specific cues, they could input it in there. So then now the patient's got...they can see the exercises, they can hear how to do it. "Oh yeah, and my therapist said, 'Make sure I put all my weight on my left leg.”’ So that just seemed to be the right package as opposed to dumping all of this information on the user. CHAD: One of the things, when I've worked with people or organizations before that can become a bit of a blocker, is identifying something like this. Oh, animations with narration that's what this should be and then needing to produce all of that in order to bring the product to market to create it all from scratch. Was this material that you already had at your disposal? Or was it going to need to be created? TIFFANY: It was going to need to be created. And the way we addressed that issue is we looked at, for lack of a better word, what are those key bread and butter exercises that just about every therapist prescribes to just about every person? I mean, it still was a sizable lift, but again, it wasn't an overwhelmingly huge production. So we went ahead and said, okay, table stakes. We've got to have these in because if you don't, then it's not really usable. And of all of these, which are the ones which are generic enough that if we built it once, a therapist could put in additional instructions to do any kind of modifications? So that was really how we addressed that. I would say if somebody is starting completely from scratch, pick a total of 10 exercises or a total of 10 things and just pilot that and just try to do low-fidelity prototypes and just validate it before going down the path. CHAD: So in the story here, we're moving towards actually building something. Was there a go/no go point in the product's life cycle where you needed to get sign-off on something in order to decide to actually bring this product to market? TIFFANY: Yes. And interestingly, we are in that point at this exact moment in time. [laughter] So we're at the point where it's released in alpha. We're getting some really great feedback. And on the clinician side, we're back to the original challenge around building something for patients. We are still actually putting finishing touches on making sure that we can really secure this database the way it needs to be secured in 2022 because things, again, are moving pretty rapidly. So we are waiting for our go decision as we speak. CHAD: But we did build something. TIFFANY: Yes. CHAD: So you didn't need to get full sign-off and go/no go before going from prototype to starting to build something. TIFFANY: Correct. Yes, yeah. Yes, sorry. CHAD: No, it's okay. TIFFANY: We had, like I said, we were really good communicating out. We had all the data to support the decisions that we made. We felt like we had a couple of very minor outstanding things that we knew that needed to still be addressed. But we also felt we were at that point where we could go ahead and build. And once we got in people's hands, we probably have much better data on how to address the outstanding items. CHAD: So given that you're at the point of you've gotten some things in people's hands, you're now making sure that this can be a product that you fully bring to market. What are some of the factors that are being looked at? And you mentioned security is one. What are some of the others? TIFFANY: Some of the others...I will say one of the things that is not a factor but was a factor early on is, hey, wait a minute, can older adults really use this? Are they really going to want to use this? That's a slam dunk. Yes, they can use it, and yes, they really want to use it. Plenty of data there. So one of the factors that's...believe it or not, the pandemic is actually throwing us a little bit of a curveball in the sense of there is so much transition happening in healthcare right now that we're having a couple of little challenges around...some of our clients are actually changing their settings. So our first target market is people who are in home health. Well, if all of a sudden you are going from skilled nursing and opening up home health, there are a lot of factors you've got to balance. So that's been a little bit of a curveball. And it's also been a curveball in finding our early adopters to really go ahead and test it out. And then the final thing that is a big challenge, and I think it's a challenge for everybody, is integration with pre-existing systems because there's so much variability and variety of EMR systems. I'll give you a great example. You could have a skilled nursing facility that has one EMR system, and that skilled nursing facility could contract with a rehab therapy company who uses a different system, but they're both seeing the same patient. We want to be super strategic about...because, again, that's a huge resource suck of looking at those API integrations. That's one of the things that we're really doing a deeper dive into now to really figure out where do we actually put these resources? What's going to give us the most bang for our buck? And knowing that the target is moving constantly. CHAD: What do you do while your...one of the challenges can be like, oh, we've got a team ready to build the product. Are you in a holding pattern now? Or what do you do? How do you manage that? TIFFANY: There are two ways to manage, and one is going back to your product right now and doing more testing, which is always a good thing because you're just refining, refining, refining. It’s tricky, though, because when you've got a lot of limits on resources, especially human resources, lots of projects going on, the tricky part is can I keep my team, or do they need to get repurposed? And I think it's all about having really honest conversations and if they are going to be pulled into another project, making sure everybody's on the same page about what that looks like so that if you are in a holding pattern, when you get off that holding pattern, that there's not a huge delay. Lots of conversations, lots of discussions, yeah CHAD: Well, I wish you the best in working through all of that and bringing this product to market. I know you've been a tremendous partner in working on this together. I know the team has enjoyed working with you. And we work with a lot of people at different companies, and your experience in navigating this has been notable. TIFFANY: Thank you. The team was amazing. I mean, it is a really great group of people, really open, at the same time, really able to crystallize some of the challenges in a way that was incredibly effective. So yeah, it was really a fantastic experience, and I'm very grateful for it. CHAD: So if folks want to follow along with you or get in touch with you, where are the best places for them to do that? TIFFANY: Either on LinkedIn. I, of course, have a space on LinkedIn but also at Relias. And my email is tshubert@relias.com. CHAD: Wonderful. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guest: Tiffany Shubert.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots

Chad talks to the CEO of thoughtbot, Diana Bald, about 2021 in retrospect. thoughtbot, as a company, has settled into a new structure that contains different teams and committed to becoming a fully remote organization. Last year, Diana successfully transitioned into taking over the company's CEO role. She and Chad talk about the improvements the company made in 2021, including DEI (diversity, equity, inclusion) efforts and training sessions, and look ahead to some improvements coming in 2022, such as an expansion of the apprenticeship program. P.S.: thoughtbot is hiring! To see open roles, visit thoughtbot.com/jobs. Follow Diana on Twitter or LinkedIn. Follow thoughtbot on Twitter, or LinkedIn. Email Diana at dianabald@thoughtbot.com. 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 back again is Diana Bald, the CEO of thoughtbot. Diana, welcome back to the show. DIANA: Thanks for having me back, Chad. Hello everybody out there. CHAD: You joined us in the spring; I guess is the best way to put it where we talked about the transition from me to you of CEO. And it feels like it was actually simultaneously both just yesterday that we did that recording and a long, long time ago. How has this year been for you? DIANA: Yeah, I completely agree. It feels the same way for me. [chuckles] This year has been interesting and eventful. Well, 2021 has been. CHAD: So we're recording this just in the dawn of 2022. Looking ahead, we're bright-eyed and ready to go to the New Year, right? DIANA: That's right. CHAD: So I thought that it'd be good to do a little bit of a retrospective or a review of 2021. A lot changed for thoughtbot. And the last time we talked about it was way back at the beginning of all those changes. And I've had all the managing directors of the different teams on now to talk about the different teams, and what they're focused on, and how they're working, and what their goals are. And I thought it'd be fun to do that for thoughtbot overall with you. DIANA: Yeah, I think it's a great idea. CHAD: Cool. So since we last talked, we really settled into the different teams and the new structure. And even little things like we've sublet most of our office spaces and those kinds of things. I'm really reaffirming how things have gone. But I'm curious, just at a high level, what's been the most surprising thing for you about 2021? DIANA: [chuckles] That was not a question I was expecting. CHAD: [laughs] DIANA: The most surprising thing for me was (There were a lot.) I think how quickly we put everything together actually. That was probably the most surprising thing. I think that we were able to reorganize and pretty much just get to work in the new team structure right away. There wasn't a lot of reinventing. We reinvented when we redefined. But as we started doing the work, it was very logical, like, oh, this makes a lot of sense. These teams break out very nicely. So that speed in which that happened, I think, was the biggest surprise to me. CHAD: I know that some people said we moved maybe too quickly on some of those changes. How do you respond to those people? DIANA: [laughs] It's different personalities. Well, can I take a philosophical perspective? CHAD: Yeah, totally. DIANA: Okay. So I have a frame of mind as life doesn't happen to us. It happens for us in the sense that there is never a perfect time to do anything. One can be preparing, preparing, preparing, and it's good. Preparation is great. Analysis is great. All that stuff is good. But there's never going to be perfect anything. In fact, it's better to get started to get the feedback because the feedback is real. And it's kind of like the way that we actually work, in fact. You respond, and you iterate based on what the circumstances are telling you. And I think that's the difference in point of view. So, for me, I thought the pace was nice. But I could see why other people might have thought we moved too quickly. CHAD: So I forgot to mention the episode number if folks want to go back and listen to more of the details. It was Episode 392 where we talked, and then Episode 393 at giantrobots.fm/393 is where we talked about the details of the different teams and going fully remote, so if folks want to go back and listen to that. And then obviously, I've been talking to the different managing directors recently. So now that we're almost a full...actually, I think we're a full year from when we actually made the changes. DIANA: January eighth was the day. CHAD: So we're a few days shy of a full year. I think there are really two aspects of this whole thing. There was the concept of going remote and committing to being fully remote. And there's the concept of then reorganizing the company in a way that was supportive of that. And a lot of that was driven by the fact that we were really organized previously around the geographic studios and how we didn't feel like continuing that way was going to be something that would be sustainable for us over the long-term, both from a sales and business perspective but from a people perspective too. And so we talked about the teams and how quick and how I think overall well that has gone. How about the fully remote aspect? How has it been for you personally? That's one way to put it. DIANA: Well, I think that remote should be taken into context. We went remote in a time when the entire world was going remote. And I think that if we had gone remote at a different time, our experiences would be a little different because, with the start of the pandemic, we had a lot of limitations to our freedom because we were on lockdown. And so when you go remote in a time of lockdown, and a time of limitations to freedom, it's very different than being remote at a time when you have the flexibility to go work out during the middle of the day, go pick up kids from school or whatever one does when you have flexibility. [chuckles] So I think that the time that we started remote helped us clarify that yes, this is something we want to do. But I think our experience was tainted because we were in lockdown at the time, and our freedoms were very limited. If our freedoms weren't so limited, we had planned, as you know, because we talked about it, having pop-up offices or having the ability to bring people together, and we weren't able to do any of those ideas. The pandemic took much longer than we thought it would for us to get to that. And right now, we're back in that place where Omicron is going on. And we're still kind of semi...not really locked down, but a lot of us are being extra cautious. And then, for me personally, I'm enjoying the freedom. I like the freedom. But I'm also very cautious because I have to protect my family. And I just need to be very careful when I meet with people and things like that. CHAD: Well, I agree that the social-emotional impact of how things have been for the last two years basically has made this transition difficult for a lot of people, myself included. And we've needed to be mindful of that, I think, as we try to move forward as aggressively as possible towards the way things we want to be. I think it's been challenging for myself, for team members to realize that the way things are now isn't necessarily the way things are always going to be. We will be able to be in person. We will be able to visit each other. We'll be able to have those pop-up offices and that kind of thing that we've been limited to do. I'm really looking forward to that sometime in the future. DIANA: Yeah, for sure I am as well. CHAD: The other side from the business has been we're not getting pressure from clients. I feel like I'm revisiting this topic. [chuckles] I know last time we talked, it was like, I wonder what it's going to be like when we start getting clients back in person. And is there going to be pressure to be with them? And that kind of thing. And unfortunately, because of the pandemic going on, we haven't been getting that pressure. Now, that works for our business because it just relieves the pressure or the need to travel or schedule things and that kind of thing. But that being said, I'm more optimistic than I was before even though we haven't truly lived it that not only will clients...and that we have a really good way of doing things like design sprints and everything remotely but that there will be a benefit to getting together at the start of projects once we can safely do that and everything. And I think people will better understand the concept of we're getting together to kick off the project or to do the design sprint. We could do it remotely, but we're choosing to do it in person with the understanding that it's totally fine to go back remote after we've had that in-person kickoff. DIANA: Yeah, and I think that there's going to be some situations where it will be better to be remote to have the sprint and other situations where let's say you want to test something with a live audience or you want to get feedback from live people interacting with a physical object or something like that where it would make sense to have the physical in-person component. And other things are better with a brainstorm to have it be digital. I think it just depends on the circumstances and the client and what they're looking to achieve. And having that flexibility that we don't currently have right now because of the variant is something I'm looking forward to. CHAD: So when we talk about the transition and you taking over the CEO role, I said that one of the reasons why I thought that was the right thing to do and was excited to do that was because I thought that you were going to be better for what the company, and particularly the managing directors and the other leaders at the company, needed to get to the next stage. And I forget exactly how much...a lot of that is baked into getting to the next stage of thoughtbot. One is resiliency of team and leadership and not having it be based solely around me. That's certainly one aspect of it. The other is your deep experience with sales and marketing; business development better match what we need to do going forward in terms of building, getting to the next levels of revenue, and sustainability. And at the time, you were still learning, or maybe learning is the wrong word. How would you describe it? Basically, like getting a handle on things before making decisions or changes to move forward with certain aspects of how we do business development and that kind of thing. DIANA: Yeah, I think I understand what you're saying. CHAD: And so now that we're significantly past that point, what are some of the things that you've done or focused on with thoughtbot business development with thoughtbot overall that you would consider positive changes? DIANA: I think the introduction of Rocket Fuel is one that I would consider a positive change in that direction. We had...I don't know if we want to re-familiarize the audience with the theme of rocket. CHAD: Yeah, I totally think you should because I think it might come out of nowhere for people. DIANA: [laughs] So we organized around a theme to make it easier for us to convey what we're doing. And you could think of the stages of a rocket from ignition to blast off in orbit. And basically, it's a fun way of saying that we have an end-to-end product development process. And so everything from ideation and validation that's our Ignite team, to building and going to market is our Lift Off team. Scaling and transforming is our Boost team. And supporting and maintaining is our Mission Control team. So when you have a rocket, you need fuel. [chuckles] And so that's where we introduce Rocket Fuel, which is basically business development and marketing. And what we did is we changed it from being two different ways of approaching, driving the business into business development being the driver and marketing being the support. And what I mean by that is it's more strategic, in line with the different stages of where we are. So for the Ignite team, their needs are very different than for the Boost team. So when we're in the ideation validation stage with a client, it's very, very different than a client who's in the transformation or in the scaling stage of their product. So having that mindset of driving that phase of product development has been very helpful to us because then we can apply the marketing tactics, strategies, plans around the stage of that product lifecycle. So that's been something that I think has worked really well this past year. CHAD: So what does the Rocket Fuel team look like? What are the different roles on it? DIANA: Well, it's small right now, but we're growing it. We have Kelly, who is our Associate Director of Business Development, and she's focused on supporting more of the implementation of some of the ideas that are coming out of each of the marketing tactics that I mentioned earlier. So whether it's partnerships with different organizations or whether it is campaigns that we're running so overseeing those, and she's also stepping in when the managing director has to step away for a few months, maybe somebody is taking paternity leave or something like that. Kelly stepped in there. And then we have in sales enablement Liz who's serving as a Sales Enablement and Business Development Manager. And she's really helping us get exactly what her title says, enable the sales process. So she's putting together the marketing collateral. She's got our CRM system, getting that organized and up to date with information. And she's starting to work on updating our handbook with business development information and marketing information that's changed since we were in our old structure. So she's getting that in line. So she's more behind the scenes and more enabling us to move quickly. And Kelly is more on the strategic end of it, helping us build out the plans that'll drive the growth of each of our teams. CHAD: And Liz is also helping respond to RFPs and making sure things move forward or are pulled together for making proposals and contracts with clients, right? DIANA: Yeah, she's doing a great job on that. CHAD: I think all of those things are something that we had talked about doing for a while, having someone be able to help with those kinds of things, especially when we have a world where managing directors at thoughtbot are responsible not just for sales but for the whole business that they run. And so they have a lot on a day-to-day or a weekly basis of what they need to spend time on. So having someone who can help them have time to spend on things that are not sales and to make sure that sales move along quickly, I think, has worked really well. And it was something we had talked about for a while, and I'm really happy to see it come to fruition. DIANA: Yeah, I am too. I agree; it is helping the managing directors take a breath. They need sustainable lives as well. And it's good that we're able to help them in this regard. I think we can help them even more. Liz has only been with us for a few months. And as she gets more and more comfortable, she gets more and more ideas and starts to run a little faster, which is great to see her do that. And the same with Kelly, as she's wrapping her arms around her new role, she is also coming up with a lot of ideas. And it's exciting to see them work because they energize each other. [laughs] It's really cool. And we're also recruiting for an Associate Director of Business Development for Mission Control to help us grow that team. If anybody out there is listening, and you know of anyone, [laughs] encourage them to apply. CHAD: Yeah, that's a really good point. So that Mission Control does DevOps, maintenance, SRE work, so we're really looking for someone who has experience growing and building that kind of business. And it's quite honestly a big growth opportunity because there's a real opportunity to start as the Associate Director of Business Development in that business and grow into more of a Managing Director role, right? DIANA: Absolutely. We see it as an opportunity to come in on the ground floor; essentially as the very fast-moving, high potential team gets going. So it's a super exciting opportunity for people that are interested in DevOps or Site Reliability Engineering or anything else that we're doing in that space of support and developing. CHAD: Great. Well, hopefully, someone hears this and says, "That's for me. I want to apply." If that's you, you can go to thoughtbot.com/jobs and check it out there. I'm making my hard pitch here. We also have some outside consultants helping with running different campaigns and digital marketing activities, right? DIANA: That's right. We are working with outside consultants to help us run some targeted campaigns based on some of the strategies that Liz and Kelly are developing. And they're doing the actual implementation of the marketing. So they'll buy the ads; they'll run them. And we also have somebody helping us with social media. Mandy is doing that. She's doing a great job of that. And we have Tori, who's still helping us out with some of the digital marketing campaign, conceptualizing them, and transitioning some of that work that she was doing on the CRM, transitioning some of that over to Liz to take over our sales enablement. So a lot of activity happening over here at Rocket Fuel. CHAD: So to put it as plainly as I can, thoughtbot has been successful. We've been particularly successful from a culture and team, and thought leadership standpoint. But we haven't been incredibly successful in making a company that operates at the level that we do and generates enough profit to be really comfortable that when a pandemic hits...that's an extreme circumstance, but there are ups and downs in every business. And our margins haven't been historically as large as other consulting companies and that kind of thing because of the kinds of team we have and the way that we run the business. And so a big goal of when we talk about taking thoughtbot to the next level has been sustainability and making sure that we operate with enough cushion that we can more than weather downturns or ups and downs in the business without having to let people go or make significant changes. And if people listened to the prior episode, they know that we had actually made significant progress towards that goal in 2019. And we were feeling really great going into 2020 about what we were going to accomplish. And then, in April of 2020, we had a significant decrease in revenue all at once, which really threw the business into turmoil because we hadn't been operating with that significant margin, a sustainable margin. So we spent 2020 recovering from that, making sure that we had corrected some of those fatal flaws. And we saw, I think, a lot of that come to fruition in 2021 and had a really sustainable year where we met and exceeded our goals. I'm really happy about that. I assume you're happy to. [laughs] DIANA: Yes, I'm really happy about that too. [laughs] I think that it's something that we haven't celebrated, and we need to celebrate it. It was actually a really great year for us financially. And I talked about speed earlier. And I said I was pleasantly surprised with the speed. And one of the factors is that in the first quarter of last year, things started to come together for us in that vein of financial sustainability. And we were able to maintain it every quarter of the full year. That's pretty great. And we should pat ourselves on the back for that. Congratulations, Chad. [chuckles] CHAD: Congratulations, Diana. You and I have talked about this before. So overall, the market recovered in a really good way for services, businesses, for software development. So that boosted our ability to really go above and beyond. But even putting that aside, it took a lot of work. It wasn't easy. And it was through the fundamental changes we had made that we were able to take advantage of that good market, I think. DIANA: Yeah, I agree. And the intentionality of what we were doing, I think the reorganization helped us see clearly the benefits of each team. Obviously, today, I have a much clearer insight into each team's strengths and each team's capabilities than I did a year ago when we last talked. I think we are still trying to get our...is it going to work? What is it going to look like? And now it's like, oh, this is so obvious. This makes a lot of sense. The teams are working on very different aspects of the product development lifecycle. And I think that intentionality also helped us with our goals. CHAD: And I think that one of the goals of doing that too was to free people up to better understand and focus on the kind of work that they wanted to do rather than trying to do everything everywhere. And for the individual person at thoughtbot, never knowing what your next client project was going to look like because it could have been any of our types of clients that we have. And I think overall, what I've heard from the team is that it has been a good opportunity to reduce those surprises, get better at the kind of thing that you're working on now, even if ultimately that means okay, you've done your stint in Lift Off and now you want to move over to Boost, or you've been in Boost, and now you want to give Lift Off a try. At least you can do that with intentionality as opposed to never being quite sure what your next project is going to look like. DIANA: Yeah, exactly. There are some people that like that variety of moving back and forth, and that's good that we can make that happen. And then there are others like you said, that really want to hone in on an area of specialty and get better at that particular thing. CHAD: I think there's a benefit to us even just having words to use to describe the different kinds of projects now because we never had those words to use before. So when now internally people say, "Oh, this is a boost-style project," that means something to people. And I think it helps us talk about the work that we're doing or we might do for customers. DIANA: Yeah. CHAD: Cool. So what else happened in 2021? [chuckles] DIANA: What else happened in 2021? Well, we did a lot of DEI training, and that was great. I learned a lot in that training. I thought actually that I was pretty hip with everything. I thought I've been involved in DEI activities all my life, so I get it, of course. But then, once I took the training, I was like, wait, there's a lot to learn here. I thought I knew a lot. But I'm learning a lot. There were several courses and several sessions. And with each session, I came away learning a lot more than I thought I would and having a greater appreciation. I think one of the greatest appreciations I learned last year was an appreciation for words, how important it is to think about what you're saying. A lot of times, we just talk, and it's important to really think through what one says. I took that to heart from the training that we got. CHAD: And I think people might hear that and say, "Oh, you're talking about being politically correct," and perhaps maybe having a negative reaction to that. But I think one way to think about it is it's not just being politically correct for the sake of being politically correct. But words can have an impact on people, or the way that you talk about something can have an impact on people, either by making them feel bad or excluding them. When you have a group of people working on something, people come at work with so many different backgrounds and experiences, and perspectives. And so, having an inclusive environment where everyone can contribute fully is super important to not only being fulfilled in our work but ultimately creating great products too. DIANA: Yeah, absolutely. And that diversity is something that will make us have better products. But it also makes us; I think in many ways, better people by understanding where others are coming from, what they might have experienced in the past, and knowing that what is available to one person may not be available to others. So it's not just political correctness but also a better understanding of humans and what we go through and that it's not necessarily equal for everyone. And it's not necessarily fair for folks. And that's sometimes easy to forget. And I think that training that we went through really reminded me. And it gave me an appreciation for the privileges that I do have and just a greater awareness that I'm so grateful for. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So we've had a DEI Council at thoughtbot for a couple of years now. And I think that we created it because of the studio model. We were very distributed as a company. And so we wanted a group of people that could come together, work on things, but also collectively, educate themselves and take action items and everything, and then take them back to their physical studios. And I think that now with the reorganization, with the progress we've made, it's not that the Council doesn't work. But it's in a different spot in terms of what we're hoping to achieve as a company and the way that it's working. So we actually have right before the end of the year, we opened a DEI program manager position, which is a full-time position at thoughtbot for someone to not do all of the work that the council is going to do but a centralized thing to make the distributed nature of the...to sort of empower the council, and free up time. We're all on client work a significant portion of our time. And so striking the balance between having DEI ingrained in the company, having everyone have enough time to work on what needs to be worked on, and to have it all be managed, we looked at that whole picture and said, we think that the Council could be even more effective if we have someone on board who can work with them full time basically. And people might be saying DEI Council full time? It's not just the council. So it's diversity, equity, and inclusion. So it really permeates everything about our culture, and how the company works, and how it functions. And there's a lot there. So that person is going to be part of the operations team, which is my team. And they'll be ingrained, you know, part of everything that we do to make thoughtbot operate but through the lens of is this equitable? Are we inclusive of the people that we have on our team in Africa and South America, as well as the United States now? That's a huge thing for us, making sure that we're setting things up in a way that works for everyone at the company. And we're more internationally diverse than we've ever been before. And so that has been something that takes up a lot of our time. And we want to make sure we do a great job with it. So that's one of the things that this new person is going to do. DIANA: Yeah, and one of the things I'm really excited about for this person is putting some metrics together for us. It's been hard for us to quantify our progress in DEI. And I know that this individual will be doing that, which is to me exciting because we're going to be able to see how are we really progressing with these initiatives? I think that's going to be great. And also, being able to partner with other organizations just outside of thoughtbot is going to be interesting as well because our DEI Council does it, but none of us have a lot of time to actually do too much of it. Everybody's got like you said, client work and other things they have to work on. So that's another thing I'm really excited about this individual taking on is that outside partnership perspective. CHAD: I feel like we have a lot of positions open right now. DIANA: [laughs] We sure do. CHAD: Not only in the operations or the non-designers and developers. We've got a lot of design and development roles open as well. DIANA: Yep. Plug for the thoughtbot.com/jobs page. [laughter] CHAD: Yeah. Well, one of the things that I'm really excited about going into 2022 we've had the Apprenticeship Program for 11 years now. We say on the website we've done over 50 apprentices. I think it's more like over 75. I just stopped doing the count a while ago. But we haven't been able to do it consistently previously because when we were distributed among the different studios, and everything was based on who you worked with in person, we needed to make sure, you know, not every studio was even large enough to have enough mentors to be able to have apprentices. But we also needed good projects for mentorship and having apprentices on them. And we also needed to make sure, like, oh, if we take on an apprentice in Austin, we need to make sure that the Austin studio needs another Rails developer. And so it was pretty limiting. But even though it was limiting, we did lots of apprentices. And it's been super successful. So many leaders at the company started as apprentices. DIANA: Christina comes to mind. She's like a development director now. CHAD: Yeah, exactly. A lot of the development directors at thoughtbot started as apprentices over the years. So I'm super excited because this is another thing that no longer being in-person studios unlocks for us is to say basically thoughtbot as long as we're hiring across all of thoughtbot, we will always have the need for designers and developers. And so we can make the Apprenticeship Program more of a rotational program. No matter where you live now, you can join. We can do remote apprenticeship like all of our positions. And you can rotate among the thoughtbot teams with a great mentor from each team and then be promoted as a designer or a developer onto one of those teams that has a position for a Rails developer or a designer. And that is going to enable us to have consistent apprenticeship positions across the company open all the time with a consistent application process with timelines laid out for when deadlines are going to be for applications and when we're accepting people, and when people start. And I'm really excited about that. I think it's going to be not only great for apprentices, which is actually one of the primary reasons why we do it but also great for thoughtbot to get this consistency to what has been a really valuable hiring channel for us in the past. DIANA: Absolutely. I think that's one of the things I'm most excited about, to be honest with you, is that Apprenticeship Program because of everything that you mentioned. And it's not like we just need to limit it to one person. It could be a group of people going through the program together, which gives them a sense of camaraderie as well and a second incoming class. We have an incoming class. [laughs] CHAD: Right, right. My only regret is that even just in this first batch, we can see...or I've just had the potential of the Apprentice Program for us reinforced. In this batch, we have almost 1,000 applications across the two Launchpads with the design and development positions. It's incredible. [laughs] DIANA: That's so amazing. CHAD: Even though we're having more apprentice positions than we've had in many years going for 2022, it's still not enough. There are so many people that could be great fits for thoughtbot that we might not be able to have enough bandwidth to take on. So I'm looking ahead to the next thing as like, how can we grow enough to have even more apprentices? DIANA: Well, let's get Rocket Fuel to help with that. [laughter] CHAD: Yeah. I've often said that hiring great team members really isn't our problem. Our problem is consistently having more than enough work to be fulfilled, to be picky and choosy, while also having enough work for our team very reliably, weathering those ups and downs. And when we turn off hiring, it hurts our ability to hire overall because it takes longer to ramp it back up and that kind of thing. And I think you saw that throughout the course of 2021. We had to turn off hiring for a while in 2020. And when we resumed it, it took quite a while for those wheels to spin back up and for enough people to get through the pipeline. Because even though we get a significant number of people applying, we really only hire less than 1% of the people who come across because our standards of what we want when we add people to the team are high. DIANA: Yeah, it's true. It's challenging. We really did feel that impact pretty hard for a while there; the repercussions of not having the hiring open in 2020 were felt for sure. CHAD: We also made the decision that we were going to focus on making sure that when we started hiring back up, we didn't just necessarily go right back to the way that we were doing things before in terms of all of our process. So we used to have a lot of automation in place because of the number of applications. And we didn't immediately put all that in place because sometimes that automation got away from us. We care a lot about the hiring process. And we wanted to make sure that we just didn't blindly turn it back on because we had a sense that it wasn't 100% working for us. And the other was that we made the decision from a DEI perspective to make sure that we didn't move forward on starting interviewing for a position without having the candidate pool we were choosing from reflect a representative sample of the United States. And that's in the tech industry; if you put a role online and just let people come into it organically from a normal job pool, the tech industry isn't representative of the United States demographics. And so, if you just let that status quo come in, you're going to see what's reflected in the tech industry. So that was another important but real limitation that we put on ourselves when we started hiring again. DIANA: Yeah, it was painful, [laughs] but it was necessary. CHAD: And I think we've seen as people move through the pipeline and as our hiring goes up that it was worth it, even if it wasn't easy and was difficult. DIANA: That's how things usually are, right? CHAD: Right. [laughs] DIANA: Things are usually not easy. And usually, things that are worth it, there's work involved. CHAD: And we're not done with DEI work and trying to build the kind of organization we want to have. You're never really done. So there's always something that we can do better. We still need to really speed up our hiring process, which has been pretty much stuck at a certain timeline for a long time. And figuring out a way to speed that up while still staying true to the kind of process and the qualifications that we want to put on the process continues to be a challenge for us. DIANA: I think that's industry-wide, though. I don't think that's unique to us. There are a lot of companies challenged with hiring at the moment. There are a lot of reasons for that. But we definitely have to keep on top of it and try to figure out ways to make ourselves better. CHAD: Yeah. I think the biggest problem is to the extent that if you lose people along the way that you would totally otherwise hire because they go to other companies first just because you didn't finish the process fast enough. That's the fundamental thing that we want to avoid. DIANA: That's the real risk that we...I think we actually lost some people for that. CHAD: Yeah, definitely. And over the years, despite trying, we haven't been able to significantly speed up our hiring process. For folks who aren't familiar, a big part of our process is having a few different stages. And the final stage being pairing, working with actual members of the team for the day. We pay for that day. And meeting the rest of the team and having a process which involves the rest of the team it's not just a siloed hiring team that's making all the hiring decisions. But doing a full day visit as the last stage means effectively that we can never have two people interviewing for the same position. And then everyone being on client work and only really being able to do those visits on Fridays means that the fastest, unless we're willing to make a change to that, the fastest we can go to hire into any one position is one final stage interview a week. That's a bottleneck. DIANA: That's a bottleneck for sure unless we have dedicated people doing the recruiting. Then that would be a challenge as well because that's all these folks would do. CHAD: Right. And then the team would feel, you know, we gain a lot from everyone being part of the team. So that when people show up on day one, we can say, "Hey, everyone that you worked with, everyone that you met was a unanimous yes to you being here." It builds a tremendous amount of trust and confidence on both sides, I think. And to not have that, I think we would need to then do a lot more work in building up that confidence of those new team members and of the team in that process and on day one when they show up. So it's an area of future work for us, definitely. I don't know what the solution will be eventually. But I do know that it's an area that we have to improve on. DIANA: Yeah, agreed. CHAD: Cool. Well, anything else on your mind before we wrap up? DIANA: No. I'm looking forward to 2022. There's a lot that we want to do. And it's going to be an exciting year. It's already starting off exciting. [laughter] Though, I do want to talk a little bit about community now or? CHAD: How about we give a little sneak peek in terms of what we're thinking for 2022? And then, in a little while, we'll have you back on to talk more about it. How's that sound? DIANA: Yeah, it sounds great. CHAD: Okay, community has always been a big part of thoughtbot. It's what has driven a lot of the open-source that we've done, our blogging. But what do you mean by community in 2022? DIANA: Well, we started off this conversation by talking about remote and some of the pros and cons associated with it. And I think that one of the things that remote does there’s a lot of benefits to it. But I think that we need to help overcome the challenges, and I want us to do more of that in 2022. So, for example, creating a culture where people feel the recognition that you might be able to do more in person than you do remotely or lessen feelings of isolation that some folks feel, bringing out the quiet voices among us, giving them space to talk and give their voice. How can we make that happen? Finding ways for people to build relationships with each other and maybe people that have never met, that are on different teams. How do we make that happen? Just overall experiencing a positive, respectful and inclusive work environment. That at a remote level is something that I think we need to dive in deeper this year. And like you said, we can dive into that more at another time. CHAD: Yeah, I'm excited. I feel it too. And it comes from I think maybe it was Stephanie or Louis that was talking about it, both members of our team who were generally like, when you were in person, there was an ease to either talking to someone off-hand or even just when you have a daily sync every day in person, it's easy to recognize a success and to have everyone applaud. And when you aren't in person with each other, you need to work at it more to really foster that sense of team and community. And that's clearly part of what getting through 2021 and settling in and getting to the next level is about for us. DIANA: Yeah, absolutely. CHAD: Cool. Well, if folks want to get in touch with you or follow along with you, where are the best places for them to do that, Diana? DIANA: I started off last year actually doing some tweets, and I'm not very good at it. I totally stopped doing it. But I'm going to try to do more of it. I can be found on Twitter @dianabald, first name, last name. I'm on LinkedIn, first name, last name. The good news about my name is that there’s not a lot of me out there, [laughter] people with my last name. So I'm easy to find. And by email, it's dianabald@thoughtbot.com. CHAD: Great. You can subscribe to the show and find notes for this episode along with transcripts at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. I'd love to get some comments and questions in 2022 and bring them to the episode. And you can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Diana, thanks again for joining me. DIANA: Thank you, Chad. Thank you, everybody. CHAD: And thank you for listening. See you next time. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guest: Diana Bald.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots

Chad talks to Rob Hirschfeld, the Founder and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. RackN is focused on helping customers automate infrastructure. They focus on customer autonomy and self-management, and that's why they're a software company, not a services or as-a-service platform company. Digital Rebar is a platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. RackN's Website; Digial Rebar Follow Rob on Twitter or LinkedIn. Visit his website at robhirschfeld.com. Follow RackN on Twitter, LinkedIn, or YouTube. 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 Rob Hirschfeld, Founder, and CEO of RackN, which develops software to help automate data centers, which they call Digital Rebar. Rob, welcome to the show ROB: Chad, it is a pleasure to be here. Looking forward to the conversation. CHAD: Why don't we start with a little bit more information about what RackN and the Digital Rebar platform actually is. ROB: I would be happy to. RackN is focused on helping customers automate infrastructure. And for us, it's really important that the customers are doing the automation. We're very focused on customer autonomy and self-management. It's why we're a software company, not a services or as a service platform company. But fundamentally, what Digital Rebar does is it is the platform that helps connect all of the different pieces and tools that people use to manage infrastructure into infrastructure pipelines through the seamless multi-component automation across all of the different pieces and parts that have to be run to bring up infrastructure. And we were talking data centers do a lot of on-premises all the way from the bare metal up. But multi-cloud, you name it, we're doing infrastructure at that level. CHAD: So, how agnostic to the actual bare metal are you? ROB: We're very agnostic to the bare metal. The way we look at it is data centers are heterogeneous, diverse places. And that the thing that sometimes blocks companies from being innovative is when they decide, oh, we're going to use this one vendor for this one platform. And that keeps them actually from moving forward. So when we look at data centers, the heterogeneity and sometimes the complexity of that environment is a feature. It's not a bug from that perspective. And so it's always been important to us to be multi-vendor, to do things in a vendor-neutral way to accommodate the quirks and the differences between...and it's not just vendors; it's actually user choice. A lot of companies have a multi-vendor problem (I'm air quoting) that is actually a multi-team problem where teams have chosen to make different choices. TerraForm has no conformance standard built into it. [laughs] And so you might have everybody in your company using TerraForm and Ansible happily but all differently. And that's the problem that we walk into when we walk into a data center challenge. And you can't sweep that under the rug. So we embraced it. CHAD: What kind of companies are your primary customers? ROB: We're very wide-ranging, from the top banks use us and deploy us, telcos, service providers, very large scale service providers use us under the covers, media companies. It really runs the gamut because it's fundamentally for us just about infrastructure. And our largest customers are racing to be the first to deploy. And it's multi-site, but 20,000 machines that they're managing under our Digital Rebar management system. CHAD: It's easy, I think, depending on where you sit and your experiences. The cloud providers today can overshadow the idea that there are even people who still have their own data centers or rent a portion of a data center. In today's ecosystem, what are some of the factors that cause someone to do that who isn't an infrastructure provider themselves? ROB: You know the funny thing about these cloud stories (And we're talking just the day after Amazon had a day-long outage.) is that even the cloud providers don't have you give up operation. You're still responsible for the ops. And for our customers, it's not like they can all just use Lambdas and API gateways. At the end of the day, they're actually doing multi-site distributed operations. And they have these estates that are actually it's more about how do I control distributed infrastructure as much as it is about repatriating. Now, we do a lot to help people repatriate. And they do that because they want more control. Cost savings is a significant component with this. You get into the 1000s of machines, and that's a big deal. Even at hundreds of machines, you can save a lot of money compared to what you get in cloud. And I think people get confused with it being an or choice. It really is an and choice. Our best customers are incredibly savvy cloud users. They want that dynamic, resilient very API-driven environment. And they're looking to bring that throughout the organization. And so those are the ones that get excited when they see what we've done because we spend a lot of time doing infrastructure as code and API-driven infrastructure. That's really what they want. CHAD: Cool. So, how long have you been working on RackN? When did you found it? ROB: [laughs] Oh my goodness. So RackN is seven years old. Digital Rebar, we consider it to be at its fourth generation, but those numbers actually count back before that. They go back to 2009. The founding team was actually at Dell together in the OpenStack heyday and even before the OpenStack heyday. And we were trying to ship clouds from the Dell Factory. And what we found was that every customer had this bespoke data center we've already talked about. And we couldn't write automation that would work customer to customer to customer. And it was driving us nuts. We're a software team, not a hardware team inside of Dell. And the idea that if I fixed something in the delivery or in their data center, and couldn't go back to their data center because it was different than what the next customer needed and the next customer needed, we knew that we would never have a community. It's very much about this community and reuse pattern. There's an interesting story that I picked up from SREcon actually where they were talking about the early days of boilers. This is going back a few centuries ago. But when they first started putting boilers into homes and buildings, there was no pattern, there was no standard. And everybody would basically hire a plumber or a heating architect. Heating architect was a thing. But you'd build a boiler and every one was custom, and every one was different. And no surprise, they blew up a lot, and they caused fires. And buildings were incredibly unsafe because they were working on high-pressure systems with no pattern. And it took regulation and laws and standards. And now nobody even thinks about it. You just take standard parts, and you connect them together in standard ways. And that creates actually a much more innovative system. You wouldn't want every house to be wired uniquely either. And so when we look at the state of automation today, we see it as this pre-industrial pre-standardization process and that companies are actually harmed and harming themselves because they don't have standards, and patterns, and practices that they can just roll and know they work. And so that philosophy started way back in 2009 with the first generation which was called Crowbar. Some of your audience might even remember this from the OpenStack days. It was the first OpenStack installer built around Chef. And it had all sorts of challenges in it, but it showed us the way. And then we iterated up to where Digital Rebar is today. Really fully infrastructure as code, building infrastructure pipelines, and a lot of philosophical pieces we've learned along the way. CHAD: So you were at Dell working on this thing. How did you decide to leave Dell and start something new? ROB: Dell helped me with that decision. [laughs] So the challenge of being a software person inside of Dell especially at the time, Crowbar was open-source which did make it easier for us to say, "Hey, we want to part ways but keep the IP." And the funny thing is there's not a scrap of Crowbar in Digital Rebar except one or two naming conventions that we pulled forward and the nod of the name, that Rebar is a nod to Crowbar. But what happened was Dell when it went private, really did actually double down on the hardware and the more enterprise packaged things. They didn't want to invest in DevOps and that conversation that you need to have with your customers on how they operate, the infrastructure you sold them. And that made Dell not a very good place for me and the team. And so we left Dell, looked at the opportunity to take what we'd been building with Crowbar and then make it into a product. That's been a long journey. CHAD: Now, did you bootstrap, or did you take investment? ROB: We took [laughs] a little bit of investment. We raised some seed funding. Certainly not what was in hindsight was going to be sufficient for us to do it. But we thought at the time that we had something that was much more product-ready for customers than it was. CHAD: And what was the challenge that you found? What was the surprise there that it wasn't as ready as you thought? ROB: So what we've learned in our space specifically...and there are some things that I think apply to everybody, and there are some things that you might be able to throw on the floor and ignore. I was a big fan of Minimum Viable Product. And it turned out that the MVP strategy was not at all workable with customers in data centers. Our product is for people running production data centers. And nobody's going to put in software to run a data center that is MVP. It has to be resilient. It has to be robust. It has to be simple enough that they can understand it and solve some core problems, which is still sort of an MVP idea. But it can't be oops. [laughs] You can't have a lot of oops moments when you're dealing with enterprise infrastructure automation software. It has to work. And importantly, and as a design note, this has been a lesson for us. If it does break, it has to break in very transparent, obvious ways. And I can't emphasize that enough. There's so much that when we build it, we come back and like, was it obvious that it broke? Is it obvious that it broke in a way that you can fix? CHAD: And it's part of the culture too to do detailed post mortems with explanations and be as transparent as possible or at least find the root cause so that you can address it. That's part of the culture of the space too, right? ROB: You'd like to hope so. [laughs] CHAD: Okay. [laughs] In my experience, that's the culture of the space. ROB: You're looking more at a developer experience. But even with a developer, you've got to be in a post mortem or something. And it's like everybody's pointing to the person to the left and the right sort of by human nature. You don't walk into that room assuming that it was your fault, and you should, but that's not how it usually is approached. And what we find in the ops space, and I would tell people to work around this pattern if they can, is that if you're the thing doing the automation, you're always the first cause of the problem. So we run into situations where we're doing a configuration, and we find a vendor bug or a glitch or there's something, and we found it. It's our problem whether we were the cause or not. And that's super hard. I think that people on every side of any type of issue need to look through and figure out what the...the blameless post mortem is a really important piece in all this. At the end of the day, it's always a human system that made a mistake or has something like that. But it's not as simple as the thing that told you the bad news that the messenger was at fault. And there's a system design element to that. That's what we're talking about here is that when you're exposing errors or when something's not behaving the way you expect, our philosophy is to stop. And we've had some very contentious arguments with customers who were like, "Just retry until it fixes itself," or vendors who were like, "Yeah, if you retry that thing three times, [laughs] then it'll magically go away." And we're like, that's not good behavior. Fix the problem. It actually took us years to put a retry element into the tasks so that you can say, yeah, this does need three retries. Just go do it. We've resisted for a long time for this reason. CHAD: So you head out into the market. And did you get initial customers, or was there so much resistance to the product that you had that you struggled to get even first customers? ROB: We had first customers. We had a nice body of code. The problem is actually pretty well understood even by our customers. And so it wasn't hard for them to get a trial going. So we actually had a very profitable customer doing...it was in object storage, public object storage space. And they were installing us. They wanted to move us into all their data centers. But for it to work, we ended up having an engineer who basically did consulting and worked with them for the better part of six months and built a whole bunch of stuff, got it working. They could plug in servers, and everything would set itself up. And they could hit a button and reset all the servers, and they would talk to the switches. It was an amazing amount of automation. But, and this happens a lot, the person we'd been working with was an SRE. And when they went to turn it over to the admins in the ops team, they said, [laughs] "We can't operate. There's too much going on, too complex." And we'd actually recognized...and this is a really serious challenge. It's a challenge now that we're almost five years into the generation that came after that experience. And we recognized there was a problem. And that this wasn't going to create that repeatable experience that we were looking for if it took that much. At the same time, we had been building what is now Digital Rebar in this generation that was a single Golang binary. All the services were bundled into the system. So it listened on different ports but provide all the services, very easy to install, really, really simple. We literally stripped everything back to the basics and restarted. And we had this experience where we sat down with a customer who had...I'm going to take a second and tell the story because this is such a compelling story from a product experience. So we took our first product. We were in a bake-off with another bare metal focus provisioning at the time. And they were in a lab, and they set our stuff up. And they turned it on, and they provisioned. And they set up the competitor, and they turned it on and provisioned. And both products worked. Our product took 20 minutes to go through the cycle and the competitor took 3. And the customer came back and said, "I can't use this. I like your product better. It has more controls with all this stuff." But it took 20 minutes instead of 3. We actually logged into the system, looked at it and we were like, "Well, that's because it recognized that your BIOS was out of date, patched your BIOS, updated the system, checked that it was right, and then rebooted the systems and then continued on its way because it recognized your systems were outdated automatically. And he said, "I didn't want it to do that. I needed it to boot as quickly as possible." And literally, [laughs] we were in the middle of a team retreat. So it's like, the CTO is literally excusing himself on the table to talk to the guy to make this stuff, try and make it right. And he's like, "Well, we've got this new thing. Why don't you install this, what's now Digital Rebar, on the system and repeat the experiment?" And he did and Digital Rebar was even faster than the competitor. And it did exactly just install, booted, and was done. And he came back to the table, and it took 15 minutes to have the whole conversation to make everything work. It was that much of a simpler design. And he sat down and told the story. And I was in the middle of it. I'm just like, "We're going to have to pivot and put everything into the new version," which is what we did. And we just ripped out the complexity. And then over the last couple of years now, we've built the complexity back into the system to do all those additional but much more customer-driven from that perspective. CHAD: How did you make sure that as you were changing your focus, putting all of your energy into the new version that you [laughs] didn't introduce too much risk in that process or didn't take too long? ROB: [laughs] We did take too long and introduced too much risk, and we did run out of money. [laughs] All those things happened. This was a very difficult decision. We thought we could get it done much faster. The challenge of the simpler product was that it was too simple to be enough in customers’ data centers. And so yeah, we almost went out of business in the middle of all this cycle. We had a time where RackN went back down to just the two founders. And at this point, we'd gotten far enough with the product that we knew it was the right thing. And we'd also embedded a degree...with the way we do the UX, we have this split. The UX runs on a hosted system. It doesn't have to but by default, it does. And then we have the back end. So we were very careful about how we collected metrics because you really need to know who's downloading and using your products. And we had enough data from that to realize that we had some very committed early users and early customers, just huge brand names that were playing around. So we knew that we'd gotten this mix right, that we were solving a problem in a unique way. But it was going to take time because big companies don't make decisions quickly. We have a joke. We call it the reorg half-life problem. So the half-life of a reorg in any of our customers is about nine months. And either you're successful inside of that reorg half-life, or you have to be resilient across this reorg half. And so initially, it was taking more than nine months. We had to be able to get the product in play. And once we did, we had some customers who came in with very big checks and let us come back and basically build back up. And we've been adding some really nice names into our customer roster. Unfortunately, it's all private. I can tell you their industries and their scale, but I can't name them. But that engagement helped drive us towards the feature set and the capabilities and building things up along that process. But it was frustrating. And some of them, especially at the time we were open-source, were very happy to say, "No, we are a super big brand name. We don't pay for software." I'm like, "Most profitable, highest valued companies in the world you don't want to pay for this operational software?" And they're like, "No, we don't have to." And that didn't sit very well with us. Very hard, as a starting startup, it was hard. CHAD: At the time, everything you were doing was open source. ROB: So in the Digital Rebar era, we were trying to do Open Core. Digital Rebar itself was open. And then we were trying to hold back the BIOS patches, integrate enterprise single sign-on. So there was a degree of integration pieces that we held back as RackN and then left the core open. So you could use Digital Rebar and run it, which we had actually had a lot of success with people downloading, installing, and running Digital Rebar, not as much success in getting them to pay us for that privilege. CHAD: So, how did you adjust to that reality? ROB: We inverted the license. After we landed a couple of big banks and we had several others and some hyperscalers too who were like, "This is really good software. We love it. We're embedding it in our service, but we're not going to pay you." And then they would show up with bugs and complaints and issues and all sorts of stuff still. And what happened is we started seeing them replicating the closed pieces. The APIs were open. We actually looked at it and listening to our communities, they wanted to see what was in the closed pieces. That was actually operationally important for them to understand how that stuff worked. They never contributed or asked to see anything in the core. And, there's an important and here, and they needed performance improvements in the core that were radically different. So the original open-source stuff went to maybe 500 machines, and then it started to cap out. And we were like, all right, we're going to have to really rewrite the data store mechanisms that go with this. And the team looked at each other and were like, "We're not going to open source that. That's really complex and challenging IP." And so we said the right model for us is going to be to make the core closed and then allow our community and users to see all the things that they are actually using to interact with their environment. And it ends up being a little bit of a filter. There are people who only use open-source software. But those companies also don't necessarily want to pay. When I was an open-source evangelist, this was always a problem. You're pounding on the table saying, "If you're using open-source software, you need to understand who to pay for that service, that software that you're getting. If you're not paying for it, that software is going to go away." In a lot of cases, we're a walking example of that. And it's funny, more of the codebase is open today than it was then. [chuckles] But the challenge is that it's really an open ecosystem now because none of that software is particularly useful without the core to run it and glue everything together. CHAD: Was that a difficult decision to make? Was it controversial? ROB: Incredibly difficult. It was something I spent a lot of time agonizing about. My CTO is much clear-eyed on this. From his perspective, he and the other engineers are blood, sweat, and tears putting this in. And it was very frustrating for them to see it running people's production data centers who told us, and this is I think the key, who just said to us, "You know, we're not going to pay money for that." And so for them, it was very clear-eyed it's their work, their sweat equity, very gut feeling for that. For me, I watched communities with open-source routes, you know, the Kubernetes community. I was in OpenStack. I was on the board for that. And there is definitely a lift that you get from having free software and not having the strings. And I also like the idea that from a support perspective, if you're using open-source software, you could conceivably not care for the vendor that went away. You could find another life for it. But years have gone by and that's not actually a truism that when you are using open-source software if you're getting it from a vendor, you're not necessarily protected from that vendor making decisions for you. CentOS is a great...the whole we're about to hit the CentOS deadlines, which is the Streams, and you can't get other versions. And we now have three versions of CentOS, at least three versions of CentOS with Rocky, and Alma, and CentOs Streams. Those are very challenging decisions for people running enterprise data centers, not that simple. And nobody in our communities is running charity data centers. There's no goodwill charity. I'm running a data center out of the goodness of my heart. [laughs] They are all production systems, enterprise. They're doing real production work. And that's a commercial engagement. It's not a feel-good thing. CHAD: So what did you do in your decision-making process? What pushed you, or what did you come to terms with in order to make that change? ROB: I had to admit I was wrong. [laughter] I had to think back on statements I'd made and the enthusiasm that I'd had and give up some really hard beliefs. Being a CEO or a founder is the same process. So I wish I could say this was the only time [laughs] I had to question, you know, hard-made assumptions, or some core beliefs in what I thought. I've had to get really good at questioning when am I projecting this is the way I want the world to be therefore it will be? That's a CEO skill set and a founder skill set...and when that projection is having you on thin ice. And so you constantly have to make that balance. And this was one of those ones where I'm like, all right, let's do it. And I still wake up some mornings and look at people who are open source only and see how much press they get or how easy it is for them to get mentions and things like that. And I'm like, ah, God, that'd be great. It feels like it's much harder for us because we're commercial to get the amplification. There are conferences that will amplify open-source TerraForm, great example. It gets tons of amplification for being a single vendor project that's really tightly controlled by HashiCorp. But nobody is afraid to go talk about TerraForm and mention TerraForm and do all this stuff, the amazing use of open source by that company. But they could turn it and twist it, and they could change it. It's not a guarantee by any stretch of the imagination. CHAD: Well, one of the things that I've come to terms with, and maybe this is a very positive way of looking at it, instead of that you were wrong, [laughter] is to realize that well, you weren't necessarily wrong. It got you to where you were at that point. But maybe in order to go to the next level, you need to do something different. And that's how I come to terms with some things where I need to change my thinking. ROB: [laughs] I like that. It's good. Sometimes you can look back and be like, yeah, that wasn't the right thing and just own it. But yeah, it does help you to know the path. Part of the reason why I love talking about it with you like this is it's not just Rob was wrong; we're actually walking the path through that decision. And it's easy to imagine us sitting in...we're in a tiny, little shared office listening to calls where...I'll tell you this as a story to make it incredibly concrete because it's exactly how this happened. We were on a call. Everybody was in the room. And we were talking to a major bank saying, "We love your software." We're like, "Great, we're looking forward to working with you," all this stuff. And they're like, "Yeah, we need you to show us how you built this plugin because we want to write our own version of it." CHAD: [chuckles] ROB: We're like, "If you did that, you wouldn't need to buy our software." And they're like, "That's right. We're not going to buy your software." CHAD: Exactly. [laughs] ROB: And we're like, "Well, we won't show you how to use it. Then we won't show you how to do that." And they're like, "Well, okay. We'll figure it out ourselves." And so I'm the cheerful, sunny, positive, sort of managing the call, and I'm not just yelling at them. My CTO is sitting next to me literally tearing his hair. This was literally a tearing his hair out moment. And we hung up the call, and we went on a walk around the neighborhood. And he was just like, "What more do you need to hear for you to understand?" And so it's moments like that. But instead of being like, no, you're wrong, we got to do it this way, I was ready to say, "Okay, what do you think we can do? How do we think we can do it?" And then he left me with a big pile of PR messaging to explain what we're doing, conversations like this. Two years ago when we made this change, almost three, I felt like I was being handed a really hard challenge. As it turns out, it hasn't been as big a deal. The market has changed about how they perceive open source. And for enterprise customers, they're like, "All right, how do we deal with the licensing for this stuff?" And we're like, "You just buy it from us." And they're like, "That's it?" And I'm like, "Yes." And you guarantee every..." "Yes." They're like, "Oh. Well, that's pretty straightforward. I don't have to worry about..." We could go way down an open-source rabbit hole and the consulting pieces and who owns the IP, and I used to deal with all that stuff. Now it's very straightforward. [laughs] Like, "You want to buy and use the software to run your data center?" "Yes, I do." "Great." CHAD: Well, I think this is generally applicable even beyond your specific product but to products in general. It's like, when you're not talking to people who are good customers or who are even going to be your customers who are going to pay for what you want, you can spend a lot of time and energy trying to please them. But you're not going to be successful because they're not going to be your customers no matter what you do. ROB: And that ends up being a bit of a filter with the open-source pieces is that there are customers who were dyed in the wool open source. And this used to be more true actually as the markets moved a lot. We ended up just not talking to many. But they do, they want a lot. They definitely would ask for features or things and additions and help, things like that. And it's hard to say no. Especially as a startup founder, you want to say yes a lot. We try to not say yes to things that we don't...and this puts us at a disadvantage I feel like from a marketing perspective. If we don't do something, we tend to say we don't do it, or we could do it, but it would take whatever. I wish more people in the tech space were as disciplined about this does work, this doesn't work, this is a feature. This is something we're working on. It's not how tech marketing typically works sadly. That's why we focus on self-trials so people can use the product. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So you have the core and then you have the ecosystem. And you also mentioned earlier that it is an actual software package that people are buying and installing in their data center. But then you have the UI which is in the cloud and what's in the data center is reporting up to that. ROB: Well, this is where I'm going to get very technical [laughs] so hang on for a second. We actually use a cross-domain approach. So the way this works...and our UX is written in React. And everything's...boy, there's like three or four things I have to say all at once. So forgive me as I circle. Everything we do at Digital Rebar is API-first, really API only, so the Golang service with an API, which is amazing. It's the right way to do software. So for our UX, it is a React application that can talk to that what we call an endpoint, that Digital Rebar endpoint. And so the UX is designed to talk directly to the Digital Rebar endpoint, and all of the information that it gets comes from that Digital Rebar endpoint. We do not have to relay it. Like, you have to be inside that network to get access to that endpoint. And the UX just talks to it. CHAD: Okay. And so the UX is just being served from your centralized servers, but you're just delivering the React for the JavaScript app. And that is talking to the local APIs. ROB: Right. And so we do use that browser as a bridge. And so when you want to download new content packs...so Digital Rebar is a platform. So you have to download content and automation and pieces into it. The browser is actually your bridge to do that. So the browser can connect to our catalog, pull down our catalog, and then send things into that browser. So it's super handy for that. But yeah, it's fundamentally...it's all behind your firewall software except...and this is where people get confused because you're downloading it from rackn.io. That download or the URL on the browser looks like it's a RackN URL even though all the traffic is network local. CHAD: Do your customers tend to stay up to date? Are they updating to the latest version right away all the time? ROB: [laughs] No, of course not. CHAD: I figured that was the answer. ROB: And we maintain patches on old versions and things like that. I wish they were a little faster. I'm not always sad that they're...I'm actually very glad when we do a release like we did yesterday...And in that release, I don't expect any of our production customers to go patch everything. So in a SaaS, you might actually have to deal with the fact that you've got...and we're back to our heterogeneity story. And this is why it's important that we don't do this. If we were to push that, if we didn't handle every situation for every customer exactly right, there would be chaos. And it would all come back to our team. The way we do it means that we don't have to deal with that. Customers are in control of when they upgrade and when they migrate, except in the UX case. CHAD: So how do you manage that if someone goes to the UI and their local thing is an old version? Are you detecting that and doing things differently? ROB: Yes, one of the decisions we made that I'm really happy with is we embedded feature flags into the API. When you log in, it will pull back. We know what the versions are. But versions are really problematic as a way to determine what's in software, not what's not in software. So instead, we get an array back that has feature flags as we add features into the core. And we've been doing this for years. And it's an amazingly productive process. And so what the UX does is as we add new things into the UX, it will look for those feature flags. And if the feature flag isn't there, it will show you a message that says, "This feature is not available for your endpoint," or show you the thing appropriate without that. And so the UX has gone through years of this process. And so there are literally just places where the UX changes behavior based on what you've installed on your system. And remember, our customers it's multi-site. So our customers do have multiple versions of Digital Rebar installed across there. So this behavior is really important also for them to be able to do it. And it goes back to LaunchDarkly. I was talking to Edith back in the early days of LaunchDarkly and feature flags, and I got really excited about that. And that's why we embedded it into the product. Everybody should do it. It's amazing. CHAD: One of the previous episodes a few ago was with actually the thoughtbot CTO, Joe Ferris. And we're on a project together where it's a different way of working but especially when you need it... so much of what I had done previously was versioned APIs. Maybe that works at a certain scale. But you get to a certain scale of software and way of working and wanting to do continuous deployment and continually update features and all that stuff. And it's a really good way of working when instead you are communicating on the level of feature availability. ROB: And from an ops person's perspective, and this was true with OpenStack, they were adding feature flags down at the metadata for the...it was incredible. They went deep into the versioned API hellscape. It's the only way I can describe it [laughs] because we don't do that. But the thing that that does not help you with is a lot of times the changes that you're looking at from an API perspective are behavior changes, not API changes. Our API over years now has been additive. And as long as you're okay with new objects showing up, new fields showing up in an object, you could go back to four-year-old software, talk to our API, and it would still work just fine. So all your integrations are going to be good, but the behavior might change. And that's what people don't...they're like, oh, I can make my API version, and everything's good. But the behavior that you're putting behind the scenes might be different. You need a way to express that even more than the APIs in my opinion. CHAD: I do think you really see that when you...if you're just building a monolithic web app, it's harder to see. But once you separate your UI from your back end...and where I first hit this was with mobile applications. The problem becomes more obvious to you as a developer I think. ROB: Yes. CHAD: Because you have some people out there who are actually running different versions of your UI too. So your back end is the same for everybody but your UI is different. ROB: [laughs] CHAD: And so you need a back end that can respond to different clients. And a better way to do that rather than versioning your API is to have the clients tell you what they're capable of while they're making the requests and to respond differently. It's much more of a flexible way. ROB: We do track what UX. We have customers who don't want to use that. They don't even want us changing the UX...or actually normal enterprise. And so they will run...the nice thing about a React app is you can just run it. The Digital Rebar can host its UX, and that's perfectly reasonable. We have customers who do that. But every core adds more operational complexity. And then if they don't patch the UX, they can fall behind or not get features. So we see that it's...you're describing a real, you know, the more information you're exchanging between the clients and the servers, the better for you to track what's really going on. CHAD: And I think overall once you can get a little...in my experience, especially people who haven't worked that way, joining the team, it can take a little bit for them to get comfortable with that approach and the flexibility you need to be building into your system. But once people are comfortable with it and the team is comfortable, it really starts to hum. In my experience, a lot of what we've advocated for in terms of the way software should be built and deployed and that kind of thing is it actually makes it so that you can leave that even easier. And you can really be agile because you can roll things out in a very agile way. ROB: So are you thinking like an actual rolling deployment where the deployed software has multiple versions coming through? CHAD: Yep. And you can also have different users seeing different things at different times as well. You can say, "We're going to be doing continual deployment and have code continually deployed." But that doesn't mean that it's part of the release yet, that it's available to users to use. ROB: Yeah, that ability to split and feature flag is a huge deal. CHAD: Yeah. What I'm trying to figure out is does this apply to every project even the small like, this just changes the way you should build software? Or is there a time in a product to start introducing that thing? ROB: I am a big fan of doing it first and fast. There are decisions that we made early that have proven out really well. Feature flags is one of them. We started right away knowing that this would be an important thing for us to do. And same thing with tracking dependencies and being able to say, "I need..." actually, it's helpful because you can write automation that says, "I need this feature in the product." This flag and the product it's not just a version thing. That makes the automation a little bit more portable, easier to maintain. The other thing we did that I really like is all of our objects have documentation embedded in them. So as I write a parameter or an ask or really anything in the system, everything has a documentation field. And so I can write the documentation for that component right there. And then we modified our build scripts so that they will pull in all of that documentation and create an aggregated view. And so the ability to do just-in-time documentation is very, very high. And so I'm a huge fan of that. Because then you have the burden of like, oh, I need to go back and write up a whole bunch of documentation really lessened when you can be like, okay, for this parameter, I can explain its behavior, or I can tell you what it does and know that it's going to show up as part of a documentation set that explains it. That's been something I've been a big fan of in what we build. And not everybody [laughs] is as much a fan. And you can see people writing stuff without particularly crisp documentation behind it. But at least we can go back and add that documentation or lessons learned or things like that. And it's been hugely helpful to have a place to do that. From a design perspective, one other thing I would say that we did that...and you can imagine the conversation. I have a UX usability focus. I'm out selling the product. So for me, it's how does it demo? How does it show? What's that first experience like? And so for me having icons and colors in the UX, in the experience is really important. Because there's a lot of semantic meaning that people get just looking down a list of icons and seeing that they are different colors and different shapes. But from the CTO's perspective, that's window dressing. Who cares? It doesn't have functional purpose. And we're both right. There's a lot of times when to me, both people can be right. So we added that as a metafield into all of our objects. And so we have the functional part of the definition of the API. And then we have these metaobjects that you can add in or meta definitions that you can add in behind the scenes to drive icons and colors. But sometimes UX rendering hints and things like that that from an API perspective, you're like, I don't care, not really an API thing. But from a do I show...this is sensitive information. Do I turn it into a password field? Or should this have a clipboard so I can clipboard icon it, or should I render it in this type of viewer or a plain text viewer? And all that stuff we have a place for. CHAD: And so it's actually being delivered by the API that's saying that. ROB: Correct. CHAD: That's cool. ROB: It's been very helpful. You can imagine the type of stuff we have, and it's easy to influence UX behaviors without asking for UI change. CHAD: Now, are these GraphQL APIs? ROB: No. We looked at doing that. That's probably a whole nother...I might get our CTO on the line for that. CHAD: [laughs] It's a whole nother episode for that. ROB: But we could do that. But we made some decisions that it wasn't going to provide a lot of lift for us in navigation at the moment. It's funny, there's stuff that we think is a really cool idea, but we've learned not to jump on them without having really specific customer use cases or validations. CHAD: Well, like you said, you've got to say no. You've got to make decisions about what is important, and what isn't important now, and what you'll get to later, and that requires discipline. ROB: This may be a way to bring it full circle. If you go back to the stories of every customer having a unique data center, there’s this heterogeneity and multi-vendor pieces that are really important. The unicycle we have to ride for this is we want our customers to have standard operating processes, standard infrastructure pipelines for this and use those and follow that process. Because we know if they do, then they'll keep improving as we improve the pipelines. And they're all unique. So there has to be a way in those infrastructure pipelines to do extensions that allow somebody to say, "I need to make this call here in the middle of this pipeline." And we have ways to do that address those needs. The challenge becomes providing enough opinionated like, this is how you should do things. And it's okay if you have to extend it or change it a little bit or tweak it without it just becoming an open-ended tool where people show up and they're like, "Oh, yeah, I get how to build something." And we have people do this, but they run out of gas in the long journey. They end up writing bespoke workflows. They write their own pipelines; they do their own integrations. And for them, it's very hard to support them. It's very hard to upgrade them. It's very hard for them to survive the reorg, your nine-month reorg windows. And so yeah, there's a balance between go do whatever you want, which you have to enable and do it our way because these processes are going to let your teams collaborate, let you reuse software. And we've actually over time been erring more and more on the side of you really need to do it the way we want you to do; reinforce the infrastructure as code processes. And this is the key, right? I mean, you're coming from a development mindset. You want your tooling to reinforce good behavior, CICD, infrastructure as code, all these things. You need those to be easier to do [laughs] than writing it yourself. And over time, we've been progressing more and more towards the let's make it easier to do it within the opinionated way that we have and less easy to do it within the Wild West pattern. CHAD: Cool. Well, I think with that, we'll start to wrap up. So if people want to find out more, where are some places that they could do that or get in touch with you? ROB: The simplest thing is of course rackn.com is the website. We encourage people to just, if this is interesting, download and try the software. If they have a cloud account, it's super easy to play with it, all things RackN through that. I am very active on Twitter under the handle @zehicle Z-E-H-I-C-L-E. And I'm happy to have conversations around these topics and data center and operations and even the future of cloud and edge computing. So please look me up. I'm excited to have conversations like that. CHAD: Awesome. And you can subscribe to the show and find notes and transcripts 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 @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots

Neal Amrhein is the founder and CEO and Matt Erickson is the CTO of My Goat. My Goat is a subscription mowing service for commercial properties. They use robotic mowers and elegant software tools to make turf care easy, convenient, and affordable. Follow Neal on LinkedIn. Follow Erik on LinkedIn. My Goat Follow MyGoat on Twitter, Facebook, LinkedIn, YouTube, or Instagram. 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 a couple of people from a company with actual robots. It's Neal Amrhein, the founder and CEO, and Matt Erickson, the CTO of My Goat. Gentlemen, thanks for joining me. So tell me more about this idea that you are robot-agnostic? Are you helping people choose the solution that's right for them? Or do you have go-to vendors? NEIL: We do. So my philosophy, having spent a number of years in technology selling hardware and even software solutions, is that one thing that my experience has held is that hardware gets better, faster, and cheaper. And for us to invest in a hardware platform or have customers invest in a hardware platform, I liken it to my early adoption of high-definition televisions where in 2003, I was one of those guys that spent $2,400 on a 42-inch Sony Wega TV. And now you can get a 70-inch with a lot more technology and so forth for about $300 at Costco. So my feeling about hardware is it gets better, faster, cheaper. It's really the software that makes the difference in terms of how you leverage it. So we engage about 6 to 12 different hardware manufacturers that make autonomous robots from robots that are 27 to 35 pounds up to 1,200 pounds and all different variations in between. And then, we extract the communication tools so that we can help our users who are formerly the groundskeepers become technology groundskeepers. And they are now interfacing with the concept of autonomous robots that are mowing commercial properties 24/7, which we would actually call maintaining versus mowing. So we use nighttime, you know, day, night, rain or shine. So that's why we're robot-agnostic and welcome the latest and greatest designers and developers of hardware. We've got some folks that are just totally focused on designing, and developing, and building awesome autonomous robotic mowers with solar panels or great things that are going out there. And we're the software platform that brings it all together. CHAD: I totally get what you're saying about the progress of hardware and wanting to be in the business of creating value on top of that. How do you make sure that you don't take on the business risk of one of the manufacturers just providing the solution that you're providing? NEIL: Chad, we don't look at a business risk if there's a manufacturer that's going and selling autonomous robotic mowers. We welcome that, in fact, because that helps us with the adoption process. The idea of having, you know, Roomba is the de facto vacuum cleaner that goes randomly in your house. But there are half a dozen other hardware devices and opportunities, and they're all selling it. It's really how are you managing that Roomba? Which is also the subscription component of the Netflix part of our business, which is that Roomba may be a shark next year. It may be something else the following year. For our customers, we select the best hardware for their particular property, whether it's a golf course. They may have an autonomous robot that's manufactured by XYZ for the tee box and another one for the fairway, and another one for the greens. They just pay a monthly subscription for access to the software to manage those particular hardware pieces and optimize that hardware. And that's something that Matt will talk a little bit about. But we really have taken the approach that robots are just like cars. They'll sit in your garage 20 hours out of the week, but they're actually effectively useful 168 hours a week. So how do we maximize that and utilize the hardware itself? And that's what our software does. And of course, with that, we share that information with our customers and our users to continue to make it more efficient. CHAD: Thanks, Neil. Matt, what does the software stack actually look like that you're all putting together? MATT: So we got to talk about the technology so Laravel, PHP, MySQL. We host in DigitalOcean. And we have a WordPress front end, but the back end is all Laravel PHP. CHAD: And so it's in the cloud for all the customers? MATT: Yes. CHAD: And then how do you communicate with the fleet? MATT: So we connect through APIs. The hardware generally has an API that can give us status updates at various intervals. So we aggregate that information back. And then, we present a web-based solution dashboard that includes different views. We can get into the different users and how we've tried to meet their needs and drive workflow for them. But at a high level, we've got some graphical dashboards. And we also have some very tactical workflows for the guys. We call them shepherds taking care of our goats on the ground. CHAD: I know that you said it's autonomous, but how do you communicate with the robots when you need to? Is it radio frequency locally, or is it cell phones? MATT: So the robots actually come with…they have both GPS and cellular connectivity. So we have pretty good real-time connectivity with the robots. So we can remotely control them. We can park them, or we can send them back to their charging stations, different features like that. You can adjust cutting height, things like that, remotely. We also use just text messaging, SMS for communicating with shepherds. It's kind of real-time feedback. So yeah, let me dig in a little bit, the autonomous idea of the robot. Yeah, we want them to be autonomous. And we work with our shepherds, groundskeepers so that each of the goats works in a pen, an area defined by that in the ground kind of like an invisible fence dog wire type thing. But basically, we work with the shepherds, and we have this training certification process. But basically, they can get that pen to an area where really what we shoot for about 72 hours of the robot should be able to operate autonomously within that pen for about three and a half days. And then shepherds will be instructed to move that robot to another pen for about three and a half days. Usually, one robot is taking care of…it ends up being about two and a half days. And that's kind of the way the software solution is driving that efficiency of people time as well as robot time. The robots can mow 24/7. They take care of the grass. They maintain it, as Neil mentioned earlier. So it's not throw the robot out once a week kind of thing. You have to change your thinking. A lot of what we deal with when we go to a robot solution over that traditional status quo mowing we really have to help people through that thought process of this is not how it used to be. It works differently. But yep, that's kind of the solution. CHAD: I feel like I need to ask, even though it's going to be a little bit of a tangent. MATT: [laughs] CHAD: How did you arrive at the name of My Goat and take the leap on a quirky name like that? NEIL: Yeah, it's a great question. [laughs] First of all, I think that I first saw one of these robots through a YouTube video about three and a half or four years ago. And you may or may not know this, Chad, but there are about 3 million of these things that have been sold since 1995. So this is not bleeding edge technology in any way, shape, or form. When I saw it on a YouTube video, it just kind of hit me that wow, these things are out there doing their thing day or night, rain or shine. And interestingly enough, the market, I guess the landscape market, the residential side, was somewhere in the neighborhood of $65 to $80 billion that we were targeting and looking at. And as far as the goats, I had talked to some early folks who were marketing folks, and we just settled on Goat. And then we put my on the front end of it. And before we knew it, we had My Goat. And as we've evolved from just a cool robot-centric organization that's using software, we've evolved into an organization that's really teaching shepherds how to become interactive with the goats. And it's taken a life of its own. The blades are called teeth. CHAD: [laughs] NEIL: And those are some of our…of course, the goats need to be brushed. They don't get washed, or they don't get sprayed down with water, but they get brushed. And there's the whole the operating system is the heart and all kinds of stuff that's been going on. CHAD: Well, I feel like with a name like My Goat, if you're not going to commit and carry that branding through to everything, what's the point? [laughter] NEIL: Right. Yes, it has taken a life of its own. And it's interesting. I don't know that it's the most catchy name for a software technology company. But it's certainly gotten some folks' attention, and it's helped. Let's put it this way: our marketing team really enjoys everything about what they can do with it. CHAD: Well, and there's something to having a brand and carrying that through in the naming that causes ideas to resonate with people and makes them special. At the end of the day, you're mowing lawns. And so making it special and communicating that you have something special, I think, is something that people can do regardless of what their product is thinking of ways of doing that. NEIL: Yeah. And I would add that I think the only pushback we've received on the name is probably from some of our high-end golf course users and prospects who don't want to turn their golf course into a goat track, so to speak. CHAD: [laughs] NEIL: But that's probably the extent of it. But overall, it's been well received without a doubt. And as we're focused on the software component of interacting with autonomous robots, our software development mentality and our vision is that it may be the same thing applied to 500 Roombas inside of a million square feet at a fulfillment center for Under Armour. And instead of having 50 people cleaning the floors, you may have five people managing 500. And how do they do that effectively and efficiently? So there's really a business-focused component of the vision that I've had for the business. And that's helped me, along with many others, to get us to where we are. MATT: I'm just going to jump in. You're right; the name sticks and people really adopt to the shepherd mentality. We get a lot of requests for shepherd crooks. [laughs] They all want a shepherd staff. CHAD: So along those lines, when people are considering working with you, what are some of the questions or concerns that they have about a solution? NEIL: Sure. So it's disruptive, Chad. I think I could probably start by saying the traditional way of maintaining or mowing commercial properties is that you have a big guy and a big machine, and how fast does it go? How much noise does it make? How many grass clippings get blown all over the place? You get in, and you get out. And then you start over. So in the state of Tennessee, where we are here, it's about 34 to 36 weeks of mowing a year. In Michigan, it's 17 to 22 weeks, depending on where you are. In South Florida, believe it or not, I know there are only 52 weeks, but they're mowing 56 to 58 times a year. So it's the frequency of going and mowing and blowing, right? CHAD: Mm-hmm. NEIL: We're changing that by saying, why be worried about the weather? Why would you be worried about darkness? Why would you be worried about noise regulations when you can have the grass maintained all the time? So that mentality of maintaining essentially two football fields a week up to three football fields a week with less than 35 minutes of labor. There is nothing in comparison. There's nothing you can compare with the traditional what we call the status quo to make that happen. So the labor efficiency and improvement in labor productivity is just the tip of the iceberg in terms of the cost savings and the financial payback. So because we are so disruptive, a lot of what we do, and a lot of the time we spend, and one of our core values is being educators. So back to your question about manufacturers selling their own proprietary hardware; absolutely, the more the merrier. We welcome. To me, the sign of success and progress is not the small city block that has one gas station but has four gas stations on the corner. It just now means there are cars that are driving around. And so, I embrace that level of competition. I believe iron sharpens iron. And folks who are traditionally in the landscape space who have made trimmers and blowers and chainsaws are now finding a little bit of competition with folks who are now solely focused on making unbelievably efficient autonomous robotic mowers, or cleaners, or robots in general, which is, again, we're not crashing giant robots although that's the name of your podcast. [laughter] We're not trying to crash them or break them. But it is certainly the foundation for where we are. MATT: Hey, Neil, you've got a good analogy. I think analogies help explain concepts. So you want to run through your airport analogy with the runways and the different airlines? NEIL: Yeah, I could share that with you. Thanks for reminding me. So my philosophy about…we sell subscriptions that are based upon a geography, Chad. CHAD: Size of geography, you mean? NEIL: Yeah, the size of the geography. So it's about a football field, give or take. Based upon some limitations with technology, we put invisible dog fences in the ground, and we charge our users, our subscribers by the particular pen or the number of pens, and then there's a ratio. So much like in an airport, we're not selling flights; we're selling runways. And those runways are accessible by all kinds of…you may have 30 terminals at the gates, and you may have five different airlines. And each of those airlines has a different brand and name, but they're using multiple hardware components. Those jets are maybe McDonnell Douglas, or maybe they're a Boeing or whatever it may be. All of that is fine by us. What we do is we have the software that runs the gates, the terminals. So you have Southwest in terminal two and Delta in terminal 32. And they're using our software to figure out how to get the baggage on the planes and get those planes off the ground so they can make money for their businesses. So we look at it that way. And that's kind of where our IP rests is in that spot in that place. And, again, there'll be other airlines, whether it's Allegiant or whomever buying more Boeing planes. But ultimately, they'll all need a runway, and the software that manages the process and the workflow is what we're focused on. CHAD: So, is the total cost of ownership of autonomous solution typically lower than what they are doing today? NEIL: It is, specifically, the labor improvement is generally about 3x in terms of improving the efficiency of the labor. So if you talk about an average groundskeeper who may be responsible for mowing, if it's a perfect day outside mowing nine acres a day and they are out there five days a week, they may have efficiencies of maybe up to 40 or 45 acres a week. With our solution, that is increased to about 135 to 145 acres a week where they can maintain about 70 mowers, 70 autonomous robotic mowers, or 70 goats as we call them. They'll herd 70 goats with the same full-time employee. So that's one aspect. With that, the immediate reaction is, well, you're eliminating jobs. We're actually redeploying jobs. I'm a builder. I'm a job creator. I've had 4,800 folks work for me in my home care business over the last 12 years. And so, I'm a big believer in improving and deploying folks in areas that we don't have robots. So, for example, there's no robot right now that's pruning trees or making up a sand trap, robots that are planting flowers or putting mulch in a flower bed. So those kinds of jobs are still out there. We're just making the traditional idea of throwing somebody on a mower in the middle of a cemetery or golf course or open space and having them manage that through our software platform sitting in their F150 pushing start and stop or pause and doing other things. CHAD: Instead of riding on the mower. NEIL: You got it. MATT: A lot of our potential customers come to us because (we kind of touched on that) there's a labor shortage. It's hard for folks to find people that want to ride zero-turns. So to Neil's point, we're not about deploying robots, kind of one for one replacing jobs. It's basically we're taking the labor force that we can get, that we have, and we're retraining them to be more efficient through these robots. Pretty age-old story when you're talking about industrialization. But the idea is we haven't displaced workers. They're not hiring fewer people. They're taking everybody they can get. And they're doing all of that value add. The groundskeepers now have time to go out and do the mulching and the landscaping, trimming, improving the property. A lot of these groundskeepers have a lot of pride in their property. And they would rather be doing the items that to them are a value add and beautification projects rather than just riding a Back 40 or a zero-turn. We had one shepherd say, hey, it's really helped his back. Riding a lawnmower is kind of rough. And walking around every now and then helping out a robot is a whole lot easier of a physical life for you. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So I saw on the website because of the kind of solution and the scale that it's at, it seems like you have a few different key customer bases. You want to talk about that and whether you knew that going in, or did you find them along the way? NEIL: Yeah, that's a great question. So we came out of the gate initially with early investors. We were focused on what we considered was the low-hanging fruit in the residential space. So we had designed and developed the operational and financial template to actually have shepherds who were employees of My Goat. And we would have the Goats sold in a subscription model to residential customers. And then we'd have the goat stay on a property and then get moved, et cetera. But we learned very quickly that business to consumer and residential customers it's not that impossible; it just was not as low-hanging fruit as we had thought initially because folks leave rakes in the yard. And anytime a goat comes upon a rake, it's going to get trapped, and therefore it needs to be rescued. And you have to send a shepherd out, et cetera. Or somebody decides to put a new vegetable garden, and they break the wire that's in the ground. They're just a bunch of…, or there's a dog chasing the robot or a little kid out there, or somebody stops it. So those required a lot of…it didn't make the robot autonomous. So we pivoted in late 2019, early 2020 into the commercial space. We expired all of our subscriptions to residential customers and went completely into the commercial space. And we had had some success with some golf courses and some cemeteries. And we've gained a lot more momentum now with cities and counties, regional airports. But large open areas that are a minimum of five acres, typically we would run a pilot or a preview with at least 12 to 14 acres. But the biggest restriction, of course, when you get into those large open areas is electricity because they've been traditionally maintained or mowed by gas-powered machines. So back to your other question about where the savings is and the payback period, and how we have an immediate impact. There's an operational savings that is pretty quick in terms of the return because we flatten out a lot of the ups and downs that a traditional landscaper has. So let's take a golf course, for example. The average golf course spends about $80,000 per hole per year and depending on the course, 45% to 60% of that is spent on mowing, mowing machines, and people involved. And we're able to take that, and they're hiring temporary people in March here in the south, and they have them here until October. So they're having to go through that cycle every single year. So if they can flatten that operational expense out by redesigning the golf course and having…and maybe it's not 100%. Much like a Roomba, you still have to get the corners and the edges, maybe with a broom if it doesn't get into every nook and cranny. So it's not a 100% solution. It's not for every application. But as we moved into the commercial space, we found a greater payback period not only on the cost of the gasoline is...you know, take a zero-turn mower. And again, I say that's probably our greatest competitor is institutionalized thinking to say, this year we're going to buy a big green, big red, or big orange machine for $16,000 or $18,000, Kubota, Toro, or John Deere. And we're going to do the same thing we did last year. We're going to find a guy who can operate it. We're going to put gas in it, and we're going to run it around. Well, you put hours in those things, and they're very costly to maintain if you hit a root. So you've got to make sure that you can't run a 1,800-pound mower when it's been raining for three days. So what do you do with a fairway when it's soggy or any other commercial area that could be…or a hill that could be dangerous. So we've found a lot of application and then, of course, the environmental part of it, Chad. So the average zero-turn emits the equivalent of a carbon footprint every hour it's running about 300 miles of a Toyota Camry running. So they haven't become more efficient. And then you've got noise regulations and so forth in a lot of communities. And even in California, they're moving in the direction of I think it's 2024 where gas-powered and oil-powered landscaping blowers and tremors, et cetera, are not going to be allowed, or you'll be fined for using them. So that's the third component of where My Goat has seen some opportunities in the commercial space. CHAD: You mentioned that they can run at night. So they must be quiet. They must be. NEIL: Yes, they are. And it's not the traditional…you're not making as much of a mess. Some of our cemetery customers have mentioned that the fact that their trimming has been reduced by up to 50% because they're going up and over markers because they only weigh 27 pounds. They're mostly plastic and rubber. They're not doing any damage to vases. So they're having a cost reduction in that regard but also with the uprights. Folks have their family members in a particular private estate area where they may have an upright, and if you have a zero-turn mower out there throwing and splashing grass clippings, you're likely having to go out there again with more labor and take a blower and clean up the mess that the mower made. So these little small operational components along with the experience. Again, back to the cemetery, you're asking about why we're there. We know that industry very well. And we know that the experience that loved ones want to have when they're out there celebrating life and grieving across a 40 or 50-acre property. They don't want to hear a zero-turn. So you're turning those things off three or four times a day for those services, and you're having that individual parked a quarter-mile away. No longer is that an operational challenge or a concern because all of these robots are being controlled, start, stopped, and programmed through our software. CHAD: That's really cool. So you mentioned investors and the early pivot away from residential to commercial. What does your funding story look like? And what phase did you get to when you took on investment? And let's start there. How did you find your initial investors? And what phase were you at when you did that? NEIL: Yeah, that's a great question. So we went through the traditional friends and family and moved into an angel round, but really I started my first company…bootstrapped it. And so, I wasn't really proficient in raising money in the traditional sense. I had an idea, put a business plan together. And I talked to a couple of folks and just told the story. To be honest with you, Chad, I wasn't really asking for money. I was more or less asking for advice. And then a number of folks were like, "Are you taking money? I'd like to take an equity position." And so, we structured the business and the shares on a pre-revenue valuation. And then, within 14 months, we were able to double that valuation. And we're now opening a new round here and a Series A with a valuation that's nearly five times our initial valuation. So we're making a lot of progress because we have, again, it's an annual recurring revenue stream. It's a subscription model. And what we did with our investors in the early rounds is many of them came on, and they just wanted to be silent. They were not interested in having an opinion. They wanted me and my team to run it. So that's been very helpful. So that's where we are in 2022. We'll be opening and closing a Series A. And I certainly can get more specific with others about that if your listeners or audience are interested. CHAD: So when you think about a Series A, what will you be using that for? What are your next scaling goals? NEIL: My commitment to my investors in the previous two rounds has been to sales and technology, so sales, business development, and technology enhancement to the software, so hiring more developers, scaling that team. Matt's leading the vision, and we've got a number of other folks who are involved in the user experience. But again, because we're a software company, it starts with a demonstration that's usually 15 or 20 minutes that can be scheduled through our website at mygoat.co. And it goes from there. On the sales side and business development is telling the story. In those verticals, we're interested in building out potentially even reseller markets with other industries that are aligned with us. We've had some very high-level conversations with folks that sell electricity for a living. The Tennessee Valley Authority we became an early preferred partner with them and because they have carbon credit that they can offer and sell to their customers, their local power companies. And they're in the business of selling power. And we're in the business of providing subscriptions that require power. CHAD: What are some barriers to continuing to scale? Do you have geographic barriers? NEIL: I have self-imposed geographic barriers, [laughter] So it's a Neil Amrhein barrier. But overall, our barriers, our challenges really are; I’ve never heard of these things before. Do they actually mow? So we get through those conversations fairly quickly. But depending on who we're talking to, it also becomes a fear. People fear change and especially things that are disruptive. So our barriers, once we get through the fear, is we don't have any electricity here on this golf course, or this city park, or this regional airport that there is unlimited electricity. So we can pull whatever electricity is necessary there. So it is really the barriers of education, just like anything that's truly disruptive in an industry that's been doing the same thing for 45 or 50 years. CHAD: So you already talked about how you view potential competition from manufacturers, but how do you view competition in general? Is there other competition out there? NEIL: The biggest competition we have is institutionalized thinking, which is doing the same thing we did last year. So that's a battle that we have every day. I like competition because I think it makes the end product, and the customer is the one who benefits the most from having lots of people in the market no matter what their angle is. We like our position because, again, we're not the hardware manufacturer. We're able to work with others. We're the financial advisor that gets to work with the insurance guy and everybody else, where all your money is with your college buddy who's managing it, et cetera. We're agnostic. We're putting it all together. So it benefits everybody. And those who make and manufacture these robots get the benefit as well because it's part of the subscription process as far as that's concerned. But the more, the merrier. A lot of people come to me and say, "Well, I saw an autonomous robotic mower out on this lawn or in the neighborhood here." And that's good for us. CHAD: Matt, I assume that being robot-agnostic means that you need to integrate with the different systems. Does that have challenges? MATT: You know, not really. Robots are, as far as the autonomous robotic lawn mowers, they're pretty much telling us the same thing. There are status updates; there are battery updates; there are GPS coordinates. It does tend to be a pretty common data set that we're seeing. So it's been a lot easier than I thought. When you think about…data integrations are always the top challenge you have. It's worked out a lot better than we thought initially. CHAD: Well, that's great. Has there been anything surprising the other way which was something you thought was going to be easy turned out to be a lot harder? MATT: Yeah. We've had a manufacturer that actually had a tiered concept in their data availability. They weren't giving us all of the data that they had. They were saving it because they were running their own kind of hey, you can use home automation techniques to integrate with your residential autonomous robotic lawnmower. Hey, if it's raining at your house, we could park your robot. So they were kind of hiding some of the API from us. We were able to work through that. But I think that goes to one of your questions about concern around competition from the manufacturers. They're really not looking at this from that niche that we're hitting, that commercial perspective. Maintaining one Roomba in your house is the analogy I use. You kind of know where he gets stuck, and you go find him. And that's okay. You don't need a lot of software for that. But that analogy Neil mentioned, if you have 500 of these guys running around a warehouse, or for us, we have property with 50 robots on. How do you know which one right now -- CHAD: And the space that that takes up. MATT: Right. Right. CHAD: You can't see them all necessarily even. MATT: [laughs] Exactly. You can't. You can't just walk around and see everyone and visually check. You need that software to be efficient to know; oh, there are three things I need to do today with the robots. Let me plan that out, and let me take care of it. So I think, like Neil said, the manufacturers out there they're making lawn equipment. They're making lots of different hardware. And to them, fleet management is really where is my hardware right now? [laughs] That's the extent of it. And they can't think about a property that needs maybe two or three different manufacturers of hardware because properties are not one homogeneous set of type of grass. There are always different needs, different features on that property. So there's always that idea that we're going to need a couple of different manufacturers, maybe. So, yeah, it's really interesting. For me, I think it's we're really hitting a home run in an area that there really aren't any other competitors exactly in our niche. And if there are, I think the industry for us what we do is at a place where we need more adoption out there in the world. [crosstalk 34:03] CHAD: Do you ever hear from early adopters? People who say they've either already bought autonomous mowers and they're struggling to manage them, or they really want to, and they're coming to you to do it? NEIL: That's a great point. I have a couple of thoughts here because you guys are going in a lot of different directions here. MATT: [laughs] NEIL: Chad, the short answer is when people buy anything early on, they're going to have the proverbial challenges of who supports it when it breaks? Who do I call? What happens next? It just goes on and on and on, whether it's a hardware platform, and that's mostly the case, or it's something else. It's what does that support look like? So the early adopters when we talk about their experiences, and this is one of the things I would say is probably our biggest challenge is that we have created a learning management software platform, a video library of how do you work with robots? We know that they're going to get trapped. There is no doubt that a 27-pound autonomous goat if there is a lightning strike like there was here in Nashville last night, they're going to be tree limbs that are down. And there'll be goats that are trapped. And it's going to take a human being, a shepherd, to be notified via SMS alert to proactively go to that spot on that property across 50 or 100 acres and rescue that goat. And it's just a matter of these kinds of things happen environmentally. So we talk about, when we talk to customers, about their utilization of the goat. And we talk about optimizing their property. It's not really that the goat doesn't graze or the robot doesn't work. It's what are the restrictions and the environmental challenges that are in front of it? If there are erosion issues around a marker or in a large open field, and if it's a really well-groomed practice field or intramural field, it's likely going to be aerated. It's going to be very flat, et cetera. But most commercial properties are not that way. So the goats actually have a tendency to go out, and they're going to find all those environmental challenges. And it requires a human being to go out there and fix them. Because if the environmental challenge is that there's a hole and on a horse farm, it's going to be there until somebody throws some dirt in it. It's just the reality. And that goat is going to find that environmental challenge every single time. So there is a learning curve that goes with it. There's a level of patience. And I think you mentioned what's our challenge? Our challenge is letting folks know that it's an evolution, not a revolution, as far as what your property is going to look like. I spent a number of years at the Ritz Carlton Hotel Company, and we talk about property health as is it a two-star property, a three-star property, four-star property, five-star property? We recognize that a lot of commercial properties are going to just be a two-star. But potentially, they could be a three-star property. Or if it's a cemetery and you've got a goat that's maybe found environmental challenges on a cemetery, it also becomes a liability or risk for family members who go visit their loved ones. So now we're using the robot proactively to improve the status of the property as opposed to saying, well, it just gets trapped every time it finds a hole or every time there's a situation that goes on. So it does require an active level of engagement and maintenance. And the philosophy has to be changed so that groundskeepers are now checking their phones or being alerted at 7:15 in the morning. And they may go rescue Billy, the goat, because a lot of folks name their robots. [laughter] They're going out there, and they're in pen 34,27, 31. And then at lunchtime, they may have another two or three of the same goats that were trapped, need to be rescued, and then again at 4:00 o'clock in the afternoon. So it's a maintenance mentality as opposed to a mow and go mentality. So that is philosophically a big change in terms of their mindset. CHAD: So what's next for My Goat then? You mentioned the Series A. Is there anything in particular on your radar that you're either worried about or are looking forward to? NEIL: Looking forward to more folks like your audience and listeners hearing our story. I'm in the business of telling our story. And I welcome, again, the competition because that means there's validation for what's going on. I don't think we're going to stuff this genie back in the bottle, so to speak. It's going to be hard for me to believe that five, six years from now, folks are going to be out there firing up a push mower that they just bought at Lowe's when they can buy something at Lowe's that's $250 for a residential robot that they get to use. Same thing on the commercial space. I don't know what it ultimately looks like from a vision perspective. But I think our challenge is continuing the messaging, the adoption, enhancing the payback period. It is really just like any good technology, artificial intelligence, robotics, et cetera. I mean, that combination. I hold the position, Chad, that I don't really think any technology is being developed or new per se since the invention of the internet. It's the application of the technology. It's what are people doing that they weren't doing before? We have the communication tools with 5G or what have you that we didn't have five or six years ago that we can now ping our goats every 15 minutes and find out what their status is. And then we can report that back to the user and say, "Hey, your optimization or utilization on your hardware and your subscription is X, Y, and Z. And your return on investment is six months to 16 months." That's where I think it elevates the conversation of efficiency and changes the game. So our next steps are continuing to get the message out, embrace not only users but industries we haven't thought about. I mentioned horse farms that just came on my radar screen not too long ago. We've had some success with cities and counties. You can imagine…everything one of our core values is green is good, and time is a number. So you just drive down the interstate, and you can see so much green everywhere as far as opportunities ahead. And there's plenty of room for lots of people to play in this space. We welcome more and more of probably the designers and developers that you got on this podcast to come up with the latest and greatest hardware and make those APIs available for Matt and his team to integrate and continue to grow. CHAD: That's great. If folks want to reach out to you to either learn more or see if you can work together, where are the best places for them to do that? NEIL: Sure. Let me first direct them to www.mygoat.co. And there are a series of areas there where it's either click on a demo now or information. Our phone number is listed there as well. I'll also give you my email address, which is Neil, N-E-I-L neil@mygoat.co, so neil@mygoat.co. And Matt's is just matt@mygoat.co as well. And those are probably the fastest way to connect with us. And if they put in a quick subject line your name and your podcast, it'll bubble everybody to the top a little faster. CHAD: Wonderful. Thank you both for joining me. I really appreciate it. MATT: Absolutely. Thank you, Chad. NEIL: Thank you for having us. CHAD: And I wish you all the best. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time. Announcer: This podcast was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guests: Matthew Erickson and Neal Amrhein.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots

Joe Ferris is thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Mission Control is our newest team doing DevOps Support, Maintenance, and SRE (Site Reliability Engineering). The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, is to support those teams and support other client teams in deploying and scaling applications. They have an on-call team and do more complex cloud build-outs with the goal being to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own. Follow Joe on Twitter or LinkedIn. thoughtbot's Mission Control team 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 Joe Ferris, thoughtbot's CTO and Managing Director of the thoughtbot DevOps and maintenance team known as Mission Control. Joe, welcome back to the show. JOE: Thanks, Chad. It's been a while. CHAD: It has been a while. I think you were the first-ever guest, if I'm not mistaken. JOE: I believe that's right. We talked about null, I think. [laughter] CHAD: Yeah. And it would have been with Ben back when I was just a listener and maybe producer. So welcome back to the show. It's been a long time, and a lot has changed at thoughtbot over the years. I've been talking to each of the managing directors of the new teams, and I wanted to be sure to have you on. Why don't we take a little bit of a step back and talk about Mission Control? When we say DevOps and maintenance, what do we mean? And what does Mission Control do? JOE: Sure. Mission Control is our newest team doing DevOps support, and maintenance, and SRE. It came out of our experiments with DevOps a while ago now, almost two years coming up. Historically, thoughtbot has shied away from getting too much into DevOps. I think a lot of us had some unpleasant experiences earlier in our career around sysadmin tasks and expectations there. Not a lot of people have wanted to be on call historically. So we've heavily leveraged services like Heroku that take a lot of that burden away from you and avoided doing things like direct to AWS deployments or getting too involved with CI/CD pipelines that were particularly complex. But we've had clients over the years that have requested more interesting or more difficult deployments. And finally, we had one a couple of years ago, where we said, "All alright, let's just handle this instead of saying no or trying to outsource it." We thought it made sense for them. And after going through it, we came to the conclusion that it was actually pretty good that the ecosystem had evolved a lot and that it was a service worth offering. That began our journey into DevOps, so to speak. So we did some smart DevOps work for a variety of clients over the next year or so before we decided to form an official team doing this new kind of work, which is how we ended up with Mission control. The goal of Mission Control, rather than building products or pairing with team members to improve their team like the rest of thoughtbot, the goal of Mission Control is to support those teams and support other client teams in deploying and scaling their applications. And we have an on-call team. We will do more complex cloud build-outs. And our goal is to empower and educate the teams that we work with so that they are more capable of working in those ecosystems on their own. CHAD: You used the acronym SRE earlier in that little spiel. I'm not sure that everyone knows what that is. [laughs] So it stands for Site Reliability Engineer, right? JOE: That's right. And that's been newer for us. So DevOps is supposed to be the fusion of development and operations. But the operations world is really big. So similar to how everybody has problems getting people to be full-stack enough given the complexity of front end and back end, we have similar problems in design. We also have that problem in DevOps where both development and operations are huge, rich ecosystems. And so, having developers that are fully experienced at both is hard. So the path of least resistance, when you say are doing DevOps, is definitely just to do operations. And it's been a struggle for us to actually break down those silos and have teams work more on the operation side on their own. So one of the things that caught our eye with SRE was some of the built-in mechanisms for engaging with the team. The one-sentence pitch for SRE is that it is operations if you approach it like a software problem. It has these concepts of SLOs, Service Level Objectives, and error budgets, which is the amount of time you spent violating your SLO. And part of the process is getting buy-in from the entire team, from the stakeholders down to the developers and the operations team. And so, it provides a natural interaction point between the operations folks and the rest of the team because nobody wants to break the error budget. Once the error budget is exhausted, everybody has to stop building new features and focus on stability until the error budget is cut up again. So rather than having this unpleasant give or take where we're more coming from the operations side, and we're always pushing for more stability, and everybody else is coming from the product side, and they're always pushing for more features, SRE gives you this useful metric to have that conversation around where we're not always just pushing for more. We're trying to hit a specific goal that we've agreed on. And when we hit the goal, we know that we can keep full throttle moving out new features. CHAD: Now, is the SRE a developer who is also working on resolving errors before the budget is hit? JOE: Yeah, a Site Reliability Engineer is a developer. But that's actually not too different from other forms of DevOps. DevOps is supposed to be developers in general. When I say we built an operations team, even if you look at the work that we're doing, a lot of it is development work. We build scripts, and automations, and so on. We don't manually set up EC2 instances, and not everything is toil, even outside of SRE. But the idea in SRE is that somebody will be more integrated with the development team and make changes to not just the operational stack but also the development stack in service of reliability. I've heard it said that SRE is a particular implementation of DevOps. That makes sense to me. CHAD: Let's start back in the beginning because you made reference to the fact that historically, a lot of what we deploy was deployed to Heroku. And we did that because, for a lot of the applications that we're building, it made sense. It minimized the operational overhead of deployments. There is a point in some systems that you cross a line. Where do we see that line typically being where you need to start looking at something else? JOE: I think there can be a few different instigating factors. One of the fastest ways for somebody to want to move to AWS is if they have significant security concerns, particularly for healthcare applications. The security model is more straightforward in AWS to have better isolation. There are options on Heroku, but it requires going to a different Heroku platform using Shield. And you just don't get the same power you get in terms of network isolation models you get on AWS with your own VPC. So if you're already at the point where you want to start out with a VPC out of the gate and do that kind of isolation, my opinion is you may as well own it and go to AWS. So that's one reason. Another is if you start hitting scaling issues, Heroku is easier for the developers because it's simple and it's very streamlined. But doing complex deployments is difficult, which eliminates some of the options available to somebody doing something like SRE. So to give one example, one mechanism people can use to make it safer to deploy without potentially introducing bugs or performance degradations is a canary release where when you release, you put the new version out as the canary build. And you route maybe 5% of traffic to that, and you actually collect metrics on performance and error rates on the canary traffic versus the regular traffic. And then you have some period where you're in experiment mode, which varies depending on the level of stability you're looking to achieve. Once you're confident that the canary release didn't introduce a regression, then it gets promoted to the stable build, and you do that every time you deploy. I have no idea how you would do that on Heroku. CHAD: I think you'd have to do it at the application level. You'd have to do it with a feature flag system. And it would only be possible to do some of the things that you would be able to do if you're able to do the whole system. JOE: Right. And I guess you could do weighted random numbers to try and decide whether to canary or not. But one of the benefits of doing it outside the application is there's no way to make a mistake. So, for example, if you introduced a bug in your canary mechanism in the application or you forget to put it behind a feature flag, then you've now deployed to production, and you have an error. Whereas if it's managed by the CI/CD pipeline, you're just deploying a new version of the application. In Heroku land, that would mean you deploy the new slug as a canary build. In most other areas, it means you're deploying a container image. That's one example of why if you get to the point that you have a lot of traffic in production and you need to manage that traffic while continuing to release features, it can be helpful to work on a platform like AWS where you have a lot more deployment options. Another one is that SRE is heavily built on observability and metrics, which can be difficult to collect on Heroku. Some of that is just a matter of lineage. Like, the SRE community was built up around tools like Prometheus that are scrape-based. That means you need to have a special metrics endpoint exposed on all of your containers. In Heroku, there isn't a way to access any of your dynos directly except through the web router, and you can't control which one you get. So using Prometheus on Heroku is not really practical, which means you need to re-implement what everybody else has built for SRE using a different observability tool. And observability out of the box on Heroku it's easy to get set up, but it's more limited. So doing something like complex SLOs and setting up error budget dashboards and alerting is going to be a significant task. Versus on a platform like Kubernetes where it doesn't sound like it'll be easier, but it is because there are open-source tools that you can just deploy. CHAD: You mentioned Kubernetes. It's probably worth calling out that that's pretty much what we are using across the board, right? JOE: For our AWS and other cloud deployments, we have standardized largely on Kubernetes. We started out using simpler containerization platforms like ECS on AWS. But what we found is that the developer tooling is generally not particularly good because there's not enough community momentum behind any of those. And the open-source is limited versus something like Kubernetes there's a massive open-source community. There is a ton of different tooling that people build that's available for developers and for DevOps. And for these things like SRE, you can use almost entirely open-source software to build out all of the interesting parts of that and deploy that. So what we've been building is basically an SRE Platform as a Service where we collect these open-source components. We deploy them to a managed Kubernetes cluster. And then, applications can immediately start exposing metrics to Prometheus and defining SLOs. CHAD: So much in the same way where we talked about some of the boundaries where it starts to make sense to not be on Heroku, what are some of the boundaries that teams hit where it makes sense to start thinking about SRE or even just having someone on the team that's focused on that kind of work? JOE: I think as soon as people start hitting their first scaling challenges. So for an MVP where you're validating a product where you don't actually have production traffic yet, I don't think it makes sense. And I also think I would avoid deploying to something like Kubernetes if you can help it for an MVP. But for anybody who has scaling concerns, SRE is a very useful mindset. And the sooner you start adopting it, the sooner you'll start to build an application that's made to scale. It can be very difficult to put out those fires while something is not on a platform where you have many options, and nobody has been thinking about observability. It means that you need to be guessing at how to put out the fire as well as simultaneously introducing metrics and potentially planning a cloud migration. So I think as soon as you start feeling nervous about deploying to production or as soon as you notice that you're spending a lot of time working on performance, it makes sense to bring in SRE. I also think anybody that needs to provide an SLA should for sure implement SRE. It can be used to measure whether or not you're on track to hit an SLA because you basically set SLOs that are stricter than your SLA, and you make sure that you meet it. CHAD: Is there a way that existing teams can layer on some of the SRE activities without having full-time SRE people? JOE: I think you can have a team member who does development that also acts as the SRE. If you have a small team, I could see the commitment to it being daunting. I think that could be one good reason to bring in outside specialists if you're not at the point where you can afford to have a full-time SRE in-house. Working with a team that can provide an SRE on-demand like Mission Control could be valuable. CHAD: I didn't realize that that was going to be a perfect segue into part of the value proposition of Mission Control [laughter] when I asked the question. But I guess that's a really good point. That is part of what we're helping people do is monthly contracts that provide this to them, even if their team can't do it 100% of the time. JOE: Right, except for pretty large teams. I don't think it makes sense for them to hire a full-time SRE. It's much easier to work with a team like ours that has the experience and has more than one person. Even if you do hire a full-time SRE, you will only have one. So if they go on vacation, or if they get sick, or if it's in the middle of the night, then do you still have an SRE? I think that's one of the benefits of working with a team. CHAD: And that's been interesting with Mission Control because we introduced Mission Control and made it a formal thing at the same time as going entirely remote. And it's interesting how doing that freed us up in terms of being able to commit to building a different kind of team. It doesn't necessarily need to be on call after hours if we're going to have an entirely remote team. We can have people on that team that span different time zones. And so, from a thoughtbot perspective, it's interesting how those things went hand in hand for us. JOE: Yes, it's been immensely helpful for Mission Control, in particular, to be fully remote. There are a lot of options that wouldn't have been available to us if we were a U.S.-centric team. It's been really interesting. I've built out development teams before that were focused on a location. And it's been really interesting to build out this team with a focus on availability and distribution. For example, one thing that has helped us is having somebody in South America because they don't celebrate U.S. holidays. So even discounting time zones, which are a challenge when you're trying to provide around-the-clock availability, just having that kind of diversity in holiday schedules really helps. So we've been able to build it totally differently than we would have if we were trying to put a bunch of people in an office. And I think it's made it possible for us to have much better coverage with a much smaller team. Mid-roll Ad I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one-on-one with a small group of agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. CHAD: So Mission Control I introduced it as maintenance and DevOps. So we're also helping people with different kinds of things beyond operations, right? JOE: Yeah, particularly with SRE, there's a focus on stability and scaling. And we're also helping people with CI/CD. One of the focuses for us this quarter has been helping people develop CI/CD pipelines that provide safer deploys and providing guidance and a system for developers to implement things like feature flags and beta flags. Because one of the challenges of making performance improvements is that you don't actually know if you've solved the problem until it's deployed, and deploying something that changes performance is inherently risky. And so, in addition to helping people actually make the performance improvements, we have to demonstrate the process for deploying and testing those improvements. CHAD: I've worked on fairly big systems in the past. But there have been a couple of different instances over the last maybe year where we've approached the problem in a different way than we have in the past, which has been really interesting to me from a development standpoint. It's the idea of…if you remember, for the food delivery application, we had that conversation about the different ways to build APIs rather than versioning APIs explicitly. And that has been a different approach than the way I would have done things in the past. And it's been a really powerful approach. So, can we talk a little bit more about that approach? JOE: Sure. CHAD: Well, specifically, so we have mobile applications that use a back-end API, and not everyone updates their mobile application at the same time instantly. You have bugs basically in the wild that you are fixing or that you're changing in your API, or if you're just introducing API changes. And so the idea of instead of explicitly versioning API on the server-side and having clients write to a specific API, instead building much more flexible APIs, in particular, having the client tell you what version of the API that they're expecting but through consolidated API endpoints so that the server is much more in control of the behavior than the client being in control of the behavior. JOE: Yeah, I think the two big changes that were helpful on that project were using GraphQL for some of the APIs, which provides more flexibility generally than a typical REST API and the minimum version requirement. So the application sends the version of the application. And the API will tell the client they have to upgrade if it's a version that isn't compatible with the newer APIs. So when we do have to break backwards compatibility, we force an app upgrade. CHAD: But in general, you're taking the approach not to break backward compatibility. And you're meeting the client where it's at whenever possible and maintaining backward compatibility in the APIs. JOE: That's something that we have been teaching developers about generally is backwards and forwards compatibility. We do that with deployments as well. For some of the larger deployments we have where there might be dozens of containers running for a service, it certainly doesn't make sense to stop them all and start new ones because the app would be down for a long time. And it would take too long to catch up to the backlog of requests. But even a typical blue-green deployment is problematic. So if we have 30 containers running and we spin up 30 new containers, and they all need 15 database connections, then during the deploy, you potentially overload your database or exhaust your connection limit. Plus, you will need to allocate the compute resources for double the normal workload. So what we've been doing instead is rolling deploys almost everywhere where we spin up a few new containers using the new version and wait until they're fully online, spin down a few old ones, and then repeat that process until everything is up to date. But to do a rolling deploy like that requires backwards compatibility with the services it uses, in particular, at the database. And so, writing Rails migrations that are backwards compatible for one version has been a challenge. CHAD: And there's not really good tooling in Rails to do multiple stages of things. So if you really want to do that, you have to manage that in your source control basically and say, "Here's a new migration. We're going to merge in and deploy after this one," and that's not so great. JOE: Right. The other way to do that in the CI/CD pipeline would be to release commits one at a time and wait for them to be rolled out. But depending on how you structure your commit log, that could be pretty tedious. [laughs] CHAD: Yeah. I've seen as I've worked on this other project we're really striving to do continuous deployment. It's a high traffic, very complex deployment with lots of individual configured tenants. Separating out the concept of a deploy from a release has been very valuable for the application and for the clients. It changes the way that you need to think about how development progresses. I never before really worked in a system where you're literally sometimes duplicating and preserving old code, putting new code in place, having them both deployed, and then being able to switch between them as part of the release, and then cleaning up the old code later. At the scale that this is at, at the complexity that this is at, it makes sense for that application. It obviously doesn't make sense for everybody to be working that way. JOE: Right. Breaking up applications to be a little smaller, having components that could be experimented with individually would make some of that easier. The experimentation there separating the release from the deploy some of that is necessary because it's monolithic in so many ways. Like, it's a very big Rails application with one database with ACID compliance, which is a very powerful model. And it provides simplicity in some ways. But then it requires you to take on the complexity of making sure that you release things correctly. I do think that it would be difficult in this particular situation but for applications that reach that level of traffic and where you need to manage the risk of deploying, having smaller components, having some services broken would make that easier because you could do, for example, a canary deploy with one release rather than duplicating the code and having the old and new version. CHAD: Right. The services create boundaries with contracts about behavior and reduces things that are tightly coupled together, and their behavior is tightly coupled together. So, for example, on this application, we do have that one service that is completely managed independently from the main monolith and has its own deploy schedule. And we can, for the most part, change them independently without needing to go through all of that process that we go through to manage change. I think you're absolutely right. JOE: Another experiment we've been trying for another client is it's another Rails monolith. There are different audiences for it. So this is the food delivery application again. And there are customers who are placing orders. There are drivers who are delivering orders. There are restaurants that are fulfilling orders. And then there are admins who are managing everything in the back end. And there's some overlap in the data they use. But the actual requests, and controllers, and pieces of the Rails application they use are almost entirely isolated. So one challenge we had was being able to provide different reliability contracts for those different audiences and also scaling them and configuring them differently. So, for example, if you've done tuning for a Rails application before, you've probably tweaked things like how many threads will I have for each of my Puma workers? How many Puma workers will I have per container? How many database connections do I need in the pool? And what we were able to do for this application using Kubernetes and Isto was running the same application, the same container, so like one monolithic Rails container but running it more than once in different configurations and routing traffic to different pools of containers based on the audience. And so, for example, if the customer is making requests, those all go to the customer pool of containers, which are scaled independently and have their own configuration tweaks for the kinds of requests that customers tend to make, which are generally small, high throughput requests with lots of little rights. And then, compared to the admin panel, they typically view dashboards and big lists of records. And so, the requests tend to be larger, but the number of users is much smaller. There are way more customers than there are admins. And so, for those, we have fewer connections. We have more memory allocated for the kind of bloat that results in those types of requests. And we also have a different performance objective for admins. It's more acceptable for those pages to respond a little bit slower. And admins understand it's their job. They have to use the software. So they'll reload the page if they have to versus a customer where if they're having trouble placing an order, they might just buy somewhere else. So that's been a pretty powerful mechanism we were able to leverage CHAD: Is that switching on URL-like endpoints? JOE: Yeah, it's based on the path. But the mechanisms available to us are actually pretty powerful. At that point, we have access to the full request. So we could really route based on anything we wanted right down to the user. CHAD: I guess that's a really good example. You don't have access to that routing on Heroku. JOE: No, I think any Platform as a Service where they manage the routing if they don't provide that feature, you don't get that feature. CHAD: This is the first we're talking about this. That is a really interesting example of how to scale a monolith solves some of the problems that services often get you without having to break everything up right off the bat in order to do that. JOE: Yeah. I also think it provides kind of an inside-out approach to doing that. One of the problems with breaking out services is you have to plan what the services are going to be to a certain degree. And so, I think the best way to do it is to extract services from a monolith the same way you extract classes to break them up. And this audience-based approach is almost like a dry run. You can see if the boundaries you're drawing make sense in terms of traffic. And if those make sense, it probably makes sense to break up the front end at those boundaries eventually into different applications. And then figure out what services you need to extract to provide the common infrastructure for those front-end services. The same way test-driven development makes it much easier to find the correct tests to write, I think this approach of audience boundary discovery is an interesting approach to finding service boundaries versus trying to guess at what the services are, which very frequently leads people to wrapping services around database tables which doesn't help at all. CHAD: Yeah, that's the wrong thing to be looking at when you're looking at how to do services. JOE: Right. It's almost like deciding what your database tables would be upfront before you've seen the UI for the application. CHAD: Cool. So heading into 2022, we're looking ahead at the upcoming year. And so what's on the docket for Mission Control? JOE: We didn't start experimenting fully with SRE until the third quarter of this year. And so far, we've loved it. So I think we'll make a pretty heavy investment into our SRE offering. The goal is for us to have an open-source set of Terraform modules that effectively deploy a platform ready to go for SRE. What we want to do is maintain and curate that platform and then deploy it and maintain it for our clients. I think another big thing we'll be doing is (This might be incredibly boring.) but restructuring the way our agreements work a little bit. One of the things we wanted to test out when we built Mission Control was how much we could have built into a monthly recurring contract versus billing for time and materials like we usually do. So we tried putting a lot into that contract and really pushing the boundaries of what would be reasonable. And there was definitely a lot of pain there for us and a lot of difficult conversations with clients. So I think for 2022, we will be shifting a lot of our work back towards time and materials. So I guess that's a lesson out there for anybody else that's providing [laughs] support contracts is to make sure that the responsibilities contained in the linear amount scale linearly. CHAD: I think when we originally conceived of Mission Control, we also saw it handling a lot more things that it turns out just were not doing as part of Mission Control like regular Rails upgrades. JOE: Yeah, a lot of the things that we included in contracts originally were not particularly important to clients or at least were not outside of what they were capable of doing already. So it wasn't that much of a value-add. There are a lot of people out there that will upgrade your Rails version. And having somebody who just does it in the background but isn't aware of some of the impacts that might have in the application turned out to be not much of a value prop. Whereas stability turns out to be a big pain point for a lot of people, people don't know how to do it. And then our maintenance offering, I think what ended up providing the most value is not the keeping the code fresh parts, but it was more for the teams that don't have a large continuous development team having access to somebody who can fix quick bugs and things like that without needing to first negotiate a contract with a provider. I think that provides a lot of value. Those are pretty separate and different offerings. But those are the pieces that we found have really been valuable to clients. CHAD: Well, great. If people want to find out more about Mission Control or get in touch with you, where are the best places for them to do that? JOE: Well, we have a website thoughtbot.com/mission-control with a dash between mission and control. There are a few ways to reach out there. You can also find us on Twitter. We are @thoughtbot, and I am @joeferris. CHAD: Cool. You can subscribe to the show and find notes 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 @cpytel. 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 was brought to you by thoughtbot. thoughtbot is your expert design and development partner. Let's make your product and team a success.Special Guest: Joe Ferris.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots

Emily Bahna a Managing Director at thoughtbot who leads the Lift Off team, where they focus on really leaning into the core of the company. The team works with new founders to launch new products or they work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But, the thing that ties Lift Off together, is that they start at ground zero to build upon an idea and actually build the first version product to get it out live into the marketplace. Follow Emily on Twitter or LinkedIn. thoughtbot's Lift Off team 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 Emily Bahna, Managing Director of thoughtbot's Lift Off team. Emily, thanks for joining me. EMILY: Thank you. CHAD: So at this point, we've talked with a few of the different managing directors at thoughtbot about their teams. And Lift Off is one of the largest teams that we have. And so what is it that Lift Off actually does? EMILY: Lift Off is focused in on really leaning into the core of thoughtbot. We work with new founders launching new products or work with existing companies that want to build out a new service or open up a new area to generate revenue for their business. But I think the thing that ties Lift Off together is that we are starting at ground zero building upon an idea and actually building the first version product and getting it out into the marketplace. CHAD: And oftentimes, those are pretty significant endeavors. The last episode that came out was with Dawn at Ignite who is more on the validation, early stage, getting things that are fairly straightforward into market as quickly as possible usually in a matter of months. But Lift Off the endeavors are usually quite a bit more significant than that, right? EMILY: Yeah. I would say that the difference between validation...we're beyond the stage of validation. We're working with clients who are ready to build a foundation. They really need to put in the infrastructure that's going to take their product and get it ready to scale into the future. So they really need to make that investment into the longer-term strategy. They need to know what's realistic to build first. But they also have to keep an eye on the long road ahead of building something that can be something that can set out to grow down the road as well. CHAD: I guess another way of putting it is that Ignite often works with brand new teams, brand new companies creating something for the first time. And Lift Off typically works with existing companies who have existing significant revenue who want to do something new, either a new business or a new product, or maybe they have an existing web product and they're going into mobile for the first time. That's another way of putting it, right? EMILY: It could be. I think that when people are ready to move into the Lift Off space, it's about having the investment, the right kind of funding to move in that direction. Sometimes we do work with new founders that have a significant amount of funding, but a lot of times it is folks that are at the enterprise level that are building a new service line. They've got validation and market research already done. And they're building out a completely new line of business that they need to explore and set a new foundation in place. CHAD: Do you have some examples of clients that have been projects of Lift Off? EMILY: Yeah. We've been doing a lot of really interesting work in the health tech space, a lot of interest in improving patient experience. So we worked with a company called Relias in terms of moving them into a new service line that they'd never been in before, really focusing on improving patient care for therapists, physical therapy therapists. We've also worked with an organization called Groups Recover Together, building out a mobile application for an organization that helps people recover from substance abuse. And we also are working with an organization called Airrosti. That is also an organization that helps in the physical therapy space, so improving patient exercises or rehabilitation through an improved mobile experience, virtual experience to improve overall patient outcomes. CHAD: I think it's not a coincidence that a lot of the projects that we work on in Lift Off are in the health tech space because that combination of...like you were saying, a lot of what Lift Off does is really build products that are complex and that are going to scale and have a certain scale fairly quickly and need to really think about more of a platform that's going to be iterated upon into the future. And once you get into a highly regulated industry like health or finance or something, there are so many factors at play, especially if you're an existing business going into that. There's lots to consider. The projects are more complex. And so having a team of people that are focused on working in that kind of environment and know the challenges of doing that and an integrated design and development team who's comfortable operating in that space, I think that that's why it's not a coincidence. EMILY: Yeah. I think there's also a lot of great energy in that space right now to move it to the next level. And to be honest, the pandemic really accelerated the need for improvements in patient engagement and allowing therapists or physicians to be able to care for patients in a virtual setting. It also is true not just in health tech, but as you mentioned, we've been actively working with a lot of FinTech companies as well, building out mobile experiences for companies that are helping people get out of debt or working in even some of these new areas like cryptocurrency and things that are changing pretty rapidly in the marketplace and being able to respond to that. But kind of working in a really complex environment some particular industries that have specific compliance security needs in order to be able to serve their customers in a safe way. So working through a lot of those challenges is what's really important and having a team that can navigate through those levels of complexity. CHAD: I've talked with the other managing directors about the benefits of our new focus teams and how working on a similar project allows the team members to focus. The other aspect of it is there are parts of what we did under the studio model. And it may have been like there'd be one Lift Off project within...I think we should mention that you used to be the Managing Director of the Durham Studio. And it was a relatively small team working with local clients. And so you may only have one of these kinds of clients a year or maybe even less. And so building up an expertise but also meeting the needs of those particular clients there wasn't enough work there, for example, to hire someone with a specific skill set or knowledge if it's only going to be few and far between. And that's been true in Lift Off because we used to, at thoughtbot, not really have product managers. Everyone was designers and developers. And that was because only a subset of our projects really needed a product manager at the table. For the most part, a lot of those smaller projects or the boost-style projects are just developers or designers working directly with a stakeholder. And so, within Lift Off, we've built a product management practice because of that specialized need within these kinds of projects, right? EMILY: Yeah, I think just like you said, the ability to really focus in on the first version product is looking at ways that we could improve our process there and provide more support that's really needed for these kinds of engagements. So what we have seen with the more complex MVPs is a lot of these clients need reliability. They need to know that what they're building is the...They need to have more support in terms of the management of that, having someone who's dedicated to being able to straddle between the business objectives and working with the team navigating some of these more complex compliance issues, security issues, and keeping that on track. Also, we've been leaning into improving our practices around defining what first version product is. We've been using design sprints to really help align both business owners and the team to determine what are the biggest risk factors? How do we define what we're actually going to build and start building that roadmap? And we've been leaning into those best practices and actually improving upon it. And so we've looked at that and built out a discovery sprint that is not just a week-long but really extends that out to about three weeks to give us more time to do more user research, dive a little deeper through the design sprint exercises, but then bring in engineering, bringing an interdisciplinary team to look at the problem from both a product management point of view, a design point of view, and a development point of view to really determine the first version product roadmap and give more clarity to our clients and a clearer sense of what we can accomplish in the first. CHAD: I can speak to this firsthand because I was advising and working on a project that started before we reorganized into teams and effectively playing that role. But as the project went on, not that we did a terrible job, but it became overwhelming for me with my other responsibilities and spending a couple of days a week. A couple of days a week is sufficient on a smaller project, but on a much larger project, it's essentially a full-time job to do all of that work. [chuckles] And I just didn't have enough time to be able to do that, let alone then provide a real active management of the roadmap six-plus months out. So a very lightweight process with not a lot of definition works when that period is then over in 6 to 12 weeks, and you have something [chuckles] in the market. When you're trying to plan and trying to coordinate work and trying to give clarity around a product and everything that's six-plus months out, it's a whole nother ball game. And it requires a whole nother level of effort, and the clients want that. And so being able to give it to them not only makes them more successful and more confident and feeling like they have that reliability, but it also then puts our team in a better supported set up for success and that kind of thing because they have what they need, and the client has what they need. And everyone's able to really come together and collaborate on building and launching a great product. EMILY: Yeah. I think we're always looking at ways that we can improve our process, and as we are taking on more of the complex projects recognizing the need for this role. What's really exciting is the interest in the product management role. It’s been an opportunity for our team members. We've had two senior developers who've wanted to move into that role. And it's been an amazing transformation of with them, similar to you, having that background, the hands-on background of understanding what it means to be a developer on a project but then being able to transition to a different role on the project and get more involved on the business side of things. But that's been extraordinarily successful in making that transition and providing the support that the team needs in order to be successful. So in some ways, it's like we were trying to do that job without really defining it. But now that it's been defined, just recognizing the value that that role plays on these types of projects and seeing the opportunity to even improve it. CHAD: I wanted to tell you all about something I've been working on quietly for the past year or so, and that's AgencyU. AgencyU is a membership-based program where I work one on one with a small group of agency founders and leaders toward their business goals. We do one on one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more. And many of the AgencyU members are now working on client projects together and even referring work to each other. Whether you're struggling to grow an agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I've seen and learned from a lot of different situations, and I'd be happy to work with you. Learn more and sign up today at thoughtbot.com/agencyu. That's A-G-E-N-C-Y, the letter U. So we have a bunch of positions open in Lift Off. But product management is one of those positions that we're looking for people, right? EMILY: Yeah. We are actually opening up a position for Director of Product Management because the role is so critical to the work that we're doing, just like...I feel like we're extending our design and development model but then adding this third tier of product management, which is just as important in terms of the team that works best for these types of projects. It's having that interdisciplinary core of product management, design, and development working together for new products. A lot of it is really having that high-level oversight, the business strategy integrated in with the folks that can specialize in the development and the design piece. Having to look at the problem from those three different points of view just provides a level of reliability for clients that they just can't get with a single point of view. CHAD: What is the size of the product management team now? EMILY: Right now? Let's see. I think we've got about five. We have four or five active product managers right now. CHAD: So tell us more about the ideal Director of Product Management. What do you think that they would be? Able to lead a team that size while also evolving our product management process and doing product management themselves? EMILY: Yeah. I think I'm bringing in somebody who can help us improve our product management process specifically for first version products and really looking at it, and really shaping it, and pulling in the best practices, and really shaping it for the clients that we have I think is one thing I'm looking for the director to do. I'm also looking at the director to upskill our team. Like I said, there are a lot of folks like developers and designers that are actually interested in moving into that role and building up a potential career pathway for folks that may want to move into that area and to ensure that they are successful with that. And then growing the team, we are hoping to be able to...I think we've got five active projects right now, so being able to grow our projects and to grow the team so that we can support those kinds of projects on an ongoing basis. So really extending that out and then working collaboratively with our design and development directors to look at how we can collectively put together best practices around first version products. CHAD: Awesome. Well, what's on your radar now? What's next for Lift Off besides hiring a Director of Product Management? EMILY: [laughs] That's definitely number one. I think what is up next is really focusing in on teamwork. How do we work collectively as a team? Are there ways to improve our process to better serve our clients? We've done a lot of things in the past year. Like I'd mentioned before, we've improved our design sprints and extended them to become discovery sprints. Those are just names, but it's really the beginning stages of kicking off a project more successfully. Looking at ways that we can improve our customer experience and being able to serve clients in a better way, improving our product management across the board for all our projects, looking at ways that throughout the first version product for our clients what other ways can we better support our clients? Either through go-to-market strategies or helping them recruit permanent team members onto their team. But I think what's next for Lift Off is really examining how we service clients and looking at ways that we can actually make it even better. CHAD: Cool. Well, I want to change gears a little bit and ask you about you. EMILY: [laughs] CHAD: So your background, I think it's important to say is as a designer, right? EMILY: Yeah, that's one of my backgrounds. [laughter] CHAD: Okay, you have a varied background. But what were you doing when you joined thoughtbot and moved into the Managing Director role? And how has that evolved over time? EMILY: I think it's really interesting. You're always leaning into something. And as you look back at your past, even if it doesn't seem to make sense, you're always gravitating to something that is your North Star. Before I joined thoughtbot, I actually ran my own agency, which was called UX-Shop. And it was a team of one; it was me. As I was building up that agency, I recognized that I couldn't do it all. The types of projects that I wanted to work on were more complex. And so, when I started UX-Shop, I would be pulling in talent to create the type of team that would make that project more successful. It was hard to continually do that in a way where I had to recruit talent [laughs] and secure projects as well without having them as permanent employees. When I joined thoughtbot, it was an opportunity where I had access to amazing talent. And I could really focus in on building that, first off doing it in the Raleigh, Durham office where we went from a team of four to I think we grew the team to about nine. And starting to really grow that office to transitioning to this new model where we went from a team of nine to...I don't know the exact number, but I think it's like 25, 28. We're heading toward the 30 mark. So it's a significantly larger team with the ability to really focus in on the kind of projects that I actually really love, which is new product design and development but going after those more complex projects. And I think when I start looking back at my own career, I'm just starting to see patterns of the same focus but the opportunity to dive into it in a bigger way, in a more challenging way, and starting to tackle that. So thoughtbot's really given me the opportunity to take that ambition and actually apply it with the opportunity to have the talented team to be able to execute on those types of projects. CHAD: How has going from a team of one to a team of four to a team of nine to a team of pushing 30...are there things that you've needed to evolve in your own skillset or experiences? EMILY: Yeah. I think certainly building leadership skills, understanding how to work through a lot of challenges on what makes a team work really well together, making sure that we've got the guidelines and structures in place. There are a lot of things that I've grown just having the opportunity to work through some of those challenges. But also, in some ways, growing into a larger team has made some things a little easier. But it was nice having that progression from a smaller team to a larger team. I don't know if I would have been as successful with growing to a team of 30 right off the bat without being able to work in that smaller space, kind of learn my lessons, and then build upon those and grow that unit, get better at what I was doing. The reason why Lift Off is really starting to thrive is understanding that that foundation is built upon a lot of trial and error and just learning how to navigate and improve my own personal leadership skills. CHAD: Are there any particular resources that you called upon in order to do that? EMILY: So certainly reaching out to folks who are in similar positions. There's a strong community here where I live in Durham, talking to a lot of founders or folks in the leadership space who are growing teams. I've had some coaching with executive coaching that's helped quite a bit, especially when I've been in situations that I just wanted to make sure that I was handling them in the right way. And then, of course, having access to the folks at thoughtbot like you, Chad, and people that I can talk to and get advice on how to navigate tricky situations have all been contributing to my education and making me a better leader in this space. CHAD: Would you recommend coaching to other people? EMILY: I would. I think it's a real opportunity for you to...there's a lot of things that you don't really know that you don't know. And there's a lot of ways of approaching things in a different way on how you communicate. That is the difference between really getting through and solving a problem versus having a situation arise and escalate and become problematic. And it's a little bit of understanding how to frame things in a thoughtful way. It's also an opportunity to understand that sometimes you just need to have some space to think before responding and understanding how to navigate complexity, especially in today's world where leadership there's so much going on, transitioning to remote. There are different things that are pulling at us in different aspects and just really understanding the human element of your teams. So having someone who you can talk to in a way that you can share those ideas and get a different perspective, I think, is really helpful. CHAD: Yeah. Well, if folks want to get in touch with you or Lift Off, what's the best places for them to do that? EMILY: Well, there's always my email, emily@thoughtbot.com. I think just reaching out to me directly is the best place. I'm always happy to talk about Lift Off or have an intro coffee call with folks that are interested in what we do. So that's the best way to get in touch with me. CHAD: Excellent. You can subscribe to the show and find notes for this episode at giantrobots.fm. If you have any questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.Special Guest: Emily Bahna.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots

Dawn Delatte a Designer and Managing Director at thoughtbot who leads the Ignite team, where they focus primarily on validating and launching early-stage products through design-thinking, business and product strategy, and iterative design and development. Dawn works collaboratively with designers and developers to ensure they add value to the people and products thoughtbot works with every day. Follow Dawn on Twitter or LinkedIn. Visit her website at dawndelatte.com. thoughtbot's Ignite team 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 Dawn Delatte, Managing Director of the thoughtbot Ignite team. Dawn, thanks for joining me. DAWN: Hi, thanks for having me. CHAD: Ignite is one of the examples I always use when I talk about why we split up into teams the way that we did and what the benefits are, Dawn. So why don't you tell people what Ignite actually does? DAWN: Cool. So the Ignite team we work with entrepreneurs, and non-technical startup founders, in some cases, experienced startup founders, as well as innovation teams within existing organizations. And we work with them to validate their product ideas and deliver very initial versions of their products to continue that validation process. We provide all kinds of services around that from a validation perspective. We use product sprint methodology to understand the opportunity, understand the market, the problem, come up with solutions, all those things to arrive at some ideas and some solutions that we can then quickly prototype and then test with target users depending on who we've decided their customer is or who they've decided their customer is. And that's very high level. I'm happy to get into more detail about what our discovery sprints are like. But after that, then we would go into, like I said, continued validation but through actual product launches. So sometimes that looks like proof of concepts, sometimes that's first MVPs. But either way, we focus on a set of goals, and that could be a certain number of users onboarded to the platform. It could be getting that next round of investment funding. But it's pretty straightforward, not a whole lot of complexity, and focused on getting a product and company to that next best stage. CHAD: One of the reasons why I use Ignite is that it's on one end of the spectrum. It's at the extreme end of the spectrum. Last week, I talked to Josh, who's on the other end of Boost, where we're working on existing products with existing teams. And Ignite is all the way on the other side, which is sometimes we are not even writing any code at all; we're just validating an idea. The work that Ignite does has always been a very important part of what thoughtbot does. But it's a big challenge to go from a product where maybe you have hundreds of thousands or millions of users and a large team, and you're doing development as a developer or designer, maybe it's healthcare or something super complex, and then to the next week where you're working on something that is going to get into market very quickly, maybe is totally unproven. The things you need to do in that environment and the way that you need to work can be a little bit different. And so allowing the thoughtbot designers and developers to focus on the particular needs of the Ignite-type clients I think we have seen, and I think we'll continue to see it as people even get more used to it, it has a direct benefit to our clients as well The best thing might not always be to write a Rails app. But if you take a developer who was on a Rails app on Friday or Thursday, and then they start on a new project on Monday, chances are they're expecting to write a Rails app. DAWN: That's a really important observation and distinction about what our developers do compared to other developers at thoughtbot. I've always said that selling any kind of project or working with new clients with any type of project, whether it's very early stage or that enterprise client that we all wear our product consulting hats, or we're product consultants first, and then we have our toolkit. But I think that is the most true, at least from my experience, in the Ignite team. And we've even talked about and, in some cases, have been able to blur the lines even more between designers and developers because first and foremost, you're coming to the problems thinking about it exactly how you're talking about. Like, what is it going to take to make this product launch successful? It might not involve writing very much code. And we might not discover that until after we've been working together for a couple of weeks and started to validate some of the ideas we have. And so, being able to have that adaptability and really focus on the consulting and strategy aspect of things is super important. CHAD: So if there is a typical or Ignite client that we're working with, what does it look like? DAWN: I would say a typical...so who we've engaged the most with are non-technical founders and entrepreneurs. And I say non-technical but what I really mean is they haven't had the experience of launching a product and going through that process. CHAD: A digital product. DAWN: Yeah, a digital product. So for lack of a better way to describe them, non-technical because there's a lot of work involved in helping them understand product strategy and technical architecting and everything that happens in between. So that's who we've been able to work with primarily while we've also worked with other types of clients. CHAD: What is typically the first step with clients? At what stage are they at, and what is the first step that we're taking them through? DAWN: The sales process is a little bit different. We're not talking about requirements. And we're not exactly talking about what the end product looks like. If the conversation is going that way, we're usually trying to bring it back a little bit and keep things more high level just to make sure that we have a really good sense of what it is that we should try to do. So the sales process is we're already starting to dig into validation processes and making sure that our clients are able to define their customers and define the problem, and have started to think about their value proposition from a business perspective, and have made other considerations that through all of our experience, all the years that we have experience with shipping products, make sure that the client understands at least at a very high level what the big components for success are going to be. And if they haven't started to make decisions about those things, that they know that we can help them do that. So that conversation is already starting in the sales process, which is great because we can get the team involved, and everybody starts wrapping their head around the problem. And by the time that we actually kick off the project, we're really excited because we all are ready, and we have ideas for what we can do together. But the first stage is usually always what we call a discovery sprint. So we've been doing Product Design Sprints for a long time at thoughtbot. And we've always been iterative with everything we do. But with Product Design Sprints, especially because every single one of them is unique, you have to figure out either what exercises you're going to do that make the most sense for this client in this project. We had, I guess a bigger iteration of the Product Design Sprint as a whole. And we've moved into this concept of a discovery sprint or a discovery phase. And it allows us to do a couple of things. So the Product Design Sprint was largely modeled after the Google Ventures Sprint, which is this intensive five-day process where you quickly understand the problem, come up with some solutions together, prototype, and test within five days. We've elongated that process a little bit. So we definitely do two weeks, sometimes four if there's a lot to uncover and make sure we understand about the market before we start writing code or before we start doing the next phase of work together. And we kick off with a lot of the same processes. So like I keep saying, making sure you understand the problem, making sure you've defined the customer, the opportunities. In some cases, at least with our clients, we're actually doing lean model canvas work because our clients haven't always thought through how they're going to make money off of this product and what their competitive landscape looks like and things like that. We incorporate a lot of that business strategy into the product strategy work that we're doing during this phase. But yeah, the first week of a discovery sprint is usually those kinds of exercises, working together through all this institutional knowledge that the client might have. Because usually, they're experiencing this problem or they've been in this industry,and they know what the problems of their customers have, and so they can talk a lot about it. And then, we move into some of the more traditional Product Design Sprint phases, so diverge exercises, converge exercises that help us to come up with a bunch of ideas for what the product should be or should do. And then decide as a group which ones are the strongest so that we can move into prototyping. We prototype. We test with either existing customers in this space, or we get anonymous users based on certain demographics that are important to validate the concept with, and then we test. And then, we do that iteratively throughout the process to make sure that we're capturing as much data as we can to feel confident about how validation is going. Or, in some cases, it might make sense for us to think about the next phase of validation actually being more like a proof of concept. And so we can jump into that really quickly depending on how validation is going. A lot of times, at the end of discovery spreads, we've incorporated some technical planning and architecting into the process. Sometimes we have to validate that the launch approach is going to work from a technical perspective. And so that's the kind of research that our developer would be doing in this process. And by the end of this phase, we have a presentation of our findings, an architectural diagram if that's where we're leaning or where we would recommend the next stage go. We would present all that information and make a decision. Sometimes we invalidate. We largely invalidate some of the ideas that we came up with, and we have to go back to the drawing board. CHAD: Have we worked with any clients recently that had a major invalidation where they really needed to go back to the drawing board based on what we learned with the whole concept? DAWN: We did have a client that we worked with this year that we didn't invalidate things during the sprint but not far into the product build, we realized that we were going to need some other infrastructure in place in order for that product to be successful. So we actually did a more traditional Product Design Sprint with this client. Part of the reasoning was…, and this product idea was in the real estate space. [chuckles] The idea was to open up the market a little bit by...I don't want to say eliminating, but I guess, in a way eliminating certain aspects of what a realtor might do in the process of buying and selling real estate. It is possible to knock on somebody's door and ask them if you can buy their house, and then the transaction is facilitated through a realtor. But this would open up the possibility of this happening digitally through a product. So there’s certain data that you can pull from real estate sites out there that let you know certain things about a property. And this is public information; anybody can find it. And the concept was to have homeowners who might potentially be interested in selling their properties be on the platform and have their homes be available to anybody that might be looking or vice versa. Like, someone who's buying could get on the platform and see what kind of homes are in their area; maybe they have a particular area that they want to buy in and essentially cut out the realtor in that they could go directly to the property owner and inquire about their home or see if they might be interested in selling it. So that was, at a high level, the product idea. We did a more traditional sprint with them because the client was obviously very familiar with this space and really understood the opportunity well. And there are not a lot of competitors in this space in the U.S., at least. Our goal was ultimately to get to a plan for MVP. And so we spent time validating the user experience and at a high level, making sure that we were confident and moving forward with everything. And we felt like we got validation for that. And we got started on the project, and we realized there's actually a lot to this space. It's very heavily...if not regulated, there are all sorts of processes in place that require very specific people and roles to accomplish different things and facilitate the process. It's also because of the role that a realtor has played for so long. People aren't very educated on what this process could be like, buying and selling homes, especially with a direct transaction. And so there was way more to uncover and to understand and to work through on the business side than we had initially anticipated. And so we decided to quickly bring in somebody to focus on product strategy while we were also iteratively working through an MVP launch. So we decided to test as often as we can and constantly be working through on a weekly basis what it was that we were building, making sure that that aligned with what we were learning in real-time, essentially. The product strategist came on and started to continue some of the competitor research that we had started in the Product Design Sprints really try to understand the market and try to work very directly with the clients who were both in real estate to quickly make decisions about the direction that we were going in while we were also iterating on this product idea. About halfway through, which is standard to Ignite a 12 to 16-week MVP launch, so about halfway through at about six weeks in, we decided that we needed to continue validating with a working prototype as opposed to continuing to chug along until we got to MVP launch and just see what happened. That was feeling too risky as we were learning more and more about the market. So I wouldn't say we invalidated anything, but as we continued to validate and as we started to build iteratively realized that we needed to spend a lot more time on validating the product idea and that it made sense to do that with a working product. And so, we pivoted in that way once we had started building. CHAD: Yeah, that's cool. I often say that it's fairly rare that we completely invalidate the core of someone's idea. But it's not at all rare that it changes based on what everyone is learning along the way, whether that be in a Product Design Sprint or discovery sprint. And I think that's one of the things that not only does it make products more successful because you're reducing risk and you're changing them based on the things that you'll learn, but I also think it leads to the working environment that I want to be a part of where it's very collaborative; everyone's building off of each other's ideas. We're changing based on what we learn rapidly. I really love doing that. DAWN: Yeah. AD: I wanted to tell you all about something I’ve been working on quietly for the past year or so, and that’s AgencyU. AgencyU is a membership-based program where I work one on one with a small group of Agency founders and leaders toward their business goals. We do one-on-one coaching sessions and also monthly group meetings. We start with goal setting, advice, and problem-solving based on my experiences over the last 18 years of running thoughtbot. As we progress as a group, we all get to know each other more, and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in my 18 years of leading and growing thoughtbot, I’ve seen and learned from a lot of different situations, and I’d be happy to work with you. Learn more and sign up at thoughtbot.com/agencyu DAWN: And it's funny what you just said about learning versus invalidating. I literally just got off of a call with somebody right before I joined this, and we touched on that exact same thing. They've been building a prototype and going through their own validation phases. And this person pointed out that they didn't want to call the work that they had been doing validation that they wanted to call it learning. And I just thought that was very poignant. I feel like I call it continued validation when I'm talking about delivering a proof of concept or initial MVP because, really, that's what it is. But I think a better way to say it is just learning. You're learning from the process and from your market, and it's all at the same time. It's very agile in that way. CHAD: One of the meta reasons why I like that from a thoughtbot perspective is that oftentimes, founders, in particular, can be very precious about their ideas or not want to give up. And so this idea of oh, it could potentially be invalidated is almost like a confrontational tension or something that even when they are shown something they might not be willing to adjust because it's not their original idea. And the word learning subtly de-escalates that a little bit. It's like, what have we learned? [laughs] Have we learned something that we can take into play? It's not invalidating the idea. DAWN: Yeah, I find that using the term like de-risking does a similar thing. Because whether or not you're an investor, that's a term that I think everybody can understand. Like, let's try to learn from and lower the risk of us not being successful with each step we take. The ultimate goal is product success and business success, and we want to get people there. But we want to make sure we do it the right way. And we want to make sure that all the decisions that we're making early on have positive, long-term effects. So yeah, de-risking and learning. I think I'm going to change the way I talk about validation now. [laughter] CHAD: So what else is Ignite working towards now? I know that you have...everywhere at thoughtbot, we've got a bunch of open positions open. So you're actively hiring, right? DAWN: Yeah. So going back to what you were saying and what we were talking about earlier, a lot of what we've been thinking through on the development side is what skills are really necessary and important for our developers to have for the types of projects and the type of work that we're doing. We made an assumption and have been working through learning [laughter] whether or not that assumption is true that we don't necessarily need a ton of back-end Rails expertise to be able to deliver products in the way that we're thinking. Rails has always been really good with MVPs, really good for MVPs and speed to market and things like that. But I think that we are thinking through how we can be even more agile and iterative with product delivery. So we're leaning towards skill sets that focus on the front end, so delivering that really great consumer or user experience on the front end because MVP and startup space is incredibly competitive nowadays. We have to be thinking through, I think, more than what we did maybe ten years ago when we were delivering MVPs for startups. So we're focusing more on the front end. We're focusing more on the user experience. And we're thinking through how we can utilize existing tooling on the back end to support the products that we're building, which we assume is going to require a lot less particular expertise and a back-end language like Rails and a lot more openness to making decisions that make the most sense for that product idea in particular so whether that's pulling together existing tools on the back end. CHAD: Well, I find it useful to think about...or one way to articulate this is mobile apps in particular because some people might not get the distinction with a web app the difference between the front end and the back end. I think it's maybe a little bit more obvious with things like React and that kind of thing. But if you take a mobile app, for example, in order to actually build and launch a mobile app, we typically need to build the mobile app, and then that mobile app needs to talk to servers on the backside. And put quite plainly, if we have a Rails developer on the project and a mobile developer on the project, that's two people. And if instead, we can have a mobile developer who is putting together some back-end services from companies like Google or Twilio or those kinds of things, to get to the next stage of the company, it's going to be a lot cheaper and potentially faster for the stage that that company is at if it makes sense then. That doesn't mean that they won't ever need a back end of their own, right? DAWN: Yeah. Well, and I'm learning more and more too that making those kinds of decisions now doesn't necessarily mean that I can't scale, even with the services that we pull together for the back end at that time when we do the initial launch. AWS, for instance, has a ton of capability for initial launches and for scaling. So there are a lot of options. That's what's become more important to us when we think through the development expertise on our team is not only experience with delivering early-stage products, because you're in that mindset, but openness to working with different technologies that would allow you to, like you're saying, plug into these different tools and servers and systems that already working for a particular industry, for instance. I mean, e-commerce is one that you think of where we definitely don't want to be reinventing any wheels there. [laughs] From a conceptual perspective, yes, and from a competitive perspective, yes. But from a back-end development and architectural perspective, there's so much that we can utilize that already exists. So yeah, we are hiring. [laughter] I think that was your original question. And we have open developer positions, which is why I was focused on that. Our development focuses less around what you've historically seen at thoughtbot, which is we need Rails developers. We need full-stack developers who can for sure stand up a custom back end. And we've shifted to...we definitely need to focus on the front end. We need that expertise. And we need some adaptability around back-end tooling and being able to pull stuff together that way. CHAD: So you were the Managing Director of the Austin studio. And now you're the Managing Director of the Ignite team. Before that, you were a designer. How has this transition compared to prior transitions that you've been a part of? DAWN: I think the biggest difference, and this has been just as challenging as it has been rewarding, and I think positive for our business, is the fact that I can focus on expanding our services and expanding our expertise in this one area. Before, we had the local studios, and we could work across the entire product lifecycle. And from a sales and business development perspective, that both gave me varied experience. And it gave me a lot of levers to pull, especially with the teams and making sure that we were all working on different things and able to cycle through different types of projects. But that's hard to do, and it's a lot of work. [laughs] And being able to focus on one stage of the product lifecycle and a set of clients, and expand our expertise in that area has been really challenging and really rewarding. We've been able to sink our teeth in and imagine what possibilities are here and explore markets that we haven't before and actually think through how we can build partnerships with people and really become experts in this space in a way that we haven't been able to in the past because there hasn't been dedicated time and dedicated effort in particular. So the transition has been really great in that way. I'm really excited about it. CHAD: Well, that's good. [laughter] You were out on parental leave for a fair amount of time. How long was it in total? DAWN: About four months. CHAD: Welcome back, by the way. DAWN: Thank you. CHAD: I'm curious on your perspective either with Ignite or maybe even more so thoughtbot overall. How was it being away, and what surprised you when you came back? DAWN: So a couple of things, we were a smaller team in the beginning of this year. We knew that we were going to have to be iterative with our approach to refining our positioning as a team and understanding all these things that we're talking about, like our clients and our customers, and who we're going to work with, how we're going to work with them, how we're going to deliver value. We knew that we were going to have to be iterative. So we went through some phases this year. We were experimental and applied our validation processes to Ignite as a business. And we learned a ton of stuff. And we're going in a great direction. And then I was out for four months [laughter], and so there was a gap. And I tried very hard not to check my email. I mostly did a good job of it. And so I was telling Diana, our CEO, earlier that I feel a little bit like we're going into 2022 with a fresh start even though we have this whole year behind us that we learned from. We got to a point where we're going in a particular direction now. And we validated enough and felt strongly enough about the direction that we're going in that we're hitting the ground running now going into next year. And I don't know what I assumed; maybe I assumed that we would have established a little bit more this year in the direction that we initially intended. And it's not like a far departure. It's just that it's certainly evolved beyond what I was imagining initially from the technical perspective, for instance. CHAD: Well, even in Ignite, which is pretty short client cycles, we're not so huge. [chuckles] Ignite might do 12 projects in a year, and that might be a lot. So we get a lot of opportunities to try new things. And the cycle time isn't that long, but it's not super-fast pace, and it's not super high volume. So it does take some time to refine things based on what we learn, even in Ignite, which is typically faster cycles. DAWN: Yeah, that's true. If you think of it that way, a lot of our projects if we're doing an MVP launch, for instance, it's about a quarter along. And if we only do a couple of those every quarter, it takes those whole cycles to be able to look at things in retrospect. I agree; it takes a little bit longer to learn overall. I like the way that you put it, too, like when you really look back and think of it, even though we do a lot of what you would consider rapid projects, it's still going to take some time to learn. And I think overall, and I think this is true for all of our teams and our whole company, the year has been so positive. And we've learned so much. And everyone is feeling really strong, I think, in their positioning in going forward into the next year. Again, it's been good. It's been certainly challenging [laughs] but good. CHAD: I think there have been certain things about this year that have been challenging, and we've talked about it on previous episodes, some of them. But just in general, I think I got the sense that we transitioned from being tired of the current pandemic situation and working situation to actually being upset and angry about it, which was a really weird transition. And I think it just made work in general challenging sometimes. We also had the challenges of fairly high turnover this year at the company like a lot of companies have had. The reasons why it happens at thoughtbot might be different than other companies, but it's something that people in general have. And sometimes that can make it hard to get ahead, but because we were having such a positive year overall, it was this weird dichotomy of general success and positive change and all that stuff. But at the same time, people were still leaving the company, and that can make it challenging. The silver lining is for a team like Ignite, even though that can be super challenging, you're in your early days, and now you're getting the opportunity to...the new people being added to the team are doing it with different expectations, and you're able to shape the team into what it needs to be today. DAWN: Yeah. There has been an interesting...it seems like there was an influx this year and excitement and readiness to get back into building products and working on their ideas from a client perspective, but our teams were just coming off of a very hard year. People were coming off of a very hard year. So a lot of exhausted people trying to show up and be positive and work through all this excitement and movement in the industry. So it's kind of like parental leave. [laughter] Totally exhausted, but you're showing up, so it's good. CHAD: Well, Dawn, thanks for stopping by the show, and joining me, and talking to me about Ignite and beyond. I really appreciate it. DAWN: Yeah, this has been really fun. CHAD: If folks want to get in touch with you or follow along with you, where are the different places that they can do that? DAWN: Let's see. Well, I have an email address that is dawn@thoughtbot.com. I have a Twitter. I'm pretty sure that my handle is @dawndig. [laughter] Why I don't know this off the top of my head. I haven't looked at my handle in a very long time. Yeah, @dawndig, so D-A-W-N-D-I-G. LinkedIn is just my name, and it's pronounced Delatte. CHAD: And you can subscribe to the show and find notes for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore. Thanks for listening and see you next time.Special Guest: Dawn Delatte.Sponsored By:AgencyU: AgencyU is a membership-based program where Chad Pytel works one on one with a small group of Agency founders and leaders toward their business goals. You'll do one-on-one coaching sessions and also monthly group meetings. You'll start with goal setting, advice, and problem solving based on Chad's experiences over the last 18 years of running thoughtbot. As you progress as a group, you all get to know each other more and many of the AgencyU members are now working on client projects together and referring work to each other. Whether you’re struggling to grow your agency, taking it to the next level and having growing pains, or a solo founder who just needs someone to talk to, in his 18 years of leading and growing thoughtbot, Chad has seen and learned from a lot of different situations, and would be happy to work with you too. Learn more and sign up at thoughtbot.com/agencyuSupport Giant Robots Smashing Into Other Giant Robots