Data-Driven Engineering Management with Bryan Helmkamp, Founder & CEO of Code Climate

(Intro Narrator at 00:00:04) Hello, my friends. Today, Joel is talking to Bryan, the founder and CEO of Code Climate, and they discuss how to implement data-driven engineering management with Code Climate, the impact that adopting a data-driven approach has on every level of the engineering organization, and how to think about creating a product that is a tool versus a product that's a solution. All of this right here, right now on the Modern CTO Podcast.

(Joel Beasley at 00:00:38) Here we go. This is the Modern CTO Podcast. I'm curious, can you share your background story?

(Brian at 00:00:54) Sure. Yeah. So I first had exposure, I think, to computers in elementary school, at school computer labs. And eventually I was able to convince my dad to buy me one at home just to kind of play around with, get on AOL back in the day. That was the way we connected to the internet, and just started to tinker a bit, both at home as well as with friends like in the neighborhood. I remember going over to somebody's house, and we had a Borland C++ thing on floppy disks and loaded it in and tried to create something that could write X's out to the terminal or whatever.

(Brian at 00:01:34) Yeah, just it was super interesting from early on and really kind of just stuck with it through school, pretty much knowing the whole way that I felt like, hey, this software engineering thing is really exciting to me, and I think it's what I'm going to want to do as a career. Went to school for computer science and did not finish. I actually dropped out to take a job doing software engineering at a consultancy in Michigan.

(Brian at 00:02:07) And I guess one thread that's sort of interesting and super fortunate, frankly, for me throughout my career is, after playing with things like Visual Basic and PHP early on, I found my way to Ruby and Ruby on Rails in particular as a programming language and framework by perhaps maybe 2005 or so, which was pretty early. There weren't very many people using Ruby on Rails commercially in the United States, and it was a pretty small community. And so that was kind of one of the big catalysts for me in my career as a technologist, was sort of finding a technology community and technology itself that was really powerful and new. And it ultimately became very popular, and there are so many successful businesses like Shopify that are built on top of this Ruby on Rails technology. But being there at the beginning for that was extremely impactful on me, on my career.

(Brian at 00:03:23) And I remember I used to go to some of the conferences in the programming language community. There was RailsConf, like the first one. And you'd look around and the folks who were sort of in the hotel lobby—I mean, I wasn't old enough to order a drink from the hotel bar at the time. I had to get other attendees to buy these drinks for me. I was 20.

(Brian at 00:03:43) But the people who were around at that time, so many of them went on to do amazing, big, great things. And it was great from a networking standpoint to kind of tie this back to your comment earlier. And that's really what brought me to New York where I am today. I got a job offer from somebody I'd known from a conference. Hey, do you want to do Ruby on Rails programming in New York City?

(Brian at 00:04:07) And it was basically just a cold offer. It's like, yeah, sure, I'm in. So I packed up, moved from Michigan to New York, where I've been since, and got experience working in a variety of different industries: mobile, social, e-commerce. Before Code Climate, I was working in an energy efficiency company, helping people figure out how to save on their power bill by giving them insights and recommendations. And sort of moved my way up from a software engineer to an engineering manager, and eventually prior to Code Climate, I was the CTO of that energy efficiency company. I had always enjoyed building things for other software engineers. So that took the form early on of open source software and just creating open source packages. They're called RubyGems in the Ruby community, that other people might take advantage of. And was fortunate to kind of work with some very smart open source contributors on some packages that were reasonably popular, and that was really rewarding to me.

(Joel Beasley at 00:05:09) Which ones?

(Brian at 00:05:10) One of them that was popular at the time was a package called Webrat.

(Joel Beasley at 00:05:16) Oh, yeah.

(Brian at 00:05:17) And Webrat—the R-A-T in Webrat stood for Ruby Acceptance Testing. So this was a package that you could use to sort of write a test harness for your web application, make sure that you can—that the application worked properly when it would click on buttons and fill out forms and whatnot. And that became—so people who have been working in Rails or Ruby more recently might have heard of a package called Capybara. And if you've ever heard of Capybara, you might think, why does it have this weird name for this giant rodent? And the reason for that is because Capybara was designed to be a successor to Webrat, and Webrat was the sort of the rat name being introduced, and Capybara became the sort of successor to that.

(Brian at 00:06:03) So that was one of them.

