Chad interviews Managing Director at thoughtbot, Joshua Clayton, about what a Managing Director at thoughtbot does, what makes Boost at thoughtbot different than other teams, and the belief in integrated teams of designers and developers company-wide.

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 Josh Clayton, Managing Director of the thoughtbot Boost team. Hey, I know that company. Welcome, Josh.

JOSH: Hey, Chad. How are you?

CHAD: All right. I'm back to the show I think. I didn't get a chance to look up the last episode you're in, but it was probably hundreds of episodes ago now.

JOSH: Yeah, it's got to have been a while.

CHAD: [laughs] Speaking of a while, you recently…now time is all messed up for me, but I know that you have been at thoughtbot for a long time. How long has it been?

JOSH: It was 12 years in August.

CHAD: It's been a wonderful 12 years, Josh.

JOSH: I agree. I agree.

CHAD: [laughs]

JOSH: It's been fun.

CHAD: So in that time, you have had a few different roles. But you've been a Managing Director for a while now.

JOSH: Yeah, I think that's...let's see. It was seven and a half years for the Boston team. And then it's 10 and a half months with Boost.

CHAD: So your background is as a developer. And you, like a lot of people who have a background as developers at thoughtbot, myself included, still do development on a fairly regular basis. What does the Managing Director job at thoughtbot actually do?

JOSH: What don't we do [laughter] is maybe a better question. Effectively, we're running that team's business. So it involves some amount of software consulting. It involves software sales. It involves managing the profitability of the team. There are marketing functions, and, I don't know, anything and everything, hiring-related things. We opened up and recently filled our Development Director position, which was open for a couple of months over the summer. We've just opened up a Design Director position. So it's everything. [laughs] It's everything it feels like.

CHAD: At the beginning of this year, we did an episode about the changes that we had made at thoughtbot to reorganize the teams around rather than geographic studios around the types of work that we would do on that team. And that's how the Boost team was created. So in that episode, we gave people an overview. But I'd love to hear in your own words, what makes Boost at thoughtbot different than the other teams, and what do you focus on?

JOSH: So what makes Boost different? I think one of the drivers, one of the motivators, is to embed alongside existing product teams, engineering, and design teams, and help them get better, help them grow as well as ship features and fix bugs. So I think that the way that I position it is if there's an existing product that's deployed, people are using it day in and day out. Hopefully, it's been battle-tested. There are probably some funky areas of the code. Those are the codebases that we're operating in. It might be a team of two people; it might be a team of 200 people. But there is an existing product and an existing team. They're looking for our support to help make it better.

CHAD: One of the things I love about Boost and the changes that we've made, especially relative to Boost, is that at thoughtbot, we really believe in integrated teams of designers and developers. And a big part of what we've always done has been to be a complete product design and development team that brings new products to market, big and small. And because we were one of the first consulting companies in the world to switch to Ruby on Rails and because of that deep experience with Rails, and scaling, and working on existing products, we had a significant number of customers who engaged us for development for that expertise, and to help them scale, and grow, and hire, and implement best practices or solve problems that they were having in their existing codebase or on their existing team.

And even though that was a significant part of our business, it was always something that seemed that we maybe even didn't really want to be doing it, or it was on the periphery of our marketing and positioning. And I was super excited when we officially created this team because it allowed us to acknowledge that this was a significant part of what we do, a significant part of our revenue, and to have a team of people that opted into doing this kind of work who would not only love the kind of work but want to even grow it and do more of it. And we haven't really had that for this kind of work. We've had individuals wanting to do it but not at an organizational level in an organization that supports it. That was more of a statement than a question, but reaction?

JOSH: [laughs] I think you're spot on. It's always been interesting to me to hear that it's...obviously, at thoughtbot, we have been building MVPs and working with a lot of different types of companies over the years and helping them launch products. But I think that the type of work that I and, ideally, obviously, other people on the Boost team enjoy working on is existing platforms and working alongside existing teams. We talk about legacy systems, and I think they get a bad rap. And it's like, no, it's battle-tested.

CHAD: [chuckles]

JOSH: The business has proven its viability. It is still around years later. Conway's law applies in all of the stuff. Again, there are gnarly aspects of the code. But I think that's what the folks on the Boost team enjoy being challenged by is problems where these things are larger systems. They've been around for a while, and they do get pretty gnarly.

