GitClear CEO - Bill Harding

(Joel Beasley at 00:00:00) Today we are talking to Bill, the CEO at GitClear, and we discuss new ways of measuring developer output, what it takes to be an effective communicator, and how to hire and retain the best talent. All of this right here, right now on the Modern CTO podcast. Here we go. This is the Modern CTO podcast.

(Bill at 00:00:28) Hey, hey, hey. How you doing?

(Joel Beasley at 00:00:31) What up? How you doing, buddy?

(Bill at 00:00:33) Pretty good. Still a little bit early in PST, but I'm waking up.

(Joel Beasley at 00:00:40) Nice. We could have done it later in the afternoon, but we got you bright and early and fresh.

(Bill at 00:00:45) I'm supposed to—this is supposed to be when a person's at their best, right? Like when they wake up and I have all this energy and the coffee is starting to flow through my veins, and I'm getting there.

(Joel Beasley at 00:00:56) So when you wake up, do you go, like, on a run? Like, how do you get started?

(Bill at 00:01:00) I just sort of drag myself out of bed. I think that someday I aspire to be one of those people that, like, gets up and does something positive, like exercise or starts the day off on the right foot. But right now it's just, like, yank myself out and just kind of trudge to whatever my first thing is. And then once I get the caffeine start going through my veins, it gets better.

(Joel Beasley at 00:01:26) Yeah, it took me a while to start the exercise stuff in the morning, but then it's like anything, right? You build momentum, and it's impossible to stop.

(Bill at 00:01:37) Yeah. How consistently do you do it?

(Joel Beasley at 00:01:40) Seven days a week.

(Bill at 00:01:41) Wow. Damn. Look at you, Mr. Goals and Ambition.

(Joel Beasley at 00:01:46) I wouldn't—I don't know. I just, like, it's addictive, right? Like, so I start—I wake up, I do, like, a 20-minute run, like, run a mile, mile and a half, and then make some breakfast, see the kids, and then go to the gym and lift weights for, like, an hour, and then come home, shower, and then go to work.

(Bill at 00:02:10) Wow. That is far beyond what my expectations or my long-term goals are. My long-term goals would just be to do the first part of what you're describing, the 20-minute, you know, mile or mile and a half. It does seem like a good way to sort of wake yourself up, right?

(Joel Beasley at 00:02:29) Yeah. So I noticed, like, I wouldn't have continued doing it if there wasn't benefit, right? Because you and I, we had an awesome lunch a couple weeks ago, and we were talking a lot about personal and professional development. And there is just such a difference when I'm weight training and exercising as far as how my mind works.

(Bill at 00:02:54) That's it. Yeah, I can see why it would be, especially for a job like yours where so much of it is interacting and being alert. That's what you're doing, right? Like, you're prepping your brain, and the body is what gives the brain all its energy, so it makes sense.

(Joel Beasley at 00:03:11) Oh, I never did this as an engineer. This is all post-engineering. Yeah, because the socialization of it—and you're a CEO, so you know, I think you probably get a lot of benefit out of it. But that transition of doing deep work to then interacting with people is really tough. It's really tough for me to do. Like, it's hard—it's taxing on my brain to be able to do it.

(Bill at 00:03:37) Yeah. Absolutely. Yeah, it's a tough context switch.

(Joel Beasley at 00:03:41) So I want to make sure that we get started with talking about GitClear because, I mean, it's like layers for me, right? Like, you first get exposed to something and you're like, okay, this is cool. I've seen this a couple times before, but then you're like, all right, well, here's what makes it different. And then I was—you know, we were kind of going back and forth on sales copy and ideas and things like that and benefits. And, you know, I read it again leading up to this and I checked in on it a couple times. You know, you gotta let that break happen mentally. And now I'm, like, in love with it.

(Bill at 00:04:12) Oh, thank you.

(Joel Beasley at 00:04:15) And you're a really good writer too. Like, I didn't notice until actually today that you had, like, in one of your bios, there's a line that you actually like writing, but you are really good at writing.

(Bill at 00:04:28) I think that's very generous. It's something that I think any CEO or person that is the face of their company or creating the content for their company—even if it's not something that anybody starts being good at, nobody starts being good at being a manager either, but if it's important, then I think you have to learn to have the discipline to cultivate more expertise in that. And so for writing, I've never been an avid reader just because I have so many other things in my life that are competing for my attention. But the internet makes it possible, even if you're not an avid reader, to be able to dig into some topics really deeply from a few people that can present content in bite-sized chunks like Wait But Why, Paul Graham, Slate Star Codex. Those are a couple of my gold standards.

And seeing how they do it and seeing how they are able to stay so concise and to create value for the people that are reading, all of those—I just try to figure out how they're doing that and how I can create that same value for people that are trying to learn about developer metrics. And so I think every year I spend more time on this and I try to get a little bit better as a writer, but I still certainly don't consider myself an accomplished writer. I just consider myself somebody that has to communicate and tries to pay as much attention as possible to what the really smart people are doing to be able to create that communication, right?

(Joel Beasley at 00:06:05) And one of my favorite books about writing comes from—it's like Robert McKee. He's, like, a scriptwriter. But if you watch how people talk in scripts, like, if you read a movie script—

(Bill at 00:06:17) Yeah.

(Joel Beasley at 00:06:18) It just doesn't—it's not how people actually dialogue, but you watch it and your brain fills in the blanks. And so I found—and I read a lot of books on writing, and I've had to communicate with board members and do all that as a founder. But this was, like, relevant, but completely over in a different area. So it gave a fresh perspective. Like, here's how you write stories professionally. And then you can leverage some of those skills and attributes in your work to better understand how people perceive it.

(Bill at 00:06:48) Yeah. Yeah, that's fascinating. I mean, there are so many different elements to it, and Paul Graham actually has been talking about writing more on Twitter lately. It's become kind of his main—I guess, his last hobby standing as he's kind of transitioned into being a father more than the founder of Y Combinator. And he's had a lot to say about sort of all of the—not tricks that go into writing well, but the tenets of being able to be an effective communicator and being able to consistently surprise your readers and to have material content beyond the first sentence of every paragraph and all these different aspects that go into it where you can spend a lifetime trying to get better as a communicator and trying to become more concise.

And it will still be interesting because there's still more to learn there. And so I love learning, and it's really fun to try to get a little bit better at it. And we've definitely seen a lot of positive results from my efforts to be a writer by way of the traffic that comes to GitClear, which at this point is still at least 50%, I want to say, content marketing—you know, the articles that we write for people that are trying to learn more about measuring developers. They're trying to learn more about how all the different products in this space compare to one another. And every week, we're getting more traffic than the week before because, you know, I keep trying to polish and make more useful the resources that we make available to people to get answers to those kinds of questions.

