Episode 50
· 28:35
If you understand the landscape, then it's much easier for you to to understand the feel and essentially what the company is capable of moving forward with. On top of that, there are a number of metrics that you can use to kind of measure the possibility of success in that market.
Jack Bridger:Hi, everyone. You're listening to Scaling Dev Tools, the show that investigates how dev tools go from 0 to 1. I'm joined today by Carl Clement, who is the founder of Code Owners, which is a really innovative new tool that helps you understand who owns what part of your code. Carl, thanks so much for joining today.
Karl Clement:Absolutely. It's been a pleasure. Thank you.
Jack Bridger:Carl, could you tell us a bit about yourself and a bit about Code Owners?
Karl Clement:Yeah. Of course. So my name is Carl, and, obviously, I'm, a engineered focused COO, which is an odd title, I guess, to do. But my background is actually in commerce, and I taught myself how to engineer when I was about 14 and kind of focused on that. Ended up really, really loving the world of engineering and, started building products and basically came to this point where I met my cofounders.
Karl Clement:We've worked together for quite some time. We also worked in venture capital for a while, from venture capital, moved on to building a consulting firm, and then brought us today to which is, we've built a number of products, but one considering called codecs, which we've raised capital for, and now we've built another product called Codenearns.
Jack Bridger:Amazing. Could you tell us a bit about Codenearns?
Karl Clement:Yeah. Of course. Code owners is essentially a platform that allows you to map the knowledge of your engineering on top of your engineering team. Now I guess that sounds a little bit, eccentric, but the point here is to understand the ownership and the knowledge across your code base, when it comes to who's contributing and who's, developed with the code.
Jack Bridger:Really, really cool. And could you give us, like, some examples of, like, how this kinda helps, teams that use code owners?
Karl Clement:Yeah. Absolutely. So the the goal here is to get a an observable view of what the actual ownership is of your, engineering organization. So by installing the tool, you can understand who's contributed to the code base, at what percentages, and also kinda see the distribution. A good example of an output of that is, a code owners file that you'd find in a GitHub repo.
Karl Clement:Basically, you can have a sense of responsibility over a section of code. Could be within a repository or across the system, could be anywhere, even a service catalog. But, essentially, the ownership is a level of responsibility of an engineer or an engineering team, that can properly manage that piece.
Jack Bridger:Yeah. That makes sense. And I've never worked in, like, a big engineering organization, but I imagine there are times when people get woken up by their beeper, and then they've gotta find like, everything is not working, and they've gotta find the person to wake up and fix it all.
Karl Clement:Yeah. Yeah. Many teams will have incidents happen, you know, 60 to 60 to a 100 incidents a week, and then some of them will have, you know, 60 to a 100 in a month or depends on varying degrees. But, typically, they'll use some sort of incident management tool, to ping some on call rotations to be able to find the right person. And, you know, our goal is to really clarify that, really find the exact person that has both the level of responsibility, but also the best understanding, the best knowledge of the code.
Jack Bridger:Yeah. That's really, really cool. And one of the things this kind of, like, brings us to a bit is a lot of the guests that we have on are kind of, you know, might be doing, like, the guys from clerk dev who are, like, kind of reinventing, auth or, you know, someone that's got a great new code editor. But and with those, there's kind of an understood category tool that someone's already using. And I think what's interesting and challenging probably for code owners is that you've got this new kind of category that people maybe aren't even aware that they need yet.
Jack Bridger:So I wondered how that's been and, like, what the process of kind of explaining why people need codoners has been.
Karl Clement:Yeah. It's definitely an education. Being able to explain what code ownership, its value, as well as just general engineering ownership, is is an extra level because you you have to assume certain functions and also allow engineers and engineering teams to follow their own process. But as it is today, engineers are served in some sort of hierarchical fashion, and there is responsibility across the team, Whether, you know, you're working on a new service or a new code base or a new repository, you will have a team on that repository working, and there's a level of responsibility and shared ownership, but it's not necessarily monitored or managed. Typically, that'll be just spread out in general fashion.
Karl Clement:Like, you join a Slack group and ping an engineer that you think knows the best or potentially it's that person that you know has all the answers. You typically will message that person. Well, our goal is to simplify and organize that level, to be able to know the the level of ownership, but also the level of knowledge across the org. Who knows best? Who has responsibility here?
Karl Clement:And, you know, what are the stakeholders of this piece of code? Yeah.
Jack Bridger:It's really cool. And I could imagine, like, there's do you solve that kind of, like, bus factor, or, like, alert them that there's just this one person that just does everything?
Karl Clement:Yeah. We, we definitely added, we're working on adding that as a specific metric as well. So if there is a an individual or a team that is too essential to the organization, in this case, the bus factor is, like, very high, which is, you know, a very large concern with a lot of organizations, especially if, you have an early founder or potentially a, early founding engineer that has a ton of implication within the code base. It it becomes very difficult to manage that, but not just that. It's distributing that knowledge from that one person to the rest of the team.
Karl Clement:The buzz factor is very high.
Jack Bridger:Yeah. That's awesome. I think, maybe Elon Musk would have really wanted code owners.
Karl Clement:Yeah. Yeah. We actually received a lot of messages when it came up with the, the actual Twitter debacle in this case because, you know, as soon as all these engineers, you know, we're now no longer at the organization. It's difficult to understand who knows what, who has the answers. And then especially when you're just as a communicational nightmare trying to figure this out.
Jack Bridger:Yeah. Really, really interesting. And how do you kind of, think about your kind of go to market when you you've gotta go through this kind of, like, maybe education type phase and probably targeting big companies here?
Karl Clement:Yeah. The the go to market is really exciting, to be honest, because there is a natural kind of sandwich effect that happens, which is the product led growth motion is trying to create a valuable tool to allow the engineers to essentially do their job better. Right? Allow them to have an easier time to complete what they need to complete in a day. But at the same time, the value prop really goes towards a top down type motion where you have to communicate with a larger organization the value that they will receive in order to implement this type of ownership and responsibility across the org.
Karl Clement:So that value is then provided to a higher up group, which is maybe a VP of engineering, potentially engineering managers, even CTOs. But at the same time, the operational buyer, if you will, is actual engineers, DevOps, DevOps engineers that are implementing. And one group in particular that that we seem to be speaking a lot with are platform engineers, which is an emerging group type. But in this case, platform engineers are typically responsible of implementing services exactly like this to allow their engineering teams to just be able to, you know, handle all their workload as easily as possible.
Jack Bridger:Interesting. Yeah. And so you are finding that there are people that are doing this on a, you you know, regular repeating basis. Yeah.
Karl Clement:Yeah. There's, quite a few people it it revolves the changes quite a bit, but there's certain cases where it could be a staff engineer or it could be a dev ops engineer or a platform engineer. But in this case, they'd be implementing tools specifically to enable the rest of their team. These people are thinking about this on a daily basis. May not necessarily be code ownership, might not necessarily be service ownership, but they're definitely thinking of service catalogs and how do they organize everything together.
Karl Clement:It's really just a big intricate puzzle, to organize an engineering team to be as efficient as possible.
Jack Bridger:Interesting. And then when you kind of have identified, platform engineers as being people that are really thinking about this, how do you find the platform engineers are thinking about it, and how do you reach them?
Karl Clement:Great question. There's a number of places you can find platform engineers, but in general is joining the community and really just having conversations with people in the right place. There is a number of Slack channels with platform engineers. There's also groups online. You can find them on Reddit.
Karl Clement:There's also just, you know, the general top down type behavior, which you can, you know, find, people by prospecting directly into, like, LinkedIn or other tooling and find people with the either the position of platform engineer or organizations that are hiring in platform engineering. That's quite interesting because it shows, a willingness to not necessarily invest, but a willingness to adopt different technologies in order to make their engineering team better. A good example of that is organizations organizations that wanna shift left, with, you know, some of their their tooling or they want to, essentially just improve developer experience as a whole. And, those organizations are typically more than likely to have a platform engineer or a DevOps engineer that's willing to install tools to make their team more efficient.
Jack Bridger:Interesting. And how, like when when there's this kind of, like, general sense that they should improve, developer experience, for instance, what do they what are they kind of looking for?
Karl Clement:Yeah. There's a number of factors, but what we've seen so far is typically Dora metrics seem to be quite of, important guiding principle, I guess, in this case, where they wanna include tooling that will help their team just be more effective. A very large one of those is, MTTR, which is mean time to resolution. And in this case, a good example of that is when you're resolving incidents. It's just being able to resolve the incident as quickly as possible.
Karl Clement:Now if developer tooling such as, either, you know, incident response management or even, like, code owners, for example, to help you resolve the incident faster, that is an important metric to be able to work your way back and understand whether or not those tools are important. So to a to a manager or, say, a CTO or, or VP of engineering, that number or that metric allows them to really identify the return on investment. When you're trying to communicate the value of your tool, that's where the value is tied.
Jack Bridger:Interesting. So is that how quickly they resolve and show that you're a part of that, essentially. And you mentioned Dora. Could you explain what Dora is?
Karl Clement:Yeah. Without going too far into detail, Dora Metrics is a set of metrics that involves the developer. So if you were to I definitely recommend going down the rabbit hole of Googling this. But Google also has a great explainer about the different, Dura metrics. And, typically, they would essentially, it's, developer efficiency.
Karl Clement:So you have a a number of metrics there that allow you to kind of measure how well your organization is doing. Google also has benchmarks for their engineering team to give you an idea, and you can kind of have comparables. It's different for every organization, obviously, because a larger org with more pods, more engineers, it kinda gets messy, which is why, you know, in implementing these developer experience based tools will help you just kinda monitor that and get a little closer to, a stable benchmark, at least whatever the market is doing.
Jack Bridger:Yeah. That's interesting. And because I I've always thought about, like, how do I know if a developer team is doing a good job? And in my I always worked in start ups, and I never came up with any or heard of any, like, metric that I felt would have really encapsulated that we were doing a good job. And I wonder if, like, when you look at these kind of metrics and stuff, is it something that you're, like, kind of keen to go along with and and focus in on, or is it like, you know, are you at the point of, like, well, there are other things.
Jack Bridger:Like, how are you kind of thinking about that?
Karl Clement:Yeah. That's an interesting problem. I think from an organization to organization, it's very different because a benchmark could be great when you're comparing, say, an enterprise to an enterprise in the same vertical or the same market. In this case, it's very different if your product is entirely engineering focused and the output of your product is, you know, top notch. It's also the most important factor.
Karl Clement:That is it plays a very big part. So your door metrics are a lot more important. Meanwhile, if you have a product that's doing quite well and maybe developer pace is a little slower and your velocity is slower, that doesn't necessarily mean it's a bad team or a, you know, bad, Like, for example, if your mean time to resolution is lower, but you don't seem to have as many incidents and they're less critical, that doesn't seem to matter quite as much. So it really depends on the business. It depends on, you know, the product that you're selling.
Karl Clement:But, some organizations are definitely more focused on door metrics just to as a good measure. But I think the benchmark, realistically, your goal should just be to improve. Right? Whatever metric that is, just improve your numbers as you go, as you implement new tooling. If it's going down or, I guess, down is a generalized statement, but if it's getting worse, that's definitely not a good thing.
Jack Bridger:Yeah. That makes sense. It's an interesting area. There's not, I I think you might be one of the first that we've had this very, like, kind of driven by this, like, improving developer experience. And one of the, tools that we spoke with offline is Backstage and how you've been kind of, like, looking at the Backstage community and, Yeah.
Jack Bridger:Backstage is relatively new to me. So I'm kinda curious about, like, what Backstage is and how you've been kind of, like, working with that initiative from a lot of companies.
Karl Clement:Yeah. Backstage is quite interesting because its grand purpose to implementation is essentially improving developer experience, but there are a number of factors that it it does improve once you've fully adopted the technology. And and Backstage itself is an open source library from Spotify, essentially allowing you to create a developer hub, if you will. You can use it for a number of things, but, essentially, the goal of it is just to gather all the engineering knowledge in, like, one place. So that could be documentation.
Karl Clement:That could also be, you know, separating your organization or your your code into services and different pieces. And it really maps things out to for you to understand, what's involved in the software. Right? If you have a big software company, you have a lot of moving pieces, a lot of services, you have infrastructure as well that's laid on top of that. It's very difficult to manage and to understand, you know, where everything is, and this kind of centralizes everything.
Karl Clement:It is very customizable as well, which is you know, allows you to pipe in any other information you have there, including ourselves. We've we're we've built a plug in to implement code owners data directly into Backstage because some of that ownership information is important to, you know, the group. But you can essentially pipe in whatever information you want into Backstage just to improve that experience. Yeah.
Jack Bridger:And so and it's a really kinda smart strategy, I think, to, like, be, kind of joining, like, an existing, like, trend movement and and kind of making that better as well. And how how have you kind of used Backstage's growth as, like, a driver for yourselves?
Karl Clement:Well, it's been an interesting conversation with some companies. Backstage implementation is essentially a signal that a company is willing to invest in the organization, but the developer experience as a whole, which is great because for us, it gives us a signal that there's some general understanding as well for the tooling rather than your run the mill engineering team that just, you know, write code, ship code, write code, ship code. There's a lot of moving pieces, and the larger your company grows, especially mid market or enterprise companies, there's the engineering team is vast, massive companies that have different groups and pods and different verticals, within an organization. And it's almost impossible to understand the full spectrum. That's why in in theory, if you're implementing backstage, you have an understanding that, you know, things need to be optimized, things need to be organized.
Karl Clement:And there's a level of responsibility across the org, which really helped us understand that someone who is implementing backstage is also curious about ownership, curious about team responsibility, and it kinda goes hand in hand in this case.
Jack Bridger:Yeah. Yeah. That's a really, really smart way to, like, think of, like, visible ways that you could determine the mindset, which is often very hard to kind of understand of different companies. Mhmm.
Karl Clement:Absolutely. And that's where the the product led growth type motion typically happens, especially for bin market at enterprise. You have to work with existing tooling that is familiar to the group. Right? If an engineer is familiar with the tool, it then helps them understand.
Karl Clement:There might be a bit of cognitive bias there, but it's just a little bit of familiarity makes it feel a lot more palatable.
Jack Bridger:Yeah. 100%. Like, none of us wanna do anything different. Right? Unless we're just kicking and screaming or or it's so good that we just have to do something new.
Jack Bridger:Yeah. That's, that's really that's a really good approach. And Carl, you mentioned, briefly that you had, like, a kind of a VC, stint before, code owners, as well as running your own business and stuff. Could you tell us a bit about, like, what you've brought, from being on that side of the table to, to now founding your own thing?
Karl Clement:Absolutely. I think that the interesting piece with, my experience with venture capital is that many organizations, typically, when you're building a product and you're putting it into market, you're always thinking of a scratch your own itch type behavior or potentially it's just found you found opportunity within a specific company or, you know, it could just be a eureka moment where you've noticed a gap or some sort of opportunity in market. And the venture capital side essentially teaches you to understand the global system around it more so than the actual execution in the product. Now when you're doing venture investing, the interesting thing is there are a number of factors that make you make that decision and move forward. But one of them is understanding the landscape.
Karl Clement:And if you understand the landscape, then it's much easier for you to to understand the feel and essentially what the company is capable of moving forward with. On top of that, there are a number of metrics that you can use to kind of measure the possibility, same landscape, you have a better understanding of what's possible and also your competition. So if you're building a product, you're very myopic. You're looking at this one problem in this one place, trying to understand it and then move forward, but you don't generally have as good of an understanding of the market and who's at play here, who are the main acquirers, who are the the big moving pieces. And, basically, the venture capital, allows you to kind of figure out those moving pieces and really understand the market, understand how products are moving, what are the tailwinds that are going to pull your product forward.
Karl Clement:You know, AI most recently is definitely one of those tailwinds where if you learn to work with AI or implement generative AI in any way, shape, or form, it'll help you move forward. And that venture capital I kinda allows you to pick and choose and understand the market.
Jack Bridger:Yeah. Very interesting. And as someone that's always, like, thinking of ideas and trying to come up my own dev tools, could you give any examples or or, like, even speaking about code owners about how you thought about it when you were kind of, like, evaluating whether you wanted to throw yourself behind this, this direction?
Karl Clement:Absolutely. Our original product was, was codecs, which allowed, you know, to to document as you code, which was an interesting piece and it's a necessary piece, but that's when we started to see opportunities in other places where code ownership and code responsibility was the root cause. And then at that point, we were able to identify different people working in the same observability space. And in this case, when you start seeing observability, you start seeing big players like, Datadog or Splunk or big, big players that have been in the market for years. Really, really understanding this, and their move towards observability as a whole is interesting because it allows you to see what larger companies like enterprise, mid market are really looking for.
Karl Clement:They're looking for a general understanding of the full spectrum. Like, what what is going on in my organization? What is going on in my system? And that was an interesting piece because from a code ownership standpoint, we saw an opportunity, but also a need for a sense of responsibility and a sense of ownership and understanding of what your engineer engineering team is building. Right?
Karl Clement:Again, with, you know, same thing with tailwinds for AI, for example, there's a lot of things we weren't able to do in the past. You couldn't necessarily look at a code base and understand exactly how it was built without going through every little git commit and really understanding, like, okay. This person added this. They added this code here and here and here, which gave us this big product. But now with certain technologies, we could figure out a lot of things.
Karl Clement:You work your way back and understand the history, understand the observability of your system.
Jack Bridger:Interesting. So it's like you're kind of the that, like, the production side of things, like, external face like, the Datadog and stuff is showing you how it's running and, like, that errors and stuff like that, and you're more like how how is it built, who build it sort of.
Karl Clement:Yeah. It it essentially validates your market position, if you will, and it validates the direction. In this case, a lot of large players are going into this space, and it allows you to understand that, okay, if they're going to this space, then that means that there's importance here. And my solution in particular solves a pinpoint in this space. Right?
Karl Clement:If you were building a particular product in a space that no one is, there is a chance that it works out, but you are also reducing your odds of understanding, especially from a b two b standpoint. If you're selling a consumer product and it's just a wow effect, you know, and no one's ever heard of it before, but you go and build this, present it to market, everyone loves it because it's just the coolest thing since sliced bread. That's a different perspective than from a b to b standpoint. B to b, it has to map directly to something they are currently doing or they need to do in order for you to have a valuable product. If they aren't doing it or they don't intend to do it, then there's no value tied to it, and it's very difficult for them to calculate the ROI on a product.
Jack Bridger:Yeah. I think it's a really, really important point. Yeah. Is there, like, direct competitors and stuff for co donors?
Karl Clement:I don't wanna speak too quickly, but not right now. Yeah. The interesting thing is the I'd say the most direct competitor is just an engineering organization with proper organization. If you have a proper, you know, hierarchical pattern, you can understand your company. Small pause can communicate effectively together and really, you know, keep moving.
Karl Clement:But the realistic situation here is that that's that that's impossible to maintain. You can if you have a really small org, if you're in the same room. You know, like, even our on our team, as we grow, we're having difficulties understanding who did what, who's responsible for what, who knows what.
Jack Bridger:Yeah. Yeah. 100%. That's, I think that's the challenge of a lot of dev tools anyway. Even even in off.
Jack Bridger:Right? I think everyone's the the main competitor is just people doing it themselves. Mhmm. Yeah. Carl, I think we're coming to the end of the time.
Jack Bridger:So I wondered if you've got any kind of key takeaways that you would advise either yourself a few years ago or someone else, who's maybe doing something slightly different to you.
Karl Clement:Absolutely. My biggest biggest recommendation for anyone is to not necessarily focus on the distribution portion of the method you're getting to market, but my biggest advice would be to focus on your ICP. That group, that person that you're trying to go and talk to, really make sure to spend the most time that you can in discovery with those people, because really understanding their needs and what they're willing to work with and what are their pain points really matter. Right? You might be the entire time, you might be talking to, say, a site reliability engineer, and you think that this person is the right person for the problem, but this person never really resonates with the problem.
Karl Clement:And then you go and speak to a different person, say a platform engineer in our case, and then it's it's a perfect match. Right? There are some situations where you need to understand the person you're selling to, both whether that's, an operational buyer or it could potentially be just like an economic buyer. So someone who's willing to willing to write the check, you know, hand over the credit card. But you have to understand those people in order to best fit the the value.
Karl Clement:Right? You have to be fixing a problem if you want someone to pay for it.
Jack Bridger:Great. Thank you, Carl. And if people wanna learn more about Codoners or about Carl, where can they learn more?
Karl Clement:Definitely check out Codoners dot com. We're building the platform. It's working. We're changing it constantly, so please do check-in. And my you can check out my personal Twitter.
Karl Clement:It's, karlclement, Karl Clement. Really appreciate it.
Jack Bridger:Amazing. Thanks, Carl, and thanks for joining us. And, thanks, everyone, for listening. Okay. I think I thanked you twice there, Carl, but thank you.
Jack Bridger:Thank you. Thank you, and thanks, everyone, for listening. We'll see you again soon. Bye. Thank you, Jack.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.