CHAD: I think one of the things that held us back in the past is that it is a skill set, and it's an experience. And you are going to be on an MVP project where you're doing design and development, going from concept to launching of a new idea, usually in a matter of weeks, working directly with a founder or a team of co-founders. And then you rotate on to this significantly larger project with maybe an engineering team of tens or dozens or hundreds of other developers on it. It's a very different skill set, and you have very different challenges in that environment. And when you're constantly switching between those different kinds of projects, you can't necessarily get better at it. And that's one of the other things that I think is helping us be more successful.

JOSH: I remember one of the teammates had joined the kick-off call with me at the Boost inception that very first meeting. And it was Joël. And Joël had asked pretty straightforwardly, "What is the expectation in terms of project rotations?" Because I think historically across the company, we'd aimed to do two to four-month engagements before we'd rotate folks. And I told him point-blank it's going to be six months to a year probably. And I don't think it necessarily shocked him or other folks on the team.

But I think when you're going into existing codebases and working alongside existing teams, there is inherently politics at play and complexities at play where it might take you being a new developer on a team six weeks, maybe longer before you actually feel comfortable and confident navigating the codebase and knowing where you can have and make an impact. And so, I think some of the shifts there have been particularly interesting to watch the types of consulting conversations that we have within the team just because it is a different beast, I think than building and launching products.

CHAD: So let's get into a little bit of detail about the kinds of projects we're doing in Boost to the extent that we can give specific examples and maybe more importantly and relevant to the audience, what are the things that we see? What are the common challenges that we see as products grow and evolve, as teams grow and evolve? What do you think one of the most common challenges that people have is?

JOSH: As teams grow and evolve, I think a lot of teams run into onboarding issues and general knowledge sharing. I think when you start a small team, and you're two, three, maybe five engineers, it's pretty easy for everyone to keep probably the entirety or the majority of that domain in their head at any one time. As you work to scale a team...there's a client of ours right now where they're effectively doubling every...I don't know what the time period is, but they're growing very, very rapidly.

And the feedback that some of our team have provided to them is it's really hard, and there are very much knowledge silos. And they're working through, okay? How do we tease this out? How do we share this context so that you don't have a couple of folks that are effectively blocking every single other member of the team? And so that's one of the core areas that hangs up our team and other teams. [chuckles] Our clients bring us on, and a lot of times, it's like we're rip-roaring and ready to go. And it's like, I need information from a bunch of people, and the processes aren't in place such that we can be as effective as we would want to be given the nature of work that we're doing.

CHAD: I think that's a straightforward problem, and it's a good example...I don't want to make this an hour-long thoughtbot commercial. But I'll just point blank say one of the reasons why sometimes working with us is positive for clients is it's really easy to have a certain pain around your onboarding process or company, even just simple things like how long it takes to get a new person a computer or to ramp them up on their existing team. If you're just hiring an employee, it's easy to ignore the cost of that.

JOSH: Yes.

CHAD: But when you're bringing on thoughtbot and we have a specific start date, and it's a certain cost, and those kinds of things, it can really expose the pain that is already happening but was just being ignored and provide the impetus to actually fix the problem.

JOSH: One of the things that we try to set out to do on the first day for any project is to open up a pull request to the codebase, whether it's an improvement to the onboarding like the README for the repository or whatever it might be. Ideally, we are finding ways to contribute on day one. And sometimes, that's frankly not realistic for individual contributors doing it from their own machines. But oftentimes, we'll know that going in. And as we onboard new folks and things like that, we'll say, okay, well, day one is going to be your pair programming over Tuple or some other tool so that you are able to engage and interact with a team and work on the code, even if there's still a bit of a lag between GitHub access and everything else that's the base of onboarding steps.

CHAD: So another common one that people bring us on to help with is scaling challenges in terms of the actual product itself, maybe that's performance or other scaling challenges. I'm working on a project now where that was how we first got involved. The service was failing, and it was only getting worse under the increasing scale. So, what are some tips that you have for how to effectively solve some of those problems while not bringing everything else that you need to accomplish to a screeching halt?

JOSH: At the end of the day, you can't fix something that you don't know is broken. Or you might have a hunch in terms of, oh, I know this page or this set of pages are slow. I think so much of what we see is teams come in, and they're like, "We don't have New Relic setup." We don't have an instrumentation setup. So they can't measure anything. And so it's like, I know this page takes three or four seconds to paint, but I don't know why. And I don't know how to fix it. It's like, okay, well, the first thing that we need to do is set up some amount of performance monitoring and application tracking just to get a sense of what that's like.