(Joel Beasley at 00:06:05) That is amazing. I don't know if you know this, but the last eight or nine years of my programming—basically, I stopped programming full-time when the podcast got really popular about three years ago. But up until then, you know, 17 years as a software developer, the last seven to nine were Ruby on Rails. Yeah, so I was—

(Brian at 00:06:26) You might have had some exposure, and I apologize for anything that didn't work well or properly. I ensured it was my fault.

(Joel Beasley at 00:06:32) Did you—were you a core contributor at all?

(Brian at 00:06:37) On the Webrat project, I basically was the lead on that. And I also had some involvement and exposure with the RSpec project, got to know the folks who sort of did that, contributed a chapter to the original RSpec book, which came out at that time. But yeah, this kind of got me into the testing groove—behavior-driven development, test-driven development. That stuff was all very interesting to me.

(Joel Beasley at 00:07:08) Yeah. No, it's phenomenal. I'm excited, though, because I don't want to get too technical with this stuff and make this whole interview about, oh, let's talk about Rails. So tell me a little bit—for people who don't know, what is Code Climate? What do you guys do?

(Joel Beasley at 00:07:21) What do you guys do?

(Brian at 00:07:23) Yeah, for sure. So the way that we describe Code Climate is an engineering intelligence company. And what that means is we make products that help people improve the way they do software development, their entire software development organizations. And the impact of that that we strive for, our sort of vision for a future state in the world, is what we think of as transparency, alignment, and efficiency for software development.

(Brian at 00:07:49) And I find that really powerful because, at least in my experience working on a bunch of different software projects over many years, unfortunately most software development initiatives tend to be lacking in one or more of those areas. And that's exactly what we try to help with. So the way that we do this is at Code Climate we connect to systems like DevOps and collaboration tools, places where engineers are working with PMs and designers day to day, things like GitHub and Jira and CircleCI. And we pull in all that data into our engineering data platform, and we take those signals, we analyze them, clean them up.

(Brian at 00:08:30) We turn that into insights that are intended to help boost basically the ROI of the software development group for a business. And the effects that that can generate are helping teams better focus on top strategic priorities, reduce the amount of time spent on interruptions, incidents, customer escalations, distractions, that type of thing, save engineers time and hassle, and ultimately be able to build better software products more rapidly.

(Joel Beasley at 00:09:00) You guys have a lot of features. I was checking you out recently, you know, before this interview. You do so much more than what you did in my head because, you know, it's been two or three years since I've been actively programming. And back then I had a handful of specific things, like the way I saw Code Climate. As you guys have expanded what you're offering in your features and things like that, what sort of—have you had difficulty with this, the fact that a lot of people see you as A and you're becoming B? Or what's that been like?

(Brian at 00:09:33) Yeah. Well, we've certainly evolved as a company. So we now have two products. Those products are called Quality and Velocity, and Quality was the product that we started with. Code Climate as a company—we're over 10 years old now. We actually celebrated our 10-year anniversary last year. It started as a nights and weekends project for me when I was a CTO and then sort of went through all of these phases from there, as a side project to, okay, I'm going to do some consulting and work on it on the side, and then, okay, this is going to be my full-time thing, but I'm not making a dollar.

(Brian at 00:10:06) So, you know, I'm starting to get nervous about running out of money, ultimately to being able to make some money on it. And we've grown a long way since there. We raised our Series C round of funding last year, which is a $50 million round of funding, and are growing very, very quickly these days. And so one of the first transitions was that change from being a single-product company with Quality to being a two-product company. And the Quality product is really focused on helping software engineers improve the quality of the code that they write in their software development workflow.

(Brian at 00:10:39) And that's where a lot of software engineers have familiarity with Code Climate as a company and as a product. The Velocity product has a what I would consider to be a much larger scope. So we launched Velocity in 2018, and the reason we did that is we sort of came to this idea that there might be an even larger opportunity to use data to improve not just the software code quality itself, but the entirety of the engineering organization. And that's kind of what we built and brought to the market with Velocity. So it is a lot bigger.

(Brian at 00:11:13) There's a lot in there. The way that we talk about the sort of the key groups of value propositions that we're able to help with, because it can feel really broad, is with the three pillars, which are align, deliver, and improve. And pretty much everything we do kind of rolls up onto one of those pillars. So with the align pillar, that's really about trying to solve these problems where you hear people say things like, you know, I have so many software engineers, and I just can't—I just don't feel like people are even working on the right things, right? We could go much faster if we could just get everybody rolling in the same direction. That's kind of an alignment problem.