(Joel Beasley at 00:08:22) No. And one of the things that just popped into my head right now is—I don't know if I shared this with you at lunch, but one of the biggest things that I've learned with content marketing is separating the individual writing the content with the person who's going to layer in call to actions. Did I say that to you at lunch?

(Bill at 00:08:41) No. You didn't. I didn't get that one. Yeah, that's a good idea, though.

(Joel Beasley at 00:08:45) It's, like, it's so impossible because I ran into this—like, the best experiences in life are the ones that you bang your head against the wall for, like, ever, and then you figure it out from someone else when you're crying, like, "I can't get it." Yeah. Separation of roles. Like, don't be the person that writes the article, but then also tries to figure out how to convert people in that content to it. Like, have a separate human being do it because you get emotionally attached to the writing and you don't imagine, like, how you're going to do the call to actions. It's just—I don't know how to articulate it well because this is one of the first times I'm talking about it. But experiencing it, if you have a separate person look at your beautiful piece of work of value, of content value, and then they figure out how to layer in call to actions, that's, like, the winning sauce.

(Bill at 00:09:34) Do you think that part of that is that as the writer, to be able to create the most effective piece, you have to be kind of single-minded in what you're trying to accomplish? Is that part of it, you think?

(Joel Beasley at 00:09:46) I think it is. And I've even tried to, like, take breaks, because, you know, I wrote the book that you have to go back and do separate takes. And I even tried to take breaks and come back, like, a week later to the writing and lay in the stuff. And for me, maybe I just didn't continue down that path long enough. I couldn't get it. And then I was talking about it with some other, like, way smart people in marketing, and they're like, "Oh, yeah. Yeah. You need to separate those two roles and just have a person who's really skilled at the conversion part," because they're going to try different conversions, and just separate the people—have the people bringing the value and the people figuring out how to convert the value. And I was like—I just hired someone on Upwork, and she did amazing, and it just worked super quickly.

(Bill at 00:10:30) See? This is what I'm talking about. Every day, you can learn something new about writing and become a little bit more of a craftsman in that domain. And I think that's part of what makes writing so interesting and exciting to me is stuff like this where—who had thought of that before? But it definitely sort of brings into relief how the process of creating the writing is something where you're already—it's so difficult because you're trying to put yourself in the shoes of not just one reader, but you're trying to put yourself in the shoes of all these different readers that are going to come across it from all different contexts, and that's hard enough unto itself without the whole domain of how is this going to benefit the writer. You know? How is this going to benefit our company with this content? So my approach has usually been to try to just not even think about how we're going to convert people that read the content, which probably isn't the greatest from a business standpoint, but I just try to focus on making it as useful as possible for people and kind of as short as possible, which I think I have had mixed results with. A lot of my articles are two or 3,000 words, so it's not the shortest. But the shortest that it can be that still gets across the questions that people are going to ask and sort of dives into the details where the details are important. And, yeah, I think to your point that having that be the single focus and having it be a separate area of discipline to try to actually convert that into desirable actions from the reader makes a lot of sense.

(Joel Beasley at 00:12:11) So how did you come up with GitClear?

(Bill at 00:12:15) Yeah. So it was very much a product of necessity. It was my response to trying to run an efficient development team on our Bonanza.com marketplace and just being completely unable to time-efficiently understand what the people on the team were working on and how I could help them become more effective in their job. And so, as we talked about, I'm a sort of a developer by practice and profession. I've been programming since I was 12, I want to say, and so I've always been kind of obsessed—maybe it's the right word—with writing code and how to improve code and how to make sure an architecture, you know, remains pliable as it grows and as it expands.

And being able to do that is pretty much a full-time job unto itself, but a great manager can do so much more than a single developer. A great manager can take a team of people that are all focused on that goal and get them in lockstep and get them working in the area that they're best at. But with the time that I had in a day after coding, I just had no realistic avenue through which I could understand what the developers on my team, which at the time, I want to say we had 10 or 15 developers—I had no avenue to understand what they were working on. It was really frustrating because all the time building the site, you know, we had a team of—well, originally just me, but a lot of Bonanza's history was about three to five developers. And at that point, you kind of can keep track of what everyone's working on. You kind of can know all the directories that are changing and what conventions people are using, what libraries they're using. But after you get past about five, it gets a lot more difficult.

And so the first version of GitClear was a response to that. It was basically simply a tool that we wanted to be able to aggregate all the different repos that we were working in. We didn't want to have to click from repo to repo like GitHub made us do. We wanted to be able to see the specific commits that people were making over the course of a day, whereas on GitHub, you know, all we had was basically a list. Here's 50 commits. Here's a list of 50 commits that happened today, but no context as to, you know, you're a busy person that only has 10 minutes to review these commits. Which one should you start with? And then being able to see how people are ramping up when they get hired and seeing how that compares to past people that have been hired. All of those were kind of these really painful points along with reviewing annual reviews where I would have to try to remember, like, what did this developer work on six months ago or nine months ago or whatever. All of these were things that were really time-consuming and that I felt like I was doing a very bad job at once the Bonanza team grew. And so GitClear was the response to that. GitClear was a tool that we started building in order to allow us to initially simply aggregate together all the commits that are happening across, I don't know, at the time it was maybe 10 repos, and isolate the ones where the most work was happening so that we could—you know, if I only had 10 minutes to review commits, I could review the three commits that really were pushing the ball forward that day within our repo.

(Bill at 00:15:40) And that could at least guide me towards answers on how the new developers on the team were getting up to speed and sort of what the high points that a person had worked on over the last year were, so that when I was doing those kind of manager-specific goals, I wasn't just relying on gut feeling, and I wasn't just relying on intuition, both of which I am deeply suspect of. I was relying on data, and I was able to make, I think, much more informed decisions, even in the early days of GitClear when our metric was much less reliable. And, you know, we were just kind of trying to figure out, is this even possible to build something like this? But it was, you know, from the earliest days, it was creating a lot of value. And obviously, we've gone a long way since then. So that was why we started it in the first place.

(Joel Beasley at 00:16:29) And we were going back and forth with these notes, and I was like, this is actually a really cool service. And then I realized that you own the note service that we are using too.

(Bill at 00:16:41) Yeah. I'm passionate about tools because I believe that every person, you know, has whatever luck gave them in terms of their talents, you know, the things they're naturally gonna be good at. But beyond that, what we're gonna get done is a function of the tools we're using. And, you know, a lot of my life, I've been a handyman, and I probably didn't own an electric drill until I was 25. You know?

