477: 20th Anniversary Episode

Chad joins cohosts Victoria and Will to talk about thoughtbot's 20th birthday! 🤖🎉

In this episode, you'll find the 411 on the thoughtbot mascot, "Ralph," taking the company fully remote, and our company values and how we believe products should be designed and built!

• Follow Chad Pytel on LinkedIn, Twitter, or visit his website.
• Follow thoughtbot on Twitter or LinkedIn.

Become a Sponsor of Giant Robots!

Transcript:

VICTORIA: Hey there. It's your host Victoria. And I'm here today with Dawn Delatte and Jordyn Bonds from our Ignite team. We are thrilled to announce the summer 2023 session of our new incubator program. If you have a business idea that involves a web or mobile app, we encourage you to apply for our 8-week program.

We'll help you validate the market opportunity, experiment with messaging and product ideas, and move forward with confidence towards an MVP.

Learn more and apply at tbot.io/incubator. Dawn and Jordyn, thank you for joining and sharing the news with me today.

JORDYN: Thanks for having us.

DAWN: Yeah, glad to be here.

VICTORIA: So, tell me a little bit more about the incubator program. This will be your second session, right?

JORDYN: Indeed. We are just now wrapping up the first session. We had a really great 8 weeks, and we're excited to do it again.

VICTORIA: Wonderful. And I think we're going to have the person from your program on a Giant Robots episode soon.

JORDYN: Wonderful.

VICTORIA: Maybe you can give us a little preview. What were some of your main takeaways from this first round?

JORDYN: You know, as ever with early-stage work, it's about identifying your best early adopter market and user persona, and then learning as much as you possibly can about them to inform a roadmap to a product.

VICTORIA: What made you decide to start this incubator program this year with thoughtbot?

DAWN: We had been doing work with early-stage products and founders, as well as some innovation leads or research and development leads in existing organizations. We had been applying a lot of these processes, like the customer discovery process, Product Design Sprint process to validate new product ideas. And we've been doing that for a really long time.

And we've also been noodling on this idea of exploring how we might offer value even sooner to clients that are maybe pre-software product idea. Like many of the initiatives at thoughtbot, it was a little bit experimental for us. We decided to sort of dig into better understanding that market, and seeing how the expertise that we had could be applied in the earlier stage.

It's also been a great opportunity for our team to learn and grow. We had Jordyn join our team as Director of Product Strategy. Their experience with having worked at startups and being an early-stage startup founder has been so wonderful for our team to engage with and learn from. And we've been able to offer that value to clients as well.

VICTORIA: I love that. So it's for people who have identified a problem, and they think they can come up with a software solution. But they're not quite at the point of being ready to actually build something yet. Is that right?

DAWN: Yeah. We've always championed the idea of doing your due diligence around validating the right thing to build. And so that's been a part of the process at thoughtbot for a really long time. But it's always been sort of in the context of building your MVP. So this is going slightly earlier with that idea and saying, what's the next right step for this business?

It's really about understanding if there is a market and product opportunity, and then moving into exploring what that opportunity looks like. And then validating that and doing that through user research, and talking to customers, and applying early product and business strategy thinking to the process.

VICTORIA: Great. So that probably sets you up for really building the right thing, keeping your overall investment costs lower because you're not wasting time building the wrong thing. And setting you up for that due diligence when you go to investors to say, here's how well I vetted out my idea. Here's the rigor that I applied to building the MVP.

JORDYN: Exactly. It's not just about convincing external stakeholders, so that's a key part. You know, maybe it's investors, maybe it's new team members you're looking to hire after the program. It could be anyone. But it's also about convincing yourself. Really, walking down the path of pursuing a startup is not a small undertaking. And we just want to make sure folks are starting with their best foot forward.

You know, like Dawn said, let's build the right thing. Let's figure out what that thing is, and then we can think about how to build it right. That's a little quote from a book I really enjoy, by the way. I cannot take credit for that. [laughs] There's this really great book about early-stage validation called The Right It by Alberto Savoia.

He was an engineer at Google, started a couple of startups himself, failed in some ways, failed to validate a market opportunity before marching off into building something. And the pain of that caused him to write this book about how to quickly and cheaply validate some market opportunity, market assumptions you might have when you're first starting out. The way he frames that is let's figure out if it's the right it before we build it right. And I just love that book, and I love that framing.

You know, if you don't have a market for what you're building, or if they don't understand that they have the pain point you're solving for, it doesn't matter what you build. You got to do that first. And that's really what the focus of this incubator program is. It's that phase of work. Is there a there there? Is there something worth the hard, arduous path of building some software? Is there something there worth walking that path for before you start walking it?