(Brian at 00:11:45) And that's especially acute as you get into larger organizations, more layers, complexity, but it can certainly sort of make it feel like it doesn't really matter how fast we're going if we're going in the wrong direction. The deliver pillar is around taking units of work and getting them moving through a system rapidly and with low risk. And depending on who you're talking to in an organization, the units of work might be at different levels of granularity.

(Brian at 00:12:19) So an individual engineer might care a lot about getting their pull request merged. You might have a product manager who cares about their feature. And then you have engineering directors who are focused on big initiatives for the next couple quarters. But they're all focused on this delivery pillar. And then the third pillar is improve, and that's really about how can we, as a software development organization, improve our processes, our teams, and even as individuals level up the way that we are contributing.

(Brian at 00:12:50) And that was kind of where we sort of started, was on this improve pillar, and we've expanded to sort of support those three, and they kind of work hand in hand.

(Joel Beasley at 00:12:59) So let's go to align first. That's a key feature of what a lot of the project management systems are trying to solve, right? Like the Atlassians and things like that of the world. Are you providing them data to help with the organization? Are you—how do you—or are you guys actually trying to do—how do you do alignment, I guess, is the better question?

(Brian at 00:13:23) Yeah. So everybody has project management tools, right? There's always some sort of system that has tickets or issues, epics, whatever you want to call it. And what we find is that there are a few sort of roadblocks to that really being able to drive the level of alignment that's necessary to be successful.

(Brian at 00:13:41) First is you have all the work that's not represented as issues, right? And so that's things that are, you know, whatever it is—it's a skunkworks project, it's somebody getting pulled out of the hallway to go work on something, it's an incident that's on fire that never even makes it to an issue because the website's down and we don't have time to write an issue. And that stuff is totally invisible relative to a project management system. The next problem is the data is only as accurate as it's sort of been updated by hand, right? So you see all the time people will be working on things and the issue says not yet started, right?

(Brian at 00:14:17) Or conversely, it says in progress, but actually it's been done for two weeks. So any sort of visibility which is built on humans kind of going in and sort of recording exactly what state things are in or recording how much time they spent on something, which some organizations try to do, is really error prone. And then the third problem is that even if you kind of had accurate data, the project management system is really designed to serve the software engineering group in terms of the way that they are breaking down their stories. They might be estimating them with points, maybe they're creating an epic, maybe they're not. But if you go up to maybe the top levels of an organization and you have a CTO who's responsible for an organization with 400, you know, people in their technical headcount, and you say, hey, I've got some great information for you. I can show you where your time is going, and here's a list of epics and how much focus each of them got over the past quarter, it's 1,200 epics, right?

(Brian at 00:15:17) And so at that point, it's not actually communicative, communicative in terms of closing the gap between what people really need to see at a leadership level in order to help steer an organization effectively and what people at the engineering team level need in order to have, you know, small units of work with clear specs that they can kind of put into a sprint and complete. And so there's this big kind of chasm that needs to be crossed. And that's one of the things that our align pillar is focused on doing is helping everybody have a consistent understanding of, hey, where is our energy going? Where is our time and money going?

(Brian at 00:15:52) Is that where we want it to be? And how do we adjust to make sure that we're actually kind of going in the direction that we feel is most important so that everyone in the organization doesn't feel like they're being pulled in three different directions all the time?

(Joel Beasley at 00:16:05) And that's something you do today?

(Brian at 00:16:07) Yes.

(Joel Beasley at 00:16:08) And so I guess I'll just go later. I'm just curious. I want to look at how you guys actually do it because that's a really big problem to solve.

(Brian at 00:16:18) It is a very hard problem. Yeah. So, you know, there are a lot of ways to simply count up things like issues and look at we have, you know, this many issues that say bug on them, this many issues that say feature on them, right? But that is very rudimentary understanding.

(Brian at 00:16:33) So what we do is we pull in all this information. The nice thing about software development compared to, let's say, you know, sales—sales, they have their CRM system, and people build very advanced insights and reporting on top of things like Salesforce. But if a sales rep texts a customer and they don't record that in Salesforce, then it basically didn't happen, right?

(Brian at 00:16:55) Whereas with software engineering, in order to be most effective, we have these systems that we use to do everything in the SDLC. We have a version control system. We have a code review system built into something like Bitbucket. We have an incident management system, CI/CD. And all of these systems record everything that's going on and are able to understand on kind of an hour by hour, minute by minute basis, like, what's really happening across an org.

