From VC to DevTools with Karl Clement, founder of CODEOWNERS
CODEOWNERS doesn't have a category yet, so Karl Clement built a proxy signal instead: if a company has already adopted Spotify's Backstage, they've already decided developer ownership is worth organizing — which makes them a much easier sell.
Karl Clement is the founder of CODEOWNERS, a platform that maps engineering knowledge and ownership across a codebase — who actually understands and is responsible for which part of the system.
We get into why selling a genuinely new category is harder than selling into an established one like auth or code editors, why platform engineers turned out to be the right buyer to chase, how DORA metrics and MTTR become the ROI language that gets a CTO to say yes, and why Backstage adoption is a surprisingly reliable signal of exactly the kind of customer CODEOWNERS wants.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
What does CODEOWNERS actually do?
It's a platform that maps the knowledge of your engineering team on top of your engineering team itself — understanding ownership and knowledge across a codebase, specifically who's contributing and who's actually developed which parts of it. By installing the tool, you get an observable view of who's contributed to the codebase and at what percentage, similar in spirit to a CODEOWNERS file in a GitHub repo, but broader — ownership can apply within a single repository, across a whole system, or even across a service catalog, representing which engineer or team is genuinely responsible for managing that piece.
How does that actually help a team day to day, say during an incident?
Many teams handle anywhere from 60 to 100 incidents a week, sometimes a month, and typically rely on some incident-management tool to page someone through an on-call rotation. Our goal is to make that far more precise — finding the exact person who has both the responsibility and the deepest actual knowledge of that piece of code, rather than paging whoever happens to be on rotation.
Other guests on this show are usually reinventing an established category like auth or code editors. CODEOWNERS feels like a category people don't know they need yet. How has that education process gone?
It's definitely an ongoing education — explaining the value of code ownership, and engineering ownership more broadly, is an extra layer of work because you have to let engineering teams keep their own processes while still making the case. Today, responsibility across a team on a given repository or service exists, but it's rarely actively monitored or managed — it's informal, spread out, usually just 'ping the person in Slack you think knows the answer.' Our goal is to organize that informally-known information into something explicit: who actually has ownership, who has the deepest knowledge, and who the real stakeholders of a given piece of code are.
Does CODEOWNERS help surface the classic 'bus factor' problem, where one person knows everything?
Yes, and we're actively building that out as a specific metric — flagging when an individual or team has become too essential to the organization, which is a real, common concern, especially around an early founder or founding engineer whose implicit knowledge touches huge parts of the codebase. It's not just about identifying that risk, it's about actually helping distribute that knowledge out from one person to the rest of the team. We actually got a wave of interest around this during the Twitter layoffs — once a large number of engineers left the organization at once, it became genuinely difficult to figure out who knew what, which turned into a real communications nightmare for whoever was left.
How do you think about go-to-market when you're both selling to individual engineers and trying to get a large organization to adopt something new?
There's a natural sandwich effect. The product-led growth motion is about building something genuinely useful that makes an individual engineer's day easier. But the actual value proposition has to be communicated top-down too, to a VP of engineering, an engineering manager, or a CTO, to get organizational buy-in for adopting this kind of ownership and responsibility structure. Meanwhile, the operational buyer — the person actually implementing it — tends to be an engineer or DevOps engineer, and one group we talk to constantly is platform engineers, an emerging role specifically responsible for implementing tools like this to make the rest of engineering more efficient.
How do you actually find and reach platform engineers?
Joining the communities where they already are and having real conversations — there are Slack channels and Reddit communities specifically for platform engineers. There's also a more direct, top-down approach: prospecting on LinkedIn for the platform engineer title itself, or for companies actively hiring for that role, since that's a strong signal an organization is willing to adopt new technology to improve engineering effectiveness. Organizations trying to 'shift left' or generally improve developer experience are much more likely to already have a platform or DevOps engineer actively looking to install tools like ours.
What are those buyers actually looking for when they say they want to improve developer experience?
DORA metrics tend to be an important guiding principle — a set of metrics measuring developer and engineering efficiency, with mean time to resolution, MTTR, being one of the biggest. If a tool like ours or an incident-response platform genuinely helps resolve incidents faster, that's a concrete metric a CTO or VP of engineering can tie directly to ROI, which is exactly where the value of the conversation needs to land.
Do you think DORA metrics are actually the right way to judge whether an engineering team is doing well?
It really varies by organization. If your product is entirely engineering-focused and the output itself is the product, DORA metrics matter a great deal. But if your product is doing well and velocity happens to be a bit slower, that doesn't automatically mean the team is doing badly — a low MTTR paired with genuinely fewer and less severe incidents matters less in isolation. It depends heavily on the business and what you're actually selling. Realistically, the goal with any of these metrics should just be continuous improvement over time as you adopt new tooling — if a number is trending the wrong way, that's the real signal worth paying attention to, more than the absolute benchmark itself.
You've mentioned Backstage as an interesting signal for finding the right customers. What is it, and how do you use it?
Backstage is an open-source developer hub originally built by Spotify, meant to centralize engineering knowledge — documentation, service catalogs, how your organization's code and infrastructure are broken up — into one customizable place. It's genuinely useful once fully adopted, and we've built a plugin that pipes our own ownership data directly into it, since that ownership information is valuable to exactly the kind of team already using Backstage.
How has Backstage adoption actually shaped your go-to-market?
A company implementing Backstage is a strong signal on its own — it shows they're already willing to invest in developer experience as a whole, not just ship code reactively. As companies grow into mid-market or enterprise, the engineering org becomes vast, split into many groups and verticals, and it becomes nearly impossible to understand the full picture without deliberate tooling. If a company has already implemented Backstage, that tells us they already understand the need for organization and optimization, and that they're likely already thinking about ownership and team responsibility — it goes hand in hand, and it's a genuinely useful, visible proxy for a mindset that's otherwise very hard to detect from the outside.
You worked in venture capital before founding CODEOWNERS. What did that experience actually change about how you build product?
Building a product tends to come from a scratch-your-own-itch instinct, or a specific eureka moment noticing a gap — which is inherently myopic, focused tightly on one problem in one place. Venture capital teaches you to see the broader system around that problem instead of just the execution — understanding the overall landscape, who the major acquirers and moving pieces in a market are, and what tailwinds are likely to pull a product forward, generative AI being an obvious recent example. That landscape-level view, and the metrics you use to gauge a market's potential, is something I carried directly into building CODEOWNERS.
How did you actually land on code ownership as the problem to build for?
Our original product, CODEX, let you document as you code — useful, but it's where we started noticing that code ownership and responsibility were often the actual root cause of the problems we were seeing. Around the same time, we noticed major established players like Datadog and Splunk moving deeper into observability, which was a genuinely interesting signal — when large, established companies move toward a category, it tells you enterprises and mid-market companies want a fuller picture of what's happening across their whole system. From an ownership standpoint specifically, we saw both an opportunity and a real underlying need for a clear sense of who's actually building and responsible for what — a need that's become newly solvable with modern tooling that can trace back through commit history and reconstruct that context, rather than manually digging through every individual git commit.
Is that kind of market validation — big players entering a related space — something you actively look for?
It genuinely validates market position and direction. If large players are moving into a related space, it signals real importance there, and a more specific solution like ours can address a precise pain point within it. Building in a space literally nobody else is in might work out, but it meaningfully reduces your odds, especially in B2B — unlike a consumer product that can succeed purely on novelty and delight, a B2B product has to map directly onto something a buyer is already doing or already knows they need to do. If they aren't doing it and have no plan to, there's no way for them to calculate a return on investment, and the sale becomes very hard.
Who's the actual competition for CODEOWNERS right now?
There isn't a direct competitor yet. The honest answer is the real competitor is just a well-organized engineering team with a clear hierarchy — small enough that everyone communicates effectively and just keeps moving. But that's realistically impossible to maintain as a team grows; even on our own team, as we've scaled, we've started running into exactly the same problem of not knowing who did what or who's responsible for what.
What's the biggest piece of advice you'd give another founder, especially one earlier in figuring out their go-to-market?
Don't focus first on the distribution mechanics of how you'll reach the market — focus on your ideal customer profile and spend as much time as possible in discovery with those actual people, understanding their real needs and pain points. You might spend a long time convinced a site reliability engineer is the right buyer, only to find the problem never really resonates with them, and then discover a platform engineer is a perfect match instead. You have to genuinely understand both the operational buyer, who'll actually use the tool, and the economic buyer, who signs off on paying for it — you have to be solving a real problem for a specific person if you want anyone to pay for it.