VICTORIA: Right. I love that. Well, thank you both so much for coming on and sharing a little bit more about the program. I'm super excited to see what comes out of the first round, and then who gets selected for the second round. So I'm happy to help promote. Any other final takeaways for our listeners today?

DAWN: If this sounds intriguing to you, maybe you're at the stage where you're thinking about this process, I definitely encourage people to follow along. We're trying to share as much as we can about this process and this journey for us and our founders.

So you can follow along on our blog, on LinkedIn. We're doing a LinkedIn live weekly with the founder in the program. We'll continue to do that with the next founders. And we're really trying to build a community and extend the community, you know, that thoughtbot has built with early-stage founders, so please join us. We'd love to have you.

VICTORIA: Wonderful. That's amazing. Thank you both so much.

INTRO MUSIC:

VICTORIA: This is the Giant Robots Smashing Into Other Giant Robots Podcast, where we explore the design, development, and business of great products. I'm your host, Victoria Guido.

WILL: And I'm your host, Will Larry. And with us today is our other host, Chad Pytel, the CEO of thoughtbot. Which, we're celebrating 20 years of business this year. Chad, welcome.

CHAD: Oh, it's good to have the tables turned on me. And I'm looking forward to the discussion today.

VICTORIA: Great. We have a whole set of questions, some of which come from other employees within thoughtbot. So we're really excited to dig into it today. Why don't we start with thoughtbot's iconic logo, the Ralph bot, and the little red robot that everyone knows thoughtbot for? And we call him Ralph within thoughtbot. So, how did Ralph come to be? Where does his design come from? And how did that become part of the company mascot?

CHAD: I'm happy to tell the story. But I have a question for both of you: have you ever heard me call the robot Ralph?

WILL: [laughs] No.

VICTORIA: I don't think I've ever heard you refer to the robot.

WILL: [laughs]

VICTORIA: So, if you did call it, I don't know what you would call it.

WILL: Oh, who started that? [laughs]

CHAD: It was someone who was at the company, Matt Jankowski.

WILL: [laughs]

VICTORIA: Ah, I see.

CHAD: I actually don't like the name. I think it's a terrible name for the robot. [laughs] I don't understand why the robot has to be gendered at all. And so I've never said that that's the robot's name. You know, when you're CEO, you have to pick your battles.

WILL: [laughs] Yes.

CHAD: Yeah. So that's the unofficial name of the robot, I think. And Matt started calling it that because Matt's a big fan of coming up with names for things. And yeah, so, at some point, he started calling it that. And it sort of stuck as people joined the company and just sort of assumed that that's what the robot's called.

We didn't start with this logo. Logo has always been a robot. But the thing we started with was an illustration based off of a tin robot that I think either one of us had or that we saw a picture of. Another Matt, who is one of the founders of the company, sketched it. He was a designer as well as a developer. And we used it for a few years.

But what we learned over the course of it as we gained more exposure is that, actually, it's a really common tin toy robot. And you can find a lot of other art and illustration and uses of it in stock photography and everything. Which at first was good because then we could get a bunch of stock photography, and it was our logo. But then we realized, ooh, this is not something that we really own or have control over. So we started to think about creating our own robot logo from scratch.

Since we're a design firm, and I think it's notoriously hard to design things for yourself, we actually went to another agency that we were friends with and hired them to work with us to create the logo. And I have to say I was probably the worst client ever.

WILL: [laughs]

CHAD: Because I was asking...I had a particular vision in mind for this idea of, like, a powerful robot. And we kept on doing sketches, after sketch, after sketch, and it was really hard. We couldn't arrive at something that seemed powerful, that didn't seem aggressive. The logo at the time was a 3D representation of the robot. And it was really hard to also make a new 3D robot that looked powerful but not aggressive. And we just banged our heads against that for a long time. I think it was a couple of months.

Until one day, I just said, you know what? We're not going to do it. Let's just stop trying to do this. [chuckles] Let's just do the simplest 2D representation of a robot that we can think of. And just going back to the drawing board starting over, we arrived at the logo we have today. Now we have to deal with the fact that it looks a lot like the Android logo. [laughter] But that's the, I guess, the story of the robot.

WILL: So, first off, scratching the name Ralph. [laughs]

CHAD: No, no, you can use it. I just think it's funny.

WILL: Definitely. Second thing is Chad is not a good client when working with designers. No, I'm just joking. [laughs]