(Brian at 00:17:25) So if you take that information in and you are able to clean it up, link it together, run it through some data science, and then aggregate it up, you can start to understand things like, hey, last month, we spent 46% of our time dealing with incidents, for example. And, you know, the number of tickets that we had was three, but actually, we can see here that the pager is going off in the middle of the night. People are responding to that. And then we can start to get into where we're going in the future, which I think of as basically second order insights.

(Brian at 00:17:59) So, you know, something like PagerDuty can tell you at a basic level how often your developers are getting woken up in the middle of the night. But what PagerDuty can't tell you is the impact of your developers getting woken up in the middle of the night on your top priority feature initiative and how we can be pretty confident that your feature is not going to ship on time unless you fix your on-call rotation. Because the people who are responsible for building that feature, you know, that's Joel, and Joel isn't sleeping, right, because the servers are on fire every night. So there's a lot that you can do by bringing this information together.

(Joel Beasley at 00:18:32) That's pretty cool. I'm definitely excited to see those interfaces, and I think your company is perfectly positioned to do something like that because you're already at the core of the life cycle for everything that they do. So you're already plugged into all of these systems. And so you can connect multiple sets of data to derive some new insights, which I think is pretty cool.

(Brian at 00:18:56) Yeah. What we're doing on the data front is working on an open data platform for software engineering data. So if you think about the common concepts that are necessary to build and ship software in 2022, there's been some level of agreement on some of these terms and what some of the best practices are in different systems that people might use. So, an understanding of a package, a release, a review, a feature flag, which was something that not many people were using not too many years ago. But now these things exist.

(Brian at 00:19:30) They've been established, but they're all spread out across all these different systems. There's a proliferation of DevOps tools in every category. There's a dozen options. And so with our engineering data platform, we have defined a language of about 50 different data types for those types of concepts. And then the connectors that we have basically talk to those systems, bring in information that we can understand semantically, and then that allows us to build the insights on top of that.

(Joel Beasley at 00:20:04) You guys have been working hard. You didn't just stop at, like, you know, tabs and spaces validation.

(Brian at 00:20:13) No. We've come a long way.

(Joel Beasley at 00:20:15) Well, I love it. So what's the interesting thing happening right now? So you're the founder. You've been at this company, obviously, 10 years, right?

(Joel Beasley at 00:20:24) I've been at companies and built them, and you always have to find something to keep it exciting, to keep it fresh. Like, what's the thing that's really got you pumped up right now?

(Brian at 00:20:34) Yeah. Well, you know, my role has certainly evolved over the last 10 years. So we started as a bootstrap company. It was myself, my co-founder. And we were able to bootstrap Code Climate around our quality product at the time to over a million dollars of annual recurring revenue, but really by just wearing all of these hats ourselves. And we got to that point, and it seemed like this huge milestone, big victory, right? Like, oh my gosh. We're two, three people. We're generating a million dollars of revenue. I mean, just do the division. Like, isn't this great? But, of course, what we learned through that experience was that it really takes a village, and we needed more people in the organization in order to do all of these different very important tasks, like respond to customer inquiries. And at the time, AWS wasn't really a thing, right? So it's like, who's going to make sure that the infrastructure is the way that it needs to be?

(Brian at 00:21:25) And so we did end up raising some funding to be able to expand and grow the organization. And over the last 10 years, I've worn a bunch of different hats, dabbled in a number of areas, but I've been the CEO the whole time. And now we have, for example, a VP of engineering who's the person who's directly responsible for all of our technology. And I like to joke sometimes that I've taken up functional programming in the form of Excel spreadsheets, which are the closest I've got to functional programming, but it's absolutely functional. So, you know, it's a high-growth year for us. We're about 60 people today. We expect to finish 2022 with around 140 people in terms of headcount, so more than doubling our staffing. And so along the way, you know, my focus areas are as much product vision and leadership on one front, but also a lot of organizational building on the other side.

(Brian at 00:22:44) So helping to upgrade, you know, our processes. The top initiative on my plate right now is something that we refer to as our company operating system, and basically updating our firmware as a company, in the sense of, hey, how do we plan our goals and initiatives and what systems we use to communicate? Because, you know, the company has kind of doubled in headcount each year for the past few years. Everything basically breaks when you double everything. So, you know, just as, if you're on top of things and you can fix your problems as they come along, you get the benefit of that for maybe a year, and then you have to kind of do it all over again. So it's been a fun experience, sort of being able to work with so many great talented people and be a leader of an organization with so much talent in it. I was saying to my fiancée recently, sometimes I feel like a wizard. She's like, what do you mean you feel like a wizard?