(Bill at 00:17:10) And so much of my life, I spent, like, manually turning a screwdriver, turning a screwdriver. And when I got that drill, I'm like, I can get 10 times more done now. And I think that's what I'm trying to do with both Amplenote, the note-taking app that you referred to, and with GitClear. I'm trying to build tools that allow me with the very limited mental faculties I have to be able to get a lot of stuff done by having much more leverage over sort of the domains in which I reside, which are, you know, programming and productivity. And so the fact that myself and our team get to help other people when they adopt these tools and get leverage themselves is icing on the cake.

(Bill at 00:17:53) You know? But for ourselves, we're dogfooding these things every day, you know, because they are the key to what allows us to run our business. We need these tools, and so I think that's a great way to be oriented when you're setting goals and when you're sort of road-mapping what a product can potentially be. So we have more work than I think is reasonable for a team of our size between the different projects we're maintaining, but we love it, and we're using them every day. So it seems to work out.

(Joel Beasley at 00:18:28) Yeah. So I want to talk about, like, my favorite things about it. Right? Because I spent so much time researching it and looking at it. So, like, and here's why.

(Joel Beasley at 00:18:38) So the first one would be, like, the answering the question, who are domain experts? Because before we met, like, months leading up to meeting, it's been a topic of conversation that's happened a lot on the podcast. People discussing, like, oh, we're making these tribes, like, Slack channels where we have, like, experts in different areas. And so you can go in there and learn all about this, like, who's the best at, you know, like, Redis or whatever it may be, whatever is important to the company. And then when I was looking at you in the notes, one of the things you had was you had this report and it could show you, like, who are the domain experts within the organization based on who works on what, like, type of code. And I thought that was amazing.

(Joel Beasley at 00:19:18) Can you talk a little bit about that?

(Bill at 00:19:20) Yeah. Yeah. That's, I totally agree that it's sort of a very common and maybe underappreciated aspect of what a good CTO does. They identify, or VP of Engineering as well, they identify who is already good at different aspects of contribution within their repository.

(Bill at 00:19:41) So it's really common in the teams that I've been a part of that you'll have somebody that's really expert in, say, the libraries or the sort of the underlying platform like Ruby on Rails. You'll have another person that's really great at models, and you'll have another person that's really great at sort of background jobs and asynchronous execution and making sure that's safe and performant. And then you kind of go further and further up the stack till you have people that are expert in HTML and people that are experts in JavaScript. And obviously, there's gonna be overlap because a lot of people are working in different domains, but I think that especially if you're a project manager and you're trying to understand who do I go to with my questions, or who do I send this ticket to that's a really difficult ticket in a domain that's gonna require somebody that really knows, you know, the ins and outs of React, for instance. And those are really hard questions to get answers to unless you sort of methodically observed a team over the course of several years, in which case you can eventually, like, develop an intuition for that.

(Bill at 00:20:49) But, again, like, we're trying to build tools that create leverage. We don't want people to have to wait years before they can really intuitively understand where the people on their team are experts. And so what we do with this report that you're talking about is we take the line impact, which is our metric for how much the code base is evolving from commit to commit, and we are able to basically analyze that in all the different dimensions and all the different types of code that we already recognize just out of the box with GitClear. So pretty much all the kinds of code I've off-handedly used as examples—Ruby on Rails, models, jobs, JavaScript—all these are code categories that GitClear already recognizes. And so when developers are just doing their job, when they're just making commits that happen to involve all these different types of files, we, first of all, know how much experience they have with it because we can see that they've authored more code than anybody else over the last year in, for instance, React.

(Bill at 00:21:52) Then we can also get a sense for their velocity because one of the other really hard elements of what GitClear offers that none of our competitors do is we are able to approximate the time required per commit. We're able to basically estimate how much time a developer had to spend to implement whatever feature, branch, or ticket that they're working on. And so once you have time and distance, you have velocity. And velocity is, I think, a really valuable way to be able to compare how people are relating to different areas within the code so you can figure out who's the fastest at writing models, who's done the most at writing models. And so then when you have a question or when you need a really important feature to be implemented, again, you're not guessing. You're consulting data that's already available, and you have the answers at your fingertips to be able to understand who on the team is gonna be best suited to answer those questions.

(Bill at 00:22:57) Or if it's a new developer, they might not even know themselves sort of what their areas of expertise are. So you can help a new developer sort of learn about themselves through these kinds of metrics. So, yeah, that's one report that I think I've been really excited about and a lot of our customers are as well.

(Joel Beasley at 00:23:14) The other one I really like, so I kinda rank my favorites in order of, like, business value. Well, that one was because it's just been a popular conversation, because I was telling people, like, to go check, like, New Relic and stuff,

(Bill at 00:23:29) you know, just to find out,

(Joel Beasley at 00:23:30) like, what areas are really popular in the application. But one of the other ones that I really liked was not waiting, like, three to six months before helping new hires. So how do you do that?

(Bill at 00:23:41) Yeah. So that is, I think, probably our most popular feature and probably our most valuable feature. It's basically a cohort report, and so I'm guessing a lot of your listeners are familiar with the idea of a cohort report. But basically, you look at, for everybody on the team that was at the same point in their tenure, how did they compare at that point? And so what we're able to do is we can look at the full commit history for developers for however much history you have in your repo, and we can say for everybody that you've previously hired, for their first, say, two weeks, for their first three weeks, for their first four weeks, how much code were they writing in that time?

(Bill at 00:24:22) Because it's often really nebulous, unless you're a lead developer that's paying very close attention to this new developer, how they're ramping up and whether you are putting them in a position to succeed. It's really easy to forget, if you're a developer or a manager or a CTO that's been working on a team for years, that when you first come on to the team, you have to set up an environment. You have to learn all the systems that are at play. You have to sort of use whatever documentation is available to understand and orient yourself as to what the conventions of the project are and where the code in the project exists. And so if you're not, if you don't have a means by which to measure how quickly people are getting up to speed, then all of these different areas that make it really hard to start at a company can be sort of neglected or ignored because you don't realize how hard you're making it for people to start and get up to speed quickly on your team.