CHAD: No, it's totally true.

WILL: [laughs]

CHAD: You know, when we have strong opinions that are mostly preferences, that leads to people being bad clients. [laughter] Because there was no reasoning behind, you know, the preferences. It was just what I had in my head. And so it wasn't until I let that go that we were able to arrive at something usable.

WILL: [laughs] That's awesome. So, was the robot a passion for you, or was it just a toy that one of the founders, employees had, and that's where you went with it, how you got your inspiration?

CHAD: The name thoughtbot with the bot on the end comes from...because before we started thoughtbot, we did a lot of Java development as a group, same people I went to school with them. We did projects together. And we would follow the pattern where you sort of have an object and then a manager object or a service object. And it was a common naming pattern. If you have orders or customers, then the service object might be called order manager or customer manager. And, in our code, we tended to not do that and instead do bots. So we would have order bot over orders, customer bot over customers.

So, when we were brainstorming names for the company, we naturally tended to put bot on the end because that was our typical naming convention in the projects we were doing together. And so there wasn't anything particular about robots that we cared about at all. [laughter] It was that naming convention, which then extended to, okay, well, it's the thoughtbot. And so it should be a robot with thoughts on it or thought lines or something like that. That's where it came from.

VICTORIA: I love to hear that. I'm learning so much myself I didn't know before even as a thoughtbot employee.

WILL: [laughs]

VICTORIA: It's been 20 years since you started the business. I want to start...or go back in time. So, if you could go back and give yourself, the younger version of you 20 years ago, some advice, what would you say?

CHAD: I've gotten similar versions of this question on different shows. My answer for the last several years has been pretty consistent. So I'll give that one, and then I think I have another one too. The thing that I didn't realize at the time that I think I would be better for and the company would be better for I had a big blind spot in terms of I started thoughtbot with friends. We were the same age. We were all five White guys in our 20s, just out of school. That was the people that I was doing projects with; that was the people I was surrounded by in school. And it was a big blind spot.

And, if I could go back in time, I would try to open my eyes to the fact that that was the case. And I think that I would be a lot better for it. And I think the company would be a lot better for having started with a more diverse team from the beginning because it makes us worse when you don't start off that way. It's harder and harder to correct it the longer it goes on. And so that would be something that I would go back and try to tell myself. Look at what you're doing. You don't realize now, but it is important.

WILL: So, because we started talking about this at Summit a month ago, and it was amazing to hear that you're saying that because, at the same time, we're at this all-staff event, and we're able to see how diverse our team is and stuff like that. How has the journey been increasing the diversity of the team? Like, I look at our team photo, and it's just amazing to see the diversity in every level, especially in leadership, the diversity in leadership. And I know we haven't, quote, unquote, "arrived." So, how has that journey been? And what does it look like in the future?

CHAD: Yeah, I mean, we've clearly made a lot of progress on this. It is better and easier now than it was in the early days because nobody wants to be the first. Nobody wants to be the first woman on the team. No one wants to be the first person of color on the team. You don't know when you're coming into an organization like that, whether it's the kind of place for you or whether you're going to run into problems. And so now that we've made some progress, that in and of itself makes it easier to continue on the journey.

But when we were just getting started on that, we really needed to do a lot to intentionally fix it without tokenizing people, which is not easy to do. And so we're very fortunate that we have made progress. And I appreciate everyone along the way putting themselves out there, willing to be the first, or the second, or the third. I know that that's not easy, and it's made thoughtbot a better place now that we've progressed.

WILL: Yeah, and I want to interrupt and say this: after that conversation, I remember I had to split and run to another event. While at that event, I met one of the first ladies that were on the team. And I started chatting about her experience. And it was amazing to see the transformation from the beginning to where it is now. So it was just really good to have that conversation with you, and then go talk to her and just, I guess, see the complete picture, so that's amazing because she's still on the team to this day.

CHAD: Yeah. But we're not done yet. Like you said, we still have [laughs], you know, we can always be better.

WILL: Where do you see it going in the future?

CHAD: Well, I think that even though the management team, the senior leadership team, we have made progress there, I think that that is an obvious area where we have more progress to go in terms of making sure that people at the company are represented...the demographics of the people at the company are represented at every level of the company, especially when you have a culture like we do where the leaders are the people who have been here the longest. And we don't have so many of those positions opening up over the years.

In fact, over the last five years, we've eliminated more of those positions in order to reduce overhead and to stay financially sustainable. So we actually have less of those opportunities than we have in the past, and so that holds us back. And so we have to figure out how to handle that and to do better with that.