(Brian at 00:23:21) I said, well, now, you know, if there's something that we're going to do, like, I can talk to people about it, and they go off and they do these amazing things, and they come back, you know, four weeks later. And they're like, oh, this is what we built. Like, let us show you this. And it's, like, amazing stuff that I could have never done myself. And it just sort of magic in a sense, because it just kind of came from this idea. And then the whole is greater than the sum of its parts in terms of the capability and organization relative to anything that I could have coded myself.

(Joel Beasley at 00:23:52) Oh, yeah. And then there's the, when you learn that you have that power, you learn to be careful with what you say because sometimes your suggestion—

(Brian at 00:24:06) —learning from folks who maybe are a little, you know, might be a little loose with some things they throw out. And then they're like, oh, wait a minute. I actually didn't mean we do that right now.

(Joel Beasley at 00:24:19) Right. Just out of curiosity, have you come across the EOS, the Entrepreneurial Operating System?

(Brian at 00:24:25) Yes. Yeah. That's a book that I think I've read once or twice. It's like an orange book if I remember correctly.

(Brian at 00:24:33) Yeah.

(Joel Beasley at 00:24:34) Yeah. We had one of the authors—like, it was written by a couple people, I believe. We had one of them in one of our group calls, like, a week or two ago. I think it was last week, and I hadn't heard about it before. And so I just learned about this whole enterprise. And they have, you know, all their own specific words and processes and everything. But when you said that you're rewriting your system, I was like, oh, that sounds a lot like the EOS.

(Brian at 00:24:58) Yeah. Yeah. We've adopted, starting a few years back, some of the concepts in here. I think we probably had maybe one or two years where the EOS system was kind of how we tried to steer the business.

(Joel Beasley at 00:25:11) So I want to talk a little bit about how you're—as an entrepreneur, I like to talk about the sales side of things too. I've—my first thought was, okay, you're probably getting, you know, all your sales because developers just know who you are. They've seen that badge on GitHub for the past decade, you know. That's how I found you guys, by the way. Like, you were on some open source projects and I could click this little Code Climate badge and I was like, what's this? And so I imagine that a lot of your business comes from developers using you and then sort of, like, expanding into some paid version, or are you guys, like, B2B calling up companies? How are you getting your business?

(Brian at 00:25:48) Yeah. Yeah. It's a great question. And we've always been really close with GitHub since back in the day. A fun fact is my GitHub user ID is 19. That was from day one, basically, when Tom and Chris, sort of, you know, threw that out in an IRC channel. They said, hey, we're playing with this thing. You know, you can sign up if you want. I signed up.

(Brian at 00:26:08) And so with the quality product, really, it grew and continues today to grow very much through sort of word of mouth and what we refer to as, like, a self-service buying motion. You know, you can sort of try it out. We have it available for free for open source projects, and there's hundreds of thousands of open source software projects that take advantage of the quality product that we offer. And then for private projects, you can, you know, activate a free trial and basically swipe a credit card, you know, at the end of a trial period. And we didn't have—you know, at the time, we were just a couple people. We didn't have sales or marketing or anything like that. And, you know, it was just about basically building something that people would adopt and be able to adopt on their own. You know, it does what it says on the tin kind of thing. There were some docs. You know, if you needed support, you can get support.

(Brian at 00:27:04) And that is a really great model for something like a developer tool like that. With the Velocity product, we got started, and we thought, oh, well, we'll just do the same thing. Right? Like, we'll sort of build the product, and then we'll give people a way to just, like, start with a free trial and a credit card form at the end. And what we learned was the difference basically between selling a tool and a solution.

(Brian at 00:27:31) So I think of our quality product as a tool. It does what it's supposed to do. It does it well. We have many customers, basically a thousand customers on the quality product. And many of them have been around for many years. But with Velocity, what we're really kind of selling is the opportunity to increase the ROI of your software engineering organization. And our customers are able to generate 30% productivity increase within a relatively short period of time of maybe six months through having access to these insights and then putting them to use. But many software engineering organizations or software leaders have not really used data to drive their groups historically in the past. There's been a lot of gut feel, anecdotes. When CTOs are talking to their leadership peers or their CEO, there's often a lot of sort of, hey, just trust me on this, you know, and I know what I'm doing. And so the concept of using data and combining qualitative context and insights with fact-based information is something that people are, in many cases, sort of learning to do for the first time.