(Bill at 00:25:19) And so what the cohort report does is it allows a manager, basically from the day the person is hired, but I think, realistically, you probably need four to six weeks of data to be able to actually see patterns in how the developer is ramping up. But every week, we can show this is the last 50 people you've hired. This is how much they got done on their first week. This is how much, you know, the new developer has got done on their first week, week two, like, week three, week four. And so very quickly, you start to be able to aggregate statistics around the number of weeks that the developer is performing about average to past hires, above the level of past hires, or below the level of past hires, in which case you usually want to have a conversation, kinda understand what the factors are there.

(Bill at 00:26:06) But the way that we've seen customers use this and the way that we've used it ourselves is as an opportunity for us to identify when we're doing a bad job of making it easy for people to set up an environment that allows developers to hit the ground running, or if we've done a bad job of documenting sort of what the systems are, then those first weeks are going to be a little bit slower. And so what we want to see is every developer we hire getting up to speed more quickly than the developer before them, which is possible if you have the right systems to measure what the experience of a developer is when they're joining your team and sort of the ability to understand what the roadblocks are for those early developers in terms of what's making it difficult for them to start contributing and just jump into the code base. So I think it's a super important question because, you know, a lot of what CTOs have to do is hire the best possible team and retain the best possible team, probably VP of Engineering even more than CTOs.

(Bill at 00:27:04) But both of those jobs are very, I think, specifically and rightly concerned with making sure that they have the best people in place. And if you hire somebody and then just aren't able to go and help them within those first critical few weeks when they might be struggling to get up to speed, it can sort of, I think, color their interpretation of the company throughout their tenure. You know? So you really want them to have a positive experience at first and you really want them to be successful from the day that they're hired, and that's what the cohort report is trying to create.

(Joel Beasley at 00:27:43) So what's your, like, what's your couple favorite top ones? Or I guess we'll just say what's your most favorite one even if we've already talked about it. I'm just curious.

(Bill at 00:27:51) Yeah. Well, honestly, my favorite one is probably the first one that the developer has taken to or the manager has taken to when they log in, which is maybe no surprise since I have a say in which one we go to after logging in. But it's the commit activity browser. It's the view of the code where it allows me to basically answer that first question that I'd talked about when you'd asked me why we built this product. I want to know who's working on what today and who is stuck and, like, what are the big changes that are happening in code so that I can know when there are new conventions or opportunities or bugs or anything that is coming into the repo that could create problems or opportunities down the line.

(Bill at 00:28:40) The commit activity browser makes it really easy to spot all that stuff, basically from the instant you log in, and it's just kind of fun and cool to look at. You know, it's, my original history as a developer was making Game Boy games. And so myself and the CTO, actually, of our company worked together on this game called Disney Friends, which was just this, like, ridiculous piece of IP that was like a Nintendogs clone. I don't, do you remember Nintendogs for the Nintendo DS?

(Joel Beasley at 00:29:14) Oh, yeah.

(Bill at 00:29:16) Yeah. It was a big hit ten years ago or whatever where you, like, take care of your dog.

(Joel Beasley at 00:29:20) Because we played this game. It's

(Joel Beasley at 00:29:22) like advanced Tamagotchis.

(Bill at 00:29:24) Exactly. Well, so we made Tamagotchis, myself and the CTO. We're really proud of this. We're not really proud. We made, we made Tamagotchis out of, like, Stitch, and we made Tamagotchis out of Nemo from Finding Nemo and from all this Disney IP because our studio was tasked with making this Nintendogs rip-off.

(Bill at 00:29:45) But what I took from that history, which is several years, like, my formative years as a developer, was that it really matters. It feels good to use a game and, like, all those, like, swishes and swoops, all those transition effects between different states within the game contributed so much to what our review scores were for the game and just from how much people experienced enjoying the game. And so I've tried to bring that same sort of feel and the same sorts of, I don't know, exciting transition effects and interactions into the commit activity browser. And so there's a lot of, like, you click a bubble and, like, the thing scrunches up, you know, and the things fly away. And I just try to make it kinda feel like a game, and it's an effective way to sort of distract oneself from the fact that, you know, reviewing code is sometimes a little bit, it's not something people look forward to. But it's so important to review code that if we can make it more fun, it's a big win for everybody, I think.

(Joel Beasley at 00:30:49) Yeah. It has a very, like, not to get too nerdy, but it reminds me of, like, a like a d3.js library. Mhmm. Like, the interactions is very

(Bill at 00:30:57) similar. Library. Oh, okay. Good. Cool.

(Bill at 00:31:00) Your intuition is on the mark. Yeah. It's, that's the only way to be able to get the physics that we needed to be able to make it feel, like, more fun or lifelike, you know, as these commits are bouncing around and you're sort of arranging where they fell in the day, like, or a week or whatever range the person wants to browse commits for. So, yeah, the d3 has a really great physics library, and that's kind of the cornerstone of what makes games feel fun and interactive and relatable as they have that touchpoint to the real world. And so that's an aspect of what I incorporated into the commit activity browser and trying to make it feel fun.

(Joel Beasley at 00:31:41) Yeah. After I saw that, I was like, I was talking with Jake and some other people at the office, and I said, you know, we should take it when people unlock their badges in our, like, when they finish the course for our leadership program, we should animate the badge, like, being unlocked versus it just popping up and being like, badge. It should be like the actual, like, intricacies of the badge. And so I have, like, an animator guy that I go to whenever I need, like, small animations. But with those little finishing touches on it, like, they definitely have, there's a time and a place when they go into the project.

(Joel Beasley at 00:32:11) Yep, right? Like, after you're very clear about what the business value is and you have some customers, like, you figure it out. But they're so small, and they're just really important in polishing the user experience. And I love you guys because your Amplenote, I didn't actually look a whole lot at the how do I say it?

(Joel Beasley at 00:32:32) Bonanza? Bonanza?

(Bill at 00:32:33) Yeah, you got it. Bonanza.com.

(Joel Beasley at 00:32:35) Bonanza. I didn't look at that a lot, but I spent a lot of time on Amplenote, and I spent a lot of time in GitClear. And your design, like, just shout out—I hope your designers are listening to this podcast, because it's amazing. Like, it's so beautiful. I just, whenever I recognize great design, I like to tell people good job.

(Bill at 00:32:53) Well, it's hard to make time for a lot of those finishing touches, right? Because that's not—you're not gonna be able to substantiate, like, this is the ROI we're going to get from this last 5% of polish. You're not gonna probably be able to measure that, animating that badge that is unlocked when a person is able to reach the achievement that you're setting for them. Like, you're not gonna be able to measure how that 5% improves people's happiness or satisfaction. You just have to sort of trust that it will. But since you can't measure it, you know, so much of our business processes are built around focusing on measurable victories. And so it's sometimes hard to wedge in time for satisfying interactions. And to me, it's just sort of a visceral pleasure that I get from using an app or an experience that feels like it's polished and feels like it's connective and has nice transitions there.