The other is, you know, one of the biggest changes over the last three years is going fully remote. And that has enabled us to hire the best people, no matter where they live, in the time zones that we operate in. And that has been really great for bringing new people, new energy onto the team. That is going to continue into the future. And we're going to see the demographics of the company continue to shift away from the United States. 60% of the company is now outside of the U.S., and that's going to keep on going. And that doesn't make us any worse off. It makes us better.

VICTORIA: Yeah, I wanted to ask you about that. So, thoughtbot, as I understand it before we went fully remote, was known for having an amazing in-person office culture. So, what was that shift like for you? And how do you maintain that company culture after going fully remote?

CHAD: Well, here's the honest answer.

WILL: [laughs]

CHAD: The honest answer was I was already not part of that office company culture. I was traveling one week out of every month to one of the studios. I didn't interact with people in the same way because of my position within the company. I was out of the studio a lot of the time. And even when I wasn't there, I was already working from home a few days a week because of my travel schedule or something like that. So moving to fully remote...and I was already sort of over-commuting to 45 minutes each way to the office.

And so moving to fully remote has made things a lot better for me because I'm traveling a lot less. I get to be home with my family a lot more. I don't have that commute time. And my experience now, I think, is more similar to everyone else on that team. And I feel like we're all sharing more equally in what the experience is at thoughtbot. And so when I work to improve that, I'm not only working to improve it for me. I'm working to improve it for everybody.

And so there are trade-offs. It is certainly different for the individual designer or developer at thoughtbot than it was before. But I think that the benefits of having the team that we have now, people being able to live where they want to live and to get that commute time back, outweigh the downsides of changing that company culture.

VICTORIA: The other part is about just that shift, right? Of it was COVID. [laughs] Obviously, a lot of people were going remote at that time. So I'm just curious how that experience really happened for thoughtbot. I know how it happened for me at the company I was at. [laughs]

CHAD: Well, it was certainly abrupt, you know. And, at the time, we thought, okay, we're going to shut down the office for two weeks, and then we'll all be back. And that, very quickly, was proven to be wrong. When it came to our actual work, the biggest shift we had was in the way that we collaborated with clients. But we were already collaborating with each other across studios in a distributed way. And so that was a more natural progression.

I think the biggest shift was the way that our projects were working and collaborating with clients. You know, we would have clients in the office with us, too, sitting right next to us. And so figuring out how to do design sprints fully remotely, to ramp up the amount of remote pair programming that we were doing, those were the big changes, I think.

And then you had the cultural ones, too, that you really need to work at when two people are getting a snack in the kitchen and having an off-hand chat about something. When you're fully remote, that doesn't happen. You need to put a lot more effort into those sort of what would have been casual conversations previously.

WILL: So, and it seems like...just having a conversation with you, I know that it wasn't an easy decision to change over. And my question is, how do you make decisions, especially the hard ones that are not...and you stick with them? For example, I know, like, with hiring, we're talking about the diversity and creating a diverse pool that kind of resembles the area that we're trying to hire for, so, you know, resemble the U.S., or overseas, or wherever it is. And that's a hard thing to do at times, but we stuck with it. And there's been other decisions I've noticed.

So, how do you make those decisions, one, and then, how do you stick with them when most companies or most people will say, "Hey, it's just too hard. Let's pivot and change it up"?

CHAD: Yeah, we have our values, five core values, and one of them is fulfillment. And I often refer to that as our North Star value, meaning that when we're faced with a decision as a company or as individuals, fulfillment is often the one that we most often look to as the guide for which direction to go in. And I think that that is really powerful for us. It causes us to choose things that other companies might not choose.

And it also is really powerful for us because it means that I don't need to be the one to make all of the decisions. You can make decisions based on what is fulfilling to you in your work. And that's very likely the right thing for everybody else at the company. And it may mean that we're a little bit less successful financially. But there are two aspects to success, you know, you need to be financially sustainable, but if you're unhappy in your work, if you're unfulfilled in your work, then that's not truly being successful. And so that's the guiding point of the way that we make a lot of decisions.

Take the example of going remote, we weren't really deciding between going back to the way things were or going fully remote. Going back to the way things were was not an option because we had already told everyone if you need to move if you need to be away from the studio you were previously part of, go do that. You don't need to worry about remaining at thoughtbot. And about 20 people moved away from where their studio had been located, which is about 20% of the company. So we were deciding between hybrid or fully remote. Going back to the way things were wasn't an option because we had already removed that from the table, I think, guided by supporting the team, fulfillment, trust, our values.