(Brian at 00:28:49) And as a result of that, we found that it is really valuable to be able to sort of help talk them through the best ways to do that. So, if an organization is interested in talking to us about, let's say, our Velocity product, they've got a couple hundred engineers, we have experts and specialists who are able to sort of help them plot a course for how they're going to bring data into their organization. And we find that to be really valuable. So kind of learned the value of, in some cases, sales, right? We do have salespeople at Code Climate. I think sometimes engineers might think of sales as a dirty word or like a bug in a system that needs to be optimized away. But sales, when it's done well, is really about helping you figure out how to achieve what you're trying to achieve with an offering of product or a piece of software. And so it can be really mutually beneficial.

(Joel Beasley at 00:29:44) Yeah. I was blown away several years ago when I heard somebody giving a talk about the amount of salespeople at different technology companies. Companies you would think are, like, Netflix, right? There's a lot of salespeople at Netflix. It's like, what do you mean? You just go on there and you buy their stuff. Well, there's all sorts of licensing. There's commercial stuff. There's so many different things that you don't see. You just primarily see the private consumer version in your life. But, you know, people helping other people is, like, what makes the economy go. It's how we communicate and transmit value to one another, right?

(Joel Beasley at 00:30:23) And so when you can find a reason to have, like, more humans together, I find that the businesses tend to grow faster versus just trying to be a completely automated situation. Like, I've never seen, uh, or it's the exception, not the rule for a company to get really, really, really big and just be completely, like, automated and need no people, like, no customer service people, no salespeople. I can't think of any good example. Can you think of any, like, $100 million companies that don't need people?

(Brian at 00:30:54) Well, I think a lot of them—you know, a lot of software businesses, SaaS businesses that grow to that scale, a lot of them do introduce more enterprise sales motions as they go. Even Atlassian, which was sort of, like, famously kind of, hey, self-service. I mean, an Atlassian seat for a lot of their products is, like, $4 a month, right? So it's like, okay, you know, it doesn't really require a whole lot of hand-holding, but they've started to add more enterprise offerings and sales. But, you know, when businesses are able to grow sort of with that just fully kind of self-service approach, it's really magical and really cost efficient. I think Zapier is one that went a long way without doing that. I think they're starting to do more of that today, but just grew like a weed, massive, with a very amazing product and strong leadership and doing that through a self-serve motion.

(Joel Beasley at 00:31:46) All right. Common sales objections. Why do people say that they don't want to buy it?

(Brian at 00:31:51) Well, I think, you know, with something like Velocity, one of the things that people are always thinking about is, you know, what is going to be the impact on my overall software engineering organization, and, you know, how are my engineers going to feel about the idea of using more data to steer? And so that's something that we would, you know, talk with prospects and customers about on a regular basis. And I think it's really important to set the context appropriately, right? Because you can imagine, like, two worlds.

**#448 Data-Driven Engineering Management with Bryan Helmkamp, Founder & CEO of Code Climate**

(Brian at 00:32:22) In one world, maybe, you know, somebody, a CTO is interested in something like Velocity to help with their engineering organization. And in the first world, they sort of throw it over the wall to some engineers, some engineering managers, and they say, "Hey, what do you think about this thing?" Right? Well, in that case, the engineers, the engineering managers, they're going to kind of fill in this void of like, "Wait, why are we even looking at this? What is the intent? What is the objective?" with whatever comes up in their head. And maybe they decide, "Oh, well, this is about turning into management by numbers or something like that." Right? And they come up with some answer that's not actually the right answer. In another world, imagine a CTO who goes to their engineering organization and says something—and this is something that a number of our customers have done. They'll say something like, "Hey, I really want our engineering organization to be a standard of excellence. And what that means is when all of you go off and write your resumes and eventually might be working somewhere else, I want people who work on this engineering team to be hired specifically because they have this experience on their resume because everybody in the city knows that they do a great job with engineering over there. And one of the ways that we're going to do that is I see an opportunity to use data to level up the way that we're doing software engineering. And here's maybe solutions that we're looking at doing it, or we're going to do it ourselves or whatever the implementation path is." But now the engineers in the organization, they understand the goal and how there's a clear alignment actually between what leadership might be thinking about and what they're trying to do. And if you kind of break down what we are able to do with engineering intelligence, sometimes I like to say that if you just think about what the problems are that software engineers experience on a day-to-day basis, you're going to think about things like slow and flaky CI environments, late-changing product requirements, being blocked on a mock-up from design. Those are all things that can be difficult for everyone in an organization to have visibility into without having data. They all can be made more transparent through data. And if you resolve those types of bottlenecks or roadblocks, you're going to have two immediate benefits. One, the engineers are going to be able to be more productive, right? And they're going to be able to spend more time in their editor, more time coding with fewer impediments. And then also there's a benefit to the product, the business, the innovation. And so it's really a win-win. So that's one of the conversations that I think is really important to think through as you're thinking about, "Okay, how do I bring something like this into an organization?"