There is a potential customer who had reached out back in January of this year. So this was weeks into Boost's inception. And they said, "Listen, we've got some performance-related issues. We don't really know what to do, but we know the application is really, really slow on these couple of pages." It's like, "Are you using New Relic, or Scout, or anything like that?" They're like, "No." It's like, okay, that's the first thing that you need to do.

And they came back about a month ago and were like, okay, "Here's the access to all of this data. Now we're ready to go," and it's like, "Yes!" They probably didn't need to wait for that long. But it really speaks to that in order to address some of the performance-related stuff; we need to have some sense of what is going on and where.

I know Steph over on The Bike Shed Podcast had talked to Nate Berkopec. And she had floated one of the questions I had had. And he basically schooled me on that podcast and reiterated it really is ultimately about measuring so much of what we're doing.

CHAD: Yeah. One of the things, especially for teams that are having a problem but feel like they don't know what to do it's tough when it's actually the case. But the reality is a lot of times; there’s actually very low-hanging fruit that it's just no one has the time or experience to actually identify that. And putting some monitoring in place combined with actually taking the time to look through it, especially if it's the first time you ever hit scaling problems...There's either a missing database in that index or some N+1 queries, and fortunately, once you identify that kind of problem, it's usually fairly quick to fix as well.

It's a different thing when there's maybe fundamental architecture things that are causing your app to have scaling problems. But it's very unlikely that those are the first problems you're ever experiencing. The first problems you're ever going to experience if your app is running slow are going to be things happening at the database level or missing an index or something like that. And it's very unlikely that significant architecture changes need to be put in place in order to fix the first scaling problems that any product usually has.

JOSH: That wasn't the type, or at least I think when we got brought on, and you were working on your most recent clients, we were well beyond...maybe we weren't, maybe I'm misrepresenting or misremembering, but it feels like we were well beyond some of the low hanging fruit.

CHAD: Yeah, there was a batch of low-hanging fruit. One of the things if you're working on a product that is scaling super rapidly, what can happen is that the low-hanging fruit masks the other problems that are happening there because it all happened too quickly, all at the same time. And that was the case on this project. So it went from having hundreds of people using it to millions of people using it in the span of a month. And so there was low-hanging fruit.

But removing the low-hanging fruit didn't make the app suddenly work again; it just made it so that we could look at the metrics and say, "Okay, those things are no longer the problem." The real problems are not being masked now. We now can identify the architectural changes that need to be put into place in order to operate at the scale.

JOSH: Yeah, it's the low-hanging fruit when the orchard is on fire. [laughter] That is true.

CHAD: Right. So you got to peel back like an onion. And this is the case with I think a lot of...whether it be a technical challenge or a team challenge. You can't always come in and very quickly solve the root problem. You might not even know what the root problem is. You just have to start solving the problem that is obvious in front of you and learning more. And then you solve that one, and then you expose the next one, and you expose the next one.

And even when you can identify the root problem, you'll be like, this is the problem, and everyone agrees it's the problem. It still might be too hard to actually fix that problem. It might be an organizational or a systemic problem. And instead, you say, "Okay, we have to iteratively solve that problem." And you start peeling back those layers to get to the point where you've positioned yourself to solve that core problem. And I think we face that a lot, particularly as external consultants. We're coming in, and we can't just be the bull in the china shop. Because we haven't built the trust with everyone necessary to make the changes, or we don't know enough to know what the changes need to be.

JOSH: Right. And I think the people aspect of all of these things in my opinion...and I should caveat this with I've been writing software professionally for almost 20 years. The people, in my opinion, are always the harder aspects to any engagement. It's very rare that we go into a technical project where it's like we literally cannot figure out a technical solution to this thing. We can usually figure it out. And it might take weeks or months to implement, especially as it spans multiple systems. But more often than not, it's really navigating the people and the relationships and building that trust like you had mentioned that is really what will help dictate success within that project.