So then the decision-making comes, do we want to figure out how to be hybrid? Which we had done before in our history. And we understood, based on that past experience, that you have to work at that quite a bit to integrate everyone fully, and sort of if you don't, it becomes very tough or even just mediocre. And so it was, are we more excited about working at being the best hybrid organization in the world, or are we more excited at figuring out how to be the best remote company in the world?

You know, for me, that was an obvious choice. I was more excited about figuring out how to be the best remote company than I was about being the best hybrid company. So I think that that's an okay... [laughter] I think that's an okay way to make decisions. What are you more excited by? What are you going to be more fulfilled by in your work than that? And so that's, you know, sort of dissecting that decision-making, you know, part of what tipped us over the edge in terms of choosing to be fully remote.

VICTORIA: I like that you said that you tried to make it so that you're not the one making all the decisions. [chuckles] And I felt that as a managing director and as an associate director that there is a very purposeful tact of when I'm bringing issues to leadership. The response I get back is very careful not to tell me what to do. [laughs]

CHAD: Yeah. I'm sure it's annoying at times, right? [laughter]

VICTORIA: I think it's a shift, right? Like, if you're coming from a typical, like, top-down organization, it can be a real mind shift, and it can be frustrating. But then, once you embrace it, it can be very fulfilling, like you said.

CHAD: Part of why we do that, too, is because if you're not careful, you know, one of our other values is trust. And we really do trust people more than they're used to. And our other value is self-management. So, people should be left to their own devices. People at thoughtbot take initiative in their work to make decisions, those kinds of things. And so, at the intersection of trust and self-management, what happens in a lot of other cultures is this idea of permission. If you have to ask permission to do things, then you can't truly self-manage.

So, when you come to a leader and you're asking for something, it's hard for that not to be articulated as asking for permission for something in a traditional sort of power hierarchy. I encourage people at thoughtbot to think about...in the way that our culture works, it's a lot better to frame things as asking for advice because there are people who have more experience in a certain area than you or whatever.

And so a much better way of framing the conversation that you want to have with those people is instead of just asking open-ended questions, which it's very easy to misunderstand as basically just asking for permission to do something, it's better to say, like, "Here's what I know. Here's what I would do based on what I know. Do you have any advice for me based on that?" And then I can say, "Oh, well, here's what I know. [laughs] Can I share that with you?"

And then, you can take that information in, and then you can make the decision based on having that additional information. I don't want to make the decision for somebody. That's the way I think about it. If you're not sure what's happening, it can be pretty frustrating in our culture because we are sort of averse to telling other people what to do. We're happy to help people and give people information, but we don't like to tell people what to do.

WILL: Yeah, and I've definitely felt this, even as a developer here. But it has been the perfect fit for me because I love the, hey, we trust you. Go and do it. Go make decisions. Hey, even if you fail, let's come back and talk about it and move forward. But also the pushing me out of my comfort zone. There has been numerous times where I'm like, "Yeah, I don't think I can do that." And someone in leadership is like, "I think you can. Let's try it out. Let's do it. If you have any questions, come talk to me. I'll help you in any way I can." So, even as a developer, I feel that same way.

And so I guess my question for you, Chad, is there's been a lot of decisions that I've seen you make or even this part right here, the trust. Because sometimes, money can override that when you're a CEO, especially because of jobs and everything. But you said fulfillment, and you had the values. But, Chad, as the CEO, like, why do you personally lead like that and make decisions like that?

CHAD: It's a really good question. [laughs]

WILL: I always wanted to peel back the layers of Chad.

VICTORIA: [laughs]

WILL: So that's what it is. [laughs]

CHAD: To tie it back to development, just like you just did, I think a lot of our values and the way that we do things come from the way that we believe products should be designed and built. When I'm working on a project, I don't want to be told how to do everything. I don't want every ticket to be specified without me being part of the understanding or decision-making process.

I want to be able to collaborate with the people that I'm working with, understand the problems that we're trying to solve, and then pick up the ticket and do the research, figure out the best way to solve it or be part of that. And when it's not clear to me, ask questions, learn from other people about the right way to solve something might be, and then to implement it in the best way that I know how, and collaborate with the people that I'm working with as I do that.

And then I pick up that ticket, and I'm responsible for deploying it to staging and asking for acceptance of it. And I'm responsible for deploying it to production. So I'm pushing my work. I have agency over my work at every step of the way. I hope everyone who's listening has had an opportunity to be on a project where you've truly had agency over your own work. It's a really good, fulfilling feeling. And so I think that's where it comes from. I think that's what I try to bring to everything that I do.

