# The Apex Framework: Measuring AI Impact in Engineering

**Podcast:** Dev Interrupted
**Published:** 2026-04-07

## Transcript

Today we've got a very special guest, in my opinion.
I am joined by my fellow host and linear BC COO, Dan Lyons.
Dan, it's really great to have you back on the show again.
It's been a little while.
What's up, BLP?
Awesome to be here.
Super excited to catch up.
We got an exciting topic today.
Yeah, yeah.
And of course I'm joking about it's been a little while because I I think you've been on the episode just a couple of weeks ago.
So it's actually really nice to get you back for multiple episodes in quick succession.
So love being here.
Yeah.
Yeah.
So all right.
So the topic that we want to we want to cover today.
So, you know, we've spent many years on this show, uh, you know, both at Dev Interrupted, but also at Linear B talking about things like Dora, like space, you know, all these frameworks that really try to measure how effectively engineering teams are operating.
You know, the idea being that like, you know, part of our core mission at both Linear B and Dev Interrupted is really to help engineering teams move from like this more like gut feel-driven decision making to data-driven engineering.
And, you know, and it's been working well, I feel like, but the world has really sort of changed in in the last year or so as AI coding tools like Copilot, Cursor, Claude, Codex, you know, all these new tools are hitting the mainstream.
And executives are seeing the bills for these tools.
They're seeing all of these viral things about how teams are getting crazy productivity and writing tons of code with AI and and and all of these things that claims and hypes that is is out there that people are making about AI.
And meanwhile, we we encounter people, I feel like on a weekly basis that that are asking us, like, does this actually make us better?
Like, are we actually more productive?
Are we delivering more value to our customers?
And that's the topic that we're gonna talk about today.
Because, because you know, we've we've got all these dashboards out there from uh that show you things like AI adoption.
You can get your Dora metrics, your cycle time, your CFR, see your predictability.
But we started developing this new operating model at Linear B that we're calling Apex.
And that's really what I want to talk about today, Dan, because this really gets into why, you know, these playbooks that we have, they're still great, but they may not be up to this up to snuff for the AI era.
Uh and and this is the framework that we hope is going to prove that value.
So before we get into the background behind Apex and how to implement it and all the details uh of what's in it, I want to just maybe start with a high level overview.
So, from your perspective, Dan, like what is Apex and why should our audience care about it?
Yeah, well, I mean, first of all, coolest name ever.
Apex.
Gotta have a cool name.
And uh why I love Apex, and we're gonna uh talk about uh each aspect of it.
Yeah, but Apex is a framework that was made by the people for the people.
And what I mean by that is it was really organically made uh through our customer base.
Yeah, it wasn't something like, okay, you know, Dora was more like, hey, let's do like a research assignment.
Let's go research and let's do all it's very like uh, I would say research focus, you know, really specific on getting code through the pipeline, you know, also change failure rate balance with quality.
But I think what's great about Apex is it came from actual users, actual usage, and from our customers.
Yeah, and I actually want to point out that you know that that research focus, you know, because this is something we've seen time and time again, like that um, you know, what works in the lab and and what you can observe through research experiments and all of that stuff, that doesn't always play out in real life.
You know, real life it can be quite a bit more messy than that.
It's it's uh you're dealing with all these different constraints.
So I really do think it's important to point out how we're trying to take a much more practical and pragmatic approach that's based on the things we see from from customers and from from our community of experts like every single day, right?
Yeah.
And no, not to Dora space, yeah.
Awesome frameworks, but uh revolutions and evolutions has happened uh since then.
You mentioned uh one of them, obviously AI taking over the world, eating the world.
So we know that you know, some of the other for uh frameworks that have been around now for years and years, probably outdated.
But there's another thing that I think happened in between, let's say, like Dora Space and then where we came to uh with Apex is engineering organizations over the last, I don't know, five years, are also no longer just responsible to ship code.
They are also responsible to the business for value.
And so when you look at Apex, right?
A and Apex, AI leverage, the P predictable delivery, predictability, the E, efficiency, still gotta be efficient with shipping code.
Yeah.
And then the X, DevX.
So what I like about Apex and what our customer base uh has told us is yeah, it's up to date because it's AI forward.
Okay, it starts with A, it's AI, but it's more about the balance.
It takes into consideration, of course, we need to ship code, it needs to be efficient and high quality, but there also has to be the value, the predictability side.
Are we actually delivering value uh stories in a predictable way every sprint?
And then it's got the A in there, right?
Okay, the AI has to be there, gotta be AI for gotta take it into consideration.
And then it rounds everything out with developer experience.
So when I think Apex, really what I've been thinking about is wow, this is a really balanced framework uh for the times that we're living in today.
Yeah, and I and I think one thing that's really important to point out is how that we we designed this framework really to be um to to focus on AI as like a central component of your SDLC.
Like it is now a primary contributor or a primary operator within your SDLC, or or at least it's becoming more and more of that over time.
And like, yes, we have we have A for AI leverage that's explicitly calling out AI, but I also do think it's important to recognize that AI is gonna impact every single aspect of this framework.
So, you know, it if it impacts your cycle time, you know, your efficiency.
Um, it impacts the experience that your developers have at your organization.
So not only are we we giving it its its own explicit like sort of boundary where we're saying this is the AI measurement that you need.
We're also showing how AI is impacting all of the aspects of your SDLC and how you need to factor that into your visibility layer.
Yeah, they all play together, right?
The A, the P, the E, so the AI, the predictability, the efficiency, they all these all relate to each other.
And you're right.
I mean, at least, you know, the customers that I'm working with, in terms of their AI journey, I think uh there's different stages, right?
If you said like, I don't know, stage one is something like, hey, maybe um we're just getting started.
And so and some companies are there, like some large enterprise.
Hey, we're we are just getting started with this.
Yeah.
And maybe on the far extreme, you know, you have uh some of our customers are doing like spec driven development.
It's established, like they're trying to be like cutting, cutting edge.
And probably most are in the middle.
They're in an experimentation phase.
AI tools have been rolled out, yeah.
Uh Claude is kind of taking over now.
They probably started with with Copilot.
But I think what's cool about this framework is it doesn't really matter where you are in that in the journey.
You don't have to be like extreme with AI in order to get value out of it.
A lot of the customers that that I talk to, we even start with the P and E, so kind of the middle of AF Apex.
We say, hey, you know what's core uh to delivery?
Let's make sure we have great planning and capacity accuracy, delivering value on time, delivering stories on time, still number one thing.
And then efficiency.
Let's make sure the code's getting out in an efficient way with high quality.
Can even just start there and then layer in, okay, how is AI adoption affecting this?
Yeah.
Um, so yeah, that that's kind of what I'm seeing, at least in the market in the customers I'm talking to.
Yeah, yeah.
And we'll get in more into these individual pillars uh quite a bit more here in a minute.
Uh, but before we do that, I want to I want to just take a step back and just sort of look at the the context behind where we are today and why we felt this need to shift to a framework like a Apex.
Um, and let's let's start with this notion that um I comes up almost on a weekly basis, it feels like here at Dev Interrupted, and this this idea that coding faster is an illusion.
You know, we hear it all the time how develop developers are feeling faster, you know, either they can write more code or they can do research more quickly.
Um, yet often we're hearing that like the bottom line for the these companies isn't really moving.
So I'm just curious from your perspective, like, why is there this massive disconnect between the tool adoption?
You know, I feel like tools AI usage is basically ubiquitous at this point.
Um, but then the actual delivery isn't quite like matching the expectations around this tool adoption.
So what do you think is going on here?
Yeah, great question.
I mean, first and foremost, I I do believe like AI is a different beast.
Maybe compared to other like two tools that have been adopted, I don't know, over the last few, like it is actually game changing.
I think anyone using AI uh developers, you just feel like you can do way more than you did before.
There's a lot of, let's say, uh volume to it.
That's the best way that I can describe it as an end user.
Even like uh if I'm not using uh AI to develop, just like doing day uh day-to-day life, I feel like I can do more volume of stuff.
Makes you feel bigger.
Like you have a bigger presence.
It makes it feel like I if I want to be, I can be like five people in parallel.
I can be like five developers.
So there is that uh volume feel.
But then I I think what's also happened is if I uh move away from the developer, and let's say uh when I'm talking to like CTOs and SVPs, there is a combination of a promise or expectation front to the business, usually coming like from the CEO of board uh or the board of like, hey, we're in the AI era.
Uh, there's an expectation to do more, move faster, deliver more code, deliver more value faster.
So you got that expectation.
Oh, okay, now that I'm supposed to uh my org is supposed to be adopting AI, I guess we got to do everything like 10x speed.
But then the the reality sets in of hey, just because you're developing more code or more volume in the early stages of the SDLC doesn't mean that it can actually get out to production, or it doesn't mean that stories are actually getting like completed on time.
There's bottlenecks uh after the coding.
Probably the rest of the SDLC hasn't caught up quite yet.
And when you put that triangle together, that's where I think the faster illusion comes from.
Yeah, and and uh, you know, I keep coming back to this this concept that came up in last year's door report where uh, you know, a lot of it this year was or last year was focused on AI in particular, uh, even more so than they have in recent years.
And uh there was a phrase in there that really that basically been stuck in my head ever since I heard it, and that is that upstream acceleration is lost to downstream chaos, you know.
Like you have these downstream bottlenecks and things like code reviews and uh deployment, stuff like that.
Um, and and I think it's becoming very apparent that if those downstream systems aren't ready for AI, the the upstream gains are just gonna get lost and go nowhere, right?
Yeah.
Um but actually when you when you and I did we did the benchmark, the benchmarks podcasts together.
Yeah, and I don't know if we we can pull uh pull the data on that, but I think you we had something in there that said, hey, even a lot of code that's being either created by AI or fully created by an AI agent, maybe a pull request goes up, it doesn't even get merged.
That's part of that chaos.
Yeah, it's more likely to not get merged, more likely to have a longer review time.
Um I think we even found some interesting conflicting ideas where like it might sit for a review longer, like someone doesn't pick it up for days, but then once they do, they just they just thumbs they give they get an LGTM and no one really owns it.
Yeah, yeah, yeah.
So that's part of the chaos.
That's like the that's like the data behind that uh upstream versus downstream chaos that you're talking about.
Yeah, yeah, exactly.
And and you know, and I mentioned Dora, and and and I want to touch on that a little bit because we we've already hinted at this, but you know, we've had Dora space, they they've been around for quite a while, very battle tested at this point and well respected in the industry.
There's been just a proliferation, I feel like, in recent years of like general productivity frameworks that um often you know to me, just kind of feel like it's it's someone who just like invents a dashboard that they want you to buy from them or something like that.
Um but you know, we've so we've always been a fan of like frameworks in general, especially some of the ones that are more well established.
But so I want to just t touch into why we're expanding upon them with apex.
Like, do you feel like it's something that we're the the existing metrics fell short of something, or is it just that we need something that the expands the scope of of what they're doing?
Yeah, yeah, like I like I said before, I mean, Dor, I mean, these are great frameworks.
They they really are.
I mean, we're we're all about them, and like uh a lot of the customers that we work with, like set metrics and we like improve cycle time or CFR or MTTR, deployment frequency, like all of that kind of stuff.
It makes sense.
Um, I just feel like there's been an organic evolution.
There's been an evolution in in the markets.
What you can do with AI kind of just uh, I would say naturally made some of the those frameworks to be out of date, no fault of their own.
And even probably probably I think some of the like the creators of Dora are like working on the next thing and all of that.
Yeah, yeah.
And our customers basically came to us and said, hey, you know, Dora, it's but it's been great.
We need something new.
And the reason we need something new is yes, AI is here and we need to be measuring the adoption and the impact of it.
That's the expectation.
And also what what I said before, I think there's the business value of it, meaning, or the business side of it.
Are we actually creating value, delivering value, and are we doing it on time?
And those are the two, like I think primary additions that uh Apex uh addresses that maybe some of the earlier frameworks, no far of their own, uh just didn't focus on, didn't need to.
Yeah.
Yeah, yeah.
I mean, built for a different era.
I mean, Dora, I think was really built for like the cloud computing era, and you, and if you think about where where we were like 10 years ago is cloud computing took over, like, yeah, there's a lot of parallels between that, but you know, as you said, this is a real game changer.
Like the rate of change that AI is creation creating is on a different scale than what we were dealing with back then.
And and I just want to get into like one last topic before we move on to the framework itself.
And that's this notion of AI in the critical path.
So one of the th the principles of A Apex, as I mentioned, is treating AI as this like first class production contributor.
So I'm wondering like how how does the mindset of like, you know, I think a lot of organizations see AI as so far as like a side experiment, um, but we're rapidly shifting into this world where AI becomes a core part of the delivery system.
So, you know, uh how like reflect on that shift a little bit, what you're seeing from Linear B customers and also like how you think Apex is here to help address that.
Yeah, like I I'll even just like reference how my how my day went today.
I'm coming off a call with I I would just say uh a CTO of one of the biggest uh let's say like re retail manufacturers in the US.
We'll we'll put it that way.
And my conversation with him, what do you think is the first thing that he came to me with?
He said, Hey, you know, we are committed, we're rolling out AI tooling.
Um, and there is an expectation now that we're able to manage adoption, provide visibility with adoption, and even more so so than that.
And like I have other customers saying this to me.
They're trying to figure out, okay, I have lots of teams.
Let's say I have a hundred hundreds of teams in the big ones, even like thousands of teams.
Where is AI being adopted?
Uh, where is it effective?
Which teams?
And then once we know that, how can we replicate those behaviors across the other teams that are maybe struggling a little more?
And the reason I tell that story like that, because you asked like AI in the critical path, yeah, it's in the critical path path now.
These are the types of uh questions that engineering organizations uh have to answer, I guess to be uh modernized or however you want to put it.
That's the expectation now.
And of course, like the Apex uh framework is well suited to address that.
Yeah, it's like when you move from from an AI experimentation to like actually having AI in your critical paths, there it creates data anomalies, right?
Like there's a there's a change in your data, and suddenly a team is operating differently than they were before, hopefully much more productive productively.
And once you see that, you want to like naturally you're gonna want to replicate that across to other teams and get them out of the experimentation stage, right?
Exactly.
And it's like a business, it now, it's like a commitment for a lot of companies.
It's like, yes, I am committed to moving past just like early experimentation to actually operationalizing, and by the way, showing the impact, like hey, all of this AI rollout, hey, is uh Claude actually doing anything for us?
Yeah, in terms of like the the bottom line of like the value and getting high quality code out to production.
Yeah.
All right.
Well, I think we've done a great job at sort of providing the background context for for how we got there or to here to this moment.
Um now I want to get into the pillars individually and sort of break down um what Apex consists of and and why we've built it this way.
So, you know, there's four distinct pillars.
We we mentioned them briefly at the top of the show, but just real quickly, I'll list them again.
So we have A for AI leverage, we have P for predictability, we have E for efficiency, and then X for developer experience or DevX.
So let's let's just start at the top with with AI leverage, because it's kind of the hot button topic, obviously.
Uh and for this, you know, we we define it as measuring how effectively AI is embedded into your production systems.
Uh and the North Star metric that we have for this is AI assisted PRs.
So, which what number of PRs over a specified time period um or what percent of PRs were assisted in some way by AI?
And we kind of break this down by like coding assistance, code review, fully agentic systems.
Like there's a variety of ways that this shows up.
And you know, the one of the things that the that we note with this framework is that like usage dashboards alone aren't going to validate your impact.
Like, I imagine if you were to just go and look at raw usage today, you would see most of your developers are using AI, at least on a weekly basis, probably daily at this point.
Um, but we take it a step further than that, and we tie usage to the actual pull requests that are entering into your your code base.
Um and and looking at how AI is contributing to the unit of work through the system.
So let's let's start there with AI assisted PRs, Dan.
So what what role do you think that this fits within Apex?
Yeah, yeah.
Okay.
So a few a few things there.
Uh I do think impact matters the most.
Okay.
So, and and that is what what I'm hearing from the customer base.
Like uh, I still have to say, how does this affect things like cycle time, rework rate, PR size, change failure rate?
Yeah.
How does it affect my planning, uh, accuracy, my delivery, all of that it it uh it matters.
And that's why it's not only about adoption.
Yeah and you and usually I I'm hearing that from uh customers that feel, hey, I've already kind of rolled rolled out AI, I'm ready for for the impact side of it.
But I would I will say there are also a lot of engineering organizations that are just uh on the adoption phase.
And when you look at AI assisted PRs, I think it's a really easy way.
And I'll go back to the teams.
You know, which teams within your engineering organization have like 70% AI assisted PRs and greater, which teams have 50% and greater, and which teams are kind of just like uh starting out, let's say uh 10, 20%.
That that type of benchmark.
And I do think that gives kind of like, okay, I can now get an understanding of like what maturity level my my adoption is with uh amongst my teams.
And like I said earlier, uh usually what people are doing is trying to look at those teams that have a uh high adoption rate and the and high impact metrics, like cycle time has decreased, uh change failure rate has decreased.
Now, when I identify those teams, I I can go in and inspect what are these teams doing with AI that maybe other teams aren't?
And then you go and try to replicate those behaviors.
That's the pattern that I'm seeing.
Yeah, and it's like it's really again, it's like it's like an anomaly detection, right?
So, like a team with really high AI usage, could it could be one of two things?
It could be a team that has learned something really good that is super beneficial that you should propagate to other teams where you can.
The other side of the equation might be a team that's currently overwhelmed by AI slop, right?
Like maybe maybe they're just creating tons of AI generated code, they're not reviewing it, they're just pushing it to production and things are blowing up constantly.
Yeah.
So, and that's where I think going from the A, the AI leverage, to these other metrics is really critical, right?
Because if you're just getting more AI assistance, but it's it's messing up all the other stuff, like predictability, the next thing that I want to talk about, then it's all for nothing.
Uh so let's let's just move on to predictability then, which you know, to us that's ensuring that your commitments are reliable and that again, the AI volume isn't adding instability into your systems.
So we have planning and capacity accuracy as the North Star metrics to this.
And of course, as AI increases this output variability that I'm describing.
Um, how do managers like control planning and capacity accuracy, Dan?
Like just to make sure the the volume isn't like upending their sprints.
Yeah.
And this is and this is the balance aspect of it.
I I'm happy you brought it up that way.
I tried to talk to you and Ori yesterday about Mr.
Miyagi from Karate Kid, the balance.
And neither of you are watching Cobra Kai, uh, which you gotta you gotta watch.
But yeah, I always required watching for all engineering reviews.
Like Apex, Balance, Mr.
Miyagi, all of this goes together.
Yes, the balance side of it is if you're just generating a bunch of uh slop or junk, whatever, uh with AI, you would see okay, my planning accuracy in my uh sprints are decreasing.
I'm not actually doing what I say I'm gonna do.
It's not uh stories aren't getting completed, bugs aren't getting fixed, I'm not actually providing value back to the business.
I'm just messing around with AI and doing a bunch of volume stuff, like we said in the beginning of the pod.
And so I feel like that uh that's one of the balancers.
Hey, let's look for teams that okay, you do have uh, let's say uh nice AI adoption.
Yeah, maybe like 65, 70% of your PRs uh are AI assisted.
But your planning accuracy is increasing, your capacity accuracy is increasing.
Uh, you're doing what you say you will.
That's kind of like uh when I say like predictability, I think we really hear ensure delivery commitments remain remain reliable.
You're still a reliable delivery team, even though you're uh utilizing AI.
Like that's the bat, I think, balancing aspect of it.
Yeah, and this is where uh, you know, we haven't talked about quality indicators very much, but I do think this is where we where the quality starts to really come into the picture.
Um, because if if you have high if you're creating software with high defect rates, or if you're slow at responding to outages or failures, um, or if you are constantly reworking existing code and and refactoring it on like a just a constant basis because it doesn't it wasn't architected the right way.
Like all of these things are gonna impact your predictability in this the lens of AI, it's gonna get it's gonna amplify, it's gonna make it even worse.
You know, it's why this stuff is so important.
And speaking of important things, let's let's talk about the the sort of tried and true, though probably not the most exciting letter within this, and that's efficiency.
You know, no one really is excited about efficiency, but everyone wants to be efficient, right?
I'm excited about it.
Yeah, yeah, yeah.
I mean, it certainly feels really good to be efficient.
Uh and you know, and this is all about optimizing how your work flows from start to merge.
Um, our north star within this is cycle time, but we also, you know, getting to the quality side of things, we also throw in CFR change failure rate as uh a core metric to this because if you move faster but you're creating more failures, you're losing the gains of being more efficient.
So, you know, Dan, my question to you is, you know, if you're adopting AI, your coding time drops dramatically because AI is doing all the writing for you, but the review time spikes, your constraints just moved, right?
Like, isn't isn't that the case?
Like how how do we how do we use cycle time as the North Star within this?
Yeah, so I I said, hey, I like efficiency.
Uh let's pay homage to Dora, cycle time and CFR.
Yeah.
These are Dora metrics.
This matters.
The efficiency of how code flows through your SDLC and the endgame actually making it out to production into the hands of a customer, that matters a lot.
Yeah.
So, you know, to your point, hey, let's say coding time decreases uh by a ton, and let's say even uh PRs open increase by a ton.
If these PRs, uh no one's picking them up for review, they're not actually making it out to production, they're getting thrown back.
Maybe you do have standards in place that are kind of blocking these PRs.
Uh, maybe the test coverage is there.
Whether whether uh maybe they do make it out to production and your change failure rate is spiking.
The customer that I was talking about earlier, quality was actually their uh this person's number one thing on their mind in the AI era.
Yeah, the mindset was like, yeah, okay, we're we're deploying uh I think they I think they were using Claude.
Hey, everyone's using Claude.
And I can see a lot more stuff is happening.
But you know what they also told me?
My number one problem is incidents in production.
And uh this person told me they're caused by code.
Like these are direct bugs in prod.
So on the quality side, again, the change failure rate, paying homage uh to Dora.
Um, the rework rate, are we having to rework the code over and over again?
That's where the efficiency is that balancer uh to the speed of AI.
So, like I told you, I'm in on it efficiency.
I still like the E.
Yeah, and I think it's really important too to break cycle time down because you know, we've we've been touching on this uh multiple times, but cycle time is a fairly complex metrics metric.
There's a lot of stages that go into it.
Uh, and you really need to break down each individual component part.
So, what's your your coding time?
How long does it take PRs to get picked up for review?
How long does that review take?
And then once it's been approved, how long is it taking you to get it to deployed to production?
Like any one of these stages could be your constraint within the system, and you you really need to go from that like high-level efficiency view all the way down to like looking at the actuals the actual segments that are getting bottlenecked and and which PRs are the ones that are causing those bottlenecks.
All right.
So let's move on to the last pillar then, and this is the X, developer experience.
And this the purpose of this is just to ensure that any gains you get from uh AI are sustainable and human-centered.
You know, the humans are the ones that have to operate these systems, and at the end of the day, they should be satisfied with how they're performing.
And that's why we picked the North Star metric for this to be developer satisfaction.
So, you know, Apex kind of treats uh devX is almost like a guardrail, right?
So if if your cycle times are improving, but your developer satisfaction drops, um, like maybe that's an indicator that your productivity gains are actually just fake, they're illusory or unsustainable.
So let's talk about developer experience, Dan.
Like, like how how does this work within Apex?
Yeah.
Like we said earlier, the A, okay, the AI leverage, the P, the predictability, the E, the efficiency, and now the X.
To me, they all relate together.
They all they all relate.
And the way that I like to think about it is if I'm leveraging AI in the right way, and what we talked about is making sure that AI has the right impact, not just adoption, right?
The right impact.
If I'm improving my predictability, devs want predictability.
I mean, when I when I was a a developer, like chaos kind of, yeah, it's case might might be fun on a Friday when I'm experimenting, but not when I'm actually like on the hook to deliver my sprint on time.
I want less chaos.
So I want to deliver great work.
I want it to be in an efficient way, right?
I don't want to create a bunch of PRs and have them get stuck in the review process or not be able to get deployed.
That's the E.
And when these things come together, yeah, I think kind of like the final check is okay, let's just validate uh that if we're doing well with the A, the P, and the E, the satisfaction is there.
And usually what I see is like if the AI leverage, the predictability and the efficiency are looking good, um, the satisfaction is usually there.
Now you might catch like a red flag or something like that.
But anyways, I I kind of think that's okay.
Maybe that's like the final check to make sure that we are listening and we're on point uh with the other aspects of APE.
Yeah, and I think it's important to remember that satisfaction can be measured at multiple levels.
So you can look at like the overall satisfaction, like how how how do you feel about the way we do work and your job here and all of that?
Um, but then the qualitative side of this is is really great for like digging all the way down to the specifics.
So, like looking at the teams that are frustrated with AI and getting direct feedback from them about why they're frustrated so that you can address it, or looking at the teams that have been incredibly successful with AI and see what are the things that that make them flow really well that you could maybe uh take from them and apply to other teams within the organization.
So um that's I think what I really love most about this last one is is how it it you you can both measure it at the high level, but then go all the way down to like the individual teams and and individuals themselves who are in being impacted by uh AI and and just get direct feedback from them.
Yeah, well said.
So let's let's talk before moving on, just about connecting this all together.
So we've we introduced we've been introducing this framework to a lot of people so far.
Um I think a lot of people look at it and they just wonder like where do I start?
You know, there's there's four pillars here.
Uh which one's for me.
So so Dan, is it is it a matter of like I have to pick one of these that is the most important to me, or do we linear B have an opinion about which one you have to come in and pick first, or how how does that work?
No, I I I think the leather picks you.
It's like uh I don't know, like in Harry Potter, when you get selected to one of the houses, you don't pick, it picks you.
You get a nice leather shoe, and it's like this shoe was for me.
It it it picks you.
And and what I mean by that is uh what I'm what I'm saying seeing is okay, when customers come in and they're kind of like, let's say that you're early on in the AI adoption journey.
Let's say you're kind of at the start starting point.
Uh usually the P and the E, the predictability and the efficiency is the place to start for you.
That's how Apex selects you.
Why?
Because still at the end of the day, you gotta be predictable, you gotta be efficient.
That's the business of engineering.
Deliver value on time and do it in an efficient way.
And then you work the A in later.
Yeah, well, more importantly, um, you know, if we know that AI is an amplifier, if you have bad efficiency, if you have bad predictability, AI is gonna make it worse rather than so I think that middle is like the c the core of it.
Now, if you are on the other side and you're saying, hey, you know what?
I made a bunch of promises uh to the business around AI adoption and the impact of AI, or hey, my P and my E are really solid, like you said, uh Ben, and I'm really looking to amplify, so I'm getting that AI leverage, then you start with the A.
And then you you work your way to the right.
Okay, more AI adoption, and I'm gonna make sure that my predictability, my efficiency, and my satisfaction uh remain constant.
Yeah, I like that approach.
Very, very flexible, kind of meets you where you are rather than trying to form fit you into it, right?
It selects you.
Yeah.
All right.
Well, I feel like we've gotten a really great breakdown of what APX is, why we brought it to the market, and and why we think engineering leaders should be leveraging it today.
Um before we close out, I want to cover just a couple more things related to this.
And and the first is is how you put Apex into operation, right?
So as a part of this, we have a guide that that we'll include in the show notes with this.
Um, but we also included a recommendations for a specific rhythm of um operations around these.
So for example, you might want to track your AI, your AI leverage on a weekly basis because it's changing so frequently.
Or you might want to look at predictability once per sprint because it's just a natural cadence to analyze that.
Whereas something like DevX or your metrics that could be monthly or quarterly, depending on like how you as an organization feel about this.
So why do you think, Dan, is the is the cadence so important to Apex actually working within organizations?
I mean, I just feel like the business of engineering, the whole per like one of the main, I don't know, tenets of engineering is to have a repeatable cadence.
Engineering is like a machine that needs to be operating in a smooth way.
When the cadence gets broken, uh engineering is broken, the business is broken.
And so, like you said, yeah, like predictability, the P of Apex, go with the flow of your uh sprints.
Maybe it's two weeks, maybe it's three weeks.
If you're working in in Kanban, it's weekly.
On the efficiency side, yeah, I mean, I look I like to look at it uh, let's say uh twice a month.
Some organizations look at it monthly.
Uh on the AI leverage side, that's a monthly mode for me right now.
And I can see actually some of our customers are even like, okay, we're kind of under the gun here, so it's like weekly.
And reporting on all of these, yeah, you reported it to the business.
You get you owe it to the business.
It's a quarterly executive report.
Or if you're gonna serve survey developers, yeah, you do it at a quarterly case uh cadence.
But the whole key key to me is like the business of engineering runs on cadences, and therefore, like the apex framework, I think fits into the natural cadence of how engineering orgs operate.
Yeah, uh that makes a lot of sense.
And and I and it's one of the things I like the most about the framework is it's it's very easy to just you know, whatever cadence works for you.
Like, like you said, if you want to if you want to keep tabs on AI like every day, like because you're moving that fast, like do it.
You know, it makes makes sense for you.
But if you're an organization that's moving a little more slowly or uses it more for executive reporting, maybe a monthly or quarterly cadence makes a lot more sense.
But the the flexibility of Apex, I think is what one of the things that makes it really powerful.
All right.
And then I want to close out by just talking about how we actually operationalize this data.
So, you know, a constant theme we've always had uh at Linear B at Dev Interrupted is that you know, visibility doesn't matter if you're not taking action upon it.
So you know, I'm curious, Dan, from your perspective, like what's the first step to taking for an engineering leader to take advantage of Apex and what should their goal be by adopting this framework?
Yeah, great question.
I mean, the the engineering leaders that I work with when we first start together, it's getting to a benchmark.
Let's come benchmark against APEC.
You gotta see where you are.
Yeah, yeah, like we said before.
If you come in and you know, hey, I'm already predictable, I got great efficiency, I need to start with AI.
So okay, the A selects you.
But oftentimes, again, Apex is a balanced uh framework.
Let's see where you are from a benchmark perspective, and then let's decide together.
And uh usually when you come in, okay, you come in, you start using Linear B, you know, you start using the platform, it will show you show you on the benchmarks.
It's pretty obvious where you'll uh same way, the benchmark will select you.
So it kind of lets you know, hey, let's start here and then build a progressive plan.
So giggle.
Here's the thing for you to solve today, kind of thing.
Come get your benchmark and then see where you want to improve, set a goal.
Those are the first two steps.
Yeah, and then and then of course, uh, you know, I think uh what one of when someone does that, they're gonna encounter a lot of common bottlenecks that we see time to time, things like code reviews, for example, or frequent bottleneck.
Uh so I'm just curious, like what what's your opinion on, you know, once you've got these metrics, like what's the next step that someone should be taking?
And they benchmark.
Yeah, yeah, yeah, yeah.
So at Linear B, we're always doing uh metric and then action.
Once you see all of your metrics, you're gonna look at them, you're gonna get benchmark, and what's a natural thing to do?
Okay, I see these metrics.
Maybe I'm talking to like the linear B MCP, I'm getting my insights.
At the end of the day, you gotta take the next step to uh action.
So, like for us at Linear B, we would say, hey, let's go roll out the AI code review.
Let's put in some git stream rules, let's work with uh let's turn on worker B.
These are the things that make the A, the P, the E, the X actually improve.
Um, so yeah, action's the next step.
Yeah, and I think in particular, AI when you're adopting it and so you're you're again putting it into your critical path, uh it it's really useful to have deterministic controls that keep it on guard, like keep you keep it on like inside of guardrails, you know.
Uh and yeah, I think without that, it's it's very easy for for a team that might otherwise be successful to be one of those teams that gets overwhelmed by AI slop, right?
Let's keep them in line.
Yeah.
All right, Dan.
Well, it's it's always great talking to you about these topics.
I I think this is just a really great reminder today that you know the tools are changing very rapidly at times, especially now, but the goals really are have always been the same.
You know, we want to deliver value to customers.
And I feel like we've really only scratched the surface of of what we could get into with Apex and you know how it can impact engineering leaders.
Uh so I definitely think we're gonna have you back at some point to to talk about this.
Um, there's, I think, a lot of room for follow-up content that I'm hoping we'll we'll be able to bring onto Dev Interrupted in the future.
But yeah, thanks, Dan, for coming out today.
Thanks for having me, man.
Can't wait to be back uh next time.
When you call, I'll be there.
Alright, awesome.
Well, for those of you that are listening, if you want to see the full Apex operating model with the metrics and the visual breakdown of these pillars that we discussed, you know, you can head over to your favorite search engine, look for the Linear B Apex framework.
We'll also have a link in the show notes if that's easier for you.
Dan, thanks to you and our audience for joining us today.
If you found this episode helpful, feel free to share it with another engineering leader who's navigating this AI transition.
I'm sure they would really appreciate the help right now.
And you, our listener, are in a place to help them because of what you've learned here today.
So help us out, help your friends out, share this episode, share the guide.
We'd love to hear what you all had to think about it.
And we'll see you all in the next episode.
AI is everywhere in software engineering, but most teams still can't prove its impact.
That's where the Apex framework comes in.
Apex is a new operating model for engineering productivity, designed to measure AI where it actually matters at the pull request level.
It connects AI activity to delivery outcomes, not just tool usage.
Apex is built on four pillars with AI leverage, predictability, efficiency, and developer experience.
Apex helps you increase throughput without sacrificing delivery confidence or burning out your team.
Because speed without predictability creates chaos and faster coding often shifts bottlenecks downstream.
If you want to operationalize AI the right way, Linear B and Apex gives you the system and the cadence to do it.
Download the guide and start measuring what matters.