(Joel Beasley at 00:35:02) You said like eight awesome things I want to address, but I can't address them all. But I really am enjoying, though, just getting to talk with you about the future of Code Climate, the direction you're headed, the culture. You know, you really spoke to me when you said being the team that everyone looks at in town as the team that does this the best, because that's my style. Like, I like to find out one thing that we do better than anyone else and just keep hitting that nail as much as possible, right? And that's for me—I think that was a pretty creative sales angle too, because there is—it's not everybody for sure. It's not everybody, but there is a segment of the market out there who wants to be the best, and they're looking for a leg up, and they're looking for that 1% advantage that they can gather. And to pitch this as like, "We can give you data that will allow your teams to be seen like that if you act on it," that's actually a pretty awesome sales pitch.

(Brian at 00:36:01) No, thanks. Well, I think the other element that is really important as time goes on is really helping engineering have a full seat at the table at the leadership team level. Because if you think about what happens with a leadership team, you've got a CEO, they've got a group around them, there's all these functional areas that are represented. All of those functional areas, whether it's sales, marketing, even HR, which is naturally a very people-oriented function—over the last 10 years, they've all gotten access to high-quality data-driven insights to help them run their functional area. And that's super important for maximizing their credibility when they speak to their executive peers, their CEO, their board about what they've done, what they're going to do, why they're doing it, what is the impact on the business. And oftentimes, historically with engineering, it's never going perfectly, right? Like, everybody's got issues. Late engineering projects are probably more common than on-time engineering projects. But people in the past, you look around and say, "Okay, this is late. Okay, it's actually really late. Okay, why?" And people kind of shrug, and they go, "Well, it's just the way it is, right? It's just—it's late. We'll try to do better next time." And so I think there's a really strong opportunity with data in engineering in order to actually help elevate the conversations around what's going on inside of technology organizations and be able to advocate as effectively as possible for the needs of the team. And that might be, "Hey, we need to invest another $250,000 on CI this year. We need to increase our budget for that," or "We need to add more headcount." But it's not always add more headcount. And nobody really feels like they can hire as fast as they want to these days necessarily. But through our experience with Velocity and helping organizations understand what's going on with their engineering data, we've seen plenty of cases where businesses add engineering headcount, and the total productivity or output of the engineering organization stays the same, or it even goes down a bit. And then you think about what happens out in the wild normally, when you see that pattern, is people typically think, "Okay, well, I guess we need to hire more people," right? And it's sort of like a self-fulfilling prophecy. And so by being able to bring concrete data-driven insights, it really helps the CTOs out there sort of convey information most effectively to their product peer or to their CEO to get what they actually need.

(Joel Beasley at 00:38:34) Yes. Every time somebody talks about hiring more people, I just think about the government when they did that healthcare project or whatnot.

(Brian at 00:38:43) Healthcare.gov.

(Joel Beasley at 00:38:44) Oh, when I read about that, I saw this article, and they were treating it like it was a construction project in the sense that the more hands we have at the job site, the easier and faster it'll get done. And I just—I laughed. And then I think some companies out in Silicon Valley, I think, ended up flying out there and helping with it.

(Brian at 00:39:05) Yeah. It was a massive—and you can have this dynamic where as you build out the complexity of an org chart, you're actually—the complexity of the software system that that org chart maintains increases as well, right? Because suddenly, okay, you have four more teams and wait a little bit, and you might very well grow four more microservices, right? It's like, well, did we need four more microservices, or could that microservice have been a module or just a class? And you see these kind of patterns spell.

(Joel Beasley at 00:39:36) So we're coming up here. We've got about 10 minutes or so left. I did want to get to this question. So I was talking with Adam Barrett. He's a past guest on the podcast. He has a company called Apex Ridge Reliability. But the interesting thing about him is he does reliability engineering. He does it for software, but he comes from a background of doing it for industrial and physical things as well. And so for me, that's really geeky because I always really look up to those people doing the hardware and industrial things because all my knowledge is basically in software.