VICTORIA: And I think that philosophy is what creates such a compelling company culture and makes people want to work here, right?

CHAD: I think so. Particularly because the work we do, the majority of us are designers and developers, but I don't think it's just design and develop. Like, it resonates a lot the relation to product work. But I think that's true for fulfillment in your own work generally across the board, no matter what your role is. People would rather have agency over their own work than to be micromanaged, to be told what to do all of the time.

MID-ROLL AD:

Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features?

We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking.

By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer.

Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops.

VICTORIA: In 20 years of hiring people and building products, what has really changed in terms of what you see customers looking for in building products, and what's stayed the same?

CHAD: There's a lot that has changed, mostly in terms of platforms and practices. When we were first getting started out, the practice of test-driven development was not generally established as a best practice. It was one that we needed to advocate for and fight for, and really put ourselves out there as this is what we believe about the way good products are built, and if you don't want that, we're not a good fit for each other. So that's what I mean by practices. A lot of those things that used to be controversial we sort of won on as they played out as, yes, general agreement now about certain best practices. And so that has evolved over time.

The other is mobile development. You know, when we first started, that wasn't really a thing. We did some mobile development early on for Palm platforms and for Motorola platforms using different versions of Java. It was a very different ecosystem. And mobile development has evolved a lot and become...almost every project we do has some mobile component. And a lot of them are native mobile applications with an API back end that we're building as well. So that has been a big change.

The things that stay the same are, I would say, the things that we have sort of been constant about. So in the way that best practices change or evolve, the constant has been that we put ourselves out there, willing to be opinionated about what we believe the current best way of working is. That means that the clients who work with us are coming to us wanting that.

And that leads to a culture of work and quality and that kind of thing, which I think has been pretty constant over the years. But it's not because we didn't try. Like, if we were willing to be anything to anybody and to compromise all the time and those kinds of things, it wouldn't be a constant. But we work at it, but I think that feeling of what it's like to do this work has been a constant.

WILL: Speaking of changes and constant changes sometimes, what's the story behind the handbook? Everyone at the company can access the handbook through GitHub and how [inaudible 29:35] Whose idea was it? How did that come to be? And explain how it's always changing and what that looks like.

CHAD: Yeah. So, like you said, we have our company handbook and the public playbook in a source code repository that everyone at the company collaborates on and has access to change. I don't remember who initially moved it into version control. It started as a document. We worked with an outside payroll or HR company to make as our first company handbook. It had policies and those kinds of things in it. At one point, you know, we were doing some revisions, and maybe me, maybe somebody else said, "Let's move this out of this," whatever it was at the time, Word doc, or whatever, "and move it into Markdown and natural place we want to have version control on it."

But even though we moved the document into version control and even though everyone at the company technically had access to it, I think for many years, we still did things like a lot of companies do, which is the version control in and of itself isn't the special thing. It's using GitHub issues to track actual problems that we know about, or potential issues that we know about, defects in our policies, our practices, the company itself, just like we do on our software products. That was the actual fundamental shift that we made because it completely changed the way that we make change at the company and organize the work that we do to improve the company.

And the way that that happened was, I think, prior to that, we made changes in a lot of ways that companies make changes. So some people know about some things, some people don't. Typically, senior leaders will get together often in meetings and talk about the issues that they see. And they tend to result in really big changes all at once that attempt to address multiple issues or make big reorganizational changes. And there's a tendency not to work iteratively when you work that way, and we did the same thing.

So the sort of final big event that happened that triggered the fundamental change of working was, at the time, we had an unlimited time off policy. We had gone to that a few years prior because it was a trend in general. But also, we were tired of sort of tracking time and the permission that happens around time off and all that kind of stuff. So we had sort of blown it all up and gone to an unlimited time off policy. But it's more well understood now that unlimited time off policies have a few issues. And we were seeing those issues.

Time off was very inconsistent among everyone on the team. Particularly, new people would join the company, and they'd be like, okay, yes, but how much time am I supposed to really take? So that was one issue. Another issue was we wanted to increase the amount of parental leave that we offered as a company, like, on paper. Now, technically, we had the unlimited time off policy, but you want to give guidance to people, and you want to be able to say in a job advertisement that you have this much parental leave, you know.