CHAD: I have a line that I use fairly often, and it's that I really believe very few, if any, developers sit down and are like, I'm going to write a bad solution today, or I'm going to write bad code today. That's not what people are doing. I think the majority of people genuinely try within their entire capacity to do a good job. And so that means that when I'm coming into a situation where there are problems, or things are messy, or there were bad decisions or bad code written, it can't be chalked up to like, oh, that was a bad developer, or that was a bad choice that was made. There was usually some people or organizational problem that caused that to happen in the first place. And merely fixing the bad code is not going to be what we should focus our time on. We probably need to do that. But if we don't fix the reason for that problem in the first place, it's just going to happen again.

A really popular example of this is when we get approached to do a Rails upgrade on a very significant product that is very behind with Rails. First of all, it's very expensive to do that on a very significant project if there's no test coverage. People could hire us to spend and spend a lot of money just getting to the next Rails version. But if they do that and don't solve the reason why they were so behind with Rails and have no test coverage and all that stuff, along the way, it will have been wasted effort because in a year or in two years, it will be back to the way that it was before. And that's one example that's very technical. But that kind of stuff happens all the time, even with squishy things [laughs] like the structure of a team or something like that.

So if you could give advice to people that are struggling with a particular problem, what would you tell them? And let's maybe make it a little bit more concrete. Like, one thing that can happen is as teams grow, like you said, not everyone can know everything. And so it starts breaking down into pods; maybe is one way to organize the team. And then you've gone into a bunch of individual teams working on discrete features. And that's happening fairly quickly. What are some ways to manage that change and manage that growth while maintaining continuity and making it go well?

JOSH: I think a lot of it depends on the goals from the technical leadership in terms of areas of ownership. That'd be the first part that I would dive into, I think. We work with clients where they segregate front-end from back-end development. And that allows the teams to focus on React and TypeScript versus Ruby or Go or whatever their back end is written in.

But if the goal is to share that knowledge, I think you've got options in terms of lunch and learn and shared code review and team demos and things like that. There are other ways to spread that information across the team so that everybody still has maybe not intimate knowledge of the code that's being written on a day to day basis, but they're at least aware of those patterns and practices and what each of the individual pods is may be responsible for and is delivering. So you have that team cohesion across more of the functional space, on the engineering side or on the product design side.

CHAD: One thing that I think I would also add is that a lot of times, people take for granted how better developers will do their job if they understand the reason or the business drivers behind what they're working on. And it's really easy for people to take that for granted because it's like, there's a ticket to the ticket. It says what to do on the ticket. [laughs]

JOSH: I have a blog post about this, actually.

CHAD: [laughs] Okay, great. We'll put that in the show notes. But if someone doesn't understand the reason behind that, it's not going to go the way that you're expecting frequently. It's not as straightforward.

JOSH: Yeah. You're left guessing what the underlying customer need is. And if you're guessing about the motivations, I don't want to say not in absolutes, but you're likely not going to address all of those core needs and implement an effective solution.

I think in the blog post that I had written, ultimately, it was advocating for getting engineers to participate in customer interviews and really understand, like, how are people using the product that I am implementing features for? Because without that exposure, without seeing those pain points, oftentimes, it's okay, you've got a product designer or a product manager who's putting together this list of things to do. And if it's treated as a checklist or oh, I need to go implement XYZ without understanding why that needs to be done in the first place, what is the pain point? What is the customer-facing? How are they feeling as they're going through the product? Without that context and without that empathy, the solution is going to be...it might functionally work. But will it be a good user experience? Will it be a good customer experience? It's a little bit more shaky, I think.

CHAD: Yeah. And in a fast-moving, fast-growing startup where everyone has a lot to do, if you're experiencing this kind of problem, it might manifest to you as stories get caught up at the beginning stages of when a developer is supposed to be working on them. And you find yourself having calls about what something is even supposed to be or supposed to do. And as the person who originated that ticket or originated that idea, you might have the feeling like, I can't believe we're having this conversation. Like, we don't have time to educate you about all the reasons why this is important and just please just do what we've said on the ticket. That is a natural reaction to that thing.

And so my advice would be if you're feeling that, if your team is feeling that or something similar, there's probably something small you can do. It might not even be having developers participate in discovery or interviews or anything. It might be as simple as just making sure that on the ticket you say why it's important. If your ticket is a checklist of things to change or do, making sure that the reason why is communicated there will go a long way to having the person pick up that ticket, get the context necessary to understand, and make good decisions as they work on it.