(Bill at 00:33:52) And so I definitely appreciate the compliment. We'll send it along to our designers. We've tried to imbue that throughout the products that we're building, that kind of satisfying last 5% that goes a little bit above and beyond what's necessary or what's gonna be measurable, but hopefully is creating user experiences that people can recognize and enjoy. And even if they can't pinpoint why they like it so much, they just feel good when they're using it.

(Joel Beasley at 00:34:22) It's like being in a nice store. Like, you know, you definitely wanna go shop in Target more so than other stores because it's got like, there's a nice experience. Like, I don't care if I'm paying a dollar or two more. I like being in this environment. And if you have to work in an analytics program or, you know, you have that need to do these things and understand these things, you wanna be in one that's really great.

(Bill at 00:34:47) Yep. Yep. I'd say that the other factor that goes into that that is sometimes overlooked is the speed of the experience, right? Because this doesn't apply to Target as much, but for websites and for user experiences that a person is gonna have online, you know, it's the same feature that you're implementing, whether it takes five seconds to load or five hundred milliseconds to load, but the experience of the user is going to be very, very different if every time they want to scratch some itch, they have to wait five seconds before that itch gets scratched.

(Bill at 00:35:20) And so that's another, I think, really important tenet of a site that people enjoy using and that serves its users well. It has to be fast to have to sort of imbue all the rest of that polish and all the rest of that experience within the sort of wrapper that the user gets. And so that's another aspect that we try to be really good at, and it's obviously difficult because it's sort of the counter to complexity. Like, we want to create really rich and really informative graphs, and the more richness and information is in a graph, the slower it's going to be unless you work really hard to make it fast. And so they're kind of two poles that are always pulling at each other, and there's going to be a balance there. But, yeah, I think that game users are—video game users are a great audience that really helps bring about or I think communicate what a lot of our primal desires are in terms of a great user experience.

(Bill at 00:36:24) It should be fast. It should be connective. It should be beautiful, and it should thus be pleasant to use. And to whatever extent that we're accomplishing those things, you know, that's what we're trying to do. That's what we're here for. And you wanna just combine that with creating value for people to sort of make the whole package of what gets a person excited to use a new tool or a new product they haven't tried before.

(Joel Beasley at 00:36:50) So when you're going through the sales process of this, like, who is buying and why are they buying?

(Bill at 00:36:57) So it's a lot of different reasons, and I think that there's—it's reflective of the fact that there's so many unmet needs and so many opportunities that exist right now in this space. I imagine that, you know, a lot of your listeners might still be earlier in their career, and they might still be sort of getting up to speed as CTOs or VPs of engineering. And what they're probably doing, which is kind of what I was doing earlier in my career, is working really, really hard to, you know, potentially really long weeks to be able to get an edge and to be able to understand things better than their peers can understand them. And working hard is great, and I, you know, have sort of been lucky enough to end up in a domain where even if I'm putting in a lot of hours, it doesn't feel like work because it's just fun to be able to solve these problems and to be able to create these experiences like we've been talking about. But when you sort of run out of hard work energy and you run out of smarts, all that's left is the tools that you have and how those are going to be able to make you more effective.

(Bill at 00:38:10) And so when it comes to what people want to get out of our product, it's really—there's a quite a breadth. It's sort of, I think, similar to the list of things that people expect out of a CTO or at least there's a strong correlation there. Some of the things that people expect out of a CTO—they expect them or a VP of engineering—they expect them to have some sense for who the domain experts are, like we talked about, some sense for how quickly people are getting up to speed and whether it's easy for them to get up to speed, some sense for where the technical debt resides in the project, and then just are the policies of the company—like, are those conducive to developers getting work done and being happy? I would say those are probably a handful of the questions that people bring to us most often.

(Bill at 00:38:59) And so our demo process or our process of introducing users to our product is just asking them, what are your biggest problems? Because, you know, over the course of all the demos we've given, we've collected a very wide breadth of different problems that people will bring to us. I guess PRs and, like, communication in the PR process is another really big bucket of problems that people will sometimes bring about, and we have solutions for those problems. We have kind of incrementally built our product around understanding what are the needs of the CTOs that come to us and that have been working really hard. And, you know, they're smart people, but they just only have so much time in a day.

(Bill at 00:39:42) And we wanna be their performance-enhancing drug. You know? Like, we wanna be the resource that they can consult to be able to answer whatever their engineering questions are. And if they have a need that GitClear doesn't yet address, well, those are a lot of our best features. Right now, we've been working with a user that's onboarding from a small company, and he has brought us a lot of good ideas around being able to identify when a Jira ticket is filed as a bug and how long does it take for us to resolve the high-priority bugs that get filed into Jira, and what can we learn about those bugs both in terms of how long it takes us to resolve them and what code was changed in the course of resolving the bug, which is sort of an indicator for where the bug came about—like, which commit, which developer, what are the circumstances that created the code that needed to be changed to resolve this bug.

(Bill at 00:40:44) And so that is, I think, a really interesting question to be able to have better insight into where bugs are being created and how quickly they're being resolved. And so that's another example of a feature that just by asking people what they want and listening, we're able to really rapidly evolve our product in that direction. And so it's maybe an overbroad answer to your initial question, but, yeah, there's all sorts of different areas that we'll tap into in the course of the demo, and it really just depends on sort of what the CTO has identified as sort of the biggest opportunities or the biggest learning areas that they want to be able to focus and better understand within their team because we have tools for pretty much whatever those problems they're going to bring to us are.

(Joel Beasley at 00:41:37) Have you narrowed, like, your ideal customer profile? Like, we want companies that are, like, $100 million in revenue with 200 to 300 people that are growing at, like, 40% year-over-year because we know that they have this one, like, meaty thing that we just do amazing at.

(Bill at 00:41:56) Yeah. Well, I would say that it's evolving. I think that through a lot of our history, our sweet spot has been the teams that are in a position like I described Bonanza in—you know, when we built GitClear—teams that are scaling from having three to five developers where the CTO could really have the time and energy to comprehend every change that is happening and they're scaling up to more like 10 or 15 or 20 engineers. That's really been a sweet spot for us because those teams—they crave tools like the Commit Activity Browser and like the Directory Browser, tools that allow them at scale to be able to see what their developers are working on and not have to have a stand-up meeting every morning where you have, you know, 15 or 20 minutes spent talking and 15 or 20 minutes spent preparing for it and then 15 or 20 minutes spent afterwards sort of digesting the takeaways from those meetings. I'm not saying all stand-up meetings need to be taken off the calendar, but I'm saying there's definitely a cost to those.