And because we're a consulting company and we make our revenue when people are working, the question was asked, how much can we say that we have for parental leave? And it was a very uncomfortable position for us to be in to not be able to work that financially because we could say, okay, we have 12 weeks of parental leave. But, at any point in time, anyone else could take more time off for any other reason because we had unlimited time off policy. And the idea that we couldn't prioritize one kind of time off over another to make it work financially was uncomfortable to us.

And then, the state of California passed a sick time law, which was fundamentally incompatible with unlimited time off policies that lump sick time and vacation time together. And so we knew about these things. We got together in a meeting. We talked about them. And we put together a pull request to the handbook that, you know, we said, you know, we could probably fix any one of these problems. But probably all signs are pointing to just switching back to a regular time off policy.

And so we put together a pull request. You can probably guess since I'm telling this story that, generally, people were very surprised. It was a big change to take in all at once. And I think even though we have a high level of trust, as a company, it was hard for people who generally viewed an unlimited time off policy as a good thing. You know, they were worried that there was some ulterior motive there, that something was being taken away for some reason, maybe financial. So we worked through it, and the pull request is there for everyone at the company, so you can see.

Anna, when she opened the pull request, outlined all of those reasons why, but it was a lot of information to take in. And after we made it through, it sort of caused me to reflect on the process. And there was good criticism from members of the team at the time about the process, and we really took that in. And I think it was the state of California passing that law that the solution that we arrived at to mind for me because they passed the law in, whatever it was, the spring or the summer. And it wasn't going to go into effect until the new year.

And that's really no different than, you know, a new version of a library is going to come out, or a new version of an operating system or a browser is going to come out. And we know it's going to break our app. What do we do? We create a ticket in the backlog. We describe what the problem is. We prioritize it among everything else we're working on. And we make sure that the fix is in place in time for that to be released.

And yet, we weren't doing that for these very obvious defects or things that we knew were going to break an existing policy against this kind of stuff. So I was like, we could use GitHub issues to log problems that we know about that are out there, and not only would that have led to a lot more transparency along the way. When a change was made, people could have come along that journey with us of identifying the problem, being aware of it, being part of problem-solving, and coming to a resolution, and then getting a pull request.

But more fundamentally, I think once you start to work that way, probably would have never made the change that we did in the first place because this way causes you to work more incrementally, to work more iteratively, to take each of the problems to try to identify the root cause and the best way to fix it. And very often, that is a smaller change that you can put into place more quickly. And we know that we don't need to get it perfect. We don't need to change absolutely everything about this all at once in order to fix every problem. We just need to make tomorrow better than today.

If we can do that, then we know that, over time, it adds up to significant positive change that is very different a year from now or two years from now than what we're doing today. But we do that by chipping away and making tomorrow better than today. And so working this way with these discrete tickets, with this thing, there are downsides too, don't get me wrong. It's not all sunshine and rainbows. It's hard to work this way. But those are some of the benefits and sort of the story of how we arrived at how we do things.

WILL: I love that because I'm familiar with creating PRs, commenting on PRs, just giving feedback through PRs. And also, I've never been in a leadership meeting at thoughtbot, like, just never been in one. But I know that if I comment on a PR, my voice is heard with leadership making the decision. I love that idea.

CHAD: Yeah, leadership meetings at thoughtbot are actually very boring.

WILL: [laughs]

CHAD: Because the only things that we're talking about that aren't represented in GitHub issues are things that aren't proper for GitHub issues, so they're individual personal problems or things like that, or, hey, we're doing a leadership training and, you know, talking about that. Actual change, actual things that happen, are represented in those GitHub issues. And that's why it's super important that we have issues for everything because when we truly work this way, if something's not represented as an issue, it's not getting worked on.

There's not a lot happening in leadership meetings other than those things that aren't ideal for GitHub issues, or we're going through, and we're saying, "Hey, this issue has been sitting around for a while," or "What's the update?" And you'll often see someone comment after the fact about an issue. Now, that being said, I think one of the hardest things about this is that when you expose these big issues, it can be a little discouraging over time to have them be around there to be not closed.

But the way...I'll bring this back to our product work as well, like, when you identify...at least this is the case for me. A bug could have been there for two years, [chuckles] and I don't know about it, and therefore, it's out of sight, out of mind. I didn't know about it. But the minute I find out about a bug in a product that I'm working on, I can't stop thinking about it, and I want to fix it so badly. It becomes my top priority right away. [laughs]