(Brian at 00:40:09) Yeah. My first reaction was that that sounds much more reliable than the average software program.

(Joel Beasley at 00:40:15) Right? You want it to be too. So when we were talking about it, he gave all sorts of tips and stuff on the show. And then I told him I was talking to you, and he knew who you guys were, and he was curious about how you approach reliability for engineering at Code Climate, like, within your organization.

(Brian at 00:40:36) Yeah. So we've tried to follow the best practices that are out there. We have an integrated team in the sense that the operations, the site reliability engineering work, the application—new feature development—that is all sort of mixed in the responsibilities for the same folks. So we try to kind of have the application engineers who are building new features, bringing them to market, kind of have that consideration in mind. Like, how is this going to run, right? And thinking about how do we make sure that we are delivering on our uptime levels, the performance SLAs that we are promising. I mean, a huge part of it for us is having version control for everything in our infrastructure stack. So basically, all of our infra changes are in the form of pull requests, generally, so they can get reviewed. They can be deployed sort of reliably. We don't actually have—one of the things that's maybe a little bit interesting—we don't have a staging environment today in the sense that we are able to deploy changes from branches and then run those as like sidecar processes relative to production. And we really focus on limiting the risk associated with the change, keeping them small, getting them deployed out to production quickly. And then we're able to review those by pulling up a subdomain or something like that. So it's probably not going to be that way forever. I think there is talk of probably introducing some pre-production, dedicated environments as we go. But it does eliminate one sort of whole step. "Hey, we've got to deploy things over here and then move them over."

(Joel Beasley at 00:42:23) Yes. I like those conversations because everybody does it slightly different. And then when I see—I'll give talks and stuff and people will ask me specific questions and want exact advice on it. You know, "What size should my teams be? Two pizza teams? Or how should we deploy?" And it's always like, you know, it's whatever's right for your company at its current stage, and that might not be the right thing tomorrow.

(Brian at 00:42:47) Yeah, for sure. I mean, I think the one universal truism is if your organization is changing, if it's growing, if the market around you is changing, the context is changing, and your engineering organization needs to evolve with it, right? And I sometimes chuckle at these ideas of doing Agile exactly by the book. Like, if you go back to the original concepts around Agile, there's this whole principle of adaptability, right, as part of it, and making sure that it's well-suited to the organization. So if it's truly about following every exact rule or tactic just to some specific letter, then to me, that feels like it kind of is not in the spirit of continuing refining the process, right? Why do you even need a retrospective if you can just go back to a book, find the appropriate section, subsection, article six that says, "Oh, we should have done it like this," right? Like, just go back to the rule book. But we do retrospectives in order to improve what we're doing on an ongoing basis. I think a lot of organizations find that to be really valuable.

(Joel Beasley at 00:43:54) Yes. Absolutely. Man, this is good. I want to wrap up with a leadership question. So you're growing this company. You're the founder. People look up to you. You've got a great team of direct reports. And I'm curious, like, if you were to design a leadership training program for your direct reports, what would be the single most important thing that they get taught in that program?

(Brian at 00:44:21) That's an interesting question. You know, I think as an organization scales and the company headcount grows and then you start to create these departments and the headcount of those departments grow, and then you bring in leaders, so much of the job becomes based in people, right? So, really, the human side of things. How do we get the right people into the organization and help them to be most successful? I can tell you when I talk to my board of directors, sometimes—it's almost like a robot asking the same question every time. Like, "How are things going with the team, right? How are things going with hiring for these key roles?" We're at this stage now where that's the top topic of conversation, right, is always people, not necessarily, "Hey, what's this KPI doing?" And so I think that's a really critical skill for every department leader to sort of have a great handle on—is how are they developing their organization in terms of the human capital that they're investing in. And generally speaking, if you've got 100 priorities on your plate—and everybody always does, there's always more to do than there is hours in the day—if you sort of err on the side of spending more of your focus and time on the people side of your organization, typically, that is going to pay the most dividends because, ultimately, having a really strong organization is going to produce leverage. It's going to produce the ability to feel like a wizard when you are talking about an idea, and suddenly that idea is materializing in front of you because you have these really talented folks who are executing on it.

(Joel Beasley at 00:46:12) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email: [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.