(Bill at 00:43:01) And I think a lot of the small teams feel that cost acutely, and I know that we acutely felt the cost of any sort of fixed scheduled meetings that we subject our engineers to. And so that has been traditionally the sweet spot of GitClear has been those smaller teams that wanna understand what their developers are working on, what tickets their developers are working on, and what they should be focusing on in terms of the domains that they send different tickets towards and the domain expertise of the developers. But what we're really finding as GitClear grows in popularity is that there's also a really big opportunity for larger teams in terms of being able to compare the performance that they're seeing across regions or across different agile methodologies that the sort of sub-teams within a large enterprise will be adopting because, in effect, every team when you have a really large company, and I'll try to use an example of somebody that isn't a customer of ours yet, say Microsoft, you have all of these probably thousands of teams that are all kind of little experiments.

(Bill at 00:44:17) They're all little productivity experiments in a sense where they're gonna have their own sort of agile practices. They're going to have their own meeting structure. They're going to have their own, you know, conventions around what should be filed as a Jira and whatnot. And so it's really difficult, using really any tool that exists to understand, like, how can we compare the output of these experiments? How can we measure which of these experiments is really working well and sort of understand why it's working well?

(Bill at 00:44:50) And so that's a new market that is really starting to catch on amongst the new customers that we're seeing is the market for being able to identify which of the teams that are within an organization are getting a lot done and are not creating tech debt in the process, and then being able to sort of interview those teams and model more of the organization or at least expose more of the organization to the practices that are working really well for these sub-teams. And so that's, I think, a really big opportunity for us, you know, in 2025 and beyond is being able to help managers take the—interpret the results of all these teams, all these experiments, these productivity experiments that are happening and take the best from all of those so the entire organization can sort of have this cross-pollination of ideas and practices and meeting structures that will work best, that measurably work best for whatever the company's domain is. Obviously, if you're a fintech company, your concerns are gonna be a lot different than if you're a healthcare company or if you're a Silicon Valley startup in, you know, B2B space or whatever.

(Bill at 00:46:09) They're all different kinds of companies need different kinds of practices, and so there's not any one right answer, but you can help your management find the teams that have kind of naturally evolved their way to the best answers and then spread those teams' information throughout the rest of the organization. So that's—I think the answer is a little bit equivocating in that I'm not able to say a single user group that has been the only one that gets value from GitClear, but there's been a few different groups that have evolved over time that really seem to tap into what we're offering and get value from it.

(Joel Beasley at 00:46:51) We were just doing this exercise this past week where we took the customers—all of our past customers based on how profitable they were for us, and that was, like, one metric. And then all of our past customers based on who's having the most success, right? Like, who's most excited about it. And then all of our customers based on who we liked the most, just doing like, we like spending time with, right? Like, who we wanna be stuck in a room with. And then we took those three sets of data, and we came up with, like, our top, you know, five, 10 customers. Because we want to figure out, like, exactly how we attracted them, exactly why they bought from us, because we are, like, getting to the point where we realize, okay, this is gonna be a long—you know, we're two or three years into this, and we're like, we're gonna spend another five, 10 years doing this.

(Joel Beasley at 00:47:43) And so we wanna make sure that we find and service the customers who we enjoy spending the most time with, who we're having the most success, and whatever. And wouldn't you know, they all came in from the same value prop. We've tried, like, 15 value props, but they've all come in from the same value prop. I know. They are—most of them are physically located, like, geographically, like, near each other. And, yeah. And then so we were like, now that made it really clear because, you know, the first couple years, you're just trying stuff. You know, you're changing your sales copy. You're trying new value propositions. You're trying to sell—you're talking to people. You're getting customers. You're taking who you can, you know, letting everyone sort of use the product. And then you're seeing, like, people having more success than others. And you're like, why? It's like, okay. Well, at some companies, their culture is different. So we just learned something about our business. Like, we are really good when a company has this culture.

(Joel Beasley at 00:48:37) So how do we—how do we identify, like, companies that have that culture? Because I would rather have a—have my sales team, like, be able to tap a company on the shoulder and say, we need to talk to you because our product only really works with companies that are like yours, that have a culture like yours, that look like yours, that are your size. And when you do use these products, you were just fanatical customers who love us, who get huge results, and you're gonna tell all your friends. And here's the case study of the other five people that are just like you that have done this too. And you're like, well, that's—I never get that type of message on LinkedIn.

(Joel Beasley at 00:49:08) You know, I never get approached. I get bombarded with junk. I never get somebody saying, "Look, you have to take a look at our product because you're the only type of company that has huge success with it, and you need to see this because you're gonna love it." So we did that exercise, and it really helped us with our clarity for this coming year.

(Bill at 00:49:27) Yeah, that's fascinating. So what do you think—which audience was it that had connected, and why do you think that was? It's not too much of a diversion. It's just interesting idea.

(Joel Beasley at 00:49:37) So yeah, they tend—companies that have people that want to improve. Like, that's the first one. You cannot buy our management training for people who don't want to grow. So if that's in the leaders, if that's in the culture of the company, then they love it. The second thing is they're usually over a hundred to a thousand people. And they're usually in tech. They're analytics companies or—we have one animation company. They do animation for Happy Feet, like different kids' movies. And so yeah, those types of companies—they tend to be in technology, they tend to be making technology, and they tend to be over $50 million in revenue, about a hundred to a thousand people. And we just noticed that they have a lot of success with it. And so now we're like, that actually made everything really clear, because the biggest problem—you know, like, you've got to know that—you're a CEO, right? Like, you have a product and there's too many customers. Like, there's too many—it's like, where do I—do I go to enterprises? Do I try to sell to them? And however you pick, it determines what your sales process looks like. Like, what type of salespeople you hire, how you get the leads, how you service the leads. I mean, is every single one like a demo, or do they go free trial first? Like, all of that structures back, and so there's just too many possibilities. You can just run in circles and get real diluted real fast. And for me, that was my biggest struggle. Like, looking back on it, that's my biggest struggle—we loved the product so much and we knew so many people could use it. But we didn't have focus. So two years of just trying all types of customers and all types of value products just made it really, really clear what we need to do for the next couple years.