JOSH: Yeah, I remember the switch to the jobs to be done format. And I remember just being like, oh, [laughs] this makes a lot more sense because we can understand the context and the why. What is driving it? What is the problem there rather than what is the solution? And I think that shift in mindset does go a long way, like you said.

CHAD: I think one of the ideas behind a well-functioning team is we talk about this idea of collaboration which is you feel like you're doing your best work, that things are moving quickly, and you're enjoying the people you're working with, and you're building upon each other's ideas, and you're making things better as a team.

And I was recently talking to someone else, a candidate for VP of Engineering at one of our clients, and they were talking about flow, the idea of flow. And it wasn't a way that I had articulated it previously, but it's certainly another way of thinking about and a good way of thinking about it, especially when it comes to what is the role of a VP of engineering? Or what is the role of a CTO at a small company? Or what is the role of a development team or a product team in general? And one way to think about that is to work to maintain a flow state.

And when we think about the processes that we have in terms of retrospectives where every week we gather, and we identify things that could be better, and we come up with action items, a lot of the things that drive what could be better or what we want to try to do differently are all identifying the things that take us out of the flow state and trying to fix that problem so that items flow from beginning to end smoothly, that they go from concept to production smoothly as quickly as possible, and that individual people know where the next item to take is that it's ready so they're not blocked as they begin it. And they're able to get that to staging, and get a pull request out, and get that reviewed quickly, get it to staging, get that reviewed quickly, and then deploy it to production. And in theory, even do a continuous deployment so that that whole flow is automated as much as possible. So this idea of flow resonated with me. Has it resonated with you?

JOSH: Yeah, I agree. I remember seeing the comparisons people saying, okay, you're not actually looking for an engineer's passion necessarily. What you're looking for...and I come back to the hiring side of things because I'm doing that right now. But rather than looking to assess passion, it's assessing capacity and ability to get into a flow state more quickly. And obviously, so much of that is dependent on the team, and the communication style, the management style, and things like that.

But flow is very much...I think once you get into that and you know how to get into that like you said, every waking moment is spent trying to optimize how do I get into this space? Because when you're in that space, when you're flowing, be it from an IC level or above, there's nothing quite like it. It's just this calm state of just everything feels like it's firing all the time perfectly, and it's good. And I think trying to make those spaces available for the rest of the team to get into that state and maintain that state makes a lot of sense.

I remember years and years and years ago, there was the focus on maker versus manager time. And we talk about anchoring manager time either at the start of the end day or around lunchtime or whatever is a logical time for a break. The idea is to maintain that flow state for as long as possible so that nothing else eats into that. Because you do an hour of writing software, and then you've got a 30-minute one-on-one with a teammate. And then you go, and you run for another hour, hour and a half, and then it's another half an hour meeting. It's like you're being sucked away. It is really hard to get into that zone and then stay there. So I think there's been a focus on it for a while. And I'm really glad that there's now a name and a thing that we can point to.

CHAD: I don't want to lead people astray about what Boost is. There's a big important part of Boost, which may not be immediately obvious to people, and that is design. I may have insinuated that design wasn't part of Boost before when we were talking about it, but it is. And it's designed on existing products and existing teams which is a different need than going from concept to launch of a new idea.

JOSH: So we had done some work with The New England Journal of Medicine. And their team, a very small team, internal team, had basically designed an application. And they ran into a number of accessibility and usability issues. They continued to hear feedback from a lot of folks saying, "This is not effective for what we're looking to do." And they'd engaged us in a couple of different times basically to rip apart and re-architect some of the application hierarchy and the usability side of things.

It's been really interesting to see okay, well, within the design side of operating within existing products, it's often lended or leaned more towards doing some amount of a design audit and usability audit, talking to customers. And less around we're going to start from scratch and more what are some of these iterative improvements that we can make to make the product more accessible, easier to understand, easier to navigate, easier to use within what is, again, these very large platforms sometimes?

CHAD: I know one common request we get is we're thinking about implementing a design system or introducing a design system with the first version of the product. And we're having this growing pain around introducing new features. Is a design system the right thing to do there? That's a request we sometimes get.

JOSH: Yeah. And I think a lot of it at the end of the day, what we're looking to assess is what are the knowns? How much do we know about the application, about the interface? We talk about on the software development side of things avoiding premature abstraction, and I think the same thing is true about design systems. Like, if we're going through a product, maybe it's a wizard, and apart from forms, the pages are individualized, and there's not really any common patterns. It's like, okay, well, maybe now it doesn't make sense. But when you've got an application that spans hundreds of pages, there are going to be patterns across the different pages in terms of application hierarchy and componentization and things like that.