And I have to remind myself that just because I know about something now doesn't mean it's actually the highest priority item, or that I can fix it, or that I should take the time to fix it. I know it's my natural tendency to do that. So shedding light on something that's positive in and of itself, and then we can chip away at that over time. And this way of working allows us to tackle big problems. But sometimes it doesn't feel so great because you're identifying sort of defects in the company itself that make everybody uncomfortable. But I would rather light be shed on those so that we have a chance to improve it than to have it go unidentified, just like bugs in our products.

VICTORIA: And just to illustrate, we have 162 open issues on our handbook. [laughter] But, you know, from my perspective, that makes me really excited, like, people are engaging with it. They're putting in issues and creating it. Because I've converted a company handbook to GitHub before, and no one ever looked at it. [laughs] So it was actually kind of nice that --

CHAD: [laughs]

VICTORIA: You said that it took some time to build up that interaction with it and make people feel comfortable. And I wanted to ask about actually your Dungeons & Dragons campaigns that you run with the company. And I'm wondering what skills or practices from that comes over into your leadership style or the culture at thoughtbot.

CHAD: Ooh, I'm not sure it's as deep as that, Victoria.

VICTORIA: [laughs]

CHAD: I just really like [laughter] playing Dungeons & Dragons. But I will say the itch that it scratches for me and the reason why I like Dungeons & Dragons, and the reason why I'm really happy to play it with thoughtbot people...my degree is computer science. But all throughout elementary school, high school, I did improv and theater, and I have a degree in theater as well.

For a long time, Dungeons & Dragons is essentially doing group improv with other people around a game. And to be able to bring those two things together with a group of people that I like to have fun with it's a really great outlet. And I really enjoy it. But I'm not sure that there's anything deeper than it sort of scratches that performance itch that I have with a group of people that I like to hang out with.

VICTORIA: That's fair. And then, just to kind of go back to one of our earlier questions we asked —what would you go back in time and advise your younger self —now, what if your younger person could travel to the future and give you some advice, looking at where you are at now?

CHAD: The only way that I've done this for 20 years is day by day. Like, each day, you get up, and you approach each day. This is the way I do it anyway. It's like I approach each day as a fresh day. And now, over thousands of days, it's been 20 years. And I think that that is part of why at least I've been able to do this so long is I don't do a lot of dwelling on what happened yesterday. I think about today and tomorrow much more than I do about what happened yesterday.

The upside is I've been able to do this for 20 years. [laughs] The downside to that is you tend to not reflect so much on the good things, just like you don't reflect so much on the bad things. You tend to not celebrate the milestones when they happen or appreciate them as much because you're onto the next thing. You're thinking about tomorrow rather than yesterday. And so I would think that if my younger self came forward and talked to me today, I think the thing that he would say is like, hey, look at where you are, look at what you've done. Take a moment [laughs] to celebrate not only your work but, you know, this is true for the people around me.

I tend not to celebrate the accomplishments as much and everything because I'm very much someone who sort of lives in maybe not even the moment but the next moment that's about to happen. And so I think the person would say, relax a little bit, have a little bit more fun. Take a moment to celebrate the people around you a little bit more. I think that's what I would say to myself.

WILL: I love learning things that I didn't know about thoughtbot. So this has been perfect.

CHAD: Thank you both for the really thoughtful questions. And on the note of what I just [inaudible 44:53], thank you for everything that you both do at thoughtbot. I really appreciate it. We couldn't have accomplished everything that we have without the individuals [inaudible 45:01]. So I'm here sort of representing thoughtbot for our 20th anniversary, but it's not just me who got us to this point. It's been a lot of other people over the many years making it happen. And so I appreciate both of you for helping make it happen.

VICTORIA: Well, thank you. And again, thank you so much for joining us.

You can subscribe to the show and find notes along with a complete transcript for this episode at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. And you can find me on Twitter @victori_ousg.

WILL: And you could find me @will23larry.

This podcast is brought to you by thoughtbot and produced and edited by Mandy Moore.

ANNOUNCER: This podcast is brought to you by thoughtbot, your expert strategy, design, development, and product management partner. We bring digital products from idea to success and teach you how because we care. Learn more at thoughtbot.com.

Sponsored By:

• thoughtbot: Are your engineers spending too much time on DevOps and maintenance issues when you need them on new features? We know maintaining your own servers can be costly and that it’s easy for spending creep to sneak in when your team isn’t looking. By delegating server management, maintenance, and security to thoughtbot and our network of service partners, you can get 24x7 support from our team of experts, all for less than the cost of one in-house engineer. Save time and money with our DevOps and Maintenance service. Find out more at: tbot.io/devops

Support Giant Robots Smashing Into Other Giant Robots