(Bill at 00:51:27) Yeah, that's—I think that really ties into something that's been true for me throughout my career that I've observed, which is that a lot of the best products have a really specific vision of what the product's going to offer and equally specific vision about what the product isn't going to offer, so that you kind of avoid becoming, you know, Microsoft Word circa 2010—I don't know if Word's still the same way as it used to be—or I'd say Evernote circa 2015 more recently. You know, like work chat. Like, we really wanna have chat in our note-taking app. You know?

(Joel Beasley at 00:52:03) Like, Evernote's doing that?

(Bill at 00:52:05) They used to. I don't know. They went through a really dark period. I hope they've come out of it. Or, actually, I guess I don't hope they've come out of it since we're competing against them now.

(Joel Beasley at 00:52:15) Amplenote for the win.

(Bill at 00:52:18) But Evernote, you know, I think is a perfect example of a tool that anybody can use it. Right? And so I think they've had a hard time figuring out, like, who are our target customers? What is our vision? Like, what is the key piece of value that we're going to just go so deep into that we blow people's minds that we understand them so well? And I think Evernote spent a lot of years, at least in the early 2010s, not having such a clear idea of who they were building it for and why they were building it. And so they went on all these—let's say, like, wild goose chases—but they went on all these misadventures of implementing features that are really only tangentially related to what I would consider their core value proposition: allowing people to capture all their ideas and information and have that organized. And because of that, they both wasted time not working on advancing the core functionality that people would really need, but they also added clutter to the UI. They also made it more difficult for the people that just wanna use it for its best purpose, because there was that much less clarity around where you should be focusing your attention. And so I love that you guys have been able to narrow down—these are the organizations that just when we tap into these types of companies that are passionate about growth, that are passionate about improving and becoming a better version of themselves every day, those are the people that we can create a ton of value for. And so what do those people need? How can we use that to build the minimum set of features that are really easy for that group of people to understand and use? And if other groups of people can get value from that, that's great. And maybe you eventually sort of try to acknowledge those other groups in whatever ways can make sense in context. But I think that it's still really important to have a solid idea of why you're building a product, who you're building the product for, and what the minimum functionality is that you can get by with and thereby avoid sort of the easy heap or the easy problem that a lot of companies fall into, which is just this dog pile of features. You know? This—we're just gonna add more value props. We're gonna add more customer endorsements and testimonials. We're gonna add more widgets and more things for people to click on. You know? Like, it's an easy path to run, and it's a really understandable place for people to end up since you just get there by listening to everybody and trying to accommodate everybody. But I think the best products have a more specific viewpoint about who they're trying to satisfy. And it sounds like you're building one of those products yourself by way of understanding who your target ideal customers are that have gotten the most value and then building something that's really optimized around those people. Right?

(Joel Beasley at 00:55:20) Right. And like, for you, you want the people using GitClear who are going to have the most success with it. Like, because what they're going to do is everybody talks. Like, they're going to go around and just scream it from the mountaintops, like, "This is actually really cool." And the thing is, it takes time to get into it and see it. So it's like, you know, how do we get—how do we reduce the time to value? Right? Like, how do we get it so that they can see the value as quickly as possible? And I love how you guys had done that where you offer a sample repo too, so they could actually see it working in a fully existing repo while their repo imports and all of that. So I really enjoyed that. Like, how do we get—I guess, like, what's the call to action? You have a free trial on the site?

(Bill at 00:56:03) Yep. Yeah. So we have a free trial. A lot of our customers will request a demo, and so we can sort of walk them through the features. Like I said, there's so many different questions that we can answer, and usually the best way for us to create value for people in a time-efficient way is for them to tell us sort of what their challenges have been or where their organization has struggled over the last year, and for us to use that to sort of guide a conversation with them. The best of these conversations happen when the user has already imported a couple of their own repos. We allow—I think we might be the only product in our space that allows this—but a user can just sign up for a GitClear account without having to go through some account manager or salesperson or anything. And so they can, from our home page, sign up for an account and import up to three repos. And we can then use that data in our demo so that we can talk specifically—and this is kind of what I spend a lot of my life doing these days—I can talk specifically to a company. Like, this is what I'm seeing on your team relative to similar companies that we've looked at. It seems like your developers are sort of losing productivity—say, Friday morning was a recent example that I've done. It is a really popular time to do the learning and to do, like, you know, company improvement. And so there's value to that, obviously, but there's a cost to it as well. And so you just wanna make companies conscious of the decisions they're making. Right? And Leaderbits is, of course, a decision that in the long term is gonna make them a much more effective company. But in the short term, you can measure and see like, "Oh, but we got a little bit less programming done right at this time." And so that's really what I try to focus on is—I think, you know, a point that you've made during our lunch that I've reflected on several times since is that you always wanna be the person that's creating value for other people. You wanna dedicate your life, in as much as a person can do something so grandiose, but you wanna dedicate your time to understanding what people need and to give that to them in sort of the best, smallest package possible that solves their needs and understands them deeply. And for us, what that looks like is people importing their actual data and us going through that data with them to show them—basically, this is how your team is operating today. This is what your team is working on today. These are who your domain experts are today, and these are what we think your team could look like tomorrow. This is where we see opportunities for us to be able to help you make your developers more productive, to be able to get answers to their questions more quickly, to be able to understand their own work. All of those things become possible when we can really have a one-on-one conversation with a customer using their own data and basically walk through it to them and help them get that edge that they need to understand their team on a really profound level. So that's usually how people sort of end up becoming GitClear customers is they're curious. It only takes, you know, five minutes to start that repo import. And if that looks good, then they'll have a conversation with us where we talk about the data. And if that's all the value we can create for them, so be it. Like, we're happy to give free ideas about where a team looks like it's stuck or where opportunities might be. But if they get value from that, then we can go so much further to give them a tool that they can use every day to better understand their team and that their developers can actually use to understand what their peers are working on and how they can become more proficient themselves. So that's what we're trying to do.

(Joel Beasley at 01:00:08) I have an idea. I have an idea. Okay. So—it is—we could love it or hate it. It's okay. So you're all about measuring things and data. I think it'd be cool to take a company, whether it's one of our customers or one of our newer customers, one of your existing customers, and maybe that has 10 engineering teams. Right? And then we put analytics across all 10, but we only give five of them management training. Right?

(Bill at 01:00:37) I like that. Yeah.

(Joel Beasley at 01:00:38) And we—like, we'll do a baseline where we track them all without any training. Like, we track all 10—I don't know, exact—I'm just off the top of my head. We track all 10 teams for two or three months. Just get a baseline. Then give one of the teams—management training. So their leaders, they understand vision, motivation, how to grow their teams, how to inspire them, how to focus, like, how to get them to work from the human level of things. And then we let the data speak.