And the work that we're oftentimes brought in to do is let's assess what's there, figure out what are the common patterns here. And it's almost like refactoring and teasing things apart to where we get slight...it's a reduction in code use or rather an increase in code reuse because we're removing some of the idiosyncrasies that maybe were not teased apart into some component-based system. And that's fun work. [chuckles] It's really interesting.

You get things like React when you're doing client-side rendering. And within the Rails side of things, there's a big push for the GitHub ViewComponent. RubyGem is another example. It's both ways to introduce these layers of abstraction that allow more of the engineering team to take on more of the application development, not because design isn't necessary, but they're then empowered to reuse these logical set of components. And so it amplifies the dev work, but it also amplifies the design work because the entire team is now leaning on that pre-baked work. It enables designers to shift focus and priorities to okay; what are new components? What are different ways to position this or present this information? And also, for our designers, it frees up their time to talk even more to customers, to people using the system.

CHAD: Well, I guess we'd be remiss if we didn't do a more blatant plug. You mentioned it earlier, but we do have an opening for Design Director on the Boost team.

JOSH: We do.

CHAD: So who would be a good fit for that role?

JOSH: That's a great question. I think a couple of the things that we're really focusing on for this role is someone who has done the work, so to speak, at an IC level for a lot of the work that we're doing right now with customers. And so we ask point-blank on the application sheet, have you worked in HTML and CSS? Have you facilitated design exercises like design sprints? Have you facilitated user interviews? Because so much of what we're seeing from a vision and a strategy perspective is we need to take and leverage these tools in the skill sets that our teams are looking to hone in on, and we want to take it a lot further. I think there's a big opportunity there.

So I think it's less around years of experience. I wouldn't say you need to have 15 years of management experience or having been a director in order to apply for the role. But it's someone that can empathize with the team and has some opinions and some thoughts in terms of okay, what is design? What is not only visual design but product design accessibility? What does that look like in the next 5 to 10 years? Those are the people that I would love to see apply.

CHAD: If someone's interested, where's the best place for them to do that?

JOSH: thoughtbot.com/jobs. And the listing is there.

CHAD: So what's next for Boost, Josh? What do you have your sights set on as we wrap up 2021 and head into the next year?

JOSH: Oh boy. A lot of where the focus has been on this year is continuing to double down on Rails as the technology stack and get our feet wet, not that our feet aren't wet, [chuckles] continue to invest on the front end with React. I think for 2022, I think the big focus...we've run in the past some pretty successful custom trainings workshops for engineering teams. I think one that we had done earlier was late last year into early this year. We ran about 120 or so of their engineers through a custom RSpec course.

So we worked with their engineering managers and some of their teams and got a sense of okay; given this codebase and given the skill sets of this 100-plus person engineering team, where should we focus? And we put together a two-day RSpec workshop. We administered over; I think, five or six weeks. We did it virtually. And the reception from that was incredible. They ended up bringing us back on. We're getting ready to start another round of consulting work where we're embedding alongside their teams. So I see that as a huge opportunity for Boost coming into next year.

And then I think one of the things that we've been pushing for is reducing some of the billing time from folks in leadership positions so that they're in a better position to support their designers and developers. And I'm really excited about the progress that we've made thus far. And I'm excited to continue carrying that into next year.

CHAD: Awesome. Well, thanks for taking the time to talk to me.

JOSH: Thank you.

CHAD: Part of this new season, Season 11 of the podcast, for the next few episodes, I'm going to be talking to each of the managing directors at thoughtbot about their teams, about the different kinds of work we do on those teams, and the challenges, and what phases are clients in those different stages of the product lifecycle.

So you can subscribe to the show and find notes for this episode and all the other episodes at giantrobots.fm. If you have questions or comments, email us at hosts@giantrobots.fm. You can find me on Twitter @cpytel. Josh, if folks want to get in touch with you or follow along with you, what are the best places for them to do that?

JOSH: Definitely Twitter. My handle is @joshuaclayton, all one word.

CHAD: Awesome. Thanks again. 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: Joshua Clayton.

Support Giant Robots Smashing Into Other Giant Robots