(Bill at 01:01:04) Wow. That's great.

(Joel Beasley at 01:01:05) Like, to see—can we make a measurable impact on the engineering team through management training? Like, because, you know, no leadership company wants to actually do this. Like, they're scared to death of it that it's not gonna work. Right? Like, I see what happens because we have over 1,500 people on it. It's like, we know it happens. But it would be so cool to have a third party. Right? Like, to have GitClear's analytics running on it, and then have our stuff come in, because then it's like—it just makes the data more truthy. Right?

(Bill at 01:01:40) Yeah. Absolutely. I mean, that's what I think. It's a beautiful idea, because I think that any earnest attempt to improve has to be informed by measurement. You can have all the great feelings in the world that "I'm learning something. I understand something better than I did before thanks to Leaderbits." But if you can't measure that and if you can't actually sort of prove out those outcomes with unbiased data, then, you know, there's 10 other potential improvements that you can make that you could also feel like they're going well and also could not be measured. You know? So what makes that idea so captivating, at least for me, is that we want to create the measurement that allows people to run experiments like that. You know, it's like what I was talking about earlier where, in a sense, a large enterprise is just a hundred productivity experiments that are running where you can understand, like, which of these teams—which of these experiments is actually working, which of these teams is getting the most stuff done, which is closing the most tickets, which is having the most code written, which is reducing the most tech debt. Whatever is important to the team, whatever metrics matter to their project managers or their CTO, GitClear can help them measure that. And so an experiment like the one you're proposing here becomes really potent way for a company to multiply, you know, by potentially 2x or 3x or however much the efficacy of what they're doing and how much they can get done, which is sort of the very definition of what a successful company is. A company is getting a lot of stuff done. So I think that makes a ton of sense. I would love to help participate in whatever way we can to run a sort of a control-based experiment where we could try to pick apart—like, does this help? How much does it help? What kind of teams does it help? And how can we sort of create more of these outcomes for other companies that could benefit from that kind of instruction? Yeah. We definitely have to try it.

(Joel Beasley at 01:03:45) With, like, two or three different companies and 10 teams each. Why don't I ask around? If you're cool with that, would you do a free trial with them for a couple months? We could actually do, like, a co-branded case study or something.

(Bill at 01:03:57) Yeah. No, that's great. Yeah. I mean, case study is a big area that I think is an opportunity for us, and we just—it's kind of like, you know, like what I was talking about earlier with the last 5% of polish. It's something that I know we should do, but it's really hard for me to carve out time to create a well-orchestrated case study. So it's something that's sort of perpetually "we're almost doing this." But I would love to be able to create a real, substantiated study that people could go to and would present them evidence in a well—from a well-controlled setting as to what they can realistically expect to get from, you know, both from the combination of their practices from GitClear and from Leaderbits. And so I think that sounds great. I think that could really sort of go straight to your MO, which is creating value for people.

(Bill at 01:04:54) I think that makes a lot of sense on a lot of different levels and ought to benefit a lot of companies that could be run a little bit better.

(Joel Beasley at 01:05:04) Yeah. I've also seen recently, like, two or three companies in a space will get together and do something. Like, they'll do a case study or something together, and I thought that was kind of interesting. And I like you, so I don't mind spending time with you and hanging out.

(Bill at 01:05:16) But yeah.

(Joel Beasley at 01:05:19) I think, and I have the network to do it too. And I know that there's certain people out there that they really care, they want to improve, and it's like, I think that we could—why wouldn't they? Yeah. The people you want to be around, that's who it is. So let me, I'll drive it forward and I'll push around and see if we can get some interest from a couple people.

(Joel Beasley at 01:05:38) And then we can—I don't know? Yeah. That was spontaneous and fun. That was pretty cool.

(Bill at 01:05:43) What's the worst that's going to happen? You know? Like, Joel's spontaneous idea could get them 50% more measurable productivity—not just us telling them, like, it seems like your people are more productive. We can actually prove out that their team is doing better. And so I like it, and I would suspect that a lot of your network is going to like it too, because the worst thing that can happen is you get free services that make you about as productive as you were before.

(Bill at 01:06:10) Oh well. If you get free services that make you 50 or 100% more productive than you were before, like, cool. Sign me up.

(Joel Beasley at 01:06:18) Dude, this is exciting. This is a really cool podcast. Like, we did it, man. We made a podcast.

(Bill at 01:06:22) Holy cow. What? We did it?

(Joel Beasley at 01:06:24) We did it. It's done. But is there anything that we missed or that we didn't get?

(Bill at 01:06:30) I don't think so. No. I think—let me double check. Yeah. Yeah.

(Bill at 01:06:34) You asked a lot of great questions and—

(Joel Beasley at 01:06:37) Get a free trial on GitClear.com. Right?

(Bill at 01:06:39) GitClear.com. Yep. Get a free trial on GitClear.com, and it's—we also have a product, Open Repos, that a person can visit, and this is kind of another way that we try to make it really easy for a CTO or a VP to understand how GitClear works. And you can actually see GitClear working for a lot of the biggest open source repos that they probably heard of, like React or Angular or TensorFlow. All these different, like, really high profile open source projects, which a lot of companies have as their libraries, are instrumented with GitClear.

(Bill at 01:07:18) And so you can actually see the 20 developers that are working on these projects and sort of what their commit activity browser looks like and how if you were a manager of that team, you would be able to much more rapidly see sort of the domain of interest and expertise for the people on those teams. And so that's another opportunity to kind of click around. But really, like, the most value that we see created is when people will just sign up for a trial and then chat with us over a demo. So yeah, hopefully they'll come to GitClear and give it a shot, and we would love to try to help them.

(Joel Beasley at 01:07:52) Yeah. I'm not shy about promoting, like, really awesome products. So GitClear.com. And you get to meet—

(Bill at 01:07:58) I like it.

(Joel Beasley at 01:07:58) Bill and his team. Great people. Right?

(Bill at 01:08:01) I like it. I'm on board with that.

(Joel Beasley at 01:08:04) Dude, I'm excited.

(Bill at 01:08:06) Hell yeah. I'm pumped.

(Joel Beasley at 01:08:09) Well, you have a fantastic day, my friend. And then, yeah, we'll circle back as we start to produce this stuff and then as I get feedback from other people on the idea of the case study.

(Bill at 01:08:20) All right. Great. Thanks a bunch, Joel.

(Joel Beasley at 01:08:22) Talk soon, Bill.

(Bill at 01:08:23) Yep. Thanks. Bye-bye. You, bud. Bye.